AI Agent 到底是什么？从“会聊天”到“能做事”

一、为什么我们需要重新理解 AI Agent？

我们已经习惯了向大模型提问，然后等待它生成答案。但如果任务不只是“回答一个问题”，而是要求系统完成一连串真实操作，情况就会发生变化。

例如：

• 查找多个网站上的资料并进行比较；
• 读取一批文件，提取信息并生成报告；
• 根据需求修改代码、运行测试并修复错误；
• 查询订单状态，填写表单，再给用户发送通知。

这类任务的共同点是：它们需要持续观察环境、做出多次决策，并真正执行动作。

因此，Agent 不能只被理解为“一个更会聊天的模型”。更准确地说，它是一个让模型能够感知环境、调用工具、持续行动并完成目标的系统。

---

二、Agent 的核心公式

理解 Agent，最重要的是记住这一条公式：

$$\text{Agent}=\text{LLM}+\text{上下文}+\text{工具}$$

也可以把它理解成：

• LLM 是大脑：负责理解、思考和决策；
• 上下文是眼睛：决定系统能够看到哪些信息；
• 工具是手脚：让系统能够对外部世界采取行动。

这个公式看起来简单，但它揭示了一个很重要的事实：Agent 的能力不是由模型单独决定的，而是由模型、信息和行动能力共同决定的。

如果模型很强，但看不到关键环境信息，它仍然无法做出正确判断；如果模型看到了信息，却没有相应工具，它也只能停留在建议层面。

---

三、LLM：Agent 的大脑

LLM 在 Agent 中承担的是决策角色。它通常需要完成以下工作：

1. 理解用户真正想完成的目标；
2. 把复杂任务拆分成多个步骤；
3. 判断当前应该先做什么；
4. 选择合适的工具并生成参数；
5. 根据工具返回的结果调整后续计划；
6. 判断任务是否已经完成。

这里的关键不是“模型能不能写出一段文字”，而是它能不能在不断变化的任务状态中持续做出合理选择。

例如，用户说“帮我汇总本月的销售数据”，Agent 可能需要先读取文件，再统一货币单位，然后运行计算，最后生成报告。每一步都依赖前一步的结果，模型需要不断判断下一步，而不是一次性输出一段看似合理的答案。

---

四、上下文：Agent 的眼睛

上下文不是简单的聊天记录，而是模型在当前时刻能够看到的全部信息。它通常包括：

• 系统提示词：定义身份、规则和权限；
• 工具定义：说明有哪些工具、工具能做什么以及参数格式；
• 用户消息：描述任务目标和补充要求；
• 模型历史回复：包含之前的判断和工具调用；
• 工具执行结果：告诉模型行动产生了什么结果；
• 环境状态：例如当前文件、登录状态、时间和任务进度。

可以把上下文看成 Agent 的工作记忆。它决定了 Agent 是否知道：

• 当前任务是什么；
• 已经完成了哪些步骤；
• 哪些尝试失败过；
• 现在有哪些工具可用；
• 外部环境刚刚发生了什么变化。

上下文缺失会发生什么？

上下文问题往往不会直接表现为程序报错，反而可能产生一个“看起来很正常”的错误答案：

• 没有工具定义，模型可能编造一个并不存在的工具；
• 没有工具执行结果，模型可能以为动作已经成功；
• 没有历史记录，模型可能反复执行同一个步骤；
• 没有环境状态，模型可能对已经变化的世界做出过时判断。

所以，Agent 的失败不一定说明模型不会思考，也可能说明它没有获得正确的信息。

---

五、工具：Agent 的手脚

工具是 Agent 与外部世界之间的连接器。常见工具可以分成几类：

类型	作用	示例
感知工具	获取信息	搜索引擎、文件系统、数据库
执行工具	改变环境	代码执行、文件修改、API 调用
协作工具	请求协助	子 Agent、人类确认、任务委派
事件工具	响应外部事件	邮件、定时任务、Webhook
沟通工具	与用户交流	消息、语音、邮件

一次完整的工具调用通常经历四个阶段：

工具设计不能只追求“功能强大”，还要考虑安全性和可控性。通用工具适合探索，例如代码解释器；高风险动作则更适合使用权限明确、规则严格的专用工具，例如支付、删除数据和发送正式通知。

---

六、观察空间与动作空间：模型和世界之间的接口

在更抽象的层面，可以把 Agent 与环境的交互理解成两个接口。

观察空间：Agent 能看到什么

观察空间包括模型可以获得的任务信息，例如：

• 用户输入；
• 文件内容；
• 网页信息；
• 数据库结果；
• 工具执行反馈；
• 当前任务状态。

动作空间：Agent 能做什么

动作空间包括模型能够发出的操作，例如：

