Day 5｜worker、manager、coordinator 是怎麼長出來的

如果你也把事情拆給好幾個 AI 做，先問自己一個問題：誰負責把它們的結果收起來？我的 repo 有四種啟動 session 的方式、四個 agent 定義檔，攤開像一張畫好的組織圖。但這張圖裡最關鍵的「中層」那一格，比 worker 晚了 13 天才出現，而且它進版控的 commit message 不是在談架構，是在講一件很具體的事：「讓總經理不必被每個 worker 各喚醒一輪」（9 月 5 日那筆 commit）。

架構如果是先設計出來的，commit message 會寫「引入三層架構」。我讀起來，那比較像止血，不像設計。

Day 4 結尾留下的缺口是權責：分工之後，誰決定、誰執行、誰驗收。這一篇回答它，但答案不是我畫的，是成本畫的。

事故：worker 先到，manager 後到

git log 上有兩個時間點。第一個是 2026-08-23，8 月 23 日那筆 commit 的訊息是更新三種 worker（被派出去做事的 subagent）的描述，並新增一份檔案強化派工規則；同一天更早還有一筆 commit（Enhance agent delegation rules）。CLAUDE.md 也把「由 Fable 擔任總經理的指揮模式」標注在這一天。worker 和派工規則同一天出現——我一開始想的分工只有兩層：一個主控，一群做事的。

第二個是 13 天後的 2026-09-05。一份寫給主控的派工規則檔第一次進版控（9 月 5 日那筆 commit）；這份跟 8 月 23 日那份寫給 worker 的描述不是同一份，它第一次獨立成檔，變成寫給主控的協定。

那 13 天的教訓就在這句 commit message 裡：扇出時每個 worker 完成都會回來喚醒主控一輪，而主控每被喚醒一次就要重付一次完整 context。worker 越多，主控被喚醒越多次——帳單長在主控身上，不在 worker 身上。

Day 2 那 10 個 agent 就是這個機制的極端版本：十份回報全部灌回同一個主控。當時我以為問題只是回報太長，所以規範寫「≤15 行」。13 天後我才看懂那只是一半——回報長度是塞進去多少，而「回報」這個動作本身還會叫醒主控。就算每份回報只有一行，10 個 worker 也是 10 次喚醒，每次喚醒都要把整場對話重讀一遍。壓短回報壓得到第一項，壓不到第二項。

所以中層要解的不是「worker 做得好不好」，是「主控被叫醒幾次」。這是一個純粹的計次問題，跟工作品質無關，而我花了 13 天才把它跟品質問題分開。

證據：三層架構長什麼樣

決策層下單、收斂層驗收、執行層只回報；經理自己就是中層，不再往下多開一層。

標題那三個英文角色在本篇各有對應：worker 是執行者、manager 是中層經理、coordinator 就是最上面下單與驗收的總經理那一格。

四種主控的角色分工寫在 CLAUDE.md，對照如下：

四個角色定義檔的 frontmatter 各自綁死了模型與 effort：中層經理（Opus / high）、Opus 執行者（Opus / high）、Sonnet 執行者（Sonnet / medium）、Haiku 執行者（Haiku / low）。派誰不靠臨場判斷，模型和 effort 一起寫死在檔案裡。

這件事的重點不是選了哪幾個模型，是選擇發生的時機。它發生在寫定義檔的時候，不是發生在派工的當下。派工當下我只選角色——這件事要判斷力還是照表操課——成本結構是角色自己帶著的。如果每次派工都要重新想一次「這題該用哪個模型、開多少 effort」，那就等於把一個成本決策塞進每一次的臨場判斷裡，而臨場判斷是最容易被當下的急迫感帶著走的東西。

我把派工權責集中寫成一份規則。下面直接看它如何規定何時設中層、退回幾次，以及怎麼判定違規。

主控只在下單與收表格時各動一次；worker 的完成都被中層吸收掉。

回到開頭那個矛盾。中層存在的理由就是時序圖上「主控只被喚醒一次」，所以它不是永遠都要有的角色。派工規則把門檻寫死了：工作單元 ≥3 個、或需要平行 fan-out，此時「只派 1 個中層經理統包整批」；退回上限 1 次，第 2 次仍不合格就換新的中層經理重跑整個單元，不在主控反覆往返。

解法：把權責寫成可稽核的條文

三件事。

一是開中層有條件。經理本身是 Opus，自己即中層，再往下開中層經理是同單價多疊一層。總經理由 Fable 坐、經理由 Opus 坐，兩者注入的是同一份協定檔，差別只在誰坐那個位置、以及那個位置的單價。所以三層不是階級，是條件式：單元夠多、需要平行，多插一層才換得回它吸收掉的喚醒次數；不夠多的時候，多的那一層就只是多一份要付錢的 context。

二是權責綁在協定檔，不在我的記憶裡。啟動腳本在開啟總經理或經理的 session 時，用 Claude Code 的 --append-system-prompt 把派工規則全文注入 system prompt。規則只有一份來源，改一次兩種主控同時生效。這看起來是工程細節，其實是權責問題：兩種主控如果各存一份規則，改完一份忘了另一份，之後出事我會分不清是 agent 沒照規則做，還是它照的是舊版規則。一份來源等於連條文的版本本身都可稽核。

三是違規要能從外部看見。派工規則給中層每批 120 calls 預算，超過必須停下來回一份 PARTIAL 表格；緊接著一條更直接：workers=0 且 calls>100 直接判定違規，寫進稽核紀錄。一個「中層」如果自己把活全幹了、一個 worker 都沒派，那就不是中層——不需要它承認，數 calls 就知道。這條判定我做成資料庫裡一個自動列出違規派工的查詢，代表它不必靠我記得去查：任何時候我都能用一句 SQL 問出來，哪幾次派工的中層其實是自己下去做的（這份紀錄未公開，讀者無法重跑這句查詢）。

至於中層實際省下多少輪，我沒有量過。commit message 寫的是意圖，派工規則寫的是條件，都不是實測值，目前只能算設計預期。

新問題：worker 說「做完了」，算不算數

組織圖畫好之後很快撞上下一個問題。前面那條違規判定，判的是 calls 和 workers 這種外部可觀測的數字，不是 agent 自己的說法。我的判讀是這個寫法不是巧合：當回報一份份收進來、每份都寫著 DONE 又條理分明，我沒辦法從文字本身分辨它是真的做完了，還是它以為自己做完了。

中層也讓驗收問題更尖銳：主控收到的是經過收斂的摘要，離原始執行過程多了一層。摘要是否可靠，仍需要回到可核對的結果。

明天談這件事：為什麼 AI 的自述不能當證據。