--- schemaVersion: 1 slug: gp-197-20260512-chrishayduk-codex-goals ticketId: GP-197 lang: zh-tw title: Codex 目標模式不是魔法：迴圈要有終點、測試和記憶 summary: Codex 的 /goal 不是把任務丟進去就會自動變好的許願池。Chris Hayduk 的重點很工程化：給 Agent 可量測的終點、夠快的測試迴圈，再用 Markdown 檔案當長期工作記憶。 originalDate: 2026-05-11 translatedDate: 2026-05-12 source: "@ChrisHayduk on X" sourceUrl: https://x.com/ChrisHayduk/status/2053807198870880743 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-197-20260512-chrishayduk-codex-goals status: published replacementTicketId: null replacementUrl: null --- # Codex 目標模式不是魔法：迴圈要有終點、測試和記憶 > **來源:** [@ChrisHayduk on X](https://x.com/ChrisHayduk/status/2053807198870880743) [Codex](https://gu-log.vercel.app/glossary#codex) 的 `/goal` 看起來很像魔法按鈕：[提示詞](https://gu-log.vercel.app/glossary#prompt)前面加一個指令，[Agent](https://gu-log.vercel.app/glossary#agent) 就會一路跑到任務完成。問題是，魔法按鈕最怕的不是不靈，是太靈：一按下去，機器真的開始跑，卻沒有人先裝煞車。 Codex 可以連續工作多久不是重點；更實際的問題，是把「連續工作」拆成三個工程條件：**迴圈要知道何時停下來，要能快速判斷剛剛做得好不好，還要有地方記住一路上試過什麼。** 換句話說，目標模式不是魔法自治。它比較像把一台很勤奮的機器放上軌道：先裝煞車，再裝儀表板，最後放一本不會失憶的航海日誌。少一個，連續工作就會從酷功能變成大型轉圈圈表演。 ## 魔法按鈕按下去，先找煞車 Codex 應用裡現在可以使用 `/goal`。使用方式很直覺：在提示詞開頭放上 `/goal`，接著指定希望 Agent 達成的事情。Codex 會進入一個持續迴圈，直到它判定目標已經達成。 這裡的關鍵不是「持續」。很多人第一次看到這種功能，腦中會浮出一種浪漫想像：太好了，任務丟給 Agent，隔天醒來程式碼自己變乾淨、模型自己變強、論文自己改好格式，人生從此進入自動駕駛。 但目標模式不是「交辦一次，奇蹟自動發生」。它比較像一個迴圈： 1. Agent 執行某些動作。 2. Agent 對這些動作打分數。 3. Agent 檢查分數是否滿足目標。 4. 如果還沒滿足，就繼續；如果已經滿足，就停止。 整個系統最容易炸開的地方，是第三步。因為「是否滿足目標」聽起來很簡單，但只要目標本身模糊，Agent 就像在玩沒有勝利條件的遊戲。遊戲畫面很熱鬧，角色一直跑、特效一直噴，可是沒有人知道關卡什麼時候結束。 > **Mogu murmur：** > > 這就是目標模式最反直覺的地方：越強的 Agent，越需要清楚的終點。弱一點的工具跑幾分鐘就停了，傷害有限；強一點的工具可能連續跑好幾天，這時候「把程式碼變好」這種願望型提示詞就變成災難產生器。 --- ## 第一個洞：沒有驗收條件，煞車就只是裝飾 過去大約半年，模型變得太好，日常工作裡的提示方式也容易變得有點偷懶。很多時候只要大概比手畫腳，告訴 GPT-5.5 想做什麼，它就能自己推敲接下來該怎麼做。 這種習慣放到目標模式就會出事。 例如「讓程式碼更好」這句話，在一般對話裡可能還行。模型可以先讀檔、找壞味道、做一些合理修補，再回報改了什麼。但在目標模式裡，這句話沒有足夠明確的終點。什麼叫更好？可讀性更好、速度更快、測試更多、架構更一致，還是檔案名稱看起來比較順眼？更麻煩的是，好到什麼程度才夠？ 這種目標不足的任務會出現兩種失敗模式。 第一種是太早放棄。Agent 工作幾分鐘，做了一點事情，然後因為無法明確證明進度，乾脆停下來。這像請人整理房間，但只說「弄漂亮一點」。對方移動兩張椅子，發現沒有驗收標準，就宣布任務完成。尷尬，但至少沒有造成太大破壞。 第二種更可怕：Agent 永遠停不下來。它會不斷改東西、換方向、嘗試各種看似合理的調整，因為「變好」這個目標永遠沒有被滿足的明確瞬間。這不是勤奮，這是把沒有出口的迷宮接上自動駕駛。 更好的替代版本是：「把某個指定檔案裡的程式執行時間降低 20%，而且不能造成既有單元測試與整合測試退步。」 這一句就完全不一樣了。它有明確目標：指定檔案的執行時間降低 20%。也有明確限制：既有單元測試與整合測試不能壞。Agent 不再需要猜「更好」長什麼樣子，只要看兩件事：速度是否達標，測試是否維持通過。 這就是目標模式的第一條鐵律：**不要給願望，給驗收條件。** 願望會讓 Agent 開始動，驗收條件才會讓 Agent 知道何時停。 --- ## 質化任務也要變成可勾掉的關卡 有些任務天生不像「降低 20% 執行時間」那麼好量化。把一篇 NeurIPS 預印本改成 ICML 研討會論文格式，就是很有代表性的例子。 這種任務乍看是質化的。格式正不正確、風格有沒有符合要求、技術內容有沒有被誤改，很多細節都不是單一數字可以衡量。更麻煩的是，ICML 的格式限制很多，原本存在 LaTeX 檔裡，不太適合直接拿來逐項驗收。 做法不是要求 Codex「把格式改對」。先讓 Codex 從 LaTeX 規則裡整理出一份 `checklist.md`，裡面有超過 200 條格式與風格規則。接著才把目標設定成：「根據 `checklist.md` 把 NeurIPS 論文改成 ICML 格式，而且不能改動任何技術內容。」 這個做法把原本的「格式要對」拆成可檢查的工作。前者聽起來像編輯部的靈魂審判；轉成清單後，目標變成「200 條規則全部勾完」。每一條規則本身仍然可能有模糊之處，但 Agent 判斷單一規則是否完成，通常比判斷整份論文是否已經「符合 ICML 感」容易得多。 這裡只能保守寫：清單截圖只留下 `[media]` 標記，沒有截圖內容。因此能確定的是：清單規模超過 200 條，涵蓋格式與風格要求；至於實際條目長什麼樣子，不能再往外補。 完成條目時，清單項目要被勾掉。這讓進度被寫進檔案系統，而不是只存在 Agent 的暫時上下文裡。人類可以直接看清單追蹤進度，Agent 也可以在長時間任務中重新讀取狀態。煞車不再是一句「差不多了吧」，而是一格一格真的被勾掉的進度。 > **Mogu 碎碎念：** > > 這其實很像遊戲任務從「拯救世界」變成「收集碎片、打敗首領、回村莊交任務」。前者很燃，但系統不知道怎麼判定；後者很土，可是可以執行。Agent 世界裡，土法常常比玄學強。 --- ## 有了煞車，還要看得到儀表板 目標清楚之後，故事沒有結束。煞車只負責告訴 Agent 什麼時候停；途中每一步到底是在靠近目標，還是在漂亮地偏航，還需要儀表板。 Agent 要怎麼知道剛剛做的改動有效？ 第二個建議是把回饋迴圈縮短。Agent 每做一輪修改，都需要某種測試機制來評估結果。測試跑得越快、執行方式越簡單，Agent 越能快速得到訊號，知道目前離目標更近還是更遠。 這一點在機器學習任務裡特別明顯。如果目標是改進某個模型架構，直接使用正式模型大小與完整資料集來訓練，可能一次實驗就要跑很久。這對目標模式非常不友善，因為 Agent 每次改一點點都要等完整訓練結果，等於讓一個很會嘗試的人，每次伸手前都先等一張慢到不行的成績單。 做法是使用較小的模型、抽樣後的資料集，讓 Agent 可以更快測試想法。重點不是把測試變得隨便，而是在不破壞分數品質的前提下，盡可能加速回饋。 在蛋白質結構模型架構搜尋的案例裡，正式資料集跑一次評分可能要好幾天；改用 NanoFold，一個小型但抽樣良好的資料集，可以讓實驗評分時間從好幾天縮短到幾分鐘。這裡的數字很關鍵：不是「快一點」這種感覺，而是從天級降到分鐘級。對一個會反覆迭代的 Agent 來說，這差距會直接改變它敢不敢多試幾輪。 NanoFold 是 Hugging Face 上公開的資料集。可確認的細節有限：它小、抽樣良好，並用於蛋白質結構模型架構實驗。因此這裡不能替它補上額外評測數字或資料組成。 > **Mogu 吐槽時間：** > > 把完整訓練當成每次迭代的評分方式，就像每改一行作文都送去印成精裝書再請老師批改。儀式感滿分，效率直接往生。(╯°□°)╯ 目標模式需要的是足夠可信、足夠快的檢查點，不是每一步都走正式審稿流程。 --- ## 儀表板之外，還要一本不失憶的航海日誌 就算有煞車、有儀表板，長任務還有最後一個麻煩：跑到第三天，Agent 還記不記得第一天為什麼轉彎？ 第三個建議看起來樸素，但非常要命：給 Agent 一些 Markdown 檔案，讓它把計畫、實驗、即時想法寫下來。 原因很簡單。目標模式可以讓 GPT-5.5 連續跑好幾天。即使 Codex 有不錯的上下文壓縮能力，這種時間尺度對任何模型都很硬。長任務不是只需要記得最新一步，還需要記得前面試過什麼、為什麼失敗、哪條路已經證明不值得再走。 如果所有脈絡都被迫塞在模型上下文裡，任務越長，記憶越像一疊被反覆影印的講義：大意還在，細節開始糊。檔案系統的好處是穩定、可讀、可回溯。Agent 可以重讀，人類也可以審計。 目標模式中通常會提供三個檔案。 **`PLAN.md`** 負責高層計畫。這份檔案記錄 Agent 打算怎麼往目標前進，也可以一開始就放入人類提供的方向或假設。它像航線圖，不需要記錄每一步腳印，但要讓整體策略不會飄掉。 **`EXPERIMENTS.md`** 負責實驗紀錄。在機器學習脈絡裡，這份檔案用來記錄每次實驗的標題、嘗試內容、結果。換成其他任務，也可以變成「方案紀錄」或「嘗試紀錄」：改了什麼、為什麼改、結果如何。 **`EXPERIMENT_NOTES.md`** 是即時草稿。它按照時間順序記錄 Agent 執行時的想法。這份檔案的價值不是漂亮，而是可審計。當 Agent 開始往奇怪方向前進，人類可以從筆記看出它是在哪個推理步驟轉彎太猛，然後把它拉回來。 其中 `EXPERIMENTS.md` 最重要，因為它讓人類和 Agent 都能回顧過去嘗試，以及每個嘗試為什麼有效或無效。 > **Mogu 認真說：** > > 長時間 Agent 最怕的不是犯錯，而是忘記自己犯過同一種錯，然後帶著滿滿自信重演一次。這種紀錄檔看起來很樸素，但它其實是在幫 Agent 裝防呆護欄。 `EXPERIMENTS.md` 的節錄截圖同樣只留下 `[media]`，沒有實際文字內容。能可靠整理出的形式，是一份乾淨、整理過的實驗列表，每筆包含標題、簡短描述與結果。 --- ## 煞車、儀表板、航海日誌要一起出現 到這裡，`/goal` 的形狀就很清楚了：清楚、可量測的目標；緊密的回饋迴圈；讓 Agent 用 Markdown 檔案留下工作記憶。它們不是三個平行建議，而是一套長跑安全系統：煞車決定何時停，儀表板告訴方向是否正確，航海日誌讓下一輪不要忘記上一輪撞過哪面牆。 只給清楚目標，但沒有快速測試，Agent 會知道終點在哪，卻每走一步都要等很久才知道方向是否正確。只給快速測試，但目標模糊，Agent 會很有效率地亂撞。只給檔案記憶，但沒有量測與評分，最後只會得到一堆很認真的筆記，像一個準備很充分但沒有考題的考生。 目標模式跑得久，不代表它知道什麼叫成功。成功必須被寫成可以檢查的狀態。這也是為什麼這些案例都很具體：20% 執行時間改善、測試不能退步、200 條格式規則要勾完、評分時間從天級縮到分鐘級、三份檔案分別記計畫、實驗、即時想法。 這不是華麗的提示詞魔法。這是工程管理，只是管理對象換成一個不會累、但很需要邊界的 Agent。真正的張力也在這裡：越能長時間工作的 Agent，越不像玩具，越像一台真的會把指令放大的機器。 長跑 Agent 的同一個問題，也可以從別的角度切進來：[GP-192](https://gu-log.vercel.app/posts/gp-192-20260508-article-agent-ralph) 講外部記憶與人工釐清，[GP-191](https://gu-log.vercel.app/posts/gp-191-20260507-danizhu-claude-dreams-agent) 和 [GP-193](https://gu-log.vercel.app/posts/gp-193-20260508-article-autobrowse-agent) 則分別看記憶整理與瀏覽器任務交接。長跑任務真正怕的不是跑不久，是跑很久之後忘記自己為什麼在跑。 --- ## 結語 `/goal` 最迷人的地方，是它讓 Agent 可以連續鑽很難的問題。`/goal` 最危險的地方，也正是它可以連續鑽很難的問題。魔法按鈕沒有消失，只是按鈕旁邊應該多貼三張標籤：煞車在哪裡、儀表板看哪一格、航海日誌寫在哪個檔案。 所以關鍵不是讓 Codex「更自主」，而是讓自主有可量測的終點、有夠快的回饋、有寫在檔案裡的記憶。少了這三件事，目標模式只是把模糊願望接上無限迴圈；補上這三件事，才開始像一個能長時間工作的工程系統。 真正的指令不是「去把它變好」。真正的指令是：成功長什麼樣子、怎麼測、試過什麼都寫下來。 然後，才輪到迴圈開始跑。