應用於科學運算的長時程 Claude 代理工作流

用於科學計算的長時運行 Claude

在本文中，Siddharth Mishra-Sharma 將解釋如何將跨越多日的代理式編碼工作流（測試預言機、持久記憶和編排模式）應用於科學計算任務，甚至是個人專業領域之外的任務。

前提

目前大多數使用 AI 代理的科學家都處於對話循環中，緊密地管理著流程的每一步。隨著模型在過去一年左右的時間裡在長週期任務上的表現顯著提升，一種新的工作方式應運而生：我們不再參與每個細節，而是可以指定高層目標，並讓一組代理自主工作。這使得在短短幾小時內完成原本可能需要數天、數週甚至數月的項目成為可能。某些類型的科學任務非常適合這種模式，例如：重新實現數值求解器、將用舊版 Fortran 編寫的遺留科學軟體轉換為現代語言，以及針對參考實現對大型代碼庫進行調試。在這些任務中，工作範圍明確，成功標準清晰，且人類的監督可以是偶發性的而非持續性的。

Anthropic 的 C 編譯器項目展示了這種模式的一個版本，Claude 通過大約 2,000 個會話構建了一個能夠編譯 Linux 內核的 C 編譯器。本文描述了如何針對典型的學術實驗室，使用 Claude Code 為科學計算任務建立類似的模式。作為一個具體案例，我將演示如何使用 Claude Opus 4.6 實現宇宙學波茲曼求解器（Boltzmann solver）的可微分版本。這是一種數值代碼，通過演化早期宇宙中光子、重子、中微子和暗物質的耦合方程，來預測大爆炸餘暉——宇宙微波背景（CMB）的統計特性。

像 CLASS 和 CAMB 這樣的波茲曼求解器是宇宙學中科學基礎設施的核心部分，讓我們能夠利用來自 Planck 和 Simons Observatory 等巡天數據來約束宇宙學模型。可微分版本（能夠在整個求解器中傳播梯度）可以使用基於梯度的推斷方法，從而大幅加快參數估計的速度。使用 JAX 編寫是非常合適的，因為它基本上免費提供了自動微分和對加速器（如 GPU）的兼容性。值得注意的是，這項任務並不在我的核心科學領域內——我對工具和科學有高層次的了解，但沒有專業知識能在任何合理的時間範圍內獨立完成它。擁有這些專業知識的團隊已經在 JAX 中構建了可微分求解器，但僅包含 CLASS 功能的一個子集。這些努力通常代表了研究人員數月到數年的時間。這裡的重點是看看代理是否能在非領域專家的極少引導下走得更遠。

這類任務在結構上與 C 編譯器項目不同，後者可以分發給大量並行代理。而波茲曼求解器是一個深度耦合的流水線——在模擬早期宇宙如何復合時的一個微小數值誤差或糟糕的近似，都會微妙地影響下游的一切。因此，它需要一組不同的代理技能。調試需要追溯整個鏈條的因果關係並利用領域知識，這可能更適合單個代理順序工作，根據需要產生子代理，並使用參考實現來剖析差異。

我們將使用運行 SLURM 作業調度程序的 HPC 集群作為計算環境，但核心理念——進度文件、測試預言機、具有明確規則的代理提示詞——無論你在哪裡運行 Claude Code 都適用。

起草計劃並在本地迭代

在轉向管理自主研究代理團隊的過程中，你應該花費大部分時間（與 Claude 協商）制定一套清晰闡述項目交付成果和相關背景的指令。這些指令應保存在根目錄下的 CLAUDE.md 文件中。Claude 會特別對待這個文件，將其保留在上下文（context）中，並參考它來制定整體計劃。至關重要的是，Claude 可以在工作時編輯這些指令，在解決問題的過程中為未來的工作更新指令。

這是一個宇宙學波茲曼求解器項目的早期 CLAUDE.md，展示了在初步嘗試編寫求解器後編寫的整體計劃和設計決策。為了達成這個目標，我指定了項目的高層目標——在完全可微分的同時實現與參考 CLASS 實現的功能對等，並在主要科學交付成果中設定相對於 CLASS 0.1% 的準確度目標——並與 Claude 反覆迭代，直到計劃看起來令人滿意。考慮到 0.1% 是 CLASS 和 CAMB 這兩個權威波茲曼代碼之間的典型一致性水平，這似乎是一個很好的科學目標。

跨會話記憶

進度文件（我們在這裡按慣例稱為 CHANGELOG.md）是代理的可移植長期記憶，充當某種實驗筆記。在 CLAUDE.md 中，Claude 被指示在此文件中記錄進度。

一個好的進度文件可能會記錄當前狀態、已完成的任務、失敗的嘗試及其原因、關鍵檢查點的準確度表以及已知的局限性。失敗的嘗試很重要——如果沒有它們，後續會話將重新嘗試相同的死胡同。一條記錄可能看起來像：“嘗試為擾動 ODE 使用 Tsit5，系統太過僵硬（stiff）。切換到 Kvaerno5。” 這是運行示例的變更日誌，展示了這些元素。

測試預言機

