Paper Notes: Why Do Multi-Agent LLM System Fail?

• MAST-Data: 是第一个概述MAS故障动态的多代理系统数据集，以指导更好的未来系统的开发。
• Build the first Multi-Agent System Failure Taxonomy(MAST)。
• 整个过程分成14种不同的失效模式，聚为3类。：
  • 系统设计问题
  • 智能体间错位
  • 任务验证
• 开发一个与人类注释高度一致的 LLM-as a-Judge 的 pipline
• 发现MAS任务失败的原因大多数还是系统设计问题，并非简单的 prompt 和 LLM limitations 所能概括的。

Some challenges

• long-horizon web navigation: Agent Workflow Memory, introduces workflow memory.(Agent workflow memory, 2024. URL https://arxiv.org/abs/2409.07429.)
• Programming agentic flows: DSPy(https://arxiv.org/abs/2310.03714)
• Task-solving capabilities: StateFlow state control

The Principles for Agentic System

• Anthropics’s blog: https://www.anthropic.com/research/building-effective-agents
• Kapoor等人证明了过于复杂的协议如何阻碍系统的正常运行。Ai agents that matter, 2024. URL https://arxiv.org/abs/2407.01502

MAST-Dataset

• 确定故障的缘由需要理解系统动态，不单单只是简单的检测。
• 缺乏具有明确定义的标准化框架，使识别和分类不同系统的MAS故障不一致，这使注释和跨系统分析复杂化。
• 数据的收集是遵循 Grounded Theory Analysis（看不太懂里面的逻辑，简单说应该就是人类专家从几个MAS中获取失败样本轨迹，）
  • 这个 GT 理论就是说，在数据收集前完全不会定义任何 failure 的类别
  • Open Coding（开放编码）：就是对原始轨迹逐行标注“发生了什么错误”（人看出来的）
  • Constant Comparative Analysis（持续比较）人来比较各种错误来实现不同 MAS 之间的错误对齐。
  • Theorizing（建模）：最终需要的是 failure mode + 定义 + 边界 + 例子
  • Theoretical Saturation（理论饱和），不再出现新的错误类型。
• 开发失败分类法 MAST 来指导人员构建 MAST-Data 最终讨论形成 IAA 协议。
• 开发 LLM-as-a-Judge 管道作为自动化注释工具。

The Multi-Agent System Failure Taxonomy

三类大故障：

• System Design Issues. 故障源于系统设计决策，以及不良或模棱两可的提示词规范。
  • 应当以最小的高水准目标和清晰的用户输入来缓解这个问题。
• Inter-Agent Misalignment. 故障源于执行过程中代理间交互和协调的关键信息流中断。
  • 最近的系统创新，如模型上下MCP和A2A，通过标准化来自不同工具或代理提供商的消息格式来改善代理通信。然而，即使同一框架内的代理使用自然语言进行通信，我们在FC2中观察到的错误也会发生。这预示着一个更深层次的代理互动动态挑战：“心灵理论”的崩溃，代理无法准确模拟其他代理的信息需求。解决这个问题可能需要对代理消息的内容进行结构性改进，或增强模型的上下文推理及其推断其他代理信息需求的能力，例如通过有针对性的培训，因为基础LLM通常没有针对这种细微的代理间动态进行预先训练。因此，强大的解决方案可能涉及改进的MAS架构和通信智能的模型级进步的结合。
• Task Verification. 故障涉及验证流程不足，无法检测或纠正错误，或过早终止任务。
  • 提前终止，不完整的验证等，导致任务通过了表面测试但是没有深入测试功能。
  • 应当参考传统软件开发的标准。

Towards better Multi-Agent LLM Systems

• 以后补充