软件越来越成为科学仪器本身的一部分——观测、分析、模拟,底层全是代码。这也意味着,科学代码里的一个 bug,伤害的不只是程序行为,还可能是论文结论背后的证据本身。但主流 coding agent 评测大多只报告"任务成功与否"的聚合分数,很少回答一个更关键的问题:agent 修不好科学软件时,究竟是怎么失败的?
OpenMOSS 团队 8 月 20 日提交到 arXiv 的 SWE-bench Science,就是冲着这个空白去的(论文地址)。
一个专挑科学软件下手的基准
先看构成:119 个任务,取自 98 个 GitHub 仓库,横跨 20 个科学领域,全部是仓库级(repository-level)的真实修复场景。每个任务归入三种范式之一:Issue-driven(议题驱动)、Expert-exploratory(专家探索)、Engineering-integration(工程集成)。
测试结果相当残酷:表现最好的 agent 是 Claude Code 搭配 Opus-5(max 配置),pass@1 依然低于 50%。也就是说,把当前跑分最亮的编码智能体放到科学软件的修复现场,一半以上的任务拿不下来。
错在哪:四类反复出现的失败机制
比分数更有价值的是失败分析。论文归纳出四种反复出现的失败模式:
- 科学知识或抽象能力欠缺——缺少对应领域的知识或抽象能力;
- 探索跑偏或只做表面修补——探索方向错误,或者停在表面级修复;
- 修复覆盖不全或系统集成失败——补丁没覆盖全,系统集成环节掉链子;
- 无法泛化——把科学知识用到观察到的样例之外时失效。
这四类不是简单的"能力不够",而是四条不同的攻关路线:有的要补知识,有的要改探索策略,有的要改集成方式。聚合分数只能告诉你"多差",失败机制告诉你"往哪改"。
更反直觉的:喂科学知识不一定有帮助
论文还做了一组配对消融实验:移除显式的科学指导,但保留仓库和可执行的工程上下文。结论是"科学知识并非总是有益":
- 恰当对齐的科学信息能约束修复方向,提升平均表现和 token 效率;
- 对齐不当的指导会诱发锚定效应(anchoring),把模型钉在错误方向上,精确修复成功率未必提升。
这对整个 RAG 和 prompt 工程社区都是提醒:上下文里塞进不对的"权威信息",比不塞更糟。
为什么这篇值得认真读
三点个人判断。
其一,coding agent 的通用基准正在快速饱和,而"能修通用 repo"和"能修科学 repo"是两码事。科学软件的特殊性在于:代码是证据链的一环,修复需要领域理解,而不仅是模式匹配。这个基准把边界划清楚了。
其二,失败机制的分类比 pass@1 更有长期价值。它把"agent 不行"这种笼统印象,拆成了可研究、可改进的具体对象——这正是基准该干的事。
其三,"知识注入并非 uniformly beneficial"这个消融结论,直接挑战了"上下文越多越好"的工程直觉。错的指导比没有指导更危险,锚定效应会让模型在错误方向上越走越远。
所以呢
下次再看到 coding agent 刷分创新高的新闻,可以多问一句:它在科学代码上的 pass@1 是多少?在"软件即仪器"的时代,这个数字可能比通用榜单更接近"AI 能否真正参与科学"的答案。