LoopX 長時間 AI Agent 狀態管理指南：讓任務可恢復、可驗證、可交接

你讓 agent 跑一個下午，研究做了、檔案也改了。隔天重開 session，它先重做昨天的搜尋，再把已完成的步驟當成待辦，最後很有自信地說「任務完成」。最煩的不是多花幾個 token，而是你已經不知道哪一份紀錄才是真的。

這篇不承諾一鍵自治。我們要做的是更實際的事：用 LoopX 的設計拆出一份最小狀態契約，讓長任務中斷後能恢復，遇到授權邊界會停手，交給另一個 agent 時也有東西可查。

這是給自行維護 agent automation、串接 runner，或讓 agent 操作發布與 production 系統的開發者指南。如果你只在 ChatGPT、Notion 裡手動處理工作，而且沒有自動副作用，先用一份清楚的 checklist 就夠了，後面的 YAML 和 claim/lease 不必硬上。

TL;DR：先保存 current truth，再談更長 context

長時間 agent 的 durable state：不是把完整聊天永久保存，而是把目前目標、執行權限、未解 gate、下一個 bounded todo、已驗證證據與停止條件放在 chat 之外。新 session 只要讀這份 current truth，就能判斷下一步能不能跑。

你的任務	最小做法	先別加什麼
一個 session 內完成、沒有外部副作用	保留一般待辦即可	不必導入 control plane
跨 session 的單 agent 任務	goal、gate、todo、evidence、budget	claim、lease、peer routing
多 agent 共用同一批工作	再加 claimed_by、lease、capability、衝突處理	不要只靠大家寫同一份 Markdown

Context 是工作記憶，能幫模型當下思考；durable state 是 operational truth，負責告訴下一輪現在走到哪裡。兩者用途不同。

為什麼聊天紀錄與 compaction 仍救不了長任務？

Anthropic 的長時間 agent harness 研究記錄了兩種很熟悉的失敗：agent 一次做太多，context 結束時留下半套成果；或後來的 session 看到一些成品，就太早宣布完成。研究採用 progress file 與 git history，讓 fresh session 能接手增量工作，也明確指出 compaction 本身不夠。

問題在於四種資料常被混成一團：

資料	回答的問題	適合用途
Transcript	剛才說了、做了什麼？	debug、追查工具呼叫
Summary	這段對話大意是什麼？	快速重建脈絡
Active state	現在什麼是真的、誰有權做什麼？	恢復與決策
Event/evidence ledger	哪個變更已發生、如何驗證？	audit、交接、回滾

摘要可以漏掉細節，transcript 也可能包含後來被推翻的計畫。真正要恢復任務時，你需要的是 active state。舉例來說，「打算建立 PR」只是對話內容；PR URL、commit SHA 與 CI 結果才是可檢查的 evidence。

LoopX 到底是什麼，又不是什麼？

LoopX 是什麼：LoopX 官方把它描述為 provider-neutral、local-first 的狀態核心與 control plane。它把 objective、gate、todo、evidence、quota 和 handoff 留在一個 compact layer，再由 Codex、Claude Code、Cursor、shell agent 或自訂 runtime 執行每一輪工作。

我們重新核對官方 README 後，確認它不是新的模型，也不是代替 agent runtime 的 hosted service。文件還明確提醒，LoopX 不是 autonomous production controller，危險權限、發布、production write 與最終 ownership 仍應留給人類。

名稱也別認錯。本文談的是 GitHub 上的 huangruiteng/loopx 開源專案，不是其他名稱相近的公司或產品。

目前更合理的看法，是把 LoopX 當成一套可檢查的 local substrate。官方 README 列出一個跨 200 小時以上 elapsed lifetime 的 OpenViking 公開貢獻歷程，以及一個經遮蔽的 owner-run Auto ML showcase；官方特別說明，這不是連續 200 小時模型執行，也不是 production autonomy 或獨立重現結果。另有獨立使用者回報 13 小時以上 C++ 任務、四天 unattended run 與七個 merged PR，但這些仍是使用者自述。已有公開案例，不等於已證明 production readiness。

五個狀態物件，如何組成可恢復的最小契約？

先不急著安裝。把你現有 automation 寫成下面這份最小契約，就會立刻看見哪些地方只存在 agent 腦中。

