Claude現在擁有研究功能^{[1]，可以在網絡、Google Workspace和任何集成中進行搜索，以完成復雜的任務。}

這個多智能體系統從原型到生產的旅程教會了我們關于系統架構，工具設計和prompt工程的關鍵教訓。多代理系統由多個代理（LLMs在循環中自主使用工具）組成。我們的研究功能涉及一個代理，它根據用戶查詢計劃研究過程，然后使用工具創建同時搜索信息的并行代理。具有多個代理的系統在代理協調、評估和可靠性方面引入了新的挑戰。

這篇文章分解了這些原則，我們希望你在構建自己的多智能體系統時能發現它們的有用之處。

本文內容翻譯自built-multi-agent-research-system^[2]

多Agent系統的優勢

適應開放式研究需求

研究工作往往涉及開放式問題，其解決路徑難以預先規劃。由于探索過程具有動態性和路徑依賴性，固定的線性流程無法應對復雜課題的挑戰。研究者通常需要根據階段性發現不斷調整方向，追蹤線索。這種不可預測性恰恰凸顯了AI智能體的優勢——它們能夠自主決策，靈活轉向或探索分支路徑，而傳統的單次線性流程則無法勝任此類任務。

并行探索

研究的本質在于從海量信息中提煉關鍵信息。多智能體系統通過子智能體并行運作，每個子智能體擁有獨立的上下文窗口，能夠同時探索問題的不同側面，再將核心信息壓縮傳遞給主導智能體。這種分工不僅實現了“關注點分離”（各子智能體可配備專屬工具、指令和探索路徑），還降低了單一路徑依賴，使研究更全面、獨立。

突破個體的局限

當個體的智力水平達到一定閾值時，多智能體系統成為提升效能的關鍵。類比人類社會發展：盡管個體智力在十萬年間進步有限，但信息時代的集體協作能力帶來了指數級的能力躍升。同樣，即使通用智能體也存在個體局限，而智能體群組能實現更復雜的任務。例如，內部測試顯示，以Claude Opus 4為主導、Claude Sonnet 4為子智能體的系統，在研究類任務中的表現比單智能體高出90.2%。

效能提升的核心機制

多智能體系統的優勢源于其對計算資源的合理分配。在瀏覽信息類任務（BrowseComp）中，三個因素解釋了95%的性能差異：Token用量（占80%）、工具調用次數和模型選擇。該系統通過分配獨立上下文窗口實現并行推理擴容，而Claude新版模型進一步放大了Token使用效率（如升級至Sonnet 4的增益超過雙倍Sonnet 3.7的Token預算）。

適用場景與經濟權衡

多智能體系統也存在局限性：其Token消耗約為單智能體的15倍，因此需權衡任務價值與經濟成本。此外，需共享上下文或高度依賴的任務（如多數編碼場景）目前并不適用。當前該系統更擅長高價值、強并行化、超單窗口信息量的任務，尤其在調用復雜工具時表現突出。未來隨著實時協作能力的提升，其應用邊界將進一步擴展。

技術架構

我們的研究系統使用了一個多Agent架構與協調工作者模式，其中一個領導代理協調的過程，同時委托給專門的子代理并行操作。

當用戶提交一個查詢時，主代理分析它，制定一個策略，并產生子代理同時探索不同的方面。如上圖所示，子代理作為智能過濾器，通過迭代使用搜索工具收集信息。

使用檢索增強生成（RAG）的傳統方法使用靜態檢索。也就是說，它們獲取一些與輸入查詢最相似的塊集，并使用這些塊來生成響應。相比之下，我們的架構使用多步搜索，動態查找相關信息，適應新的發現，并分析結果，以制定高質量的答案。

流程圖顯示了我們的多代理研究系統的完整工作流程。當用戶提交查詢時，系統創建一個LeadResearcher代理，該代理進入迭代研究過程。LeadResearcher首先考慮這種方法，并將其計劃保存到內存中以持久化上下文，因為如果上下文窗口超過200，000個令牌，它將被截斷，保留計劃非常重要。然后，它會創建具有特定研究任務的專用子代理（此處顯示了兩個，但可以是任何數量）。每個子代理獨立執行Web搜索，使用交錯思維^[3]評估工具結果，并將結果返回給LeadResearcher。首席研究員綜合這些結果，并決定是否需要更多的研究-如果是這樣，它可以創建更多的子代理或完善其策略。 一旦收集到足夠的信息，系統就會退出循環，并將所有發現傳遞給CitationAgent，CitationAgent處理文檔和研究報告，以確定引用的具體位置。這確保了所有主張都正確地歸因于其來源。最終的研究結果，包括引用，然后返回給用戶。

