/goal 讓 Codex CLI 開始自己跑完任務——但 token budget 這條護欄，真的夠嗎？
Codex CLI 0.128.0 出了一個功能叫 /goal，講白話就是：你設定一個目標，它自己跑，跑到覺得目標完成、或 token 燒完為止。
第一次看到這個的反應是：「喔不。」
不是因為它不強，是因為它太強了，強到我開始想一個問題：這個「自主跑完」的能力，我準備好接了嗎？
它到底是怎麼跑的
原理比你想的簡單。背後主要是兩個 prompt template：goals/continuation.md 和 goals/budget_limit.md，每跑完一個 turn 就自動注入到 context 結尾——前者是「你還沒完成，繼續」，後者是「你快燒完了，趕快收尾」。
這東西有個名字叫 Ralph loop，概念不是 OpenAI 發明的，但 Codex CLI 把它包進了正式 feature。以前要做這件事，你得自己寫 shell script 包一層、或是用更重量級的 agent 框架。現在一個指令下去，CLI 自己接管循環。
從工程角度看，這個實作蠻聰明的：不是真的在 agent 裡面跑 while loop，而是靠 prompt 來驅動下一個 turn 的行為。輕量，容易理解，但也代表它的「判斷力」完全取決於你的 goal 寫得好不好。
跟以前手動接力比，差在哪
我之前用 Codex CLI 的方式，是跑一段、看 output、決定下一步、再跑。這個流程本質上是我在當那個 loop controller。優點是我對每一步都有感知，缺點是：如果任務要跑 10 個 turn，我就要盯著螢幕 10 次。
/goal 把這個決策權交回給模型。效率提升是真的，但你跟任務之間的距離也拉開了。
我試過一個對比場景：同樣是「幫我把這個 legacy API module 重構，加上錯誤處理和 logging」，手動接力版我跑了 7 個 turn，途中三次手動校正方向（有一次是它要把所有 console.log 換掉，但那些是 production debug 用的，不能動）。/goal 版呢？跑了 5 個 turn 自動完成，但它把那些 debug log 也改了，而且我是看到 diff 才發現的。
效率 +30%，風險也 +30%。 這個數字是我主觀估計，但方向是對的。
token budget 作為護欄，這個設計的問題
這邊是我最想講的部分。
token budget 是 /goal 的「安全閥」——模型燒超過你設的 budget，就收工。設計初衷很合理，但有一個根本的認知錯誤：token 的消耗量跟任務的風險程度，不是線性關係。
換個說法：一個「刪掉所有 deprecated 函數」的任務，可能 500 token 就跑完了，但留下的後遺症你可能三週後才發現。一個「寫 unit test 補完整個 module」的任務，跑了 5000 token，但頂多就是 test 寫得不夠好，不會死人。
所以用 budget 來做風控，本質上是在控制「時間花多少」而不是「風險有多大」。這是拿計時器當保險絲。
真正的風控應該在哪裡？我覺得有三個層次：
第一層：goal 的定義本身。你的 goal 寫「重構 payment module」跟寫「重構 payment module，不動任何對外 API interface，不刪任何現有 function，只加不改」，結果會差很多。大部分人懶得寫那麼細，然後出事了說模型「自作主張」。
第二層：scope 隔離。我現在的習慣是，凡是 /goal 類型的任務，先 git checkout 一個新 branch，跑完再 review diff。聽起來很基本，但有幾次我懶得開 branch、直接在 main 跑，都後悔了。回滾成本比你想的高，尤其是它跑了十幾個檔案的時候。
第三層：中途 checkpoint。這個 Codex CLI 目前好像沒有原生支援。理想狀態是：每跑 N 個 turn 就 commit 一次，給你一個觀察點。這塊如果之後能加進去，我覺得 /goal 的可用性會大幅提升。
什麼場景我真的會用 /goal
試過幾個之後，我自己的 checklist 大概是這樣：
適合：
- 任務有明確的「完成標準」可以被模型自評（「把所有 TODO 加上 issue number」「把 JSDoc 補完整個 utils 目錄」）
- 失敗代價低，最壞情況是重來（prototype、內部工具、有完整 test coverage 的模組）
- 你不需要即時知道它怎麼想的，只需要看最後結果
不適合：
- 有 side effect 的操
作（API call、資料庫寫入、發 PR）
- goal 很模糊、依賴你的主觀判斷（「讓這段 code 更好」這種）
- 你對這塊 codebase 本來就不熟，不確定哪些地方不能動
上個禮拜我跑了一個「把舊的 callback 風格全部換成 async/await」的任務，跑了約 3200 token，12 個檔案，結果 90% 正確。剩下 10% 是有一個地方它沒處理好 error propagation，但因為我有 test，馬上就抓到了。整體來說算成功，但如果沒有 test coverage 的話，我不敢這樣跑。
這不是終點，是起點
/goal 讓 coding agent 從「工具」更靠近「員工」了一步。不是 AI 替代你，而是它開始有能力在你給的邊界內自主完成一段工作。
但這個比喻也帶出問題：你怎麼給新員工交代任務？你不會說「去把那個系統弄好」然後走人，你會說「這個範圍你可以動，那個不行，做完給我看一下才 deploy」。
agent workflow 設計的核心挑戰，從來不是模型夠不夠強，而是你有沒有把邊界和驗收標準說清楚。
/goal 把這個問題從「理論上」變成「你現在就得面對」。以前沒有這個功能，你可以說「反正還是手動接力，差不了多少」。現在不行了，你得真的想清楚：這個任務的邊界在哪？完成的定義是什麼？出錯的後果你能接受嗎？
我覺得這個功能最大的貢獻，不是省了多少時間，而是逼你去想清楚你原本其實沒想清楚的事情 ☕
作者：咖啡驅動開發