Codex Goal 深度解析：讓 AI Agent 連續工作數小時的目標驅動工作流

Tue, 26 May 2026 23:44:37 +0800

瀏覽器、終端和 IDE 裡的 AI Agent 已經越來越會寫程式了，但很多人真正遇到的問題不是「它不會做」，而是「它做一半就說完成了」。

簡單 ticket 很適合交給 coding agent：修一個按鈕、補一個介面、改一段文案、加一個測試。目標清楚，邊界很小，驗證方式也直接。但一旦任務變成大型遷移、跨模組重構、測試套件修復、依賴升級、prompt eval 優化，Agent 就很容易出現一種典型問題：

它完成了一個看起來合理的中間狀態，然後過早停下。

Codex Goal / Persistent Goals 這類能力要解決的，正是這個「提前收工」問題。它的重點不是讓 Agent 多跑幾輪，而是讓 Agent 圍繞一個明確目標持續推進，直到滿足可驗證的完成標準。

Codex Goal 解決的不是循環，而是停止條件

很多長任務自動化會從一個粗糙方案開始：

`1`	`繼續檢查程式碼，修復問題，直到沒有錯誤。`

或者更機械一點：

循環 10 次：
1. 執行測試
2. 讓模型修復失敗
3. 再執行測試

這類 rough loop 看起來能讓 Agent 工作更久，但它有兩個硬傷：

它不知道什麼時候真的該停。
它也不知道「沒有繼續報錯」是否等於「任務完成」。

Codex Goal 的關鍵不是循環次數，而是 goal、state、judge stop condition 三件事。也就是說，Agent 需要知道這次工作的目標是什麼，目前已經完成到哪裡，以及什麼證據能證明任務真的結束了。

這也是長任務 Agent 的核心分水嶺：不是「多執行幾步」，而是「能不能判斷自己還差什麼」。

Goal 和普通 prompt 的區別

普通 prompt 更像一次性指令：

`1`	`把這個專案的測試修好。`

Goal prompt 則更像一份小型任務合約：

目標：修復目前倉庫中失敗的測試。
範圍：只修改 src/ 和 tests/，不要改建置腳本。
完成標準：npm test 全部通過，且新增修改不引入 lint 錯誤。
驗證命令：npm test && npm run lint。
失敗處理：如果超過 3 次仍無法修復，輸出剩餘失敗用例、已嘗試方案和阻塞點。
輸出：總結修改檔案、修復原因、驗證結果。

兩者最大的差別在於，Goal prompt 把「完成」定義清楚了。

如果沒有 definition of done，Agent 很容易把「我改了程式碼」誤判成「我完成了任務」。如果有清晰的完成標準，Agent 就必須圍繞測試、日誌、diff、建置結果、eval 分數這些外部證據繼續推進。

為什麼 LLM judge stop condition 很關鍵

長任務裡最難的不是讓 Agent 執行命令，而是讓它判斷：

現在是否真的完成了？
是否只是通過了局部測試？
是否修了一個問題，卻引入了另一個問題？
是否需要繼續搜尋、繼續執行驗證、繼續回滾某個方向？

這就是 LLM judge stop condition 的價值。

理想狀態下，Agent 不應該只看「最後一個命令是否退出碼為 0」。它還應該綜合判斷：

使用者給出的完成標準是否全部滿足；
修改是否限定在允許範圍內；
測試、lint、build、eval 是否都跑過；
失敗日誌是否還有未處理項；
是否存在明顯的副作用和風險；
最終輸出是否能讓人類快速複核。

換句話說，judge 不只是「判定成功」，還要防止 Agent 自我安慰式收尾。

哪些任務適合交給 Goal

Codex Goal / Persistent Goals 更適合那些需要多輪探索和驗證的複雜 coding work，例如：

程式碼遷移：從舊框架遷到新框架，從 CommonJS 遷到 ESM，從舊 API 遷到新 API。
大型重構：拆分模組、整理邊界、替換重複實作、降低複雜度。
測試修復：連續分析失敗用例，定位原因，修復後反覆驗證。
依賴升級：升級框架、SDK、建置工具，同時處理 breaking changes。
Prompt eval 優化：執行評測，分析失敗樣本，調整 prompt 或工具呼叫策略。
技術債清理：圍繞明確規則逐步替換舊寫法，並保持行為不變。

