Why better models don’t fix every agent failure: Lessons from OpenAI

为什么更先进的模型无法解决所有代理故障：来自 OpenAI 的教训 - Arize AI

OpenAI 技术团队成员 Stuart Sy 一直反复提到一个故障案例。在一个系统中，他观察到大约每 30 到 50 次对话中就会出现一次对话突然中断的情况，既不会抛出错误，也不会在仪表板上显示明显错误的答案。

任何将代理系统部署到生产环境的开发人员都熟悉这种问题：那些只在关键时刻出现、其余时间隐藏的 bug。但正是这种频率让问题难以被发现。每几十次运行才会出现一次的故障可能不足以显著影响整体质量评分，但在生产环境中却频繁到无法忽视。

Sy 的诊断从模型之外开始。"大多数情况下，模型的智能并不是瓶颈，" 他表示。工程挑战在于理解模型周围发生了什么，测量故障，并利用这些证据改进系统。

为什么能力强大的模型仍然会失败？

"大多数情况下，模型的智能并不是瓶颈，" Sy 说。差距体现在能力冗余上：模型已经具备团队想要的功能，但"通常受限于它们实际可访问的工具或上下文"。

当代理失败时，首先要问清楚运行过程中实际看到了什么，以及在决定是否更换模型前，它被允许执行哪些操作。

这种模式在各种类型的代理中都存在。运行在强大模型上的客服代理仍然可能因无法访问账户状态或调用解决问题的工具而失败。代码代理可能推导出正确的修改方案，但若测试运行环境从未暴露给它或未授权其写入文件，仍然会失败。在两种情况下，故障可能更多与周围系统是否提供了任务所需条件有关，而非模型本身能力不足。

更先进的模型无法弥补周围系统中的所有故障。上下文决定了代理能接收的信息，而运行环境决定了可用的工具、状态和操作。仅升级模型无法修复缺失的工具、截断的上下文或静默的权限失败。

在更换模型之前，请先问这四个问题：

• 代理是否接收到了它所需的文档、状态和工具结果？
• 它所需的工具是否可用，且模型可以使用的模式是否完整？
• 工具调用是否失败、超时或返回了模型当作事实处理的空负载？
• 如果一个人拥有相同的上下文和工具，是否能完成这项工作？

如果故障出现在这些层级中的任何一个，转向更大的模型可能只会增加成本，而无法解决根本问题。

任务专用模型让位于上下文、提示和评估

Sy 的第二个观点涉及工程时间现在应该投入的方向。

"以前，如果你想对用户反馈进行情感分类，或者想将内容归入结构化分类体系，就必须训练一个专用模型，" 他表示。这产生了"一个效率很高但只能单次使用的工具"。

现在的替代方案是基础模型加上周围系统："正确的上下文工程、提示设计和评估集，以优化提示和工具的设置方式"。

保持模型不变足够长的时间以从中学习，然后改变其周围的输入和工具，并测量每次更改是否真正推动了结果的变化。

上下文工程是决定模型所见内容的实践：事实、会话状态、工具以及包裹它们的格式。提示词的措辞仍然重要，但它只是其中的一层。其余部分包括你检索的证据、压缩的方式、暴露的工具模式，以及在失败后是否能重放相同的组合。

评估集为这种迭代循环提供了一个稳定的靶点。它在你开始修改提示、上下文或工具之前，就定义了成功的样子。一个替换情感分类器的团队应该使用真实反馈的标记样本进行评估，而不是使用通用的有用性评分。一个替换分类模型的团队应检查新设置是否将案例路由到正确的节点，并在标签不明确时选择不处理。评估会告诉团队替换是否真正保留或改进了他们关心的行为。

一个紧密的循环如下所示：

• 收集一组真实示例，包括间歇性故障。
• 编写一个狭窄的准则来命名故障。
• 在上下文、工具或提示中更改一件事。
• 重新运行相同的案例。
• 仅在评估结果发生变化时保留更改。

递归式自我改进是你必须构建的反馈循环

“在研究和应用组织中，一个重要的主题是递归式自我改进的概念，”Sy表示。你需要问自己：“你如何设置这些自动循环，以便通过爬坡不断变得更好？”

