编码智能体的双面性：60倍加速与科学正确性困境

一份来自 OpenAI 及其学术合作伙伴的实地报告显示，coding agent 能够更新老旧的科研软件并提升其运行速度。然而，大量工作只是从编写代码转移到了验证结果。

许多被广泛使用的科研工具，最初只是为某一篇论文编写的配套代码。小型学术团队往往没有足够的时间和资源进行适当的测试、维护或性能优化。结果就是，这些脆弱的软件虽然对整个研究领域至关重要，却需要持续不断地修补。OpenAI 及其学术合作伙伴发布的一份实地报告表明，AI coding agent 或许能帮助填补这一缺口。

报告记录了八个案例研究，其中大多数来自生物学领域。在这些项目中，研究团队使用了 Codex 和 Claude Code 等 coding agent。项目范围涵盖基础维护、针对性优化，以及使用现代编程语言进行彻底重写。

八个项目的范围从简单的构建系统现代化，一直到完全基于 GPU 的原生重写。｜图片：OpenAI

Coding agent 带来了超过 60 倍的性能提升

其中一个相对简单的项目，是对用于读取遗传数据的 Python 库 cyvcf2 进行现代化改造。GPT-5.5 用现代化方案替换了它已经过时的构建和安装流程。

MHCflurry 的迁移则复杂得多。MHCflurry 是一个免疫学模型，用于预测免疫细胞会识别哪些靶标。Claude Code 和 Codex 轮流担任开发者和审查者，将大约 10,000 行代码从 TensorFlow 移植到 PyTorch。

rustar-aligner 项目的目标更加宏大：使用 Rust 从头重建 STAR。STAR 用于把来自细胞的测序读段映射到基因组中的对应位置。原版包含超过 20,000 行 C 和 C++ 代码，尽管仍是许多科研工作流的一部分，却已经无人积极维护。

为了检查重写版本的行为是否与原版一致，团队使用来自酵母细胞的 10,000 条短测序读段对两个工具进行了测试。对于单端读段，rustar-aligner 在 99.815% 的情况下与 STAR 产生了相同结果；对于双端读段，两者的一致率为 99.883%。

比较内容不仅包括读段映射到基因组中的位置，还包括两个程序为每条读段生成的其他几个关键字段。不存在某个工具成功映射、而另一个工具未能映射的读段。

RustQC 把 15 个独立的质量控制工具整合进一个程序，因此实现了幅度最大的性能提升。在一个大型数据集上，运行时间从 15 小时 34 分钟缩短至 14 分 54 秒，提速超过 60 倍。

另一个名为 HelixForge 的项目，则用可在 GPU 上运行的版本替换了一个用于生成合成基因组数据的工具。在一项使用单个供体数据和一段 1,000 万碱基对基因组区域的测试中，HelixForge 完成整个工作流的速度是 BamSurgeon 的 59.6 倍。仅核心计算步骤就快了 98.6 倍。

这款 GPU 原生重写版本在所有测量指标上都击败了成熟的 CPU 工具，而不仅仅是速度。｜图片：OpenAI

代码运行得快，仍然可能得出糟糕的科学结果

纵观这些案例研究，Agent 可以迅速完成定义明确的任务，但无法可靠地判断自己的工作在科学上是否正确。即使生成的代码包含错误，这些系统往往仍会表现得信心十足。

“有了 coding agent，快速推进相当容易；但就目前而言，要想在科学研究中走得更远，仍然需要专家的指导、理解力、判断力和严谨态度。”cyvcf2 开发者 Brent Pedersen 写道。

负责 RustQC 项目的 Philip Ewels 将 Agent 描述为“表达流畅、极具说服力，却会以一种很容易被忽略的方式自信地犯错”。他从不让模型自行判断其工作是否准确，而是另外构建了一套独立的测试框架。

性能提升来自一系列细小的代码修改，而非某一次单独的优化。｜图片：OpenAI

bayesm 案例表明，这类错误可能极难发现。它的 Rust 重写版本比原版快 2 到 20 倍，但两种高级方法的早期版本都包含仅凭输出结果很难察觉的错误。

在其中一种方法里，Agent 把一个关键控制参数弄反了，导致程序使用了预期值的倒数。另一个独立的 bug 则直接影响了计算过程。研究人员将其与数千个结果已知的合成数据集进行详细的校准测试后，才发现这个问题。

