当智能体执行失败时：从遥测数据检测与定位运行时故障

# 当智能体执行失败时：从遥测数据检测与定位运行时故障
来源：https://arxiv.org/html/2608.14680
###### 摘要.

基于大型语言模型（LLM）的智能体系统的可靠性是整个执行过程的属性（包括工具调用、模型调用、护栏机制以及智能体间通信），而不仅仅是最终答案的属性。仅评估任务结果无法揭示运行失败的方式或原因。我们提出了**AgentChaosBench**，这是一个基准测试，用于从智能体系统的执行遥测数据中检测和定位运行时故障。我们运行了五个异构应用，这些应用通过**智能体间协议**协调智能体，并通过**模型上下文协议**调用工具。我们在其工具、模型、护栏和智能体间边界处注入了十种运行时故障（不可用或缓慢的工具、损坏或过大的响应，以及延迟、循环或错误路由的委派，以及被绕过的护栏），同时还包含了一个无故障对照组。由此产生的数据集包含275条经过处理的追踪记录：250条故障执行记录涵盖十种故障类型，以及25条无故障对照记录。每条故障追踪记录都与相同输入的无故障执行记录对齐；故障类型标签以及（如果适用的）位置标签在诊断时被保留不提供。在基于结构化单条追踪输入的任务上，一组零样本LLM基线模型表明该任务远未解决：参数高达140亿的本地检测器在十种故障类型的最高1项准确率上仅达到13.6%–19.2%，即使是前沿的DeepSeek-v4-pro模型也仅达到24.8%；而同时识别故障类型及其位置的方法最高准确率仅为22%；参考依赖型故障（尤其是被绕过的护栏）从单条追踪记录来看几乎无法解决。对齐的无故障参考记录改善了某些相对故障的检测，但未能解决护栏绕过问题。保留的标签和紧凑的预测格式支持了基于LLM和非LLM诊断方法的可复现比较。

## 1.引言

大型语言模型智能体正从对话接口演变为能够规划、调用工具、维护状态并与其他智能体协调的软件系统（He等人，2025；Zhao等人，2026）。像AgentBench这样的基准测试展示了通过与外部环境进行多步交互可以解决的任务广度（Liu等人，2024）。更新的AI原生系统进一步将智能体与标准化的工具和通信协议相结合，包括模型上下文协议和智能体间通信，这使得系统行为不仅依赖底层模型，还依赖于编排逻辑和网络服务（Wang等人，2026b）。随着这些依赖的增加，仅评估最终任务结果无法深入了解系统运行的可靠性或特定执行失败的原因。

**任务 + 故障配置 → 插桩的智能体执行 → 原始追踪（Langfuse JSON） → 处理后的追踪（case.json） → 结构化视图（每个span一行） → 诊断方法 → 故障类型 + 位置 → 预测与保留标签对比 → 原始视图**  
图1. AgentChaosBench数据生成与诊断流程。任务和故障配置驱动插桩的智能体执行，产生原始的Langfuse追踪。移除真实值字段以生成处理后的追踪，直接用于诊断或总结为结构化视图。预测结果与单独保留的标签进行评分对比。

生产环境中的智能体执行暴露了广泛的故障面。远程工具可能变得不可用、超时，或返回看似合理但已损坏的响应；LLM调用可能超出其上下文预算；智能体间请求可能被延迟或路由到错误的智能体。这些故障不一定是由于错误的推理步骤引起的，但它们可以传播到长执行过程中，并最终表现为错误答案、过高延迟或停滞的工作流。因此，初期工作已将故障注入和混沌工程的思想应用于智能体系统，研究了工具不可用性、延迟、挂起、错误响应、任务扰动以及工具或API故障（Iannillo，2025；Gupta，2026）。更广泛地说，最近的一项关于真实世界智能体系统维护的基准测试发现，最先进的软件工程智能体仅解决了所研究问题中的0.67–4.67%（Rahardja等人，2025），这凸显了修复智能体特定故障的难度。这些工作确立了在压力下测试和维护智能体的重要性，但对诊断跨异构工具、模型、护栏和智能体间边界的故障提供的支持有限。

