什么时候需要 Agent，什么时候不需要

前面讲的 RAG 是一条固定流水线：查资料、组装、生成，一次走完。很多问题这样就够了。

但有些任务一次查不完。还是那个 AI 客服的例子：客户报告"升级到新版之后，某个功能不能用了"。要答这个问题，得先查这个版本有没有已知问题，再查客户用的是哪套配置，可能还要查这套配置下有没有相关的变更说明——而且后一步查什么，取决于前一步查到了什么。如果第一步就在已知问题里找到了答案，后面几步根本不用做。

这种"自己拆解任务、自己决定下一步、循环到完成"的运作方式，就是 Agent（智能体）。它和固定流水线最核心的区别是：走几步、每步做什么，由模型临场决定，而不是预先写死。

反过来也要说清楚：简单任务不该用 Agent。一步就能答完的问题，直接调模型或走固定 RAG 流程更好——更快、更便宜、出了问题也更容易查。通行的建议是从最简单的固定流程做起，确有必要再加复杂度。自主性是有代价的，本章最后会讲。

ReAct：最常见的运作模式

Agent 最基础也最常用的模式叫 ReAct¹，名字取自论文标题中的 Reasoning（推理）与 Acting（行动）。在原始论文中，模型的执行轨迹由三部分交替构成：

• Thought（思考）：模型根据目前掌握的信息，判断下一步该做什么
• Action（行动）：模型请求调用一个工具——查数据库、算一道题、请求某个接口
• Observation（观察结果）：工具执行后返回的内容，由 harness 送回给模型

注意前两步是模型产出的，第三步是外部送进来的。后来的资料常把这三步写作 Reason / Act / Observe，以与 ReAct 这个名字对齐，指的是同一回事。

需要说明的是，原始论文里的 Thought 是模型以文字形式写出来的。现在的推理模型已经把这一步内化了：它们能在两次工具调用之间先"想一想"，再决定下一步，这个思考由模型原生完成，不需要开发者再用提示词模板引导它写出 Thought。² 所以今天的 ReAct，更多是一个理解 Agent 怎么运作的模型，而不是必须照搬的写法。

三步反复循环，直到模型判断任务完成。

ReAct 是默认起点，但不是唯一模式。任务复杂到单个循环跟不住时，可以让模型先把整件事拆成计划再逐条执行；同类错误反复出现时，可以加一层让它回顾失败原因的机制。业界的经验是：先用 ReAct 建立基线，测出成功率、工具调用准确率、延迟和成本，确认单个 Agent 确实解决不了问题，再往上升级——过早堆复杂度是常见且昂贵的错误。

四个配套概念

Harness（运行层）

模型本身只是一个根据输入上下文生成输出的推理器。它不会自行保存状态，不会主动循环，也不能直接执行外部操作。真正把模型组织成一个 Agent 的，是包在外面的运行层（通常称为 harness）。Harness 驱动模型反复思考、调用工具、接收结果并继续推理，使整个系统能够持续完成任务。

除了驱动这个循环，harness 还负责：维护可用工具的清单、把模型发出的工具调用请求解析出来并真正执行、决定每一轮往上下文窗口里放什么（旧内容是压缩还是丢弃）、出错时重试、高风险动作前拦下来等人批准、以及记录全过程。

用 3.4 的话说，harness 就是那个"唯一主动发起动作"的后端。Agent 并没有改变那张通信图，只是让后端把其中几步反复跑。

这个词借自软件测试（test harness 指在受控条件下运行代码的脚手架）。它之所以值得有个单独的名字，是因为harness 的质量和模型的质量同等重要：同一个模型换一套 harness，表现可能差出一大截，现实中不少企业 Agent 项目的瓶颈，出在 harness 设计上，而不是模型本身的能力。harness 里的每个组件，都编码着一个关于"模型自己做不到什么"的假设；这些假设值得反复检验，因为它们可能本来就不对，而且模型一变强，就会很快过时。³

Function Calling（工具调用）

模型不会真的执行任何东西。它能做的只是输出一段结构化的文字，意思是"我想用'搜索产品文档'这个工具，参数是'旧版本数据迁移'"，然后由 harness 去执行，再把结果转述回来。

换句话说，模型只能表达意图，连发起动作都做不到——这正是 3.4 那条规则的另一面：主动权始终在后端手里。（这个能力现在更常被称作"工具调用"，"函数调用"是早期叫法。）

MCP（Model Context Protocol，模型上下文协议）

MCP 是一个开放标准，规定了工具和数据源该用什么接口与 Agent 对接。它最早由 Anthropic 发布，2025 年 12 月起交给 Linux 基金会下的 Agentic AI Foundation 管理。⁴ 在它出现之前，每接一个工具都要写一段专门的适配代码；有了统一标准，就像从"每种电器配专属插头"变成了 USB 接口。

不过，使用 MCP 有两个不可忽视的代价。首先是高昂的上下文成本。由于 MCP 的工具说明需要一直保留在上下文中，一旦接入的服务器过多，对话都还没开始，上下文窗口就会被占去一大半（目前业界通常用“按需加载”来缓解这个问题）。其次是安全隐患。MCP 让 Agent 能够随意连接第三方工具，但这也会把工具本身的漏洞一并带进来，关于这方面的风险，我们将在第六章专门探讨。

Skill（技能）

