OrchestraBench：评测多智能体编排的故障模式、恢复能力与任务分解质量
OrchestraBench: Evaluating Multi-Agent Orchestration Failure Modes, Recovery, and Decomposition Quality

多智能体编排框架正从演示阶段走向生产环境，但现有基准通常只报告任务准确率，无法说明流水线为何失败、级联故障从哪里开始、哪个路由决策导致了系统性崩溃。缺乏这种归因能力，团队就无法针对性地改进路由策略或容错机制。

OrchestraBench 基于种子可复现的故障注入框架，在模板化的企业工作流上系统评测故障、恢复与任务分解质量，引入"级联半径"（cascade radius）和"分故障模式恢复率"作为核心指标，并用bootstrap置信区间和配对检验比较不同路由策略。作者还用真实Claude agent，在可验证的算术依赖链上做受控机制探针实验，覆盖MAST定义的五种故障模式，并将同一计算任务改写为贷款审批工作流以验证结论的稳健性，同时在Sonnet、Opus、Haiku三种模型上重复实验。

在26个人工标注的诊断案例上，关键词/标志位路由器在表面标志误导或缺失的对抗性案例中得分0%，而基于意图推理的模型路由器得分100%，与oracle持平，说明路由决策的鲁棒性高度依赖于是否具备语义理解能力，而非简单的规则匹配。

五种MAST故障模式呈现三个恢复梯队：工具故障可完全恢复（恢复率1.0），模糊委派部分恢复（0.30），三种潜在或语义类故障完全无法恢复（0.0）——这一排序在贷款审批场景重构后依然成立，且在Sonnet、Opus、Haiku三个模型间保持一致（绝对数值随上下文变化）。级联半径随流水线深度增加而增长（深度3到7对应均值从0.9升到4.7）。盲目重试会复现潜在故障并延长检测时间，说明容错的前提是先具备检测和归因能力。一项"可信状态修复"消融实验表明，此前观察到的遏制效果主要来自可信状态信号本身，而非系统的自主检测能力。

这篇论文对duplex/实时agent交互的参考价值在于它把"路由决策的语义理解能力"和"故障恢复的可检测性"分离出来单独度量——这与全双工场景中turn-taking决策（该不该打断、该不该切换意图）本质上是同一类"路由"问题：关键词/规则式路由在对抗性/歧义输入下会系统性崩溃，唯有语义级理解才能维持鲁棒性。更值得警惕的是"潜在或语义类故障完全无法恢复"这一发现——如果把这个结论迁移到duplex agent的Interaction Layer与Thinking Layer协同场景，意味着一旦两层之间出现语义层面的状态不一致（而非显式工具报错），当前的多智能体架构可能同样缺乏自愈能力，这是一个值得后续研究直接检验的假设。论文本身的局限也很诚实：作者明确声明这些是"受控链条的机制探针"而非"领域工作负载层面的结论"，外推到真实生产系统时需要谨慎。