Feb 1, 2026ScienceLong-Running Claude for Scientific Research

用於科學研究的長期運行 Claude

前提

現今將編碼代理（coding agents）用於科學研究通常遵循對話模式：你提出問題，獲得回覆，然後進行迭代。然而，某些類型的科學計算任務並不完全契合這種模式——例如重新實現數值求解器、將舊式 Fortran 方言編寫的遺留科學軟體轉換為 Rust 等現代語言，或是針對參考實現對大型代碼庫進行調試。在這些任務中，工作範圍明確，成功標準清晰，且可能只需要偶爾而非持續的人類監督來引導整體方向。這些任務可能需要數天甚至數週的實際時間。

C 編譯器項目展示了這種模式的一個版本：Claude 跨越了大約 2,000 個會話，構建了一個能夠編譯 Linux 核心的 C 編譯器。通過一組測試、進度追蹤和自主執行循環，一個並行的 Claude 團隊能夠在多個獨立會話中，針對一個大型技術項目取得持續進展，直到滿足所有成功標準。

本教程介紹了如何為學術實驗室設定類似的科學計算模式，並使用 Claude Code 進行操作。我們將以運行 SLURM 作業調度程序的 HPC 集群作為工作範例，但其核心理念——進度文件、測試預言機（test oracle）、具有明確規則的代理提示詞——無論你在何處運行 Claude Code 都同樣適用。截至撰寫本文時，根據任務範圍，訂閱 5 倍或 20 倍的 Max 方案應足以應付大多數此類性質的工作流。

在本地迭代計劃

在這種新的工作方式中，你應該花大部分時間撰寫項目簡報（project brief），清晰地闡述項目的交付成果和相關背景。在移至集群之前，先在本地與 Claude 協作迭代並完善此簡報是非常有用的。將結果保存為項目根目錄下名為 CLAUDE.md 的文件；Claude 會自動將其保留在上下文（context）中。

一個好的項目提示詞還應包含引導協議（orientation protocol），告訴代理在開始編寫任何代碼之前的每個新會話開頭該做什麼，例如：「閱讀 CHANGELOG.md——特別是『當前狀態』和『後續步驟』。從優先級列表中選擇影響力最大的任務。」這可以防止代理在不了解已完成工作的情況下盲目投入代碼編寫，或重複嘗試已經失敗的方法。

項目的初始部分也可以在網頁版的 Claude Code 上完成，然後在需要時使用 /teleport 命令將對話及其上下文轉移到本地終端或計算集群。

跨會話記憶

進度文件（我們在此按慣例稱為 CHANGELOG.md）是代理的可移植長期記憶，充當某種實驗筆記。一個好的進度文件可能追蹤：(1) 當前狀態，(2) 已完成任務，(3) 失敗的方法及其原因，(4) 關鍵節點的準確性表，以及 (5) 已知的局限性。失敗的方法是最重要的——如果沒有它們，後續會話將重複嘗試相同的死胡同。一條記錄可能如下所示：「嘗試使用 Tsit5 處理擾動 ODE，系統過於剛性（stiff）。已切換至 Kvaerno5。」你的 CLAUDE.md 應指示代理持續更新 CHANGELOG.md。

測試預言機 (The Test Oracle)

長期運行的自主工作取決於代理是否有一種方法知道自己是否正在取得進展。對於科學代碼，這可以是一個參考實現、一個清晰的可量化目標或現有的測試套件。指示代理在工作時擴展測試套件並運行測試以防止退化（regressions）是很有幫助的。

以 Git 作為協調工具

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

實際上，這可以是 CLAUDE.md 中的一組指令，例如：「在每個有意義的工作單元後 commit 並 push。在每次 commit 前運行 pytest tests/ -x -q。絕不要 commit 會破壞現有已通過測試的代碼。」

為了引導代理，你隨時可以通過 SSH 進入集群並手動重新提示和/或更新其指令。你還可以使用 Claude Code 鉤子（hooks）來實現協作引導，而無需直接附加到會話。例如，PostToolUse 鉤子可以定期從遠程倉庫拉取並檢查指定文件（如 STEERING.md）中來自協作者的新指令。當新指令出現時，鉤子會將其注入 Claude 的上下文中，讓你或協作者在任務中途重新定向代理。這讓多人只需向倉庫推送一個文件即可協調運行。有關設置詳情，請參閱鉤子指南。

執行循環