雖然通過代理進行更具開放性的科學發現肯定即將到來，但目前長時運行的自主科學工作關鍵取決於代理是否有辦法知道自己是否正在取得進展。對於科學代碼，這可以是一個參考實現、一個清晰的可量化目標或現有的測試套件。指示代理在工作時擴展測試套件並運行測試，以防止退化（regression），也是很有幫助的。在我的示例任務中，Claude 被指示使用 CLASS C 源代碼作為參考實現來構建並持續運行單元測試。

以 Git 作為協調工具

Git 是以不干涉方式監控和協調代理進度的好方法。代理應在完成每個有意義的工作單元後進行提交（commit）和推送（push）。這為你提供了在出現問題時可恢復的歷史記錄，使進度在本地可見，並防止在計算配額在中途耗盡時丟失工作。

實際上，這可以是 CLAUDE.md 中的一組指令，例如：“在每個有意義的工作單元後提交並推送。在每次提交前運行 pytest tests/ -x -q。切勿提交破壞現有通過測試的代碼。”

為了引導代理，你隨時可以 SSH 進入集群並手動重新提示和/或更新其指令。通常更簡便的做法是直接要求本地的 Claude Code 實例 SSH 進去並為你運行命令；這也適用於下面描述的所有內容。

執行循環

如上所述，通常先在本地迭代計劃，直到獲得一個看起來合理並編碼在 CLAUDE.md 中的計劃，這是非常有用的。從那裡開始，在計算節點上的終端複用器（如 tmux）中啟動 Claude Code 會話，告訴代理在哪裡可以找到你的代碼庫，然後讓它開始運作。因為會話在 tmux 中運行，你可以分離（detach）會話、關閉筆記本電腦，並偶爾檢查進度（在波茲曼求解器的案例中，我會在手機上查看 GitHub，例如在排隊買咖啡時）。

在 HPC 集群上，你可能會通過 SLURM 調度程序請求一個節點，一個在 tmux 會話中啟動 Claude Code 的示例作業腳本可能如下所示：

作業開始後，你接入 tmux 會話，給予 Claude Code 指示（例如，“閱讀 CHANGELOG.md 並開始下一個任務”），並在確信它走在正確軌道上時分離會話。你可以隨時重新接入以進行檢查、引導或開始新任務，使用如下命令：

Ralph 循環： 隨著模型能力增強，它們需要的定製編排（如提示詞工程、RAG 或上下文填充）越來越少。然而，在特定時間點，提供一定程度的腳手架作為能力提升是有用的。例如，當前的模型可能會表現出代理惰性——當被要求完成一個複雜的多部分任務時，它們有時會找藉口在完成整個任務之前停止（“時間不早了，我們明天再繼續吧？”）。

為了規避這一點，一個有用的編排模式是 Ralph 循環，它本質上是一個 for 循環，當代理聲稱完成時，將其踢回上下文中，並詢問它是否真的完成了。這對於長時運行的任務很有用，因為代理會承認任務未達標，並繼續工作直到達標。其他類似的模式包括 GSD（以及特定領域的變體）以及 Claude Code 原生的 /loop 命令。

Ralph 可以通過 /plugin 安裝。Claude Code 中一個典型的調用提示詞可能如下：

在這裡，Claude 將迭代最多 20 次，直到它以“DONE”咒語保證任務已完成。

結果

Claude 在幾天內從零開始完成了這個項目，其各項輸出與參考 CLASS 實現達到了低於 1% 的誤差一致性。我要求 Claude 在項目過程中重建代碼某些主要輸出（各種 CMB 角功率譜）的準確度，並標註開發過程中的里程碑。它生成了下圖，展示了通往低於 1% 準確度的路徑。

代理的開發軌跡有些笨拙。例如，它的測試覆蓋範圍存在明顯漏洞——有一段時間它只在單個（基準）參數點上測試代碼，大大減少了其捕捉錯誤的範圍。它也會犯一些初級錯誤，比如在規範約定（gauge conventions）上絆倒，或者花費數小時追查宇宙學家一眼就能看出的錯誤，但它始終朝著低於 1% 準確度的既定目標持續前進。

這個項目的一個副作用是，通過觀察 git 提交歷史，我學到了驚人數量的關於波茲曼求解器及其模擬物理學的知識。這個項目並非出自我的核心科學領域，但跟隨 Claude 的增量進展並查閱我不認識的內容，被證明是一種吸收科學知識的有效方式。提交日誌讀起來就像是一個快速、極度字面化的博士後的實驗筆記。

雖然最終的求解器尚未達到生產級別（例如，它在每個範疇內與參考 CLASS 實現的一致性尚未達到可接受的精度），但它證明了代理驅動的開發可以將研究人員數月甚至數年的工作壓縮到幾天內。

這種壓縮改變了什麼才算作“閒置時間”。AI 研究中的一個普遍經驗是，在晚上啟動一個實驗（例如訓練運行），然後在早上滿意地看到結果。不運行實驗就意味著機會成本。如今，不運行代理感覺也有成本。如果你擁有計算資源和成功標準明確的項目，那麼你沒有讓代理為你工作的每個夜晚，都是被留在桌面上的潛在進展。