智能體的提示工程與評估

多智能體系統與單智能體系統有著關鍵的區別，包括協調復雜性的快速增長。早期的我們也犯了一些錯誤，比如為簡單的查詢生成50個子代理，無休止地在網上搜索不存在的資源，以及用過多的更新來分散彼此的注意力。由于每個代理都是由提示引導的，因此提示工程是我們改善這些行為的主要手段。下面是我們學到的一些提示代理的原則：

像智能體一樣思考

要改進智能體的表現，必須深入理解其行為模式。我們通過在控制臺中復現系統提示詞與工具，逐步觀察智能體的運行過程，從而暴露典型問題：例如在結果已充足時仍繼續搜索、使用冗長低效的查詢語句或錯誤選擇工具。高效的提示詞設計依賴于對智能體思維模型的精準把握——只有明確其決策邏輯，才能針對性優化。

強化協調器的指派能力

在我們的系統中，領導代理（lead agent）的職責是將查詢分解為多個子任務，并將這些子任務的具體信息描述給下屬代理（subagents）。為了確保每個子代理能有效地執行分配給它們的任務，它們需要獲得幾個關鍵信息：任務目標、輸出格式、使用工具和來源的指導以及明確的任務界限。如果沒有詳細的任務描述，代理們很可能會重復工作、留下遺漏或者找不到必要的信息。

最初，我們允許領導代理給出簡單、短小的指令，比如“研究半導體短缺”，但我們發現這樣的指令往往足夠模糊，以致于下屬代理誤解了任務或者與其他代理執行了完全相同的搜索。例如，一個下屬代理調查了2021年汽車芯片危機，而另外兩個代理則重復工作，調查了2025年當前的供應鏈情況，這導致勞動力的劃分不夠有效。

綜上所述，教會協調者如何委派任務是至關重要的。這包括如何清晰地定義每個子任務，確保每個代理都有明確的工作指導，從而避免工作重復、遺漏和信息查找失敗，確保任務高效、有序地完成。優化后的分派需包含四大要素， 這套標準使多智能體協作效率提升3倍。

1. 明確目標（如"分析2021年汽車芯片危機對當前產能的影響"）
2. 輸出格式規范（結構化表格/時間軸）
3. 工具與數據源指引（優先使用行業報告數據庫）
4. 任務邊界定義（避免與其它子任務重疊）

根據查詢復雜性調整規模

在不同的任務中，智能體往往難以判斷應當付出多大的代價，因此我們在提示中加了規模調整規則。對于簡單的事實查找，只需要1個代理進行3-10次工具調用；直接比較可能需要2-4個子代理，每個子代理進行10-15次調用；而復雜的研究可能需要超過10個子代理，并明確分配各自的責任。這些明確的指南幫助主要代理有效地分配資源，并防止在簡單查詢中過度投資，這是我們早期版本中常見的失敗模式。

工具的設計和選擇

工具的選擇直接決定智能體任務的成敗，例如，如果一個代理在網上去搜索只存在于Slack中的信息，那么從一開始就注定失敗。為此我們開發了智能體專用啟發式規則：

1. 優先選擇專用工具（如專利數據庫>通用搜索引擎）
2. 工具描述需包含輸入輸出示例
3. 對模糊描述工具啟動驗證流程

讓模型自我優化

我們發現，Claude 4模型可以成為出色的提示工程師。當給定一個提示和一個失敗模式時，它們能夠診斷智能體為何失敗，并提出改進建議。我們甚至創建了一個工具測試代理——當給定一個有缺陷的MCP工具時，它會嘗試使用該工具，然后重寫工具描述以避免失敗。通過對工具進行數十次測試，這個代理找到了關鍵的細微差別和漏洞。

搜索策略

在深入具體問題之前，Agent應該先探索整個領域。代理們常常默認使用過長、過于具體的查詢，導致返回結果很少。我們通過提示代理開始時使用短的、廣泛的查詢，評估可用信息，然后逐步縮小焦點來抵制這種傾向。

引入思考過程

