OpenAI報告：編碼代理加速科學軟件構建

OpenAI近日發佈了一份現場報告，追蹤了八個科學計算項目，這些項目使用編碼代理（包括OpenAI的Codex和Anthropic的Claude Code）來加速軟件構建。報告顯示，代理在五個項目中獨立使用Codex，另外三個項目則結合了Codex和Claude Code。值得注意的是，這是一家供應商發佈的自有產品在科研場景中的應用調查，案例由貢獻者撰寫。

儘管存在利益偏差，但報告指出的模式值得關注：科研軟件普遍存在維護問題。為單篇論文開發的工具，由小型學術團隊編碼，缺乏專業工程支持，往往積累技術債務，無人承擔清理責任。OpenAI認為代理可以解決這一債務，其引用的八個項目涵蓋基因組學、免疫學、統計學和RNA測序等領域。

代理承擔的任務大致分為三類：打包和構建系統清理、現有代碼性能優化、以及完整的語言或後端移植。例如，用於讀取基因組變異文件的Python庫cyvcf2，其舊版構建和打包系統被替換為更統一的流程；DNA測序讀段模擬器HI.SIM經過兩次自主優化，在代表性測試集上運行時間減少31%，且輸出不變；用於PacBio HiFi讀段基因組組裝的Hifiasm，在優化目標上運行時間減少25%。

在遷移方面，MHCflurry（預測T細胞蛋白片段）從TensorFlow/Keras後端遷移到PyTorch，同時保持與已發佈模型權重的兼容性；bayesm-rs（R語言bayesm包的Rust移植）在單線程上運行速度提升2.3–2.7倍，八線程時達到4.4–9.5倍。此外，rustar-aligner、svb和kuva等項目涉及Rust構建，包括完整重建已失去維護的廣泛使用的RNA序列比對工具STAR。RustQC將15個獨立的RNA測序質量控制工具整合為單個程序，運行時間縮短60倍，磁盤I/O減少25倍。HelixForge是突變模擬工具BAMSurgeon的GPU原生重建，運行時間縮短約60倍。

所有案例的共同點是：代理能很好地處理範圍明確的實現請求，但無法判斷自身輸出是否科學合理。貢獻者描述代理對含有明顯錯誤的工作表現出自信，這迫使人類構建驗收測試。項目通常分階段進行，代理快速生成初稿，剩餘時間用於邊緣情況和數值差異。

報告指出，降低工程成本有利有弊。一方面，過去需要資助的工程崗位現在可由兩人團隊完成；另一方面，不同實驗室可能輕易產生三個不兼容的工具版本。報告強調，在代理生成第一行代碼之前，應決定誰擁有重建的工具並確保承諾。最終，OpenAI的報告指向一個具體選擇，而非普遍認可：確保工具的所有權和維護承諾。