《Agent Orchestrator 設計模式：多代理協調系統架構全書》

AI 系統只用單一代理時，表面上很省事：丟需求、等答案，需要工具就再補呼叫。可是一旦任務拉長、跨領域，又得經過檢核、平行處理和鎖關，單一代理很快就撐不住。接下來要補上的，是一個會排順序、叫對人、驗成果、接住失敗流程的主控者。這個角色，就是 Agent Orchestrator。

「am.dev.orchestrator 是系統開發領域的唯一主控者，負責解析需求與切分 phase、依 phase 指派對應 sub-agent、收斂交付物。」 — .github/agents/am.dev.orchestrator.agent.md

問題通常不在某一項能力不夠，麻煩在於所有責任全擠在一起。會寫程式的代理，未必擅長規格盤點；審查做得細的代理，也不一定適合直接落地修改。流程順序也很容易被打亂，邊界都還沒定清楚就先進實作，後面多半一路補洞。更麻煩的是責任線會跟著糊掉：同一個代理同時思考、同時輸出，事後根本難查是哪個判斷點先失守。

Orchestrator 的解法，重點在把能力拆對。它像交響樂團的指揮，不拉小提琴、不吹長笛，也不直接替定音鼓手下場演奏；它真正做的是讀總譜、安排進場順序、控制節奏、提示重音、在不同樂器之間維持整體結構。這個比喻非常準確，因為好的 Orchestrator 也不應該代替 sub-agent 工作。它的價值在於協調，而不在於親自下場做某一件專業工作。

多代理架構一路演化過來，大概看得到四個台階：單體代理先包辦全部；接著進入 function-calling，代理會用工具了，但決策還是集中在同一個主腦；再往前才出現 multi-agent，各角色開始分工；真正跨進平台化，則是 orchestrated multi-agent。差別不只在代理變多，還多了一層可管理、可驗證、可回流的協調框架。從 am.course.writing-orchestrator 的 C0 到 C6，到 am.dev.orchestrator 的 P0 到 P11，都能看到這種框架化思路。

成熟的 Orchestrator 手上其實一直在管四件事。它要先做 routing，把需求送到合適的 sub-agent；接著安排 sequencing，讓流程照順序走，不准亂插隊；然後用 gating 檢查令牌、交付物和審查結果是否到位；最後靠 handoff management 把上下文穩穩交出去，必要時還得把子主控的結果回流主線。回頭看就很清楚：Orchestrator 真正管理的是秩序，不是內容產出。

這也是為什麼真實平台一旦成長，Orchestrator 的數量會比想像中還多。以本書分析的系統來看，已經形成跨 7 個以上領域、16 個 orchestrator、145 個以上專門 sub-agent 的協調網路。它已經是一個分層治理平台：有單一入口、有領域主控、有子主控、有審查型工作代理、有實作型工作代理，也有跨域治理代理負責紀錄、handoff、lessons 與 merge signoff。當規模走到這一步，沒有 Orchestrator，不只是效率變差，而是整個系統根本無法穩定運轉。

「am.course.writing-orchestrator 僅負責流程分派、關卡判定、handoff 驗證與使用者確認；不可直接撰寫課程內容。」 — .github/agents/am.course.writing-orchestrator.agent.md

因此，理解 Orchestrator 的第一步，是把它看成系統內部的流程作曲家。它把不同專業能力排進一個有節奏、有證據、有退路的工作流中。只有這樣，你才會明白為什麼一個好的 Orchestrator 必須關心 phase、gate、handoff、備援、治理依賴與最終簽核；也才會明白，真正的強大，來自整個協調系統能不能在複雜條件下仍然保持可預測、可維護、可審核。

認識 Orchestrator 之後，下一步是看整個平台如何分層。真正可擴張的多代理系統，不會把所有 orchestrator 平鋪在同一層，而是採用清楚的上下游結構：上層負責入口與路由，中層負責領域協調，下層負責專業執行，旁邊再配上一條橫切全域的治理帶。這種設計的好處，是能同時兼顧擴展性、責任隔離與跨域一致性。

最上層的閘道層是整座系統的入口閘口。使用者不需要先知道自己該呼叫哪一個領域；它只要描述問題，閘道就應該判斷這是開發需求、課程產製、研究專案還是品質稽核。雖然本地可見檔案中，am.major 主要以歷史與相容規範被提及，但這正好說明閘道的角色：它是入口與轉送，不必深入領域細節。am.dev.orchestrator 文件裡就明白寫著「am.major.agent 保留作為歷史與相容規範文件」，這代表入口概念仍在，只是實務上已把更多主流程往領域主控下放。

第二層是領域主控層，也是整個平台最有辨識度的一層。每個領域至少有一個主控，有些領域甚至會再長出子主控。軟體開發域由 am.dev.orchestrator 統領，文件中可見 P0 到 P11 的長流程，涵蓋需求、分支、規格、邊界、方案、實作、審查、測試、文件與合併。課程域則由 am.course.writing-orchestrator 主導，走的是 C0 到 C6，而且在 C4.5 會切給 am.course.translation-orchestrator 當子主控，再把英、日、韓翻譯與品質稽核收回主線。這正是典型的階層式協調。

「作為 am.course.writing-orchestrator 的子主控，負責翻譯階段分派與結果回流，不可獨立脫離主流程執行。」 — .github/agents/am.course.translation-orchestrator.agent.md

第三層是子代理層。真正的工作都在這裡發生：需求分析師去釐清邊界，architecture designer 提出方案，implementer-front-end、implementer-backend、implementer-data 分別落地，reviewer-logic、reviewer-security、reviewer-performance 負責審查，course 領域則由 slides-writer、lectures-writer、fact-checker、visual-quality-reviewer 等角色分工。也就是說，領域主控不生產內容；它只是把正確的工作，交給具備正確權限與能力的工作代理。

第四層是治理層，它看起來像旁支支援，但其實是所有主流程必須穿越的共用制度。從本地可見檔案來看，治理代理包含 am.governance.session-recorder、am.governance.handoff-manager、am.governance.test-audit、am.governance.project-spec-recorder、am.governance.lessons-recorder、am.governance.merge-signoff 與 am.governance.domain-shared-manager。它們不像領域工作代理那樣聚焦單一業務，而是保障整體平台的可追溯性與一致性：誰做了什麼、何時交接、哪些關卡已過、 lessons 是否沉澱、是否可合併，全都由這一層維持。

把四層放在一起看，你會發現這個系統其實回答了兩個關鍵問題。第一，誰負責判斷？ 由閘道和領域主控判斷。第二，誰負責做事？ 由 Sub-Agent 做事，而治理層則保證做事過程能被審核。這種分工的威力，在規模小時看起來像多此一舉；但當系統擴大到跨 7 個以上領域、十多個 orchestrator、上百個工作代理時，它會從「設計偏好」變成「唯一能維持秩序的方法」。

如果 Orchestrator 只能留下一條規矩，那大概就是 Dispatcher-Only。主控負責 dispatch、sequence、validate、gate 與 handoff，手不要伸進程式碼、內容草稿、分析結論裡。這條線一守住，多代理系統才有辦法被審核、被替換、被測試，也才撐得久。

「主控不直接實作業務程式碼，僅分派與收斂。」
「am.course.writing-orchestrator 僅負責流程分派、關卡判定、handoff 驗證與使用者確認；不可直接撰寫課程內容。」 — .github/agents/am.dev.orchestrator.agent.md ／ .github/agents/am.course.writing-orchestrator.agent.md

理由其實很務實。主控要盯的是流程有沒有走對、順序有沒有錯、上一階段的輸出能不能安全交給下一階段；內容本身怎麼寫，應該留給對應的工作代理。只要 Orchestrator 自己也下場產出，它就同時變成裁判、教練和球員，後面一出事，很難分清楚到底是流程設計有洞，還是內容製作出了錯。Dispatcher-Only 把責任線拉直，每份輸出都能追到具體的 sub-agent。

替換和測試也是同一個道理。reviewer 表現不穩，可以換 reviewer；implementer 速度太慢，可以換 implementer。可是一旦 Orchestrator 自己也做了一半內容，流程邏輯和業務產出就綁死在一起，想替換就會很痛。測試也會跟著失焦，因為 phase 邏輯、handoff 規格和工作代理成果全混成一團，最後只剩一個拆不開的大黑盒。

回到指揮的比喻，這條原則其實很自然。交響樂指揮可以決定小號何時進、弦樂何時收、速度何時拉開、哪一段需要重來，但指揮不會因為長笛今天吹得不夠好，就自己拿起長笛來補。只要指揮下場演奏，整個指揮職責就消失了：沒有人再看總譜、沒有人再維持整體節奏、沒有人再協調其他聲部。軟體裡的 Orchestrator 也是一樣。它若開始親自實作，很快就會失去對整體流程的掌控。

從實務文件來看，這條規則已被寫得非常明確。am.dev.orchestrator 的分派者原則第一條，就是「主控不直接實作業務程式碼，僅分派與收斂」；am.course.writing-orchestrator 直接寫明「不可直接撰寫課程內容」；使用者需求中提到的 am.editorial.full-editing-orchestrator 與 am.paper-writing.orchestrator 也遵守相同紀律：一個負責派工與收斂，不負責親自下場分析或實作。這意味著 Dispatcher-Only 已經成為整個平台共享的架構憲法。

一旦違反 Dispatcher-Only，反模式通常會立刻出現。最常見的是「主控偷做一點」，例如 orchestrator 在等待 sub-agent 回覆時，順手補一段內容、修一個 bug、替 reviewer 下結論。這種做法短期看似省事，長期卻會造成四個後果：輸出責任不清、測試切面破碎、替換成本升高、治理紀錄失真。更糟的是，團隊會逐漸失去對系統的信任，因為沒有人知道哪些結果是誰產生的，也不知道哪一道 gate 其實從未真正被執行。

所以，Dispatcher-Only 的真正價值，不只是讓程式碼看起來比較漂亮，而是讓整個多代理平台保有制度感。只要主控守住邊界，工作代理的品質問題可以被獨立修復，治理規則可以被穩定套用，系統也才可能在不同領域之間複用同一套 orchestrator 思維。這條規則越早建立，後面的 phase-gate、handoff contract、備援 strategy 與 anti-pattern 偵測就越容易落地。