如前所述，通常先在本地迭代計劃，直到獲得一個看起來合理並編碼在 CLAUDE.md 中的計劃。準備就緒後，在計算節點上的終端複用器（如 tmux）中啟動 Claude Code 會話，告訴代理在哪裡可以找到你的代碼庫，然後讓它開始工作。因為會話在 tmux 中運行，你可以分離（detach）會話、關閉筆記本電腦，並偶爾檢查進度。在 HPC 集群上，你可能會通過 SLURM 請求節點；在雲端虛擬機或工作站上，你通常可以直接啟動 tmux。

一個在 tmux 會話中啟動 Claude Code 的 SLURM 作業腳本範例可能如下所示：

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

Ralph 循環

隨著模型變得更好，它們需要的定制化編排（提示工程、RAG、上下文填充等）越來越少。然而，當前的模型可能會表現出「代理懶惰」——當被要求完成一個複雜的多部分任務時，它們有時會在完成部分任務後找藉口停止（「時間不早了，我們明天再繼續吧」）。

目前一種有用的編排模式是 Ralph 循環，它本質上是一個 for 循環，在代理完成工作後將其踢回上下文，並詢問是否真的完成了。這對於長期運行的任務很有用，因為代理會承認任務尚未達到規範，並繼續工作直到完成。

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

在這裡，Claude 將迭代最多 20 次，直到它以「DONE」咒語保證任務已完成。與其手動 SSH 進入集群並在交互式 Claude Code 會話中運行命令，你隨時可以要求本地版本的 Claude Code（例如在你的筆記本電腦上）來執行此操作。

應用與結論

作為一個具體的例子，我使用這些模式配合 Claude Opus 4.6 實現了一個可微宇宙學波茲曼求解器（differentiable cosmological Boltzmann solver），這是一種數值代碼，用於在給定一組宇宙學參數（如暗能量比例）的情況下，預測大爆炸餘輝——宇宙微波背景（CMB）的樣貌。它通過演化早期宇宙中光子、重子、中微子和暗物質的耦合方程來實現。像 CLASS 和 CAMB 這樣的波茲曼求解器是宇宙學中核心的科學基礎設施，能夠從 Planck 和 Simons Observatory 等巡天觀測中進行參數估計。

該實現通過 JAX 完全可微，從而實現基於梯度的推斷。與現有帶有顯著簡化假設的代碼互補，該求解器涵蓋了直到各種 CMB 觀測量的完整流程。利用 CLASS 的 C 源代碼作為測試預言機，並使用追蹤準確性表和失敗數值方法的進度文件，Claude 在幾天的實際時間內從零開始構建了它，達到了與 CLASS 低於百分之一的誤差一致性。這類任務在結構上與 C 編譯器項目不同，後者可以分發給大量並行代理。而波茲曼求解器是一個深度耦合的管道：重組模組中的細微錯誤可能會無聲地移動可見性函數，進而改變擴散阻尼尺度等等。調試需要追溯整個因果鏈，這更適合單個代理順序工作，根據需要產生子代理，並使用參考實現來剖析差異並持續測試其工作。

我要求 Claude 在項目過程中重建一些主要交付成果（各種 CMB 角功率譜）的準確性，並標註里程碑。它生成了上面的圖表，顯示了在運行幾天後達到低於百分之一準確性的路徑（在此期間代理並非持續運行，且重啟了幾次）。代理的進展有些笨拙——它會犯一些宇宙學家看來顯而易見的錯誤，例如在不同的規範約定（gauge conventions）上絆倒——但它始終朝著設定的低於百分之一準確性的目標持續前進。

雖然最終的求解器尚未達到生產級別，但它證明了代理驅動的開發可以將研究人員數月甚至數年的工作壓縮到幾天內。

機器學習研究中的一個普遍經驗是，希望在通宵啟動一個實驗（例如訓練運行），然後在早上滿意地看到結果。不運行實驗意味著機會成本。如今，不運行代理感覺同樣具有成本。如果你有計算配額、帶有測試套件的代碼庫以及明確的準確性目標，那麼你每個不運行會話的夜晚都是被留在桌面上的潛在進展。科學計算經常在代理擅長處理的工作上遇到瓶頸——追查 2 倍因子、將中間值與參考值進行比較、在參數空間中運行驗證掃描。研究人員推遲這些任務是因為它們枯燥乏味，而不是因為它們不可能完成。