与此同时，故障归因研究表明，诊断智能体系统本身就具有挑战性。现有研究对多智能体系统中反复出现的行为故障模式进行了分类，并使用反事实回放和程序化扰动等技术来识别长轨迹中导致故障的智能体和步骤（Cemri等人，2025；Zhang等人，2025）。这条研究路线主要将故障归因于智能体动作或推理行为（Deshpande等人，2025；Epperson等人，2025；Wang等人，2026a；Zhu等人，2025；Mazhar等人，2026）。它并未直接解决本文考虑的补充性运行问题：给定智能体执行的遥测数据，检测器能否区分正常行为与外部引起的运行时故障、识别故障类型并定位受影响的系统组件？回答这个问题需要具有受控故障的执行、系统级遥测数据以及独立于检测器对最终答案解释的真值。

我们提出了**AgentChaosBench**，一个用于评估基于LLM的智能体系统可诊断性的故障注入基准测试¹。我们使用源自AI-NativeBench（Wang等人，2026b）的智能体应用作为可执行负载，并在其执行的多个边界注入故障，包括工具调用、LLM调用、护栏以及智能体间交互。每次运行都使用本地部署的LLM执行，并通过Langfuse进行插桩以捕获其分布式追踪，包括智能体、模型和工具的span及其时序、输入、输出和状态元数据。故障注入标记和标签在诊断前被移除；注入的故障类型和受影响的位置作为真值单独保留。

生成的基准测试涵盖五个异构智能体系统和十种故障类型（包括工具失败、工具或智能体间延迟过高、上下文溢出、工具输出损坏、工具和智能体错误路由，以及护栏绕过），外加一个无故障对照组，共计275次受控执行，其中故障执行和无故障执行针对相同输入进行对齐。该基准测试将诊断表述为两个相关任务：故障类型分类和定位负责的span或组件。由于明确的故障和细微的语义损坏存在于同一分类体系中，该基准测试既测试对错误信号的直接识别，也测试对执行追踪的上下文推理能力。其保留的标签和紧凑的预测格式也支持基于LLM和非LLM诊断方法的可复现比较。第一组LLM基线模型表明该任务远未解决：参数高达140亿的本地检测器在十种故障类型上的最高1项准确率仅在13.6%–19.2%，即使前沿的DeepSeek-v4-pro模型也仅达到24.8%。组件定位仍然不可靠：最高1项准确率仅达到31%，同时正确获得类型和位置的准确率仅为8–22%。与可信度最相关的参考依赖型故障（尤其是被绕过的护栏）即使对于前沿模型，从单条追踪记录来看也几乎无法解决。对齐的无故障参考记录将上下文溢出的召回率提高了最多55个百分点，并有助于检测某些延迟和路由故障，但其效果因故障类型而异，并且被绕过的护栏问题仍未解决。

总之，本文做出了以下贡献：
- • 我们定义并实现了一个面向生产的故障模型，涵盖工具、模型、护栏和智能体间边界。
- • 我们构建了跨越五个系统、十种故障类型以及无故障对照组的275条处理后追踪记录，具有对齐的参考记录和经过验证的类型及位置标签。
- • 我们提供了一个自动化诊断协议和LLM基线，显示了较低的故障类型和定位准确率，以及来自配对参考记录的特定故障增益。

## 2.基准测试设计与构建

智能体系统不是一个单一模型，而是概率语言模型、编排逻辑、本地和远程工具、护栏以及网络服务的组合。现代系统越来越多地通过模型上下文协议连接这些组件以访问工具，并通过智能体间协议进行智能体间通信（Wang等人，2026b）。这种组合使得可靠性成为整个执行过程的属性，而不仅仅是模型或最终输出的属性。因此，确保智能体系统需要检查执行是*如何*展开的，而不仅仅是*产生了什么*。

AgentChaosBench通过受控的故障注入和基于追踪的诊断支持这种形式的分析。我们执行五个异构智能体系统，向其模型调用、工具、护栏和智能体间交互注入故障，并将产生的遥测数据捕获为结构化追踪。诊断方法接收到一条所有注入标记和故障标签已被移除的追踪记录，并且必须对故障进行分类并定位受影响的span或组件。为了使该任务既现实又可验证，注入的故障必须模拟合理的运行时故障，并在收集的遥测数据中产生证据，以支持其分配的故障类型和位置。图1总结了由此产生的流程。

