第40回　多智能体翻车记——失败模式、根因与止血法

人多未必就稳当，众口也能酿迷汤。
若无规矩来收口，越帮越忙更心慌。

第39回我们唱了协作的好：分工、拓扑、共识。
可看官都明白：
江湖从来不缺“看起来很合理的系统”，缺的是“摔过跤还能爬起来的系统”。

这一回专讲翻车。

有一篇 2025 年的研究专门做了系统性失败分析：
他们观察多个流行多智能体框架在 150+ 任务上的执行轨迹，归纳出 14 种失败模式，并把它们聚成三大类：

  • 系统设计问题
  • 智能体之间的不对齐
  • 任务验证与终止问题

并且给了可扩展标注与评估工具链（LLM-as-a-Judge）以及数据集。1

你不必背 14 条清单，先把“三大类”钉牢；
遇事能定位到“是哪一类在作妖”，才是工程本事。

一、三大类失败：像三种“病根”

1）系统设计问题：规矩没立，系统先乱

常见表现：

  • 角色说明不清：谁负责什么、谁能改最终输出，没写死
  • 对话管理混乱：消息太多、摘要太差、关键约束丢了
  • 工具与环境没隔离：权限不清、超时不管、错误不处理

这类失败不是模型“笨”，是系统“没骨架”。
第38回的状态机、审计与回滚，就是专治这一类。

2）智能体不对齐：各唱各的调

常见表现：

  • 协作目标不一致：有人追速度，有人追完美，互相拖拽
  • 信息不对称：一个代理掌握关键证据却没传出去
  • 互相误导：自信的错误在群体里扩散，变成“共识幻觉”

你把它当成团队协作就懂：
目标不对齐，会议开到天亮也没结果。

3）验证与终止问题：没有“验收”，就没有“完成”

常见表现：

  • 明明错了却以为对：缺验证门槛
  • 明明做完了还在做：缺终止条件
  • 一步错步步错：缺关键节点检查，错误滚雪球

第38回讲的“选择性验证”与“可验证执行”，就是给这一类装刹车。

二、14 种失败模式该怎么用：当成“排障索引”

工程里最怕两种对话：

  • “它又坏了。”
  • “我也不知道为什么坏。”

失败模式清单的真正价值不是论文炫技，而是把排障变成“可复用流程”：

  1. 把一次失败写成一条轨迹（谁说了什么、谁调用了什么工具）
  2. 标注它属于哪类失败（系统设计 / 不对齐 / 验证终止）
  3. 再细到具体模式（例如：角色冲突、对话漂移、过早终止……）
  4. 对症下药：改提示、改拓扑、加验证、加回滚、加隔离

这就像高二数学的错题本：
不分类，你永远在“重新学”；分类了，你才在“修弱点”。

三、止血三件套：把系统从“能跑”变成“能控”

把前几回串起来，止血法可以归成三件套：

  1. 骨架：状态机/工作流，把流程写死（第38回）
  2. 边界：角色权限与责任边界写死（第39回）
  3. 刹车：关键节点验证与终止条件写死（第38回）

多智能体系统若没这三件套，通常会出现一个现象：
“看起来努力得要命，结果离目标越来越远。”

四、极简可跑代码：用日志把失败粗分到三大类

下面代码不是要“自动判案”，只是演示一个工程做法：
把执行轨迹的关键事件（角色、动作、错误、验证结果）写成日志后，至少可以做粗粒度定位：

  • 是否缺验证（VERIFY 缺失或频繁失败）
  • 是否角色冲突（角色互相否定/改写）
  • 是否系统层错误（超时/权限/工具失败高发）
def classify(log):
    has_verify = any(e["type"] == "VERIFY" for e in log)
    verify_fail = any(e["type"] == "VERIFY" and not e["ok"] for e in log)
    tool_errors = sum(1 for e in log if e["type"] == "TOOL" and e.get("error"))
    conflicts = sum(1 for e in log if e["type"] == "MSG" and "不同意" in e.get("text", ""))

    if not has_verify or verify_fail:
        return "任务验证与终止问题"
    if conflicts >= 2:
        return "智能体之间的不对齐"
    if tool_errors >= 2:
        return "系统设计问题"
    return "难以粗分（需要更细标注）"


if __name__ == "__main__":
    trace = [
        {"type": "MSG", "role": "Planner", "text": "先检索，再写草稿，再验证。"},
        {"type": "TOOL", "name": "search", "error": "timeout"},
        {"type": "TOOL", "name": "search", "error": "timeout"},
        {"type": "MSG", "role": "Writer", "text": "我先凭记忆写一个。"},
        {"type": "VERIFY", "ok": False},
    ]
    print(classify(trace))

这段代码的意义在于提醒你：
多智能体的改进不能只靠“换更大模型”，你必须能：

  • 记录轨迹
  • 标注失败
  • 对症修复

否则你永远在“感觉它不稳”，而不是“知道它哪里不稳”。

五、小结：失败分析不是泼冷水，是把路修平

多智能体不是银弹。
它更像“多线程程序”——
性能可能更强，但 bug 也更隐蔽。

你想把系统做稳，最有效的顺序是：

  • 先把单体做成可控工作流（第38回）
  • 再把群体做成有边界的协作（第39回）
  • 最后用失败模式做系统化排障与迭代（本回）

第四篇到此，图与智能体的主线已从“结构”走到“执行与协作”。
后面章节若继续扩展，就可以更深入：

  • 更细的验证器设计与成本权衡
  • 多智能体在软件工程、科研与产品场景的专门策略

欲知后事如何，且听后文分解。

幻觉核查

  • “14 种失败模式、三大类归因、LLM-as-a-Judge 与数据集发布”：可核对论文摘要与方法概述。1
  • 本回对三类失败的工程解释属于概括性总结，具体 14 模式的命名与边界以原论文定义为准。
  • 本回代码是“粗分定位”的玩具示例，不应当被当作真实评估器。

逻辑审计

  • 与第39回衔接：第39回讲“协作机制”，本回讲“机制为何失效”，把系统工程的风险补齐。
  • 与导读一致：导读强调“慢思考与自校验”，本回把“自校验”扩展为“系统化诊断与迭代”，避免把错误当偶然。
  • 与第38回闭环：失败一旦可归类，就能决定该加状态机、加验证、还是改拓扑与角色边界。

引用与溯源

Footnotes

  1. Cemri, M., et al. Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657 (v1: 2025-03-17) https://arxiv.org/abs/2503.13657 ↩ ↩2

← 多智能体协作——分工、辩论与协调算法 后 Transformer 时代——SSM、Mamba 与线性注意力 →