這一課會完成什麼
- 比較責任交接與由管理者控制的專職工作單元，選擇適合任務的協作方式
- 定義窄工作單元契約、隔離的憑證與全域預算
- 量測重複、矛盾、引註有效性、延遲、token 與彙整品質
- 簡單查詢或依賴前一步證據的任務，維持單 Agent 路徑
開始前先準備
- • 模組 06 的單 Agent 迴圈、終止分類規則與執行軌跡
- • 能同時進行的執行獨立任務的測試資料執行器
先把定義說清楚
多 Agent 協作
多 Agent 系統由協調器把不同任務、脈絡或工具分配給獨立的模型工作單元。工作能平行進行，或需要隔離不同權限與能力時，這種架構才值得考慮。拆分後仍要明列每個單元的責任、預算、來源與失敗結果，並由協調器負責最終答案。替幾個提示詞取不同角色名稱，尚不足以做到隔離。要用相同任務比較單 Agent 與多 Agent 的品質、延遲、費用和人工修改時間。
平行工作單元可以更快搜尋獨立分支，也能保留分支本機脈絡。同時，它們可能重複搜尋、沒有證據就互相矛盾、吃完共用預算，還讓憑證多出幾個失敗點。
Anthropic 公開的廣度優先研究設定報告顯著增益，也同時說 token 使用高很多、緊密耦合的工作不適合。這些數字值得拿來設計比較，不能直接當成採用多 Agent 的理由。
現場情境
Horizon competitor landscape
具名合成情境。Horizon 研究、公司集合、問題、預算與輸出都是本機測試資料；Anthropic 公開數字會另行標示，不套到 Horizon。
- 負責人
- 你要比較單一研究迴圈，以及由管理者把有上限的公司研究工作單元當作工具的架構。
- 要做的決策
- 按問題是否獨立與預期收益，選擇固定程式流程、單 Agent，或管理者與工作單元協作。
- 目前狀態
- 基準評測有 20 題：5 題直接事實、10 題獨立多公司比較、5 題後續工作依賴前面共用證據的分析。
- 預期成果
- 直接事實避免多 Agent 額外成本；獨立比較可測平行工作單元；依賴密集的問題預設留在共用脈絡的迴圈。
限制條件
- • 管理者最多啟動 4 個工作單元，最終答案責任歸屬不能交出去。
- • 每個工作單元只拿 1 個公司或來源分支、唯讀工具、固定輸出 schema 與本機呼叫預算。
- • 全域控制器管總經過時間、支出、來源允許清單與總計工作單元。
- • 彙整只能使用已接受的工作單元輸出中存在的證據 ID。
實作範例
4 個工作單元很快做完，仍因重複分支而失敗
證據類型: 具名模擬情境HRZ-14 要求 4 家公司的治理主張。管理者指令太模糊，啟動 4 個工作單元後有 2 個查同一家公司，Delta 完全沒人處理。彙整合併 8 個引註，看似完整，卻沒驗公司涵蓋程度。
工作單元契約加分配的對象、排除的對象、必要證據次數、來源規則版本與證據 ID。管理者每個對象只預留給 1 個工作單元，彙整前驗涵蓋程度；分支失敗回 evidence_gap，重複 URL 去重且不算額外涵蓋。
修正後涵蓋 4 家公司。比較報告同時列任務成功、重複呼叫、矛盾、token、延遲、成本與審查者修改量。直接查事實的題目，即使答案正確，若只增加協調成本就回較簡單架構；不預設多 Agent 一定較好。
主張限制
Horizon 指標來自合成資料。Anthropic 公開案例以 Opus 4 當主 Agent、Sonnet 4 當工作單元，在其內部研究評測中比單 Agent Opus 4 高 90.2%；並提到 Agent 約使用聊天 4 倍 token、多 Agent 約 15 倍。這些數字只適用原架構與評測，不是本實作承諾。
做法
照著做，每一步都有檢查點
現場情境
按問題是否獨立與預期收益，選擇固定程式流程、單 Agent，或管理者與工作單元協作。
- 01先標任務結構
- 02寫窄工作單元契約
- 03集中管全域控制
驗收條件
多 Agent 只在獨立比較的同一套基準評測產生足夠淨改善時被採用；直接與緊密耦合的題有清楚備援。
- 01
先標任務結構
替 20 題標記直接查詢、獨立研究或依賴前一步證據的任務，逐題說明能否平行。看候選版結果前先凍結標籤，避免事後挑選有利的題型。
檢查點 · 5／10／5 分組完整；每題都有單 Agent 路徑與是否允許工作單元的理由。
- 02
寫窄工作單元契約
請求指定對象、範圍、排除的範圍、必要證據與本機預算；結果回證據、限制、失敗與用量，不能回任意說明文字當完成證明。
檢查點 · 工作單元不能研究未分配的對象；缺漏分支以有型別的 evidence_gap 回傳。
- 03
集中管全域控制
管理者只分配與整合，全域控制器限工作單元次數、時間、成本、權限與取消。工作單元不得遞迴委派。
檢查點 · 第 5 個工作單元、超出預算的分支與未授權工具在執行前被拒。
- 04
驗涵蓋程度再彙整
按分配的研究分支，核對證據 ID、權限、重複來源與矛盾主張。缺少任何必要分支就顯示缺口；引註很多也不能取代完整的證據涵蓋。
檢查點 · 原始 HRZ-14 測試資料因 Delta 分支缺漏而判 fail；修正版的 4 個分支都有獨立且已接受的結果。
- 05
在相同評測決定是否保留
兩種架構使用相同題目與設定，各跑 3 次。按題型比較品質、一致性、延遲、成本、重複搜尋、矛盾和人工審查負擔，再決定哪些工作值得平行。
檢查點 · 架構決策紀錄列哪些題型保留多 Agent、哪些回到單 Agent，以及取消或僅完成部分結果時怎麼處理。
實務脈絡
展示版之後
實作拆解
先依任務結構分組，再看候選版結果。直接查單一事實通常無需平行；獨立公司研究可以同時做；後一步依賴前一步證據時，拆開容易丟失脈絡。Horizon 的 5／10／5 分組是教學測試資料，每組都保留單 Agent 路徑。多 Agent 未同時通過品質、延遲、成本與審查負擔門檻，就降回基準版。
工作單元契約列分配對象、排除範圍、必要證據、來源規則、局部預算、允許工具、失敗型別與限制。管理者負責分配、取消與彙整，並承擔最後答案；全域控制器限制最多 4 個工作單元、共用支出、期限和憑證。工作單元不得遞迴委派或繼承管理者的廣泛工具權限，失敗才能定位到個別分支。
彙整前建立涵蓋矩陣，逐個必要分支核對已接受結果與有權限使用的引註。重複 URL 去重，矛盾主張並列交驗證器，不用投票取代查證。兩種架構各跑 3 次，報任務成功、重複搜尋、矛盾、總 token、p95 延遲、成本與人工修改分鐘。Anthropic 的 90.2%、約 4 倍與約 15 倍 token 只屬於其公開案例，不能當作 Horizon 的結果。
營運檢查
多工作者架構最容易在整合階段失真。主管收到結果後，先按指派範圍建立覆蓋表：每家公司是否有回傳、來源是否通過政策、引文是否存在、限制是否揭露、是否和其他分支衝突。缺一個分支就明列證據缺口，不讓語言模型用其他公司資訊補齊。相同網址或相同父文件只算一次涵蓋；兩個工作者對同一主張相反時，保留雙方證據給驗證程序，不用票數決定真實。完成這道關卡後，才允許產生最終文字。
效能比較要把協調成本攤開。除了端到端時間，還要記主管規劃與整合的模型用量、各工作者啟動與失敗重跑、工具呼叫、重複來源、取消後仍在執行的工作，以及人工處理矛盾的時間。平行化可能降低等待，卻讓總成本和審查量升高；這不一定錯，但必須符合任務價值與事前上限。對直接事實題，多工作者若沒有品質改善就淘汰；對緊密依賴題，即使偶爾更快，也要檢查因脈絡分裂造成的矛盾與遺漏。
驗證與上線
主管分派前先保留全域資源。每個分支估計模型、工具與時間上限，總和超過剩餘預算就縮小或改成單一執行；不能先啟動四個工作者，再在費用發生後取消。取消訊號要傳到正在等待的工具與模型呼叫，結果晚到時標記已取消，不進整合。部分結果若仍有價值，簡報明列未完成分支；若必要分支缺失，終止為證據不足。
身分隔離用測試證明。每個工作者只拿自己的來源允許清單與讀取憑證，嘗試其他公司、管理工具、核准或外部寫入都被拒。主管也不應把完整高權限憑證放進提示或共享脈絡；它只透過應用程式控制分派。新增角色時比較實際工具清單與核准清單，漂移就停止。這讓角色差異成為可執行政策，不是提示裡的職稱。
矛盾評分不交給單一風格裁判。先用程式檢查來源存在、版本、權限與主張方向，再把證據交分析師或窄範圍模型評分。若兩個合法來源真的不同，結果應保留差異與範圍，而非選寫得比較有自信的一方。整合器也不能新增工作者未提供的引用。以架構盲測樣本校準裁判，避免它偏愛多工作者產生的長答案。
架構決策每次模型、工具、題型或價格重大變更都重跑。新的模型可能讓單一執行足以處理原本需要分支的題目，也可能改變平行呼叫成本。報告保留每個版本的路由比例與降級原因，讓團隊看見多工作者是否真的只用在獨立高價值任務。若採用率一路擴張卻沒有相應品質增益，先收緊路由，不要再加更多角色。
補強練習
每個分支完成時回傳使用量與終止原因，主管不得只收成功文字。某工作者達到本地預算後，結果標部分完成；整合器依必要性決定是否保留現有證據或讓整體證據不足。這避免失敗分支被靜默忽略。
用故意重疊的來源測去重。四個工作者都找到同一篇首頁，覆蓋仍只算一份；若主張需要四家公司，只有四個不同公司來源才通過。報告同時列唯一父文件數與引文數，長篇答案就不能靠重複引文撐出完整感。
取消測試要確認已啟動工作真的停止。主管達到全域時間或費用上限時送取消，工具與模型呼叫收到訊號，晚到結果不進整合，租約與資源也釋放。若供應商不支援即時取消，最壞成本要先計入預留。
交付前最後檢查
主管與工作者的提示、工具與身分分開版本化。某分支品質下降時，可先回退該工作者，不必整套更換；但整合合約或來源政策改變，就要重跑所有分支與單一基準。版本關係要能從最終追蹤還原。
若無法說明某個工作者提供了哪項獨立價值，就從架構移除並重跑基準。
架構圖與實際工具清單要由同一份設定產生，避免文件和權限配置分岔。
延伸實作
分支結果要能單獨重播。保存指派範圍、工作者版本、工具清單、來源政策、輸入證據與回傳合約，不保存不必要的隱藏推理。整合失敗時，先用原結果重跑覆蓋與矛盾檢查，判斷問題在工作者還是整合器；只有分支本身證據不足才重新搜尋。這能避免每次除錯都把四個工作者全部重跑，增加費用與變異，也能讓團隊針對單一能力回退，不影響其餘通過分支。
動手實作
比較 Horizon 單 Agent 與 4 個工作單元
用相同 20 題比較模組 06 的單 Agent 基準，以及管理者搭配工作單元的版本。先分直接查詢、獨立研究和依賴前一步三類，再比較品質與協調成本。
準備項目
- • 凍結單 Agent 基準版本、20 題與來源資料集。
- • 為工作單元使用模擬讀取工具與隔離的憑證測試資料。
- • 先寫全域預算，再允許平行啟動工作單元。
- • 彙整評分器不得只看說明文字格式。
本課產出
有型別的管理者／工作單元契約、分流器、4 個限定範圍的工作單元測試資料、全域控制器、彙整驗收門檻、20 題三次試跑的比較報告與 ADR。
起始模板: 工作單元契約與全域預算
TypeScripttype WorkerRequest = {
taskId: string;
assignedEntity: string;
excludedEntities: string[];
question: string;
sourcePolicyVersion: string;
maxToolCalls: number;
};
type WorkerResult = {
taskId: string;
assignedEntity: string;
status: "covered" | "evidence_gap" | "failed";
evidenceIds: string[];
sourceUrls: string[];
limitations: string[];
toolCalls: number;
estimatedCostUsd: number;
};
type GlobalBudget = {
maxWorkers: 4;
maxWallMs: number;
maxCostUsd: number;
usedCostUsd: number;
};
function canSynthesize(expected: string[], results: WorkerResult[]): boolean {
return expected.every((entity) =>
results.some((r) => r.assignedEntity === entity && (r.status === "covered" || r.status === "evidence_gap"))
);
}預期結果
多 Agent 只在獨立比較的同一套基準評測產生足夠淨改善時被採用；直接與緊密耦合的題有清楚備援。
留給下一課
保留單 Agent 基準版本、工作單元契約、全域預算、分流器與多 Agent 失敗測試資料；總整專案只有在任務結構通過時才使用平行分支。
驗收條件
- 0120 題用相同資料集、評分器及模型設定，兩種架構各跑 3 次。
- 02管理者最多 4 個工作單元；工作單元有隔離的工具／憑證，也不能遞迴委派。
- 03彙整前驗分支涵蓋程度、證據 ID、重複與矛盾。
- 04決策報告同時包含品質、延遲、token、成本、審查負擔、關鍵失敗與降級路徑。
常見故障
故障診間
F1工作單元數量正確，仍漏掉必要分支。
- 先檢查
- 對照分配、對象預留額度、結果契約與涵蓋矩陣。
- 可能原因
- 管理者只要求『平行研究』，沒有指定互斥範圍。
- 修復方式
- 每個分支明列分配的／排除的對象，彙整前阻擋執行的涵蓋程度檢查。
- 下次怎麼避免
- 保留重複分配與分支缺漏測試資料。
F2平均延遲下降，成本與審查者工作卻暴增。
- 先檢查
- 按題型拆總計 token、工具呼叫、重複來源、矛盾與修改分鐘。
- 可能原因
- 分流器把直接或依賴密集的任務也送進平行工作單元。
- 修復方式
- 收窄多 Agent 資格，把不值得的題路由回確定性的／單 Agent。
- 下次怎麼避免
- 發布驗收同時看品質、時間、成本與審查負擔。
F3專職工作單元做了只有管理者才能授權的操作。
- 先檢查
- 查工作單元憑證、已暴露的工具、交接歷史紀錄與共用執行身分。
- 可能原因
- 工作單元繼承管理者能力或共用廣泛權限憑證。
- 修復方式
- 各角色使用工具允許清單與身分；核准／外部操作留在管理者邊界。
- 下次怎麼避免
- 每個角色跑權限拒絕測試，能力偏移直接 fail。
F4評測器偏好某架構的撰寫格式，掩蓋事實矛盾。
- 先檢查
- 確定性的引註／矛盾檢查與模型評判者格式分數分開，人工審評分歧異。
- 可能原因
- 一個廣泛評判者評分規準混在一起評呈現方式、事實與操作。
- 修復方式
- 證據／狀態用程式評，受限評判者只在通過的輸出上校準。
- 下次怎麼避免
- 回歸測試集保留人工標記與隱藏架構標籤的樣本。
展示版之後
正式上線前的邊界
- 01批准多 Agent 拆分前，必須有確定性的或單 Agent 基準版本。
- 02工作單元只用於不同能力、規則、脈絡、責任歸屬或平行分支。
- 03每個工作單元有有型別的請求、結果、證據、限制與失敗契約。
- 04全域負責人統一管預算、權限、終止、執行軌跡關聯與最終發布。
- 05各角色使用最小權限憑證；遞迴委派另行限制，預設禁止。
- 06彙整前去重證據並驗分支涵蓋程度。
- 07重複試跑評品質、延遲、成本、重複、矛盾與審查負擔。
- 08文件寫清降級、取消、partial-result 與單 Agent 備援。
證據類型
資料來源與主張限制
資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。
- [1]Orchestration and handoffshandoff · 把 agent 當成工具 · single-agent 基準
OpenAI · 官方文件 · 2026-08-20
- [2]Anthropic 如何打造 multi-agent 研究系統廣度優先委派 · 平行研究 · multi-agent 成本限制
Anthropic · 公開案例 · 2026-08-20
- [3]打造有效的 agentworkflow 與 agent 的定義 · 架構模式 · 成本與控制的取捨
Anthropic · 官方文件 · 2026-08-20
- [4]拆解 AI agent evals結果與軌跡評分 · 重複試跑 · 隔離的評測環境
Anthropic · 官方文件 · 2026-08-20
延伸的 Tenten 資源