### 2.1.设计目标

基准测试设计遵循六个目标：
- • **与生产相关的故障。** 故障模拟具体的运行时故障（不可达或缓慢的工具、损坏的响应、上下文预算耗尽、延迟或错误路由的委派、被绕过的护栏），而非合成的推理扰动。
- • **覆盖系统组件与交互。** 故障分类法涵盖LLM调用、工具、护栏、单个智能体以及跨多个智能体框架的智能体间通信。
- • **可复现性。** 每个案例都由一组固定的任务输入生成，在受控的注入配置下对本地部署的模型执行，因此结果不依赖于行为可能漂移的专有API。
- • **无真值泄漏。** 直接揭示注入故障的注入标记、故障标签和其他属性从诊断输入中移除；方法只能通过可观测管道获得遥测数据。
- • **基于追踪的标签。** 每个案例都有一个保留的故障类型和受影响的span或组件。质量控制检查验证注入的故障相对于相同输入的对齐无故障运行，在追踪中产生区分信号（§2.7）。
- • **自动评分。** 机器可读的预测格式支持对LLM和非LLM方法进行评分，无需人工仲裁。

表1. AgentChaosBench中使用的选定AI-NativeBench（Wang等人，2026b）工作负载。
### 2.2.智能体系统与任务选择

我们在AI-NativeBench的五个智能体应用程序基础上构建AgentChaosBench（Wang等人，2026b），选择这些应用程序是为了确保基准测试能够检验我们故障分类法所针对的边界。具体而言，我们要求每个选定的系统：（i）使用真实的工具或MCP交互，（ii）通过A2A协议跨智能体委派工作，（iii）产生足够长的多步骤执行以便故障传播，以及（iv）具有确定性的成功条件。我们使用每个系统的异构A2A（H-A2A）变体。在该变体中，由CrewAI、LangGraph和AutoGen实现的智能体通过A2A进行通信，并通过MCP访问外部工具。由于该协议栈对所有五个系统都是通用的，表1显示了在每个工作流中智能体角色如何分配给框架。

### 2.3.部署与执行环境

每个系统部署为一组独立的A2A服务（每个参与智能体一个进程），暴露HTTP/JSON-RPC端点，以及工作流所需的工具和MCP服务器。编排器发布任务输入并驱动工作流直至完成或失败。

为了使执行可复现且不依赖于任何外部LLM提供商，所有智能体都由一个本地部署的模型Qwen3.5-9B提供服务，该模型通过OpenAI兼容的端点托管在vLLM推理服务器后。一次运行中的所有智能体共享此端点，因此相同输入的无故障执行和故障注入执行之间的行为差异可归因于注入的故障而非模型变化。解码采用贪心策略（温度为0），工具调用使用vLLM的Hermes风格解析器。在A2A和工具边界处应用了有界超时和重试，与部署时此类系统的行为方式一致；这些策略本身是检测器必须推理的观测行为的一部分。例如，有界重试使重复尝试在追踪中可见为重复调用。

### 2.4.故障模型

我们的故障模型旨在覆盖主要的运行时故障模式，而非作为详尽的本体。它涵盖了环境可能扰动智能体执行的四种方式：*可用性故障*使工具或A2A调用显式失败（工具失败、A2A超时）；*性能故障*延迟原本有效的交互（工具延迟、A2A延迟）；*控制和路由故障*改变被调用、重复或委派的内容（无限循环、工具错误路由、智能体错误路由）；以及*数据和策略故障*改变交换的内容或执行决策（上下文溢出、输出损坏、护栏绕过）。这些类别共同检验了工具、LLM、智能体、智能体间和护栏边界。它们描述了注入的机制，而非其预期的诊断难度。

表2定义了十种故障类型及其目标边界、旨在在追踪中留下的可观测信号，以及预期的真实值位置。每个输入都配有一个无故障对照。为便于阅读，我们在论文中使用带空格的显示名称（例如，Tool Failure）；发布的标签使用相应的蛇形命名标识符（例如，tool_failure）。我们区分*注入的运行时故障*和*内在的推理错误*：基准测试将故障注入执行环境（工具、委派、护栏、模型I/O），同时保持模型和