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

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

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

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

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

ReAct：最常见的运作模式

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

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

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

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

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

四个配套概念

Harness（运行层）

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

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

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

这个词借自软件测试（test harness 指在受控条件下运行代码的脚手架）。它之所以值得有个单独的名字，是因为harness 的质量和模型的质量同等重要：同一个模型换一套 harness，任务成功率可能相差一倍以上；相当比例的企业 Agent 项目失败，根源在 harness 设计而不在模型能力。Anthropic 有一句话概括得很好——harness 里的每个组件，都编码着一个关于"模型自己做不到什么"的假设；模型在某件事上变强之后，对应的组件就该拆掉。

Function Calling（工具调用）

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

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

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

一个开放标准，规定了工具和数据源该用什么接口与 Agent 对接。在它出现之前，每接一个工具都要写一段专门的适配代码；有了统一标准，就像从"每种电器配专属插头"变成了 USB 接口。

两个代价值得知道。其一是上下文成本：MCP 的工具说明是常驻上下文的，接的服务器一多，对话还没开始就已占掉相当一部分上下文窗口（目前业界用"按需加载工具"来缓解）。其二是安全：MCP 规范本身不含认证与授权机制，2026 年上半年已出现数十份相关漏洞报告，接入第三方 MCP 服务器前需要审查。

Skill（技能）

一份打包好的工作流说明：把某类任务该怎么做——用什么措辞、按什么步骤、什么算完成——写成文档，需要时让 Agent 照着做。形式上就是一个文件夹，里面放一份说明文件，可以附带模板和参考资料。

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

Skill 和 MCP 常被搞混，其实是互补关系：MCP 解决"能接触到什么"，负责把 Agent 接上外部系统；Skill 解决"该怎么做"，教它一套办事的规矩。Skill 本身不连接任何东西，也不执行任何调用，它就是一份写好的说明。多数生产级 Agent 两个都需要。

记忆

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

所以 Agent 的记忆分两层：

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

记忆在 2024 年前后还只是"上下文窗口"的代名词，如今已被视为与推理、编排、工具并列的核心架构层，而不是可选项。

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

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

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

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

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

代价与风险

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

不过这正是提示缓存最擅长的场景——Agent 每一轮的上下文都是在上一轮末尾追加内容，开头那一大段逐字相同，可以直接复用已经算好的结果，主流服务商对命中缓存的部分只收约一成费用。由此产生一条与直觉相反的设计规则：把稳定的内容（系统指令、工具说明、参考资料）原样固定在开头，变化的部分一律追加到末尾。缓存要求前缀完全一致，工具顺序一变、中间插入一个时间戳，缓存就落空了。它也不是万能的：便宜的只是输入部分，而每轮生成的思考和工具调用属于输出，仍按原价计费；缓存本身还有有效期，harness 中途压缩上下文同样会让前缀失效。

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

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

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

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