Codex 新命令 /goal 深度解析
整理版優先睇
/goal 命令令 Codex 擁有長任務追蹤能力，背後係持久化加運行時核算嘅實踐
呢篇文章係講 OpenAI Codex rust-v0.128.0 版本嘅 /goal 命令，作者深入源碼拆解呢個功能點樣從 TUI 命令解析、App Server RPC，一路落到 Core Runtime 同 SQLite 持久化層。作者想解決嘅問題係：長航時任務入面，AI 好容易喺多輪對話入面「失憶」，唔記得終極目標。/goal 嘅做法係將目標持久化儲存，配合 Ralph Loop 控制環，令智能體可以自動續航，仲有 Token 預算限制，防止無限循環或者過度消耗。
文章嘅整體結論係：/goal 嘅實現係一次教科書式嘅「持久化 + 運行時刻核算」實踐，透過 SQLite 固定長期記憶，透過 Runtime 環路賦予自主性，又透過提示詞工程做到優雅嘅邊界控制。Ralph Loop 嘅核心唔係無限循環，而係四個工程約束：目標規格外部化、每輪執行可丟棄、驗證形成反壓、退出信號明確。
作者透過源碼逐層分析，由 TUI 嘅 SlashCommand::Goal 開始，到 App Server RPC 嘅 Feature Gate 檢查，再到 SQLite 嘅 thread_goals 表，最後講到用量核算同自主續航環路。成個設計令模型由被動執行者變成預算敏感嘅任務管理者，透過 create_goal、get_goal、update_goal 三個工具主動管理目標。
- Ralph Loop 唔係單純無限循環，而係「目標→執行→觀察→修正→再執行」嘅控制環，靠外部化目標同驗證反壓確保質素。
- /goal 將目標持久化儲存喺 SQLite，重啟 Codex 都仲喺度，仲自動觸發續航對話。
- 預算限制用 Token Budget 控制消耗，超標時自動注入隱藏 developer 訊息引導模型收尾。
- 自主續航環路會檢查 Thread 空閒狀態，並防止死鎖：如果模型上輪冇做任何工具調用，就唔會自動觸發。
- Codex 向模型暴露三個工具：create_goal、get_goal、update_goal，令模型可以自主管理任務進度。
Ralph Loop：智能體嘅可控閉環
理解 /goal 之前，最好先理解 Ralph Loop。佢聽落好粗暴：一個 while true 循環反覆啟動 AI 編碼 Agent，將同一份任務說明餵畀模型，等佢讀代碼、做修改、運行驗證、輸出完成或卡住嘅信號，然後下一輪。
- 目標規格外部化：目標唔靠模型短期記憶保存，而係放喺 PRD、任務清單、測試、倉庫文件入面。
- 每輪執行可丟棄：上下文窗口可以刷新，Agent 每輪重新讀取現實狀態，減少長上下文漂移。
- 驗證形成反壓：測試、類型檢查、Lint、日誌同評審結果會話畀 Agent 知「仲未過」，逼佢繼續修。
- 退出信號明確：完成、卡住、超預算都必須有可觀察嘅狀態，唔係靠模型一句「差唔多」。
Codex 嘅 /goal 可以睇成呢個思想喺產品入面嘅內建版本：佢唔再依賴外部 bash 腳本反覆啟動進程，而係將目標、狀態、預算、續航提示詞同完成工具都接入同一個 Thread runtime。
/goal 命令：持久化目標嘅自動續航系統
對於長航時任務，開發者往往需要 AI 保持對終極目標嘅關注，唔好喺多輪對話入面逐漸失憶。/goal 命令允許用戶為當前會話設置一個持久化嘅目標。
狀態化：目標存儲喺 SQLite 中，重啟 Codex 依然存在。
自動化：當目標處於 Active 狀態且會話空閒時，Codex 會自動觸發下一輪對話以繼續任務。
可控性：支援 Token 預算限制，防止智能體陷入無限循環或過度消耗。
- 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 等核心字段。
核心實現：用量核算同自主續航
/goal 嘅強大之處在於佢能精確感知任務消耗。喺 codex-rs/state/src/runtime/goals.rs 中，account_thread_goal_usage 負責更新進度。
物理計費 vs 邏輯計費：系統會自動扣除 Cached Input Tokens，只計算真實嘅推理成本。
當消耗超過 token_budget 時，狀態切換為 BudgetLimited。此時，Runtime 會向模型注入一條隱藏嘅 developer 消息，引導模型「儘快收尾」，實現優雅嘅預算轉向（Steering）。
「空閒」判斷並唔等同於用戶界面暫時冇動靜：源碼會同時排除已有活躍 Turn、下一輪隊列已有輸入，同埋觸發 Turn 嘅內部 mailbox 已有待處理消息等情況。
模型工具：智能體嘅自我管理
Codex 向模型暴露咗三個核心工具，令模型從「被動執行者」變成「預算敏感嘅任務管理者」。
- 1 create_goal：主動建立持久化目標。
- 2 get_goal：查看剩餘預算同用量。
- 3 update_goal：任務完成後標記 complete。
呢三個工具令模型可以自主管理任務進度，而唔係每次等用戶畀指令。
喺 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 環路賦予咗自主性，又通過提示詞工程實現咗優雅嘅邊界控制。
在 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 環路賦予了自主性，又通過提示詞工程實現了優雅的邊界控制。