本卷 Part 1 先建立概念、分層與原則。後續 Part 2 會進入 Phase-Gate、handoff、平行通道與子主控等核心設計模式。

當平台開始同時承接開發、課程、編務、研究、簡報等多種任務時，第一個不能含糊的設計，就是入口到底誰說了算。在這套系統裡，am.major 被定義成所有使用者任務的閘道：它的定位很單純：專職的純路由進入點，而非最大的工作代理或萬能主控。使用者只要描述問題，am.major 就負責辨識需求屬於哪個領域，再把任務送進正確的領域主控。這個切面看似前置，實際上決定了後面所有 phase 是否會走在正確軌道上。

「am.major.agent 保留作為歷史與相容規範文件；新專案流程以 am.dev.orchestrator 為主。」
「主控不直接實作業務程式碼，僅分派與收斂。」 — .github/agents/am.dev.orchestrator.agent.md

Gateway 只做分流，不做業務

am.major 的第一個責任，是把「我收到什麼」翻譯成「我該交給誰」。它會先做 task analysis：辨識這是開發需求、課程產製、翻譯延伸、編務修訂、研究任務，還是簡報製作。接著會依規則進入 route confirmation，用 ask_user 明確揭露判斷結果，讓使用者知道這個需求即將被送往哪個 orchestrator。確認後才 dispatch；當各領域完成後，再由閘道做 result convergence，把最終輸出收斂回單一對話入口。這四步驟——分析、確認、派送、收斂——構成了整個平台的入口骨架。

真正重要的是，閘道不可以因為「反正都看懂了」就順手幫忙做一點業務工作。假設使用者說「我要補一門課的日文版，順便把封面配色調整一下」，am.major 最多只能判定這是 am.course 的任務，並看出其中含有翻譯與視覺樣式兩段工作；它不能自己翻譯一段內容，也不能代替 am.course.style-designer 選顏色。只要入口開始偷做事，後續的 handoff、責任追蹤與品質 gate 就會一起失真。

Domain Prefix 就是路由桶

這個平台的命名慣例非常有力量：am.{domain}.{role}。只要看到前綴，就知道任務會落進哪個路由分組。像 am.dev.orchestrator 屬於系統開發域，am.course.writing-orchestrator 與 am.course.translation-orchestrator 屬於課程域，am.editorial.full-editing-orchestrator、am.editorial.proofreading-orchestrator、am.editorial.deep-analysis-writing-orchestrator、am.editorial.proofread、am.editorial.ai-writing-quality 則落在編務域。研究與產製型工作又會導向 am.nstc.writing-orchestrator、am.financial.research、am.presentation.slide-production。這種命名就是路由表本身。

• 開發域：am.dev.orchestrator
• 課程域：am.course.writing-orchestrator、am.course.translation-orchestrator
• 編務域：am.editorial.full-editing-orchestrator、am.editorial.proofreading-orchestrator、am.editorial.deep-analysis-writing-orchestrator、am.editorial.proofread、am.editorial.ai-writing-quality
• 研究與提案域：am.nstc.writing-orchestrator、am.financial.research
• 簡報產製域：am.presentation.slide-production

一旦進入對應領域，該領域就應該是自成一體的。也就是說，每個領域都必須有自己的 orchestrator、自己的 sub-agent 清單、自己的 handoff schema，甚至自己的 phase 命名法。am.dev 用 P0~P11，am.course 用 C0~C6，am.nstc 用 W0~W7；外觀看似不同，實際上都在同一套治理宇宙裡運作。閘道的工作，是明確指出：從這裡開始，責任已經交給某一個完整的專業系統。

跨領域任務則更能看出閘道的價值。例如「把研究結果整理成課程，再做成簡報」本質上就不是單一域問題。這時 am.major 必須把工作拆成可理解的序列：先交給研究域產出可信內容，再送往課程域做教材化整理，最後由簡報產製域完成視覺交付。某些情況下也可以平行化，例如編務校對與視覺素材準備可同步進行，但前提永遠是 route transparency：使用者知道目前在哪個領域、下一步會交給誰、為什麼這樣排。

多代理平台最常見的失敗，往往來自流程太容易跳關。需求還沒收斂就開始實作、handoff 還沒驗證就往下送、審查只跑一半就宣布完成，這些都會讓整條鏈條變得不可預測。Phase-Gate 設計模式的核心，就是把工作拆成有編號的階段，並在每一段尾端放上一道 gate。Phase 決定順序，gate 決定可不可以前進；兩者缺一不可。

「任一子流程失敗時，不可跳關，必須重試、降級或 ask_user 決策。」
「若上一關 handoff 缺漏或驗證失敗，不可進入下一關。」 — .github/agents/am.dev.orchestrator.agent.md ／ .github/agents/am.course.writing-orchestrator.agent.md

Phase 是時間軸，Gate 是制度軸

幾乎所有成熟 orchestrator 都會把工作切成可命名的 phase。am.dev.orchestrator 從 P0 對話追蹤啟用、P1 需求、P2 分支、P3 規格基線、P4 澄清、P4.5 邊界 gate、P5 架構、P6 實作、P7 審查、P8 測試治理、P9 文件、P10 lessons，一直到 P11 合併；am.course.writing-orchestrator 則用 C0 需求確認、C1 大綱、C2 素材對齊、C3 投影片、C4 講義、C4.2 正確性預審、C4.4 冗餘審查、C4.5 翻譯子主控、C5 視覺 QA、C6 最終簽核。am.nstc.writing-orchestrator 又有 W0 profile、W1 outline、W2 literature、W3 drafting、W4 stats、W5 AI detection、W6 領域 review、W7 DOCX output。命名不同，但模式完全一致。

為什麼一定要強調「嚴格順序」？因為很多工作不是可以任意重排的。以開發域來說，P4.5 邊界 gate 沒過，代表根因證據或功能邊界都還不完整；這時若直接進 P6，實作代理就只能憑感覺修改。以課程域來說，C4.2 的術語、事實與一致性預審沒過，後面的翻譯與視覺風格做得再漂亮，也只是把錯誤包裝得更完整。Phase-Gate 的本質，就是把「先做什麼、後做什麼」從經驗法則提升為制度。

Half-Phase 是避免重編號的工程智慧

真實系統不可能一開始就把所有 gate 想完，因此成熟平台往往引入半關卡，例如 P4.5、C4.2、C4.4、C5.5。這些編號看起來細碎，實際上非常實用：你可以在不破壞整條編號語意的情況下，插入一個額外驗證點。像 am.dev.orchestrator 的 P4.5 專門處理 bug 根因與 feature 邊界；am.course.writing-orchestrator 的 C4.2 與 C4.4 則分別處理正確性預審與全章節冗餘。半關卡是對流程演化的正規回應。

Hard Gate 與 Soft Gate

並非所有 gate 的嚴格程度都一樣。Hard gate 需要明確驗證條件，例如 test pass、令牌存在、品質分數達門檻值、無 BLOCKER；條件沒達成就必須阻擋。像 P4.5 需要 [BUG-ROOT-CAUSE-CONFIRMED] 或 [FEATURE-BOUNDARY-LOCKED]，P8 需要 [TEST-VERDICT] PASS，C5.6 則要求上傳前 Playwright 視覺檢查通過。Soft gate 則通常只要求前一步完成並留下可追溯紀錄，例如大綱已產出、素材盤點已完成、某份整理報告已回寫。兩種 gate 共同存在，讓系統既能嚴格，又不至於每一步都過度繁重。

如果把不同領域的 phase 並排比較，會更清楚看出這其實是一種共通架構語言。開發域與課程域雖然產物完全不同，一個產生 code、review、test report，另一個產生 slides、lectures、translation、visual QA；但兩者都用「需求 → 規劃 → 產出 → 審查 → 驗證 → 簽核」的骨架來保證品質。也就是說，Phase-Gate 已經成為整個平台共享的節奏控制器。

Phase-Gate 讓系統知道何時該停、何時能走；handoff contract 則讓系統知道「到底交了什麼」。沒有 handoff 的多代理流程，看起來像是在協作，實際上只是把上下文碎片丟來丟去。真正可稽核的平台，會把每一次 phase transition 都寫成具體的 JSON 契約，放進 specs/{feature-id}/handoff/，讓下游代理不需要猜，也不被允許猜。

「每個 phase 建立 step-<nn>-<phase>.json，記錄 sub-agent 名稱、實際使用 model ID、令牌用量、輸入來源、產出檔案、狀態與摘要。」
「若 handoff 缺漏或格式錯誤，禁止流程前進並回報缺失項。」 — .github/agents/am.governance.handoff-manager.agent.md

Handoff 是契約，不是備忘錄

很多團隊一開始會把交接理解成「留一句話給下一位代理」，例如寫個摘要、貼一段 log、或在對話裡口頭說明。但在 orchestrated system 裡，這些都不夠。契約的意思是：欄位固定、格式可驗證、缺一不可。以本系統的實務規範來看，handoff 至少必須清楚描述 phase 身分、執行結果、時間、模型與摘要；在本書歸納的通用欄位裡，可用 phase_id、status（pass / fail / blocked）、gate_token、created_at、model、summary 來表達最小必備資訊。若再加上輸入來源、輸出檔案與令牌用量，就能讓每一步都具備機器可讀與人類可審的雙重價值。

這裡最關鍵的設計，在於接收端必須先驗證再工作。也就是說，下一個 agent 啟動前，不能只看檔案存在就算了，而要確認欄位完整、狀態可接受、必要交付物已出現、gate token 合法。若驗證失敗，流程就應該立刻停住，絕對不能抱著「大概沒問題」往下跑。因為 handoff 一旦失真，後面每一個 phase 都只是在建立更大規模的錯誤。

回流（Return Flow）讓子主控可逆

