研究揭示 AI 智能体为何静默失败，以及如何度量这类故障

大型语言模型智能体现已能回答客服工单、查询数据库并规划行程。当它们出错时，通常仍会返回一个自信的答案和一个成功状态码。越来越多的研究解释了这类故障为何难以察觉，以及工程团队正在如何学会度量它们。

传统软件往往以显眼的方式失败。函数抛出异常，服务器返回错误码，监控仪表盘随即变红。AI 智能体的行为则不同。它是一个循环：语言模型读取提示词，决定调用搜索 API 或数据库之类的工具，读取结果，再决定下一步做什么。每一步都可能出错，而整条链路上的每个网络请求却依然成功。

考虑一个常见情形。某个天气工具发生故障，在一个原本正常的响应中返回了“服务不可用”这段文本。模型读到这段文本，礼貌地致歉，或者更糟——根据其训练数据写出一份看似合理的预报。用户收到了一段流畅的答案。服务器日志显示请求成功、延迟正常。常规监控体系中没有任何一处记录下出了问题。

模型提供商在自己的文档中也描述了同样的缺口。Google 的 Gemini API 指南指出，模型“不会自行执行函数”。它只提出函数名和参数，由开发者的应用来执行调用。因此，应用是系统中唯一能看到真实结果的部分。Anthropic 关于构建智能体的工程指南提出了一个相关的观点：智能体需要在每一步从环境中获得“真实基准”（ground truth），例如工具返回的结果，才能判断自身的进展。当工具把失败当作普通文本报告时，这个真实基准就是错的，智能体无从察觉。

这并不是一种新问题，只是一个老问题更尖锐的版本。2015 年，由 D. Sculley 带领的 Google 工程师描述了机器学习系统中的“隐藏技术债”。他们认为，生产环境 ML 系统的大部分风险位于模型代码之外，存在于数据依赖、配置和胶水代码之中。智能体又为这份清单增加了一层。提示词和工具描述属于配置，它们可以在代码毫无改动的情况下改变系统的行为。

小改动，大影响

提示词的小改动能有多大影响？在 ICLR 2024 上发表的一篇论文中，华盛顿大学的 Melanie Sclar 及其同事只改变了少样本提示词的格式：分隔符、空格和大小写。含义保持不变。在 LLaMA-2-13B 上，同一任务的性能波动仍高达 76 个准确率百分点。这种敏感性并未随模型规模增大、示例增多或指令微调而消失。

作者建议报告在多种合理提示词格式下的性能区间，而不是单一数字。对工程团队而言，实际教训更简单：修改提示词就是修改代码。它需要版本历史，也需要在到达用户之前经过测试。

同样的道理适用于工具描述，模型会将其作为提示词的一部分来读取。Anthropic 的指南建议，工具定义应当获得“与主提示词同等的提示词工程关注”。指南描述了一个编码智能体，它反复在相对文件路径上出错。当工具被改为要求绝对路径后，模型便不再出错地使用它。模型没有变，变的只是它读到的描述。

一次成功说明不了什么

第二条研究线索关注一致性。由 Sierra 的 Shunyu Yao 及其同事发布、并在 ICLR 2025 上展示的 τ-bench 基准模拟客服对话，其中智能体必须使用工具并遵循业务规则。作者引入了一个名为 pass^k 的指标：智能体在全部 k 次尝试中都正确解决同一任务的概率。

结果令人清醒。一个 GPT-4o 智能体单次尝试可解决约 61% 的零售任务。当它必须连续八次在同一任务上成功时，这一比例降至约 25%。一次能跑通的演示，几乎说明不了系统在第一千次运行时会有怎样的表现。

多智能体系统在哪里崩溃

许多团队现在将多个智能体串联起来，一个负责规划，另一个负责执行，第三个负责检查工作。加州大学伯克利分校 2025 年的一项研究《多智能体 LLM 系统为何失败？》分析了七个主流多智能体框架中 1600 多条带标注的执行轨迹。由 Mert Cemri 带领的作者构建了一个名为 MAST 的分类体系，包含三大类共 14 种失败模式：系统设计问题、智能体之间的失配，以及任务验证。

