OpenAI 科学计算提速，但验证成为瓶颈

OpenAI 于 7 月 28 日发布了八项科学计算案例研究，展示编程智能体如何处理从日常维护到完整重写基因组学软件的项目。结果带来了一些显著的性能提升，也暴露出一个更棘手的限制：代码生成正比验证更快地变得容易。

这份新的实地报告主要考察了生命科学领域完成的项目。其中五项仅使用 Codex，另外三项将 Codex 与 Claude Code 结合使用。研究人员将这些智能体用于打包、优化、框架迁移、编程语言转换，以及面向 GPU 的重新设计。

这种组合让 OpenAI 的科学报告比又一项编程基准测试更具参考价值。这些智能体处理的是具有真实科学后果的软件，而非孤立的编程练习。不过，OpenAI 和参与研究的研究人员并未独立复现每一项报告中的基准结果。大多数结果仍是各项目负责团队给出的特定案例描述。

因此，核心矛盾并非 Codex 与 Claude Code 之间的竞争，而是快速实现与缓慢科学验证之间的冲突。智能体如今可以修改数千行代码、转换成熟系统，并生成看似合理的统计扩展。科学家仍必须判断，这些变化是否保留了实验本身的含义。

Anthropic 从不同角度得出了类似结论。其关于长时间运行智能体的研究认为，自主科学编程依赖测试预言机，即能客观告知智能体是否取得进展的机制。两家公司都指向了相同的分工：智能体负责实现，专家负责定义、测试和判断。

OpenAI 科学计算不再止于代码建议

报告中最重要的变化，是科学家愿意委托的工作规模。

AI 编程工具最初是自动补全系统，能够建议一个函数或补完一行代码。OpenAI 报告中的项目则将智能体应用于整个代码仓库。这些系统可以检查现有代码、编辑多个组件、执行测试、解读故障，并持续朝既定目标推进。

这八项案例研究涵盖六种彼此重叠的项目类型，包括轻量维护、针对性优化、兼容性迁移、转换到新的编程语言、以性能为导向的重写，以及新增科学能力。

其中一个项目对 cyvcf2 进行了现代化改造。cyvcf2 是一个用于读取和写入基因组变异文件的 Python 库。经历十年来 Python、依赖管理和打包系统的变化后，这个库越来越难以构建和发布。GPT-5.5 帮助其用统一系统替换了旧有打包流程，相关改动已合并至上游。

这个例子之所以重要，是因为维护工作很少能获得与新方法或论文同等的学术认可。然而，过时的构建系统可能会阻止其他科学家安装或复用原本有价值的研究软件。编程智能体可以承接那些必要、重复且难以获得资金支持的工作。

MHCflurry 案例走得更远。MHCflurry 预测哪些蛋白质片段可能出现在细胞表面，这项任务与免疫学和癌症研究有关。其老化的 TensorFlow 和 Keras 依赖带来了日益严重的维护问题。

智能体帮助将该软件包迁移至 PyTorch，同时保留已发布模型及其预测结果。据贡献者介绍，这次重写涉及约 130 个文件、近 10,000 行代码。在审查人员确认现有权重能够正确加载、预测结果保持在既定容差范围内后，它随 MHCflurry 2.2.0 发布。

这些项目代表了智能体 AI 科学的实践核心。智能体并不决定某项生物学假设是否有意义；它降低了维持支撑该假设的软件可用所需的工程投入。

OpenAI 的案例也说明了为何成熟的科学工具是有吸引力的目标。成熟软件包拥有可运行的行为、现有测试套件和参考输出。这些产物为研究人员评估智能体所作改动提供了依据。

从零开始的科学开发则宽容得多。当不存在公认的实现时，研究人员必须在信任结果之前设计模拟、统计检查或其他验收标准。目标越缺乏客观性，监督智能体就越困难。

因此，这份报告描述的是有边界的进展。智能体能够在比普通助手更广的范围内完成实现工作，但并未消除对科学指导的需求；当成功可以通过外部标准衡量时，它们表现最佳。

旧研究代码已成为昂贵的基础设施

当数据增长使被忽视的科学软件愈发难以容忍时，编程智能体正在到来。

研究软件通常始于论文的辅助材料。一个小型学术团队构建足够的代码来测试某种方法，发表结果后转向下一个获得资助的问题。其他研究人员随后可以采用这些代码，直到原型在不知不觉中变成共享基础设施。

激励机制仍然错位。相比打包、文档、测试或依赖更新，大学更直接奖励论文、资助和新颖的科学贡献。许多实验室也缺乏专业软件工程支持。

在当前这波智能体 AI 浪潮之前收集的证据显示了问题的规模。一项研究代码研究在干净的计算环境中测试了逾 9,000 个已发表的 R 脚本。研究发现，其中 74% 在首次运行时失败，经过自动清理后仍有 56% 失败。

