前言

在人工智能快速发展的今天，大语言模型（Large Language Model, LLM）已经从实验室走向了大众日常的生产力场景。我确实认为大学生们，至少在靠AI写论文的大学生们，确实需要了解一些关于AI应用上的东西，而不是盲目地去买豆包专业版。

不同于真的大学纯水通识课，本文不会说什么神经网络、Transformer这种底层知识，而是从实际落地出发，面向普通人介绍如今AI的真正能力边界。对于非计算机专业背景的学习者而言，我们只需要学会如何正确、高效地与大模型进行交互，并将大模型的能力融合进现实的业务流程与工作流中。

一、大语言模型与文本生成式AI

1.1 纯文本交互

大语言模型最基础的使用方式是纯文本交互。用户通过输入自然语言提示词（Prompt），模型根据概率预测逐字生成文本回复。

纯文本交互的本质是上下文续写。模型并没有人类意义上的思考过程，而是基于海量数据训练出来的语言规律，根据当前输入的上文预测下一个最可能出现的词。在上下文中，历史消息以外的、针对当前任务的新消息称为提示词。模型可接收到的所有文本（多模态模型包括图片等）称为上下文。

模型收到的上下文是多个被分类的块，包括一个系统提示词、数个用户消息、数个模型输出和数个工具调用结果。大模型厂商以此区分每段文本的身份定位，对模型进行针对性训练，这使得模型更能理解自己当前的角色进行回复，我们也能看到它明确的回答开始和结束。

• 系统提示词由开发者设计。模型训练时通常被训练得不容易被透露给用户。遵循等级一般最高。
• 用户输入包含用户对模型下达的指令。模型分辨它们来自用户，在与系统冲突时模型会拒绝用户。
• 模型输出包含模型对以上所有内容所进行的回复。模型会读取历史的所有系统提示词、用户输入和模型输出，然后向用户输出文本作为回复。

1.2 工具调用

在纯文本交互中，模型输出的内容完全由其内部预训练的参数和提供的上下文决定。这使得它无法实时获取外部信息（如查询今日天气或实时汇率），也无法准确执行复杂的数学计算或对外部系统发起真实操作。为了让模型理解“自主获取信息”的概念，工具调用系统被训练、分化出来用于模型语义主动地获取信息。组成工具调用的基本功能包括工具调用结果上下文和模型工具调用输出。

模型工具调用输出是模型的“手”。是模型在合适的上下文下输出的一种不同于纯文本的输出模式。它允许模型：

1. 以字符串方式指定一个工具，再通过某种参数化方式传入执行参数。其中参数化方式通常为JSON格式。
2. 获取工具调用的结果。工具调用应当是无需用户参与的。 模型在合适的上下文下才会进行工具调用。常见的情景是系统提示词包含了工具调用的说明时。此时模型就会遵循系统提示词的介绍进行工具调用。

工具调用结果上下文是模型的“眼”。在模型发出工具调用时，收到它的处理机(Harness)应当具有处理该工具调用的能力。在完成工具调用后，返回一个工具调用结果上下文插入上下文历史中，再次返还给模型进行续写。

• 处理该工具调用的能力，具体来说，就是
  1. 识别模型给出的模型工具调用输出，提取对应的工具和参数。
  2. 获取对应的工具，进行工具的执行。
  3. 返回该工具的执行结果。
• 模型可能会在多次请求中依次调用工具调用。也会在一次请求中并行附带多个工具调用。部分模型也支持模型同时输出工具调用和文本。
• 语言大模型天生具有泛化性。如果处理机返回“该工具不可调用”，模型会采取一系列措施绕过该方式，包括但不限于尝试使用其他方式、向用户说明服务确实暂时无法使用、甚至可以自行尝试修复处理机(或工具)本身。
• 我们后续会称这种处理机为Harness。

以AI应用作为Harness，一个完整的AI应用通过工具调用获取信息的完整工作流程为：

1. 开发者通过系统提示词等方式配置，将一系列可调用的工具（含工具名称、功能描述及所需参数格式）告知模型。
2. 用户向AI应用发送指令，指令以用户消息的形式送达模型。
3. 当用户的指令需要借助外部工具时，模型输出一个结构化的工具调用输出，其中指定了模型要调用的工具名称以及由模型填入的参数。
4. AI应用捕获到模型的工具调用请求后，拦截该指令，并在现实世界中执行对应的代码逻辑或 API 调用。
5. 宿主程序将执行后获得的数据以工具调用结果上下文的形式重新拼接到上下文中传回给模型。模型读取到最新的工具结果后，总结并输出最终面向用户的解答。

通过这种机制，大模型能够体现一定的能动性，感知外部环境、调度多种计算资源。

马克思主义认为，能动性(Agency)是人区别于一般物的自觉活动能力，在实践基础上能动地认识世界和改造世界。

在极为充分的Harness环境下，大模型体现了与人类极为相似的能动性，我们称这种组合体为Agent。

思考：Agent是否拥有主观能动性？ 马原背疯了说是

1.3 处理机 (Harness)

模型本身只提供接收一段上下文，返回一段文本或工具调用的接口，而用户面对的是网页、终端或编辑器。介于二者之间、负责把请求送出去并把结果取回来的程序称为 Harness。Harness 位于用户界面与模型之间，负责模型提供接口不做、但所有可以按预期自动化执行的任务。

以一次普通的对话为例，Harness 至少完成了以下工作：

1. 拼装请求：保存历史消息，在每次请求时把系统提示词、历史消息与用户的新输入按顺序拼接为完整的上下文，并携带 API 密钥发送给模型接口。
2. 接收与呈现输出：接收模型返回的纯文本，流式输出时逐字显示在界面上；其中的标记语言交由渲染器转换为富文本。
3. 执行工具：当模型输出工具调用时，解析其中的工具名与参数，执行这些工具，并把执行结果作为新的上下文块写回历史。
4. 管理上下文长度：历史消息过长时，对上下文进行截断或摘要。
5. 处理异常与用量：网络中断后的重试、接口限速的处理、用量与费用的统计。

只有系统提示词、用户消息和模型输出的产品形态称为聊天机器人（Chatbot）。最简单的聊天机器人只有拼装请求、接收与呈现输出的功能。由于缺乏管理上下文长度，过去的网页AI聊天过长时会产生提示。现代的大部分聊天机器人都有网络搜索这一功能，这是通过执行工具实现的。虽然 Harness 不必提供工具调用功能，但工具调用功能一定由 Harness 提供。

二、富文本

从上个世纪电脑刚普及开始，人们对于想在文本中指出重点这件事上就一直非常努力。

纯文本虽然能够完成绝大多数信息的传递，但在日常办公、学术研究和网页排版中，仅靠纯文本难以展现清晰的结构与视觉效果。包含加粗、标题、列表、表格甚至更奢侈的复杂样式的文本，我们称之为富文本。

在AI时代，掌握如何用纯文本字符来表达排版格式即文本编码语法变得至关重要。因为大语言模型本质上只能输出纯文本字符串，它能且只能通过生成特定的格式控制语法，再由 Harness 交给渲染器将其转换为视觉丰富的富文本界面。

2.1 图形界面工具与办公软件

在传统的办公环境中，我们最熟悉的是可视化图形界面（GUI）工具，例如 Microsoft Office和 WPS Office（包括其中的Word、PowerPoint、Excel）。这类工具采用所见即所得的模式，用户通过点击鼠标按键（如“加粗”、“设置字号”）来调整样式。点击功能按钮时，软件实际上将当前操作的文本/段落对应的数据结构进行修改。这个数据结构中包含了大量刻意对用户隐藏的配置和样式，这使得用户界面十分简洁易用，但也经常导致找不到某个选项来进行某种修改。“字符底纹”和“文本突出显示颜色”就是一对这样的例子。

