七个 Agent 攻 40 道数学题：闭卷最多解 7 个，联网解 27 个却靠抓现成答案

2026 年 10 月 27 日提交的 arXiv 论文《OpenFrontiers: A Collection of Open Research Problems and a Benchmark for Scientific Rediscovery》（编号 2610.37739）把“模型能不能做科研”变成了一套可核验的评测。它收集 12,151 条开放研究问题记录，构建 200 个数学问题基准，其中 110 个在 2026 年已解决、90 个仍开放，每个问题都带一个经过自动探针和两名独立评审检查的 Lean 4 表述。论文用 7 个 LLM agent 在 HQ-50 子集上测试：封闭书条件下最多解决 7/40 个已解决问题，而联网成功主要反映检索到已发布解答。这是现在值得看的原因——它没有讨论模型“是否有科研潜力”的抽象话题，而是给出了一个严格判分口径。

为什么是“科学重新发现”而不是普通解题

论文摘要开头的判断是：LLM 在研究级问题求解上表现出越来越多潜力，但缺少一个成体系的研究问题集合，而且用研究级问题评估模型仍然很难。OpenFrontiers 的设计是跨学科的：它把开放研究问题语料和一个回顾性数学基准放在一起。

这里的关键词是“回顾性”。开放问题没有标准答案，无法直接判分；已解决的问题有确定答案，可以判分。用最近已解决的数学问题来测模型“重新发现”能力，就能绕过“开放问题无法评分”的难题。判分工具是 Lean 4：一种形式化定理证明器，证明必须写成可验证的代码，机器能检查每一行推理。这比自由文本打分严格得多，也排除了一部分“看起来对但推理有漏洞”的回答。

论文选择 110 个“2026 年已解决”的问题作为重新发现题目，这个时间窗口也值得注意。我的推导是：这是为了尽量避开模型训练数据里已经存在的完整解答。如果题目在更早年份就已解决，模型可能在预训练阶段就见过答案，closed-book 分数会被污染。这个推导不是论文明确说的，但它解释了为什么基准用“最近解决”而不是随机抽取历史问题。

12,151 条语料与 200 条数学基准的构成

论文摘要给出的数据相当具体：语料记录 12,151 条问题的 statement、context、progress 等信息；基准包含 200 个数学问题，110 个已在 2026 年解决，90 个尚未解决；每条都带一个由 automated probes 和 two independent reviews 检查过的 Lean 4 表述。一个子集 HQ-50 进一步按 quality score 等条件筛选。

HuggingFace 集合页 给出了更细的划分，正好可以和论文对照：

可以看出，HuggingFace 页面补充了论文摘要没有明说的 HQ-50 内部比例：40 个已解决和 10 个开放。这与论文摘要里“40 resolved problems”对得上。另外，DAIR.AI Academy 转载页显示三位作者均来自伊利诺伊大学厄巴纳-香槟分校，这也符合形式化证明团队的常见背景。

三种评测条件：封闭书、冻结检索、联网

论文的评测协议是：在隔离沙箱里，用两个独立检查器给形式化证明打分，并设置三种条件——closed-book、frozen-retrieval、live-web。

• closed-book：模型只能用参数内知识，不能调用外部检索。
• frozen-retrieval：允许检索一个冻结的语料。
• live-web：允许实时联网。

从评测设计看，三种条件测量的是三种能力。封闭书最接近“模型自己知道多少”；联网则可能把公开答案直接检索进来。论文摘要说 live-web success mostly reflects retrieval of published solutions，这是官方结论。我的推导是：如果只公布 live-web 分数，很容易高估模型的独立科研能力；closed-book 才是更严格的上限。

40 道题上的实测：三档条件的真实差距

论文正文第 5 节给了分模型、分协议的完整数字，比摘要那句”最多 7 个”具体得多。

闭卷（A 条件，原生协议）：7 个 agent 各解出 0–3 题。 在允许续跑（continuation）的协议下，上限抬到 0–7 题。论文特别指出，续跑协议帮助最大的恰恰是最早放弃的那些 agent：Claude Sonnet 5.5 从 0 涨到 4，GPT-6.1-sol 从 2 涨到 7，GPT-6-luna 从 0 涨到 2；而开源权重模型的变化最多只有 2 题。

