Anthropic - Multi-Agent Research System
https://www.anthropic.com/engineering/built-multi-agent-research-system
Anthropic 分享 Research 功能背後的 multi-agent 系統的經驗分享。
為什麼研究工作適合用多智能體系統
- 研究過程本質上不確定:不能預先硬編流程,因為每一步都可能因新發現而改變方向。
- AI agents 很適合做這種探索型任務:能自主運作、多輪決策,靈活地處理中途出現的線索。
- 單線式搜尋流程太死板,無法應付真正的研究挑戰。
多智能體架構的核心運作邏輯
資訊壓縮是搜尋的本質:從大量資料中萃取出精華。
每個 subagent 都有自己的 context window,分頭探索問題不同面向,最後彙整給主代理。
分離關注點(Separation of concerns):subagents 使用不同的工具和 prompt,各自探索,有效降低路徑依賴並增加調查完整性。
多智能體系統真正發揮作用的條件
一旦 AI 智能達到某個門檻,多智能體架構能幫助擴充效能。
類比:人類社會能協作,所以比單個人更強;AI agents 也是如此。
研究中常出現「廣度優先」任務:同時探索多個獨立方向,多智能體在這方面表現顯著優於單一智能體。
性能分析與成本考量
效能三大主因:
- token 使用量(佔 80% 的變異)
- 工具呼叫次數
- 模型選擇
最新 Claude 模型(如 Sonnet 4)在效率上有巨大增益,比起單純加倍 token 更有效。
代價不低:多智能體系統平均用掉 15× tokens,是一般聊天的 15 倍!
- 適合「任務價值高」且「資訊多、工具多」的場景
- 不適合所有 agent 需共用 context 或過度依賴交互協調的任務,如大部分程式開發工作
🧪 多智能體研究流程案例概覽
🎯 啟動階段
使用者送出查詢時,系統建立一個 LeadResearcher agent。
該代理會先 規劃研究策略 並儲存在 Memory,以避免 context window 超過 200,000 tokens 後被截斷。
🔄 研究迴圈
LeadResearcher 建立多個 Subagents,每個分派特定任務(如網頁搜尋、工具使用等)。
每個 Subagent:
使用 interleaved thinking 評估搜尋結果
獨立蒐集並回傳研究成果
LeadResearcher:
綜合資訊、判斷是否需要進一步研究
可啟動新的 subagents 或更新策略
📝 引用與結果產出
當資訊足夠,系統會退出 research loop。
成果交由 CitationAgent:
處理文件與研究報告
指出正確引用位置,確保所有論點都可溯源
📤 最終交付
系統回傳 完整研究報告與引用結果 給使用者。
Prompt Engineering 在多智能體系統中的關鍵作用
多智能體系統的複雜度遠高於單一智能體:早期 agent 會不斷繁衍 subagents、搜尋不存在的資料、彼此干擾訊息更新。
每個 agent 都是由 prompt 驅動 → Prompt engineering 就成了改善行為的主要手段。
提示設計八大原則
-
從 agent 的角度思考:用 Console 模擬 prompt 流程,逐步觀察 agent 行為 → 揪出問題像是冗長查詢、不停重複查找。
-
教導 orchestrator 如何分派任務:lead agent 必須清楚指派每個 subagent 的任務目標、輸出格式、使用工具與邊界 → 否則容易重工或資訊缺漏。
-
根據查詢複雜度配置努力程度:簡單任務用 1 agent + 3~10 次 tool call,複雜研究則超過 10 subagents + 明確分工。
-
工具設計與選擇至關重要:使用錯誤工具會導致搜尋無效 → 每個工具需要明確的功能定義與用途說明。
-
讓 agent 自我優化:Claude 4 可以是出色的 prompt engineer → 能診斷失敗原因並改寫工具說明,提升使用效率。
-
搜尋策略由廣入深:先用簡短廣泛查詢瞄準全貌,再逐步聚焦 → 避免一開始就查太細導致結果貧乏。
-
引導 agent 的思考流程:利用 extended thinking 作為可控 scratchpad → subagent 執行 interleaved thinking,提升查詢品質。
-
並行工具呼叫加速研究效率:
lead agent 同時啟動 3-5 subagents
每個 subagent 同時使用 3+ 工具 → 相較於序列查詢,研究速度提升高達 90%。
有效提示策略的核心
- 啟發式設計 > 硬性規則:模擬人類研究者的策略,例如:
- 分解複雜問題成小任務
- 評估資訊品質
- 根據中途發現調整搜尋方向
- 動態切換深度 vs. 廣度探索
- 加入 guardrails 限制非預期行為、並持續快速迭代測試。
如何有效評估多智能體系統(Multi-agent Systems)
📌 挑戰點在哪裡?
傳統評估假設流程是固定的 → 多智能體系統卻不是走單一路徑。
即使初始條件相同,每個 agent 執行方式可能差很多 → 使用不同工具、路徑也能達成同一目標。
所以不能只評估「步驟對不對」,要看「結果合理、過程合邏輯」。
🚀 評估策略要怎麼做?
🧯 先做小規模測試
- 剛開發時改 prompt 效果很明顯,一次 tweak 成功率可能從 30% 飆到 80%!
- 所以不用等有幾百個測試案例才能開始 → 少量但貼近實際使用情境的 query 就很有效。
📊 用 LLM 做評審超有效
- 自由形式輸出很難程式化評分 → 用 LLM 當 judge 能大幅提升效率。
- 評分標準包括:
- 事實正確性(claims 是否符合 source)
- 引用準確性(sources 是否與 claims 對應)
- 完整性(是否涵蓋所有要求的面向)
- 資源品質(是否優先使用 primary source)
- 工具效率(工具選擇與使用次數是否合理)
🧍♂️ 人類測試仍不可少
- 人類測試能發現奇怪的 edge case,例如:
- 選錯低質來源(e.g. content farm)
- 忽略好資料(e.g. academic PDF)
- Prompt 加入 source quality heuristics 有助改善這問題。
🧩 Agent 行為的「突現性」與設計要點
- 小改 lead agent 的 prompt → subagent 行為可能完全改變!
- 必須理解 agents 互動模式 而不只是看單一 agent 的行為。
- 有效的 prompt 是一套「合作框架」,包括:
- 勞務分配
- 解題策略
- 資源使用預算
多智能體系統的工程挑戰與部署可靠性
🧠 系統特性與複雜性
- 傳統軟體 bug 可能只影響某個功能,但 agentic 系統裡,小改動可能導致巨大的行為變化。
- Agent 是 有狀態的(stateful):能持續運作並跨多個 tool call 保留上下文 → 錯誤會累積,不易重啟。
🛠 錯誤處理策略
-
不能輕易重啟:一旦 agent 運作中斷,若無 resume 機制,使用者體驗會很差。
-
解法:
- 使用 model 的 自適應能力:讓 agent 理解失敗原因並調整策略
- 搭配 deterministic safeguards:例如 retry logic、regular checkpoints → 增加穩定性
🧵 除錯(Debugging)要用新觀念
- Agent 是非確定性的 → 同樣的 prompt,執行結果可能不同。
- 傳統 debug 手法難以追蹤 → 加入 全流程追蹤(production tracing),觀察 agent 的 decision path。
- 為了保護使用者隱私,不監控會話內容,而是分析 互動結構與模式。
🚢 部署策略:Rainbow Deployment
- Agent 系統是動態運行的 prompt+tool+execution 網絡 → 每次更新可能都會干擾正在執行的 agent。
- 解法:
- 不一次全部更新 → 使用 rainbow deployment,逐步將流量從舊版導向新版,兩者同時運行以減少中斷。
🕸 執行方式與併發挑戰
🚧 同步執行的瓶頸:
- 主 agent 等所有 subagent 結束後才繼續 → 雖然簡單,但容易卡住整個流程。
⚡ 非同步的潛力與風險:
- 同步可以同時執行 subagents,甚至動態生成新 agent → 大幅提升效能
- 但也帶來挑戰:
- 結果整合困難
- 狀態一致性維護成本高
- 錯誤傳播更複雜
總結
系統穩定運作的關鍵因素
要讓多智能體架構在大規模運作下仍可靠,必須仰賴以下幾點:
- 紮實的工程設計
- 全面的測試流程
- 精緻的 prompt 與工具規劃
- 穩健的操作實踐(operational practices)
- 三方團隊(研究、產品、工程)之間緊密協作,並 深刻理解 agent 行為特性
附錄:多智能體系統的進階實作技巧
🏁 End-state evaluation:評估「結果狀態」比逐步流程更實用
對於會持續改變狀態的 agent,逐步驗證每個行動太困難也不實際
建議以「是否達成最終正確狀態」作為評估核心
若 workflow 複雜,可分成幾個 checkpoints,檢查是否發生預期的狀態轉變即可,不必每步都驗證
🧠 長對話管理策略(Long-horizon conversation)
真正上線的 agent 常處理百輪以上的對話,context window 很快就爆了
解法:
agent 主動 摘要工作階段,並將重要資訊存到 external memory
當 context 即將溢出時,生成新 subagent → 起始於乾淨 context,但透過 handoff 保留必要脈絡
透過記憶機制存取 research plan 或先前結果 → 保留對話連貫性,又不失效率
📁 Subagent 輸出到檔案系統:減少“口耳相傳”的錯誤
某些資料不必透過 lead agent 傳遞 → Subagent 可直接輸出成 artifact 並存至外部系統
然後只回傳簡潔的 reference 給 coordinator
優勢:
資訊保真度高、不會在多輪傳遞中被稀釋或誤解
大型結構化資料(程式碼、報告、可視化)尤其適合此模式
減少 token 開銷 → 不必整段內容硬搬回對話歷程