Terminal-Bench-Science上线科研Agent评测
8月28日讨论把科研工作流评测推到前台。
本文要点
- 社区讨论把0.1版科研工作流评测从项目页带到公共视野。
- 评测对象从通用终端任务扩展到科学研究者自己的工作流。
- 页面把10月5日写作0.2版PR截止，形成后续任务扩展节点。
阅读辅助
先看数字、证据和来源，再读正文。
本期news peg是8月28日HN讨论，不是10月5日页面日期。
2026-08 · GitHub README的引用信息标注Terminal-Bench-Science v0.1.0为2026年8月版本。
Terminal-Bench-Science 今天进入早报的 news peg，来自 HN 在 2026-08-28 00:06:51 UTC 创建的 item 49472820，这条讨论把 0.1 版科研 agent 评测推入社区讨论流。官网公告页本身展示的是首版 benchmark 信息；页面上容易被抓到的 2026-10-05 是 0.2 版任务征集的 PR 截止日，不应被改写成 0.1 版发布日期。
可以核实的主体事实是：Terminal-Bench-Science 由 Stanford 相关研究者和 Terminal-Bench 团队牵头，目标是评估 AI agents 在科学研究工作流中的表现。首版包含 70项 expert-curated tasks，覆盖生命、物理、地球、数学和工程科学这 五个 broad scientific domains。公告页和 GitHub README 都把任务来源描述为 researchers’ own work，也就是让科学领域贡献者拿真实研究流程设题，从而避免只由模型厂商单方面定义“科研能力”。
榜单数字要克制解读。公告显示 Claude Opus 5 在 Terminal-Bench-Science 0.1 上的 resolution rate 为 30.0%，GPT-5.6 Sol 为 22.4%，Claude Fable 5 为 21.4%，Claude Opus 4.8 为 10.5%，Grok 4.6 为 7.1%。这些数字说明当前模型在该 benchmark 上仍有大量任务没有解决；它们不能推出模型已能可靠完成科研任务，只能说明评测对象开始更接近真实科研工作流。
对读者的直接影响在评测口径。研究者可以把它视为一个更贴近实验、分析、代码和数据处理流程的公开任务集；模型团队会把“能不能跑完整科研工作流”纳入 agent 评估；企业买方则需要留意榜单是否把模型、工具、沙盒、执行预算和人工提示拆开，否则同一个百分比可能混合了多种系统能力。
日期先校准：8月28日是讨论锚点
本期最需要先处理的是日期。官方公告页的可见内容包含 “Terminal-Bench-Science 0.2 Deadline: October 5, 2026”，GitHub README也写明 no new PRs will be accepted after the deadline。这是面向贡献者的后续征集截止日，说明项目还在向 0.2 版扩展任务集。它不是 0.1 版发布日，也不能作为本期新闻的新鲜锚点。
新鲜锚点来自 HN。HN item 49472820 的标题是 “Terminal-Bench-Science: Evaluating AI agents on scientific research workflows”，URL 指向 terminal-bench-science.ai/announcement，API 时间戳换算为 2026-08-28T00:06:51Z。本次发现腿也记录 AI HOT 转引了这条 HN 热点，并把第三方摘要回溯到官网公告。因此本文把它写成“8月28日进入社区讨论，官网公告页显示0.1版 benchmark 信息”，避免写成“官网当天发布0.1版”。
| 原文或抓取口径 | 本文中文表述 | 不能写成 |
|---|---|---|
HN item time 1787875611 | HN在 2026-08-28 00:06:51 UTC 创建讨论 | 官网当天发布0.1版 |
Terminal-Bench-Science 0.1 | 首版 benchmark 信息已经公开展示 | 0.2版已经发布 |
70 expert-curated tasks | 70项专家策划任务 | 70篇论文或70个模型 |
five scientific domains | 覆盖 五个科学领域 | 覆盖所有科研学科 |
October 5, 2026 | 0.2版新PR截止日 | 0.1版发布日期 |
这个区分对早报很重要。若把 2026-10-05 当作发布日，内容会在新鲜度上误导读者；若完全忽略 10 月 5 日，又会漏掉项目接下来最可验证的里程碑。正确写法是：8月28日是本期社区讨论和发现锚点，10月5日是后续贡献窗口的截止时间。
0.1版评了什么：科研工作流而非论文问答
Terminal-Bench 的主线是终端环境中的 agent benchmark。主站把 Terminal-Bench 定义为用于衡量 agents terminal mastery 的 benchmark 集合，任务通常要求 agent 在命令行环境里完成可验证的操作。Science 分支把这种终端任务框架移到科研现场：任务要求模型在可执行环境里完成数据、代码、实验或分析流程，而不只停留在问答或论文摘要。
官网公告把项目定位为 evaluating AI agents on workflows from researchers’ own work。GitHub README进一步说明，任务由生命、物理、地球、数学和工程科学领域的 domain experts 撰写与审查，并欢迎研究者通过 proposal、build、review 流程继续贡献。这种设计把“科研能力”的定义权部分交回给科学家：什么算一个有意义的任务，什么输出可以客观验证，哪些步骤容易被模型偷懒，应该由懂领域的人先给约束。
首版任务数是 70项。这比动辄上千题的问答 benchmark 小得多，但它的成本结构也不同。一个好的科研 workflow 任务，需要准备数据、运行环境、oracle 解、评分规则和防作弊边界；如果任务来自真实研究，它还可能包含领域软件、长时计算、文件格式转换、统计判断或实验复现。任务少不必然意味着价值低，但会带来覆盖面和方差问题：五个领域里每个子方向被代表多少，任务难度是否均衡，都会影响榜单解释。
项目方展示的贡献者图注显示，proposal、review 或 pull request 相关贡献者有 376人，来自 22个国家。这是一条重要但仍需保持口径的数字：它证明项目试图用跨地域、跨机构的科学共同体扩大任务来源；它不等同于每名贡献者都提交了完整任务，也不代表每个领域都获得同等覆盖。
榜单数字：30%反而说明问题还没被解决
0.1版榜单最醒目的结果是最高 resolution rate 只有 30.0%。如果一个 benchmark 的第一名已经接近满分，它更多是宣传页；Terminal-Bench-Science 当前的数字反而说明，它还在测量 frontier models 的不足。
| 模型与运行代理 | Resolution rate | 早报解读 |
|---|---|---|
| Claude Opus 5，Claude Code | 30.0% | 当前榜单最高，但仍有七成任务未解决。 |
| GPT-5.6 Sol，Codex | 22.4% | 距离最高项有差距，需看Codex环境和预算口径。 |
| Claude Fable 5，Claude Code | 21.4% | 与GPT-5.6 Sol接近，但不同模型和代理组合不能粗暴合并。 |
| Claude Opus 4.8，Claude Code | 10.5% | 说明同一代理框架下模型版本差异可能很大。 |
| Grok 4.6，Grok Build | 7.1% | 榜单只反映该任务集和该运行代理，不宜外推到所有能力。 |
这里至少有三层口径要拆开。第一是模型本身。Claude Opus 5、GPT-5.6 Sol、Claude Fable 5、Opus 4.8 和 Grok 4.6 是不同模型或版本。第二是 agent harness。榜单里有 Claude Code、Codex、Grok Build 等运行代理，它们会影响工具调用、文件处理、命令执行和上下文管理。第三是任务环境。科学 workflow 可能需要安装依赖、读取数据、运行脚本、判断中间结果，这些都会放大环境差异。
因此，30.0% 不应被写成 Claude 已能解决科研任务。更准确的读法是：在项目方给出的 70项专家任务上，最强被评估组合只能解决约三成。这对科研 agent 是一盆冷水，也是一条有用基线。它把讨论从“模型是否懂科学知识”推进到“模型能否在受控终端环境里产出可验收结果”。
README给出的运行方式也支持这个理解。项目建议安装 Harbor，并用 oracle 运行多次来确认任务在沙盒环境中可工作；测试 agent 时需要传入 agent 和 model，并设置并发、环境和参数。Terminal-Bench-Science属于执行型 benchmark，榜单分数可能同时受模型能力、代理实现、工具权限、沙盒稳定性和任务定义影响。
为什么科学任务更难，也更值得测
科研工作流对 agent 的要求比普通问答更杂。模型需要读懂自然语言任务，也要操作文件、调用命令、解释报错、运行脚本、检查输出、处理依赖和判断结果是否符合领域标准。很多失败发生在执行链中段：路径错了、参数错了、数据格式理解错了、仿真实验没收敛，或者最后没有把结果写到正确位置。
这也是 Terminal-Bench-Science 的新闻价值。过去很多 AI 科研评估侧重知识问答、论文生成、代码片段或单点 benchmark。它们有用，但距离真实研究者的工作日仍有距离。科学家平时面对的是一串不干净的动作：拿到数据，清洗格式，复现实验，写脚本，运行模拟，生成图表，校验统计显著性，再把结果组织成可以被同事复核的材料。若 agent 不能在这些步骤里稳定工作，单次问答正确率再高也难以变成科研生产力。
Stanford AI Lab 的公开转发给这件事提供了传播语境。其页面嵌入的最新动态显示，Stanford AI Lab 转发了 Steven Dillmann 关于 Terminal-Bench-Science 的发布帖；项目官网则把它描述为 Stanford-led community effort，并列出与 Terminal-Bench 团队和多学科专家协作。本文只把 Stanford AI Lab 用作公开传播和机构语境来源，不把它写成单独发布方的完整新闻稿。
更值得注意的是贡献流程。README写明贡献任务需要先 proposal，再 build，之后进入 automated checks、parallel domain and technical review 和 final bar-raiser approval。这个流程反映出项目方知道科研任务很容易出问题：题目可能过窄，oracle 可能不稳定，评分器可能泄漏，依赖可能难装，模型可能通过捷径过关。一个严肃的科学 benchmark，难点不是收集题目，而是持续维护任务质量。
早报判断是，Terminal-Bench-Science 把科研 agent 的评测对象从“知道什么”推向“能完成什么”。这个变化会逼模型团队面对更硬的执行问题：长链任务、环境约束、错误恢复、领域软件和可验证产物。对科研场景来说，这些比一次漂亮回答更接近生产力。
但这类 benchmark 也有天然风险。任务只有 70项时，覆盖不足和分布偏差不可避免；任务公开后，模型和代理系统也可能围绕公开任务过拟合。项目方把 0.2 版新 PR 截止设在 2026-10-05，说明任务集还会继续扩展。接下来后续关键在于新增任务能否保持领域代表性、可运行性和防泄漏设计，而不只是榜单每次涨几分。
对读者而言，最实用的读法是把它当成“科研 agent 进入执行评测阶段”的信号。最高 30.0% 的 resolution rate 留出了足够大的失败空间；这正好提醒企业、实验室和模型厂商，今天的 agent 更适合被接入有边界的研究辅助流程，不能直接替代科学判断。
信源边界与本次核查
本文的置信度设为 medium，原因是核心事实有多源交叉，但发布日期和榜单数字仍高度依赖项目方页面。官网公告和 GitHub README 可以互相印证 70项任务、五个领域、Claude Opus 5 30.0% 以及持续贡献流程；HN API 可以确认 2026-08-28 的社区讨论锚点；GitHub任务目录提供公开任务集入口；Stanford AI Lab 公开转发提供传播背景。
不写成 high confidence，是因为官网公告没有提供一个容易被机器读取的 0.1 发布日期，页面上显著的 2026-10-05 又是后续 PR 截止日。GitHub REST API在本次核查中返回匿名限流，因此本文没有声称已经用 REST API逐项核过 release 或 commit 时间。对榜单而言，第三方复现和持续任务版本化也还没有充分展开。
这种边界不影响报道成立。它只要求标题和正文把“8月28日讨论发现”与“首版 benchmark 信息”拆开，避免把旧材料包装成当天官网新发布。对于 AI 早报，宁可把信源限制写明，也不要为了让新闻显得更硬，把日期和状态动词写错。
后续验证路径
任务集扩展是第一条线。项目方已经给出 2026-10-05 的 PR 截止日，后续可以核对新增任务数、合并任务的领域分布、review 记录和 release 说明。如果任务数增加但质量审核变弱，榜单可比性会下降。
榜单口径是第二条线。科研 workflow 评测不只比较模型，还比较 agent harness、沙盒环境、运行预算、工具权限、并发设置和失败重试。若这些条件不透明，30.0%、22.4%、21.4% 这样的百分比很容易被误读为纯模型能力。
第三方复现实验会决定它的公共基准地位。项目README已经给出 Harbor 运行路径，理论上方便外部团队复跑。后续若独立实验室能在同样任务、同样预算和同样代理设置下复现主要结果，Terminal-Bench-Science 才能从“项目方榜单”升级为更强公共基准。
科学家贡献流程还要抵抗任务泄漏和过拟合。开放 benchmark 的价值在开放，也会因为开放而被训练集污染。科学任务还可能包含真实数据和领域软件，如何保证题目可公开、答案可验证、又不被模型简单记忆，是项目能否长期可信的核心。
高风险相邻领域需要安全边界。生命科学、化学、网防和工程控制任务都可能触及双用途问题。Terminal-Bench-Science 本文涉及的是科研工作流评测，不应被夸大成自动科研系统；但随着任务扩展，项目方需要说明哪些任务可公开，哪些执行环境必须隔离，哪些输出需要人工审核。