擴展思考模式使Claude能夠輸出可見的思考過程，這可以作為一種可控制的草稿紙。主導智能體使用思考來規劃其方法，評估哪些工具適合任務，確定查詢復雜性和子代理數量，并定義每個子代理的角色。我們的測試顯示，擴展思考提高了指令執行、推理和效率。子代理也進行計劃，然后在工具結果之后使用交錯思考來評估質量，識別差距，并優化他們的下一個查詢。這使得子代理在適應任何任務時更為有效。

并行化拓展性能

復雜的研究任務自然涉及探索許多來源。我們早期的代理執行順序搜索，這是痛苦的緩慢。為了提高速度，我們引入了兩種并行化：

1. 主代理并行而不是串行地啟動3-5個子代理
2. 子代理并行使用3個以上的工具。

這些變化將復雜查詢的研究時間縮短了90%，使研究能夠在幾分鐘內完成更多工作，而不是幾小時，同時覆蓋比其他系統更多的信息。

如何評估你的智能體

在構建可靠的人工智能（AI）應用中，良好的評估是不可或缺的，而對于智能體而言，這一點同樣適用。然而，多智能體系統的評估呈現出獨特的挑戰，這一挑戰的根源在于傳統評估方法的局限性以及多智能體系統的復雜性。

傳統評估方法的局限性

傳統評估方法往往基于一個假設：AI在每次給定輸入X時，都會遵循相同的步驟Y來產出結果Z。這種評估方式忽略了多智能體系統的動態性和多樣性。在多智能體系統中，即便是在相同的起始條件下，不同的智能體可能會采取完全不同但同樣有效的路徑來達成目標。例如，一個智能體可能會檢索三個資源來尋找答案，而另一個智能體則可能檢索十個資源，或者它們可能會使用不同的工具來找到相同的答案。

這種多樣性帶來的挑戰是，我們無法總是預先知道哪一步驟是正確的，因此也就無法僅僅通過檢查智能體是否遵循了我們預設的“正確”步驟來進行評估。多智能體系統的特點在于其靈活性和適應性，而這恰恰是傳統評估方法難以捕捉的。

因此，我們需要的是一種靈活的評估方法，這種方法能夠在判斷智能體是否實現了正確的結果的同時，也考慮到它們是否遵循了一個合理的過程。這意味著評估不僅僅關注最終的輸出是否正確，還關注智能體達成目標的方式是否高效、是否采用了合理的策略。

關鍵方法

小樣本快速評估

在早期的智能代理開發階段，即使是微小的變化也可能引起巨大的影響。一個簡單的調整可能就能將成功率從30%提升到80%。當效果大小如此之大時，你只需通過幾個測試案例就能發現變化。我們開始時選取了大約20個查詢，這些查詢代表了真實的使用模式。頻繁地測試這些查詢使我們能夠清晰地看到變化的影響。

我們經常聽到AI開發團隊延遲創建評估，因為他們認為只有包含數百個測試用例的大型評估才有用。然而，最好從幾個例子開始小規模的測試，而不是拖延到你可以建立更全面的評估。

使用LLM對結果進行評估

由于研究輸出通常是自由文本，且往往沒有唯一正確答案，傳統的程序化評估方法難以適用。而大語言模型（LLM）天然適合這類開放式評估任務。我們設計了一套基于LLM的評分體系，用于對研究輸出進行標準化評估。

我們采用了一個LLM作為“裁判”（judge），根據以下維度對研究輸出進行打分（0.0-1.0），并給出“通過/未通過”判定：

1. 事實準確性（Factual Accuracy）：研究結論是否與引用來源一致？
2. 引用準確性（Citation Accuracy）：引用的來源是否真實支持相關論點？
3. 完整性（Completeness）：是否覆蓋了研究問題的所有關鍵方面？
4. 來源質量（Source Quality）：是否優先使用高質量的一手資料（如學術論文、官方報告），而非低質量的二手信息？
5. 工具使用效率（Tool Efficiency）：是否合理選擇工具，并避免冗余調用？

人工審核也很重要

即使最完善的自動化評估體系（如LLM裁判）也無法覆蓋所有現實場景中的邊界情況。人工測試者能夠捕捉到評估標準忽略的典型問題，包括：

1. 異常查詢下的幻覺回答

• 當用戶提出罕見或高度開放式問題時（如“請比較18世紀與21世紀的半導體供應鏈”），智能體可能生成看似合理但完全虛構的結論。
• 解決方案：在提示詞中強制要求“對超出訓練數據范圍的問題明確聲明不確定性”，并設置回退機制（如轉人工審核）。