另一项对 98 个计算生物学工具的调查发现，当研究人员按照其文档中的安装说明操作时，57.1% 会失败。另有 27.6% 即使经过人工干预也无法安装。根据这项组学软件研究，一次自动安装失败平均会增加约 70 分钟的工作量。

这些数字并不意味着每一次失败都会导致科学结果出错。它们表明，在分析开始之前，可能已经耗费了多少研究时间。损坏的依赖、缺失的配置细节和未记录的假设，会让软件复用变成调查工作。

基因组学让这种压力尤为明显。过去十年中，测序成本的下降速度快于下游分析成本。实验室能够以足以对存储、计算和处理软件流水线造成压力的规模生成数据。

问题不只是代码运行缓慢。脆弱的分析流水线会降低可重复性，使旧结果难以重新审视，并在实验室之间造成细微差异。即使学术激励将实现视为一次性产物，它仍然成为实验方法的一部分。

智能体 AI 科学改变了处理这类技术债的经济性。研究人员可以要求智能体更新依赖、添加测试、迁移框架或检查性能瓶颈。过去会与论文或资助申请截止日期竞争的工作，如今更容易尝试。

这种转变给大学、资助机构和实验室负责人带来的压力，不亚于软件开发者。如果实现成本降低，人们的预期就会上升。研究人员将更难为发布无法安装、测试或复现的代码辩解。

不过，较低的开发成本并不会自动形成持久的基础设施。一次生成的重写仍需要审查人员、发布、文档、用户支持和未来维护。智能体可以减少积压工作，却无法创建一个对结果负责的机构。

对于试图保留决策、基准和实验背景的实验室而言，一个可搜索的工程知识库可以支持这种管理工作。它无法验证科学输出，但可以让设计选择和审查证据与代码保持关联。

最快的提升来自明确的答案

当研究人员能在实现开始前定义成功标准时，智能体交付了最强的结果。

HI.SIM 提供了最清晰的例子。这个基因组模拟器包含重复计算、不必要的数据复制和大量小文件写入。GPT-5.2 接收了一个零样本优化请求，并在无需进一步人工干预的情况下完成了局部改动。

在四个工作负载组成的基准测试套件中，贡献者报告称总运行时间减少了 30.97%。优化后的软件产生了字节级完全一致的输出，也就是说每一个输出字节都与参考版本匹配。这种严格比较大幅减少了性能提升是否改变科学结果的不确定性。

hifiasm 项目采用了更灵活的目标。Hifiasm 根据长 DNA 测序读段组装基因组，其运行时间集中在若干计算需求很高的操作中。GPT-5.5 优化了现有 C 实现中的部分热点路径。

贡献者报告称，在留出的合成数据上，运行时间减少了 25.1%；在记录的人类 20 号染色体读段上，降幅为 14.7%。这些改动还必须满足评估前定义的读段排序阈值。

RustQC 实现了报告中最大的加速幅度。它以一个单遍 Rust 程序替换了 RNA 测序工作流中 15 个比对后质量控制步骤。在包含 1.86 亿条读段的数据集上，顺序任务运行时间从 15 小时 34 分钟降至 14 分钟 54 秒。

这一结果意味着超过 60 倍的降幅。据报告，磁盘流量也从 2.5 TB 降至 0.1 TB，同时经测试的数值输出仍保持等价。贡献者还报告称，Trim Galore 的执行速度提升了七倍，FastQC-Rust 则提升了三倍。

HelixForge 采用了面向硬件的方法。该项目用 GPU 原生实现替换了一个 CPU 流水线，后者用于将已知突变插入测序读段。这类合成数据可帮助研究人员测试变异检测工具是否能在已知位置发现突变。

在一个供体和一个 10 兆碱基区域上，贡献者报告称编辑阶段运行速度提高了 98.6 倍，端到端运行时间提高了 59.6 倍。平均突变频率误差从 0.076 降至 0.034，而一种可检测到的重新比对伪影几乎被消除。

这些结果很可观，但不应被视为关于编程智能体生产力的普遍结论。完整报告明确将其数值发现标注为贡献者报告且仅适用于特定案例。各团队使用了不同模型、项目范围、数据集和验证目标。

这种模式比综合平均值更重要。对于范围明确的优化，精确的输出等价性效果良好；预测容差有助于框架迁移；具有已知答案的模拟数据集则支持引入新行为的项目。

这正是 OpenAI 科学计算项目取得成功背后的机制。智能体并不会自行识别科学真相。研究人员将科学需求转化为可执行的测试，再利用智能体搜索实现空间。