# 各 agent 在续跑协议下的闭卷成绩（论文正文 Table 3 口径）
Claude Sonnet 5.5 : 0  -> 4
GPT-6.1-sol       : 2  -> 7
GPT-6-luna        : 0  -> 2
open-weight models: 变化 <= 2 题
# 全部 14 次运行（7 模型 x 2 协议）合计
A+B 累计解题数    : 53
落在题目数        : 8   <- 53 次解题只覆盖 8 道题

最后两行是论文里最狠的一处：53 次解题只落在 8 道题上。而这 8 道题里，importance 档位为 3 的三道（R01、R04、R29，全都是人类用简短构造解出的）贡献了 53 次里的 44 次；importance 档位为 5 的 21 道题里，只解出 1 道（N28，靠一个有限证书），而且只解出过 1 次。

换句话说：agent 反复攻克的是少数几道简单题，真正难的题基本没动。

冻结检索（B 条件）没有系统性帮助。 论文说 B 在 2 次运行中比 A 高（多 1 题、多 2 题），在另外 3 次中落后 —— 这与”检索快照早于所有解法”的解释一致。

联网（C 条件）成绩跳到 1–27 题，但论文给出了拆解：全部 181 次 C 条件下的解题中，167 次来自”抓取到了已定位的解答来源”（预印本、代码仓库或问题页），而且常常还附带着一份公开的 Lean 证明供改编。论文举的例子是 Erdős 问题 #152（E03）—— 它在 2026-04-03 已被一个 DeepMind prover agent 用公开 Lean 证明解决：

E03 (Erdos #152) 在两种条件下的表现
28 次 A/B 条件尝试  ->  0 次解出
14 次 C 条件运行    -> 11 次解出
# 每次都是先抓取问题页或其论坛帖，帖子里就链着那份公开证明

论文自己的措辞是：这已经变成纯粹的找答案（solution-seeking），而不是科学重新发现。

不过论文也留了一句不那么绝对的话：即使在联网条件下，也没有哪个模型能解完那 40 道已解决题。所以”检索能力也有上限”这个判断，论文是认的。

为什么联网好可能是个陷阱

如果你只看 live-web 的分数，会得出“模型研究能力不错”的错觉。但论文的官方结论是 live-web 成功主要反映检索到已发表解答。换句话说，模型在联网条件下通过的题目，很大概率是找到了已经公开的解法，而不是自己重新发现。

按这个口径推下来可以得到一个边界判断：OpenFrontiers 的 live-web 分数更适合用来测“搜索-复用”链路，而不是科研创新。这个判断是我的推导，不是官方说法。对于想评估 agent 的团队，更值得看的是 closed-book 和 live-web 之间的差值：差值越大，越说明模型靠外部信息过关。

形式化证明这道窄门

这个基准还有一个官方没展开的代价：用 Lean 4 形式化证明来判分，意味着只有能写成 Lean 代码的数学问题才被纳入。论文的基准只覆盖数学，而且是最近解决的数学问题；那些无法形式化的科学发现——比如实验物理、化学合成、生物实验设计——不在评测范围内。

另外，两名独立评审提高了可靠性，但评审者知道哪些问题已经解决，可能使基准偏向某些类型的问题。这两点是我从评测设计推导出的边界，不是论文自己说的。

你可以拿它做什么

如果你正在做 LLM agent 评测，而且关心“闭卷科研能力”，OpenFrontiers 可以作为一道额外考题。数据集已经公开在 HuggingFace，其中 OpenFrontiers-Bench 和 HQ-50 可以直接取用；一级来源仍是 arXiv 摘要页，需要更细的协议细节可以去读 HTML 全文。

我的建议是不要只报一个总分。把 closed-book、frozen-retrieval、live-web 三个分数并列看，尤其关注 closed-book 和 live-web 的差。这个差值比任何单独数字更能说明模型是在“重新发现”，还是在“找到了答案”。

参考来源：

1. arXiv:2610.37739 摘要页 https://arxiv.org/abs/2610.37739
2. HuggingFace OpenFrontiers 集合页 https://huggingface.co/collections/FlippyDora/openfrontiers
3. DAIR.AI Academy 转载页 https://academy.dair.ai/papers/openfrontiers-a-collection-of-open-research-problems-and-a-benchmark-for-scienti-2610.37739

参考来源

• OpenFrontiers: A Collection of Open Research Problems and a Benchmark for Scientific Redis