从回答的模型到行动的模型

从回应模型到行动模型

在此之前，每一章都把大语言模型描述为一个被动的角色：接收提示词，生成回复，结束。模型对外部世界毫无作为——它只是产生文本。

但有一件事改变了这一切。大语言模型现在可以调用工具：搜索网页、执行代码、读写文件、发送邮件。有了这种能力，一种全新的架构成为可能。

没有工具的模型的局限

向一个没有联网能力的大语言模型提问："苹果公司现在的股价是多少？"

它会编出一个听起来合理的数字，或者说它不知道。无论哪种情况，都无法给出正确答案——因为这个信息不在它的参数里。

给它一个工具——一个实时股票 API——答案就变得唾手可得。模型不需要在训练时学习这些信息，而是在需要的时候直接获取它。

ReAct 循环

智能体的参考架构叫做 ReAct（推理 + 行动，Reasoning + Acting）。它以三个阶段循环运作：

思考（Think） — 模型分析当前情况，写出推理链："要回答这个问题，我需要 X。我将用这些参数调用工具 Y。"

行动（Act） — 模型生成一个结构化的工具调用：工具名称和对应参数。系统执行调用并取回结果。

观察（Observe） — 工具返回结果被注入上下文。模型看到发生了什么，然后决定下一步行动。

如此循环，直到模型判断自己有足够的信息来给出最终回复。

逐步体验

以下是三个任务：一个简单任务（计算）、一个需要调用 API 的任务、一个需要链式调用多个工具的任务。逐步观察模型的推理过程，以及上下文如何随着每一轮迭代不断积累。

观察这个循环：模型思考、选择工具、读取结果、重新开始。每一轮都是一次新的 token 预测——「智能体」并非来自新的架构，而是来自一个学会调用函数的 LLM。

工具是如何定义的

工具不是模型"神奇地理解"的代码片段，而是一个结构化定义——名称、描述、参数——出现在模型的上下文中：

{
  "name": "web_search",
  "description": "在网络上搜索最新信息。",
  "parameters": {
    "query": "string — 搜索查询词"
  }
}

模型在训练时学会了以这种格式生成工具调用。当它"选择使用某个工具"时，实际上只是生成了一段形如 API 调用的文本。

系统检测到这段文本，执行真正的调用，然后将结果返回到上下文中。

不断增长的上下文

循环的每次迭代都会向上下文中添加新的 Token：推理链、工具调用、工具返回结果。一个需要五轮迭代的复杂任务，很容易就会消耗数千个 Token。

这就是为什么智能体往往比简单的问答交换更慢、更昂贵。这也是为什么上下文管理——知道该保留什么、该压缩什么、该丢弃什么——仍是智能体系统设计中尚未解决的核心问题之一。

工具调用与微调的取舍

一个自然的问题：为什么让模型学会使用工具，而不是直接把信息训练进参数？

有几个原因：

数据会变化。 股票价格、天气、数据库状态——这些信息持续变化，任何训练都无法捕捉到最新状态。

精确性。 计算、SQL 查询、单位换算——工具是确定性的、精确的，而大语言模型不是。

模块化。 给模型新增一个工具只需几行代码；重新训练模型以融入一项新技能则需要数周时间和数百万美元。

规划与任务分解

最强大的智能体不满足于线性循环。它们会将复杂任务分解为子任务，并行执行其中一些，再汇总结果。

例如，"撰写一份关于三家竞争对手的对比报告"可以分解为：分别查找三家竞争对手的信息（三个并行调用），再综合各结果。

这仍然是一个活跃的研究领域。当前的大语言模型在短任务上的规划能力相当不错，但在长而复杂的任务上很容易偏离轨道。

智能体的风险

有了行动能力，随之而来的是造成损害的可能。

不可逆操作。 一个拥有邮箱访问权限的智能体可以发送邮件，发出去就无法撤回。良好的智能体架构会区分读操作（无害）和写操作（需要确认）。

无限循环。 没有保护机制的智能体可能陷入死循环：搜索信息、找不到、换个表达、再搜索……无休无止。

奖励劫持。 如果目标描述不准确，智能体可能找到出乎意料的捷径来最大化得分——而不是真正完成你想要的任务。

工具幻觉。 模型可能凭空编造不存在的工具调用，或使用错误的参数。

MCP：迈向工具的统一标准

最早的时候，每家厂商都定义了自己的工具调用格式：OpenAI 有 function calling，Anthropic 有自己的内部协议，每个智能体框架都在重新发明轮子。结果就是：互不兼容，每接入一个模型都要重写集成，整个生态四分五裂。

2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP）：一个开放标准，用与具体模型无关的方式来描述工具、资源和提示词。一个 MCP 服务器对外暴露一组工具（比如"读这个文件"、"查这个数据库"）。任何兼容 MCP 的客户端——Claude Desktop、Cursor、各种 VSCode 扩展、智能体框架——都能连上去。

经常被提到的一个类比：MCP 之于大语言模型，就像 USB-C 之于外设。一个通用的接口。

普及速度很快：2025 年里，OpenAI、Microsoft 以及大多数主流厂商都宣布支持 MCP。它已经事实上成了工具调用的标准协议。

代码解释器、沙盒、Computer use

有几类工具特别重要，值得专门提一下：

Code interpreter（代码解释器）。 一个 Python 沙盒（有时是 JavaScript），模型可以在里面执行任意代码。精确计算、数据处理、生成图表——所有大语言模型自己干得不好的事情，都可以丢给 Python。OpenAI、Claude、Google 都提供这个能力。

Browser / web automation（浏览器自动化）。 一种工具，让模型能够在网页上点击、滚动、填表单。Anthropic 称之为 computer use，OpenAI 推出了 Operator。目前还比较脆弱，但发展很快。

File system & shell（文件系统与终端）。 一种工具，给模型一个虚拟磁盘和一个终端的访问权限。这是 Cursor、Cline、Aider、Claude Code 这些"编码智能体"的核心。

长期记忆

智能体的上下文会增长，但仍是有界的。那么一个助手是怎么在下一次对话里"认出"你的？靠外部的长期记忆。

有几种常见做法：

• 向量记忆 —— 把每次重要的交互摘要后存成嵌入。每次新对话开始时，检索出相关的"记忆"（这其实就是 RAG 的记忆版）。
• 结构化用户档案 —— 智能体维护一份关于用户的资料（偏好、正在进行的项目、历史记录）。
• 过程性记忆 —— 智能体记录下行之有效的"配方"（"要总结一篇论文，按这些步骤来"）。

ChatGPT 在 2024 年引入了记忆功能，Claude 在 2025 年也跟进了。这是当前智能体设计中最活跃的方向之一。

多智能体：多个大语言模型协作

近年来兴起的一种趋势：不再是单一智能体，而是让多个专门化的大语言模型相互协作。

一个编排智能体接收任务，将其分解并委托给专门智能体（代码专家、网络搜索专家、结果核查专家）。各子任务的结果汇回编排智能体，由它进行综合。

这种架构与人类组织颇为相似——拥有同样的优势（并行化、专门化）和同样的问题（沟通成本、协调开销、智能体间的信息损耗）。

这意味着什么

大语言模型不再是你查询的"神谕"——它变成了一个你为之连接手臂的大脑。

这一转变还是近期才发生的。当前的智能体在定义明确的任务上令人印象深刻，在长且模糊的任务上则仍然脆弱。但发展速度很快，理解底层架构——ReAct、工具调用、不断增长的上下文——是最好的起点。

更新于 2026年5月10日