MAST: Multi-Agent System Failure Taxonomy/ 多智能体失败模式分类（MAST）——给Agent团队做一次故障解剖

MAST（Multi-Agent System Failure Taxonomy）是伯克利团队从 1600 多条真实多智能体执行轨迹中归纳出的失败分类学——14 种细粒度失败模式、3 大类别，把「Agent 团队为什么搞砸」从一句含糊的「幻觉了」拆成可以标注、可以统计、可以拿来做回归的「故障向量」。

• 三大类别，各占约三分之一 — FC1 规格与系统设计问题（约 42%）：任务或角色说明写得含糊、步骤重复、丢失对话历史、不知道什么时候该停。FC2 智能体间失配（约 37%）：不问澄清就自己猜、任务跑偏、忽略其他 Agent 的输入、推理与动作不一致。FC3 任务验证（约 21%）：过早收尾、压根没做验证、验证做错了（把失败判成成功）。

• 14 种细粒度模式，每一条都有编号 — 例如 FM-1.3 步骤重复、FM-1.4 丢失对话历史、FM-1.5 不知道终止条件、FM-2.2 不主动澄清、FM-2.6 推理-动作不一致、FM-3.1 过早终止、FM-3.3 错误验证。每种模式都有明确定义、典型出现阶段（执行前/执行中/执行后）和对应的缓解建议，可以直接当评审清单用。

• 最高频的三种 — 步骤重复、推理-动作不一致、不知道终止条件。这三类合计占了失败的大头，而且都不是「模型不够强」导致的。

• 最重要的结论 — 多智能体系统的主因是组织问题，不是认知问题。论文在 7 个主流框架上实测，失败率高达 41% 到 87%；换更强的模型并不能自动消掉这些模式，得改系统设计、角色定义和协作协议。

• 可规模化的标注 — 人工标注者之间的一致性 Cohen's Kappa 达到 0.88，用 LLM-as-Judge 自动标注与人工的一致性为 0.77。也就是说这套分类可以脱离人工，跑批量回归。

1. 先看真题，摸清分布 — 从 HuggingFace 拉取 MAST-Data 数据集（repo_id 为 mcemri/MAD，文件 MAD_full_dataset.json），里面是带 14 类标注的真实执行轨迹，每条平均上万行。

操作：pip install huggingface_hub，用 hf_hub_download 取回后按失败模式编号做频次统计，先看哪些模式在你们关心的任务域里最常见。

1. 把你们自己的 Agent 轨迹套进官方标注器 — 导出 Agent 的完整 trace（system prompt、每一轮的输入输出、工具调用名与返回值、结束原因）为 JSON，喂给仓库里的 MAST LLM annotator 提示词，让裁判模型输出这一轮任务命中了哪几个 FM 编号。

操作：先用 20 条轨迹跑通，确认裁判输出的编号人工看得懂，再铺量到全量回归集。

1. 做一次消融对照 — 固定一套 20 到 50 条回归集，分别跑改动前和改动后两版 Agent，比较失败模式占比的变化。

示例：加了「终止条件显式检查」后 FM-1.5（不知道终止）的占比应明显下降；加了「主动澄清」策略后 FM-2.2 应下降；如果加了严格终止反而让 FM-3.1（过早终止）上升，说明用力过猛。

1. 评估指标（每次加固都要一起上报）

• 任务成功率：端到端完成的条数 / 回归集总条数

• 失败模式命中率：某个 FM 编号出现的轨迹数 / 总轨迹数，并按三大类汇总

• 单类占比变化：Δ占比，用来回答「这次加固到底打掉了哪一类失败」

• 标注一致性：抽 20 条人工双盲复核，算与 LLM 裁判的 Kappa，目标不低于 0.7（论文里 o1 裁判是 0.77）

• 回归率：加固后新引入的失败模式数量，防止修好一个坑掉进另一个坑

1. 没有多智能体也能用 — 单 Agent 同样会犯步骤重复、不知终止、过早终止这几类错误，三大类别照样适用。可以先在单 Agent 上把标注流程和指标口径跑通，再等系统复杂化。

用到的工具与平台：

• MAST 官方代码与标注器: https://github.com/multi-agent-systems-failure-taxonomy/MAST

• MAST-Data 数据集: https://huggingface.co/datasets/mcemri/MAD

• MAST 项目主页: https://sites.google.com/berkeley.edu/mast/home

1. 把「失败」定义成「答案答错了」 — MAST 里大量失败轨迹的最终答案是正确，但过程绕了远路：反复重复同一步、来回澄清好几轮、工具调用与推理对不上。只测最终答案准确率会漏掉一大半问题。做法是过程指标（步数、重复调用次数、澄清轮次）和结果指标同时记录。

1. 拿论文里的失败率当自己的基线 — 41% 到 87% 这个区间来自不同框架、不同任务、不同模型，直接引用到汇报里站不住脚。正确用法是只在「你们自己的固定回归集 + 你们自己的 Agent 版本」之间做纵向比较，论文数据只作为「这个问题普遍存在」的佐证。

1. 标注颗粒度不统一 — 同一段轨迹，有人标成 FM-1.3（步骤重复），有人标成 FM-2.6（推理-动作不一致），统计出来的分布就没法用。做法是先用 20 条做双人标注校准，Kappa 到 0.8 再铺量；LLM 裁判只在人工已经校准过的类别上使用，不要拿它当唯一裁判。

• MAST 论文（Why Do Multi-Agent LLM Systems Fail?）: https://arxiv.org/abs/2503.13657

• MAST 官方代码、数据集与 LLM 标注器: https://github.com/multi-agent-systems-failure-taxonomy/MAST

• MAST 项目主页（14 种失败模式完整定义）: https://sites.google.com/berkeley.edu/mast/home

• MAST-Data 数据集: https://huggingface.co/datasets/mcemri/MAD

• IBM 用 MAST 诊断企业级 Agent 基准 ITBench 的实践案例: https://huggingface.co/blog/ibm-research/itbenchandmast