2. 系統性故障模式

• 例如，早期版本智能體在連續調用多個工具時，可能因API速率限制導致任務鏈崩潰，而自動化測試未模擬此類場景。
• 解決方案：人工測試中發現該問題后，我們增加了工具調用熔斷機制——當子智能體連續3次調用失敗時，自動切換備用工具或上報主控智能體。

3. 隱蔽的數據源偏見

• 在提示詞中嵌入來源質量啟發式規則（例如：??優先選擇.edu/.gov域名、預印本平臺arXiv、知名機構報告??）。
• 為搜索引擎工具添加??site:*.edu OR filetype:pdf??等高級篩選參數。
• 這一調整使權威來源引用率從32%提升至78%。
• 人工測試者發現，智能體傾向于選擇SEO優化但低質量的內容農場（如某些商業科技網站），而非權威性更高但搜索排名較低的來源（如學術PDF或個人專家博客）。
• 改進措施：

多智能體的涌現行為

多智能體系統會自發產生涌現行為（Emergent Behaviors）——這些行為并非預先編程，而是由智能體間的交互動態形成。例如：

• 微小改動引發級聯效應：若調整主控智能體的任務分派策略（如從"嚴格分工"改為"動態搶單"），可能導致子智能體出現資源競爭或任務遺漏
• 非線性響應：某個子智能體工具調用失敗時，系統可能自動觸發"任務重分配"或"備用工具切換"，即使該流程未被顯式編碼

典型案例：在早期實驗中，我們僅修改主控提示詞中的??"請分配3個子任務"???為??"請確保至少3個角度被覆蓋"??，結果某些子智能體開始自發拆分任務，產生7-8個微任務，導致token消耗激增。

工程上的挑戰

生產上有哪些調整

在傳統軟件開發中，Bug的影響通常局限于某個功能失效、性能下降或服務中斷。但在智能體系統（Agentic Systems）中，微小的改動可能引發級聯效應，導致系統行為發生巨大變化。這種差異源于智能體的狀態持續性（Statefulness）和長時程任務（Long-Running Processes）特性，使得錯誤會不斷累積，而非簡單重啟就能解決。

狀態持續性

智能體在執行任務時，會維護一個長期記憶狀態（如對話歷史、中間推理結果、工具調用記錄）。與傳統無狀態服務（如HTTP請求-響應模式）不同，錯誤可能導致：

• 狀態污染：錯誤的中間結果影響后續決策（如錯誤的數據分析導致后續查詢偏離正軌）
• 不可逆操作：某些工具調用（如發送郵件、提交訂單）無法簡單回滾

長時程任務

智能體可能運行數小時甚至數天（如市場趨勢分析、跨平臺數據整合），這使得：

• 錯誤恢復成本高：重啟意味著丟失所有中間進展
• 資源浪費：重復執行已完成的工具調用（如重新爬取已獲取的網頁）

級聯行為變化

• 提示詞微小調整可能導致智能體策略劇變（如修改“盡量詳細”為“盡量簡潔”后，智能體跳過關鍵驗證步驟）
• 工具API的變動（如返回格式變化）可能讓智能體解析邏輯完全失效

智能體容錯系統的核心設計

可恢復執行

• 檢查點（Checkpointing）：定期保存智能體的完整狀態（如對話歷史、工具調用記錄、中間結論）

     例如：每完成3個工具調用或消耗5000token后自動快照

• 斷點續跑（Resume from Failure）：

    錯誤發生時，從最近的有效檢查點恢復，而非從頭開始

    用戶無感知（如“系統已自動修復，繼續分析中…”）

自適應恢復

• 錯誤感知與自主調整：

    當工具連續失敗時，智能體自動切換備用方案（如用Google搜索替代失效的內部數據庫查詢）

    通過??[THOUGHT]??輸出暴露決策邏輯（如“檢測到API返回格式異常，嘗試清洗數據后重試”）

• 受限重試機制（Guarded Retry）：

    不是無限制重試，而是設置熔斷條件（如最多3次失敗后觸發升級流程）

確定性保護層

調試、部署與執行優化

1. 調試新范式：應對非確定性行為

智能體的動態決策特性使得傳統調試方法失效——即使輸入相同，每次運行可能產生不同結果。我們采用以下方法應對：

