一個研究問題經常包含幾項可以分別調查的工作。例如，比較三種知識庫方案，要查部署方式、權限規則和數據導出能力。單 Agent 可以依次完成；多 Agent 則可以分頭取得材料，再整合成同一份比較。

真正增加難度的，是分工之後的連接：子任務怎樣劃分，哪些信息需要傳遞，結論怎樣合併，以及誰判斷調查已經充分。 多智能體研究需要設計的，正是這些協作關係。

結合 Anthropic 的多智能體研究系統，我把這些關係整理為三部分：

• 協作結構： 多 Agent 帶來什麼收益，Lead 與 Subagent 怎樣配合。
• 任務執行： 怎樣拆分和委派任務，怎樣並行搜索並交回證據。
• 結果判斷： 怎樣彙總、補查和評估，什麼情況下額外協調不值得。

下面用知識庫方案比較作為簡化例子，討論機制，不涉及具體產品推薦。

一、多智能體研究怎樣組織h2

研究型協作先要回答兩個問題：分開探索有什麼收益，整體任務由誰協調。

1. Multi-Agent：並行探索、上下文隔離與協調成本h3

並行探索：減少獨立工作之間的排隊

調查甲方案的部署文檔，不必等到乙方案的權限説明查完。這類工作可以同時進行，最後再按同一標準比較。多 Agent 對寬範圍研究有價值，首先因為任務存在多個可以獨立推進的方向。

但“查得更多”與“答得更好”之間還隔着證據篩選和彙總。如果幾個 Agent 都重複搜索同一份介紹，增加的是工作量，未必是覆蓋範圍。

獨立上下文：把探索細節留在各自分支

一個研究方向會產生大量中間材料：讀過的頁面、未成功的查詢、版本差異和暫時的假設。Subagent 可以在自己的 Context 中處理這些內容，再把關鍵發現交給 Lead。

這裏增加的是系統的探索空間，而不是 Lead 的單次窗口。子任務輸出經過篩選，主 Agent 才不必同時承擔所有分支的閲讀負擔。這個收益延續了上下文隔離的思路。

專門職責：讓不同分支採用合適的方法

部署研究需要看安裝條件，權限研究需要核對規則，導出研究則需要確認格式和限制。不同分支可以有不同的搜索路線和關注點，不必讓每次推理同時兼顧全部問題。

這些收益也有成本：重複背景、額外推理、工具調用、等待和彙總。我的判斷依據是，拆分後能否產生有用且可整合的獨立結果。範圍很小的事實查詢，或者每一步都依賴同一份最新判斷的任務，未必值得增加協作。

2. Lead / Subagent：分配任務與彙總研究h3

這類架構把“總體安排”和“局部探索”分開：Lead 持有用户目標並組織研究，Subagent 接受子任務，在局部範圍內自行決定搜索步驟。

Lead：負責計劃、委派和整合

Lead 先把用户問題轉化為比較標準，再決定分工。結果回來後，它檢查覆蓋是否完整、口徑是否一致；必要時追加調查，材料充分後組織最終回答。

因此，Lead 的主要工作不是重複所有子任務，而是處理分支之間的關係。甲採用企業版文檔、乙採用免費版文檔，這種比較尺度不一致的問題，需要在總體層面發現。

Subagent：運行自己的搜索循環

Subagent 不只是一次模型調用。它可以先搜索資料，讀到版本限制後換一個查詢，發現證據不足後繼續打開參考頁面。它有局部目標，也有獨立的 Tool Loop。

例如，權限分支讀到“支持文檔級權限”，還需要查明權限是否繼承、是否能覆蓋上層設置。停在一句概述上，尚未完成用户真正需要的調查。

Citation Agent：為報告定位引用

Anthropic 的實現還設置了 Citation Agent，在研究材料與報告形成後定位來源。這是該系統的角色安排，不是所有多 Agent 系統都必須擁有的組件。

它幫助把報告陳述對應到證據位置；事實範圍仍需核對。例如“某版本支持”被寫成“所有版本支持”，問題出在結論本身，添加鏈接不會自動修正它。

二、研究任務怎樣分解、委派與彙總h2

