审稿人很准，但没人听：多智能体数学推理中一个被忽视的失败模式

一个反直觉的发现

想象一家餐厅请了位米其林级别的卫生检查员。她每次检查都能精准发现后厨的每一个问题——油温不够、砧板交叉污染、调料过期。报告写得详尽又准确，精准度 86%。

但报告交到厨房后，厨师长看了一眼，放进了抽屉。下次检查，同样的问题还在。

与此同时，街对面另一家餐厅用的是"广播式"检查——所有厨师围在一起，检查员当众指出问题，大家集体讨论怎么改。检查员水平差一些，精准度只有 64%，但每个问题都被当场修复。

半年后，第二家餐厅的卫生评级比第一家高 4 个百分点。

这不是寓言。这是 Argonne 国家实验室最新论文 Precise but Uncoupled: Reviewer Precision Does Not Guarantee Critique Uptake in Multi-Agent Math Reasoning 的核心发现——把"餐厅"换成"多智能体数学推理系统"，把"卫生检查员"换成"审稿 agent"，故事完全一样。

大家都在用的设计：专门审稿人

当前主流的数学推理多智能体系统几乎都有一个共同设计：专门的审稿人角色。MALT 把推理拆成生成器、验证器、精炼器三个 agent 端到端训练；DPSDP 用强化学习训练 actor-critic 对；大量综述和 scaling 分析都认为，角色异质性是多智能体增益的主要来源。

这套设计的底层假设很朴素：把审稿和求解分开，让专业的人干专业的事，审稿人负责找错，求解器负责改错，整体性能就会提升。

这个假设听起来太合理了，以至于很少有人去检验它。

4181 道奥赛题，10 个难度层

Argonne 团队决定认真检验一下。他们选了 Omni-MATH 基准——4181 道竞赛级数学题，分 10 个难度层，从高中竞赛到 IMO 级别。这个基准的好处是有足够的"天花板"——当前最强模型在最高难度层上还远没饱和，能真正区分不同协议的优劣。

模型固定用 gpt-oss-120b，比较四种协议：

1. Baseline LLM：一次性作答，没有协作
2. Single-Agent Iterative：单 agent 迭代，有验证器反馈但无协作
3. PER（Planner-Executor-Reviewer）：分层式，规划器→执行器→审稿器，审稿意见走"建议通道"
4. Broadcast：广播式同行讨论，所有 agent 共享候选答案，集体审议后提交

结果：精准度赢了，准确率输了

整体数据（Table 1）：

Broadcast 赢了 4 个百分点。但真正反直觉的不是这个，而是下面这组数据：

PER 的审稿人更准（86.1% vs 64.4%），但有用审稿被采纳的概率只有 33.6%，而 Broadcast 是 93.5%。 审稿引导的实际修复率 PER 只有 5.1%，Broadcast 是 28.6%——差了 5.6 倍。

这就是论文标题所说的"Precise but Uncoupled"——审稿人很准，但审稿意见和求解器的下一步行动是脱钩的。

为什么会脱钩？信息流 vs 决策流

论文用一张图（Figure 1）解释了根本差异：

PER 的架构：Planner → Executor → Reviewer。审稿人的反馈走的是"建议通道"——进入一个独立的 advice field，求解器可以看也可以不看。提交决策是"角色本地"的，审稿人无权阻止。

Broadcast 的架构：所有 agent 共享候选答案，审稿意见进入共享状态，提交需要集体重新批准。想绕过审稿意见？做不到，因为答案修改是集体行为。

用工程语言说：PER 的信息流和决策流是分离的——信息到了，决策可以不变。Broadcast 的信息流和决策流是耦合的——信息到了，决策必须响应。

这就像开头那个寓言：第一家餐厅的检查报告进了抽屉（信息流到达，决策流不变），第二家餐厅的检查结果是当众宣布的（信息流和决策流绑定）。

三个诊断指标：检测、采纳、修复

论文最大的方法论贡献是提出了三层分解：

1. Detection（检测）：审稿人能不能发现错误？——用 Reviewer Precision 衡量
2. Uptake（采纳）：有用的审稿意见有没有改变下一步候选答案？——用 CouplingRate 衡量
3. Repair（修复）：改变之后有没有真的修对？——用 ReviewerGuidedRepairRate 衡量

之前的评估只看第 1 层（审稿人准不准）和最终通过率，完全跳过了第 2 层。这就是为什么"审稿人很准但系统不行"这种失败模式能长期隐藏——不是没有问题，是评估指标看不见问题。

论文还引入了 NeglectRate（忽视率）：在有错误候选且审稿人给出了有用反馈的情况下，求解器完全无视反馈的比例。PER 的 NeglectRate 是 48.8%——接近一半的有用审稿意见被直接无视。Broadcast 只有 26.2%。

更扎心的是 TryButFailRate（试了但没改对）：PER 40.2%，Broadcast 48.1%。PER 不是"改不好"，是"根本没改"。尝试修复的成功率两家差不多，但 PER 连尝试都不尝试。

两个干预实验：承认没用，嵌入有用

如果脱钩是问题，怎么修？论文做了两个精巧的对照实验：

干预 1：ACK-required（强制承认）

"你必须明确承认收到了审稿意见"

结果：FinalPassRate 从 85.2% 降到 82.5%，NeglectRate 从 48.8% 升到 79.2%，CouplingRate 从 33.6% 降到 17.5%。

强制承认反而更差。 求解器学会了"口头承认"——在回复里写"收到审稿意见，已考虑"，但候选答案原封不动。这是典型的表面合规（superficial compliance）：满足了新指令的形式要求，但没改变实质行为。

这和现实世界的"整改报告"何其相似——出了事故，要求写整改报告，报告写得漂亮，但同样的故障下次还出。