这些案例同样依赖分阶段迭代。团队将宽泛目标拆分为更小的改动，构建中间基准，并在失败出现时修订验证体系。初始实现很快完成，但细微的数值差异和真实场景中的边界情况耗费了更多时间。

最后这一公里使得该报告无法支持一种简单的自动化叙事。智能体 AI 科学加速的是流程中间环节，即将规范转化为代码的过程。它并未消除创建规范所需的工作，也无法省去此后建立令人信服证据的工作。

看似合理的代码并非科学证据

该报告最强烈的警告是：智能体可能言之凿凿，却产出在科学上存在缺陷的结果。

bayesm-rs 案例清晰揭示了这一风险。研究人员使用 GPT-5.2，将 R 软件包中选定的贝叶斯统计模型和采样器翻译为 Rust。基础重写拥有成熟的参考实现，因此团队能够将后验行为与原始版本进行比较。

当智能体加入新的统计扩展时，问题随之出现。初始输出看起来合情合理，但其实现包含采样器和 HART 特定逻辑方面的缺陷。审查人员修正了这些问题，随后受测采样器才通过收敛性和基于模拟的校准检查。

一张看似合理的图表或一个运行稳定的程序并不够。统计软件即便能够成功运行，也可能是在对错误的分布进行采样、采用不恰当的简化，或将偏差隐藏在看似合理的平均值背后。

rustar-aligner 项目带来了另一项验证挑战。广泛使用的 RNA 测序比对工具 STAR，累积了超过 20,000 行 C 和 C++ 行为。智能体协助构建了一个旨在复现这些行为的 Rust 替代版本。

贡献者报告称，在 10,000 条酵母 RNA 测序读段上，多个比对字段的单端数据一致率为 99.815%，双端数据一致率为 99.883%。这些数字听起来几乎等同于完全一致。然而在科学流程中，剩余的差异仍可能需要调查。

某项差异可能源于无害的实现选择、重写版本中的漏洞，或原始版本里未被记录的约定。智能体无法仅凭一个百分比解决这一问题。领域专家必须沿着下游分析追溯差异，并判断哪种行为在科学上可被接受。

这一局限也体现在独立评估中。FrontierSWE 通过广泛的实现和研究级问题来测试编程智能体。报告指出，智能体没有完整完成其五项从零开始的实现任务中的任何一项，进一步凸显了仓库工作与开放式工程之间的差距。

当生成的代码影响科学行为，而非打包或性能时，风险会进一步增加。项目引入新方法时，精确比较将变得不可能。研究人员随后必须选择模拟方法、容差和结果衡量标准，而这些选择可能遗漏隐藏的失效模式。

真实数据带来了更大压力。小型合成工作负载能加快迭代，但 OpenAI 的贡献者反复发现，当切换到真实数据集后，会出现额外的边界情况。验证套件只能检测其被设计用来检查的行为。

Anthropic 对编程智能体的更广泛研究也支持专业知识的必要性。其对约 400,000 个会话的分析发现，人类做出了大多数规划决策，而 Claude 完成了大多数执行决策。领域专家之所以取得更好结果，是因为他们能够识别错误，并从误解中恢复。

因此，Codex 与 Claude Code 之间的竞争差异只是次要问题。两者都正朝着更长时间、更自主的执行方向发展。真正重要的竞争，是不断增长的智能体自主性与科学组织审计其产出能力之间的较量。

研究人员还应区分代码验证与科学验证。单元测试可以确认一个函数的行为是否一致，却无法证明其背后的生物学假设是否恰当、数据集是否具有代表性，或某种解释是否足以支撑发表的结论。

OpenAI 的科学发现让专家承担起新的角色。他们花在输入实现代码上的时间更少，更多时间用于设计验收标准、选择参考数据集、调查差异，以及判断证据是否足够有力以发布。

这并非消除人类劳动，而是将劳动从构建转移到判断。将智能体输出视为成品代码的实验室，将错过报告最核心的教训。

更快的重写可能让科学社区碎片化

低成本实现带来了第二个问题：技术上令人印象深刻的项目过多，却没有明确的负责人。

科学软件承载的不只是源代码。成熟项目会积累兼容性承诺、命名惯例、文档、用户预期，以及针对异常数据集的变通方案。其中许多约束从未出现在正式规范中。

智能体可以将函数翻译为 Rust，或替换旧的机器学习框架。但它无法自动继承原始项目所积累的信任。用户需要知道，谁将审查问题、发布更新、修正漏洞，以及应对周边生态系统未来的变化。

OpenAI 的报告指出，在可行时，及早与维护者协调是首选路径。cyvcf2 的现代化改造进入了原项目。MHCflurry 的框架迁移也以上游发布的形式交付，为未来开发保留了一个受到认可的归属。