從用户問題到最終報告，需要把任務邊界、委派要求與證據交接連接起來。

3. Task Decomposition：按對象、主題與依賴劃分工作h3

任務分解要同時滿足兩件事：局部可以推進，整體能夠彙總。

知識庫比較至少有兩種拆法：

拆分方式	子任務負責什麼	彙總時需要處理什麼
按對象	每個 Agent 調查一家方案的全部指定能力	對齊字段、版本和解釋尺度
按主題	分別調查部署、權限、導出，覆蓋所有方案	將不同主題的發現合成各方案畫像

按對象拆，分支容易形成完整的局部認識；按主題拆，則方便對某一維度深入調查。哪一種更合理，取決於資料怎樣分佈、哪些背景會被反覆共享，以及子任務之間有多少依賴。

動態分解發生在看到當前任務和新證據以後。 如果某一家有兩個部署版本，Lead 可以追加版本核對，而不必從一開始就為所有可能情況創建分支。這與固定並行和動態編排的區別是一致的。

任務數量也不是固定配置。一個只需查官方地址的問題，沒有必要開出完整研究團隊；某一分支已經證據充分，也不需要為了保持人數對稱繼續搜索。

我會用三個問題檢查拆分：

• 子任務是否能在不持續等待其他分支的情況下產出結果？
• 返回結果是否直接服務於用户要求？
• 分支之間的重複背景和交接成本，是否小於獨立探索的收益？

這三個問題比“應該開幾個 Agent”更能解釋分工的依據。

4. Delegation：明確子任務目標、範圍與輸出h3

角色名稱只説明大致職責，委派還要提供執行這次任務所需的信息。對於研究型 Subagent，至少要講清目標、範圍、來源、輸出和結束條件。

例如，下面的委派比“研究甲方案”更容易執行：

核實甲方案的部署方式、權限能力和導出限制。以官方文檔為依據，記錄適用版本。返回每項結論、關鍵限定、來源和未確認項；不調查價格，不替其他方案作比較。覆蓋指定字段後返回，缺少公開證據的項目明確説明。

這段説明不是提前規定每條搜索命令，而是規定應該取得什麼結果，以及不能把什麼當作結果。Subagent 仍然可以根據新發現調整路線。

輸入要足夠，輸出要可接續

如果用户只考慮私有部署，子任務就必須知道這個前提。否則它可能認真調查雲服務，卻沒有回答當前任務。

輸出也不能只有“支持”“不支持”。Lead 需要知道支持什麼版本、有哪些限制，以及依據在哪裏。輸出約定的價值，是讓下一位能夠繼續判斷，而不是重新做一遍調查。

搜索指引要約束方法，不必窮舉步驟

寬範圍研究可以先找到資料入口，再逐步深入影響結論的細節。開始就使用很長、很具體的查詢，可能在尚未認識資料結構時把搜索範圍收得過窄。

工具也要匹配資料位置：公開產品文檔可以通過網頁搜索取得；內部記錄則需要訪問實際保存它們的系統。換關鍵詞不能解決查錯地方的問題。

提示改進要對應可觀察的失敗

幾個分支反覆查同一主題，應該檢查任務邊界；返回結果缺少版本，應該檢查輸出要求；已經證據充分卻繼續搜索，應該檢查結束條件。

這些都是提示工程的具體對象。它改進的是任務理解與協作行為，不只是讓語氣更像“專業研究員”。

5. Parallel Search 與 Synthesis：並行取證與結果彙總h3

兩層並行，處理不同位置的等待

Lead 同時啓動多個 Subagents，是任務層的並行；Subagent 同時查詢幾份互不依賴的資料，是工具層的並行。

兩者可以配合，但不能跳過前置依賴。需要先確定版本才能選擇文檔的操作，仍然應順序執行。一個 Agent 也能並行調用工具，因此並行調用本身不等於多智能體協作。

證據交接：壓縮細節，保留判斷條件

“支持導出”如果實際只指文本，不含附件，省略限定就會改變結論。好的摘要應縮減搜索過程，而不是縮減事實適用範圍。

較大的產物可以留在外部，回傳可讀取的引用；重要結論仍要帶上來源與限定。這樣既減少模型之間重複搬運，也保留了核查入口。

