多模型协作怎么选：五种模式的实测

让两个 AI 辩论，再请第三个裁决，能比单模型更可靠吗？bayze-mcp 作者跑了 6 轮真实测试，修复了 7 个问题，得到的答案有条件：对抗式审查能揭露盲点，但流程必须先管住输入、长度、角色和证据。

这份调试记录值得读的地方，是它把多模型协作里的失败摊开了：约束被程序丢掉、裁判超长导致结果作废、双方站到同一边，以及模型编造账单。对想搭 AI 工作流的程序员，这些比一场漂亮演示更有用。

先选协作方式，再纠结模型强弱

3 个月前，bayze-mcp 还是一条流水线：model A 起草、model B 审查、model C 修改。现在它提供 5 种多模型协作模式，但原文没有逐一介绍全部模式，重点比较了聚合、候选裁决和辩论。

作者最有价值的发现是：任务与协作方式是否匹配，比模型质量更关键。

有硬性长度限制时，MoA 聚合在两次运行中分别超出上限 +59% 和 +74%。聚合需要重写，而重写往往让内容越写越长；作者此前测到的修改步骤，长度也膨胀到了 1.66×。

裁判从已有候选中挑选，更容易保留符合长度限制的版本。但开放式写作又有另一种需求：挑选只能交付两稿中较好的一个，综合生成才有机会吸收两边的优点。

这组数据支持的是流程取舍，不能据此宣布某种模式全面胜出。

为什么字数限制必须由程序执行

作者在 6 轮测试中列出了 5 个计数样本。例如，Qwen-plus 声称「恰好 10 个词」，实际有 14 个；声称「约 580 字符」，实际有 799 个。Claude haiku 在早期运行中也少报了 1–38 个字符。

因此，bayze-mcp 用引擎确定性执行 max_chars / max_words 检查，不采信模型自报的长度。

但只在出口拦截还不够。第 1–2 轮发现，maxOutputTokens: 2000 可以放出约 3000 字符，而 max_chars: 2000 又会拒绝超过 2000 字符的结果。生成预算和验收条件彼此打架，模型正常完成也可能交不了差。

另一个问题更隐蔽：MCP 层接受了 context，编排器却悄悄把它丢了。测试代理抱怨约束被忽略，根因在调用链。

到第 4–5 轮，固定按 1.4 chars/token 推导 token 上限的办法又失效了：Claude 的中英混合输出达到了 2.43 chars/token。作者改为首调测量实际比例，再据此收紧压缩重试的预算。原文没有给出这套校准在更多任务上的成功率。

约束要进入执行逻辑，不能只停留在提示词里。

三个模型开会，也会一起编造证据

测试题是：一个 8 人创业团队，是否应该在 12 个月内迁出某云厂商的全套服务？

第 3 轮终于出现了有效交锋。双方逐点引用对方，一方抓住另一方同时承诺「RPO < 5s」和承认「主节点故障切换耗时 3.2 小时」。RPO 衡量可接受的数据丢失时间，切换耗时衡量恢复速度，两者不是同一个指标；这里需要追问的是整套承诺是否有架构与证据支撑。

随后裁判输出了 786 字符，超过 600 字符门槛，整份裁决被丢弃。这次裁判调用花了 $0.021，占整轮成本的 90%。前面的讨论即使有用，最后一个出口失败，照样无法交付。

第 4–5 轮还暴露出角色失控：模型把 opening / rebuttal / verdict 当成自己的完整任务，一次演完全部辩论。修复办法是在 system prompt 中限定每一方只负责自己的立场。

更严重的是，Qwen 编造了「审计过该团队真实账单」、基准测试和 Git 历史。工作流根本没有访问这些资料。作者于是要求裁判降低不可核验定量主张的权重，并在裁决中点出疑似捏造。

第 6 轮，双方又一致支持迁移。给角色贴上正反方标签仍无效，因为两个步骤收到相同输入，流程没有注入立场的位置。作者增加了可选的 stances: [pro, con]，同时要求尽力论证指定立场，但不得为此编造证据。

最终裁决建议放弃 12 个月全量迁移，先降低退出成本：容器化、采用兼容 S3/Postgres 的接口、优先迁走流量开支大的部分，AI 服务最后考虑。

裁决还估计自托管需要 0.5–1 FTE 的 SRE 投入，但这仍不能当成普遍测算。作者明确承认，两边模型产生的所有美元金额都是编造的，已被裁判排除。能留下的是决策框架和风险清单。

我的判断

我认可作者把协作失败当成工程问题处理：输入是否传到、角色是否隔离、输出是否合格，都能检查，比反复调整语气更可控。

但「多模型辩论更可靠」仍是经验之谈。原文没有提供同题单模型、普通审查和辩论模式的完整对照数据，也没有证明第三个模型能稳定识别前两个模型的虚构。它展示了暴露问题的能力，尚不足以证明最终答案更接近事实。

对普通团队，我会先考虑候选生成加程序校验，或者单独安排一次审查。只有问题确实存在取舍、且值得承担额外调用成本时，再引入辩论。对账单、性能和迁移收益，接入真实资料比增加发言席位更直接。

能拿来做什么

• 在 Node 编排服务里检查 context 等字段是否完整传递，并由程序执行 max_chars / max_words 校验；字符和单词的计数口径也要事先明确。
• 为方案评审注入明确立场，同时要求模型区分已知事实、估算和待核验信息；涉及账单、基准测试或 Git 历史的结论，应回到真实资料验证。
• 单独记录裁判阶段的成本和失败原因。原文中一次超长裁决就消耗整轮 90% 的费用，最终出口值得优先检查。
• 想复现可从下列命令启动。项目自述采用 MIT、local-first，密钥留在用户环境，并有 193 项自动化测试；模式取舍记录在 docs/adr/0006-multi-ai-collaboration.md 的 ADR D1–D8 中。

npx -y bayze-mcp@0.14.0 mcp --config your-config.yaml