一份打包好的工作流说明：把某类任务该怎么做——用什么措辞、按什么步骤、什么算完成——写成文档，需要时让 Agent 照着做。形式上就是一个文件夹，里面放一份说明文件，可以附带模板和参考资料。这套格式最早由 Anthropic 提出，2025 年 12 月作为开放标准发布，已被多家 Agent 产品采用。⁵

Skill中的关键设计叫渐进式披露：平时只加载技能的名字和一句话描述，只有当任务匹配上，才把完整内容读进上下文。所以装几十个技能也不会撑爆上下文窗口。

很多人容易把 Skill 和 MCP 搞混，但它们其实是互补的关系。简单来说，MCP 解决的是能调用哪些外部资源，负责把 Agent 和各种外部数据库、工具接口连通；而 Skill 解决的是拿到资源后该怎么做，专门教它一套办事的规矩。Skill 本身不建立任何连接，也不执行具体操作，它本质上就是一份写好的行动指南。正因如此，绝大多数生产级别的 Agent 都需要把两者搭配起来使用。

记忆

模型没有记忆——第一章讲回环 C 时说过，多轮对话靠的是把历史一并塞回上下文。Agent 面临同样的问题，而且更严重：一个跑几十轮的任务，中间产生的思考、工具调用和返回结果，很快就会超出上下文窗口装得下的量。

所以 Agent 的记忆分两层：

• 短期记忆：当前上下文窗口里的内容，也就是这轮任务到目前为止的全部过程。它有硬性容量上限，harness 需要不断决定保留什么、压缩什么、丢弃什么。
• 长期记忆：上下文之外的一个外部存储，把过去的经历、结论、用户偏好存下来，需要时再检索回来。它的实现方式其实就是 RAG——只不过检索的对象不是公司文档，而是 Agent 自己的历史。

记忆在 2024 年前后，大多还只是"上下文窗口"的代名词；现在的 Agent 系统设计里，它更多被当作与推理、编排、工具并列的一层来对待，而不是事后才补的细节。

Agentic RAG：把检索的决定权交给模型

代理式 RAG（Agentic RAG）是第一章提到的第三代 RAG。

它的做法是把本章这套机制应用于检索环节：检索不再是流水线上固定执行的第三步，而是成为 Agent 可以按需调用的一个工具。模型自行判断已获取的资料是否足以支撑回答，若不足，则调整角度再检索一轮，直至满足需要——这正是第一章所说的回环 A。

需要强调的是，改变的不是组件，而是指挥权。向量数据库、嵌入服务、重排服务、生成模型均未发生变化，后端与它们之间的通信方式也保持原样。唯一的区别在于，"检索几轮、如何检索"由代码中预设的固定规则，转为模型在运行中的实时判断。

这样做的代价是可预测性下降。在固定规则下，一次问答要走几步、调用几次模型、花费多少，事先都是确定的；改由模型临场判断之后，这些取决于它当时的判断，而模型的输出本身带有随机性——同一个问题，这次检索一轮就够，下次可能检索了四轮。成本、延迟乃至答案本身，都从确定值变成了一个区间。

代价与风险

上下文会滚雪球。 每一轮循环，harness 都要把之前所有的思考、工具调用和返回结果重新发给模型，输入越滚越长；3.3 讲过 prefill 的开销随输入长度呈平方级增长，因此这部分成本涨得比轮数快得多。

这正是提示缓存最适用的场景。因为 Agent 每一轮通常只在对话末尾追加新内容，前面大量的背景信息保持不变，系统就可以复用已经算好的结果。为了提高缓存命中率，应把系统指令、参考资料等固定内容统一放在最开头，把变化的内容全部放在末尾。缓存通常按固定的前缀匹配；中间哪怕只是调整了工具的顺序或插入一个时间戳，也会改变后续前缀，使这部分缓存失效。

提示缓存能大幅降低使用成本。虽然首次写入缓存时，部分服务商可能会加收 25% 到 100% 的费用，但之后命中缓存的部分，输入费用通常会降到原价的一成甚至更低⁶。不过需要注意的是，缓存只针对命中的输入部分降价，Agent 每轮生成的思考过程和工具调用依然按输出原价计费。此外，缓存本身有有效期；如果系统在中途自动压缩上下文记录，也可能改变前缀，导致后续缓存失效。

可能停不下来。 模型判断"任务已完成"的能力并不可靠，它可能在两个工具之间反复横跳，也可能陷入死循环。所以 harness 必须设硬性上限：最多跑几轮、最多花多少钱、超时如何处理。

工具失败会连锁。 某个工具返回了错误或异常数据，模型可能据此继续推理，越走越偏。生产系统需要在执行前校验输入、对瞬时故障重试，并把失败明确告诉模型，而不是静默跳过。

高风险动作要有人批准。 Agent 与问答系统最本质的区别是它会真的动手——发邮件、改数据、下订单。因此涉及不可撤销后果的动作，通行做法是设置人工审批关卡并保留完整的操作审计记录。这应当在架构设计阶段就作为一等组件考虑，而不是出事后再补。第五、六章会分别从合规和安全的角度再谈。

Agent 放大了提示注入的危害。 问答系统被注入，最坏结果是给出一个错误答案；Agent 被注入，则可能真的执行了攻击者想要的操作。第六章会详细讲这个风险。