他们的核心发现是，许多失败源于系统的设计方式，而不仅仅是底层模型的局限。智能体无视自己被分配的角色，跟丢对话，或者在未检查结果的情况下宣称任务完成。这些失败不会留下任何错误痕迹。只有当有人能读懂每个智能体实际做了什么时，它们才可见。Unite.AI 对多智能体悖论的报道从架构角度提出了一个相关观点：增加智能体可能会放大早期错误，而不是将其抵消。

让不可见变得可见

工程上的应对借鉴了分布式系统的做法。在分布式系统中，长期以来人们用一种称为追踪（tracing）的技术，跨多个服务跟踪请求。将其应用于智能体时，每个用户请求成为一条 trace，而每次模型调用或工具调用则成为其中的一个“span”。一个 span 记录其输入、输出、所用 token 数以及耗时。这一领域的行业标准组织 OpenTelemetry 正在为生成式 AI 的 span 起草共享约定。截至 2026 年，这些约定仍被标记为开发中，因此属性名称仍可能变化。

Langfuse、Arize Phoenix 和 AcruxCore 等几个开源项目已经应用了这一思路。它们的源代码是公开的，因此团队可以检查 trace 的存储方式，并在自己的服务器上运行这些软件。它们将模型调用和工具调用记录为同一条 trace 中的 span，并允许团队为其附加质量评分。工具的选择不如一个细节重要：工具 span 必须记录工具实际返回了什么，而不仅仅是网络请求是否成功。否则，上文描述的天气工具故障将始终不可见。

行业调查表明，追踪如今已很普遍，但测试却落后于它。LangChain 的《智能体工程现状》报告在 2025 年底调查了 1,340 名从业者。质量是将智能体投入生产时被提及最多的障碍，32% 的受访者提到了这一点。89% 的组织报告对其智能体采用了某种形式的可观测性，62% 的组织对各个步骤和工具调用进行了详细追踪。只有 52.4% 在测试集上运行离线评估，37.3% 对实时流量进行评估。大多数团队能看到其智能体做了什么。但检查其是否正确的人更少。

大规模评分答案

Trace 显示发生了什么。它们并不说明答案是否良好。逐条人工阅读每段对话无法扩展，因此团队越来越多地使用第二个模型作为评分者，这种方法被称为 LLM-as-a-judge。Lianmin Zheng 及其同事在 NeurIPS 2023 的一篇论文中发现，GPT-4 等强模型与人类偏好的一致率超过 80%，与人类彼此之间的一致率大致相同。

同一篇论文也记录了该方法的弱点。评判模型偏好先展示的答案，偏好更长的答案，并且可能偏爱自己生成的文本。因此，评判分数只是估计值。它们对处理大量数据有用，但需要对照一小部分人工标注的示例进行检查，并随机化答案顺序。

从实践到政策

这项度量工作也正成为一种治理期望。美国国家标准与技术研究院于 2023 年 1 月发布了其 AI 风险管理框架。其四项核心功能之一“度量”（Measure）要求组织随时间量化、跟踪并记录 AI 风险。对于智能体而言，trace 和评估分数正是该功能所要求的证据。

团队现在可以做什么

这与本平台提出的论点相呼应：可靠性才是智能体 AI 的真正考验。上述研究为该论点补充了度量层面的细节：可靠性不是一次性观察到的属性，而是必须持续度量的一个范围。

研究指向一小组习惯，而主要模型提供商也推荐了其中许多相同的做法。OpenAI 的智能体构建实用指南告诉团队，在优化之前要“设置评估以建立性能基线”，并在智能体超过设定的失败尝试次数或面临高风险操作时，将控制权交给人类。Anthropic 建议在智能体自主行动之前“在沙箱环境中进行广泛测试”。

在实践中，这意味着几个具体步骤。像对待代码一样，将提示词和工具描述纳入版本控制。针对固定数据集测试每一次提示词更改，并预期得到一系列结果，而不是单一数字。每个测试用例运行多次，因为一次通过会掩盖不一致性。在 trace 中记录工具输出，这样失败的工具就无法隐藏在成功状态码背后。将自动评判分数视为估计值，并用人工检查加以核对。

这些习惯都不需要模型能力取得突破。它们需要的是把 AI 智能体当作它本来的样子：一个必须被度量的概率系统，因为它很少会主动宣告自己的失败。