這些任務的共同點是：中間狀態很多，失敗原因不一定一次能看清，完成標準必須依賴驗證結果。

哪些任務不適合只靠 Goal

Goal 並不是萬能的。下面這些任務如果只靠一個長 prompt，風險會很高：

目標非常模糊，例如「把產品增長做好」。
週期很長，例如連續幾週的 SEO、GEO、廣告投放優化。
需要跨系統調度，例如同時處理內容、資料、投放、客服和業務指標。
涉及生產風險，例如資料庫變更、線上配置、財務操作、帳號權限調整。
缺少驗證手段，例如沒有測試、沒有指標、沒有日誌、沒有人工作收標準。

這類任務更像 Mission，而不是 Goal。

Goal 適合小時級到一兩天的深度執行。Mission 則需要狀態、歷史、調度、人類審批、階段性複盤和長期指標。比如 SEO / GEO / Ads 優化，不只是讓 Agent 循環寫內容或調參數，而是要持續記錄策略、實驗、資料變化和下一步計畫。

寫好 Goal Prompt 的模板

一個好用的 Goal prompt，至少應該包含下面幾塊：

目標：
用一句話說明最終要達成什麼結果。

背景：
說明目前問題、相關檔案、業務約束、已有嘗試。

範圍：
允許修改哪些目錄、檔案、模組；哪些地方不要碰。

完成標準：
列出可驗證的 definition of done。

驗證命令：
寫清楚需要執行的測試、lint、build、eval 或腳本。

失敗策略：
如果無法完成，要求 Agent 輸出失敗原因、已嘗試方案、剩餘阻塞點。

風險邊界：
禁止破壞性操作，生產配置、密鑰、資料庫、外部服務需要人工確認。

交付格式：
要求總結修改點、驗證結果、風險和後續建議。

真正決定長任務效果的，往往不是 prompt 寫得多漂亮，而是完成標準夠不夠硬。

Goal Buddy 的價值：先幫你把任務說清楚

很多長任務失敗，不是 Agent 能力不夠，而是人類一開始就沒有把任務拆清楚。

Goal Buddy 這類輔助工具的價值在於：在正式把任務交給 Agent 之前，先幫你準備目標、邊界、完成標準和驗證方式。它像一個任務預檢器，會追問：

這個任務的最終可見結果是什麼？
哪些目錄可以改，哪些不能改？
成功後跑什麼命令證明？
失敗時要不要繼續嘗試，最多嘗試到什麼程度？
是否需要分階段提交？
哪些操作必須讓人類確認？

這一步看似囉嗦，但它能顯著減少 Agent 中途跑偏、過早停止或改出一堆難以複核程式碼的概率。

給 Codex、Claude Code、OpenCode 使用者的實踐建議

如果你正在用 Codex、Claude Code、OpenCode、OpenClaw 或類似 coding agent，可以按下面方式使用長任務：

先提交目前工作區，保證有乾淨回滾點。
把任務寫成 Goal，而不是一句泛泛的需求。
明確允許修改的範圍和禁止修改的範圍。
給出驗證命令，最好讓 Agent 每輪都能自己執行。
要求 Agent 在無法完成時報告阻塞點，而不是硬編一個「完成」。
對高風險操作設定人工確認，例如刪除檔案、改資料庫、改部署配置。
最後只接受帶有測試結果和修改總結的交付。

長任務 Agent 的正確使用方式，不是「讓它自己隨便幹一晚上」，而是給它一個清楚的目標、堅實的護欄和可驗證的出口。

小結

Codex Goal / Persistent Goals 的意義在於，把 coding agent 從「執行一句指令」推進到「圍繞一個目標持續工作」。

它最適合複雜但邊界明確的工程任務：遷移、重構、測試修復、依賴升級、eval 優化。它不適合完全模糊、週期很長、缺少驗證標準的業務任務；那些更應該設計成 Mission 系統。

未來 AI Agent 的競爭點，很可能不只是模型會不會寫程式，而是能不能圍繞目標持續推進、正確判斷停止時機，並把過程留給人類複核。

參考：

長任務 on KnightLi的博客