多​智​能​体​编排​的​失败​模式

一个反复被验证的观察：把任务拆给多个 agent 之后，系统的失败率往往不降反升。问题几乎从不出在单个 agent 的能力上——单独测试时每个都表现良好——而是出在它们之间的交接上。

失败模式一：转述失真

Agent A 完成调查，把结论转述给 Agent B。每一次转述都是一次有损压缩，而且损失的往往是限定条件：「在测试环境下 P95 延迟约 200ms」经过两次交接变成「延迟是 200ms」。限定条件的丢失比数字错误更危险，因为它让结论看起来依然可信。

工程解法是传引用，不传转述：

# 反模式：结论经过多次转述
result = agent_b.run(f"根据 A 的发现：{summary_by_a}，继续分析")

# 正确：传递原始产物的引用，B 自己读取一手数据
result = agent_b.run(
    task="继续分析延迟问题",
    artifacts=["logs/bench-0621.jsonl", "reports/p95-analysis.md"],
)

任何数字、任何关键判断，接收方必须能追溯到原始来源。转述只用来导航（「去看哪个文件」），不用来承载事实。

失败模式二：责任真空

两个 agent 各自认为边界情况归对方处理，于是谁都没处理。这类问题在单 agent 系统里不存在——它是拆分本身制造出来的新失败面。

解法朴素但有效：任务边界用清单而非自然语言描述。「处理用户输入」是模糊的；「校验编码 / 处理空值 / 截断超长输入，三项全部由你负责」是清晰的。模糊留给人类，清单留给 agent。

失败模式三：验收缺位

最隐蔽的一类：编排者把子 agent 的「我完成了」当成事实。子 agent 报告成功的置信度和任务实际完成与否，相关性远比直觉要低——它可能跑通了一个空壳测试，可能修好了症状而非病因。

子 agent 的产出是待验材料，不是结论。验收这一步省不掉，省掉就是在赌。

验收不需要重做全部工作，但需要独立于产出方的证据：重跑一次关键命令、亲手核对一个数字、抽查一处修改。成本大约是任务本身的十分之一，换来的是整条流水线的可信度。

---

一条主线

三类失败模式其实是同一件事的三个侧面：多 agent 系统的可靠性由信息交接的保真度决定，而不是由单点能力决定。

这和分布式系统的历史惊人地相似——单机性能从来不是难点，难的是一致性协议。Multi-agent 工程正在重演这段历史，而我们还处在「每个团队自己发明土协议」的阶段。下一步值得押注的方向，是交接协议的标准化：结构化的任务契约、可追溯的产物引用、独立验收的原语。谁先把这三件事做成基础设施，谁就定义了这个领域的工程范式。