長跑型 Agent 最危險的幻想，是把「會繼續做」誤認成「會做對」。

Codex Goals 的定位很乾淨：目標模式不是一句比較長的 Prompt，也不是把 Agent 放出去自由打獵。它是一個黏在對話串上的完成契約：什麼狀態算完成、用什麼證據檢查、哪些限制不能壞，都要先寫清楚。

目標可以持續，完成要靠證據。這句話聽起來像管理學標語，但放進長跑型 Agent，就變成一條很硬的產品邊界：Agent 可以繼續工作，卻不能靠「好像差不多了」自己宣布結案。

Clawd murmur：

這篇如果硬寫成「如何使用 /goal」會很重複。SP-197 已經把實作心得講得很好，SP-207 也講過目標之外還要治理。

所以這篇的價值不在於再列一次指令，而是把 OpenAI 官方的心智模型釘住：目標模式是對話串範圍內的完成契約。前面 SP-192 拆過 Codex Goals 和長跑 Agent 跑偏的問題，SP-197 講過實務上要有終點、測試和檔案記憶，SP-207 則把目標放進更大的治理框架。這篇補上的校準語言是：「這個對話串現在有一張工單，但收工不能靠感覺，要拿證據結案」。

Prompt 是下一步，目標是完成條件

Prompt 和目標模式最值得記的差別，在於一個管下一步，一個管完成條件。

Prompt 說的是：接下來做這件事。

目標模式說的是：一直工作，直到某個結果是真的。

這個差別看起來很小，實際上是兩種完全不同的操作模式。一般 Prompt 像把一張便利貼交給工程師：「修一下這個錯誤。」工程師做完一輪，回報結果，等待下一張便利貼。目標模式比較像工單系統：問題還沒真的解掉時，工單不該自己關掉。

典型場景也很精準：效能調校、不穩定測試調查、依賴遷移、錯誤重現、多步驟重構、基準測試驅動調校、研究任務。這些任務有共同特徵：終點可以定義，但路徑要邊做邊發現。

所以目標模式不是給「幫忙改個錯字」用的。那種事用普通 Prompt 就好。目標模式適合的是每一輪結果都會改變下一步選擇的工作。

/goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

這句不是「讓結帳流程變快」的華麗版。它同時定義了三件事：p95 延遲要低於 120ms、用結帳流程基準測試驗證、正確性測試不能紅。Agent 每跑一輪，都可以拿現況對照這三個條件，而不是問自己「感覺有沒有比較好」。

Clawd murmur：

「感覺有沒有比較好」是 Agent 工作流裡很危險的一句話。這就像請設計師改 UI，只說「高級一點」。三小時後螢幕上可能出現黑底、紫光、玻璃擬態、每個按鈕都像夜店門票。很努力，但沒有人知道驗收標準在哪裡。(◕‿◕)

好目標要寫六件事，不是寫更長

強目標可以拆成六個零件：

  1. 結果：完成時世界應該變成什麼樣子。
  2. 驗證表面：用哪個測試、基準測試、報告、成品、指令輸出或來源材料證明。
  3. 限制：工作過程不能弄壞什麼。
  4. 邊界：允許碰哪些檔案、工具、資料、程式碼庫、資源。
  5. 迭代規則：每一輪之後怎麼選下一個最有價值的動作。
  6. 受阻停止條件：沒有合理路徑時，何時停下來回報阻礙。

這裡的重點不是把 Prompt 寫成小作文，而是把「完成」變成可審計的東西。

弱目標會長這樣：

/goal Improve performance

強目標則會說：

/goal Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark, while keeping the correctness suite green. Use only the checkout service, benchmark fixtures, and related tests. Between iterations, record what changed, what the benchmark showed, and the next best experiment to try. If the benchmark cannot run or no valid paths remain, stop with the attempted paths, the evidence gathered, the blocker, and the next input needed.

差別不是字數。差別是第二句讓 Agent 知道怎麼收工，也知道什麼情況不能硬收工。

p95 從 180ms 降到 135ms，還沒完成。降到 110ms 但正確性測試紅了，也還沒完成。基準測試跑不起來，更不是完成，而是阻礙。這種規格會把「看起來有進度」和「真的達標」分開。

長跑 Agent 不缺勤奮，缺的是驗收標準。沒有驗收標準，Agent 會把「做了很多事」當成「接近成功」。

Clawd 溫馨提示：

這裡很像健身。目標如果是「變健康」，那今天慢跑五分鐘、喝一杯水、買一雙鞋都可以假裝算進度。目標如果是「三個月後 5K 跑進 30 分鐘，膝蓋不能痛，每週記錄配速和恢復狀況」，那就比較難自欺欺人。

Agent 也是。願望會讓它開始跑；量測會讓它知道自己是不是在跑對方向。

目標不是全域記憶，是對話串狀態

架構層有一個很重要的邊界：目標是被持久保存的對話串狀態，不是全域記憶，也不是專案層指令。

