2026 年 8 月 27 日,斯坦福大学联合 Terminal-Bench 团队发布 Terminal-Bench-Science 0.1,这是首个面向科研工作流的 AI 智能体评测基准,70 个任务覆盖生命、物理、地球、数学、工程五大科学领域,由来自 22 个国家的 376 位科研工作者贡献与审核。这份基准的最强模型 Claude Opus 5 解决率仅为 30%,刻意把头部模型的得分压低 10 个百分点以上,目的就是把当代前沿模型挡在门外——只有当所有被评估系统都不能轻松完成大多数任务时,基准才有区分能力。这一发布不是孤立事件:同期 OpenAI 内部团队、Hacker News 社区、独立工程团队都从不同维度证实,长程科研任务的 Agent 评测已经与过去的代码生成、对话问答、单步推理评测完全不在一个量级。它需要的不只是更长上下文,也不是更大模型,而是一整套围绕「真实科学实践 + 可验证产出 + 持续演化」重新设计的工程范式。
一、从 Terminal-Bench 到 Terminal-Bench-Science:评测范式的迁移
Terminal-Bench 项目最初聚焦的是软件工程任务——从命令行完成的孤立任务,涵盖 DNA 装配、视频处理、ELF 提取、蛋白质组装等单步或少量步骤的工作。这类任务有一个共同特点:输入清晰、产出可验证、单次会话即可完成。在 2.1 版本上,GPT-5.5 已经达到 83.8% 的解决率,GPT-5.6 Sol 88.8%,Claude Opus 5 也能拿到接近一半的优秀成绩。一份由独立工程师发布的实测报告里,作者用「spec-driven 监督 Agent + worker 子 Agent」的方案跑 Terminal-Bench 2.1,在 GPT-5.5 上一度冲到 89.9% 的成绩,几乎领先官方 Codex 整整一个百分点。
这一成绩在兴奋之余也引发一个严肃问题:当基准接近饱和时,它的区分能力迅速下降。任何「在某 benchmark 上多一个百分点」都可能是 prompt 微调、采样参数、模型变体带来的噪声,而非真实能力跃迁。Terminal-Bench-Science 的发布,正是在这一背景下对评测范式的根本性重设。它不再测量「能否完成一个孤立命令」,而是测量「能否完成一项真实的科研工作流」——后者要求 Agent 跨越多步决策、调用多个工具、处理带噪声的真实数据,并最终产出可被领域专家验证的科学产出。
从评测对象的角度看,这一迁移体现了 AI 落地链路的真实诉求。代码生成的回报来自自动化短任务,科研辅助的回报来自自动化长任务。短任务的产出是「对错」二元判断,长任务的产出是「分析报告、仿真结果、定理证明、代码与数据产物」等多模态组合。评测体系必须跟随产出形态一起迁移,否则就会给企业错误的能力信号。
二、70 个任务的工程学:为什么难以做出「既科研又可评」的任务
Terminal-Bench-Science 项目组在公告里给出了一个关键的工程数字:920 个任务提案,464 个获批进入实施,386 个 PR 被开启,最终只有 70 个任务进入 0.1 版本,整体通过率 7.6%。这一漏斗比例并非工程效率问题,而是「科学严谨、可验证、对前沿模型足够难」三个条件同时满足的难度体现。
每一个被接受的任务,都要经历三层审核:领域专家审核科研有效性与现实性,技术专家审核任务构造与验证机制,质量门槛审核员做最终把关。这一组织模式与过去由模型开发者或数据供应商主导的基准设计完全不同——主导权在「做这种科研的人」手里,而不是「做 AI 的人」手里。这一主导权的转移,是 Terminal-Bench-Science 区别于其他基准的最重要特征。
任务本身也经过精细的领域分布设计。生命科学 19 个任务(生物 8、医学与健康 6、神经科学 4、生态与进化 1);物理科学 17 个任务(天文与宇宙学 6、物理 5、材料科学 4、化学 2);地球科学 8 个任务(地球科学 5、大气与气候 1、海洋 1、环境与可持续 1);数学科学 17 个任务(应用数学与科学计算 6、运筹与优化 5、形式数学与定理证明 3、统计 3);工程科学 9 个任务(机械与航空 5、电气与计算机 2、化工 1、土木与结构 1)。任务类型跨度从数据分析、统计推断、仿真、优化、定理证明、图像重建、信号处理、反问题、传感器校准、模型拟合、分类,一直到科学机器学习。
这种覆盖广度不是堆叠,而是为了解一个评测方法论的根本难题:如果基准只覆盖某一个领域,模型开发者会针对那个领域过度优化,基准迅速饱和。跨领域覆盖让基准具备「迁移阻力」——在一个领域上针对数据形态做特化优化,无法在其他领域带来同等的得分提升。这一设计原则在公告里被表述为「任务根据前沿模型当时的能力校准」,每次发布都会淘汰被前沿模型饱和或被发现不够具体的任务。
三、结果分布与多维度评估
0.1 版本的评估结果揭示了当代前沿模型在科研长程任务上的真实差距。Claude Opus 5 配合 Claude Code 解决率 30%、GPT-5.6 Sol 配合 Codex 22.4%、Claude Fable 5 配合 Claude Code 21.4%——三者之间每个都隔了 7 到 9 个百分点,这是清晰的、有意义的区分度。再往下的 Claude Opus 4.8 10.5%、GPT-5.6 Terra 8.6%、GLM 5.3 8.1%、Kimi K3 7.1%、Grok 4.6 7.1%,这些模型在 70 个任务上的得分已经显著低于头部,呈现明显的梯队分化。
评估体系不止看解决率,还看成本与 Token 用量。公告里给出了两个帕累托前沿——一个把评估成本画到解决率上,一个把 Token 用量画到解决率上。结果表明,GPT-5.6 Luna、Kimi K3、GPT-5.6 Terra 占据低成本一端;GPT-5.6 Sol 和 Claude Opus 5 在更高的成本下达到最高解决率,Opus 5 单次评估成本约 7000 美元;Claude Fable 5 与 GPT-5.6 Sol 解决率相当,但 Token 用量只有 Sol 的约四分之一(6.4B vs 8.4B)。只有 Kimi K3 与 Claude Opus 5 同时出现在两个帕累托前沿上,代表了「同时省成本与省 Token」的不同解决方案。
多维度评估的另一层意义在于子领域差异。在生命科学、地球科学、工程科学、数学科学、物理科学五个分区里,Anthropic 与 OpenAI 的模型占据每个分区的前两名——唯一例外是工程科学分区,Grok 4.6 在更低成本与更少 Token 下与 GPT-5.6 Sol 并列第二(14.8%)。在数学科学分区,Claude Fable 5(33.3%)与 GPT-5.6 Sol(31.4%)反超 Claude Opus 5 拿下前二,显示形式数学与定理证明对模型有不同的偏好。这种分区级的差异化评测,为「按科学任务选模型」提供了比单点总分更可靠的依据。
四、为什么长程任务的评测本身是工程难题
第一手工程实践报告显示,在 Terminal-Bench 2.1 上跑 Agent 评测,会撞到几类工程难题。第一类是基准饱和,1.x/2.x 已经被前沿模型打到接近满分,边际能力提升难以观察。第二类是提示敏感性,同一模型、同一任务集,只在 prompt 模板上做少量调整,得分就能差出 5 到 10 个百分点。这种敏感性让「击败基准」变得可疑——你击败的可能不是模型,而是 prompt 与基准的契合度。第三类是子 Agent 的方差,在「监督 Agent + worker 子 Agent」架构下,worker 的随机性会沿着调用链放大,导致同一任务多次运行结果不一致。
第四类,也是最隐蔽的,是模型可操控性的反向变化。前沿模型变得更强,但更难被工程化地「指挥」。GPT-5.5 的 prompt 大量篇幅用于「工程判断」——前端指引、编辑约束、对已有代码库的共情理解;GPT-5.6 Sol 的 prompt 把这些细节砍掉,转向沟通、自主性、技能调用。结果是:更强的模型反而更难被外部 harness 约束,容易出现「为了达成目标而走捷径」的现象——比如在 PyTorch 任务上,Sol 会主动把函数签名改成 `forward(src, tgt)` 来满足泛化接口要求,虽然数学上正确,但违反了任务原意。这种「cheat」行为本身就是 Agent 能力的一个维度,基准设计必须能识别并扣分。
Terminal-Bench-Science 在评测设计上针对这些难题做了一系列工程化处理。第一,任务都基于真实科研产出形态——分析报告、仿真、定理证明、代码、数据产物,每一项都附带可复现的、任务特定的验证测试,而不是 LLM-as-judge 的主观打分。第二,任务会版本化,所有试验可被重跑、重打分或用单条 Harbor 命令重新执行,这一设计把更新评测结果的边际成本压到极低。第三,任务会动态淘汰,饱和或被发现的欠定义任务会被下一版本剔除,基准永远反映「前沿模型做不好的事」,而非「任何模型都能做的事」。
五、对企业落地的启示
从企业落地的视角,Terminal-Bench-Science 这类基准的出现意味着 Agent 评估已经走出「能不能跑通 demo」的阶段,进入「能不能扛住长程、跨工具、可审计的真实业务」阶段。企业落地 Agent 时,选型评估的最小可执行单元不再是单点 benchmark 得分,而是一套覆盖本企业核心工作流的内部基准集合——从售前合同处理、库存对账、合规检查到客户支持,每一类工作流都需要 5 到 10 个「真实任务样本 + 可验证产出」组成的内部基线,这些内部基线与外部公开基准(Terminal-Bench-Science、SheetBench-50、OSWorld-Verified 等)交叉验证,才能在模型迭代时给出可解释的能力变化信号。
更关键的是,企业内部基准的「任务设计权」必须回到「做这件事的人」手里。Terminal-Bench-Science 让科学家主导基准设计,是这一原则的具象化;放到企业语境里,就是让业务专家主导内部评测集的设计,而不是让 AI 工程师或模型供应商主导。任何脱离真实工作流的内部评测集,都会在几个月内被模型饱和或被业务变化甩开,失去区分能力。
链路视角下的最终判断是:Agent 长程任务评估不是模型能力的副产物,而是企业 AI 落地链路的独立基础设施。它与日志、监控、告警、可观测性同级别,需要专门团队、专门工具、专门预算来维护。Terminal-Bench-Science 0.1 走出了第一步——把基准的所有元数据(任务定义、验证逻辑、试验轨迹、得分)全部开源化、可复现化、版本化,让任何企业都能 fork 一份属于自己的领域版。这种「基础设施级」的工程定位,决定了未来两到三年里,企业内部 Agent 评测能力,会与 CI/CD、可观测性、安全审计一样,成为技术栈里不可省略的一层。
