推荐这份报告，OpenAI 记录了 8 个科学软件加速项目的实况。 核心发现：瓶颈不在写代码，在验证——agent 经常对明显错误表达高度自信。 OpenAI 在 7 月 28 日发布了一份实地报告，记录了 8 个用 coding agent 加速科学计算软件的案例。全文基调不是"AI 将取代科学家"，而是一个更具体的观察：瓶颈已经不在代码实现，而在验证。 8 个项目 覆盖基因组学、免疫学、统计学和 RNA 测序。5 个项目独立使用 Codex，3 个结合 Codex + Claude Code。任务分三类：打包和构建系统清理、现有代码的性能优化、以及完整的语言或后端迁移。 几个具体数据： • HI.SIM（DNA 测序读段模拟器）：GPT-5.2 和 GPT-5.6 分别做了一轮自主优化，运行时减少 31%，输出不变 • Hifiasm（基因组组装）：优化目标上减少 25%，独立的人类测序数据上减少约 15% • MHCflurry（蛋白质片段预测）：TensorFlow/Keras 后端完整迁移到 PyTorch，保持已发布模型权重兼容 • bayesm-rs（R 统计模型的 Rust 移植）：单线程快 2.3-2.7 倍，8 线程快 4.4-9.5 倍 两个更极端的案例： • RustQC 把 15 个独立 RNA 质量检测工具合并成单一程序，运行时减少 60 倍，磁盘 I/O 减少 25 倍 • HelixForge 是 GPU 原生重建的突变模拟工具 BAMSurgeon，在真实人类数据 benchmark 上运行时减少约 60 倍 核心发现：验证，不是代码生成，是真正的瓶颈 所有贡献者一致观察到同一个模式：agent 处理有明确边界和可衡量目标的实现请求时能力很强，但无法判断自己的输出是否科学上正确。agent 经常对包含明显错误的工作表达高度自信。 这意味着研究者的实际负担从"写代码"转移到了"构建验收测试"——精确输出匹配、与现有工具的等价性检查、或者用模拟数据预先建立的标准答案。单个 reference 不足以验证 agent 的输出，需要多个维度的确认。 一个贡献者的原话被引用了两次："让 agent 跑得快是一回事，让科学走得远仍然需要专家的指导、理解、品味和 care。" 维护问题 报告提出了一个值得注意的警示：更低的工程成本双向作用。它让一个两三人团队可以承担原本需要资助性工程雇佣的重建工作，但也让三个不同实验室更容易产生同一工具的三种不兼容版本。报告建议在 agent 生成第一行代码之前就确定谁负责维护重建的工具。 原文： #Codex# #ScientificComputing# #AgentEngineering#