handoff 的另一個高階用途，是支撐子主控的切換與回流。課程域是最典型的例子：am.course.writing-orchestrator 在 C4.5 不直接自己做英日韓翻譯，而是先寫入 step-06-transfer-to-translation.json，把 zh-TW 主版本交給 am.course.translation-orchestrator。翻譯子主控收到 handoff 後，平行分派 T1 英文、T2 日文、T3 韓文，再做 T4 品質稽核，最後透過 step-06r-return-to-writing.json 把控制權交回寫作主控。這條回流鏈的重要性，在於它把「切出去」與「接回來」都制度化，不需要靠人工記憶。

「啟動前必須先讀取 specs/<feature-id>/handoff/step-06-transfer-to-translation.json。」
「回寫 step-06-translation-orchestration.json 與 step-06r-return-to-writing.json，交還 am.course.writing-orchestrator 繼續後續 phase。」 — .github/agents/am.course.translation-orchestrator.agent.md

當 handoff 契約成熟之後，它就成了整個平台的稽核軌跡。你可以回頭回答很多原本很難追的問題：是哪個 agent 在哪個 phase 產出了這份檔案？當時使用哪個模型？有沒有拿到必要令牌？是正常通過、失敗，還是因為 blocked 而中止？這些資訊一旦落盤，就能支援 lesson 回顧、錯誤定位、流程優化，甚至模型選型與成本分析。換句話說，handoff 是治理的主幹資料。

當任務規模夠大時，完全序列化的流程雖然安全，卻會拖垮吞吐量。於是多代理平台自然會引入平行通道：把彼此相對獨立的工作，同時交給不同代理處理。可是平行化不是「多開幾個視窗」那麼簡單，它真正考驗的是收斂能力。只要沒有收斂規則、沒有衝突決策、沒有寫入所有權，平行通道很快就會從加速器變成事故來源。

「若主控觸發平行 sub-agent 執行，必須等待所有平行 sub-agent 全數完成並回覆結果後，主控才可進入下一關卡。」
「平行 sub-agent 必須先分配 write-scope；未分配不得執行。」 — .github/agents/am.dev.orchestrator.agent.md

哪些工作適合平行化？

適合平行的任務通常有兩個條件：第一，產出彼此相對獨立；第二，前置輸入已經足夠穩定。開發域最典型的例子，是 am.dev.orchestrator 的 P7 審查階段：am.dev.reviewer-logic、am.dev.reviewer-security、am.dev.reviewer-performance 可以同時檢查同一批變更，但它們看的切面不同。等三者收斂後，主控再進入 P7.5 規格一致性、P7.6 跨平台、P7.9 機密合規等更高層的序列收斂。課程域則在 C4.5 交給 am.course.translation-orchestrator，由 T1、T2、T3 同步產生英、日、韓版本，再於 T4 做品質稽核，最後回流主線。

其他領域也有類似節奏。像 am.qr.orchestrator 會根據設定限制，最多同時啟動 2 個 inspectors 做平行檢查；am.editorial.full-editing-orchestrator 在某些情況下，也能把不同書稿章節分配給不同工作代理先各自修訂。你會發現，平行通道的目的，是在不打破制度的前提下，把可獨立工作的片段同時推進。

Fan-in 的本質是「等待全部」，不是「先到先贏」

平行化最危險的誤解，就是只要先收到幾條通道的成功結果，就急著往下跑。真正的收斂恰恰相反：主控必須等待所有平行通道都結束，才能開始下一個 gate。因為下一關要驗證的是整體狀態，而不是局部樂觀。以 P7 為例，只收到 logic 與 performance 的 PASS，卻還沒看到 security 的裁定，就不能宣稱審查完成；同理，翻譯子主控也不能只因為英文與日文完成，就先把課程交回主流程，韓文與品質稽核都必須一起到位。

衝突解決與寫入鎖

平行通道另一個核心議題，是結果矛盾時誰說了算。假設 reviewer-security 要求關閉某個開口，而 reviewer-performance 建議打開同一個快取策略；或不同語系翻譯對同一專有名詞給出相互衝突的慣例。這時 orchestrator 不能假裝沒看到，而要啟動 resolution policy：先標記衝突點，再決定是回退某一通道、交由一致性審查關卡仲裁，或要求補充證據後重跑。換句話說，平行不代表去中心，而是先分工、再集中決策。

• Lock ownership：平行代理不能同時寫入同一組檔案，必須事先分配 write-scope。
• Conflict policy：結果互斥時，主控要有明確的仲裁或重跑規則。
• Fan-in gate：全部 lanes 完成後，統一驗證是否可進下一個 phase。
• Sequential follow-up：fan-in 後常會接更高階的總檢查，例如一致性、跨平台或機密合規。

因此，平行通道真正帶來的，不只是「更快」，還讓系統在不失控的前提下提高吞吐量。它要求 orchestrator 更嚴格地定義所有權、更誠實地面對分歧、更耐心地等全部結果收齊。沒有這些配套，所謂的平行只會把 race condition、結果覆蓋與責任不清一次放大。

當一個領域內部已經複雜到需要自己的 phase、自己的 handoff、自己的品質關卡時，單一主控往往會太重。這時系統有兩種常見做法：第一種是把某一段工作委派給子主控，等它跑完整條子流程再回來；第二種是從一個抽象 orchestrator 模板繼承下來，保留共用骨架，覆寫其中幾個 extension points。前者解的是分工，後者解的是重用；兩者共同構成階層式編排的核心。

「作為 am.course.writing-orchestrator 的子主控，負責翻譯階段分派與結果回流，不可獨立脫離主流程執行。」
「am.course.translation-orchestrator 為本主控的 sub-agent，不可獨立跳流程執行。」 — .github/agents/am.course.translation-orchestrator.agent.md ／ .github/agents/am.course.writing-orchestrator.agent.md

Delegation：父主控暫停，子主控接手一段完整生命週期

最清楚的 delegation 範例，就是課程域在 C4.5 的翻譯切換。am.course.writing-orchestrator 先完成需求、大綱、素材、投影片、講義與前置審查，接著把多語翻譯視為一個「邊界清楚、可獨立治理、可回流」的子問題，交給 am.course.translation-orchestrator。子主控收到 step-06-transfer-to-translation.json 後，以 T1、T2、T3 平行處理英日韓翻譯，再經 T4 品質稽核與 T5 回流交接，把結果送回父主控。父主控並沒有失去控制權，它只是暫時把某一段生命週期委派給更專精的流程控制者。

這種設計的好處，在於子任務擁有自己的節奏與關卡。例如翻譯不只是一個工作代理動作，而是一整個小型管線：多語平行、品質稽核、頁數一致性、return handoff。若硬要把這些細節全部塞回寫作主控，父主控會變得過於臃腫，phase 也會失去可讀性。因此，只要某段子流程已經形成獨立生命周期，delegation 往往就是比「再加幾個子步驟」更乾淨的選擇。

Inheritance：共享骨架，覆寫核心方法

另一條路是範本繼承。研究域常見的做法，是由 am.research.orchestrator 定義抽象 P0~P10 骨架，把研究倫理、統計驗證、文件化與最終輸出等共通步驟收斂在基底模板，再把 P4~P7 標成 MUST OVERRIDE 的 extension points。如此一來，am.paper-writing.orchestrator 可以在中段換成學術寫作脈絡，am.trading-research.orchestrator 則換成交易研究與市場驗證邏輯，但兩者仍共享前後段的治理紀律。這就是「子類承接同一套制度骨架，而非複製一份流程」的意思。

委派與繼承雖然都會形成階層，但目的並不相同。Delegation 是 parent calls child：父主控在某一個 phase 把工作交出去，子主控跑完後回來；Inheritance 則是 child is-a base orchestrator：子主控本身就是研究主控的特化版本，並在共享骨架上覆寫局部 phase。前者強調生命周期切換，後者強調流程模板重用。這兩種模式若分不清，架構很容易失焦：該拆子主控的地方硬塞成超長 phase，該用模板共用的地方卻複製出一堆近似流程。

何時該 delegate，何時該 inherit？

• 適合 delegation：子任務邊界明確、可獨立重用、有自己的 gate 與回流需求，例如課程翻譯、特定編務子流程。
• 適合 inheritance：多個子領域共享大部分骨架，只需覆寫中段方法論，例如 paper-writing 與 trading-research 共用 research 基底。
• 不該用 delegation 的情況：若子任務其實只是單一步驟，沒有獨立生命周期，硬拆只會增加 handoff 負擔。
• 不該用 inheritance 的情況：若實際共享不到一半流程，硬繼承只會產生脆弱的假抽象。

階層編排的終極目標，是讓每一層都保持可理解。父主控知道自己只管大節奏，子主控知道自己只處理被授權的一段生命周期，模板基底則只保留真正跨案例都成立的共通骨架。當這三件事同時成立，多代理平台就能在擴張時保持秩序，而不是因為新增領域而讓主流程愈來愈難讀、愈來愈難維護。

當平台從單一流程長成多領域生態時，最容易被低估的一層，就是治理層。很多人以為 am.governance.* 只是附加審查者，實際上它更像整個系統的共同憲法：不直接寫程式、不直接寫課程、不直接修稿，卻負責規定所有領域都必須遵守的 handoff 欄位、測試門檻、簽核方式、可追溯紀錄與風險防線。也正因為這一層存在，am.dev、am.course、am.editorial、am.research、am.nstc 雖然 phase 命名不同，仍能在同一套治理語言下被驗證、被追蹤、也被恢復。

「提供所有 am.<domain>.* 可共用的治理規範來源，避免各領域重複維護同一套治理邏輯。」
「確保對話過程被持續記錄到 flow DB，讓 localhost:8765 能看到最新 session 分析。」 — .github/agents/am.governance.domain-shared-manager.agent.md ／ .github/agents/am.governance.session-recorder.agent.md

治理是橫切全域的制度層

治理代理最重要的洞見，是它們不屬於任何單一領域。am.governance.domain-shared-manager 定義的是全部領域共同採用的 handoff 契約、品質最低門檻、工具指引與模型基準；它不是開發域的附屬品，也不是課程域的秘書。像 handoff JSON 必備的 sub_agent、model_id、token_usage、status、started_at、completed_at 等欄位，就是從治理層往下壓的共同格式。文件甚至直接指定治理基準模型為 claude-opus-4.6，這代表治理先定框架，再讓各領域在框架內做最佳化，而不是每個主控各玩各的。

