[AI 分享] 用 Codex /goal 理解 Agent 核心

 [AI 分享] 用 Codex /goal 理解 Agent 核心

摘要：Codex 的 /goal 模式是理解 Agent 的好入口，涵蓋目標、狀態、工具、驗證、預算與停止條件。

內容:

很多人學 Agent 時，會先接觸規劃、多智慧體、工具呼叫、長期記憶、自動化與工作流等大概念。這些當然重要，但如果想真正理解 Agent 為什麼能持續做事，而不只是回答一句話，Codex 的 /goal 模式其實是一個非常適合的切入點。它不會複雜到難以理解，卻剛好包含了 Agent 系統中最關鍵的幾個元素：目標、狀態、工具、驗證、預算與停止條件。

從表層使用來看，平常給 Codex 一個 prompt，它通常只會處理一輪，可能讀檔、改程式、跑命令、看錯誤後回傳結果。若任務很短，這樣就足夠；但當任務拉長，例如專案遷移、修複雜 bug、效能優化或補齊測試時，就不可能靠一輪完成。這類任務常常要經過多個檢查點：先重現問題、再定位原因、接著修改、執行測試、修正新錯誤，最後再驗證結果。沒有 /goal mode 時，人往往得一直守在旁邊，反覆下「繼續」指令；而 /goal 的作用，就是把這個持續推進的意圖，變成一個可持久追蹤的任務目標。

/goal 模式最重要的概念，不只是「長任務」，而是「可驗證的停止條件」。這也是許多人學 Agent 時最容易忽略的一點。很多人以為 Agent 的核心在於會拆步驟，但真正困難的是：系統怎麼知道自己什麼時候做完。如果沒有清楚的完成定義，它就只會不停生成看似合理的下一步，卻無法真正結束。因此，/goal 的本質不是讓模型更努力，而是給模型一個能反覆檢查的完成標準。

例如，若目標是把專案從 JavaScript 遷移到 TypeScript，並要求 Strict Mode 編譯通過、不保留明顯 Any、關鍵路徑測試全數通過，這就是一個明確且可驗證的 /goal。相較之下，「幫我把專案優化一下」就過於模糊，沒有範圍、驗收方式與停止依據。當目標寫得夠清楚，Codex 每一輪都能檢查：編譯過了嗎、Any 清掉了嗎、測試跑了嗎。如果答案是否定，它就不應宣告完成。這也說明 Agent 的第一層核心，就是目標必須可驗證。

更深入來看，/goal 並不是只存在對話上下文中的一段文字。從原始碼可見，它會被寫入獨立的 SQLite 狀態資料庫中，並以執行緒 ID 對應任務資料，包含目標文本、狀態、Token 預算、已消耗 Token、已用時間、建立時間與更新時間等欄位。這代表 /goal 不是單純依賴模型記住你的需求，而是作為一個真正存在於系統外部的任務狀態。上下文可能被截斷、壓縮或摘要，但外部狀態表能明確保存任務目前進展、資源消耗與是否結束。這正是 Agent 的第二層重點：長任務不能只靠上下文，必須有外部狀態。

再往下看工具邊界設計，原始碼中可見幾個和 /goal 相關的工具，例如 Get/goalal、Create/goalal 與 Update/goalal。Get/goalal 用來查看當前目標與資源使用情況；Create/goalal 用來建立新目標，但不能隨意覆蓋尚未完成的任務；Update/goalal 則更關鍵，模型能更新的狀態很有限，主要只是在「完成」或「阻塞」之間做判定。至於暫停、恢復、清空、預算限制與用量限制，則由宿主系統控制，而不是交給模型自由決定。這反映出很典型的 Agent 設計原則：模型負責推進與判斷，系統負責保存狀態、控管邊界與限制資源。這也是 Agent 的第三層重點：工具要能行動，但權限必須收口。

/goal 最像 Agent 的地方，在於它的自動續跑機制。當執行緒進入 Idle 狀態時，系統會檢查是否存在 Active /goalal；若有，就會讀取該目標，生成一個 continuation 的執行項，並將它重新注入執行流程，啟動下一輪工作。所以，我們看到的「它自己繼續做」，並不是模型突然產生了自我驅動，而是執行時系統在空閒邊界做了一次排程決策。這一點非常重要，因為它把 Agent 從神祕化的想像，拉回工程實作的本質：它更像是一個有目標、有狀態、有觸發條件、能決定下一步的狀態機。這就是 Agent 的第四層：持續性來自執行時排程，而不是來自模型的主觀意志。

在資源管理與停止條件上，/goal 的設計也很值得借鏡。它不是單純讓模型一直跑，而是會記錄 Token 與時間消耗，甚至在 Token 計算上，還會扣除快取輸入，避免重複計算成本。這背後反映的是一個非常現實的系統設計問題：長任務必須有成本視角。若一個 Agent 能長時間自動執行，卻不知道自己花了多少資源，那最終只會讓自動化失控。

此外，/goal 的狀態不只包含 Active 與 Complete，還有 Paused、Blocked、Usage Limited、Budget Limited 等狀態。Paused 代表可以被人工暫停；Blocked 表示任務推進受阻；Usage Limited 與 Budget Limited 則代表達到用量或預算上限；Complete 才是真正完成。這些狀態共同說明，/goal 不是無限迴圈，而是一個有預算、有邊界、有失敗與停止條件的長任務機制。這也是 Agent 的第五層核心：不只要會開始，更要會停。很多自動化系統不好用，不是因為它不會做事，而是因為它不會停。

從實用角度來看，凡是「中間步驟多，但最後有清楚驗收標準」的任務，都很適合 /goal。像是程式碼遷移，可以定義成遷移到特定框架、頁面視覺一致、建構成功、關鍵測試通過；修 bug 可以定義為先重現問題、只修改相關模組、補回歸測試、本地測試通過並說明驗證結果；效能優化則可以要求首頁 TTI 降到指定秒數內，並以指定命令驗證，且不能犧牲核心功能；資料研究也可以要求閱讀指定資料、提取證據、給出結論與不確定點，且關鍵判斷都必須附來源。這些任務都有清楚邊界，因此很適合交給 /goal 持續推進。

相反地，有些任務就不適合 /goal。第一種是開放式、沒有完成定義的任務，例如「幫我把專案做得更好」，因為沒有 Done，系統就沒有停下來的依據。第二種是把一堆互不相關的事情塞在一起，例如一邊修登入、一邊改首頁、再重構支付、順便寫週報，這比較像待辦清單，而不是單一 /goalal。第三種則是需要頻繁人工主觀判斷的任務，例如設計風格要不要更高級、文案是否更像某個品牌、商業策略是否該轉向，這些更適合先讓系統做規劃或提出方案，再由人做決策。

整體來說，Codex 的 /goal 模式之所以是理解 Agent 的好入口，不是因為它只是多了一個更強的提示詞，而是因為它完整呈現了 Agent 系統運作的幾個核心原則：目標要可驗證、任務要有外部狀態、工具權限要受控、續跑來自系統排程、執行必須記帳且能停止。當你理解了這些，就更能明白，真正能長時間穩定運作的 Agent，不是無限循環的模型，而是一個有狀態、有邊界、有證據的系統。