[Paper] MAS-FIRE：故障注入与基于LLM的多智能体系统可靠性评估

Source: arXiv - 2602.19843v1

概述

大型语言模型（LLM）驱动的多代理系统（MAS）正成为解决复杂、分布式任务的强大方式——比如自主研究助理、协同代码生成器或 AI 驱动的运维团队。然而，由于这些代理之间使用自由形式的自然语言而非严格的 API 进行交流，细微的“语义”错误（幻觉、指令误解、推理漂移）可能悄然累积，导致整个工作流崩溃。论文 MAS‑FIRE 引入了一套系统化的故障注入框架，使工程师能够有意注入并研究这些失败，首次提供了对 MAS 成功或失效的细粒度视角。

关键贡献

• 故障分类 – 15 种不同的故障类型，涵盖 内部代理 的认知错误（例如幻觉、推理漂移）以及 跨代理 的协同失误（例如消息丢失、路由交换）。
• 非侵入式注入机制 – 三种在不修改源代码的情况下破坏运行中多智能体系统（MAS）的方法：
  1. 提示修改（篡改系统提示或用户提示）
  2. 响应重写（后处理 LLM 输出）
  3. 消息路由操控（在代理之间洗牌或丢弃消息）
• 分层容错分类 – 四层层级结构（机制 → 规则 → 提示 → 推理），阐释 MAS 如何从故障中恢复。
• 实证评估 – 将 MAS‑FIRE 应用于三种代表性 MAS 架构（线性流水线、层级管理‑工作者、以及迭代闭环），揭示了系统性稳健性和脆弱性的模式。
• 模型 vs. 架构的洞察 – 更强大的基础 LLM 并 不 能保证更高的可靠性；拓扑结构（例如迭代反馈回路）可以中和 >40 % 的致命故障，这些故障会使线性流水线瘫痪。

方法论

1. 定义故障空间 – 作者列出了在真实部署中观察到的 15 种实际故障模式（例如 “代理产生了不存在的文件的幻觉”， “管理者错误路由子任务”）。
2. 注入故障 – 通过三种注入钩子，他们以编程方式修改提示、重写 LLM 响应，或在 MAS 执行原始任务时打乱消息图。这 不需要对代理本身的代码进行任何更改，使该方法可用于黑盒服务（OpenAI、Anthropic 等）。
3. 运行基准任务 – 使用了三个典型的 MAS 工作负载：
   • (a) 多步骤数据分析流水线
   • (b) 分层计划‑执行场景
   • (c) 迭代自我调试的代码生成循环
4. 观察并分类结果 – 对每个注入的故障，他们记录系统是否：
   • (i) 崩溃（任务直接失败）
   • (ii) 通过更高层机制恢复（例如，管理者重新发出提示）
   • (iii) 降级（部分成功）

这些结果被映射到四层容错模型上。整个流程实现了自动化：定义故障、选择注入点、运行 MAS，并收集日志以揭示 过程级 可观测性（谁说了什么、何时说以及系统如何响应）。

结果与发现

• Model size matters, but not uniformly – Switching from GPT‑3.5‑turbo to GPT‑4 reduced hallucination‑type faults by ~15 % but increased reasoning‑drift failures because the larger model generated more elaborate (and thus more fragile) reasoning chains.
• Topology trumps raw capability – The iterative design outperformed the stronger model baseline, showing that architectural safeguards (e.g., verification steps, looped feedback) are a more reliable path to robustness.
• Tiered recovery patterns – Most successful recoveries happened at the prompt tier (re‑issuing a clarified instruction) or rule tier (manager applying a sanity‑check rule). Pure reasoning‑level fixes were rare, suggesting that explicit guardrails are more effective than hoping the LLM will self‑correct.

Practical Implications

• Design‑for‑observability – 当构建 MAS 时，公开消息图（谁与谁通信，内容是什么），以便像 MAS‑FIRE 这样的故障注入工具能够挂接。简单的日志中间件即可满足需求。
• Add verification layers – 在 rule 层实现轻量级规则检查器（例如，“引用的文件是否真的存在？”），以在幻觉蔓延前捕获错误。
• Iterative feedback loops – 即使是一个适度的 “不确定时再次询问” 子例程，也能显著提升系统韧性；考虑在每个代理输出后加入 “自审” 步骤。
• Don’t rely on bigger LLMs alone – 投入更强大的模型可能收效甚微，除非你也重新设计协同拓扑结构。
• Automated reliability testing – MAS‑FIRE 可集成到 CI 流水线：注入一套故障，运行 MAS 完成代表性任务，并断言在发布前失败率保持在阈值以下。

限制与未来工作

• 故障类型范围 – 15 类故障分类虽然全面，但仍是手工构建的；一些特殊领域的故障（例如安全策略违规）未被覆盖。
• 评估范围 – 实验仅限于三个 MAS 原型和少量基准任务；更大规模的行业工作负载（例如多代理 DevOps 编排）仍需研究。
• 非侵入式注入开销 – 当前的钩子会增加延迟（提示重写、消息洗牌），可能影响对时间敏感的系统；未来工作可以探索更高效的注入点。
• 自动化缓解合成 – 论文对现有恢复行为进行分类，但尚未提出自动生成新防护措施；将 MAS‑FIRE 扩展为能够建议规则或提示修复是一个开放方向。

作者

• Jin Jia
• Zhiling Deng
• Zhuangbin Chen
• Yingqi Wang
• Zibin Zheng

论文信息

• arXiv ID: 2602.19843v1
• 分类: cs.SE, cs.AI
• 发表时间: 2026年2月23日
• PDF: 下载 PDF