• 全鏈路追蹤（Full Production Tracing）

    記錄每個決策節點的完整上下文（如工具調用參數、搜索結果排序、中間推理邏輯）

    案例：用戶報告“找不到明顯信息”時，追蹤發現智能體因過度依賴??site:.com??過濾而遺漏.edu域名的權威資料

• 高階行為監控（High-Level Observability）

    工具調用頻率異常（如某API突然被密集調用）

    決策路徑偏離（如80%的子智能體意外選擇同一低效搜索策略）

    不記錄具體對話內容（保護隱私），但分析宏觀模式：

    成效：發現某次更新后，智能體因提示詞微調產生“工具依賴癥”——調用次數增加3倍但信息質量未提升

• 非確定性調試工具箱

    重放測試（Replay Testing）：用歷史輸入+隨機種子復現問題

    差異對比（Diff Debugging）：并行運行新舊版本，比較決策路徑分歧點

2. 部署策略：狀態化系統的挑戰

智能體的長時程特性要求獨特的部署協調：

• Rainbow Deployment

1. 新舊版本并行運行，通過路由層控制流量比例
2. 新任務分配給新版本，進行中任務繼續使用舊版本至完成
3. 監控錯誤率，全量切換前確保無狀態兼容問題

• 狀態兼容性檢查

       a. 新舊版提示詞能否加載同一檢查點？

       b. 工具API變更是否導致歷史中間結果失效？

       c. 版本升級時自動驗證：

       d. 案例：某次數據庫schema更新導致智能體無法解析已保存的JSON，觸發自動回滾

3. 同步 vs 異步執行

當前同步模式的瓶頸：

• 主控智能體阻塞：必須等待所有子任務完成才能繼續
• 資源利用率低：快速完成的子智能體閑置等待慢速任務
• 缺乏動態調整：無法根據中間結果實時增減子智能體

異步化的潛在收益與挑戰：

graph LR  
A[主控智能體] -->|異步觸發| B[子智能體1]  
A -->|異步觸發| C[子智能體2]  
B --> D[工具調用]  
C --> E[網絡搜索]  
A -->|實時訂閱| F[結果流]

• 關鍵技術需求：

     a. 事件驅動架構：子智能體通過消息隊列發布進展

     b. 一致性快照：異步環境下仍能保存全局一致狀態

     c. 優先級搶占：當某結果顯著改變任務方向時（如發現關鍵證據），終止低優先級子任務

• 性能權衡實驗

4. 未來方向

• 混合執行模型：

     關鍵路徑同步（如事實核查），非關鍵路徑異步（如背景資料收集）

• LLM驅動的協調器：

     訓練專用模型實時決策“何時該同步/異步”

• 故障注入測試框架：

     模擬網絡延遲、工具故障等場景，驗證系統韌性

智能體系統的復雜性本質上是人類協作復雜性的鏡像——正如團隊管理需要平衡自由度與控制力，技術架構也需在靈活性與可靠性間找到動態平衡點。

總結

當構建人工智能(AI)代理時，最后一公里往往變成了整個旅程的大部分。在開發者的機器上能夠運行的代碼庫需要進行大量的工程化處理，才能變成可靠的生產系統。代理系統中錯誤的復合性意味著，對于傳統軟件來說的微小問題可能會完全偏離代理的軌道。一個步驟的失敗可能導致代理探索完全不同的軌跡，導致不可預測的結果。

正如本文所描述的所有原因，原型到生產的鴻溝通常比預期的要寬。盡管存在這些挑戰，多代理系統在開放式研究任務中已被證明是有價值的。用戶表示，Claude幫助他們發現了他們之前沒考慮過的商業機會，導航復雜的醫療選擇，解決棘手的技術錯誤，并通過揭示他們獨自一人找不到的研究聯系，節省了多達數天的工作。通過細致的工程設計、全面的測試、注重細節的提示和工具設計、健壯的操作實踐以及研究、產品和工程團隊之間的緊密合作（這些團隊需要對當前代理能力有深刻的理解），多代理研究系統可以在規模上可靠地運行。我們已經開始看到這些系統如何改變人們解決復雜問題的方式。

參考資料

[1] 研究功能: ??https://www.anthropic.com/news/research??

[2] built-multi-agent-research-system: ??https://www.anthropic.com/engineering/built-multi-agent-research-system??

[3] 交錯思維: ???https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking#interleaved-thinking??

本文轉載自??AI 博物院?? 作者：longyunfeigu