goal:
  objective: "完成一篇有官方來源的工具評測"
  authority: "可寫草稿，不可發布"
  state: active
gate:
  status: pending
  question: "是否接受新增付費來源？"
todo:
  id: validate-sources
  action: "逐一確認 references 可開啟"
  status: ready
evidence:
  - type: file
    value: "draft.md"
    verified_by: "frontmatter-validator"
budget:
  max_attempts: 2
  attempts_used: 0
  stop_when: "沒有新的 verified delta"

這是本文為了教學整理的 reference implementation，不是 LoopX 官方固定 schema。真正重要的是責任：goal 由 owner 定義，agent 不可自行擴張 authority；gate 要寫成能回答的具體問題；todo 一次只描述一個可驗證動作；evidence 要能由檔案、測試或外部系統 readback 查證；budget 決定何時停止。

LoopX 的 state interaction model 進一步區分 actor 與寫入邊界。Dashboard 只是 projection，不能變成另一份會和原始狀態漂移的真相。這跟我們整理 AI agent 安全框架時碰到的核心問題很像：可觀察不代表有權執行，畫面上看得到按鈕，也不代表 agent 應該按下去。

15 分鐘建立最小狀態契約

這 15 分鐘只用來盤點與寫出 contract，不包含接 runner、處理 concurrency 或跑故障演練。Bounded transition 的意思很簡單：每一輪只接受一個清楚輸入，完成一個有限動作，驗證結果，再把狀態交回去。不要用「繼續研究直到完成」當 loop condition。

盤點 current truth：列出目前目標、權限、blocker、下一步與已存在成果。無法指出唯一來源的欄位，就是第一個缺口。
把一輪縮成一個動作：例如「收集來源」和「驗證來源」拆成兩個 todo，不要在同一輪順便寫稿、發布與通知。
定義 evidence：收集完成要有 URL 清單，驗證完成要有 HTTP 結果或官方頁面內容，不能只存「已確認」。
固定 restart 讀取順序：先 registry，再 active goal、pending gate、next todo、recent evidence。Transcript 放到真的需要 debug 時才讀。
沒有 delta 就停：LoopX quota 文件把 quiet skip 與 preflight failure 視為不應消耗 slot 的情況。沒有新授權或新證據時，安靜等待比生成一份「進度更新」可靠。

拿內容研究 automation 來說，第一輪 collect 只產生候選來源，第二輪 validate 才確認官方性與時效，第三輪 handoff 寫入可用 claims。這三輪都能單獨失敗、重跑與驗證。手作 YAML 可以先幫你看清流程，但它不會自動帶來 atomic write、schema validation 或 claim conflict protection，這些得另外實作或交給合適工具。

單 agent 與多 agent，要在哪裡分叉？

單 agent 先把 restart identity、gate、evidence 與 budget 做好，已經能消掉大部分「重啟後不知道從哪裡接」的混亂。這時加入 lease 和 capability routing，只會多出維護成本。

兩個 agent 可能同時拿同一項 todo 時，才需要多一層協調：

claim:
  todo_id: validate-sources
  claimed_by: reviewer-02
  lease_expires_at: "2026-08-12T15:00:00+08:00"
  capability: source-verification
  handoff_when: "all official links return a valid page"

LoopX todo contract把 ownership、claim 與交接做成明示狀態。你仍要實測自己的儲存與 runner：兩個 process 同時 claim，是否只會有一個成功？過期 lease 回收時，舊 worker 的晚到 writeback 會不會覆蓋新結果？官方文件沒承諾的 production guarantee，不要因為介面看起來完整就自行補上。

遷移前至少記下五個實測結果：舊 todo 與 evidence 如何匯入、雙 process claim 是否互斥、過期 lease 的晚到 writeback 如何處理、升級是否需要 state migration，以及停用後能否匯出人類可讀資料。無法從官方文件確認的欄位就標成「待實測」，別拿預期行為當保證。

四個 failure drills，驗證它真的能恢復而不是看起來能跑

正常路徑跑通不稀奇。真正能讓你放心睡覺的，是故障發生時系統仍做對事。

Drill A：做到一半直接砍 process