由于 STAR 已不再积极维护，Rustar-aligner 采取了不同路径。替代版本转由新的社区进行管理。这种安排可以奏效，但需要可见的负责人和可信的维护计划。

危险在于出现一波并行重写。如果多个实验室各自生成某个受信任工具的新版本，每个版本的行为都可能逐渐偏离。用户会分散到不同软件包中，而本就有限的专家审查者也会被分摊到更多代码库。

当不同实现产生略有不同的科学结果时，碎片化尤其危险。一个实验室生成的数据，可能无法再与另一个实验室的数据顺畅整合。纵向研究也可能在流程升级后改变行为。

因此，更快的编码提高了治理的价值。项目需要贡献规则、基准测试套件、发布流程、兼容性政策和明确的归属说明。资助方可能需要将维护视为科学基础设施，而不是一种非正式义务来支持。

其中还存在安全维度。编程智能体往往可访问代码库、包管理器、测试系统和计算资源。更长时间的自主运行，为智能体误解请求或与不安全依赖交互留下了更多空间。科学验证不能取代常规的安全审查。

OpenAI 的科学计算工作将面临与更广泛开源软件相同的制度问题：当一项由智能体协助的改动看似正确、通过了现有测试，却在日后造成重大错误时，谁应承担责任？

这份现场报告没有解决这个问题。它建议开展协作和管理，但这些都依赖资金、激励机制和愿意承担责任的维护者。智能体 AI 科学可以减少编写补丁的劳动，却无法保证五年后仍有人负责。

这种不确定性应当影响项目选择。与社区一起更新一个正在积极维护的库，与发布一个竞争性的重写版本，是不同的事情。单凭速度提升，并不足以证明破坏兼容性或制造新的维护负担是合理的。

指挥智能体的科学家应首先确定这项工作的未来归属。验证能够证明一个发布版本今天符合既定标准。管理则决定了在依赖项、数据集和研究实践发生变化后，用户能否继续信任它。

三个信号将表明这一模式是否成立

下一阶段必须证明，这些孤立项目能否成为可重复的科学实践。

第一个信号是独立复现。OpenAI 将其报告描述为回顾性和探索性的，参与团队仍需对各自项目的具体主张负责。外部团队应在更多硬件、数据集和下游工作流程上复现其中的重点基准。

复现将强化这样一种判断：编程智能体能够可靠地实现科学计算现代化。若大型性能差异在原始环境之外缩小，即使个别项目仍然有用，也会削弱广泛生产力主张的说服力。

第二个信号是上游采纳。更多由智能体协助完成的改动，应通过常规的审查、测试和发布流程进入既有项目。上游接受表明，维护者认为这项工作符合软件的技术与社区要求。

不断增加的一批独立重写版本则会传递相反信号。这将表明，智能体生成替代方案的速度快于社区评估或吸收它们的速度。这样的结果或许会促进实验，但也会让共享基础设施更缺乏一致性。

第三个信号是标准验证实践的发展。科学领域需要可复用的测试框架、参考数据集、容差政策，以及用于记录智能体协助改动的溯源记录。这些系统必须检验科学含义，而不仅是代码能否运行。

近期的竞争可能会加快这项工作。Anthropic 一直强调面向科学智能体的确定性检索、测试预言机和可审计产物。2026 年发表在 Nature 上的一项科学软件系统，也反映出人们对帮助领域专家产出实证软件的智能体日益增长的兴趣。

最终胜出的不会是写出最多代码的模型，而是能够让错误显现、保留证据，并在部署后明确责任归属的工作流程。

对开发者而言，这意味着应在增加更多自主性之前先构建评估基础设施。对研究负责人而言，这意味着应将验证时间视为一等项目成本。对资助方而言，这意味着应在提供模型访问权限的同时，支持维护者和共享基准。

科学领域之外的知识工作者也应关注这一点。只要软件承载专业判断，底层模式就同样适用。智能体可以加快金融、工程、政策或运营中的实现工作，但领域专家仍必须定义正确性并调查例外情况。

OpenAI 科学计算正从演示走向制度检验。这八个项目表明，智能体能够完成过去需要大量专业工程投入的工作。它们也表明，更快的实现使验证和管理变得更显眼，而不是更不必要。

实际的下一步，是选择一个拥有强参考输出的范围明确项目。在智能体修改任何内容之前定义验收标准。记录每一项基准、差异和人工决策。然后追问：所得证据是否足以说服一名独立审查者？

这个问题的重要性，远超过第一版实现出现得有多快。如果研究机构能够让可靠的审查机制与智能体式 AI 科研同步规模化，科学软件就能变得更快、更具持久性。否则，明天的技术债只会以更高的速度被制造出来。