am.governance.session-recorder 的角色也很能說明這種橫切性。它不關心你現在做的是 bug 修正、課程翻譯還是研究寫作；它關心的是這個 session 有沒有被記錄、關鍵節點有沒有事件、ask_user 決策有沒有保留下來，以及 localhost:8765 的視覺化頁面能不能看到最新脈絡。換句話說，治理層處理的是「流程是否可被信任」，而不是「內容是否好看」或「演算法是否聰明」。

真正的力量，來自被各個主控反覆呼叫

治理代理之所以重要，關鍵在於每個領域主控都會在特定 phase 呼叫它們。以 am.dev.orchestrator 為例，P0 會叫 am.governance.session-recorder 建立追蹤起點，P2 以 am.governance.handoff-manager 建交接基線，P3 可由 am.governance.project-spec-recorder 作為備援，P8 由 am.governance.test-audit 做測試治理，P10 交給 am.governance.lessons-recorder，P11 再由 am.governance.merge-signoff 收最後一關。課程域也相同：am.course.writing-orchestrator 在 C5.7 呼叫 am.governance.project-spec-recorder，C5.8 呼叫 am.governance.lessons-recorder，C6 則把最終簽核交給 am.course.final-signoff，並以治理規範作為後盾。

因此，治理層不能被理解成「第八個領域」。它更像垂直骨架一樣穿過所有 orchestrator，而非和開發域、課程域並列競爭。沒有這層，領域仍然可以各自跑，但跑久了就會出現欄位不一致、測試標準不一致、簽核標準不一致、錯誤經驗沒沉澱、流程中斷後無法恢復等問題。治理層的真正功能，是讓多代理系統在規模變大之後，仍保持同一種制度感。

Phase-Gate 真正難的地方，在於要求每一個 phase 都留下可驗證的收據。這個收據在本系統裡通常叫做 gate token：它就是下一個 phase 啟動前必須先驗證的完成證明。沒有令牌，就代表上一關尚未完成；只有口頭說「應該差不多」在這套制度裡完全不算數。

「若 handoff 缺漏或格式錯誤，禁止流程前進並回報缺失項。」
「Gate 未通過前，禁止進入 P5/P6，亦不得要求 implementer 開始任何程式碼修改。」 — .github/agents/am.governance.handoff-manager.agent.md ／ .github/agents/am.dev.orchestrator.agent.md

Gate token 是 phase 的收據，不是裝飾性的標籤

在治理規範中，令牌會被嵌進 handoff JSON。am.governance.handoff-manager 要求每個 phase 都寫入 step-<nn>-<phase>.json，而 am.governance.domain-shared-manager 又要求這些檔案至少具備 sub_agent、model_id、token_usage、status、started_at、completed_at 等欄位。也就是說，下一關不會只看「有沒有一個 PASS 字樣」，而會同時看令牌、交付物、時間戳、模型資訊與產出檔案是否完整。治理的重點從來都在驗證代理，而非直接相信代理。

以開發域為例，P4.5 的令牌是 [BUG-ROOT-CAUSE-CONFIRMED] 或 [FEATURE-BOUNDARY-LOCKED]；P7 的 reviewer 全數通過後，才能回收 [REVIEWER-VERDICT] PASS；P7.9 機密合規要看到 [SECRET-COMPLIANCE-PASSED]；P8 測試治理則必須拿到 [TEST-VERDICT] PASS 以及測試矩陣、覆蓋率結果與測試報告。這些令牌之所以有價值，是因為它們都對應到具體交付物，而不是一句抽象的「我完成了」。

Hard gate 看證據，Soft gate 看完成狀態

Hard gate 的特徵，是有明確驗證標準，而且不達標就絕對阻擋。本平台最典型的 hard gate 包括：

1. am.dev P4.5：沒有根因證據或邊界契約，就不得開始改程式。
2. am.dev P8：所有測試未通過之前，不得宣稱完成，也不得進入後續文件同步與合併。
3. am.paper-writing R6：事實查核分數必須過門檻，否則研究稿不能往後送。
4. am.paper-writing R8：統計驗證必須同時檢附信賴區間（CI）與 p 值，不接受只挑有利指標。
5. am.research P6 / P8：統計關卡屬硬阻擋，嚴禁 p-hacking，資料分析必須可回溯。
6. am.editorial：AI 偵測分數必須低於門檻值；多數內容型稿件以 < 30 為標準，fanpost 更嚴格採 < 20。
7. am.nstc W5：提案類 AI 風險需低於 30，論文類需低於 25，否則不得進最終提交。

Soft gate 則較像流程節點的完成確認。例如大綱已落檔、素材盤點已回寫、翻譯子主控已完成 return handoff、規格基線已建立。Soft gate 仍然要留記錄，但通常不要求分數、覆蓋率或統計顯著性，只要求上一關狀態完整、檔案存在、欄位齊全。換句話說，hard gate 解決「能不能放行」，soft gate 解決「流程有沒有走對」。

產物驗證比 token 更不容易作假

真正成熟的系統，不會只檢查令牌字串，還會檢查令牌背後的交付物是否存在而且內容合理。像 [TEST-VERDICT] PASS 背後必須有測試矩陣與報告；[MERGE-COMPLETE] 背後必須有 merge hash 與驗證摘要；轉交翻譯子主控時，還要同時看到 step-06-transfer-to-translation.json 與 step-06r-return-to-writing.json。這也是為什麼治理系統偏好 JSON handoff：因為它既能被人閱讀，也能被工具驗證。

若 gate 驗證失敗，流程會先退回產出該令牌的代理修正。一般策略是第一次失敗先補件、第二次失敗再明確重跑、第三次仍失敗則升級到 ask_user。某些關卡還設有備援驗證器，例如 am.dev.boundary-backup-validator 可以在 P4.5 主責代理失敗後，以保守策略重新產出 gate token；但若連備援都無法建立可信證據，就必須誠實停下，不可硬闖下一關。

成熟的 orchestrator 不會假設一切都會順利，它從一開始就把失敗當成設計物件。代理可能輸出不完整、gate 可能驗證失敗、前置條件可能缺漏、不同 reviewer 可能互相衝突，甚至同一個問題可能重跑三次仍然無法收斂。可靠性的關鍵，在於預先定義：失敗時回哪裡、誰來補位、什麼時候該停、什麼時候一定要把決策交還給人。

「任一子流程失敗時，不可跳關，必須重試、降級或 ask_user 決策。」
「若無法在合理探索後找到根因證據或鎖定邊界，必須輸出 [BOUNDARY-BACKUP-ESCALATED]，不得虛構根因。」 — .github/agents/am.dev.orchestrator.agent.md ／ .github/agents/am.dev.boundary-backup-validator.agent.md

先重試，但絕不允許無限重跑

重試是必要的，但無限重試只會把失敗包裝成忙碌。這套系統的慣例，是先讓 producing agent 針對失敗原因做明確修正；如果相同問題持續出現，就把每次迭代當成可記錄的 loop。像 am.dev.test-fixer 就直接寫明：同一失敗案例最多自動修補 3 次，第 3 次仍失敗必須升級。這種上限很重要，因為它強迫 orchestrator 承認「自動化已經到極限」，而不是讓代理在錯誤路徑上空轉一整晚。

因此，失敗回圈的標準節奏通常是：第一次失敗先補件並重跑；第二次失敗要求更清楚的輸入、證據或界線；第三次失敗仍不收斂，就不得再假裝可以靠運氣過關，而是必須升級。升級的對象通常有兩個：如果有備援代理，就先啟動備援；如果沒有，或備援也失敗，就由 orchestrator 彙整脈絡後交由 ask_user 決策。

備援代理的本質，是保守降級而不是偷偷改規則

am.dev.boundary-backup-validator 是非常典型的備援設計。它不是主責代理的平行競爭者；只有在主責失敗或阻塞後才被允許啟動。而且它的策略不是更激進，反而更保守：邊界必須從寬定義，根因至少要有一條 file:line 證據，不能證明就輸出 [BOUNDARY-BACKUP-ESCALATED] 並誠實停下。這種設計很關鍵，因為備援的目的，是在資訊不足時提供一條風險較低的保底路徑。

1. 代理輸出無效：回到原代理，附上缺漏欄位與澄清後的 prompt，重新產出。
2. Gate 驗證失敗：退回 producing agent 補 artifact、補 token 或補證據，禁止直接往下跳。
3. 重複失敗達 3 次：啟動備援代理；若無備援或備援也失敗，交由 ask_user 決策。
4. 前置條件缺漏：立即停管線，例如缺 handoff、缺規格基線、缺測試環境時不得假裝可繼續。
5. 跨代理衝突：由 orchestrator 依 resolution policy 收斂；若 reviewer 與 implementer 無法收斂，主控必須回送修正，不可自己下場代修。

有些領域甚至把回退做得更像版本控制。以編務 proofread 管線為例，當 P2 的修正驗證失敗時，最合理的處理往往是要求產生一個新的更正版，重新進入驗證流程。這種「版本式回退」的觀念很值得學：錯了就回到上一個可驗證狀態，而不是在不可信版本上越補越亂。

要讓這一切可以恢復，還需要狀態檔。這就是 pipeline-tracking.json 的價值：目前在哪一個 phase、遇過哪些失敗、重試幾次、最後一次成功在哪裡，全都必須落盤。這樣一來，不論是 session 中斷、context 壓縮，還是人類隔天回來接手，都可以從同一個追蹤檔接續，而不必靠記憶猜測「昨天大概做到哪」。

多代理系統一旦進入實戰，很快就會發現：不是所有工作都值得用同一個模型做。需求判讀、UI 風格設計、程式碼修補、事實查核、統計驗證、最終簽核，所需要的推理深度與輸出形式完全不同。模型治理的任務，就是把「哪一類工作該用哪一類模型」制度化，並把選型理由與使用紀錄寫進 handoff，讓品質、成本與責任三者都能被回頭稽核。

