我让 Agent 同时跑两遍，严格评分从 60% 降到了 53.3%

背景

单个 Agent 为补齐引用会反复搜索和修改答案，4 个问题用了约 60.9 万 Token。

问题

需要验证同一个问题独立运行两次，再从两份答案中选择一份，能否增加证据探索、减少反复修正并提高通过数。

做法

两次运行使用独立状态和固定预算，最后由不读取测试答案的 Selector 选择；同时计算两份答案的理论上限、实际选择损失和完整成本。

结果

Selector 得到 16/30，理论上限只有 17/30，当前单路径为 17/30；Best-of-2 多用约 73.5 万 Token，相关生产代码已删除。

1. 背景、冲突、问题与结论

背景。 前一轮增加提交检查后，Agent 会为缺少引用的论文继续搜索和修改答案。4 个重点问题合计 使用约 60.9 万 Token，其中一个问题经历 19 次模型调用、26 次工具调用和 7 次提交拒绝。

冲突。 单个 Agent 在同一段长上下文中反复修补，可能围绕最早找到的证据继续修改。再运行一个独立 Agent 可以增加探索，也会重复支付问题、工具定义、历史和工具结果的上下文成本。

问题。 同一个问题独立运行两次，再从两份答案中选择一份，能否提高通过数，并把额外成本控制在 可接受范围内？

结论。 Best-of-2 最终为 16/30，两份答案的理论上限只有 17/30，恢复后的单路径也是 17/30。 两次运行没有产生足够互补的答案，总 Token 增加约 73.5 万。并行方案没有进入生产。

2. 先固定四个概念

概念	含义
Sample	同一个问题的一次独立 Agent 运行
Selector	两次运行结束后选择其中一份答案的固定规则
Oracle pass@2	假设总能选中两份答案中的通过者时，Best-of-2 的理论上限
Hard Pass	回答类型、指定证据位置和引用全部通过固定规则

Selector 不合并两份答案，也不生成第三份答案。它只在 Sample 0 和 Sample 1 之间做选择。

历史 MiniMax 的 18/30 来自多次运行结果合并，只能提供参考尺度。实验结束后恢复单路径，当前代码得到 17/30。后者更接近同一运行方式下的生产基线。

3. 实验需要验证的三个主张

1. 两次独立运行会找到不同证据，形成互补答案；
2. 不读取 Golden Data 的 Selector 能选出较好答案；
3. 并行执行可以缩短等待时间，额外 Token 不会抵消收益。

三个主张需要分别验证。最终结果下降，可能来自两次答案都不好，也可能来自 Selector 选错，还可能 来自预算不足或技术失败。

4. 实验设计如何隔离变量

4.1 两次运行完全隔离

两次 Sample 只共享用户问题和只读论文数据。每次运行分别创建：

• ResearchRunContext；
• 论文和位置授权；
• Evidence ID 与已读证据；
• SDK Session 和工具轨迹；
• Model Client；
• 模型调用、工具调用、Token 和提交拒绝计数。

论点。 第二次运行必须看不到第一次的授权位置、Evidence ID 和会话历史。

论据。 共享状态会让第二次运行沿用第一次的搜索结果，无法判断独立探索是否产生互补答案。

论证。 Best-of-2 的假设依赖两次独立采样。状态共享会改变实验对象，理论上限也失去解释意义。

4.2 每次运行使用相同预算

第一版预算为 5 次模型调用、8 次论文工具调用和 1 次提交修复。4 个重点问题中有 3 个尚未形成完整答案 就耗尽预算。模型调用提高到 7 次后，仍有 3 个技术失败。

最终每次 Sample 的上限为：

max_model_calls = 10
max_corpus_tool_calls = 12
max_rejected_final_submissions = 2

多论文回答通常需要识别论文、分别定位、读取多个位置、组织引用，并可能修正一次提交。预算需要覆盖 这条基本路径，同时阻止无限补证。

4.3 Selector 不读取测试答案

两次运行都完成后，Selector 按以下顺序比较：

1. 用户明确要求的论文是否都有同论文正文引用；
2. 数值声明能否在引用原文中找到对应数值；
3. 是否讨论当前问题没有要求的额外论文；
4. 被拒提交、模型调用、工具调用和 Token 是否更少；
5. 完全相同时按固定序号选择。

Selector 不读取问题编号、指定证据位置、预期事实、人工标签或自动分数。两次完整运行都会保存，离线 分析可以分别计算单次结果、Oracle pass@2 和实际选择结果。

5. 论点一：两次运行没有产生足够互补的答案

论据。 30 个固定问题得到：

指标	结果
Selector 最终 Hard Pass	16/30，53.3%
旧 15 个问题	13/15，86.7%
新 15 个问题	3/15，20.0%
Oracle pass@2	17/30，56.7%
技术失败	5/30
60 次独立运行中预算耗尽	16/60

两次 Sample 单独得分为：

Sample 0：13/30
Sample 1：14/30
Oracle pass@2：17/30
Selector：16/30

Sample 0 独有 3 个通过问题，Sample 1 独有 4 个，两者共同通过 10 个。

论证。 如果第二次运行提供大量互补答案，Oracle pass@2 应明显高于单次结果。实际理论上限只有 17/30，与恢复后的单路径相同。Selector 即使每次都选对，也无法超过这个上限。

两次运行使用了相近检索词，也围绕相近证据组织答案。运行次数翻倍，证据探索范围没有同步扩大。

结论。 Best-of-2 的主要限制位于答案生成阶段。第二次 Sample 没有提供足够多的新通过答案。

6. 论点二：Selector 不是主要瓶颈

论据。 Oracle pass@2 为 17/30，Selector 得到 16/30。只有 toolsandbox_constraint_selection_001 出现明确选择失误：一份答案通过，Selector 选了另一份。