我们无法展示Office的语法。它的语法不是一种语言，它们被层层压缩到文件中，纯文本基本无法描述Word文档。这样的工具也并不匹配大模型的工作逻辑。人类使用图形界面的高效在于手眼协调，而模型有更好的方式编写带格式的文本，而不是输入文本后低效地模拟人类进行格式设置。

2.2 HTML5

HTML5（超文本标记语言，H5）负责定义网页的结构与内容（如段落、标题、图片、表格），而 CSS（层叠样式表）则负责定义内容的视觉呈现（如颜色、字号、布局、动画）。我们不需要学习它的完整语法，仅了解它的有限特性即可。它的表示类似于：

<section>
	<h2>二级标题</h2>
	<p><b>重点</b><i>区分</i><u>下划线</u></p>
	<p style="font-size: 20pt; color: red">20磅 红色</p>
</section>

显示起来就是：

一方面，HTML/CSS是现代互联网排版的基石。互联网中几乎所有能看到的界面都可以通过它们实现。模型输出HTML/CSS代码，可以生成极其丰富且定制化程度极高的可交互界面。自然，几乎所有在Word文档中能做到的排版内容也都可以使用HTML/CSS实现。

另一方面，如上所示，HTML实现简单的语法依赖大量而繁琐的前后闭合标签，CSS依赖大量重复的关键词，这对上下文有限的大语言模型的理解上是不利的。模型生成冗长而繁琐的代码会消耗大量的Token，导致响应速度变慢，且还容易因少写一个闭合标签而导致排版错乱。因此，在不需要复杂专业场景时，通常不会直接让模型输出原始的 HTML/CSS。

它们常被市场宣传统称为“HTML5 技术”，以至于你可以使用”H5”来简称它。这默认包含了HTML5+CSS3。

2.3 LaTeX

LaTeX 是一种基于 Plain TeX 的排版系统，广泛应用于学术界、科研机构以及出版业。它能够精准处理高质量的文档排版，特别是在复杂数学公式的呈现上具有不可替代的优势。对于有数学任务，模型经常主动在输出中使用LaTeX表达式来表达数学公式。它的表示类似于：

