為什麼我們不追逐 Graph、Loop 與 Harness Engine：CMS 早已進入外循環

最近幾個月，graph engine、loop engine、harness、Agent Teams、nested subagents 成為熱門話題。

很多人可能會問：為什麼我們很少討論，也不特別分享這些機制？

答案很直接：它們大多仍在延伸產品的內循環，而我們早已把問題移到外循環。

這不是說內循環不重要。相反地，Claude Code、Codex、Grok 本身就是產品，自然必須持續讓 agent 更會思考、更會使用工具，也能生成更多層 subagent。只是當你已經擁有外循環，新的 graph、loop 或 harness 就不再是能力解鎖，而是可以評估、吸收或替換的零件。

產品負責把內循環做好

一個 coding agent 最基本的內循環是：

prompt
  → 模型判斷
  → tool call
  → observation
  → 下一輪判斷

今天的 Claude Code、Codex 與 Grok，正在這個循環裡加入更好的 context 管理、subagent、team、graph、hook、background task 與 resume 體驗。

這是產品應該做的事。不是每位使用者都熟悉 supervisor、state machine、checkpoint 或 failure domain。產品必須把複雜性包起來，讓工程師不用先設計一套執行系統，也能可靠完成工作。

但成熟工程師看到的會再多一層：Claude Code、Codex 或 Grok 不必擁有整個任務生命週期。它們可以只是 worker。

架構經驗讓你提早進入外循環

當你理解 process、state、retry、idempotency、lock 與 recovery，就可以把產品提供的內循環放進自己的外循環：

載入 durable state
  → 選擇一個 inner-loop worker
  → 啟動獨立 process
  → 驗證實際結果
  → 寫入 checkpoint
  → retry、換 CLI、停止，或進入下一輪

這時真正擁有工作流程的，不再是某個 LLM session，而是外部 control plane。

模型可以換、CLI 可以換、process 可以死亡，任務本身仍然存在。因為已完成什麼、還缺什麼、做過哪些決策、卡在哪裡、下一步是什麼，都保存在模型 context 之外。

這就是 CMS（Claude Multi-Session）的核心。

CMS 把 `claude -p` 變成可替換的 Worker

CMS 沒有把所有智慧塞進一個更大的 root prompt。它把 Claude Code 的非互動 -p／--print 模式抽出來，當成可以由外部程式反覆啟動的 worker protocol：

CMS orchestrator
  → 讀取 checkpoint
  → spawn claude --print
  → worker 完成一個有限任務並輸出 report
  → orchestrator 驗證結果、更新 state
  → process 結束；下一輪啟動新的 worker

Worker 內部仍然可以使用 subagent、Agent Teams 或 graph workflow。差別在於，它不擁有整個 mission。排程、並行數、retry、停止條件、CLI routing 與恢復位置，都由外循環管理。

CMS 也不綁定單一模型。同一個 state contract 可以交給 Claude、Codex 或 Gemini。只要 worker 能讀取任務狀態並輸出結構化 report，下一輪就能由不同 CLI 接手。

Checkpoint 是 Process 之間的 API

外循環不能只保存一段「上一輪做了很多事」的聊天摘要。下一個 process 需要明確知道：

已完成與待完成項目；
重要決策與不能破壞的限制；
目前 blocker 與失敗原因；
上一輪實際修改與驗證結果；
下一個可以執行的動作。

CMS 將這些資訊保存為 checkpoint 與逐輪 report。狀態更新使用 lock、atomic write 與 backup，避免平行 worker 互相覆蓋，或在 process 中斷時留下半份狀態。

因此 process crash 不等於 mission 消失。新的 terminal、新的 process，甚至不同 CLI，都可以從 checkpoint 繼續。

CMS 系列指令處理不同形狀的長任務

我們內部使用的進階 CMS 不是一條超長 prompt，而是一組共用相同 process、state 與 recovery 合約的指令：

指令	用途
`/cms`	拆解工程需求，分派 planner、builder、tester、reviewer、fixer 等獨立 workers
`/cms-auto-cycle`	每輪以 fresh process 完成一個 TDD／acceptance criteria 循環
`/cms-iterate`	執行可持續數十輪、可停止與恢復的通用 iterator
`/cms-auto-explore`	反覆探索、評估、實作並驗證下一個高價值機會
`/cms-review`	逐模組審查大型專案，保存發現並分批修復與驗證

這些指令的共同點不是 agent 數量，而是任務生命週期位於 agent process 之外。

這條路線不是最近才開始

我們在 2025 年 7–11 月的內部建置期就開始使用外循環架構，並一路運作至今。進階 CMS 把每輪工作隔離在獨立 process，完整處理 checkpoint、report、resume、backup、並行控制與跨 CLI routing。

2026 年 1 月，我們也已透過開源專案 Director Mode Lite 分享基礎版。首版就包含 iteration、checkpoint、resume、status、stop 與 Stop Hook；後續的 Evolving Loop／Orchestrator 再加入分階段狀態與 file-based report。

開源的是外循環的基礎模型；完整的 process-isolated CMS 則是我們持續內部使用的進階版。

這條架構路線比近期的 graph、loop 與 harness 討論至少早了八個月。領先的不是某個功能名稱，而是更早理解：loop 應該由誰擁有。

為什麼我們不追逐每一個新 Engine

如果新的 Agent Team、graph engine 或 harness 能讓 worker 跑得更快、協作更好、telemetry 更完整，我們當然可以採用。它們可以直接放進 CMS 的某個 worker process 裡。

但評估標準不再是「這是不是最新方法」，而是：

它有沒有改善 state contract？
它有沒有提高 isolation、recovery 或 observability？
它能不能降低失敗成本？
它是否讓 worker 更容易被替換？

如果答案是肯定的，就吸收它。如果只是替既有 topology 換一個新名字，就繼續做事。

這就是為什麼我們沒有花很多時間逐一討論最近流行的內循環機制。不是沒看到，也不是排斥新工具；而是外循環早已完成，這些工具只需要放回正確的架構位置。

工具名稱會一直改，subagent 層數也會一直增加。但成熟的執行系統始終在回答同一個問題：

現在負責思考的 process 消失後，工作本身還能不能繼續？

CMS 的答案是：可以。因為 process 是 worker，checkpoint 才是事實，而外循環擁有整個 mission。

延伸閱讀：我們在 Agent Teams 存在之前就建好了它與從 Userland Hack 到 SDK 原生：CMS 遷移藍圖。