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的報告指向一個具體選擇，而非普遍認可：確保工具的所有權和維護承諾。