如果你只用一個 Agent，很多問題其實都不複雜。給它任務、給它工具、讓它跑測試，做完以後再看結果就行。真正開始變麻煩，通常是你同時把 Codex、Claude Code、Cursor，甚至一些自動化 worker 接進同一個 repository 之後。

這時最先暴露出來的問題，往往不是「誰更聰明」，而是非常普通的協作問題：Claude 以為 Codex 還沒開始，所以自己也改了同一個檔案；一個排程任務已經設定好了，另一個 Agent 就把它當成「已經成功執行」；某個任務在聊天裡發出去了，但接收方根本沒有真正確認；前一個 Agent 基於舊 commit 做完分析，後一個 Agent 接手時 repository 已經變了，卻還沿著舊狀態繼續做。

這些問題靠「再加一個 orchestrator」並不會自動消失。Routing 只解決任務下一步該交給誰，可靠的 multi-agent workflow 還需要另一層：誰現在擁有這項工作、大家以哪份狀態為準、handoff 是否真的被接收、執行環境是否具備所需 capability、完成之後又是誰驗證的。

我最近在 GitHub 上看到一個很極端但很有參考價值的例子：microcredit-agent-testbed 的 central message board。這個專案把 Hermes、Claude Code 和 Codex / ChatGPT 分成不同工作 lane，用一個公開 issue 加上一份 canonical world model 協調任務。它的業務背景不是重點，我真正感興趣的是裡面反覆強調的幾條規則：一個 request 不等於對方已經接單，一個 schedule 不等於任務真的跑過，設定成功也不等於後續執行成功。

這讓我重新看了一遍自己之前寫的 Agent Orchestration。以前我更關注「怎麼把任務拆給不同角色」，現在我覺得還少了一層：routing 只是編排的入口，shared state 和 handoff 才是多 Agent 真正開始工程化的地方。

編排不是「多叫幾個 Agent」，而是先把 ownership 說清楚

OpenAI 現在的 Orchestration and handoffs 文件把兩種模式分得很清楚。一種是 handoff：下一個 specialist 真正接管接下來的工作；另一種是 agents-as-tools：外層 manager 仍然負責最終結果，只把某個子任務交給 specialist。

這個差異很重要，因為它其實是在回答一個最核心的問題：到底誰擁有目前的結果。

如果 manager 一直負責，specialist 更像一個函式，做完以後把結果交回來；如果發生 handoff，控制權就真的移動了。很多 multi-agent workflow 之所以愈來愈亂，就是因為程式層面有 delegation，狀態層面卻沒有明確 ownership。每個 Agent 都知道「有人在做」，但沒有人能準確回答「現在究竟是誰負責」。

拿 Coding Agent 來說，一個最簡單的 bug 修復流程可能是：

issue
  -> triage agent
  -> implementation agent
  -> review agent

看起來已經很合理了。但如果 implementation agent 已經接手，triage agent 還能不能繼續改同一個 scope？review agent 是只讀，還是也能直接修？implementation agent 說 DONE 以後，算不算任務真的結束？如果 review 沒過，是回到 WORKING，還是重新建立一個 request？

這些規則如果只藏在 prompt 裡，最後很容易靠模型「大概理解」來維持流程。我現在更傾向把它們變成一份很小的協調契約。至少讓每次 handoff 都能說清楚：request id、sender、receiver、owner、deliverable、source revision、dependencies、acceptance test、需要的 capability、fallback，以及目前 status。

這不是為了把 Agent workflow 做成另一個 Jira，而是讓那些最容易產生誤會的狀態，不再需要從聊天上下文裡猜。

我最後把狀態壓得很簡單：

REQUESTED
  -> ACKNOWLEDGED
  -> WORKING
  -> DONE
  -> VERIFIED

關鍵不在五個單字，而在於不能偷跳。

訊息送出去，只能證明 REQUESTED；只有接收方自己確認，才算 ACKNOWLEDGED。建立排程任務，也不能直接推斷它已經 DONE。Agent 自己說做完了，可以進入 DONE，但只有拿到測試、diff、log 或其他驗證證據，才應該進入 VERIFIED。