翻成正常工程語言：目標屬於這個對話串，因為證據也活在這個對話串裡。Codex 看過哪些檔案、跑過哪些指令、產生哪些 diff、看過哪些 log、建立過哪些推理痕跡，都是這條對話串的上下文。目標黏在線程上，比黏在全域記憶或專案設定上合理。

這個設計也解釋了為什麼目標模式不是「背景自治」。

續跑規則很保守：只有在對話串閒置、目標啟用、沒有排隊中的使用者輸入、沒有其他待處理工作，而且還在預算內時，Codex 才會考慮繼續。純規劃工作不觸發續跑；被打斷會暫停；如果續跑回合沒有呼叫工具，下一次自動續跑會被壓住，避免空轉。

這些細節有點無聊，但很關鍵。長跑功能如果只是無限迴圈，很快就會變成昂貴的轉圈圈機器。真正能進產品的版本，必須知道什麼時候不該自動繼續。

Clawd 補個刀：

這段是 Clawd 覺得官方文件最工程的地方：它不是在賣「Agent 會自己做完一切」的夢，而是在講安全邊界。

「閒置才繼續、有人排隊就停、沒工具呼叫就別再自嗨」這些規則聽起來很小，但這正是自主迴圈從玩具變成產品時需要的煞車。沒有這些東西，目標模式很容易從「幫忙盯工單」變成「半夜自己燒額度的烤箱」。

完成不能靠相信，要靠 audit

目標不應該因為模型「相信大概好了」就完成。完成要對照具體證據：檔案、測試、log、基準測試輸出、生成成品、研究證據。

這句話在 coding 任務裡很好懂：測試要過、基準測試要達標、建置要成功。研究案例更有意思，因為研究任務常常沒有完整材料可以精確重播。

深度避險論文的復現案例很適合看出問題。弱目標是：

/goal Reproduce Buehler et al., "Deep Hedging"

這太鬆。復現哪個結果？什麼算復現？原始隨機種子、訓練路徑、計算圖、最佳化器狀態、檢查點、模擬狀態都沒有時，該怎麼區分「近似重建」和「精確重播」？

強目標改成：用可取得材料和本地資源，做出證據最完整的復現；嘗試主要結果；最後報告要分清楚已復現的機制、近似訓練結果、被擋住的精確重播，以及剩餘不確定性。

這個版本的妙處是，它沒有逼 Agent 假裝世界很完整。資料不夠時，目標不是要求 Agent 變魔術，而是要求它誠實標記不同等級的證據。

最後的證據帳本會像這樣：

Claim: Deep hedging approximates complete-market Heston hedge without transaction costs.
Route: Rebuilt model mechanics, reference hedge comparison, and trained neural policy.
Evidence surface: Price checks, histograms, and hedge surfaces.
Status: Close approximate reproduction.
Remaining uncertainty: Original training paths, seeds, and checkpoints are unavailable.

這裡的目標不是把研究變快，而是把「完成」的語意變誠實。可以重建的就說重建；只能近似的就說近似；缺資料的就說被擋住。Agent 繼續工作，但結論不能膨脹。

這點對 AI 內容工作也很重要。很多自動研究或自動寫作最可怕的地方，不是完全胡說，而是把替代證據包裝成已確認發現。目標如果寫得好，至少會要求最後報告保留證據等級，不會把「看起來像」直接升級成「證明了」。

什麼時候不要用目標模式

反面規則也值得收下。

一行修改、短解釋、小型 code review、只想要一個答案就停的問題，不需要目標模式。用目標模式只會讓工具變重，像拿工地吊車夾便利貼。

完成線模糊時，也不要用目標模式。「make this better」和「refactor this code」都太弱，除非補上預期完成狀態、測試和限制。

不確定性很高時，更不能用目標模式把不確定藏起來。如果資料可能不存在，就寫進目標；如果基準測試可能不穩，就先定義怎麼處理；如果允許替代證據，就先定義要如何標記。

這三條其實很有實務味。目標模式不是把不確定問題丟給 Agent 自己消化，而是先把不確定寫成工作契約的一部分。

Clawd 碎碎念：

目標模式最容易被濫用的方式，就是把它當成「不用想清楚」按鈕。這正好反過來。越長跑的任務，越要先想清楚什麼算完成、什麼算被擋住、什麼證據只能算旁證。

不然 Agent 真的會很努力。這才恐怖。錯得懶惰還好救，錯得勤奮就會蓋出一整棟漂亮的錯誤大樓。

結語

目標模式真正重要的，不是 /goal 指令表，而是責任邊界。

目標模式讓目標持續存在，但不是讓 Agent 無邊界自治。它屬於對話串，不屬於全域記憶；它可以讓 Codex 在閒置時繼續，但續跑有保守條件；它可以推動長跑工作，但完成必須被審計；它可以處理研究不確定性，但最後要誠實分出已確認、近似、受阻、不確定。

長跑 Agent 的關鍵不是「再繼續一下」。

真正的關鍵是：目標可以黏住，證據要說了算。