「@model:claude-opus-4.6」
「一般策略與關鍵決策：claude-opus-4.6；UI/UX 規劃與畫面實作：優先 Claude Opus 4.7；程式碼落地與修補：gpt-5.3-codex。」 — .github/agents/am.governance.domain-shared-manager.agent.md ／ .github/agents/am.dev.orchestrator.agent.md

模型分派的重點在任務適配

從可見 agent 規格來看，治理層把 claude-opus-4.6 設成預設模型，代表它適合處理高層政策、共用規範與關鍵決策；開發域則進一步拆分：策略與架構用 claude-opus-4.6，UI/UX 與畫面設計偏向 claude-opus-4.7，真正的程式碼落地交給 gpt-5.3-codex。課程域也有類似分流：am.course.outline-planner、am.course.fact-checker、am.course.translation-orchestrator 多採 claude-opus-4.6；am.course.slides-writer、am.course.material-manager、am.course.playwright-visual-checker 則使用 gpt-5.3-codex-high。這顯示成熟系統不迷信單一最強模型，而是根據任務型態做分配。

跨到其他領域，模型治理只會更精細。像編務域的 am.editorial.deep-analysis-writing-orchestrator 可以偏向在 director／writing 步驟使用 claude-opus-4.7，而一般編修或治理步驟維持 claude-opus-4.6；am.editorial.full-editing-orchestrator 則可以把 editorial 類步驟交給 claude-opus-4.6，把事實密度更高的步驟交給 gpt-5.3-codex。研究與提案域更可能在高風險決策採多模型平行，例如 am.nstc W2.5 文獻回顧以三個頂級模型同時比對，再採多數決。這些做法背後的邏輯都一樣：模型扮演的是職務配置，而非身分象徵。

四條模型治理原則

1. 任務適配：簡單路由與格式化工作可以用快模型；創作、架構、策略用高階模型；程式導向或事實密集工作則優先 code 型模型。
2. 三模型驗證：對高風險判斷，不追求單一模型神諭，而是追求交叉驗證。am.dev.bug-rootcause-boundary 就明定第二輪根因探索須由三個不同 provider 的頂級模型獨立判讀，再用 2/3 多數決收斂。
3. 模型落盤：每份 handoff 都要記錄 model_id 與 token_usage，這讓成本估算、品質追溯與異常分析有依據。
4. 升級要有理由：某一 phase 若要從預設模型跳到更昂貴模型，必須留下可檢查的理由，不能只是因為「感覺比較強」。

權責隔離讓除錯變得無罪且精準

模型治理若沒有配合責任隔離，最後只會變成一張華麗採購清單。真正重要的是：每個 sub-agent 對自己的輸出負責，orchestrator 只負責協調與驗證，不代寫、不代修、不代判。這正是 Dispatcher-Only 在治理層的延伸。如果 reviewer 不同意 implementer，主控要做的是把意見退回 implementer，不是自己動手偷偷改。如此一來，每份輸出都能追到是誰做的、用了哪個模型、經過哪些 gate、在什麼 handoff 被接走；出問題時是找流程、找模型、找角色，不是找戰犯。

這種所有權鏈還有一個常被忽略的好處：它讓除錯可以「無責備」。當我們看到某個 gate 失敗，不必先陷入情緒，只要回到 handoff JSON 看 sub_agent、model_id、交付物與時間戳，就能知道問題是在模型選型、prompt 約束、角色邊界，還是下游驗證規則。責任隔離因此是為了讓系統能精準修補。

am.dev.orchestrator 是整個平台裡最完整、也最具治理色彩的開發主控。它會把需求分析、規格基線、邊界鎖定、架構設計、實作、審查、測試、文件與合併簽核全部拆成 P0 到 P11 的序列化管線。這種設計的目的很清楚：在任何一行程式碼被修改前，先確認需求是否明確、變更邊界是否有證據、風險是否可回滾，避免團隊落入「先改再說」的高成本循環。

「主控不直接實作業務程式碼，僅分派與收斂。任一程式碼修改前，必須先定義變更邊界；Bug 修正不得猜測原因，必須先完成程式碼探索與根因證據。」 — am.dev.orchestrator 的 Dispatcher 原則與 P4.5 Hard Gate 規範

整條管線之所以能被稱為「開發作業系統」，關鍵在於兩端都由治理代理包住。P0 先呼叫 am.governance.session-recorder 啟用對話追蹤，把 flow 事件與決策點落盤；P11 再由 am.governance.merge-signoff 做最終簽核與 ask_user 確認。中間則依序經過 am.dev.requirement-analyst、am.dev.branch-manager、am.dev.spec-baseline-architect、條件式的 am.dev.style-designer、am.dev.clarification-checker、P4.5 邊界關卡、am.dev.architecture-designer、三路 implementer、四路 reviewer、am.governance.test-audit、am.dev.docs-syncer 與 am.governance.lessons-recorder。實務文件常以「23 個核心子代理」概括這套直接協作網路；若把備援與 speckit 類支援節點一併納入，可路由節點還會再往上增加，這也說明它是目前最龐大的主控配置。

完整 12 階段：每一關都先回答一個風險問題

這套流程最關鍵的設計，在於每一關都對應一種真實風險。P1 解決「做錯題」；P3 解決「破壞既有基線」；P4 解決「規格含糊」；P4.5 解決「根因不明或邊界擴散」；P5 解決「沒有回滾方案就直接下手」；P7 解決「只有實作者自我感覺良好」；P8 解決「沒有測試就宣稱完成」。你會發現，這是一連串很務實的事故預防機制。

P4.5 是整條管線的真正閘門

在所有 phase 中，P4.5 最能代表 am.dev.orchestrator 的紀律。若是 bugfix，主控必須收到 [BUG-ROOT-CAUSE-CONFIRMED]，其中要包含 file:line、重現條件與呼叫鏈；若無法重現，至少要輸出 [BUG-REPRO-BLOCKED]，並附上重現嘗試矩陣與觀測缺口。若是 feature，則一定要拿到 [FEATURE-BOUNDARY-LOCKED]，寫清楚 in-scope、out-of-scope、no-touch、impact matrix 與非回歸保護。更嚴格的是，當 bug 流程出現 BLOCKED-CANDIDATE 時，主控不能接受一句「查不到」，而是必須再啟動三個不同 Provider 的頂級模型做二次根因探索，採 2/3 多數決；若仍無共識，就輸出 [BUG-ROOT-CAUSE-TIE] 並升級決策。這些規定的核心精神只有一句：證據先於修改。

為了避免流程在 P4.5 卡死，系統還安排了 am.dev.boundary-backup-validator 當保守備援。它不追求完整重做，而是在主責代理失敗、缺欄位、或輸出與 gate 不一致時，以縮小分析面的方法重新驗證；若連備援都無法產出令牌，才回報 [BOUNDARY-BACKUP-ESCALATED]。這樣的備援策略很值得學：備援在主角失手時，扮演幫系統保留最小可前進資訊的安全網。

四路平行審查，讓問題在進測試前就被攔下

P7 的扇出是另一個經典設計。am.dev.reviewer-logic 看流程正確性與需求對齊，am.dev.reviewer-security 看漏洞與敏感資料風險，am.dev.reviewer-performance 看瓶頸與可擴展性，am.dev.reviewer-crossplatform 則在 P7.6 專責 Linux、macOS、Windows 三平台可攜性。這明確承認「不同風險需要不同眼睛」，而不是把同一份審查拆成四個人做。P7.5 的一致性關卡與 P7.9 的機密合規又補上文件一致性與機密掃描，形成從程式邏輯到營運風險的完整封鎖線。只有當這些裁定都通過，P8 的測試治理才有意義，因為你送進測試的已經不是未經審查的粗胚。

am.course.writing-orchestrator 展現的是另一種與開發不同、但同樣嚴密的 orchestration 哲學。開發流程重視 root cause 與 rollback；課程流程則重視受眾適配、教材可追溯、語言一致性與視覺可讀性。從 C0 到 C6.5，它把課程從需求、章節、素材、投影片、講義、翻譯、視覺檢核一路推到最終交付，而且每一步都必須維持「繁中主版本」作為唯一事實來源。

「全流程使用台灣正體中文，禁止大陸用語。英／日／韓譯文必須是語義翻譯，不可使用字串 replace 式機械替換產生。」 — am.course.writing-orchestrator 與 am.course.translation-orchestrator 的核心規範

這條管線的第一個特色，是它把「內容生產」與「內容驗證」分成兩股力量。C0 由 am.course.requirement-analyst 定義主題、受眾、時長與驗收標準；C1 交給 am.course.outline-planner 做章節與頁數配置；C2 再由 am.course.material-manager 把 source-materials 盤點成可追溯素材清單。到了 C3 與 C4，才分別由 am.course.slides-writer 產生 slidesData_{topic}.js、由 am.course.lectures-writer 產生 lecturesData_{topic}.js。這樣安排的目的，是把「教學結構」先鎖住，再進入內容落地；否則投影片與講義很容易一開始就失去對齊。

主流程 C0–C6.5：把教材產製拆成可驗證的交付鏈

這裡最值得注意的，是 C4.2、C4.4、C5 與 C5.6 形成一條很有層次的品質鍊。先做台灣正體中文術語檢查，避免陸式詞與非台灣慣用術語混入；再做法規與資料查核，把 FACT_ERROR 修掉、UNVERIFIED 標示清楚；接著由一致性稽核確認 slidesData 與 lecturesData 長度相同、divId / canvasId 唯一；最後再用冗餘審查與視覺審查處理內容重複與版面可讀性。也就是說，課程域先追求「學員看到的版本穩定且可信」，而不是急著把內容寫快。

T1–T5：翻譯不只是語言切換，而是子主控治理

am.course.translation-orchestrator 是本書非常適合拿來教學的子主控範例。它本身不負責翻譯任何一種語言，而是先讀取 specs/<feature-id>/handoff/step-06-transfer-to-translation.json，確認來源是 zh-TW 主版本，然後平行分派 am.course.translate-en、am.course.translate-ja、am.course.translate-ko 執行 T1、T2、T3。三條通道全部完成後，才交給 am.course.translation-quality-auditor 執行 T4，檢查是否為語義翻譯、是否頁數與來源一致、是否有 replace 式機械痕跡；最後再以 T5 回寫 step-06-translation-orchestration.json 與 step-06r-return-to-writing.json，交還寫課程主流程。

