前言¶
科研軟件有一個長期被忽視的痛點：很多工具最初只爲某篇論文或某個項目而寫，後來卻被整個領域沿用，卻幾乎沒有人專職維護。安裝失敗、依賴過時、性能瓶頸、框架遷移——這些「不性感」的工程活，在實驗室裏往往排不上優先級，但拖慢的是實打實的研究進度。
2026 年 7 月 28 日，OpenAI 發佈實地報告《Scientific Computing in the Age of Agentic AI》（智能體 AI 時代的科學計算），彙總 8 個由科研團隊主導、藉助編碼 Agent 改造軟件的案例，主要覆蓋基因組學、免疫學、統計建模與 RNA 測序等生命科學方向。報告由參與項目的維護者自述寫成，屬於回顧性、探索性的實地記錄，而非隨機對照試驗或代表性抽樣調查——這一點在閱讀結論時需要始終放在心裏。
報告的核心判斷並不「喊口號」：Codex、Claude Code 以及 GPT-5.5、GPT-5.2 等前沿模型，確實可以在安裝打包、語言移植、性能優化乃至大規模重寫等任務上顯著提速；但它們無法替代人類判斷軟件是否在科學意義上「算對了」。瓶頸正從「寫代碼」轉向「設計測試、驗證輸出、明確長期維護責任」。
報告背景與參與工具¶
OpenAI 這份報告共收錄 8 個項目。其中 5 個僅使用 Codex，另外 3 個同時使用 Codex 與 Anthropic 的 Claude Code。任務類型大致分三類：
- 打包與構建系統現代化：解決「裝不上、測不了、發不了版」的問題；
- 既有代碼的性能優化：在保持輸出一致的前提下壓縮運行時間；
- 語言/後端遷移或重寫：例如 TensorFlow 轉 PyTorch、C/C++ 轉 Rust、CPU 邏輯改 GPU 原生實現。
參與工具橫跨 OpenAI 的 Codex、GPT-5.5、GPT-5.2，以及 Claude Code。部分貢獻者提到，2025 年初的模型能力尚不足以完成 MHCflurry 這類大規模遷移，到 2026 年的新一代模型才具備可行性——這說明案例結果與當時可用的模型代際強相關，不宜簡單外推到所有代碼庫。
八個案例：Agent 擅長什麼¶
1. cyvcf2：把 legacy 構建換成現代打包流程¶
cyvcf2 是讀寫基因組變異文件的 Python 庫。維護者 Brent Pedersen 使用 GPT-5.5，將舊的構建與打包體系替換爲統一的現代流程，目標是讓安裝、測試與發佈更順暢。Pedersen 在報告中寫道：「用編碼 Agent 很容易跑得快；但在科學裏要走遠，仍需要專家的指導、理解、品味和細緻。」
2. MHCflurry：約一萬行 TensorFlow 遷到 PyTorch¶
MHCflurry 用於預測 T 細胞可能識別的蛋白片段，是免疫學領域的常用模型。團隊使用 Claude Code 與 Codex 交替承擔實現與審查角色，將約 1 萬行 TensorFlow/Keras 代碼遷移到 PyTorch，同時保持與已發佈模型權重的兼容。這類遷移對維護性至關重要，但也風險極高：程序能跑、數值看起來合理，不代表生物學假設被正確保留。
3. rustar-aligner：STAR 的 Rust 重寫¶
STAR 是 RNA 測序讀段比對領域的經典工具，原代碼超過 2 萬行 C/C++，且已缺乏活躍維護。貢獻者 James M. Ferguson 藉助 Agent 完成 Rust 版 rustar-aligner。在 1 萬條酵母細胞短讀段測試中，單端比對與 STAR 一致率爲 99.815%，雙端爲 99.883%；雙方均未出現「一方完全比對、另一方完全失敗」的讀段。由於 STAR 原項目不再維護，rustar-aligner 最終由 scverse 社區接手。
4. RustQC：15 個 QC 工具合併爲一個¶
Phil Ewels 主導的 RustQC 將 15 個 RNA 測序質控工具整合爲單一程序。在一個大數據集上，運行時間從 15 小時 34 分鐘降至 14 分 54 秒，提速超過 60 倍；磁盤 I/O 約降 25 倍。配套的 FastQC-Rust、Trim Galore 重寫分別約快 7 倍與 3 倍，且行爲與原工具保持一致。Ewels 沒有讓模型自行評判正確性，而是構建了獨立的測試 Harness，用可量化的驗收標準做對照。
5. HelixForge：GPU 原生替代 BamSurgeon¶
HelixForge 是對突變模擬工具 BamSurgeon 的 GPU 原生重建。在涉及真實人類數據、約 1000 萬鹼基區域的基準測試中，完整流水線約快 59.6 倍，核心計算步驟約快 98.6 倍；團隊還報告其生成的突變頻率更接近設定目標，並修復了原工具產生僞影的若干缺陷。
6. hifiasm：基因組組裝工具的性能調優¶
hifiasm 用於 PacBio HiFi 讀段的基因組組裝。貢獻者 Suyash Shringarpure 先自行構建訓練集與驗證集，再讓 GPT-5.5 尋找優化點。在優化目標數據集上運行時間約降 25%，在真實人類基因組數據上約降 15%。Agent 能自行搭建基準腳手架並提出候選方案，但提供 profiling 結果、引導模型避開重複失敗路徑，仍依賴人類研究者。
7. HI.SIM：DNA 測序讀段模擬器¶
HI.SIM 經歷 GPT-5.2 與更新一代模型的兩輪 largely autonomous 優化。貢獻者 Andrew Ho 報告，在代表性測試集上總運行時間約降 31%，且輸出未改變。Ho 自述並非基因組學專家，也不是 C 程序員，此前常被性能 bug 與打包問題卡住——Agent 讓他這類「能識別問題但無力親手修」的用戶也能推動改進。
8. bayesm-rs：Rust 移植裏的「看起來對、其實錯」¶
bayesm-rs 是 R 包 bayesm 中統計模型的 Rust 移植。在單線程上比原版約快 2.3–2.7 倍，8 線程約快 4.4–9.5 倍，且在預設容差內與原版估計值匹配。但早期版本的兩套高級方法仍藏有難以從輸出表面看出的錯誤：例如 Agent 將某控制參數取倒數；HART 方法存在計算代價過高、校正因子縮放錯誤等問題。團隊最終通過對數千組已知結果的合成數據集做詳細校準才定位問題。
Andrew Bai 與 Andrew Ho 的總結很直白：凡是有明確參照可對照的任務，Agent 處理得又快又準；凡涉及原代碼從未嚴格定義、需要統計判斷的擴展，則必須靠人直接驗證。
失敗與邊界：科學正確性無法外包¶
報告中最值得企業 AI 團隊細讀的部分，不是 60 倍提速的數字，而是驗證失敗的模式。
bayesm 案例說明：軟件可以在數值上穩定、輸出看起來合理，卻在科學假設層面悄悄出錯。Philip Ewels 形容 Agent「 eloquent、convincing，且會以不易察覺的方式 confidently wrong（自信地犯錯）」。Ferguson 在 rustar-aligner 項目裏提到，模型可以聲稱某張圖「看起來沒問題」，但發佈前對 900 多張圖的逐張人工覈查，仍然只能由人完成。
因此，報告反覆出現同一種分工：
- 人：定義目標、驗收標準、驗證方法與長期維護責任；
- Agent：在邊界清晰的任務裏產出實現；
- 人：用獨立 Harness、金標準數據集、與既有工具的 parity check 做最終裁決。
「測試通過」不等於「科學正確」。在科研場景裏，這兩者差距可能直接決定下游解讀是否失真。
測試 Harness 與可治理 Agent 編程¶
OpenAI 這份實地報告側重生命科學軟件維護，但與之呼應的另一條研究線索，是 2026 年 7 月 arXiv 論文《Cheap Code, Costly Judgment: A Case Study on Governable Agentic Software Engineering》（arXiv:2607.01087）。該文通過 12 周、420 KLOC 生產代碼與 116 萬行測試/lint/文檔的個案，提出 governance conversion（治理轉化） 理論：當代碼生成變得廉價，工程瓶頸轉向如何把 Agent 高速產出轉化爲可審查、可糾正、可長期維護的系統。
兩篇材料合在一起，指向同一實踐模式——可治理的 Agent 編程：
- 任務可規格化：安裝腳本替換、與原版逐位對比、固定容差內的數值 parity，Agent 表現最好；
- 獨立測試 Harness：不讓模型自評正確性；Ewels 的 RustQC 是典型做法；
- 分階段交付：Agent 快速出初稿，人類時間花在邊界條件、小數值偏差與兼容性上；
- 治理機制沉澱：Hooks、審批策略、AGENTS.md 指令、沙箱權限——把一次踩坑轉成可複用的約束。
對企業而言，這比「讓 Agent 自主寫完就上線」更接近可落地的工程路徑：Agent 是基礎設施助手，不是端到端的自主開發者。
組織風險：便宜重寫也可能製造分裂¶
報告還提醒了一個反直覺風險：重寫成本下降，可能讓社區更快出現多個互不兼容的分叉。
RustQC 團隊曾希望用 Rust 版完全替代 Java 版 FastQC，但原作者未同意；最終他們把發現的優化回灌到原版 Java，同樣獲得約 3 倍提速。MHCflurry、cyvcf2 的改動合併回了上游；rustar-aligner 則因 STAR 停更而遷入 scverse。OpenAI 在報告中建議：在第一行 Agent 生成代碼落地之前，先決定誰擁有、誰維護、如何歸屬——否則「技術容易，治理難」會變成新的技術債。
報告還給出了方向性估算（非第三方審計數據）：若 Agent 能解決 100 個科研包中 25%–50% 的安裝問題，可挽回的研究時間價值約 60 萬至近 500 萬美元；NumPy 每年或可節省約 650 小時維護工時。這些數字說明維護 backlog 的經濟體量，但不能替代單個項目上的實測驗收。
對企業 AI 落地的啓示¶
如果你正在評估 Codex、Claude Code 或 GPT-5.5 是否用於內部工具鏈，這份報告給出的啓示比「能不能寫代碼」更具體：
第一，優先掃維護 backlog，而非追求自主科研。 依賴修復、框架遷移、性能調優、GPU 化——任務邊界清楚、驗收標準可寫進 Harness 的場景，投資回報率最高。
第二，把驗證流程產品化。 金標準數據集、與 legacy 系統的輸出 diff、合成數據上的已知答案校準，應成爲 Agent 工作流的一等公民，而不是事後補測。
第三，高置信錯誤比低質量代碼更危險。 Agent 越會解釋、越像「已經想清楚了」，人越容易放鬆警惕。在醫療、生信、金融、工業仿真等高風險領域，這一點尤其致命。
第四，Buy vs Build 要問「誰維護」。 便宜重寫降低的是實施成本，不是 stewardship 成本。Enterprise 採購 Agent 工具時，應同步採購 ownership model：合併上游、社區託管，還是內部 fork——需在開工前定案。
小結¶
OpenAI 與學術合作者這份 8 案例實地報告，給 2026 年的 Agent 討論添了一層必要的冷靜：編碼 Agent 已經能實質性加速科研軟件的安裝、移植與優化，有時提速一個數量級以上；但它們不能替人裁決科學是否正確。 真正的競爭點，從「誰生成的代碼更多」轉向「誰更會把 Agent 放進可驗證、可治理、可維護的流程裏」。
下一波值得觀察的信號包括：更多實驗室是否公開 Agent 現代化管線的 concordance 數據；NumPy、PyTorch 生態是否把 Agent 用於 routine 維護而保留算法變更的嚴格人工審查；以及測試 Harness、社區託管模式能否跟上重寫速度，避免工具生態碎片化。
對開發者來說，最務實的起點或許很簡單：挑一個「裝不上、跑不動、沒人修」的內部或開源依賴，寫清 acceptance criteria，讓 Agent 改第一輪——然後花足夠時間驗證它不僅跑得快，而且算得對。
