在实践中，我们的多智能体失败几乎从来不是模型的问题——而是交接环节的问题。MAST数据是否符合您的观察？

我一直在构建和调试多智能体流水线（编排+工具使用），并不断遇到同一个障碍：一次运行失败后，有人更换模型或增加上下文窗口，它通过了一次，然后在其他地方失败。我们一直把协调问题当作能力问题来处理。伯克利MAST论文（《为什么多智能体LLM系统会失败？》，arXiv:2503.13657）与此一致。他们手动注释了7个框架中的1600多个执行轨迹（6名注释者，Cohen's Kappa系数0.88），并将失败分为3类：- 规范与设计：41.8%（糟糕的分解、角色模糊、无终止条件）- 智能体间不一致：36.9%（交接时上下文丢失、输出冲突、格式不匹配）- 验证：21.3%（过早的“完成”、不完整或错误的检查）评估方面更棘手：各种2026年的审计报告显示，LLM裁判超过一半的时间是错误的，存在位置偏差（偏向第一个答案）和长度偏差。而且pass^k方差非常严重——同一智能体在4次运行中，pass^4的得分可能比pass^1低15-25分。所以一次绿色运行说明不了什么。我的看法：大多数“增加另一个智能体”的修复方案会让情况更糟，因为它们增加了更多的接缝，而不是减少。我发现最被低估的修复方案是使用一个专用验证智能体，它具有独立的上下文和评分标准，生产智能体从未见过——基本上将验证视为一个独立阶段，就像安全流水线中的独立扫描器。