這樣做的好處有三個。第一，沒有平行寫入衝突：英、日、韓各自輸出到獨立檔案，不互相覆蓋。第二，頁數一致性可以被制度化：翻譯階段保留同一頁面結構，而不是重寫教材，讓多語版本在 viewer 與 handout 介面都能對位。第三，語義品質可以集中治理：翻譯代理只負責產出，是否「像人寫的」交給專責稽核判斷。這就是子主控的價值：把複雜度隔離在邊界內，再把已驗證的結果回流主線。

課程域還有一個很實務的設計：本機 Playwright 視覺檢查被放在上傳前的必要 gate。很多人以為課程內容只要文字對、圖表對就好，但實際交付時，重疊、截斷、對比不足、封面比例錯位往往才是最常見的事故。am.course.playwright-visual-checker 因此是部署前的阻擋關卡，不只是「美觀加分項」。這也解釋了為什麼 style designer 要放在 C4.6，而不是一開始就決定：先把知識本體穩住，再去追求畫面一致，是比較低風險的順序。

編務領域最值得研究的地方，在於它清楚證明：同一個母題也不該被一條超大管線硬做到底。am.editorial 已依不同階段與產物型態拆成四套：全編修、後編校、版後 PDF 校對，以及原創深度分析寫作。這種切法非常成熟，因為它承認「編修」在不同情境下，其實是完全不同的工作。

「不是所有編務問題都應該丟給同一條大流程；正確做法是依輸入型態、編務階段與輸出責任切成專用 orchestrator。」 — 編務域 orchestrator 群的共同設計原則

第一條是 am.editorial.full-editing-orchestrator，也是最完整的一條。它超過 430 行，從 T0.5 的 book profile setup 開始，接著做 T0 環境與語言轉換、T0.8 來源語言清理、T1 文本切段、T2 事實查核，再一路走到 T4.5 事實複查、T4.7 套用修正、T5 MOE 辭典對照、CN term detection、注音驗證、文法、標點、邏輯、故事重寫、編輯風格、報告建置與知識庫更新。它動用的子代理超過 20 個，包含 zh-converter、text-segmenter、fact-checker、moe-dictionary、cn-term-detector、zhuyin-validator、grammar-checker、punctuation-checker、logic-checker、story-rewriter、editorial-stylist、report-builder 與 reading-builder。更關鍵的是，所有子代理共用 00_Handoff/book-context.json 作為中央共享狀態，讓每輪修正都能回到同一本書的上下文，而不是各自形成孤島。

第二條 am.editorial.proofreading-orchestrator 是為「已做過完整編修」的作品準備的輕量管線。它以 Step 0–9 推進，保留必要的故事潤修與 expert review，但不再重做整套深度清洗，因此速度更快、成本更低。它還能在輸入不是 zh-TW 時，自動先建立 book/XXX/ 結構並做基礎轉換，適合已經有成熟稿件、但仍需要正式校閱與出版前整理的場景。也就是說，它專門服務「稿件成熟度已較高」的場景，並非全編修的縮水版。

第三條 am.editorial.proofread-orchestrator 聚焦在 PDF 版後驗證。它的工作聚焦在抽出 PDF、核對修正是否真的進版、進行 triple-agent verification、版面檢視與報告輸出。這裡最重要的規則有兩個：一是必須存在版本化 PDF 資料夾與 book-profile.json，二是 P2-V 的視覺確認可以推翻純文字比對結果。換句話說，就算文字層看似正確，如果行距、分段、斷行或圖說位置已造成閱讀誤解，流程仍要判定為未完成。它同時明定不得覆寫 full-editing 的報告，確保「內容編修」與「版後校對」的責任鏈不互相污染。

第四條 am.editorial.deep-analysis-writing-orchestrator 則完全聚焦原創分析內容生產。它從 P0 的四頁共識預選開始，接著做 A1 觀點分析、A2 視覺分析、A2.5 storyboard direction、A3 Lemon 風格人味寫作、A4 三代理交叉複審至少 3 輪，最後在 A5 做風險門檻值稽核。它的反 AI 腔規則非常明確：禁用「先否定再轉折」公式、禁用千篇一律的 busy-life 敘事；fanpost 類內容 AI 分數必須低於 20，其他類型低於 30，而且要求使用 claude-opus-4.6 或 claude-opus-4.7。這顯示編務域不只追求正確，還追求文本的真實人味與可讀性。

四套主控背後的共同架構觀

編務域最大的洞見，是它拒絕把所有事情塞進單一「超級編輯流程」。如果你拿全編修去做 PDF 版後校對，會浪費大量不必要的語言清理；如果拿後校稿流程去做原創分析寫作，又完全缺乏觀點建模與人味審核。四套 orchestrator 因此像四把不同的手術刀：都屬於出版領域，但切入深度、驗證方式、輸出責任完全不同。這是非常成熟的系統思維，因為它把複雜度分散到正確的位置，而不是讓使用者永遠被迫走最重的流程。

研究域最迷人的地方，在於它沒有把 orchestrator 寫成只能直接執行的流程，而是先定義一個抽象模板，再讓不同研究領域去覆寫方法論。am.research.orchestrator 就是這樣的母板：它規定 P0 到 P11 的共同骨架，但把 P4 到 P7 明確標成「MUST 覆寫」，表示任何具體研究管線若不提供自己的方法步驟，就根本不該啟動。這種設計非常像軟體工程裡的抽象基底類別，只不過它繼承的是研究紀律，而不是程式語法。

「am.research.orchestrator 不可直接執行；P4–P7 為 MUST 覆寫擴展點。統計驗證 P8 為 HARD GATE，未通過不得進最終文件與簽核。」 — 研究域抽象主控的核心契約

母板本身已經把許多重要的研究倫理寫死了。P0 是 session init，P1 由 am.research.hypothesis-designer 建立研究假說，P2 由 am.research.literature-scout 做文獻盤點，P3 由 am.research.data-explorer 做資料探索，然後把 P4–P7 留給具體領域覆寫。等方法論部分跑完後，P8 再由 am.research.statistical-validator 做硬閘門驗證，P9 進入 am.research.robustness-tester，P10 由 am.research.research-documenter 整理研究文件，P11 最終簽核。你會發現，母板真正提供的是「誠實的最低標準」：不准 p-hacking、不准 look-ahead bias、不准 overfitting，且所有關卡都要留下 gate token。

Paper Writing：在抽象母板上長出雙模式研究寫作

am.paper-writing.orchestrator 明確宣告 extends: am.research.orchestrator，這一點非常重要，因為它表示自己承接母板的倫理與驗證責任，而非另起爐灶，再加上論文域自己的方法鏈。它同時支援兩種模式：Research-First 的 R0–R11，適合先完成研究再撰寫；Draft-First 的 D0–D7.5，適合已經有草稿但需要補強研究品質。它覆寫 P4–P7 的方式，包括內容稽核、創新發現、文獻缺口分析、結構架構、草稿撰寫、事實與邏輯審核，並額外新增 R5.5 formalization audit、R7.5 innovation reframing、R7.6 AI detection / humanization、R9 submission readiness 等關卡。硬閘門至少有四個：fact-check、formalization、P8 statistical validation，以及 submission readiness 分數必須大於等於 75；AI 偵測門檻值則要求低於 40。這代表論文域真正看重的，不只是內容能不能寫出來，而是方法是否足夠正式、創新是否說得清楚、最後是否真的達到可投稿水準。

Trading Research 與 Sport Research：同一骨架，不同方法論

am.trading-research.orchestrator 則把研究母板拉到量化交易場景。它的具體 phases 會走過 strategy design、filter composition、experiment setup、feature engineering、DL/RL enhancement、pattern recognition、backtest、code review、report analysis 與 improvement loop，並配合 15 個以上的交易專用代理，例如 strategy-designer、backtest-coder、report-analyst，以及 improvement-signal、improvement-risk、improvement-reviewer、improvement-mutator、improvement-execution。母板裡的「研究誠實」到了這裡就轉譯成 no data snooping、必做 OOS 驗證、QA hard gate 不得放水。你可以把它看成：母板定義的是倫理，子類別負責把倫理翻譯成領域可操作規則。

am.sport-research.orchestrator 也遵循同樣思路，只是研究主題換成學生運動排名。它使用 17 個子代理，並設下 6 個運動領域特有的 hard gates，例如 data quality、temporal integrity、fairness 等。這個例子特別有教育意義，因為它顯示抽象研究模板並不限於論文或金融；只要一個領域需要「先建假說、再做資料與方法驗證、最後再形成報告」，都可以拿來擴展。真正不能省略的，是 P8 的統計驗證與 P9 的 robustness testing，因為那是所有研究共通的可信度底線。

從架構角度看，研究域提供了一個很漂亮的 lesson：不是所有 orchestrator 都應該立刻可執行。有時候最有價值的設計，是先做出一個不能直接跑、但能約束子系統的方法骨架。這樣一來，後續新領域不用每次都重新思考研究倫理與驗證底線，只要專心覆寫方法本身。這正是抽象模板的威力：它把好的原則變成系統層級的預設值。

有些 orchestrator 的核心任務，在於判定內容是否足夠合規、足夠原創、足夠能交出去。am.qr.orchestrator、am.da.orchestrator 與 am.nstc.writing-orchestrator 正好代表三種不同的品質治理思路：配置驅動的品質檢查、歷史偏差資料的再發預測，以及帶有人味與學術語感約束的提案寫作。它們都不是一般意義上的「內容寫作主控」，卻都非常能說明 orchestrator 在高要求場景下的價值。

「真正成熟的品質主控，不會把檢查清單寫死在程式裡；它會讀取配置、選擇檢查項、彙總裁定，再依規則自動判定是否失敗。」 — am.qr.orchestrator 的配置驅動精神