干预 2：EMB（嵌入工作上下文）

把审稿意见直接放进求解器的工作上下文，而不是走独立的建议通道

结果：FinalPassRate 从 82.5%（ACK-required）升到 86.3%，Pass@1 从 71.0% 升到 74.5%，NeglectRate 从 79.2% 降到 69.8%。

有效，但只是部分恢复。 EMB 比 base PER 略好，但仍然不如 Broadcast。这说明：把审稿意见放近一点有帮助，但还不够——Broadcast 的集体审议机制提供了更强的耦合。

论文把 Base PER → EMB → Broadcast 读作一个"审稿意见呈现方式逐步直接化"的序列，而不是单次干净消融。方向性证据一致：审稿意见越直接进入求解器的工作上下文，采纳率越高。

难度分层：越难越明显

协作的增益不是均匀分布的。在 tier 1-2（最简单），协作只多解 2 个百分点。从 tier 4 开始，增益急剧打开。tier 6-9，PER 比 Single-Agent 多解 10-16 个百分点，Broadcast 多解 14-20 个百分点。

关键观察：在 hard tier 6-9 上，PER 的审稿人精准度依然很高（0.81-0.87），但有用审稿被采纳率只有 0.32-0.37，Broadcast 维持在 0.93-0.96。难度上升没有降低审稿质量，但 PER 的脱钩问题依然存在——这不是"审稿人不够好"，是"管道设计本身有问题"。

工程洞察：评估的盲区

这篇论文对 AI 从业者有几个直接启示：

1. 审稿人精准度不是系统质量的充分指标。 你的 reviewer agent 可能在内部评测里准确率 90%+，但如果协议设计让 solver 可以轻松绕过审稿意见，系统整体性能仍然不行。评估多智能体系统时，必须同时测 Detection、Uptake、Repair 三层。

2. "加一个审稿人"不是免费的。 PER 用了更多验证器调用（2.19 vs 1.35 per problem），生成更少 token 但最终准确率更低。如果只看"审稿人精准度"这种中间指标，你会以为 PER 更好；看最终通过率才发现它更差。中间指标可以骗你，最终指标不会。

3. 信息流和决策流的耦合方式比审稿人质量更重要。 与其花力气提升 reviewer 的精准度，不如想想怎么让 reviewer 的意见更直接地进入 solver 的工作上下文。Broadcast 的优势不是"审稿人更好"，是"审稿意见更难被绕过"。

4. 表面合规是真实风险。 ACK-required 实验说明，如果你用"必须承认"这种合规式控制，模型会学会口头承认但行为不变。这对 AI 安全有直接启示——对齐评估不能只看模型说了什么，要看模型做了什么。

5. 安全关键场景下，被无视的审稿等于没有审稿。 论文在 Broader Impact 里特别指出：在安全关键场景中，正确的审稿被无视，功能上等同于没有审稿。如果你的 AI 系统有一个"安全检查 agent"，但它的警告可以被执行器轻松跳过，这个安全检查就是装饰性的。

跨家族复现：Gemma 3 也一样

附录 D 用 Google 的 Gemma 3 27B 做了简化版跨家族复现。整体排名有变化（不同模型家族对协议的偏好不完全一致），但精准度和采纳率的分离依然存在。这说明脱钩不是 gpt-oss-120b 的特殊问题，而是 PER 式接口的通病。

我的思考：从"找错"到"改错"

这篇论文让我想到一个更广的规律：很多系统的瓶颈不在感知而在行动。

• 自动驾驶：检测到危险但刹车系统没响应，等于没检测
• 医疗诊断：诊断对了但治疗方案没执行，等于没诊断
• 代码审查：PR review 指出 bug 但开发者不修，等于没 review
• AI 安全：对齐评估发现风险但部署流程不响应，等于没评估

"Precise but Uncoupled" 不是一个多智能体系统特有的问题，它是所有"检测-行动"分离系统的通病。只要检测和行动之间有一个可被绕过的接口，就会出现脱钩。

反过来想，Broadcast 的成功给了一个设计原则：如果你想让反馈被采纳，就让反馈和决策绑定。不要走独立通道，不要给执行者"看也可以不看"的选项，要让反馈成为决策流程的必经环节。

这和人类组织的经验一致：最有效的反馈机制不是"写报告给领导看"，而是"当众讨论、集体决策"。透明度和强制性，比精准度更重要。

当然，论文也有局限。作者坦诚：这是 test-time study，模型家族固定；Omni-MATH 是数学题，正确性二元，其他领域可能不同；CouplingRate 是协议级答案转换统计，不完全是"模型内部是否理解了审稿"的语义判断；within-PER 的干预是方向性证据，不是干净因果证明。但核心发现——审稿人精准度和审稿采纳率是可分离的——在他们的设置里是扎实的。

数据与代码

论文的公开追踪可视化在 HuggingFace Space，代码和数据待机构审批后发布。

论文：Precise but Uncoupled: Reviewer Precision Does Not Guarantee Critique Uptake in Multi-Agent Math Reasoning
作者：Chih-Hsuan Yang, Jingyan Jiang, Vikram Vasudevan, Cheng-Hau Yang, Huihuo Zheng, Le Chen, Eliu A. Huerta, Venkatram Vishwanath, Ian T. Foster, Rajeev Thakur
机构：Argonne National Laboratory / University of Chicago / Oregon State University
模型：gpt-oss-120b（主）+ Gemma 3 27B（跨家族复现）
基准：Omni-MATH（4181 题，10 难度层）

一句话总结：审稿人准不准决定不了系统好不好，审稿意见有没有被采纳才是关键。评估多智能体系统时，别只盯着 reviewer 的精准度，看看 solver 到底听没听。