結果彙總：對齊、核查，再補查

Lead 首先對齊版本、時間和字段，再分析差異。結論衝突時，應回到來源找條件差異，而不是按多數決選答案。

如果乙的權限結果只有一段宣傳介紹，Lead 可以追加一個窄任務：“核實文檔權限與空間權限的繼承關係。”這種補查直接針對缺口，不必重新調查整個產品。

補查也需要收斂：要求的字段已有依據或明確標註未知，關鍵矛盾已經處理，繼續搜索不再改善判斷，就可以形成回答。

Anthropic 當時的實現按批次等待子任務完成。這説明分支可以並行，彙總仍可能被慢分支阻塞。異步調度能改變等待方式，但不會消除結果一致性和交接問題。系統運行機制

三、多智能體研究的質量怎樣評估h2

研究路線可以不同，仍然需要檢查結果依據、協作過程和完成任務的代價。

6. Evaluation：檢查報告質量、執行過程與成本h3

評估多 Agent，既要看回答，也要看取得回答的過程。搜索路徑可能不同，不能僅因為步驟與參考流程不同就判錯。

結果質量：用户要求是否被證據充分地回答

維度	知識庫比較中怎樣檢查
準確性	能力和限制是否符合資料，版本是否一致
引用	來源是否支持對應陳述
覆蓋	三個指定維度是否都得到處理
來源質量	是否使用具有直接依據的資料
不確定性	缺少證據的項目是否被如實標註

這裏的完整，不是讓所有格子都有肯定答案。明確哪些資料尚未公開，也是一項研究結果。

執行過程：協作在哪個環節失效

同樣是漏掉導出限制，可能有三種原因：Lead 沒有委派這項調查；Subagent 沒找到資料；或者資料已經返回，卻在彙總時丟失。

查看委派、工具結果和子任務輸出，才能區分這三種情況。它們需要不同修改，不能都歸結為“再強調一次完整性”。

LLM Judge 可以按照明確標準輔助檢查報告，人工審閲則補充難以自動判斷的來源偏差和解釋問題。兩者的作用都是提供反饋，而不是替系統作無條件的正確性保證。

成本：更快交付與更少消耗不是一回事

並行可能降低實際等待時間，同時增加總 token 和調用量。比較方案時，需要把質量、等待和總消耗放在一起，而不是隻數運行了幾個 Agent。

當分支高度依賴同一份狀態、經常需要重新同步大量背景時，協調成本會迅速上升。這也是研究型協作不能直接推廣為所有任務默認架構的原因。

幾個關鍵問題，串起任務分工、證據與評估h2

多 Agent 的收益為什麼不只是加速？

獨立 Context 可以分擔探索資料，不同職責可以集中處理不同問題。加速只是其中一項收益，證據覆蓋與信息篩選同樣重要。

怎樣判斷子任務劃分是否合理？

看它能否相對獨立地推進、是否返回整體需要的結果，以及交接成本是否可控。單純把一個題目切成幾句，並沒有保證這些條件成立。

動態拆分與固定並行的區別是什麼？

固定並行提前規定分工；動態拆分根據當前輸入與新證據確定子任務。動態的是任務安排，不是取消目標和邊界。

為什麼委派必須約定輸出？

因為結果要被另一個 Agent 使用。沒有來源、版本和未確認項，Lead 很難區分事實、假設與遺漏，也無法可靠比較不同分支。

彙總為什麼不能只是拼接摘要？

子任務通常只保證自己的局部範圍。版本對齊、結論衝突和整體覆蓋屬於跨分支問題，需要在彙總時重新檢查。

研究路徑不固定，評估依據是什麼？

以準確性、引用、覆蓋和來源質量評價結果，以調用記錄檢查過程與成本。不同路徑可以同樣合格，但無依據的結論不會因為路徑複雜而變得可靠。

獨立 Context 能否解決多個 Agent 改同一項目的衝突？

不能。它隔離模型所見的信息，不自動隔離外部代碼和業務狀態。共享項目還需要任務認領、版本同步和集成驗證。

參考資料h2

• Anthropic · How we built our multi-agent research system