技术 · 熟练
让两个 AI 互查，先看它们配不配
同门互审最容易互相点头
「让它俩互相检查」是今年最流行的一招，也是最容易白费的一招。开源榜上已经有现成做法：一个 harness 同时调度 Claude Code 与 OpenAI Codex，让两个助手分工并互相复核，省掉在两个窗口之间来回切。但配对不是随便配的 —— 如果两个执行体来自同一家、同一底座、同一套训练偏好，它们对同一处错误会给出同一套盲区：一个漏了，另一个大概率也漏，互相检查就退化成互相点头。真正让互查产生价值的是「异构」两个字：不同的底座、不同的训练数据、不同的失败偏好，才会在同一个产物上给出不同意见。这一页讲三件事：什么条件下配对才有意义 · 配对要先把哪些接口定死 · 以及它贵在哪里。
方法 · 一图看懂
1
先分清同构与异构 — 同一底座 / 同一厂商多开 = 同构，盲区重合；互查的价值来自分歧
2
配对前定三样 — 谁提交 · 谁复核 · 分歧由谁裁（不定这三样，互查会变成两个 agent 互相改
3
复核方只拿产物不拿过程 — 把执行方的推理轨迹一并给它，会让它顺着对方的思路走
4
给复核方一份可判的清单 — 复核要求是「这条约束是否满足」这种可判命题，不是「你觉得行不行」
5
算清成本 — 异构配对要付两份服务费，收益要落在「拦下的错误数」上才算成立
原理 · 为什么有效
这一招的成立条件其实是分歧率，不是协作形式。两个执行体互相检查的价值 = 它们出错集合的差集；同构配对的差集天然小（因为训练偏好相近，容易犯同一类错），异构配对的差集才值得付第二份钱。这条判据也解释了为什么「多开几个实例」常常没用：同一底座重复跑几遍，得到的是一致性，不是发现率。反过来说，一旦有了真实分歧，真正的工作量就不在「检查」上，而在「裁决」上 —— 两个 agent 各执一词时，需要一个明确的第三方规则（或人）来定，否则两个 agent 会陷入互相改对方的产物。这也正是很多 harness 在做的事：把「分歧怎么收」变成协议的一部分，而不是留在运行时的即兴处理。
适用场景
适用：你已经在用编码 agent 做有明确验收标准的活（改 bug / 生成测试 / 迁移依赖），并且发现自家的错误总是同一类；或者你要处理的产物有可机械判定的约束清单（等价性、覆盖率、接口契约）。
⛔ 不适用：任务没有可判定的验收对象（纯探索 / 纯创意），或者你的预算只够一份服务费 —— 这种情况下，把同一份预算投给「更明确的验收清单」比投给第二个 agent 更值。
⚠️ 前提：你得能说清「复核方要判的具体命题是什么」。说不清，配对就只是多了一层来回。
自测 · 5 问
我要配的两个执行体，来自不同的底座 / 厂商吗？还是只是同一家多开了两个实例？
我有没有一个可机械判定的清单，能交给复核方逐条判？
复核方拿不拿得到执行方的推理过程？如果拿得到，我担不担心它顺着对方的思路走？
两个人意见不一致时，谁说了算，这条规则我现在写得出来吗？
过去一个月，我拦下的错误里有多少是「换个底座就会发现的」？
怎么上手 · 验证步骤
先拿一件小事跑通闭环，别上主线任务。三步：① 选一个有明确验收标准的小活（比如给一个函数补测试，标准是覆盖率与不许改动原签名）；② 让执行方交付，只把产物交给复核方，复核要求写成可判命题（「有没有改动原函数签名」「有没有覆盖到这个分支」）；③ 记录三样东西：复核方提出的不同意见数 · 其中真正有效的数 · 两人最终分歧由谁裁的。跑三五个小活之后，如果「有效意见数」长期接近 0，说明你配的其实是同构对 —— 换一个不同底座的复核方才值得继续。
自检动作：给这次配对算一个数 —— 「有效分歧 / 总复核次数」。这个比例低于你的预期，问题通常不在复核方不认真，而在两边太像。把两个底座分别写在纸上，比一比它们的共同点：共同点越多，这个比例注定越低。