這看起來有點保守，但 Agent 數量一多，反而會讓系統更輕。因為每個新接手的 Agent 不需要重新讀完整聊天記錄來猜發生了什麼，只要讀 canonical state 和最近幾筆 receipt 就夠了。

我把這些規則寫成了一個很小的 validator

只講協定還是太虛，所以我在 Content Lab 裡做了一個第一方實驗，沒有執行上面那個第三方 repository 的任何程式碼，只用 synthetic fixture 測協調規則本身。

第一部分是一個 coordination-contract validator。我故意構造幾種最常見的壞狀態：兩個 Agent 同時宣稱自己是同一個 scope 的 active owner；任務直接標成 DONE，但沒有 receiver acknowledgement；handoff 綁定的是舊 source revision；分配給某個 Agent 的任務需要 merge capability，但它實際上只有 read / write；任務完成了卻沒有 verification evidence；同一個 external action 已經有 active request，又重複發起一次；以及一條已經被 supersede 的任務仍然保持 active。

8 組 fixture 全部按預期被識別。

這個結果本身不複雜，我也不會把它寫成「已經證明 multi-agent 衝突率下降」。它能證明的只有一件事：很多看起來像 Agent 智慧問題的協作錯誤，其實可以在模型之外做確定性檢查。

Capability mismatch 就很典型。我們平常很容易籠統地說「這個 Agent 有 GitHub 權限」，但實際執行裡，read、edit、push、merge、deploy、secret access、對外傳訊息，根本不是同一種 capability。某次互動式 session 能 push，也不代表一個 scheduled worker 在另一個環境裡同樣能 push。

所以我現在愈來愈不喜歡用一個模糊的 has-access 來描述 Agent。更合理的方式，是讓任務宣告自己需要什麼 capability，再由執行環境明確回答有沒有。

Claude Code 目前的 subagents 文件 也和這個方向一致。每個 subagent 有獨立 context，可以限制 tool 和 permission；如果需要隔離 repository 修改，還可以放進單獨 worktree。文件也說得很清楚：需要大量獨立探索、工具權限隔離，或能獨立返回結果時，subagent 很有價值；如果多個階段需要緊密共享 context、頻繁來回迭代，主 session 反而可能更合適。Multi-agent 不是越多越好，真正值得拆的，是那些邊界本來就不同的工作。

第二部分實驗，則專門測 receipt replay。

我讓一個 append-only event log 從 REQUESTED 一路走到 VERIFIED，然後故意測幾種非法跳轉。REQUESTED -> WORKING 會被拒絕，因為「發出任務」不能自動推斷「對方已經接單」；REQUESTED -> DONE 也會被拒絕，因為排程、設定或觸發本身都不是執行結果；如果 ACKNOWLEDGED 不是 receiver 自己寫的，也不算有效；VERIFIED 沒有 evidence 一樣過不了。

7 組 replay 檢查全部通過，而且刪除 derived state 以後，可以只靠 event log 重新推導出最終 VERIFIED 狀態。

這一點對長時間運行的 Agent workflow 很重要。狀態如果只存在某個聊天視窗裡，視窗一斷、上下文一壓縮、執行換到另一台機器，很容易就開始靠推斷繼續工作。只要 request、ack、done、verify 這些 receipt 是持久化的，新 Agent 不需要「相信前一個 Agent 的摘要」，它只需要讀事實。

GitHub 很適合做這層 control plane，但別把它當成萬能資料庫

做到這裡，我反而覺得 GitHub 很適合個人開發者先把這層搭起來。

不是因為 GitHub 天生就是 Agent orchestration 平台，而是它剛好有幾個很適合做 control plane 的屬性：狀態可以版本化，修改有作者和時間，commit 可以當 revision，issue / PR 能掛 evidence，repository file 又能直接被 Codex、Claude Code 這類工具讀。對小團隊或個人專案來說，你不一定要先上一個專門的 orchestration backend，先把 canonical state 固定在 repository 裡，就已經能解決不少跨 session 問題。