在產生外部副作用前終止 runner，用全新 session 啟動，不餵舊 transcript。它應能只靠 durable state 找到 current goal、未完成 todo 與最後 verified evidence，而且不重複已完成的副作用。

Drill B：讓 owner gate 一直 pending

給 agent 一條明確不可跨越的發布 gate。預期結果是 quiet no-op，或只走事先核准的 fallback lane，例如繼續整理草稿，但絕不能偷偷發布。Lifetime goal 代表意圖持續存在，不代表無限授權。

Drill C：讓兩個 peers 同搶一項 todo

同時送出 claim，確認只有一個有效 owner；再模擬 lease 過期，檢查新 owner 接手後，舊 owner 是否會被拒絕寫回。這個測試會很快揭露「大家共寫一個 JSON 檔」到底安不安全。

Drill D：讓舊 worker 寫回舊 schema

先讓舊版 worker 讀取狀態，再升級 schema，最後放行舊 worker 的 writeback。系統應檢查 schema version、拒絕不相容更新並保留原狀態，同時留下 migration 或人工介入路徑。做不到，就表示升級期間必須先停 worker，不能假設 rolling update 安全。

四個 drill 可以共用一組驗收標準：verified evidence 有新增、重複 side effect 為零，而且只有 valid transition 才記入 budget spend。這是本文建議的測試方式，不代表 LoopX 已保證 rolling update 安全，也不是官方公布的效能數據。

資料與權限邊界，哪些內容絕對不能 commit？

狀態必須持久，不代表所有內容都該進 Git。LoopX 的 public/private boundary要求 credentials、private traces、raw operator artifacts 與 active private state 留在公開 artifacts 之外。

資料	建議位置	原因
Current truth	受控 state store	需要一致寫入與明確 owner
Transition/event ledger	Append-only log 或 git history	方便 audit 與回滾
Debug transcript	Private trace store	內容長，可能含敏感輸入
跨專案查詢資料	Database/index	方便篩選與聚合
Credentials	Secret manager 或受保護環境變數	不應進入 model 可任意寫回的狀態

我們逐項比對 LoopX 的狀態文件時，還看到一個容易忽略的風險：evidence 也可能是 agent 自說自話。Anthropic 的 agent eval 指南用訂票例子區分 transcript 裡「已訂位」的陳述，和資料庫裡真的存在 reservation 的 outcome。換到你的流程，就是讓 CI、API readback 或獨立 evaluator 查結果，不讓執行者自己替自己蓋章。

什麼時候不該用 LoopX？

判斷面向	繼續用簡單待辦	值得評估 LoopX 類控制層
任務長度	一個 session 可完成	經常跨 session 或跨天
外部副作用	幾乎沒有	會發布、付款、改 production
Agent 數量	單一執行者	多個 peers 會搶工作
中斷成本	重跑很便宜	重跑會重複操作或浪費大量資源
Audit 需求	看最終檔案就夠	必須知道誰在何時依什麼證據推進

如果你要的是託管 SLA、跨區 HA、完整企業 IAM 或成熟 workflow engine，不能只看到「control plane」就假設 LoopX 都有。官方明確表示 LoopX 不是 autonomous production controller，危險權限、發布、production write 與最終 ownership 仍由人類掌握。反過來說，只有一個晚上能做完、失敗後重跑也沒差的小任務，一份清楚的 checklist 往往更省事。

OpenAI 的 Agents SDK 更新也把 state externalization、snapshotting 與 rehydration 放進長時間工作的設計裡。這能獨立證明 durable execution 是真需求，但不能拿來替 LoopX 背書，更不能把 OpenAI SDK 的能力寫成 LoopX 已提供的保證。

結論：長任務的目標不是一直跑，而是永遠知道下一步能不能跑

挑一條你現在的 automation，先寫 goal、gate、todo、evidence 與 stop rule，然後真的砍掉 process 做一次 restart drill。過不了，就先別增加 scheduler 頻率或更多 agent，那只會讓錯誤跑得更勤快。

如果任務短、沒有外部副作用，用一份好 checklist 就好；如果它跨 session、會動到真實系統，先做最小狀態契約；等多個 agent 開始搶同一批工作，再加入 claim、lease 與 LoopX 這類 control surfaces。可靠不是永遠不停，而是該停的時候真的停得下來。