AI 智能体很少崩溃，却会悄无声息地失效：研究揭示了原因

大型语言模型智能体如今能够处理支持工单、查询数据库和规划行程。它们出错时，通常仍会给出看似笃定的答案，并返回成功代码。越来越多的研究解释了为何这类故障难以察觉，也说明工程团队正如何学习衡量这些故障。

看似成功的故障

传统软件往往会以明显的方式出错：函数抛出异常，服务器返回错误代码，监控仪表盘随即变红。AI 智能体的表现则不同。它是一个循环：语言模型读取提示，决定调用某种工具（例如搜索 API 或数据库），读取结果，再决定下一步做什么。链条中的每个步骤都可能出错，但所有网络请求仍可能全部成功。

来看一个常见的情况。天气工具发生故障，在原本正常的响应中返回了“服务不可用”这段文字。模型读到这段文字后，可能礼貌地道歉；更糟的是，它可能根据训练数据编造一份看似合理的天气预报。用户收到的是一段流畅的回答。服务器日志显示请求成功，延迟也正常。传统监控体系中没有任何记录表明发生了故障。

模型提供商也在自己的文档中描述了同样的问题。Google 的 Gemini API 指南指出，模型“本身并不会执行函数”。它只会提出函数名称和参数，实际调用则由开发者的应用程序执行。因此，只有应用程序能看到真实结果。Anthropic 关于构建智能体的工程指南也指出，智能体需要在每一步从环境中获取“真实情况”（例如工具返回的结果），以判断自身进展。当工具以普通文本的形式报告故障时，这些真实情况就不准确，而智能体也无从察觉。

这并非一种全新的问题，而是一个老问题的更突出版本。2015 年，以 D. Sculley 为首的 Google 工程师描述了机器学习系统中的“隐性技术债务”。他们指出，生产环境中的机器学习系统，其大部分风险并不在模型代码中，而在数据依赖项、配置和胶合代码中。智能体又给这份清单增添了一个新层面。提示和工具描述都属于配置，即使代码没有任何变化，它们也可能改变系统的行为。

微小改动，巨大影响

提示稍作改动，影响究竟有多大？在一篇于 ICLR 2024 发表的论文中，University of Washington 的 Melanie Sclar 及其同事只改变了少样本提示的格式：分隔符、间距和大小写。提示的含义保持不变，但在 LLaMA-2-13B 上，同一任务的表现仍相差最多 76 个准确率百分点。即使扩大模型规模、增加示例或进行指令微调，这种敏感性也没有消失。

作者建议报告不同合理提示格式下的表现范围，而不是只给出一个数字。对工程团队而言，实际教训更简单：修改提示就是修改代码。提示需要有版本历史，也需要在交付给用户之前经过测试。

工具描述也同样如此，因为模型会把它们作为提示的一部分来读取。Anthropic 的指南建议，工具定义应获得“与主提示同等程度的提示工程关注”。指南提到一个编码智能体总是在相对文件路径上出错。将工具修改为要求使用绝对路径后，模型便能无误地使用它。模型本身没有改变，改变的只有它读取的描述。

一次成功说明不了多少

另一项研究关注的是一致性。Shunyu Yao 及其在 Sierra 的同事发布了τ-bench 基准测试，并在 ICLR 2025 上介绍了这项研究。该基准模拟客户服务对话，要求智能体使用工具并遵守业务规则。作者提出了一项名为 pass^k 的指标：智能体在 k 次尝试中每次都正确完成同一任务的概率。

结果令人警醒。GPT-4o 智能体单次尝试约能完成 61% 的零售任务。若要求它连续八次成功完成同一任务，这一比例便降至约 25%。一次演示成功，几乎说明不了系统运行到第一千次时会有怎样的表现。

多智能体系统在哪里失灵

如今，许多团队会将多个智能体串联起来，由一个负责规划，另一个负责执行，第三个负责检查结果。2025 年，UC Berkeley 发布了一项研究，题为《为什么多智能体 LLM 系统会失效？》。研究分析了七种热门多智能体框架中 1,600 多条带注释的执行轨迹。由 Mert Cemri 牵头的作者团队构建了一套名为 MAST 的分类体系，将 14 种失效模式归为三类：系统设计问题、智能体之间的不一致，以及任务验证问题。

