讓智慧代理跑上一整天 — 長時運行編碼代理的維運基礎設施

問題是什麼

很長一段時間裡，用編碼代理就是短促的來回。改一下這個函式、看一下這個測試，人每隔幾分鐘握住又放開鍵盤。可 OpenAI 的 Codex 在從空倉庫做設計工具的實驗裡，約25小時沒有人工介入地一路跑了下來。燒掉1300萬 token，生出3萬行程式碼。現在可以按小時、甚至按天放開代理，而不是按分鐘。麻煩在於，一旦放它跑這麼久，短任務裡藏著的東西就會一齊冒出來。上下文視窗反覆被填滿又壓縮，在這個翻攪裡代理從最初的規格慢慢漂移。token 成本毫無節制地線性堆積，一位實務者警告長時運行模式「消耗多到離譜的 token」，五小時上限的方案還沒把大活做完就到期。最要命的是，凌晨3點跑著的25小時運行悄無聲息地崩掉，到早上都沒人發現。代理你能啟動 — 但那一層維運：盯著它是不是真在跑、成本漏了就停、漂移了就抓住、卡住了就呼叫人 — 整塊都是空的。

為什麼是現在

長時運行從實驗室展示跨進真實工作流的訊號同時冒出來好幾個。OpenAI 在 GPT-5.1-Codex-Max 裡推出了壓縮：上下文接近上限時，模型修剪歷史、保留核心狀態另開一個新視窗繼續執行，內部評測報告它在單任務上自主跑了24小時以上。Codex CLI 在 v0.128.0+ 加了 /goal 指令，處理能跨越中斷、工作階段斷線和 token 上限存活下來的持續目標。不再是一次給一條指示，而是給一個帶可驗證停止條件的目標，讓代理跨多輪去追求。模型側的效率也跟上了：在同等推理強度下少用30%思考 token 還拿到更高準確率的報告，正是讓整天自主在經濟上跑得通的條件。也就是說，模型和執行環境已經在朝長時運行全力跑。可真正能同時管制多個運行、即時看成本和漂移、在卡住的節點呼叫人的那塊儀表板，卻是每個團隊用 Markdown 檔案和 shell 指令稿每次手工拼。沒有標準化維運工具，典型的空白。

怎麼構建

入口大致有三條。一，檢查點與還原層。25小時實驗裡真正馴住代理的，是刻在倉庫裡的規格、計畫、狀態 Markdown 檔案。把這種外部化狀態的模式從手寫檔案抬升成產品：給運行打快照，崩了就從最後一次通過驗證的節點把它救活，自動留下「做了哪些決定、走到哪一步」的稽核軌跡。二，漂移與成本管制儀表板。把多個代理運行放在一塊螢幕上看。現在在哪個里程碑、燒了多少 token、偏離規格多遠（碰了那個說好別改的檔案沒有）、在哪兒驗證崩了。設預算上限，半夜 token 暴漲就自動停。三，人工介入節點設計。代理在判斷的岔口停下呼叫人，拿到答覆就原地接著跑；把可驗證停止條件和「別改這個」的約束放在一處管理的策略層就掛在這裡。變現走團隊訂閱 — 並行運行數、保留的檢查點容量、管制的代理台數。別一開始就盯所有模型和執行環境，深扎進一個率先押注長時運行的執行環境（如 Codex /goal），成為那個生態的控制塔，更實際。

flowchart LR
  A[長時運行代理] -->|進度狀態| B[檢查點層]
  A -->|token 與漂移指標| C[管制儀表板]
  C -->|超預算| D[自動停機]
  C -->|需要判斷| E[人工介入]
  E -->|答覆| A
  B -->|崩潰時還原| A

成功條件

這個市場拼的是「多快贏得信任」。第一，維運層本身必須比它管制的代理更穩。控制塔一晃，底下所有運行跟著晃 — 檢查點還原只要有一次出岔、把好端端的活給丟了，客戶立刻掉頭就走。第二，成本護欄必須是即時攔截，而不是事後帳單。「你昨天用了這麼多 token」已經太晚，價值在於踩到上限前那一下停住。第三，漂移偵測才是資料鎖定的核心。哪些訊號真正預示漂移（哪種檔案改動、哪種驗證失敗模式），只會隨著運行累積越來越準，那份越滾越大的優勢是快速跟隨者複製不了的。最常見的失敗，是一上來就想撐住所有執行環境，結果哪個都沒扎深。