让两个模型吵一架，再用第三个裁决——我把多 AI 协作磨成了五种模式，六轮真实测试修出七个 Bug

Bayze
5 阅读4分钟

上一篇文章里，Bayze 还只是一个「草稿→评审→修订」的瀑布工作流引擎。三个月迭代到 v0.14，它已经有了五种多 AI 协作模式——而这五种模式里最有趣的 debate（辩论），是被六轮真实测试硬生生磨出来的。这篇文章记录全部过程，包括每一次翻车。

一、为什么「多模型」不等于「效果更好」

先泼冷水。我们把所有主流协作模式各跑了真实任务，结论浓缩成一张表：

模式机制实测成本什么时候真的有用
waterfall 复核A 起草→B 结构化评审→按需修订~$0.001/次高质量档位的默认选择
parallel + 评委N 模型并行答→评委按硬约束选优$0.0013/次带硬约束的任务（字数/格式）
MoA 聚合N 模型答→强模型合成一份$0.006/次开放生成（无长度上限）
修订循环+升级评审打回→循环修订→用尽换强模型$0.002/次升级初稿不稳的复杂任务
debate 辩论双方交锋 K 轮→裁决者终审$0.02-0.04/次分析/决策/风险评估

关键发现是模式与任务的匹配比模式本身更重要：

  • 带字数上限的任务，MoA 必然超标（两次实测 +59%、+74%——「重写型步骤天然写长」，和修订步 1.66 倍膨胀是同一族现象）；评委选优反而天然守住（选短的那版就行）
  • 开放生成任务正相反：选优只能拿到「两版中较好的一版」，合成才能取两家之长

二、五个字数教训：不要相信任何模型报的字数

六轮测试里我们攒了五个样本：

  • qwen-plus 自报「exactly 10 words」，实测 14 词
  • qwen-plus 自报「约 580 字」，实测 799 字
  • claude-haiku 少报 1~38 字（历史数据）
  • ……

没有任何一个模型的自报字数可信。所以 Bayze 的做法是：字数约束一律交给引擎的确定性检查（max_chars / max_words），模型说什么都不算数。配置长这样：

steps:
  - name: deepseek
    provider: deepseek
    model: deepseek-chat
    input: original
    timeout_ms: 60000
    evaluate: [non_empty, { max_chars: 4000 }]   # 引擎数，不信任模型

三、debate 六轮实战：一部 Bug 发现史

这是全文最重要的部分。strategy: debate 的设计很简单：两个模型就同一个问题各自开场、互相反驳 K 轮、第三个模型裁决。听起来很美，六轮真实测试的完整翻车记录如下。

第 1-2 轮：两个「看不见」的 Bug

第一轮直接超时，第二轮双方开场全部超长被拦。深挖发现：

  1. context 字段被静默丢弃——MCP 层接收了用户补充约束，编排器直接扔掉。测试 AI 抱怨「我的约束被模型无视」，真相是约束根本没到模型手里。
  2. token 预算与字符闸门自相矛盾——maxOutputTokens: 2000 允许模型写 ~3000 字，而 max_chars: 2000 在 2000 字处拦截。引擎允许模型写到必然被自己拒绝的长度。

第 3 轮：机制全部跑通，新的东西开始浮现

五个步骤（开场×2→反驳×2→裁决）全部执行，反驳质量出乎意料地好——逐条引用对方论点、抓住 qwen 自相矛盾的地方（一边承诺 RPO<5s 一边自曝主从切换要 3.2 小时）、双方各有让步和自我修正。跨模型辩论确实能暴露单模型的盲区。

但裁决写超了，被字符闸整段丢弃——那一次裁决花了 $0.021，占整次运行成本的 90%。

第 4-5 轮：三个「玄学」问题的工程答案

  • 单方开场=整场迷你辩论：模型把「开场/反驳/裁决」的纪律当成了自己的作业结构，一个人把整场辩论演完。修复：开场提示词明确「只写己方立场，禁止模拟对方/反驳/裁决」。
  • token 封顶的换算常数陷阱：我们按 1.4 字/token 限制输出，结果 Claude 中英混合输出实测 2.43 字/token——572 token 封顶精确地产出了 1392 字。固定常数追不上各家 tokenizer，最终方案是自校准：首次调用实测字/token 比率，超闸后用它精确钳住压缩重试的上限。
  • qwen 编造「我们核查过该团队真实账单（脱敏后）」——工作流根本没有渠道接触任何账单。还有「实测 QPS=42」「复现了其测试环境」「Git 提交记录显示…」全是臆造。修复：裁决提示词加入编造折扣条款——无法验证的量化论据一律折扣，疑似编造须点明。

第 6 轮：同向锚定——最后一个设计缺陷

裁决终于完整交付了，但发现双方模型站在同一边（都主张「值得迁移」）。用户第二轮试图显式分派正反方——无效，因为两个步骤拿的是同一份输入，立场没有注入入口。「立场自然涌现」在开放分析题上有效（双方真的吵起来过），在是非题上会让两个模型锚定同一结论。

修复：可选的 stances 立场指派：

strategy: debate
judge: { provider: anthropic, model: claude-sonnet-4-5, evaluate: [{ max_chars: 1200 }] }
rounds: 1
stances: ["支持：应当执行任务中提议的方案", "反对：不应当执行"]
steps:
  - { name: deepseek, provider: deepseek, model: deepseek-chat, ... }
  - { name: qwen, provider: dashscope, model: qwen-plus, ... }

注入原则写在提示词里：按指派立场尽力论证，但绝不编造证据。

四、辩论裁决的真实产出（节选）

拿一个真实问题测的：「8 人创业团队，12 个月内从云厂商全家桶整体迁移到自托管值不值得」。两轮辩论+裁决的合并结论：

不建议 12 个月内整体迁移。建议：留在托管云+议价+只对「便宜且标准」的组件择机局部迁移。

  • 算术不成立：8 人团队需新增 0.5-1 个 SRE，省下的钱不到半个人
  • AI 服务是最后该动的：专有模型+托管 RAG+半年一迭代，自建 GPU 沉没成本最高
  • 12 个月的正确用法：把切换成本降到可承受（容器化+S3/PG 兼容+流量型支出先挪），拿「我有替代方案」去谈折扣

注意：双方模型给出的所有金额数字都是编造的（裁决已点名排除）——这份结论可取的是决策框架和风险清单，真实决策要用你自己的账单算。这也是六轮测试最重要的元结论：模型的量化论证不可直接采信，跨模型对抗+裁决折扣只是把「不可信」变得可见了。

五、怎么玩

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

配置示例和五种模式的完整文档在 GitHub README（中英双语）：

MIT，本地运行，密钥只走环境变量，193 项测试全绿。如果你也在做多人 AI 协作的编排，欢迎来聊——特别是「你的模型编过什么数据」这个话题，我们攒了一打案例。

avatar
文章
阅读
粉丝