自主編碼正在從「更好的提示詞」轉向「更好的控制系統」。一個重要的轉變是，工程師們正在學習如何將 Agent 包裹在目標、評估器、循環和工件中，讓它們在人類停止輸入後仍能持續運作。
這之所以重要，是因為大多數嚴肅的工程工作都是長週期的：需求模糊不清、隱含的約束條件、部分失敗、變化的上下文以及反覆驗證。新的前沿領域是圍繞 Agent 設計系統，使其能夠規劃、執行、檢查成果、從錯誤中恢復，並在無需人類持續操控的情況下持續取得進展。
本文基於一場 DAIR.AI Academy 關於自主長時運行編碼 Agent 的講座，我在講座中實際展示了 Claude Code 的 /goal 模式、較新的 /loop 命令、驗證器、工件以及編排模式。本文與 Codex 和 Claude Code 協作撰寫。
從提示詞設計到目標設計
像 Claude Code 的 /goal 這類功能背後的核心概念很簡單。編碼 Agent 仍然是執行者，但人類不再與它進行逐輪互動。相反地，人類指定了期望的最終狀態、證明成功所需的證據、不得違反的約束條件，以及在可能的情況下指定允許的輪數和預算。
這個 (goal) 目標的運作方式更像一份契約，而不是一個更長的提示詞。一個弱的目標會讓模型有空間提前停止、走捷徑，或重新定義成功，使其在對話記錄中看起來合理，但在實際系統中卻失敗。一個強的目標則為 Agent 提供一個它可以反覆衡量自己的標靶。
工程判斷在此仍然至關重要。最好的目標融入了領域知識，這些知識本是模型需要自行猜測的。對於研究實驗來說，這可能意味著一個目標基準分數、一個保留的評估、一條要求的損失曲線，以及結果必須超過初始基線的規則。對於 UI 任務來說，這可能意味著一個螢幕截圖參考、具體的佈局約束，以及一個瀏覽器驗證步驟。模型可以執行，但人類仍然定義了「完成」的真正含義。
評估器成為一級組件
長時運行的 Agent 除了目標之外，還需要一個第二角色，即評估器。這個評估器可以是另一個編碼 Agent、作為評審的 LLM、一個腳本、一個測試套件、一個基準測試框架，或者是它們的組合。關鍵的設計選擇在於為任務匹配正確的評估器。當成功的定義很明確時，確定性檢查效果更好。在任何能用類型檢查、單元測試、Lint 規則、整合測試和基準測試腳本清晰地表達條件時，都應該優先使用它們。
當成功的定義較模糊時，Agent 評估器就變得有用。一個腳本可以告訴你測試是否通過，但它不容易判斷一份生成的研究報告是否連貫、實作是否忠實遵循了一篇論文，或者一個 UI 是否符合設計意圖。這就是評估器需要語言理解能力、判斷力，有時甚至需要視覺能力才能發揮作用的地方。
實際的運作模式是，將確定性檢查作為基礎，Agent 評估作為更高層級的審查。這種組合減少了虛假的成功宣告，同時允許模型在那些無法被乾淨地納入測試斷言中的任務上保持自主性。
驗證器定義了信任的邊界
更深層的觀點是，自主性只有在系統擁有可靠的驗證器時才能運作。一個編碼 Agent 可以生成計畫、實作功能，並解釋為什麼它認為工作已經完成，但這個解釋不應被視為證據。證據來自於 Agent 難以繞過的外部檢查。
對於程式碼來說，驗證器可以是測試套件、類型檢查器、基準測試、瀏覽器運行結果、螢幕截圖比對或可重現的腳本。對於研究工作來說，它可以是保留的評估、可重現的數據表、損失曲線，或是比基線有所改善的基準分數。對於設計工作來說，它可能是一張參考螢幕截圖加上視覺審查步驟。驗證器是將長時運行 Agent 從一個自信的文字生成器，轉變為一個可以被信任並賦予更多時間的系統的關鍵。
大多數捷徑都出現在這個邊界上。如果驗證器定義模糊，模型通常會滿足於對任務最簡單的解釋。如果驗證器過於狹窄，模型可能會過度擬合於它，而錯失了更廣泛的意圖。因此，一個好的自主工作流程需要分層驗證：用廉價的確定性檢查來捕捉基本失敗，再用更高層級的審查來捕捉需要判斷力的失敗。少數前沿模型已經能夠達成一定程度的驗證，但根據我的研究，仍然存在明顯的 OOD（分佈外）問題。如果你指派給 Agent 的驗證任務落在訓練分佈之外，模型會表現得非常掙扎。
驗證器仍然是一個開放的研究領域，但我預計會有更多公司開始在此領域進行大規模投資。在企業中，對微調驗證器的需求也非常高。
循環讓自主性持久耐用
目標為 Agent 提供了方向，但循環讓工作得以持續。這個區別很重要，因為模型常常在真正任務完成之前就停止了。它們可能達到輪數限制、失去信心、用盡上下文，或者認為部分解決方案已經足夠。
循環是外層的控制系統。它會被喚醒，檢查進度，運行檢查，將結果與目標進行比較，並在目標尚未達成時，將 Agent 與下一個指令一起送回運行。在最簡單的形式中，這是帶有編碼 Agent 和確定性條件的 Ralph 循環模式。在更靈活的形式中，循環包含一個可以推理進度並決定下一步行動的評估器 Agent。
長時運行的自主性，運作方式是「在控制層的監督下反覆努力」，而不是一次連續的智慧行為。Agent 仍然可能失敗，但循環讓系統能夠注意到失敗並繼續運行，而不是默默地宣告勝利。
規劃是專業知識的切入點
講座中一個最強烈的共識是，規劃仍然至關重要。你可以要求一個前沿模型來生成計畫，但你仍然需要檢查它、挑戰其假設，並在將任務交給自主循環之前，讓成功標準更加清晰。
這導致了一個有用的分工。一個更強的規劃模型可以幫助定義目標、識別缺失的約束條件、並構建評估。一個不同的執行模型則可以在計畫明確後運行實作。在實踐中，這意味著工程師們不應再將「那個模型」視為單一選擇。模型的選擇變成了一個架構決策。
有些模型是更好的規劃者。有些是更好的執行者。有些是更便宜的評估者。有些更擅長基於視覺的審查。一個好的編排器讓你可以在這些角色之間切換，而不是等待某一個供應商提供完美的編碼 Agent 介面。
視覺工件成為控制面
當許多 Agent 同時運行時，終端機記錄是無法擴展的。一旦你有數個會話並行工作，純文字就成了一種糟糕的進度了解介面。
即時工件之所以重要，是因為一個包含損失曲線、基準分數、任務狀態、螢幕截圖、成本估算和近期決策的儀表板，能為人類提供更好的方式去監督自主性。工件成為了決定何時介入的控制面，而不是事後生成的報告。
最有用的模式是將儲存與呈現分開。Markdown 或一個知識庫可以儲存持久的證據、日誌、筆記、計畫和結果。HTML 工件則可以將這些狀態渲染成可視化且可互動的形式。Agent 可以搜尋 Markdown，而人類則可以監控工件。
對於 UI 和產品工作來說，視覺線索尤其強大。一張參考螢幕截圖比文字更能精確傳達設計意圖，而具備視覺能力的評估器可以將實作結果與該參考進行比較。這減少了常見的失敗模式：Agent 雖然技術上實現了要求的組件，但卻忽略了間距、層級、對齊或產品感覺。
會話挖掘將使用過程轉化為記憶
另一個重要的見解是，過去的 Agent 會話是豐富的工作流程數據來源。如果一個 Agent 反覆以同樣的方式失敗、忘記運行同樣的檢查、使用了錯誤的路徑或重試了同一個壞掉的命令，這些模式不應該被埋在日誌裡。
會話挖掘將這些記錄轉化為操作規則。一個 Agent 可以掃描過去三十天的工作，找出反覆出現的失敗模式，並提出對專案指示、知識庫學習內容或 Agent 規則的更新。這就是一個團隊可以逐步改進其「控制框架」，而無需手動記住每一個錯誤的方法。
目標是讓本地環境變得更智慧，而無需從頭開始訓練模型。Agent 指令檔案中的一條小規則就可以防止未來會話中反覆出現的失敗，特別是當這條規則針對該專案時。
實用的操作模型
對於 AI 工程師來說，新興的工作流程看起來像這樣。
- 啟動完整的自主運行之前，先從一個小而便宜的測試子集開始。
- 撰寫一個目標，其中包含可衡量的成功標準、明確的約束條件，以及（在可能的情況下）輪數或時間預算。
- 將執行者與評估者分開，這樣實作和判斷就不會混為一談。
- 在長時運行循環啟動之前，先定義好外部驗證器。
- 盡可能使用確定性檢查，然後再針對模糊的標準添加 Agent 審查。
- 要求提供證明工件，例如日誌、螢幕截圖、基準測試曲線或已更改的文件。
- 挖掘過去的會話，並將反覆出現的教訓提升為專案指示。
這就是「使用編碼 Agent」和「設計自主編碼系統」之間的區別。前者給你一個對話，後者給你一個控制框架。
哪些問題仍然存在
上述任何一點都沒有消除那些困難問題。Agent 仍然會走捷徑。它們仍然會提前停止。它們仍然會高估完成度。它們仍然會產生看似自信但實際上很薄弱的計畫，尤其是在處理最新論文、不熟悉的基準測試或超出其訓練分佈的系統時。
更信任它們並不能解決這個問題。更好的控制系統才能解決。目標、循環、評估器、確定性檢查、視覺工件和會話記憶，都是讓自主性變得可觀察、可修正的方法。
方向是明確的。編碼 Agent 的未來取決於圍繞更強大模型的更好編排，工程師們需要設計出合適的條件，讓 Agent 能夠安全地運行數小時甚至數天，並仍然產出可被驗證的成果。