统计校准发现了此前一致性测试未能检测出的 bug。｜图片：OpenAI

另一种名为 HART 的方法，整体上生成了看似合理的结果，但仍存在多个缺陷，包括不必要的高成本计算，以及缩放不正确的校正因子。仅凭看似合理的测试结果，无法证明代码是正确的。

2025 年初，一次将 MHCflurry 移植到 PyTorch 的尝试曾以失败告终。开发者 Sergey Feldman 如今认为，失败的原因在于当时可用的模型，而非 coding 工具本身。在他看来，只有较新的模型世代才足够可靠，能够独立完成这类工作中的大部分任务。

人类定义测试，Agent 编写代码

这些项目采用了相当一致的分工方式：人类负责定义目标、成功标准和验证方法，Agent 则负责具体实现。

hifiasm 项目展示了这种分工在实践中如何运作。Hifiasm 用于根据大量短片段组装出完整基因组。在让 GPT-5.5 对其进行优化之前，研究人员先搭建了一套测试环境，并准备了相互独立的训练数据集和验证数据集。随后，模型找到了一些改进方案，使该工具在真实人类基因组数据上的运行时间缩短了近 15%。

用于模拟遗传数据的库 HI.SIM 所需的人类参与更少。GPT-5.2 只用一轮操作，就找到了优化程序各个部分的方法。之后，使用更新模型进行的第二轮操作又发现了更多改进。所有修改结合起来，在不改变输出结果的前提下，将运行时间缩短了约 31%。

低成本重写带来了维护难题

报告作者还粗略估算了潜在的成本节省。如果 Agent 能够解决科研软件中四分之一到二分之一的安装问题，那么在 100 个软件包的范围内，节省下来的科研时间价值将在 60 万美元至近 500 万美元之间。仅就 NumPy 而言，报告估计 Agent 每年就能节省约 650 小时的维护工作。

除了验证和科学准确性之外，长期维护仍然是一个尚未解决的重大问题。低成本重写可能会割裂用户社区，也会进一步分散经验丰富的维护者本就有限的时间和精力。

各团队采取了不同的项目归属和维护策略。有些改动被直接合并进原项目。由于 STAR 已经停止维护，rustar-aligner 转由 scverse 研究联盟负责。FastQC 的作者拒绝用 Rust 重写版本替换原工具，因此团队把发现的改进方案加入原有的 Java 版本，同样实现了三倍的性能提升。

这份实地报告回顾了已经完成的项目，并以参与者的叙述为依据。报告作者强调，这些发现并非来自具有代表性的研究。不过，他们仍然认为，主要瓶颈正在从编写代码本身，转向验证、科学审查，以及为维护和未来开发划定清晰的责任归属。

同样的模式也出现在科研之外的软件开发领域。METR 的一项研究发现，在广泛使用的 SWE-bench Verified 基准测试中，被判定为通过的解决方案，约有一半会被真实项目的维护者拒绝。

另一项针对开发者使用 AI 生成代码时所遇挫败感的研究，也发现了类似的权衡：生成代码时节省下来的时间，可能转而消耗在代码审查上。由于 AI 生成的漏洞报告占用了维护者的时间，却没有带来有用结果，curl 项目已经关闭了其漏洞赏金计划。

这份实地报告也是 OpenAI 全面进军科学领域的一部分。该公司已经组建了一支由 Kevin Weil 领导的专门科学团队。他预计，2026 年之于科学，将如同 2025 年之于软件工程。4 月，OpenAI 推出了面向生命科学研究的模型 GPT-Rosalind，并为 Codex 发布了一款可免费使用的生命科学 plugin，将模型与 50 多个公共数据库和生物学工具连接起来。

没有炒作的 AI 新闻——由人类精选

订阅 THE DECODER，即可享受无广告阅读、每周 AI 新闻通讯、每年六期独家前沿报告“AI Radar”、完整历史归档访问权限，以及评论区访问权限。

继续阅读，了解完整情况。订阅不炒作的新闻报道。

访问 THE DECODER 的所有文章。

不受干扰地阅读——没有 Google 广告。

访问评论和社区讨论。

每周 AI 新闻通讯。

每年 6 期：“AI Radar”——深度解析关键 AI 主题。

参加 KI Pro 在线活动最高可享 25% 优惠。

访问我们完整的十年文章归档。

获取来自 The Decoder 的最新 AI 新闻。