am.qr.orchestrator 是 GMP／製藥合規場景的品質審查分派者。它最有創意的地方，在於「不把要跑哪些檢查寫死」。主控會先從 YAML 載入檢查項目，再依啟用狀態與產品型態，動態路由到 13 個專責檢查員：raw-material、process-control、environment、equipment、documentation、deviation、change-control、CAPA、complaint、stability、release-testing、supplier、training。它還明定同時最多只跑 2 個 inspector（可調），每個 inspector 都必須回傳標準化裁定 YAML，最終分數與自動失敗條件則完全由配置決定。這種做法非常強，因為一旦法規框架或產品型態改變，只要調整配置，不必重寫 orchestrator 本體。

am.da.orchestrator 則是另一種品質治理：它回顧 3 年以上已結案的 deviation，分析哪些偏差有再發風險。它的流程從 P1 資料篩選、P2 偏差抽取、P3 重複事件辨識開始，接著在 P4–P6 對部門、產品、類別做排名，P7 預測 recurrence、P8 提出改善建議、P9 再由 originality guard 做原創性守門。它只接受 closed-status 偏差，因為未結案事件本身仍在變動，不適合作為趨勢樣本。它還規定 AI originality 必須低於 30%，最多只允許 3 次重寫。這裡可看出偏差分析不只是資料統計，也是報告可信度治理：如果內容太像 AI 生成模板，管理層很難真正採納。

am.nstc.writing-orchestrator 則把品質治理帶進學術提案寫作。它從 W0 的 wizard-based profile creation 起步，以 ask_user 驅動填寫申請脈絡；W1–W2 做大綱與文獻搜尋；W2.5 則用三個頂級模型做 literature review，多數決收斂，這是一種非常有代表性的「三模型驗證」模式；W3–W4 進入草稿與統計；W5 做 AI detection / humanization，提案門檻值低於 30、論文型輸出低於 25；W6–W7 再做領域審查與 DOCX 交付，而且 W3↔W5↔W6 最多只能 loop 3 次。這裡的重點，在於主控把「學術語感」、「台灣學術書寫慣例」、「不能堆 buzzwords」也變成管線規則。也就是說，品質標準不只涵蓋正確性，還涵蓋語氣與風格。

三條品質導向流程，三種不同的偏差控制方法

這三個例子共同指出一件事：品質審查不能等寫完之後才補一個 review；它必須在 orchestrator 層級決定「檢查怎麼被觸發、怎麼被量化、什麼情況下一票否決」。am.qr.orchestrator 用配置驅動解決可擴充性；am.da.orchestrator 用 closed-only 與 originality guard 解決樣本污染與報告模板化；am.nstc.writing-orchestrator 則用三模型交叉驗證與 loop 上限防止提案一直重寫卻不收斂。這些規則背後，都在幫組織把「品質」變成可執行、可稽核、可重複的制度。

流程一旦變成長鏈條，大家很快就會發現，光知道「有產出」完全不夠用。更關鍵的是：它怎麼來的、哪一關改過、誰放行的。am.governance.session-recorder、各領域 orchestrator 的 pipeline-tracking.json，再加上一段段 handoff JSON，拼起來就是這條證據鏈。大型組織敢把多代理系統放進正式流程，靠的通常就是這些東西。

「可觀測性要做的，是讓每一次派遣、每一個 gate、每一次失敗與重試，都能在事後被完整重建。」 — 多代理平台的稽核設計原則

am.governance.session-recorder 很像平台的黑盒子。session 一開始，它先把追蹤脈絡立起來，記下使用者要求、主控選了哪條路、每次 handoff 什麼時候產生，背景代理又是怎麼換狀態的；甚至還提供 localhost:8765 的視覺化介面，讓治理者直接沿著時間軸回看整段協作。這很重要，因為 orchestrator 早就不只是單一 agent 的延伸思考，而是一台會持續分派、等待、回收、再決策的流程機器。少了 session recording，你只看得到最後那份報告，中間哪個 phase 曾失敗、哪個 reviewer 拉過警報、哪裡觸發過 ask_user，通通會糊成一片。

另一條關鍵軌跡是每個 orchestrator 自行維護的 pipeline-tracking.json。像 am.dev.orchestrator 這類深度 phase-gate 管線，會在每個階段寫入目前 phase、開始與完成時間、失敗原因、重試次數與是否達到 hard gate。這讓主控不只知道自己「現在跑到哪裡」，也讓外部治理代理能判斷管線是否卡在邊界分析、測試修補，或最終 merge signoff。當流程被中斷時，這份追蹤檔也讓恢復執行成為可能：新的 session 並不需要重新猜測上下文，而是可直接從上次成功的 gate 往後接續。

handoff trail 更細，卻也最有用。每次 phase 結束留下的 JSON，不能只丟一個 status: pass 就算交差；輸入摘要、輸出交付物、驗證結果、風險說明、下一階段要接的上下文，連這次用了哪個模型，都該寫清楚。這樣回頭查時，整條決策鏈才拼得起來：是哪個 orchestrator 在哪個 phase 叫了哪個子代理、吃了哪些輸入、最後給出什麼結論。翻譯域尤其明顯，回流 handoff 還會記令牌數和模型名稱，所以成本分析不再只是猜。要是日文版品質突然掉下來，就能直接回查，是模型換了、令牌預算太緊，還是 handoff 漏了術語表。

這種可追蹤性在高要求產業尤其重要。以 am.qr 所代表的 GMP／合規審查場景來說，平台不只要做對，還要能證明自己曾盡到合理注意義務。當稽核人員追問某份放行判定是如何形成的，理想答案不會是「AI 看起來覺得可以」，而是完整鏈條：P2 讀了哪些檢查項、哪兩個 inspector 平行執行、哪個裁定觸發自動失敗、誰在 signoff 前確認了例外、是否曾啟動備援代理。這才叫做盡職查核。多代理系統一旦有了這種稽核軌跡，出了問題時就能準確定位：是 phase 設計錯、代理執行錯、模型選型錯，還是 handoff 契約本身不足。

多代理編排的價值，從來不只是把事情拆成很多 agent，而是把不同成本結構與不同工作型態放在最適合的位置。只要系統一大，成本、延遲與吞吐量就會互相拉扯：模型越強通常越貴、平行度越高通常越快但越難治理、hard gate 越嚴格通常越穩但也越慢。理解這三者的平衡，是 orchestrator 走向平台化之後一定要面對的現實。

「真正成熟的 orchestrator，不會把所有步驟都丟給最強模型；它會把昂貴的思考留給真正值得昂貴的地方。」 — 模型成本治理原則

先把一件事講白：不是每個 phase 都值得上 claude-opus。路由、格式化、證據清點、欄位完整性檢查，通常交給便宜又快的模型就夠了；真正該用高階模型的，多半是高不確定性的創作、跨來源綜合判斷、風格收斂，或深度錯誤分析。這也是成熟 orchestrator 的常態：主控自己吃的令牌其實不多，因為它主要在做路由判斷；真正燒令牌的，是 slides-writer、lectures-writer、draft-writer 這種內容生成或長文本分析代理。當 handoff 會留下模型 ID 和令牌數，團隊就能慢慢看清楚，哪些 phase 可以降級，哪些地方省不得。

平行執行帶來的速度優勢很直觀。四個 reviewer 一起跑，實際審查耗時理論上就能壓到原本的大約四分之一；品質審查、翻譯品質稽核、跨平台 reviewer 這類工作，本來就適合扇出。可別把它想得太美，平行從來不是免費午餐。多條通道到了 hard gate 前還是得收斂，整條流程最後等的永遠是最慢那一位，不是平均值。am.nstc 在 W2.5 做三模型驗證就是很典型的例子：它確實更慢也更貴，但能更早抓到文獻錯誤，省掉後面整份提案重寫的代價。

不同 orchestrator 也呈現不同的深度與廣度權衡。am.dev 是典型的深管線：12+ sequential phases，一關一關鎖定需求、邊界、實作、測試、治理。它的優點是風險逐步收斂，缺點是每個 hard gate 都可能成為等待點。相對地，am.qr 代表寬管線：核心 phase 不一定很多，但檢查通道很多，而且非常依賴平行分派與配置驅動。深管線比較像精密裝配線，寬管線比較像多工檢驗站；沒有哪一種絕對較好，重點是任務本質。如果事情本身需要連續收斂，就應該接受更深的 phase；如果事情本身是多面向檢驗，就應該把速度押在平行度上。

吞吐量策略則更偏向平台經營。當你同時處理多章課程、多語版本、多份審查報告時，最有效的方法往往是做批次切分，而不是硬把單一流程再壓更快：例如把不同章節平行、不同語種平行、不同審查通道平行，同時保留最終收斂的治理節點。另一個常用策略是非阻塞式前進：對於不影響 correctness 的審查，可先讓下一階段準備上下文，等評語回來再最終收斂。反過來說，沒有 orchestration 的成本也極高。若沒有 gate 制度，錯誤會一路流到下游，最後在接近交付時才爆炸，造成回工、重翻、重測、重簽核。那種成本通常比前面多幾個治理 phase 還要大得多。

不同編排形態的成本與效能對照

設計模式真正有用的時候，常常是系統快出事之前。多代理 orchestrator 一鬆掉治理，崩壞通常不會轟一聲出現，多半是慢慢滲進來：主控開始偷做事、handoff 變成空殼、平行通道互相覆蓋、失敗重試沒有上限。前幾次你可能只覺得有點亂，等規模放大，問題就會一起冒成品質不穩、稽核困難和成本失控。

「反模式最危險的地方，不在於它明顯錯，而在於它常常在短期內看起來更快、更省事。」 — 編排治理的警訊原則

拿系統裡常見的情況來看，反模式其實很好認。Dispatcher-Only 一鬆，主控就可能直接寫程式、直接改內容，最後誰該負責都講不清。為了趕進度跳過 hard gate，看似少等一次，實際上只是把半成品上下文塞給下一階段，後面再用數倍成本補洞。還有一種很容易踩到的坑叫「幻影交接」：handoff JSON 檔案明明在，內容卻只有空泛的 pass/fail，沒有證據、沒有風險、也沒有可用上下文。這種假完成最麻煩，因為下游會真的拿它當可靠輸入。

