長時程 Agent：休眠、檢查點與獨立評估
長時程 Agent 的工作單位是跨天工作流，不是單次提示詞。事件驅動休眠、逐步檢查點、獨立評估三角色，是讓報到、核貸、簽核類流程真正可恢復、可信賴的三塊骨頭。
多數 Agent 示範是無狀態的：你問、它答，十到十五分鐘的 context 用完就丟。看起來像「會做事」，工作單位其實仍是單次提示詞。真實業務裡，報到、核貸、客服升級、跨部門簽核，往往以小時、天、甚至週計——中間有人簽名、物流送達、外部 webhook、半夜排程。若你的 Agent 不能在等待中真正停下、醒來後不幻想中間發生過什麼，它就只是較貴的聊天窗。
這是「Agent 系統工程」系列第二篇。第一篇談記憶分層；本篇談正交的問題：長時程執行（long-running agents） 需要哪三塊骨頭——事件驅動休眠、逐步檢查點、獨立評估。
從「提示詞」到「工作流」
長時程 Agent 的工作單位不是一句 prompt，而是一條跨 Session、可恢復的流程。它要能端到端負責多步驟任務，而不是每一步都靠人類把上一步的 JSON 貼回去。
這與「上下文視窗變長」不是同一件事。窗再長也會滿，品質會從中間爛掉；更重要的是，等人簽文件的三天，你不該讓一個執行緒空轉輪詢，也不該把三天的閒聊塞進同一個 context 假裝還醒著。
三個先決條件
1. 真的能休眠（事件喚醒）
錯誤做法：while true 輪詢資料庫或外部 API，燒錢又脆。
正確方向：在明確的暫停點把狀態寫死，程序可以退出或縮成零；直到 webhook、排程、人工核准、或工具回呼再把流程拉起來。
休眠不是詩意修辭，是資源與正確性需求：等待期間不佔用推理迴圈，醒來時只依賴持久狀態，不依賴「模型還記得昨晚說過什麼」。
2. 每一步都有檢查點
狀態必須在每次轉換時落地。容器重部署、進程被殺、審核人員三天後才點按鈕——Agent 都應從上次合法狀態繼續，而不是憑語義記憶腦補「應該已經簽過了」。
這通常意味著：狀態是資料庫裡的列舉或狀態機，而不是向量庫裡一坨原始 JSON 聊天。沒有外部結構時，長跑 Agent 常見結局是偏離目標、破壞系統、或直接放棄——因為它根本不知道自己走到哪。
3. 不能自己當自己的考官
生成與評估若由同一條推理鏈、同一個「想過關」的動機完成，品質會系統性偏樂觀。包含多家實驗室在內的觀察大致一致：代理評估自己的輸出時，往往過度自信。
較穩的拆法是三角色（名稱可換，職責別混）：
| 角色 | 職責 |
|---|---|
| Planner | 拆步驟、訂成功標準、決定何時暫停等人 |
| Generator | 執行、呼叫工具、產出草稿與動作 |
| Evaluator | 獨立檢查是否達標；不達標則打回或觸發有限重試 |
這與第一篇「記憶分層」裡的生成／驗證分離、以及產品工程裡的 loop checker，是同一族設計：把做與判拆開。
一個具體形狀：跨天的報到流程
想像人資報到：建案 → 發歡迎與文件包 → 等員工簽署 → 等筆電物流送達 → 產生第一天行程 → IT 開帳號（可委派子代理）……
關鍵設計選擇：
- 狀態機排序：不能被 UI 或使用者「跳步」逼到後段；沒簽名就不能假裝硬體已就緒。
- UI 不做樂觀更新：畫面等後端恢復執行後再變——用來證明暫停／恢復是真的，不是前端假動畫。
- 協調者 + 專職子代理：需要 IT 配置時委派，而不是讓一個巨無霸代理既談薪資又管帳號又寫歡迎信，推理鏈糊成一團。
這類流程展示了長時程相對聊天機器人的三點不同：
- 持久記憶結構（狀態可查、可恢復）
- 事件驅動休眠（暫停點之間不空轉）
- 多代理委派（專職、鏈路清晰）
長跑時最常撞的三道牆
| 牆 | 症狀 | 方向 |
|---|---|---|
| 上下文退化 | 窗滿了、中間事實丟失、品質掉 | 狀態外置；對話只保留必要；摘要進 Memory Bank 而非無限堆 context（見系列①） |
| 缺持久狀態基建 | 重跑就亂、無法解釋走到哪 | 狀態機 + 檢查點 + 可觀測的轉換 log |
| 自我驗證失效 | 「做完了」但其實沒做完或品質差 | 獨立 Evaluator；關鍵步驟人工閘；工具層 deterministic 檢查優先於「再問一次模型開不開心」 |
框架與平台在過去一年的進步，多半是在補這三塊：可組合的多代理、session／memory 產品化、可恢復的工作流 runtime——而不是再換一個「更會聊天」的模型就結束。
和「快迭代」並不矛盾
短週期產品開發強調每天發布、快速承認錯誤；長時程 Agent 強調跨天正確。兩者衝突只存在於誤解：
- 產品迭代要的是：錯誤便宜、回饋快。
- 單筆業務流程要的是：狀態不丟、不跳步、不自嗨。
你可以很快地改進「報到狀態機的某一個轉換邏輯」，同時要求每一次真實報到實例都有檢查點。速度放在系統演進；嚴謹放在實例執行。
可執行的起步檢查清單
若你要從聊天式 Agent 升到長時程：
- 畫出狀態機：哪些節點是自動，哪些是等人／等事件。
- 每個轉換寫入持久儲存；恢復時只信儲存，不信模型回憶。
- 暫停點明確：睡什麼、誰叫醒、叫醒後讀哪一個狀態 ID。
- 拆出 Evaluator（規則／測試／另一模型／人審，依風險選）。
- 禁止「同一 agent 寫完又給自己打 A+」當唯一閘。
- 觀測：每個實例的當前狀態、停留時長、重試次數——否則長跑無法維運。
結語
長時程 Agent 的產品形態，比較接近會睡覺的工作流引擎，中間嵌著會推理的步驟，而不是「永遠醒著、context 無限的超級員工」。
休眠省資源與幻覺；檢查點保證真相在磁碟上；獨立評估壓住自我吹捧。三者缺一，跨天任務要嘛貴，要嘛假，要嘛安靜地做錯。
系列第一篇談「記得住什麼」；本篇談「跨時間還跑得動且可信」。下一篇補上工具介面那一層：MCP 為什麼不是取代 API，而是讓模型以標準方式發現與使用能力。
延伸閱讀
- 本系列 ①：Agent 記憶不是一個向量庫
- 本系列 ③：MCP 在 API 之上：模型如何發現工具
- 當實作不再是瓶頸：把「選擇與驗證」工程化
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。