主要错误分布为：

错误	次数
REQUIRED_ANCHOR_MISSING	26
REQUIRED_ANCHOR_NOT_CITED	26
REQUIRED_PAPER_MISSING	8
OUTCOME_MISMATCH	6
CITATIONS_REQUIRED	5

论证。 Selector 与理论上限只差 1 个问题。修复唯一明确的选择错误，结果也只能从 16/30 提高到 17/30。大多数失败在两份答案中都没有满足指定证据或论文覆盖要求。

产品 Selector 只能使用论文覆盖、引用内容、数值和成本。它无法读取 Golden Data 指定的证据位置。 为提高自动评分而加入指定位置，会把测试答案泄漏到运行时。

结论。 继续增加 Selector 规则无法突破 17/30 的生成上限。下一步应改进候选读取和证据选择， 不应先扩大选择器。

7. 论点三：并行缩短等待，但总成本上升

论据。 Best-of-2 全量结果为：

成本指标	结果
模型 HTTP 响应	364
论文工具调用	325
Prompt Token	3,290,152
Completion Token	147,145
Total Token	3,437,297
全量等待时间	约 19.1 分钟

恢复单路径后的结果为：

指标	MiniMax 单路径
Hard Pass	17/30，56.7%
旧 15 个问题	12/15，80.0%
新 15 个问题	5/15，33.3%
技术失败	1/30
模型调用	212
工具调用	167
Total Token	2,702,429
累计问题耗时	约 36.1 分钟

论证。 并行运行让每个问题的等待时间接近较慢的 Sample，而非两次耗时之和。模型账单仍按两次 运行的总用量计算，因为两条路径都携带问题、历史、工具定义和工具结果。

Best-of-2 比恢复后的单路径少通过 1 个问题，并多使用约 73.5 万 Token。两组耗时统计口径不同，不能 直接计算严格加速比；Token 和通过数已经足以否定默认启用。

结论。 本次并行方案降低了部分等待成本，没有提高结果，也没有降低每个通过答案的模型成本。

8. 论点四：相同调用上限不等于相同有效工作量

论据。 60 次独立运行中有 16 次预算耗尽，30 个问题中有 5 个技术失败。部分 Sample 在第 10 次模型 调用后仍未形成完整答案。

论证。 一次模型调用可能安排多个工具动作，也可能只处理一个位置。固定 10 / 12 / 2 可以控制 账单，无法保证每个 Sample 完成相同数量的研究步骤。

继续扩大预算会增加形成答案的机会，也会进一步抬高 Best-of-2 成本。Oracle pass@2 已经没有超过当前 单路径，追加预算缺少直接收益依据。

决定。 停止提高 Best-of-2 预算。预算耗尽继续作为单路径 Harness 的独立问题处理。

9. 实验暴露的工程问题

全量运行发现了几项单元测试未覆盖的问题：

• 第一版只统计胜出答案的 Token，漏掉失败或未选中 Sample 的成本；
• 两次运行都失败时，外层技术失败记录丢失内部用量；
• 用户取消后，另一条 Sample 仍可能继续；
• 胜出 Sample 先结束时，请求完成时间被提前记录；
• 两条进度事件缺少 sampleIndex，无法区分来源；
• 历史用户问题中的旧论文会污染 Topic Change；
• get_research_skill 被误计入论文工具预算。

论点。 编排实验必须记录所有候选运行，而非只记录最终答案。

论据。 原始 model.response 事件可以还原 343.7 万 Token，而第一版聚合只看胜出 Sample，会低估 实际账单。

论证。 Selector 决定用户看到哪份答案，不会消除另一份答案已经发生的请求、Token 和失败。成本、 取消和诊断必须覆盖整组运行。

处理。 增加带 diagnostics 的 HarnessExecutionFailed，让全部失败时的用量进入最终记录，并补上 取消、完成时间和事件归属测试。

10. 工程决定

Best-of-2 没有进入生产。并行运行、Selector、独立预算和相关生产代码已经删除，每个研究回合恢复为 一个 Agent。

保留三项实验成果：

1. 每次运行使用独立状态的实现经验；
2. 保存所有候选运行，用于区分“没有生成好答案”和“生成后选错”；
3. 从原始事件离线计算 Oracle pass@2、选择损失、成本和错误分布的方法。

EvalRecorder 继续保存：

<run_id>/events.jsonl
<run_id>/result.json

最终论证。 生成上限只有 17/30，Selector 已达到 16/30，单路径同样达到 17/30 且少用约 73.5 万 Token。三个事实共同支持删除默认 Best-of-2。

后续工作回到证据选择、回答类型和人工审核，不再为同一假设增加并行层数。

随后进行的模型 API 对照见 换成 GPT 后，严格评分为什么从 60% 降到 36.7%。

11. 证据边界

能够支持的结论。 在本次 MiniMax、30 个固定问题和 10 / 12 / 2 预算下，Best-of-2 没有提高 Hard Pass，生成互补性不足，成本高于单路径。

尚不能支持的结论。 本次结果不能证明所有 Best-of-N 都无效。不同模型、主动制造差异的 Prompt、 不同工具或能够合成答案的后处理器可能得到不同结果，需要作为新的实验重新验证。

历史 18/30 不是严格同条件基线。本文停止 Best-of-2 的主要依据是 Oracle pass@2、恢复后的单路径 17/30 和完整 Token，而非标题中的历史参考值。

12. 复现资料

恢复单路径后的合并运行目录：

/tmp/paperloom-minimax-single-restored-merged-20260714

相关资料：

• 检索召回恢复后，为什么只多通过一个问题
• 模型 API 迁移实验
• research/golden-data/README.md
• harness_py/ONBOARDING.md