Codex 新命令 /goal 深度解析
整理版優先睇
Codex 新增 /goal 命令實現長任務追蹤，從源碼剖析其持久化、預算控制與自主續航機制。
呢篇文章係關於 OpenAI Codex rust-v0.128.0 版本入面新增嘅 /goal 指令。作者透過深入源碼，分析咗呢個功能點樣由 TUI 指令解析、App Server RPC，一路落到 Core Runtime 同 SQLite 持久化層。作者想帶出嘅係，/goal 唔係一個簡單嘅指令，而係一個完整嘅長任務追蹤系統，令 AI 智能體可以持續關注終極目標，唔會喺多輪對話中失憶。
文章指出，/goal 嘅核心思想嚟自 Ralph Loop——一個「目標 -> 執行 -> 觀察 -> 修正 -> 再執行」嘅控制環。佢透過 SQLite 將目標持久化，令到即使重啓 Codex，目標仍然存在。同時，佢引入 Token 預算限制，避免智能體無限循環。最關鍵嘅係自主續航環路，當任務空閒時自動觸發下一輪對話，但喺模型冇進行工具調用時會抑制自動觸發，防止死鎖。整體上，/goal 令到 Codex 從被動執行者變成預算敏感嘅任務管理者。
- /goal 命令提供持久化目標管理，支援自動續航同 Token 預算限制，令 Codex 處理長任務更可靠。
- 實現上透過 SQLite 儲存目標狀態，Runtime 做用量核算，超支時注入隱藏提示引導模型收尾。
- 相比外部腳本循環，/goal 將目標、狀態、預算同完成工具整合喺同一個執行緒運行時，更輕量穩定。
- Ralph Loop 思想——目標外部化、每輪可丟棄、驗證反壓、退出信號明確——係設計長期任務 AI 嘅關鍵工程約束。
- 開發者可以用 create_goal、get_goal、update_goal 工具，令智能體自我管理任務進度同預算。
從 Ralph Loop 到 /goal：理解控制環
想清楚理解 /goal，最好先認識 Ralph Loop。呢個模式聽落好粗暴：一個 while true 循環反覆啓動 AI 編碼 Agent，將同一份任務說明餵畀模型，等佢讀代碼、做修改、運行驗證、輸出完成或卡住嘅信號，然後進入下一輪。
但真正重要嘅係四個工程約束：目標規格外部化、每輪執行可丟棄、驗證形成反壓同退出信號明確。呢啲約束確保目標唔靠模型短期記憶，而係落喺文件同測試入面。
/goal 命令：持久化與自動續航
/goal 命令畀用戶為當前會話設定一個持久化目標。呢個目標會存喺 SQLite 嘅 thread_goals 表，就算重啓 Codex 都唔會消失。狀態欄位包括 objective、status 同 token_budget。
當目標處於 Active 狀態，而會話空閒嗰陣，Codex 會自動觸發下一輪對話嚟繼續任務。呢個自動續航機制令智能體可以持續工作，唔使用戶手動輸入。同時支援Token 預算限制，防止無限循環。
核心機制：用量核算與預算限制
/goal 嘅強大之處在於佢可以精確感知任務消耗。account_thread_goal_usage 呢個函數負責更新進度，佢會自動扣除Cached Input Tokens，只計真實推理成本。呢個係「物理計費 vs 邏輯計費」嘅分別。
當消耗超過 token_budget，狀態會切換做 BudgetLimited，同時 Runtime 向模型注入一條隱藏的 developer 消息，引導模型「儘快收尾」，實現優雅嘅預算轉向。
自主續航環路：防止死鎖的設計
呢個係實現「自主智能體」最關鍵嘅一環。當 Goal 係 Active 而 Thread 空閒，GoalRuntimeState 就會被激活。但系統會檢查上一輪有冇進行過工具調用——如果冇，就會抑制下一次自動觸發，防止死鎖。
所謂「空閒」唔單止係 UI 冇鬱動，源碼仲會排除已有活躍 Turn、下一輪隊列已有輸入、內部 mailbox 有待處理消息等情況。呢個設計確保智能體喺瓶頸時停低，等用戶幹預。
模型工具：智能體的自我管理
Codex 向模型暴露咗三個核心工具，令佢變成預算敏感的任務管理者：
- 1 create_goal：主動建立持久化目標，等系統記住要做乜。
- 2 get_goal：查看剩餘預算同用量，等模型知自己仲有幾多資源。
- 3 update_goal：任務完成後標記 complete，正式結束目標。
呢啲工具畀模型從「被動執行者」升級做主動管理者，可以自己決定點樣分配 Token 同處理任務邊界。
喺 OpenAI Codex rust-v0.128.0 版本入面，/goal 命令嘅引入令 Codex 開始有更明確嘅長任務追蹤能力。呢篇文章會深入 Codex 源碼，揭秘呢個功能點樣由 TUI 命令解析、App Server RPC，一路深入到 Core Runtime 同 SQLite 持久化層。
一、先理解 Ralph Loop：將智能體變成一個可驗證閉環
理解 /goal 之前，最好先理解 Ralph Loop。佢聽落好粗暴：一個 while true 循環反覆啟動 AI 編碼 Agent，將同一份任務說明或規格文檔餵俾模型，等佢讀 code、做修改、運行驗證、輸出完成或卡住嘅信號，然後進入下一輪。
呢個模式真正重要嘅唔係「無限循環」，而係四個工程約束：
目標規格外部化：目標唔靠模型短期記憶保存，而係落喺 PRD、任務清單、測試、倉庫文件入面。
每輪執行可丟棄：上下文窗口可以刷新，Agent 每輪重新讀取現實狀態，減少長上下文漂移。
驗證形成反壓：測試、類型檢查、Lint、日誌同評審結果會話俾 Agent 知「未過到」，迫佢繼續改。
退出信號明確：完成、卡住、超預算都必須有可觀察嘅狀態，唔係靠模型一句「差唔多」。
所以 Ralph Loop 嘅本質係一種「目標 -> 執行 -> 觀察 -> 修正 -> 再執行」嘅控制環。Codex 嘅 /goal 可以當做呢個思想喺產品入面嘅內建版本：佢唔再依賴外部 bash 腳本反覆啟動進程，而係將目標、狀態、預算、續航提示詞同完成工具都接入同一個 Thread runtime。
二、咩係 /goal？
對於長航時任務（Long-running tasks），開發者往往需要 AI 保持對終極目標嘅關注，而唔係喺多輪對話入面逐漸「失憶」。/goal /goal 命令允許用戶為當前會話設置一個持久化嘅目標。
狀態化：目標儲存喺 SQLite 入面，重啟 Codex 依然存在。
自動化：當目標處於 Active 狀態而且會話空閒時，Codex 會自動觸發下一輪對話去繼續任務。
可控性：支援 Token 預算限制，防止智能體陷入無限循環或過度消耗。
三、技術全景圖：由指令到狀態
/goal /goal 嘅實現唔係單一模塊堆砌，而係一個貫穿全棧嘅精妙設計。
1. 交互層 (TUI & Slash Command)
在 codex-rs/tui/src/slash_command.rs 中，SlashCommand::Goal /goal 被定義為一種支援內聯參數嘅命令。
2. 通信層 (App Server RPC)
TUI 通過 RPC 請求同後端通信。喺 thread_goal_handlers.rs /goal 入面，系統會檢查 Feature Gate 並驗證線程持久化狀態。
3. 持久化層 (State DB)
目標儲存喺 SQLite 嘅 thread_goals goal 表入面，包含 objective、status、token_budget 等核心字段。
四、核心實現 1：用量核算與預算限制
/goal /goal 嘅強大之處在於佢可以精確感知任務消耗。喺 codex-rs/state/src/runtime/goals.rs 中，account_thread_goal_usage Runtime 負責更新進度。
⚠️ 物理計費 vs 邏輯計費：系統會自動扣除 Cached Input Tokens，只計算真實嘅推理成本。
當消耗超過 token_budget token_budget 時，狀態切換為 BudgetLimitedover_budget。此時，Runtime 會向模型注入一條隱藏嘅 developer steering 消息，引導模型「盡快收尾」，實現優雅嘅預算轉向（Steering）。
五、核心實現 2：自主續航環路 (Continuation)
呢個係實現「自主智能體」最關鍵嘅一環。當 Goal 處於 Active 狀態而且 Thread 空閒時，GoalRuntimeState Continuation 會被激活。
為咗防止死鎖，如果模型喺上一輪冇進行任何工具調用，系統會抑制下一次自動觸發。呢種設計保證咗智能體喺遇到瓶頸時可以停落嚟等用戶介入。
呢個「空閒」判斷並唔等同於用戶界面暫時冇鬱動：源碼會同時排除已有活躍 Turn、下一輪隊列已有輸入，以及觸發 Turn 嘅內部 mailbox 已有待處理消息等情況。
六、模型工具：智能體嘅自我管理
Codex 向模型暴露咗三個核心工具，令模型由「被動執行者」變成「預算敏感嘅任務管理者」：
1. create_goal: 主動建立持久化目標
2. get_goal: 查看剩餘預算和用量
3. update_goal: 任務完成後標記 complete
寫喺最後
/goal 命令嘅實現係一次教科書式嘅「持久化 + 運行時刻核算」實踐。佢通過 SQLite 錨定咗長期記憶，通過 Runtime 環路賦予咗自主性，又通過提示詞工程實現咗優雅嘅邊界控制。
在 OpenAI Codex rust-v0.128.0 版本中，/goal 命令的引入讓 Codex 開始具備更明確的長任務追蹤能力。本文將深入 Codex 源碼，揭秘這一功能是如何從 TUI 命令解析、App Server RPC，一路深入到 Core Runtime 和 SQLite 持久化層的。
一、先理解 Ralph Loop：把智能體跑成一個可驗證閉環
理解 /goal 之前，最好先理解 Ralph Loop。它聽起來很粗暴：一個 while true 循環反覆啓動 AI 編碼 Agent，把同一份任務說明或規格文檔餵給模型，讓它讀代碼、做修改、運行驗證、輸出完成或卡住的信號，然後進入下一輪。
這個模式真正重要的不是“無限循環”，而是四個工程約束：
目標規格外部化：目標不靠模型短期記憶保存，而是落在 PRD、任務清單、測試、倉庫文件裏。
每輪執行可丟棄：上下文窗口可以刷新，Agent 每輪重新讀取現實狀態，減少長上下文漂移。
驗證形成反壓：測試、類型檢查、Lint、日誌和評審結果會告訴 Agent “還沒過”，迫使它繼續修。
退出信號明確：完成、卡住、超預算都必須有可觀察的狀態，而不是靠模型一句“差不多了”。
所以 Ralph Loop 的本質是一種“目標 -> 執行 -> 觀察 -> 修正 -> 再執行”的控制環。Codex 的 /goal 可以看作這個思想在產品裏的內建版本：它不再依賴外部 bash 腳本反覆啓動進程，而是把目標、狀態、預算、續航提示詞和完成工具都接進同一個 Thread runtime。
二、 什麼是 /goal？
對於長航時任務（Long-running tasks），開發者往往需要 AI 保持對終極目標的關注，而不是在多輪對話中逐漸“失憶”。/goal 命令允許用戶為當前會話設置一個持久化的目標。
狀態化：目標存儲在 SQLite 中，重啓 Codex 依然存在。
自動化：當目標處於 Active 狀態且會話空閒時，Codex 會自動觸發下一輪對話以繼續任務。
可控性：支持 Token 預算限制，防止智能體陷入無限循環或過度消耗。
三、 技術全景圖：從指令到狀態
/goal 的實現並非單一模塊的堆砌，而是一個縱貫全棧的精妙設計。
1. 交互層 (TUI & Slash Command)
在 codex-rs/tui/src/slash_command.rs 中，SlashCommand::Goal 被定義為一種支持內聯參數的命令。
2. 通信層 (App Server RPC)
TUI 通過 RPC 請求與後端通信。在 thread_goal_handlers.rs 中，系統會檢查 Feature Gate 並驗證線程持久化狀態。
3. 持久化層 (State DB)
目標存儲在 SQLite 的 thread_goals 表中，包含 objective, status, token_budget 等核心字段。
四、 核心實現 1：用量核算與預算限制
/goal 的強大之處在於它能精確感知任務消耗。在 codex-rs/state/src/runtime/goals.rs 中，account_thread_goal_usage 負責更新進度。
⚠️ 物理計費 vs 邏輯計費：系統會自動扣除 Cached Input Tokens，只計算真實的推理成本。
當消耗超過 token_budget 時，狀態切換為 BudgetLimited。此時，Runtime 會向模型注入一條隱藏的 developer 消息，引導模型“儘快收尾”，實現優雅的預算轉向（Steering）。
五、 核心實現 2：自主續航環路 (Continuation)
這是實現“自主智能體”最關鍵的一環。當 Goal 處於 Active 狀態且 Thread 空閒時，GoalRuntimeState 會被激活。
為了防止死鎖，如果模型在上一輪沒有進行任何工具調用，系統會抑制下一次自動觸發。這種設計保證了智能體在遇到瓶頸時能停下來等待用戶干預。
這個“空閒”判斷並不等同於用戶界面暫時沒動靜：源碼會同時排除已有活躍 Turn、下一輪隊列已有輸入，以及觸發 Turn 的內部 mailbox 已有待處理消息等情況。
六、 模型工具：智能體的自我管理
Codex 向模型暴露了三個核心工具，讓模型從“被動執行者”變成了“預算敏感的任務管理者”：
1. create_goal: 主動建立持久化目標
2. get_goal: 查看剩餘預算和用量
3. update_goal: 任務完成後標記 complete
寫在最後
/goal 命令的實現是一次教科書式的“持久化 + 運行時刻核算”實踐。它通過 SQLite 錨定了長期記憶，通過 Runtime 環路賦予了自主性，又通過提示詞工程實現了優雅的邊界控制。