在这里，自我改进并不需要代理自主地重写自身或更新自己的权重。这个循环可以是一个工程化的过程，将生产证据转化为对上下文、提示、工具、评估或周围系统的更改。

OpenAI的这种循环从规模开始。“当我们接近ChatGPT的十亿用户时，我们不断从许多不同来源获得大量反馈，”Sy说。“这比任何人都能手动阅读、理解、优先处理并一次性采取行动的量还要多。”

因此，他们构建了一个系统，每天处理数百万个数据点，然后创建对这些数据流的共享理解。“你确实需要一些重型的传统软件工程来处理所有这些规模，”Sy说。

大多数团队每天不会处理数百万个事件。他们仍然可以应用这个过程：

• 将评分、工单、聊天更正和跟踪失败放入一个事件模型，附带原始文本和对话或跟踪ID。
• 从你已知的失败中引导出一个简短的分类法：工具错误、上下文缺失、标签错误、被放弃的会话。
• 聚类最近的剩余项，使新的失败模式在有人为它们创建图表之前就能显现。
• 将确认的聚类提升为评估案例，然后在发布后持续观察。

为什么代理评估需要过程指标

随着代理运行时间变长，最终输出分数会掩盖更多失败。

“你不仅要关注最终输出，还要关注过程中的情况，”Sy说。开发人员应该能够回答：

• 做出了哪些工具调用，有多少次？
• 这些调用是否有错误率和延迟？
• 模型使用的思考努力量是否会影响最终输出？

一个编码代理可能在十二次失败的工具调用、三次超时和多次未整合测试结果的尝试后，生成一个看似正确的补丁。仅查看最终差异的评估可能会遗漏这些过程失败。一个跟踪记录会暴露这些失败。

这也是为什么工具链评估与模型评估并列的原因。工具链是负责管理工具、上下文、状态、重试机制和停止条件的运行时环境。如果追踪记录显示工具错误率较高，下一步的改进可能涉及工具模式、重试策略或权限层，而非系统提示。

Hamel Husain 在该系列的第二部分中提出了相关观点：通用指标很少能捕捉到真正关键的失败情况，而有用的评估应从分析真实数据开始。Sy 补充了监控需求。如果运行过程中从未记录工具调用、错误、延迟或思考努力，就无法查看这些数据。

实际上，这意味着需要监控整个执行轨迹，而不仅仅是最终响应。例如，在 Arize Phoenix 或 Arize AX 中，你可以检查以下内容：

• 每个模型调用和工具调用的跨度，包括参数、错误和延迟。
• 单个请求的追踪记录视图，以便查看完整路径而不仅仅是最后一条消息。
• 多轮对话中的会话级评估。
• 生产环境中的罕见追踪记录，例如每30次对话中发生一次中断的情况，这在包含20个示例的黄金数据集上永远无法捕捉到。

每30次发生一次的中断正是生产环境追踪能够揭示的失败类型。离线评估仍然必要，但生产运行会暴露固定评估集尚未包含的罕见且新出现的故障。

AI工程师仍需具备工程能力

对话接近尾声时，Sy完成了该系列反复探讨的同一句话：“AI工程师是‘那些利用现在可用的新原始工具，在基础模型或大语言模型之上构建AI产品或系统的人’。”

随后，他对此设定了限制条件。“仍需要具备扎实的基础工程技能。你仍然需要真正理解你所构建的现有系统。”

AI工程在现有工程技能的基础上，新增了围绕模型、上下文、工具、评估和代理运行时的特殊关注点。AI工程师应了解如何“最大限度地发挥生成式AI的性能”，并“以有原则且可预测的方式”使用它。在Sy的清单中，这意味着上下文工程、工具链工程、合适的工具、技能和MCP连接器，以及能够充分观察代理以实现生产级性能的能力。

这比“提示工程师”的工作描述更加精准。它也与Michael Grinich在该系列第一部分中的观点一致：围绕代理的系统决定了自主性是真正有用还是仅仅快速失败。

“有原则且可预测”是Sy所描述领域的一个有用标准。重放失败运行使其可复现。工具错误和延迟有助于区分上下文失败与运行时失败。将反复出现的生产投诉转化为评估案例，为团队提供验证下一次更改是否真正解决问题的方法。

你可以观看Stuart Sy主讲的《AI工程师的崛起》完整视频。