为什么AI智能体在实际应用中会失败：解析“马具工程”

想象一下，凌晨2点还有位开发者正在花费三周时间重写提示词、测试最新的旗舰模型，并调整RAG数据块的大小。在沙箱环境中，该智能体表现优异；但一旦投入实际使用就会出问题：它会忘记两步之前做出的决定，在返回有缺陷的结果之前还宣称任务已完成，而且无论使用哪种模型，它的任务成功率都只有68%。要将其提升到70%以上似乎根本不可能。

很多团队都经历过这种情况。常见的诊断是模型不够好，但更准确的原因是问题出在围绕该模型构建的系统中，除非人们承认这一点，否则更换模型也难以带来显著改善。

与大型语言模型合作的三个阶段

关于大型语言模型应用的思考已经经历了三个阶段，而许多团队在遇到第三阶段的难题时仍停留在前一两个阶段。

第一阶段：提示工程

所有人都是从这里开始的，即确认模型是否理解了请求。大型语言模型对引导方式极为敏感。恰当选择的角色设定、几个示例以及明确的输出格式都能改变结果，而对于有限的单轮任务而言，良好的提示设计是不可或缺的。

但这种方法也会遇到瓶颈。无论指令表述得多么优雅，都无法为模型提供其缺乏的事实，无法让它记住三次工具调用之前发生的事情，也无法在现实数据不足时阻止它编造内容。常见的误区是认为更清晰的提示就能替代缺失的背景信息或实时上下文，事实并非如此。

第二阶段：上下文工程

下一个问题是模型是否掌握相关事实。各团队开始引入RAG流程、动态检索功能、工具输出反馈机制以及精心设计的对话历史记录，同时更加关注模型在做出决策时所能获取的信息。这确实是一个进步，当恰当的信息在合适的时间出现时，智能体也会明显变得更聪明。

但上下文处理无法解决执行偏差的问题。智能体虽然制定了出色的计划，第一步也执行得正确，但在第二步错误解读了工具的返回值，此后又连续十几步偏离正轨。系统中没有任何机制能察觉到这一点，它依然在继续执行早已出错的计划。

这里一个常见的错误是将上下文工程与向量数据库RAG混为一谈。真正的上下文管理还包括动态注入状态、总结工具响应以及有意识地截断历史记录。RAG只是起点而已。

第三阶段：管控工程

现在的问题是模型能否长期保持正确运行，而对于那些期望更优模型能做到这一点的人来说，答案可能会让他们有些沮丧。管控工程就是为模型构建支撑框架的实践：通过确定性系统监控模型的行为，捕捉其错误，在模型偏离轨道时设置限制并将其拉回正轨。这个词源自控制用的缰绳和安全绳索。

一种思维模型：智能体等于模型加管控框架

LangChain推广的一种表述方式很直观：智能体是由模型加上配套工具构成的。在代码库中，除了调用基础模型API之外，几乎所有能让智能体在实际环境中正常运行的元素都属于配套工具。

可以想象让一名初级同事去参加重要的客户会议。

• 提示词就是会议议程：打招呼、介绍产品、询问需求。
• 上下文则是相关背景资料：客户历史记录、价格表以及会议目标。
• 配套工具则包括其余要素：他们携带的清单、中途与你的沟通确认、会议记录，以及在他们偏离议程时进行纠正的方法，还有会议报告的验收标准。

再好的说明也无法弥补缺失的问责机制。前两个阶段有助于模型更好地思考，而框架则使其能够稳定运行。有一个团队的经验案例——这仅属于个例而非基准——表明，通过重新设计任务分解、状态处理、关键步骤验证以及故障恢复机制，同样的模型在相同的提示下，任务成功率从约70%提升到了95%以上。

成熟框架的六层结构

框架并非一个文件或简单的封装工具，而是由多层构成的，每一层负责处理不同类型的故障。

第1层：信息边界

模型在其直接所处的环境中所看到的内容对性能的影响几乎超过其他所有因素。额外的数据并不会让它变得更聪明，反而会使其分心。将系统规则、当前任务状态以及外部信息混为一谈只会让情况更糟，因为模型会开始忽略各种约束条件，而重要的规则则沦为背景噪音。应当明确界定并标注模型所接收的信息：它的角色、当前目标、成功标准，以及不同类型信息之间的清晰区分。

第二层：工具系统

如果没有工具，大型语言模型只能预测文本；而有了完善的工具系统，它便能在现实世界中发挥作用。早期的常见错误是提供过多的工具——虽然有15种文档齐全的工具听起来很强大，但模型的注意力会被分散，进而开始编造并不存在的参数，或误用那些它几乎不理解的API。

The harness should govern when tools get used, not just which ones exist. It should stop the model from guessing when it ought to search, and from searching when it already knows. And one rule has no exceptions: don't pipe raw tool output straight back to the LLM. A 50-item JSON reply from an API poisons the context. Filter, parse and summarise results before the model sees them.

