大多数希望提升智能体性能的 AI 团队都会采用同样的手段：扩大上下文窗口、增加文档、优化提示。本文认为，这种思路完全错了。缺少的并不是更多信息。而是控制。设计完善的控制层，正是智能体只能在演示中运行与能够用于生产环境之间的分水岭。
给 AI 智能体更大的记忆、更多文档或更长的上下文窗口，并不会让它更聪明，只会让它更慢、更昂贵。真正的提升来自让智能体在需要时自行选择所需信息，而不是一次性吞下所有内容。
可靠性来自循环，而非模型。智能体能否从演示中的惊艳表现走向生产环境中的稳定运行，差别不在 AI 的质量，而在于系统是否会检查自己的工作。在每一步进行规划、行动、观察和验证的智能体，能自行发现错误，而不是信心满满地犯错。
如今大多数 AI 智能体本质上只是多了几个步骤的聊天机器人，没有任何机制判断自己是否方向正确、何时应停止或何时该换一种方法。加入适当的控制层——明确的成功标准、结构化状态和验证检查——才能把徒具智能体外形的东西变成真正可信的系统。
你昨天午饭吃了什么？
你大概不会回放一生中的所有记忆，直到找到“昨天加午饭”。你会直接跳到经历中与这两个概念相关的部分。这为构建智能体提供了一个实用的思维模型：
巨大的上下文窗口并不等于记忆。
堆积起来的检索文档并不等于理解。
冗长的思维链并不等于可靠性。
这些只是原料。但真正让智能体像智能体的因素，与让大脑不必穷举整个人生经历的因素相同，那就是：控制。
近期的一篇综述——大语言模型的智能体推理——出色地总结并命名了许多人在构建过程中感受到的转变：从模型内部的推理，转向通过交互进行推理。本文并不是对那篇论文的总结。而是试图将这种转变落实为实用的系统设计：
如果像构建带工具的聊天机器人一样构建智能体，就会不断遇到聊天机器人的故障模式，只不过犯错的代价更高。
有一段时间，我们“让模型更聪明”的默认方案基本是：更好的提示、思维链、自洽性或基于采样的改进，再加上或许一些搜索。
ReAct 是一个转折点，因为它让“思考 → 行动 → 观察”显得顺理成章。但请注意其中隐含的限制：很多做法最终仍只是“使用更多 token 的单样本推理”。这项综述的界定更精准：智能体推理强调扩展测试时交互，将推理变成一个迭代过程，让模型、记忆和环境始终参与循环。
如果你构建或使用过在演示中令人惊艳、在实际工作流中却很脆弱的智能体，本文正适合你。
下面说说一种我经常见到的模式（我自己也确实构建过类似版本）：
采用一个优秀的聊天模型
添加几个工具（搜索、数据库查询，也许还有代码执行）
添加 RAG
添加一条“你是自主智能体”的系统提示
用 while 循环把这一切包起来，直到它停止或超时
恭喜，你得到了一个徒具智能体外形的东西。但它往往会以可预见的方式失败：
上下文膨胀：每次观察都被追加，提示逐渐堆成考古地层。
工具乱用：“自信地用错工具”成为默认的故障模式。
没有停止条件：它不停运行，只因为它能，而不是因为它应该。
缺乏落地规范：除非你迫使它检查，否则它不会发现自己错了。
记忆 = 聊天记录：本质上就是写日志，却把它称为学习。
这就是“智能体”为何常在演示中宛如魔法，到了生产环境却一团糟。我们将智能体系统投入生产的经验也印证了这一点：一旦评估对象不再是模型而是系统，故障模式就会涉及导航、工具规范、上下文裁剪和评估设计，而不只是“模型是否答对”。
于是问题变成：理想的智能体是什么样？
为了说得更具体，下面用一个大多数人都能想象的简单工作流为例：“帮我预订下周二从伦敦飞往纽约的航班。下午 6 点前抵达。价格不超过 900 英镑。要靠过道的座位。”
一种常见的“智能体式”实现如下：
立即检索大量航空公司或旅行政策文档，即使暂时一个也用不上。
调用搜索工具，将一长串结果粘贴到提示中，然后“挑一个”。
尚未验证到达时间、行李、座位和政策等约束，便草率预订。
如果失败，它会略换一种方式重试，却不清楚具体改变了什么、从中学到了什么。
问题并非模型无法推理，而是系统没有掌控工作流。
更具智能体特性的版本会将任务视为一个交互过程，并明确记录状态和执行检查：
规划：重述约束并列出缺失信息（例如，“偏好哪个机场？”或“可以中转一次吗？”）。
行动：使用结构化查询调用航班搜索（日期范围、抵达时间限制和预算）。
观察：将结果存入紧凑的状态对象（包含价格、抵达时间和中转次数的前 5 个候选项），而不是粘贴一大堆内容。
更新：若不满足约束，则优化查询（例如，“下午 6 点前抵达的要求太严格，要扩大时间范围还是提高预算？”）。
验证：运行验证器（“抵达时间 < 18:00”“价格 ≤ 900 英镑”“符合政策”“可选座”）。
停止：仅当预订 API 返回确认且所有验证均通过时才停止。
这种变化看似细微，却具有决定性。检索按需触发，而非条件反射；上下文受到管理，状态采用结构化形式而非不断堆积；验证则置于循环之中，而非留给用户处理。将“预订航班”换成“创建采购订单”“发放退款”“更改生产配置”或“交付 PR”，道理都一样：一旦智能体能够行动，循环就比提示更重要。
上述综述将智能体推理分为三层：基础层（规划、工具使用和搜索）、自我演进层（反馈加记忆），以及集体层（多智能体协调）。
但更深层的理念是：推理成为组织规划、决策和验证的核心原则，而不只是生成看似合理的思维链。这听起来很抽象，直到你把它对应到架构变化上。需要记住三个核心要点：
优秀的智能体不应把检索视为“每次必做”。检索是一项决策，不是条件反射。
这里有一条实用的经验法则：
如果系统每轮都会检索，那你构建的不是检索，而是上下文税。
这种情况在实际工作中屡见不鲜。调试生产事故时，你不会把所有日志全塞进上下文，而会根据当前假设决定下一步获取哪些指标或日志。这就是“智能体式检索”。更具体的模式如下：
判断是否需要检索
如果需要：拟定查询、获取内容、快速浏览并提取信息
如果证据冲突：再次获取
完成这些后再综合信息
“智能体式 RAG”也正是从这里开始区别于传统 RAG：检索成为一个有意识的推理步骤，而不再是默认的管道阶段。
当评估对象从“模型”变成“系统”时，状态跟踪和追踪就变得至关重要。
如今，业界已越来越明确地重视智能体工作流的可观测性。例如，OpenAI 的 Agents SDK 内置追踪功能和 Traces 仪表板，可记录智能体的运行过程（生成、工具调用、移交、护栏和自定义事件），让你能够逐步调试和审计实际发生的情况。
这并非“锦上添花”，而是系统可调试与只能凭感觉检查之间的区别。
在我看来，这项综述中最具可操作性的部分，是它对反馈的阐述非常直接。它将反馈分为三种机制：反思式反馈（生成 → 批评 → 修订）、参数适应（通过微调或强化学习来学习），以及验证器驱动的反馈（反复重试，直至通过验证）。
大多数团队都应从验证器驱动的反馈入手，因为它朴实无华，却很有效。只要能编写任何一种验证器，用来执行单元测试、检查模式、设定业务规则或约束（“超过 X 的退款必须升级处理”），或核实事实性（“必须提供引文”），就能把不确定的模型输出变成真正可信的结果。
这里一个容易被忽视的根本变化其实很简单：在智能体领域，可靠性往往更多来自循环，而非模型。
我发现，无需训练便能稳定改善行为的最简循环规范如下：
分步运行：规划 → 行动 → 观察 → 更新；
每次行动后，用 1–3 个要点总结观察结果；
达到成功标准或预算上限时停止，并返回当前最佳结果和仍存的不确定性。
这并不是要让模型变得啰嗦。而是要让系统清晰可读，并迫使它在每一步都“接触现实”。一个工程师很容易理解的例子，是类似 CI 的闭环落地：
规划：提出变更清单
行动：运行测试或 lint 检查
观察：解析失败信息
更新：修补并重试
以下几个问题往往能暴露无意间造成的智能体设计缺陷：
“我的智能体会自行决定检索什么，还是我每次都会检索？”
如果无条件检索，你将为此付出代价：延迟增加、成本上升、上下文被稀释，以及“垃圾进、垃圾出”的风险更高。
“我的智能体能发现自己错了吗？”
如果智能体唯一的反馈信号是“用户恼火了”，那你就是在用人类的痛苦做强化学习。验证器驱动的重试循环，是让它接受现实检验最简洁的方式。
“记忆是否可写？它会随时间推移而改善吗？”
如果你的“记忆”只是不断追加聊天记录，本质上不过是在写日志。这项综述对记忆的界定很重要：记忆会成为智能体随时间持续完善、动态增长的上下文，而不只是一份对话实录。
日志告诉你发生了什么，记忆则告诉你下次该怎么做。聊天记录是一份对话实录。记忆是一套不断演进的策略，用于决定哪些内容值得留到以后。
一种实用的入门做法，是建立一张小型“经验教训”表：以任务类型、工具和故障模式为键，以有效做法和应避免事项为值。重点不是构建完美的知识图谱。重点是让行为产生复利效应：记忆加反馈，让智能体从“无状态助手”变成能随时间不断改进的系统。
人们很容易想用更多智能体解决问题，但这往往会成倍增加协调开销。一种优秀的“最小可行团队”模式如下：
协调者：分解任务并分派
执行者：调用工具或实施变更
批评者/评估者：检查正确性和风险
记忆管理员：记录并整理经验教训
如果无法说明每个智能体各自负责什么，你可能还不需要多个智能体。
如果我们真正接受这种范式转变，或许就不会再把所有内容塞进提示、将失败视为最终输出，也不会再像评估聊天机器人那样评估智能体。我们会开始按智能体的本质看待它们：它们是以语言作为控制平面的软件系统，而可靠性来自循环。
添加另一个模型前，先添加一个评估循环。检索所有内容前，先让检索按需触发。先交付一个验证器，再考虑交付十个。将记忆视为策略决策，而非数据库。采用多智能体时，先从两个开始，而不是二十个。这些并非规则，而是经受住生产环境考验的模式。