因此，反模式辨識不該只靠經驗，而要變成結構化審查。你需要能夠從管線追蹤、session recording、檔案擁有權、模型配置與重試計數中，看出哪裡正在累積債務。當 orchestrator 平台具備這種徵兆辨識能力時，團隊就能在崩壞之前先修設計，而不是等到交付事故發生才回頭補規則。

八種常見反模式與對治方式

大多數組織起步時，都沒有一座完整的 orchestrator 平台。更常見的畫面，是先養出幾個什麼都做的單體 agent，靠少數高手硬撐，直到品質開始飄、交接越來越痛、責任也說不清。這時候導入策略若太猛，反而容易翻車。比較穩的走法，通常是挑一個場景先試、把治理補齊，再慢慢擴出去，最後才沉澱成跨領域可重用的模板。

「組織導入 orchestrator 的關鍵，在於讓團隊看到：分工之後，責任更清楚、回工更少、證據更完整。」 — 遷移與變革管理原則

第一階段應該從單一領域試點開始，而且必須選一個痛點明確、輸出可衡量的場景，例如程式碼審查、課程翻譯或品質審查。這個試點不需要太複雜，3 到 5 個專責子代理就足夠，重點是讓團隊看見 Dispatcher-Only、phase-gate 與 handoff 的基本好處：誰負責什麼變清楚了，哪一關出錯也更容易定位。此時不追求包山包海，反而要刻意做小，讓模式先被理解、被信任。

試點一旦有成果，很多團隊下一步就想快速擴張，偏偏最容易漏掉的正是治理地基。session recording、handoff 契約、lessons learned 這些東西看起來不花俏，少了卻很傷。領域一多，大家都說自己有流程，但彼此的流程對不起來，也共用不了教訓。比較穩的做法，是先把跨領域的共同規範立住：開始要錄、過程要留 handoff、失敗要有 escalation、結案要有 merge signoff。說穿了，這一段就是平台能不能放大的地基。

第三與第四階段才是橫向擴張與模板抽象。當某個領域 pattern 已被證明有效，就可以向其他領域複製；再進一步，把共同 phase 抽成抽象母板，例如研究域的 am.research.orchestrator，或跨治理的 handoff manager、merge signoff、session recorder。對於原本的單體 agent，遷移也不必一次拆完。最實際的做法，是先把它最不穩定、最耗時、最常返工的那一段抽出去，變成第一個專責子代理；其餘部分暫時留在原 agent。等證據累積夠多，再逐步把其他責任切開。這樣的拆解才不會讓團隊因一次重構過大而失去信心。

組織層面的挑戰同樣不能低估。從「一個人全包」轉向「協調 specialists」，意味著文化必須改變：主管要接受流程變得更透明、成員要習慣在 handoff 中清楚交代上下文，而不是把所有知識藏在個人腦中。導入成效也需要新的衡量方式，不能只看單次完成時間，而要看重工率是否下降、交付是否更穩、合規稽核是否更順、團隊滿意度是否上升。當這些指標開始改善，orchestrator 就不再只是實驗工具，而會成為組織的新作業系統。

四階段遷移路徑

把整套架構走完再回頭看，orchestrator 的下一步其實很清楚：平台不會只是繼續加更多 agent，它還會更會調整自己、更能跨邊界協作，也更懂得把人類專家正式拉進流程。從 am.major 這類 meta-orchestrator，到各領域越來越成熟的治理層，方向已經浮出來了。未來的平台看起來會更像一張可學習、可發現、可協商的協作網路，而不是手工串好的 phase 清單。

「好的 orchestration 最終比拚的是紀律：知道什麼該自動化、什麼該保留給人、什麼必須留下證據。」 — 建構 16 個 orchestrator 之後得到的核心洞見

先看自我演化 orchestrator。當 am.governance.lessons-recorder 持續累積錯誤根因、失敗邊界和預防規則，主控未來就不必每次都等人工改 phase；它可以依 lessons-learned 資料，調整哪些 gate 應該前移、哪些備援代理要先叫、哪些模型組合在特定場景更穩。這不表示 orchestrator 可以隨意改寫自己。所有變動仍得待在治理框架裡，留下紀錄、接受審核，也能回滾。

另一個方向是動態代理發現。今天很多 orchestrator 仍把可用子代理名單寫死在設定裡，但 am.qr 的動態 routing 已經示範過，主控完全可以依配置、能力描述與領域 metadata 即時選通道。把這個思路放大到平台層，畫面就很不一樣了：主控收到任務後，會先查現在有哪些能力可用、哪些模型成本合理、哪些備援代理在線，而不是假定名單永遠固定。那時候 orchestrator 看起來就更像服務網格，不只是腳本排程器。

再往前看，還有跨組織和人機混合編排。未來的 handoff 很可能不只在同一個儲存庫裡流動，還會跨團隊、跨平台交換標準化契約；這也是為什麼 handoff contract、gate token、管線定義、model provenance 和審計欄位遲早會更像一套正式協定。另一邊，ask_user 的角色也會升級。現在它多半拿來處理歧義或卡關，之後完全可能把人類 reviewer 視為一種 first-class agent：有人類 SLA、有人類 handoff、也有人工 gate token，整條流程才真的進入人機共治。

還有一個面向躲不掉：倫理。當 orchestrator 會自動選代理、調整流程，甚至跨組織調度，公平性、透明性和問責性都只會比今天更重要。模型為什麼被選中、某個輸出為什麼判 fail、某個風險有沒有因成本壓力被忽略，這些都得留得下紀錄，也解釋得出來。走過七個領域、十六個 orchestrator 之後，真正留下來的體會很簡單：平台可以越做越聰明，治理千萬不能變含糊。Dispatcher-Only、phase-gate、handoff 契約和治理層守得住，未來才站得穩。

本術語表彙整全書最常出現的核心概念，方便在閱讀不同領域主控時快速對照。中文用語一律採台灣正體中文慣例。

以下清單可用於新 orchestrator 的方案審查、design review 或 merge 前自我檢查。若有任何關鍵項目無法打勾，通常代表流程還不夠可治理。

• □Is the orchestrator dispatcher-only?（主控是否完全不直接執行工作？）
• □Are phases numbered and strictly sequential?（phase 是否編號並維持明確順序？）
• □Does every phase produce a handoff artifact?（每一階段是否都會輸出交接產物？）
• □Are hard gates defined with measurable criteria?（hard gate 是否有可量測的通過標準？）
• □Is there a max retry limit (≤3) for gate failures?（gate failure 是否限制最多 3 次重試？）
• □Is ask_user used for ambiguous/blocked situations?（遇到歧義或阻塞時，是否正式使用 ask_user？）
• □Are parallel lanes explicitly assigned ownership?（平行 lane 是否有明確擁有者與寫入邊界？）
• □Is session recording enabled at pipeline start?（管線起點是否啟用 session recording？）
• □Are lessons captured at pipeline end?（管線結束時是否沉澱 lessons learned？）
• □Is merge signoff the final phase with user confirmation?（merge signoff 是否是包含使用者確認的最終 phase？）
• □Is model assignment documented for each phase?（每個 phase 是否有記錄模型分派？）
• □Are backup agents defined for critical gates?（關鍵 gate 是否有備援代理？）
• □Is the pipeline resumable after interruption?（流程中斷後是否可從既有 tracking 與 handoff 恢復？）
• □Are governance agents integrated (session, test audit, secrets, merge)?（治理代理是否完整接入？）
• □Is the handoff schema compatible with am.governance.handoff-manager?（handoff schema 是否與治理契約相容？）

以下 JSON 範本可作為設計新 orchestrator 時的起點。範本重點不在欄位愈多愈好，而在於每個欄位都要對後續 phase 真正有用。

1. 標準 phase handoff

{
  "phase": "P3-implementation",
  "status": "completed",
  "owner_agent": "am.dev.implementer-backend",
  "model": "claude-sonnet-4.6",
  "inputs": {
    "requirement_handoff": "specs/feature-x/handoff/P2.json",
    "boundary_token": "BG-2026-0007"
  },
  "outputs": {
    "files_changed": ["src/api/order.ts", "tests/order.spec.ts"],
    "summary": "新增訂單取消 API 並補上錯誤處理與測試"
  },
  "risks": ["舊版前端尚未接上新錯誤碼"],
  "next_action": "移交 test-audit 與 logic reviewer"
}

2. Gate token 與驗證結果

{
  "gate_name": "P4-test-audit",
  "token_id": "TA-2026-0142",
  "result": "pass",
  "validated_by": "am.governance.test-audit",
  "checks": {
    "required_tests_present": true,
    "coverage_threshold_met": true,
    "regression_risk": "low"
  },
  "evidence": ["reports/test-matrix.json", "reports/junit.xml"],
  "issued_at": "2026-05-30T14:20:00Z"
}

3. 翻譯回流 handoff

{
  "phase": "T3-return-handoff",
  "language": "ja-JP",
  "owner_agent": "am.course.translate-ja",
  "model": "gpt-5.4",
  "token_usage": {
    "input_tokens": 18240,
    "output_tokens": 9412
  },
  "artifacts": {
    "slides_file": "slides/topic-ja/slidesData_topic_ja.js",
    "lectures_file": "slides/topic-ja/lecturesData_topic_ja.js"
  },
  "terminology_flags": ["保留 ETF 與 K 線縮寫"],
  "next_action": "交由 translation-quality-auditor 做語義一致性檢查"
}

4. 失敗升級 handoff

{
  "phase": "P2-boundary-analysis",
  "status": "failed",
  "owner_agent": "am.dev.bug-rootcause-boundary",
  "retry_count": 3,
  "failure_reason": "無法證明根因，現有紀錄互相矛盾",
  "escalate_to": "am.dev.boundary-backup-validator",
  "required_human_input": true,
  "questions": [
    "是否有可接受的保守修補邊界？",
    "是否允許先以 feature flag 方式止血？"
  ],
  "attached_evidence": ["logs/rootcause-summary.json"]
}

如果你希望把本書的設計模式延伸到更完整的平台建設，以下主題值得持續追蹤。建議依你的領域與治理需求有選擇地深化，而不是照單全收。