我自己的 Content Lab 現在其實就在這樣做。Current topic、active Dossier、上一條 command、下一條 command 都會持久化；Dossier 的狀態從 DISCOVERED、SCORED、RESEARCHING、READY_FOR_TEST 一路追加，不靠某一個聊天視窗記住「現在做到哪裡」。這次實驗也順手驗證了：active pointer、explicit next command 和 append-only state history 都可以在同一套 GitHub-backed workflow 裡穩定使用。

但我不建議把所有 runtime state 都一股腦塞進 repository。高頻 lock、毫秒級 lease、大規模 message queue、temporary token、敏感 credential，這些明顯不是 Git 的強項。GitHub 更適合保存那些需要跨 session、跨 Agent、可追溯的 durable facts。

我會把它想成兩層：

runtime state
  -> 臨時執行、lock、stream、短生命週期訊息

canonical coordination state
  -> owner、revision、handoff、receipt、evidence、最終 decision

前一層可以放 database、queue、SDK session；後一層則需要「過幾天再回來，還能知道當時到底發生了什麼」。

OpenAI 現在的 Running agents 也把 state 明確拆成不同 continuation strategy：你可以自己保存 history，也可以使用 session、server-managed continuation，或恢復被 interruption 暫停的 run。同時 Agents SDK 的 observability 文件 會記錄 model call、tool call、handoff、guardrail 等 trace。對我來說，這兩層剛好說明同一件事：執行狀態和可稽核狀態都需要設計，不能只靠 prompt。

真正應該先補的是「誰做了什麼」的證據鏈

回頭看原來那篇 orchestration，我現在還是認同一個原則：如果一個 Agent 就能穩定做完，不要為了架構看起來漂亮，硬拆成五個 Agent。OpenAI 現在的文件也直接建議，能從一個 Agent 開始就先從一個開始，只有在 capability isolation、policy isolation、prompt clarity 或 trace legibility 真的需要時，再加入 specialist。

但一旦你已經開始用多個 Agent，我會比以前更早補 shared state。

不是先上更複雜的 supervisor，也不是先研究誰當 planner、誰當 reviewer，而是先把幾個很基礎的問題釘死：一個 scope 同一時間誰負責；接收方有沒有真的確認；任務基於哪個 revision；這個 Agent 到底具備什麼能力；DONE 之後有什麼 evidence；出了問題以後能不能從 receipt 重新還原發生過什麼。

這層東西不酷，也不會讓 demo 看起來更「智慧」。但真正長期運行以後，它比多加一個 Agent 更重要。

因為 multi-agent 系統最怕的並不是某個模型偶爾答錯，而是每個 Agent 都各自合理，合在一起卻沒人知道真實狀態。一個 Agent 以為任務沒人做，一個 Agent 以為自己已經完成，一個自動化以為 schedule 已經執行，一個 reviewer 又在舊 revision 上驗收——最後每個局部判斷都說得通，整體卻已經失真。

所以現在如果有人問我 Agent Orchestration 到底是什麼，我不會只回答「讓多個 Agent 分工協作」。

我更願意把它說成：把任務、狀態、權限和證據組織成一條不需要靠猜的 workflow。

Routing 決定下一步交給誰；ownership 決定現在誰負責；handoff 負責把 context 和邊界交過去；receipt 證明對方真的接了；capability boundary 防止任務被交給一個根本做不了的人；trace 和 evidence 則讓你之後還能解釋這件事為什麼變成現在這樣。

如果你正在繼續把 Coding Agent 往真實專案裡接，前面那篇 CLAUDE.md 太長怎麼辦：我重新拆了一遍 AGENTS.md、Skills 和 CI 的邊界 更偏「規則應該放在哪裡」；這篇解決的是下一層問題：當不只一個 Agent 開始一起工作以後，這些 Agent 怎麼共享一份可信的現實。