• 调用搜索工具；
• 运行代码；
• 修改文件；
• 发起 API 请求；
• 给用户发送消息；
• 请求另一个 Agent 协助。

这个视角能帮助我们重新判断许多问题：有些任务失败，并不是模型“智力不够”，而是观察空间缺少关键数据，或者动作空间没有提供完成任务所需的能力。

因此，提升 Agent 能力不只有“换一个更强模型”这一条路，还可以：

1. 扩展观察空间，让模型获得必要信息；
2. 扩展动作空间，让模型拥有必要工具；
3. 改善接口设计，让信息和动作更容易被正确使用。

---

七、ReAct：Agent 如何一步步完成任务

Agent 最经典的运行方式之一是 ReAct，它来自 Reasoning 和 Acting 两个词。

它可以概括为：

思考 → 行动 → 观察 → 再思考

Agent 不会只生成一次答案，而是通过多轮循环逐渐完成任务：

一个简单例子：汇总多币种数据

假设用户要求“汇总几个账户的余额，并换算成人民币”：

1. Agent 先读取各个账户的数据；
2. 发现币种不同，于是调用汇率工具；
3. 得到汇率后，调用代码工具完成计算；
4. 检查计算结果；
5. 生成最终汇总报告。

在这个过程中，Agent 的每一步都依赖工具结果。它不是凭空规划完整答案，而是在行动和反馈之间不断修正计划。

---

八、轨迹：Agent 的执行记录

Agent 在任务执行过程中产生的全部消息和结果，可以看作一条轨迹（Trajectory）。

轨迹通常包括：

• 用户请求；
• 模型的回复和工具调用；
• 工具执行结果；
• 后续模型决策。

轨迹的价值在于，它让 Agent 的行为变得可观察：

• 可解释：能看到 Agent 为什么采取某个动作；
• 可调试：能定位失败发生在模型、工具还是上下文；
• 可优化：能发现重复、过早结束等行为模式；
• 可学习：可以将优秀轨迹沉淀为知识或训练数据。

因此，Agent 不只是“最后输出了什么”，执行过程本身也很重要。

---

九、Harness：把模型变成可靠的执行系统

如果说 LLM 是大脑，那么 Harness 就像是围绕大脑建立的运行框架。它负责把模型的输出接入真实环境，并确保整个过程可控。

Harness 通常负责：

• 构造和管理上下文；
• 提供和管理工具接口；
• 维护 ReAct 循环；
• 保存任务状态；
• 检查参数和权限；
• 验证工具执行结果；
• 在出现错误时进行重试、纠正或请求人工确认。

这说明，一个可靠的 Agent 不能只依赖模型“自己发挥”。模型负责提出决策，Harness 负责把决策变成受约束、可验证的行动。

模型越强，通常意味着它能做出更多自主决策；自主空间越大，错误的影响范围也可能越大。因此，模型能力提升并不会让工程框架失去价值，反而会提高对 Harness 的要求。

---

十、把整节内容串起来

现在可以把一个 Agent 的工作过程完整串起来：

1. 用户提出任务；
2. Harness 构造上下文；
3. LLM 根据上下文理解任务；
4. LLM 决定是否调用工具；
5. Harness 校验工具调用；
6. 工具与外部环境交互；
7. 执行结果返回并加入上下文；
8. LLM 根据新结果继续决策；
9. 任务完成后输出最终结果。

这就是一个 Agent 系统的基本闭环。

---

十一、最容易记住的三个结论

结论一：Agent 是系统，不是单独的模型

模型、上下文、工具和 Harness 共同决定 Agent 的实际能力。

结论二：上下文决定 Agent 能看见什么

如果关键信息没有进入上下文，模型就无法基于它做出判断。

结论三：Agent 的本质是循环执行

真正的 Agent 不是一次性生成答案，而是通过“思考—行动—观察”的循环逐步完成任务。

---

十二、用一句话总结

AI Agent 是一个以 LLM 为决策核心、以上下文为感知基础、以工具为行动接口，并通过 Harness 持续观察和执行任务的智能系统。

理解了这句话，后续学习上下文工程、知识库、工具设计、Coding Agent 和多 Agent 协作时，就有了统一的坐标系。

---

结语：从“模型会什么”转向“系统能完成什么”

学习 Agent 时，一个值得建立的思维转变是：不要只问“这个模型有多聪明”，还要问：

• 它能看到哪些信息？
• 它能调用哪些工具？
• 它能否记住任务状态？
• 它的行动是否经过验证？
• 它能否在失败后继续推进？

当我们从这些问题出发，Agent 就不再是一个模糊的产品名词，而变成了一个可以拆解、设计、调试和持续改进的工程系统。