他们的核心发现是，许多故障源于系统设计，而不只是底层模型的局限。智能体会忽视分配给自己的角色、跟丢对话内容，或未经检查结果便宣告任务完成。这些故障不会留下错误记录，只有能够查看每个智能体实际做了什么的人才能发现。Unite.AI 对多智能体悖论的报道也从架构角度指出了类似的问题：增加智能体可能放大早期错误，而不是将其抵消。

让隐患显现出来

工程上的应对方式借鉴了分布式系统的做法。在分布式系统中，人们早已使用一种称为追踪的技术，跟踪请求在多个服务间的流转。应用于智能体时，每个用户请求都会形成一条追踪记录，其中每次模型调用或工具调用都是一个“跨度”。跨度会记录输入、输出、所用令牌以及耗时。负责这项工作的行业标准组织 OpenTelemetry 正在起草生成式 AI 跨度的通用规范。截至 2026 年，这些规范仍标注为开发中，因此属性名称仍可能发生变化。

多个开源项目已经采用了这一思路，例如 Langfuse、Arize Phoenix 和 AcruxCore。它们的源代码是公开的，因此团队可以检查跟踪记录的存储方式，并在自己的服务器上运行这些软件。它们会将模型调用和工具调用记录为同一条跟踪记录中的各个跨度，并允许团队为这些跨度添加质量评分。与工具的选择相比，有一点更重要：工具跨度必须记录工具实际返回的内容，而不能只记录网络请求是否成功。否则，上文所述的天气工具故障就会一直被隐藏起来。

行业调查显示，追踪如今已十分普遍，但测试的发展却落后于追踪。LangChain 于 2025 年末对 1,340 名从业者进行了调查，发布了《智能体工程现状报告》。受访者最常提到的智能体投入生产障碍是质量问题，占 32%。89% 的组织表示，已对其智能体采取某种形式的可观测性措施；62% 的组织则对单个步骤和工具调用进行了详细追踪。只有 52.4% 的组织使用测试集进行离线评估，37.3% 的组织评估了实时流量。大多数团队都能看到智能体做了什么。能够检查其行为是否正确的团队则少得多。

大规模评估答案

追踪记录能显示发生了什么，却无法说明答案好不好。人工逐条阅读所有对话无法大规模开展，因此团队越来越多地使用第二个模型充当评分员，这种方法称为“以大语言模型为评审”。Lianmin Zheng 及其同事在一篇发表于 NeurIPS 2023 的论文中发现，GPT-4 等强大模型与人类偏好的吻合率超过 80%，与人类彼此之间的偏好一致率大致相同。

同一篇论文也记录了这种方法的弱点。评审模型更偏好先展示的答案、更偏好较长的答案，也可能偏袒自己生成的文本。因此，评审模型给出的分数只是估算值。它们适合用于大规模评估，但仍需用一小批由人工标注的示例进行核验，并随机调整答案的呈现顺序。

从实践走向政策

这项测量工作也逐渐成为治理方面的要求。美国国家标准与技术研究院于 2023 年 1 月发布了《人工智能风险管理框架》。框架的四项核心职能之一“测量”要求组织量化、跟踪并记录 AI 风险随时间的变化。对于智能体而言，追踪记录和评估分数正是该职能所要求的证据。

团队现在可以采取哪些行动

这与本平台此前提出的观点相呼应：真正检验智能体式 AI 的是可靠性。上述研究进一步说明了如何衡量这一点：可靠性不是只需观察一次的属性，而是一个必须持续测量的范围。

研究总结出一套精简的实践准则，主要模型提供商也提出了许多相同建议。OpenAI 关于构建智能体的实用指南建议团队在优化之前“建立评估机制，以确定性能基线”；如果智能体的失败次数超过设定值，或面临高风险操作，则应将控制权交给人工。Anthropic 建议在智能体独立行动之前，先“在沙盒环境中进行充分测试”。

具体而言，这意味着要落实几个步骤。像管理代码一样，对提示词和工具说明进行版本控制。针对固定数据集测试每次提示词变更，并预期结果会有一定波动，而不是只看一个数字。每个测试用例都运行多次，因为只运行一遍会掩盖不一致性。在追踪记录中记录工具输出，避免工具故障被成功状态码掩盖。将自动评审分数视为估算值，并通过人工进行核验。

这些做法都不需要模型能力取得突破。它们要求我们正视 AI 智能体的本质：它是一个概率系统，必须接受测量，因为它很少会主动报告自己的失败。