问一个模型做计划——迁移、重构、切换——你会得到一个流畅、自信的回答。
流畅不等于正确。 一个模型独立采样一个分布，房间里没有对手，它会把第一个猜测合理化成计划。
用 coding agent 时最贵的失败几乎从来不是语法问题。而是计划读起来很好但是错了：错误的抽象、漏掉的冲击半径、让状态 brick 的迁移步骤。你在三小时后才发现，不是在评审时。
核心洞察
一个模型独立采样一个分布，房间里没有对手。所以它把第一个猜测合理化成计划。
两个独立模型很少在同一个计划上犯同样的错误。它们分歧的地方，几乎恰好是计划中最危险的部分——那个没人检查的假设。
多模型共识（multi-model consensus）就是把这个分歧从噪音变成可行动的信号。
三阶段共识循环
/consensus 运行 GPT（Codex）、Gemini 3（Antigravity）、Grok（xAI）同时处理同一个 artifact，Claude 作为仲裁者。每轮有三个阶段：
Stage 1：并行评判
Claude 先把自己的裁决（APPROVE / REQUEST CHANGES / REJECT）盲写进 transcript，放在任何人看到其他意见之前。
这样 Claude 的判断不会在看到别人意见后漂移。然后 GPT、Gemini、Grok 在各自的 fresh thread 里并行评审，各自从单次 shot 中给出 verdict。
关键：没人看到别人的评审。
Stage 2：盲交叉审核
这个阶段新增于 2026 年 5 月 26 日。
每个外部评审者评价其他人的答案（身份最佳努力剥离）。「not viable」的票变成候选关键问题，仲裁者必须权衡。
这捕获了「Stage 1 看起来像共识，但其实是三个人各自绕过同一个坑」的情况。
Stage 3：仲裁裁定
Claude 调和 Stage 1 的 verdict、Stage 2 的候选问题和自己盲投的 verdict。每个异议被接受、记录理由后驳回、或者 defer。Claude 修改 artifact，loop 再跑，最多五轮。
只有当每个响应的外部都 approve 且 Claude 的预提交 verdict 一致时才收敛。如果无法达成，写明原因而不是伪造共识。
两个额外的工具
专家分离（Expert Separation）
不只是换模型。不同专家身份让分歧更尖锐：
- Architect：架构层面
- Plan Reviewer：计划审查
- Scope Analyst：范围分析
- Code Reviewer：代码审查
- Security Analyst：安全分析
- Researcher：研究
- Debugger：调试
一个 Security Analyst on Gemini 和一个 Architect on GPT 争论的是不同的事情，不是同一个模型 review 两次。
评审者身份隔离
每次 round 发送完全相同的 artifact text，冷启动，新鲜 thread。评审者永远看不到 triage、running verdict 或之前 round 的 framing——只有 artifact 和有限的 round metadata。
Claude 的判断应用于报告之后，而不是在他们收到之前就烘进去。
为什么有效
独立是关于哪个模型，更是关于不同的 hat。
结合轴：Security Analyst on Gemini 和 Architect on GPT 争论不同的事。「这个安全吗」和「这是正确的形状」由不同的评审者争论，不被平均成一个平淡的 verdict。
对于一个迁移计划，跑 Plan Reviewer 广泛评审，加一个 Security Analyst pass。「安全吗」和「形状对吗」被不同的人争论，而不是被合并。
一个模型是猜测。三个以上同意才形成计划。
当分叉恰好是风险的锚点时，你需要一个机制强制它们面对面包车型成计划，而不是各自合理化自己的第一版猜测。