\begin{cases}
\dfrac{-b \pm \sqrt{b^2 - 4ac}}{2a} \\[6pt]
s(x)=\displaystyle\int_0^x\sqrt{1+\left[y'(t)\right]^2}\,dt
\end{cases}

以上代码将渲染为：

大模型在解答数学题或撰写学术论文时，会自动将推导过程中的公式用 LaTeX 标记输出。Harness的渲染引擎（如有，如MathJax或KaTeX）会自动将其转化为美观的公式图形。

2.4 Markdown

Markdown 是一种轻量级标记语言，它允许人们使用极为易读易写的纯文本格式编写文档，然后转换成有效HTML来显示。由于其语法简单、占用的 Token 少、对模型极度友好，Markdown 已成为大模型默认的富文本输出标准。顺带一提，本博客使用 Markdown 进行写作。

Markdown 语言创造者 John Gruber 说：

Markdown 不是 HTML 的替代品，甚至远远不是。它的语法只覆盖 HTML 的一个很小的子集。

对于 Markdown 没覆盖的标记，你直接写 HTML 就行。

Daring Fireball: Markdown Syntax Documentation

关于Markdown的基础语法，网上已有大量极为成熟、阅读时间不超过五分钟的教程，本文不再作冗长介绍。

Markdown在发展过程中，不同的平台和软件对其语法进行了扩充，形成了多种方言（Dialects）。大模型有时会自发地使用其中的一种或多种常见方言。

GFM (GitHub Flavored Markdown)

这是目前最流行的方言标准。在基础语法上增加了删除线（~~内容~~）、任务列表（- [x] 已完成）、自动链接以及表格支持。

LaTeX 数学公式

使用单个美元符号 $ 包裹以绘制行内公式。例如 $E = mc^2$ 渲染为 $E = mc^2$。 使用双美元符号 $$ 包裹以绘制块级公式，独占一行并居中。例如：

$$
\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}
$$

渲染为

Mermaid 图表

Mermaid 是一种纯文本驱动的可视化图表生成器，Harness 将 Mermaid 语言的代码块转换为 Mermaid 图表。它的表示类似于：

```mermaid
graph LR
A-->B
```

渲染为

第一章中部分图表就使用Mermaid渲染。

用户侧使用

使用**双星号**包裹你的文本后，模型理所当然地会理解这个词更重要。但对于更多复杂语法，实际上，只要你的输入没有歧义，模型都可以基本理解你所输入的内容。比如你不需要对所有代码块都添加三个反引号。甚至对于数学公式也可以简化到抽象的地步。

这里我所说的 int 0,inf exp -x**2 dx 是指：

\int_{0}^{+\infty} e^{-x^2} dx

即 LaTeX 表述的：

其中模型正确无歧义地理解了：

• int 数学中常用于表示积分
• 0,inf 在积分后可以表示定积分上下限
• exp 数学中常用于表示$e$的幂函数
• -x**2 中，**是 Python 中表示幂的运算符，这里只是因为我在手机上比^好输入，且这也是能被模型理解的。
• 公式是标准的高斯积分，不可能被理解为其他歧义公式。

如上便可轻松地在纯文本下让模型准确无误地理解数学公式，前提是有一定 LaTeX 数学语法基础。这个方法的重点是无歧义，如果创造了有歧义的式子，模型可能在猜测意图上花费大量时间。

三、命令行

2026年初“小龙虾”爆火。圈外人也不知道为什么火，我圈内人也不知道为什么火。它既不万能也不无能，本质上还是个工具。我们上面已有工具调用的基础，再谈它的底层原理就是一句话：

“AI直接使用一台完整独立服务器命令行作为工具调用。”

等等，什么是命令行？

相比基于人类手眼协调操作所制作的图形界面软件，大模型更适合使用简洁明确的文本化交互方式来进行工作。好在，这种交互模式早已成熟且仍然存在。

2025年2月，Anthropic 发布了 Claude Code，这是一个直接在终端中运行的研究预览版 AI 编程工具，能够自主读代码、改文件、运行命令(1)。随后，OpenAI 的 Codex CLI（2025年4月）和 Google 的 Gemini CLI（2025年6月）相继发布。这三大 AI 实验室的产品发布，标志着“大模型直接使用命令行”作为一种主流产品范式的正式确立。它们都属于 Harness。

3.1 操作系统的命令行

命令行是通过输入文本指令来控制计算机操作系统的界面。

• Windows 操作系统：常见的命令行环境有 cmd（命令提示符）和 PowerShell。其中 PowerShell(pwsh) 功能更为强大，支持复杂的自动化脚本。
• macOS / Linux 操作系统：使用的是基于 Unix/Linux 架构的终端（Terminal），默认的 Shell 环境通常为 bash 或 zsh。

此处的“控制计算机操作系统”要回到电脑没有图形界面的年代去理解，一切操作是基于电脑没有可视化操作实现的，我们使用命令来进行所有基本操作，这包括创建删除修改查看文件和文件夹内容、以及运行各种命令行软件。

命令行上以字符为单位。在命令行上除了纯粹使用计算机执行的办公任务，没有什么“能玩”的东西。你能在命令行中看到分辨率最高的东西很可能是ascii艺术画。

要让大模型对电脑进行操作(读取文件等)，使用人类的方式阅读屏幕、进行屏幕点击等模拟鼠标操作是极为低效的。进入2026年后，大模型训练普遍提高了“智能体”能力的训练权重，其中就包括对命令行操作的能力。

基础结构

在命令行里，一条完整指令通常由命令名称、选项和操作对象组成，并以空格分隔。以 Linux/macOS 下列出目录的命令为例：

ls -l -a /home/user

• 命令：ls（list，列出目录内容）。
• 选项：
  • -l - 使用长格式显示详细信息.
  • -a - 显示包含隐藏文件在内的所有文件.
  • 单个字母的参数通常以连字符 - 开头.
  • 多个字母的参数以双连字符 -- 开头，如大多数应用都提供 --help.
  • 多个单字母参数通常可以简写连写，如 -la.
• 操作对象（Argument）：/home/user，指定要操作的目标路径。

* 常见命令

ls 是bash中最基础的用于查看目录下文件的命令。它和大量其他命令包括:

• pwd - 显示当前所在的绝对路径
• cd - 切换目录
• ls - 列出目录内容
• touch - 创建空文件或更新文件时间戳
• mkdir - 创建目录
• cat/less/more/head/tail - 以各种方式查看文件
• cp - 复制文件或目录
• mv - 移动或重命名文件/目录
• rm - 删除文件或目录
• rmdir - 删除空目录
• find - 在磁盘上查找文件或目录
• grep - 在文件内容中搜索文本
• chmod - 修改文件权限
• chown - 修改文件属主

等一同组成一组控制电脑的基本文件系统操作，大模型会频繁大量使用这些命令来与文件系统交互，如阅读和修改文件代码。

除了文件系统，还有如ps以各种方式查看进程等命令操作，但涉及较深操作系统相关知识，此处不再介绍。

3.2 命令行软件

上一节中提到的命令均为操作系统自带命令。除此之外，开发者和用户还会安装各种命令行软件来完成具体任务，它们是模型在终端里的主要工具。

这些软件提供了复杂的功能，如 curl（网络请求工具）、git（代码版本控制工具）、ffmpeg（音视频处理工具）、markitdown（二进制文件转文本工具）、甚至 python 这种家喻户晓的编程语言本身，在没有外部封装的情况下也是需要使用命令行调用的。它们同样完全使用命令行进行操作，而且是相当一部分图形界面软件内部调用的基础组件。

大模型可以通过上一章提到的工具调用能力，将复杂的业务需求转化为一行具体的 CLI 工具命令并交给 Harness 执行。例如：

ffmpeg -i input.mp4 -vn -acodec libmp3lame output.mp3

模型通过执行上述命令，直接将一段视频文件中的音频提取为 MP3 格式。

安装和检修命令行软件

在 Windows 上右键 Windows 图标，点击 Windows PowerShell，进入 PowerShell 界面。接下来执行应用对应的命令即可检查对应命令行软件状态。

一个软件中可能有多个程序，每个程序对应一个命令，或者说命令背后就是一个程序。对于编程语言 Python 来说，它同时提供了 Python 运行程序 python 和包管理器程序 pip。

部分软件基于其他软件运行。举例来说，软件 markitdown 是基于 python 的，python 提供了其生态下软件的包管理工具 pip，pip 本身也是一个软件，通过 pip 可以下载 markitdown，然后就可以直接在命令行使用 markitdown 软件了。

大多数软件中有一些约定俗成的参数，这包括：

• --version - 查询软件版本
• --help - 查询软件自带的帮助

% 检查markitdown
C:\Users\BPuffer>markitdown --version
markitdown 0.1.6

% 在pip中检查markitdown作为包的状态
C:\Users\BPuffer>pip show markitdown
Name: markitdown
Version: 0.1.6
Summary: Utility tool for converting various files to Markdown
Home-page:
Author:
Author-email: Adam Fourney <adamfo@microsoft.com>
License-Expression: MIT
Location: C:\Users\BPuffer\AppData\Roaming\Python\Python312\site-packages
Requires: beautifulsoup4, charset-normalizer, defusedxml, magika, markdownify, requests
Required-by:

% 检查pip的状态
C:\Users\BPuffer>pip --version
pip 25.0.1 from C:\Users\BPuffer\AppData\Roaming\Python\Python312\site-packages\pip (python 3.12)

% 检查python的状态
C:\Users\BPuffer>python --version
Python 3.12.8

软件自带的帮助通常遵循一个大致的讲述格式，需要一定的英语能力方能看懂。例如：

C:\Users\BPuffer>markitdown --help
usage: SYNTAX:

    markitdown <OPTIONAL: FILENAME>
    If FILENAME is empty, markitdown reads from stdin.

EXAMPLE:

    markitdown example.pdf

    OR

    cat example.pdf | markitdown

    OR

    markitdown < example.pdf

    OR to save to a file use

    markitdown example.pdf -o example.md

    OR

    markitdown example.pdf > example.md

Convert various file formats to markdown.

positional arguments:
  filename

options:
  -h, --help            show this help message and exit
  -v, --version         show the version number and exit

...

环境变量

在 macOS/Linux 上，大多数软件安装后的PATH会自动配置，可以立即在命令行调用。Windows 由于其图形化操作及历史原因，程序自动配置PATH经常失效。本节将简单介绍 Windows 上环境变量的配置。

大部分软件在硬盘上作为程序存在，并不能作为命令直接使用。我们可以通过键入程序完整的目录位置来运行这些程序，但这十分麻烦，且对于尤其常用的软件，记住完整路径并不合适。

// TODO

* 3.3 Shell

单条命令只完成一个动作，实际任务则需要若干动作按顺序配合。为此，命令行在程序之外还有一层解释器，负责组合命令、展开路径、替换变量，这个解释层称为 Shell。

随多种操作系统存在多种 Shell。macOS/Linux 上常见的是 bash、zsh，Windows 上对应的是 cmd 与 PowerShell。

1. Shell 允许把一条命令的输出直接交给另一条命令作为输入，这称为管道（|），中间结果不经过屏幕。管道可以连续使用，形成一条处理链（流水线），每个命令处理一个流水线任务，这也是命令行软件普遍遵循的设计方式。

2. Shell 允许改变一条命令的输入来源与输出去向，称为重定向，包括 > 将输出写入文件，>> 将输出追加到文件末尾，< 从文件读取输入，以代替键盘输入等。

3. Shell 允许把多条命令写在一行中，称为命令的连接，如; 依次执行，前一条失败也继续，&& 在前一条执行成功时才执行后一条，|| 在前一条执行失败时才执行后一条。

4. Shell 中可以使用 * 匹配任意长度的任意字符。如 *.md 表示当前目录下所有 Markdown 文件。使用 ? 匹配单个字符。

5. Shell 中表示字符串时，双引号 "AA$NAME" 中的变量会被正常替换 AAuser，单引号 'AA$NAME' 中的内容一律按字面处理 AA$NAME，反斜杠 \ 可以使其后的任意单个字符失去特殊含义，此反斜杠本身不会展示，可以使用 \\ 表示反斜杠本身(转义自身)。路径或文件名中含空格时需要用引号包裹。

6. 变量替换与命令替换让一条命令的输出成为另一条命令的组成部分。$HOME、$PATH 等环境变量写在命令中，由 Shell 替换为具体值。$(命令) 先执行括号内的命令，再把输出拼接进当前位置。

7. 以 # 开头的部分为注释，Shell 不会执行。

示例：

LOG=/var/log/nginx/access.log
OUT=$HOME/nginx_report

mkdir -p "$OUT" &&  # 创建目录；成功才继续
    echo "开始 $(date)" >  # 输出开始时间，重定向到
    "$OUT/report.txt" ||  # 报告文件；如果前面失败
    echo "创建目录失败" >>  # 记录错误到
    /tmp/nginx_report.err  # 错误文件

grep ' 500 ' "$LOG" |  # 筛选 500 错误
    awk '{print $1}' |  # 提取第一列 IP
    sort |  # 排序
    uniq -c |  # 去重并计数
    sort -nr >  # 按次数降序排序，并重定向到
    "$OUT/500_ips.txt"  # 结果文件

wc -l <  # 从文件读取输入，统计行数
    "$OUT/500_ips.txt" >>  # 输入文件；追加到
    "$OUT/report.txt"  # 报告文件

cd "$OUT" ||  # 进入输出目录；失败则
    exit 1;  # 退出
tar -czf 500_ips.tgz 500_ips.txt report.txt  # 打包结果文件

echo "结束 $(date)" >>  # 追加结束时间到
    "$OUT/report.txt"  # 报告文件

一个模型可能输出的、较为现实的命令如同：

DIR=/tmp/shell_demo; FILE="$DIR/report.txt"; mkdir -p "$DIR" && echo "开始 $(date)" > "$FILE" || echo "初始化失败 $(date)" >> /tmp/shell_demo_error.log; grep -v '^#' < /etc/hosts | sort | uniq > "$DIR/hosts.txt"; wc -l < "$DIR/hosts.txt" >> "$FILE"; echo "完成 $(date)" >> "$FILE"

用于极为复杂的单次自动化操作。

* 3.4 命令输出与控制流

在进程执行模型中，程序终止时均会返回一个退出状态码（Exit Code），其取值为 0 至 255 之间的整数。按惯例，0 表示成功，非 0 表示失败。在 Shell 中可通过 $? 获取。退出状态码首要用途是供调用方程序判定执行结果。

常见约定包括：

• 1 表示一般错误
• 2 表示用法错误
• 126 表示无执行权限
• 127 表示命令不存在
• 128 + n 表示进程被信号 n 终止，例如 Ctrl+C 对应的退出状态码为 130。

任何程序都拥有特殊的文件标准输出（stdout，文件描述符 1）与标准错误（stderr，文件描述符 2）。语义上，正常执行结果应写入标准输出，警告与错误日志应写入标准错误。各类编程语言中的 print 本质是向标准输出写入一段文本。一般执行命令时，标准输出与标准错误都被默认连接到终端上被直接显示。

Harness 将执行一条命令所获得的信息返回给模型。其内容可归结为以下三类：

1. 标准输出与标准错误：合并为一段文本，作为工具调用结果写回上下文。命令产生大量日志是常见情形（如 npm install、编译、递归 grep），而上下文窗口容量有限，故输出可能被 Harness 截断。Harness 通常保留首尾若干行，并在结果中注明截断。
2. 退出状态码：若为 0（成功）且有其他输出时，可能跳过此段。否则将此状态码作为一段信息合并到上下文。若干工具使用非零退出码表示“未找到”、“存在差异”等正常结果（例如 grep 未匹配时返回 1），故退出状态码也经常传递重要信息。
3. 其他可选信息：执行耗时、是否因超时被停止、输出是否被截断及截断了多少行、权限不足等命令执行过程和信息呈现本身相关的信息。

四、智能体 (Agent)

让模型自动地完成所有任务的模糊概念在2023年就有出现，但由于当时及其后的模型的智能和上下文不足、Harness 的概念不够完善导致模型出现无法有效进行工具调用、无法有效循环等问题。

2026年2月5日，Mitchell Hashimoto 的博客My AI Adoption Journey，正式提出了 “Harness Engineering” 这一术语。其核心理念是“每当 AI 犯错，就工程化一个方案让它不再犯同样错”，即通过构建外部系统来引导和修正模型行为。这为后来“Harness”作为模型之外一切控制机制的总和奠定了概念基础。

$\text{ Agent = Model + Harness }$ 将“Harness”定义为模型权重之外的一切，包括系统提示词、工具调度、上下文管理、权限控制、错误恢复等所有工程化组件。

4.1 工作循环

智能体(Agent)是由大语言模型与具备工具执行能力的 Harness 组合而成、能够在无需人工干预的情况下连续完成多步任务的系统。

单次工具调用的具体过程已经在1.2节有所介绍：模型输出工具调用，Harness 执行该调用，执行结果被写入上下文，模型据此生成回答。智能体与这一过程的区别在于，目标未必是“回答用户的问题”，而是在修改、运行、测试的工具调用循环中得到一个目标完成的结果，工具调用过程会被反复执行，直到满足终止条件为止。

单个循环由三个环节构成：

1. 模型决策输出：模型读取 Harness 提供的上下文，模型运行，输出文本或工具调用。
2. 执行工具调用：Harness 将工具调用格式识别为对文件系统、命令行或网络接口等的实际操作，运行并收集其输出。
3. 注入工具调用结果：将执行结果作为新的上下文块(即工具调用结果上下文)追加到消息历史中，成为下一次决策的输入。

模型不保存状态。每次续写都是一次独立的调用，输入为上下文，输出为文本或工具调用。所谓“聊天记录”，实际来源是 Harness 每一轮重新提交的完整历史。上下文是系统中唯一的状态载体。

上下文长度是有限资源。随着轮次增加，历史消息不断累积，接近上限的同时每一轮的费用与时间也在上涨。为了让长任务能一直跑下去，主流 Harness 会用两种办法把上下文压回安全范围：窗口法与压缩法。

• 窗口法：丢掉最早的若干轮消息，只保留系统提示词和最近的一批。它不额外花钱也不额外花时间——被丢掉的旧消息本来也要在每一轮里重复付费——代价是丢掉的约定就真的没了。所以它适合“近期消息就能决定行为”的场景：模型连续处理同一批文件、反复执行同一类命令、按固定顺序翻日志，旧消息里的细节对下一步几乎没有影响。反过来，如果任务开头有一句“先不要动数据库”，而这句话被窗口丢掉了，模型接下来就真的会去动数据库。窗口法不会让循环暂停，开销稳定；上下文结构保持一致的时候，模型的产出也会更稳定。
• 压缩法：把消息历史交给模型总结成一段摘要。Harness 附加一条总结要求，把当前完整上下文发出去，取回摘要，再挑出其余必须保留的部分（通常是系统提示词、最初的用户任务、最近若干轮），组成一份新的上下文。它要多花一次模型请求，但换来的是一条可以继续跑很久的线索。压缩必然丢细节，所以 Harness 一般会在要求里写明“保留结论、待办、当前状态、文件路径”，而不是让模型自由发挥。

现实中的 Harness 往往是两者混用：先窗口，接近上限再压缩；对个别特别占地方的东西（几万行的命令输出、整篇网页正文）单独截断或摘要。模型本身对这件事毫无感知——它看到的永远是 Harness 递给它的那一份上下文，它不知道自己曾经忘记过什么。

正常情况下，当模型不再输出工具调用、用户主动中断、循环达到 Harness 预设的步数或时间上限时，循环将终止。但如模型 API 无响应这类可能导致工作运行异常，但有可能修复的问题，Harness 有责任进行处理（如限制重试次数地重试调用模型请求）。

4.2 工作区

工作区（Workspace）就是一个文件夹。Harness 启动时选定一个目录，此后模型所有的相对路径、文件读写、命令执行都默认发生在它里面。没有工作区这个概念，“读文件”三个字就没有宾语。

工作区通常等于一个项目：一个网站的全部源码、一篇论文的草稿和数据、一套爬虫脚本、一本笔记。把它做成一个文件夹，好处是模型看到的“世界”和你交付的东西是同一个东西：

• 路径是相对的。模型写 src/index.ts，指的就是工作区里的这个文件。同一个任务换一台机器、换一个工作区目录，命令不用改。
• 沙箱通常以工作区为界。工作区之外的读写要么被拒绝，要么需要你逐次批准（见 4.6 节）。这一层的意义是让“模型只能碰这个文件夹”成为一个工程事实，而不是提示词里的一句请求。
• 工作区里有什么，模型的世界里就有什么。它看不见你的桌面、浏览器标签页和别的项目，除非路径能到达。所以想让模型用上的资料就放进工作区，不想让它碰的密钥就别放进去。

项目里的特殊文件

有一类文件既不是给人看的，也不是给编译器看的，而是给模型看的。Harness 启动时会自动把它们读进上下文：

• AGENTS.md：工作区的说明书，通常写着项目结构、怎么构建、怎么跑测试、代码规范，以及“不要做什么”。Codex、DSH 等使用这个名字。
• CLAUDE.md：Claude Code 使用的同类文件，写法与作用基本相同。有的 Harness 两个名字都读。
• README.md：给人看的项目说明。模型会主动去读它，但不会被自动注入——这个区别在上下文紧张的时候很重要（见 4.1 节）。

这类文件的价值在于省掉每次都要重复的交代。把“构建命令是 pnpm build”“不要修改 dist/”“提交信息用中文”写进 AGENTS.md，比每次开新会话都重新说一遍可靠得多。它们属于项目，不属于某个 Harness：换一个工具，同一个 AGENTS.md 大体上照样管用。

4.3 能力边界

智能体的能力由模型、Harness 和工具条件共同决定，任何一方不足都会导致任务无法完成。

模型能力不足时，智能体可能：

• 无法理解工具调用，完全无法做到有效的事件循环。
• 进行基础的工作，但缺乏测试甚至陷入循环无法交付。
• 在遇到问题时，无法给出有效的解决方案，错误将问题归因后结束循环
• 能完成测试等循环逻辑，但循环极长导致大量循环消耗。
• 使用较差的方法解决问题，可能产生各种额外问题需要解决。
• 能完成任务，但无法充分理解任务隐含情境导致结果不佳。

Harness 或工具能力不足时，智能体可能：

• 没有有效的完成工作途径。目标在框架下未被提供转化为现实的充分根据和必要条件。
• 因工具说明不足频繁导致问题，提供的工具被模型认为“不好用”。或花费大量时间测试 Harness 提供的工具是否有效。
• 上下文管理不当导致模型遗忘初始任务、陷入死循环或超出 Token 限制。
• 导致沙箱逃逸，向模型泄露隐私和不安全接口。

这些问题的共同来源

把上面两张清单归一下类，智能体的失败基本出在四个地方。

1. 上下文不是记忆。模型每一轮都从零开始读一遍 Harness 递给它的上下文。上下文里没写的东西，对这一次调用来说就不存在；上下文里写错的东西，对它来说就是事实。它不是“忘了”，而是从来没有记住过。
2. 模型不知道自己不知道。它输出的是概率上最像答案的文本，而不是“我确定”或“我不确定”的判断。于是它会在完全不懂的领域里给出和在熟悉领域里同样自信的回答，也会在失败之后给出一个听起来很合理的失败原因。
3. 环境不配合。工具的描述和它的真实行为对不上，依赖没装，网络不通，路径不存在，权限不够，输出被截断，进程超时被杀。这些都和模型聪不聪明无关，但它们决定任务能不能做成。
4. 没有人在回路里。自动执行意味着错误也会被自动执行。每一步单独看都合理的一串决策，可以走出一条完全错误的路线：改了不该改的文件，装了一个带后门的包，把测试改成能通过的形状。

所以与这类系统共事的基本姿势是：把任务拆到“每一步都能被检查”的粒度；让它先给计划再动手；在不可逆的操作前保留确认；把可验证的东西交给工具去验证，而不是相信它的叙述。指望它一次听懂、一次做对、自己发现所有问题，就是在给它安排一场必然的失败。

4.4 模型的接入

接入一个模型需要三类信息：

1. 接口地址（BaseUrl）：模型服务的请求地址。每个服务商的每种格式接口地址通常固定。
2. API 密钥（APIKey）：调用者的身份凭证，通常为 sk- 开头的一串字符。
3. 模型标识（model id）：用于指定实际调用的模型。同一平台通常提供多个模型，其能力与价格各不相同。

接口地址（BaseURL）

接口地址回答的是“请求发到哪里”。一个模型服务在网络上就是一个 HTTP 接口，地址由服务商固定给出，通常长这样：

模型接口目前主要有四种协议：Chat Completions API, Anthropic Messages API, Google API, Responses API

接口地址通常随协议而异。以 Deepseek 为例，官方提供Chat Completions API, Anthropic Messages API 和 Responses API. 三种接口均在官方文档中说明，分别为

https://api.deepseek.com/chat/completions
https://api.deepseek.com/anthropic
https://api.deepseek.com

首次调用 API, 使用 Anthropic API, 使用 Responses API

API 密钥（APIKey）

API 密钥回答的是“我是谁”。

API 密钥的价值等同于账户的支付权限，不应写入公开的代码仓库、截图或聊天记录。密钥一旦泄露，应立即在服务方后台吊销并重新签发。

补充几条工程上的习惯：密钥应当放在环境变量或者本地的 .env 文件里，并确保这个文件写在 .gitignore 中；不同用途签发不同的密钥，方便按用途吊销和核对费用；把密钥写进截图、聊天记录和公开仓库是最常见的泄露方式，而爬虫抓取这类仓库的速度以秒计。

模型标识（model id）

模型标识回答的是“发给谁”。

模型调用时，至少需要提供模型标识以指明本次将调用的具体模型。对于 Harness 而言，也需要提供上下文窗口和单次最大输出 token 用以对上下文进行控制。部分支持思考强度自定义的模型也可以选择输入此次回答的思考强度档位。

需要强调的是，模型标识是服务商自己起的名字，不是通用编号：同一个模型在官方、在云平台、在中转站可能叫三个不同的名字；平台也可能在同一个名字下悄悄换掉权重。名字里带日期（-0813 之类）的一般是固定快照，不带日期的一般跟着更新走。要复现一个结果，用带日期的那一个。

提供方与计费

模型的提供方可分为三类：

1. 官方直连：由模型所有者直接提供，稳定性最好，价格最高。
2. 聚合与中转：转发请求或转售套餐额度。此类服务的价格可能高于或低于官方，使用前应确认其来源与计费方式。
3. 来源不明的渠道：价格显著低于官方，存在额度来源不明、以低能力模型冒充高能力模型等风险，除非运营商可识别且可信，否则不建议在正式工作中使用。

模型按 token 计费，输入与输出分别定价，输出的单价通常高于输入。此外，上下文在每一轮循环中都会被重新提交，其中的重复部分会被重复计费。多数平台对前缀完全相同的重复请求提供缓存折扣，Harness 因此通常将系统提示词固定在上下文开头。

4.5 工具、MCP 与 SKILL

模型本身只能输出文本，它对外部世界的一切操作都要由 Harness 提供工具来实现。工具从哪来，是这个领域最近两年变化最快的事情，目前大致分三层。

工具：Harness 内置的能力

读文件、写文件、执行命令、抓网页、搜索——这些是 Harness 自己实现、直接写进系统提示词的工具。第一章讲过，工具的定义（名称、描述、参数格式）由 Harness 拼进请求，模型照着它输出工具调用。

同一个模型在不同 Harness 里的“动手能力”差别很大，原因就在这里：工具集不一样。一个只能读文件、不能执行命令的 Harness，即使接上最聪明的模型，也做不了需要运行代码的任务。

MCP：把工具的来源标准化

如果每个 Harness 都要为每个软件单独写一遍适配，工具生态就永远是碎的。MCP（Model Context Protocol，模型上下文协议）要解决的正是这件事：它规定一套统一的说法，让外部程序把自家能力暴露成工具，任何支持 MCP 的 Harness 都能直接使用，不必为它写专门的代码。

一个 MCP 服务（MCP Server）在 Harness 眼里就是几个多出来的工具。传输方式主要有两种：

• stdio：Harness 把 MCP 服务当作子进程启动，通过标准输入输出通信，适合本地工具。
• Streamable HTTP：连到一个 HTTP 地址，通常带认证头，适合远程服务和多人共用的服务。

配置一般是 JSON，各家 Harness 的字段大同小异：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    },
    "remote-service": {
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

SKILL：按需加载的技能

工具是“能做什么”，Skill（技能）是“怎么做”。一个 Skill 就是一个文件夹，里面有一个带元信息的 SKILL.md：

---
name: markitdown-skill
description: 把 PDF、DOCX、网页等转成 Markdown。当用户要求读取或转换文档时使用。
---

（正文：具体怎么调用、有哪些坑、示例命令……）

关键在渐进披露：Harness 启动时只把技能的名字和描述放进上下文（几十个字），模型判断这次任务用得上了，才去读那个文件夹里的正文和附件。比起把所有知识都塞进系统提示词，这种做法对上下文友好得多。

安装方式随 Harness 不同

同一个 MCP 服务或 Skill，在不同工具里的安装方式并不一样，这是这个领域目前最烦人的地方：

MCP 服务本身的分发方式也有几种常见格式：Node 写的用 npx -y <包名> 直接跑，Python 写的用 uvx <包名> 或 pipx，Go/Rust 写的直接下载可执行文件，也有打包成 Docker 镜像的。看到安装说明以 npx、uvx 开头，基本就是这个意思。

4.6 安全

Agent 的可执行范围等同于它获得的权限。获得 shell 权限的 Agent 可以删除文件系统里的文件；获得浏览器控制权的 Agent 可以使用你已经登录的账号执行操作；持有 APIKey 的 Agent 可以产生费用。Harness 通常会在系统提示词里写入限制性条款，但系统提示词属于文本约束，不是权限机制：模型读了这句话会去遵守，但没有任何东西强制它遵守。

沙箱

真正起作用的是沙箱：由操作系统限制一个进程能读写哪些路径、能连哪些网络。Linux 上常见的是 bubblewrap、Landlock、seccomp，macOS 上是 Seatbelt，Windows 上是受限令牌与作业对象。Harness 把命令放进沙箱里执行，于是“模型只能碰这个文件夹”从一句请求变成了内核层面的拒绝。

但沙箱是减害，不是消除。只要沙箱里的进程还能联网——而在很多配置里它必须能联网，否则装不了依赖、拉不到代码——它就能访问本机端口、内网服务，以及 Harness 自己的控制接口。

沙箱逃逸

2026 年 9 月的 CVE-2026-82533 是这件事的教科书案例：DSH 用于判断“这个请求是不是本机用户发的”的函数只检查了请求里的 Host 头，没有校验连接的实际来源地址；Linux 下的沙箱又与主机共享网络命名空间；于是沙箱里的 Agent 只要执行一条 curl 打到自己 Harness 的本地接口，就能把审批要求改成“永不询问”。更糟的是，Harness 没能区分“这是 Agent 自己发起的”和“这是人发起的”，把这次策略变更记成了用户操作（source: {kind: 'user'}）。同期还有一个 CVE-2026-101078，位于另一个沙箱后端（Landlock）中，属于本地提权，影响范围同样覆盖开发期的版本。

这正是本节开头那句话的注脚：系统提示词属于文本约束，不是权限机制。而把控制面暴露在本地回环上、只靠一段文本判断“是不是用户”，等于没有认证——本地地址不是信任边界，回环接口也是接口。

另外三件常被忽略的事

• 提示词注入。工作区里的文件、抓回来的网页、工具返回的内容，都可能夹带指令。模型对“谁在说话”的判断来自 Harness 给的上下文标签，而标签是 Harness 打的：一个网页正文里写着“忽略之前的指令”，在模型眼里确实就是一条指令。所以喂给模型的外部内容和模型能调用的工具，最好不要同时给得太满。
• 凭据。Agent 会非常自然地读取工作区里的一切，包括 .env、配置文件、~/.ssh。给它一把能读生产数据库的密钥，就等于给它这个权限。
• 依赖与插件。MCP 服务和 Skill 是第三方代码，运行起来和你自己敲下那条命令没有区别。

能做的事

最小权限（只给它真正需要的目录和网络）、不可逆操作保留确认、不把生产密钥放进工作区、把高风险任务放进容器或者虚拟机、装第三方插件之前看一眼代码；以及定期回看 Harness 的权限日志——谁在什么时候批准了什么，这笔账要能对得上。

参考：Forkast 对 CVE-2026-82533 的分析

五、具体工具的评价

前四章讲的是这套东西怎么运作。这一章讲的是我用过之后觉得怎么样。

通识课最容易变成没用的通识课的方式，就是只讲原理、不给判断：原理学完，面对一排名字差不多的模型和产品，人还是不知道该用哪一个，最后只能看谁广告多。所以下面写的是主观评价。会有偏见，会有遗漏，也会有以后被证明是错的判断。我把理由一并写出来——你可以不同意结论，至少知道我是凭什么说的。

5.1 模型编年史

把 2018 年至今的模型按发布时间排开，大致能分成三代：基座模型（2018–2021，比的是语言理解本身）、对话模型（2022–2024，比的是能不能听懂人话、按人的偏好回答）、推理模型（2024 年底至今，比的是在回答之前肯花多少算力去想）。每一次换代，衡量“好”的标准都要被换掉一次。

这一节按厂商梳理，只讲脉络和方向，不追求把每个版本号列全。想查完整的时间线，推荐这个整理得相当认真的外部资料：LLM Timeline，按厂商分行标出每一次发布，还用自己的标准标出了“当时被当作转折点”的模型。下面这张脉络表从它那里受益不少。

OpenAI：定义赛道的那一家

• 2018–2020：GPT-1、GPT-2、GPT-3。把“堆参数 + 预训练 + 微调”这条路走通，并在 2020 年发布 API，第一次把大模型变成可以按量购买的商品。
• 2022-11-30：ChatGPT。五天一百万用户，两个月一亿。
• 2023-03-14：GPT-4。多模态，考试成绩进入人类前列。
• 2024-09：o1 预览版。第一次把“回答之前先想一段”做成产品，推理模型时代开始。
• 2025-08 之后：GPT-5 系列一路小版本迭代（5.1、5.2、5.3-Codex、5.4、5.5、5.6 Sol），2026-09 的 GPT-6 Astra 把这一代推到顶点。
• 方向可以说是全都要：模型、产品、平台、算力。优势是几乎每一代都踩在最前面，代价是偶尔踩空，GPT-5 发布时的口碑就是例子。

Anthropic：把编程和安全当主战场

• 2023–2024：Claude 1、2、3。Claude 3 Opus 是第一个真正对 GPT-4 构成威胁的对手，Claude 3.5 Sonnet 则在开发者圈子里确立了“写代码好用”的位置。
• 2025：Claude Code 发布，把“模型直接操作终端”做成了正经产品（见第三章）。同年 Sonnet 4.5、Opus 4.5 把长任务能力往前推。
• 2026：Opus 4.6 到 Opus 5 密集迭代；4 月的 Claude Mythos 是一个极端案例——它在漏洞挖掘上强到 Anthropic 决定不公开发布，转而做防御项目，消息出来当天网络安全股应声下跌。
• 方向很清楚：企业级与代码，再加上把“安全”当成差异化能力来做。

Google：从被嘲笑到重新领先

• 2017 年的 Transformer 论文出自这里，但它在产品上慢了半拍，Bard 首发翻车，一度被当成 AI 时代的落后者。
• 2024-02 的 Gemini 1.5 第一次把一百万 token 的上下文做到可用；2025-03 的 Gemini 2.5 Pro 补上了推理；2025-11-18 的 Gemini 3 Pro 被广泛认为是 Google 重新拿回前沿的一代。
• 2026 年走的是密集小版本路线（3.1、3.5、3.6、3.7、3.8），同时把模型直接铺进搜索、安卓和 Workspace。
• 方向：多模态、长上下文、自研芯片、分发渠道。它手里有别人没有的东西——全世界最大的分发入口。

DeepSeek：把效率变成武器

• 2024-12 的 V3 用约六百万美元的训练成本做出对标一流的效果；2025-01 的 R1 把推理能力开源，“DeepSeek 冲击”直接震到了美股。
• 2025 年走的是 V3.1、V3.2 这样的稳定迭代；2026-04 发布 V4，随后是 V4-Flash 系列。到了 2026 年，便宜和高效已经是全行业标配，V4 一代反而显得没什么戏剧性——这件事本身说明了 R1 当年改变了什么。
• 方向：极致的成本控制、开源权重、智能体能力。本文讨论的这套 Harness 体系里，有一套就出自它家。

其他几家

一句话概括这一节：前沿能力在收敛，路线在分叉。头部的差距从“能不能做到”变成了“在什么价格、什么延迟、什么条件下做到”，而各家选的路线——开源还是闭源、通用还是垂直、卖模型还是卖产品——比模型分数更能决定它明年还在不在。

5.2 模型指标与历史的主客观评价

客观指标能说明什么

模型排行榜大致分三类，各有各的毛病：

最后一条值得多说一句：智能体类评测的分数不是模型的分数，是“模型 + Harness”的分数。评测方要么固定一个统一的 Harness 来比较模型，要么连 Harness 一起比较，看榜时必须先搞清楚它固定了哪一半。厂商自家发布的数据通常是自家 Harness 下的最好成绩，这是营销，不是欺骗。

主观：我用起来是什么感觉

抛开榜单，日常使用里真正影响判断的是这几件事：

• 它会不会主动承认不确定。会的话你多花几秒核实，不会的话你要在事后花几小时收拾。
• 它能不能在长任务里不跑偏。做一次问答很容易，连续做两百步工具调用还记得最初的目标，是另一回事。
• 它写的中文像不像人话。这一点各家差距极大，而所有评测榜都测不出来。
• 它贵不贵、快不快、稳不稳。同一个模型在工作日下午和凌晨两点的速度能差一倍。

历史上的分水岭

回头看这些年，真正改变了行业走向的发布并不多，而且判断标准不是它有多强，而是当时的人是否把它当成了转折点：

• 2022-11-30 ChatGPT：AI 进入大众视野。
• 2023-03-14 GPT-4：证明能力还能继续往上走，并且值得付钱。
• 2024-02 Gemini 1.5：百万上下文从参数表上的数字变成能用的东西。
• 2024-06 Claude 3.5 Sonnet：开发者开始认真考虑“用它写代码”。
• 2024-09 o1：推理模型范式确立，算力从训练挪到推理。
• 2024-12 DeepSeek V3 与 2025-01 R1：证明前沿能力不必由最有钱的几家垄断。
• 2025-11 Gemini 3 Pro：Google 回到前沿。
• 2026-04 Claude Mythos：能力第一次强到“决定不发布”。
• 2026-07 Kimi K3：前沿开源模型第一次真的能被跑起来、被用起来。

反过来，也有几代模型当时声势浩大，事后看只是常规迭代。这很正常：模型是快速折旧的资产。今年最贵的旗舰，明年就是便宜档；某个模型在榜单上的领先，保质期通常以月计。

所以通识层面最有用的一条建议是：别追排行榜，追你自己的任务。拿你真实要做的那件事去试，试三个模型，看哪个一遍就过。这比任何榜单都准。

5.3 Harness 编年史及其评价

Harness 这条线的历史比模型短，但变化更快。

• 2022–2023：只有聊天框。 ChatGPT 的网页界面本身就是最早的流行 Harness：拼接历史、按 token 计费、渲染 Markdown，一个工具都不给。这个形态至今仍是绝大多数人使用 AI 的方式。
• 2023–2024：编辑器插件。 补全式的 Copilot、对话式的 Cursor，把模型塞进编辑器。此时模型仍然不能自己动手，改哪里、改成什么都要人指定。
• 2024-11：MCP 提出。 Anthropic 把“外部程序如何向模型提供工具”标准化，工具生态从此可以跨产品复用。
• 2025-02：Claude Code。 在终端里运行的智能体，能自己读代码、改文件、跑命令、看报错再改。这是“大模型直接使用命令行”成为主流产品范式的起点。随后 Codex CLI（2025-04）、Gemini CLI（2025-06）相继跟上，三大实验室在这一年达成了共识。
• 2025 下半年至 2026：形态分化。 TUI、IDE、GUI 三种形态各自成熟；网页端也开始给模型配工具（搜索、代码执行、文件），聊天框和智能体的界限被抹掉。
• 2026-02：Harness Engineering 被命名。 “每当 AI 犯错，就工程化一个方案让它不再犯同样的错”——这句话把工程重点从提示词技巧转移到了系统设计上。
• 2026 至今：插件、技能、多智能体。 Harness 之间比的不再是“能不能调用工具”，而是上下文管理策略、权限模型、插件生态、成本可视化，以及能不能把子任务分给别的智能体。

常见的 Harness

这张表只列较有代表性的产品，同类产品还在不断增加，写进来不代表推荐。

评价

• **形态不重要，工具集重要。**一个 Harness 好不好，先看它给了模型什么工具、怎么管上下文、出错之后怎么办，界面好不好看排在这三样后面。
• **同一模型在不同 Harness 上表现不同。**工具定义、上下文策略、系统提示词都不一样，而模型训练时主要适配的是自家那套。所以“这个模型不行”和“这个模型在这个工具里不行”是两句话。
• **权限模型是分水岭。**有的 Harness 默认随便跑命令，有的默认只读、要写文件就问一句。前者效率高，后者敢用在真项目上——这取决于你打算让它碰什么。
• **插件生态决定上限。**内置工具解决通用问题，剩下的靠 MCP 和 Skill 补。一个没有插件机制的 Harness，能力上限就是它出厂那天。

我个人的选择标准很简单：能读到我的文件、能执行命令、能在动手之前问我一句。三样里最后一样最少见，也最重要。

六、其他议题

这一章放三件前面几章装不下、但每个用 AI 的人都躲不开的事：检测、幻觉，以及模型到底在“想”什么。它们的共同点是争议大、说法多，而且都直接影响你怎么用这东西。

6.1 AIGC 检测

它是怎么工作的

AIGC 检测（AI 生成内容检测）想让机器判断一段文字是不是机器写的。目前主流做法有四类。

1. 统计特征。看困惑度（这段文字对语言模型来说有多“意外”）与突发性（句长和结构的起伏）。人类写作像心电图，长短错落；模型输出偏平滑、偏工整。这是最早的一代方法，也是最容易误伤的一代：一个文风严谨的学者、一个用词规整的非母语写作者，写出来的东西天然平滑，于是天然“像 AI”。
2. 分类模型。用海量人类文本和 AI 文本训练一个判定器，还专门拿“容易被误判的样本”做对抗训练来压低误报。这一类是目前的主力，部分产品宣称其英文误判率已降到万分之几——不过这类数字基本来自厂商自测，第三方独立评估还很少。
3. 水印与元数据。在采样环节嵌入统计信号（水印），或者在文件里写入来源信息（内容凭证一类）。这是唯一理论上可靠的一类，前提是生成方配合、内容没有被重新编辑；一旦被改写、被截图、被转成别的格式，水印基本就没了。
4. 检测模块挂载。国内高校普遍使用知网、维普、万方等系统自带的 AIGC 检测模块，报告形式通常是把疑似段落标红，但不解释判定依据。

为什么它不可靠

• 检测器给出的是概率，不是事实。同一段文字单独检测与放进整篇文章里检测，分数可能不一样；改几个词，分数也可能大幅跳动。《连线》杂志报道过，作家米娅·巴拉德的小说被检测工具判为 78% 由 AI 生成，出版方随后取消了该书在美国的出版计划，而她否认使用过 AI。“AI 率 96%”也不是“96% 的内容由 AI 写成”，而是“判定器认为这段文本的 AI 特征很强”。
• 基准是自己报的。厂商用自己的测试集报出极低的误判率，而生成模型和检测模型在同时迭代，今天准的模型下个月就可能不准。
• 中文更难。汉语的语义和表达方式都比英语更松散，判定器在中文上的准确率和解释能力都要更差一截——这也是误判集中的地方。

绕过方法（原理）

既然检测依赖文本的统计特征，那么改变统计特征就能影响判定。公开讨论里常见的手段有这么几类：

• 提示词层面：要求改变句长节奏、减少连接词、加入口语和个人经历、避免排比与三段式；或者指定模仿某位具体作者的风格，后一种在独立评估中确实能绕过部分检测器。
• 模型混合层面：A 模型出初稿，B 模型改写，人再润色一遍；或者中文译成英文再译回来，把原来的用词分布洗一遍。经过这类处理的文本，漏检率明显上升。
• 人工介入层面：让模型只出大纲，正文自己写；或者把 AI 写的内容按自己的理解重写。介入程度越高越难被检出——因为它确实越来越像人写的。
• 专门的“降 AI 率”工具：本质是上面几种的组合，被包装成服务出售。

这些方法都不保证有效，也不保证稳定：检测器更新一次，昨天的技巧可能就失效。还有一个广为人知的反常现象——有毕业生查出自己论文的 AI 率是 62%，把文章交给大模型改“像人写的”之后再查，涨到了 94%。改写本身又引入了更多模型味。

我的看法

以下完全主观。

**第一，我不认为“AI 率”是一个有意义的指标。**它测的是文本的统计外观，而不是写作过程。一个人用 AI 帮忙起提纲、查资料、改病句，和一个人把题目丢给 AI 再复制粘贴，产出的文本在检测器眼里可能都是“AI 特征很强”，得到相近的分数；反过来，一个完全自己写的人，只要写得够规整，也照样可能被打上高分。把这种数字当作学术判决，是把概率当成了结论。检测报告只标红不解释，学生拿到手根本不知道该往哪个方向改，只能再去找 AI 改，于是越改越像 AI。

**第二，这套流程里的钱花得很荒诞。**学校花钱买检测系统，学生花钱买降 AI 率的服务，双方围着一个彼此都知道不准的数字博弈。真正该做的是透明的使用标注制度：哪些部分用了 AI、用在哪一步、自己做了什么，写清楚就行；判定权留在老师和答辩委员会手里，工具只提供线索。

**第三，也是我最想说的：用 AI 代替大脑的大学生，是在给自己挖坑。**大学四年里，写论文真正的收益不在那篇论文，而在写的过程：读文献、找材料、梳理逻辑、被导师打回来重改。这个过程被外包出去之后，你拿到的是一个你无法为之负责的结果——答辩时老师追问一句“这里为什么这么写”，你答不上来，因为你没写过。更现实的问题是，简历上写着“熟练掌握 AI 工具”，实际掌握的却是“把问题粘进对话框然后复制”，这种能力的替代成本是零。

我不反对用 AI，我反对的是用 AI 把该自己走的路走过去。工具能帮你省掉重复劳动，省下来的时间应该用在更难的地方。

6.2 幻觉与抗幻觉

幻觉（Hallucination）指模型生成看上去合理、实际错误的内容。它不是一个能修好的 bug，而是这套机制的必然产物。

为什么会幻觉

• 它的任务是猜下一个词。训练时被奖励的是“预测得准”，不是“说得对”。一个编造得流畅的答案和一个正确的答案，在生成过程里没有本质区别。
• 它没有“不知道”这个状态。模型参数里没有一张事实清单，只有统计规律。面对完全没学过的问题，它不会返回空值，而是沿着最像答案的方向编一个出来。编造参考文献、编造 API 名称、编造法律条文，都是同一个原因：这些东西的格式高度规律，而内容无法被参数验证。
• 后训练让它更爱编。人类偏好打分倾向于“有帮助的回答”，而“我不知道”在打分里往往得低分，于是模型学会了用自信的语气填补空白。
• 上下文里的错误会被当成事实。你贴进去的资料、工具返回的内容、上一轮它自己编的一句话，都会平等地成为它续写的依据，它不会因为那是自己说的就降低信任。

抗幻觉

能做的不是消除，而是把不可验证的环节尽量换成可验证的环节：

• 凡是能用工具验证的，就不要用记忆回答。要今天的汇率就搜索，要算数就写代码，要读文件就去读文件，要确认一个函数是否存在就去看文档。工具返回的是事实，参数里的是印象——这是工具调用最大的价值，比“自动干活”重要得多。
• 要求它区分“我记得”和“我查到了”。明确让它标出哪些结论有出处、哪些是推测，并给出来源链接。凡是不肯给出处的具体数字和引用，默认当作幻觉处理。
• 把问题变成可检查的形式。不要问“这个配置对不对”，让它输出改后的配置和验证命令；不要问“这段代码有没有 bug”，让它把测试跑起来。可执行的东西比叙述可靠。
• 允许它说不知道。在系统提示词或者提问里明确“不确定就说不知道，不要编”，确实有一点效果。注意是“一点”。
• 交叉验证。同一个关键问题问两个不同厂商的模型，答案不一致的地方就是你需要自己动手的地方。
• 在自己不熟悉的领域里额外警惕。幻觉在你熟悉的领域最容易发现，在你陌生的领域最难发现——而后者恰恰是你最想依赖它的时候。**不要把你无法判断真伪的问题交给模型。**它可以帮你查，不能替你决定。

6.3 模型的“思考”

它是怎么出现的

2024 年下半年之后，模型多了一种用法：在给出答案之前，先生成一大段中间文本，把它当成草稿，边写边算，最后再给结论。这段中间文本呈现出来，就是我们看到的“思考过程”。这类模型被称为推理模型，其背后的训练思路叫作测试时计算（test-time compute）：把算力从训练阶段挪一部分到回答阶段，让模型在难题上多想一会儿。

它的实现方式仍然是逐 token 生成：模型并不真的停下来运算，而是把中间步骤写进上下文，再读回来。区别在于，这样的文本是专门为“想清楚”训练过的——通过强化学习，答对时奖励这条推理路径，答错时惩罚它。于是模型学会了分解问题、检查上一步、发现不对就回头。

由此带来几个直接后果：

• 思考是花钱的。思考 token 按输出计费，而输出单价通常比输入贵好几倍。一道简单的题让它“想”两千字，账单和延迟都会明显变差。
• 思考可以要求，但很难控制。多数产品提供“思考强度”档位，越高越慢越贵，而且不保证更准——难题上收益明显，简单题上纯属浪费。
• 思考过程不等于真实计算过程。它是又一次生成，是模型“愿意让你看到的那一版草稿”，可能省略、可能美化，也可能在答案已经定了之后补一段解释。不要把它当成程序运行日志来读。

隐藏思维链

从 o1 开始，OpenAI 就只返回思考的摘要，不返回原始思维链，理由是竞争（不想把训练数据白送给对手）和安全（不希望别人拿它做蒸馏）。此后各家做法不一：Anthropic 与 Google 一度更愿意给出思考内容或者思考摘要，OpenAI 则守得最紧。2026 年 9 月 GPT-6 Astra 发布时，“它是不是在隐藏思考”又成了一次公开争论。

更值得注意的是另一条技术路线：把额外的计算放进模型的隐藏层里反复迭代（所谓 looped transformer、递归深度），而不是把中间过程输出成 token。如果这条路走通了，那就不存在可以展示的思维链——不是厂商不想给，而是根本没有一段文本可以给。

对使用者来说，这件事有三个实际影响：

1. 你不能再靠读思考过程判断它对不对。原本“读一遍它的推理，看有没有明显跳步”是一种低成本的检查手段，以后可能只剩结论。
2. 你在为看不见的 token 付费。账单上有一笔推理 token 的费用，内容你却读不到。
3. 可解释性退回黑盒。一个能读草稿的模型和一个只能看答案的模型，信任成本完全不同。

我的看法仍然是主观的：即便思维链只是“又生成了一段话”，它对使用者依然有价值——它给了你一个检查的抓手，让你能发现它从哪一步开始胡说。把它藏起来是厂商的商业选择，不是技术的必然。用你的钱买来的算力，消耗在哪里，你至少应该有权知道。

结语

本文原稿由AI生成，由人类大幅修改(修改部分大于50%)。