Layer 3: execution orchestration

Models often fail not for lack of individual skills but because they can't chain them in order. They run in a stream of consciousness, hopping between steps, skipping checks and writing output before they have what they need. The harness sets fixed rails: understand the goal, assess what information is held, fetch what's missing, analyse, generate, verify, then output.

这使项目管理从概率模型转变为确定性系统。模型不应决定工作的顺序，而这种结构应属于调度框架。

第4层：内存与状态

无状态智能体在每一步都会“遗忘”之前的内容，就好像多步骤任务中的每一步都是一次新的对话。一种可行的方法是将三种类型的内存严格分开：

1. 当前任务状态，即哪一步正在执行、哪些任务待处理以及哪些已确认。
2. 本次会话得出的中间结论。
3. 长期内存与用户档案，如跨会话持续的偏好和上下文信息。

最有害的错误是将任务状态与对话历史混为一谈。这样一来，上下文窗口会不断膨胀且结构混乱，导致任务进行过程中模型的性能越来越差。

第5层：评估与可观测性

原始智能体在此处会失效。它们会产生输出并宣称任务成功，但却无法判断结果是否正确。能够自我评估工作的智能体存在固有的乐观偏差：它会将有缺陷的代码视为正常运行，即便根本没有回答问题也会将其回复评为满意。

该系统需要独立的自动化检查机制。事后由人工审核效率过低且无法扩展。这一层负责自动输出验证、测试环境、详细日志记录、指标统计以及错误溯源。系统必须持续证明自己的操作是正确的，而不能仅凭猜测。

第6层：约束、验证与恢复

在实际应用中，失败是常态。API会超时，JSON格式可能出错，搜索结果也可能不准确。没有恢复机制的智能体在每次出现错误后都需要由人工完全重新启动。为此需要三个要素：

• 约束条件：规定智能体绝不能执行的硬性规则。
• 验证机制：在输出前后进行的检查，包括模式验证、格式检查以及约束条件确认。
• 恢复策略：重试机制、备用方案以及回滚到上一个已知稳定状态的功能。

上下文焦虑

在需要执行数十个步骤的任务中，一旦出现异常情况，Anthropic的研究人员给这种现象起了一个名字：上下文焦虑。当上下文窗口接近容量极限时，模型会忽略细节、偏离核心目标，并显得急于完成任务。它们会编造出从未得出的结论，跳过验证步骤，这种急功近利的态度反而导致它们工作粗糙。

显而易见的解决办法是压缩：总结历史记录，插入摘要后再继续处理。这样虽然能减少标记数量，但无法重置模型的认知状态或注意力分散问题。更有效的办法则是彻底重启智能体。当上下文规模过大时，压缩后的摘要会被传递给一个全新的智能体实例，该实例拥有干净的上下文且没有累积的混乱状态。这就好比通过重启进程来解决内存泄漏问题，而非依靠急躁的垃圾回收机制。这种方法的名称为“上下文反射”。

工具展示得益于一种名为“渐进式披露”的类似理念。模型不会在初始阶段加载整个工具库，而只会看到最基础的框架。当它表示需要某种特定功能时，系统才会注入详细的文档和参数规范。优化上下文并非要为模型提供更多信息，而是要在其真正需要时提供恰当的内容。

将生成与评估分开

最实用的理念之一源自 Anthropic 构建自主智能体的方式——这些智能体无需人工审核即可连续数小时生成完整可用的产品。其核心在于严格的三分制结构：

• 规划器将模糊的人类需求转化为精确的工程规范。
• 生成器依据这些规范逐步执行任务。

评估器作为独立的质检角色运作，其功能与生成器相互分离。

评估器并非仅仅阅读生成器的代码，还会与输出结果进行交互。在处理用户界面时，它会逐项点击界面元素，检查布局并测试各种交互状态。它的验证标准是现实世界的情况，而非生成器对现实世界的描述。

OpenAI的举措更为深入。当这些智能体编写代码的速度超过人类审核拉取请求的速度后，他们便为这些智能体配备了独立的自动化CI/CD流水线。这些智能体在隔离的沙箱环境中执行任务，通过无头浏览器截取屏幕截图，查看自身的日志，并不断循环直至部署成功，整个过程无人监督。“完成”不再仅仅意味着文本已生成，而是指代码已运行、日志已检查、错误已被发现并修复，且部署在沙箱环境中也得到了验证。

真正的瓶颈所在

基础模型的智能水平决定了基准测试排行榜上的理论上限。而配套系统的设计质量则决定了这种智能能否在复杂的实际环境中存活、恢复功能并发挥价值。一旦超过一定水平，模型本身就不再是瓶颈。70%的成功率与95%的成功率之间的差距，也就是演示版本与正式产品之间的差距，恰恰存在于配套系统中。