有兩篇關于多智能體的文章在這兩天引起了熱議。

第一篇是 Anthropic 的《How we built our multi-agent research system》，以多個 Claude Agents 的配合為案例，分享了期間遇到的工程挑戰和經驗。

第二篇是 Cognition（AI 程序員 Devin 母公司）的《Don’t Build Multi-Agents》，看起來和 Anthropic 針鋒相對，但其實是分享了他們在 AI Coding 領域的多智能體落地實踐。

細讀就會發現，Anthropic 多智能體的成功，很多依賴于「低依賴、可并行的任務」；而 Devin 的 Coding，很多是「高依賴、緊耦合」。就連 Anthropic 自己都說，

「某些場景目前還不太適合多智能體系統，比如需要所有智能體共享同一個上下文的任務，或者智能體之間存在大量依賴關系的情況。……多智能體系統最適合那些價值高、需要大量并行處理、信息量超出單個上下文窗口、需要與多個復雜工具交互的任務。」

也就是說，當下的 AI Coding，暫時還沒辦法用多智能體，但不代表之后不能。看似觀點不同，但其實說的還是一件事。

兩篇放在一起看，基本上是今天設計Multi-Agent的必讀文章了，有教程和設計原則，還有踩坑實踐。

文章轉載自「錦秋集」和「思考機器」的翻譯版本，略有刪減。

TLDR:

• 對于超出單個智能體能力的任務，多智能體架構能有效擴展 token 的使用。

• 智能體使用的 token 通常是普通聊天的 4 倍左右，而多智能體系統更是達到了 15 倍。

• 大部分編碼任務的可并行部分比研究任務少得多，而且 LLM 智能體目前還不太擅長實時協調和分配任務給其他智能體。

• 長上下文很重要，只是今天 Anthropic 用拆分任務的方式解決了，未來會有更好的方式。

• 對于多智能體來說，提示詞很重要。提示詞不只是溝通語言，更是調度邏輯、任務協議、格式規范的集中承載體。

• 調試很重要，對于多智能體來說，微小的改動會引發連鎖反應，會累加。要預設失敗是常態，系統需要有重試的能力。

• 2025 年，對于編程等強依賴上下文的任務來說，運行多個 Agents 協作只會導致系統脆弱。決策過程過于分散，agents 之間無法充分共享上下文。

超 6000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

Claude 現在具備了強大的研究能力——它能搜索網絡、Google Workspace 以及各種集成系統，完成復雜的研究任務。

將這個多智能體系統從原型打造成生產級產品的過程，讓我們在系統架構、工具設計和提示工程方面收獲了許多關鍵經驗。所謂多智能體系統，就是讓多個智能體協同工作——每個智能體本質上都是能夠自主調用工具的大語言模型。我們的研究功能是這樣運作的：先由一個主智能體根據用戶需求制定研究計劃，然后創建多個并行工作的子智能體去搜索信息。當系統中有多個智能體同時運作時，如何協調它們、評估效果、保證可靠性——這些都是全新的挑戰。

01性能提升 90%，但目前也不是都適用

研究工作本質上是探索開放性問題，我們很難預先設定好每一步該做什么。探索復雜主題時不可能預設固定路徑，因為整個過程充滿變數，每一步的發現都會影響下一步的方向。人類做研究時，會根據新發現不斷調整策略，追蹤調查中冒出的新線索。

這種不可預測性恰恰說明了為什么 AI 智能體特別適合研究任務。研究需要根據發現靈活調整方向，探索相關聯系。模型必須能夠自主運行很多輪次，基于中間發現來決定下一步探索什么。簡單的線性流程根本無法勝任這類任務。

搜索的本質是提煉——從海量信息中萃取關鍵洞察。子智能體通過并行工作實現了這種提煉：它們各自擁有獨立的上下文窗口，可以同時探索問題的不同維度，然后把最重要的信息匯總給主研究智能體。每個子智能體還實現了關注點分離——使用不同的工具、提示和探索路徑，這減少了路徑依賴，讓調查更加全面深入。

當智能水平達到一定程度后，多智能體系統就成了提升性能的關鍵方式。這就像人類社會的演進：雖然個體人類在過去 10 萬年里變得更聰明了，但信息時代的人類社會憑借集體智慧和協作能力實現了能力的指數級增長。即便是通用智能體，單打獨斗也有其局限；而智能體團隊能完成遠超個體的任務。

我們的內部評估顯示，多智能體研究系統在處理需要同時探索多個方向的廣度型查詢時表現尤為出色。測試結果令人振奮：以 Claude Opus 4 為主智能體、Claude Sonnet 4 為子智能體的多智能體系統，比單獨使用 Claude Opus 4 的性能提升了 90.2%。

舉個實際例子：當要求找出信息技術類標普 500 公司的所有董事會成員時，多智能體系統通過任務分解，讓各個子智能體分頭搜索，成功找到了答案；而單智能體系統只能一個個慢慢搜索，最終沒能完成任務。

多智能體系統之所以有效，主要原因是它們能夠投入足夠的計算資源（token）來解決問題。通過分析 BrowseComp 評估（測試瀏覽智能體查找難覓信息的能力），我們發現三個因素解釋了 95%的性能差異。

其中，僅 token 使用量這一項就解釋了 80%的差異，另外兩個因素是工具調用次數和模型選擇。這個發現驗證了我們的架構設計：通過給不同智能體分配獨立的上下文窗口來增加并行推理能力。

最新的 Claude 模型在 token 使用效率上有巨大提升——升級到 Claude Sonnet 4 帶來的性能提升，比在 Claude Sonnet 3.7 上加倍 token 預算還要顯著。對于超出單個智能體能力的任務，多智能體架構能有效擴展 token 的使用。

當然，凡事都有代價：實際使用中，這些架構消耗 token 的速度非常快。根據我們的數據，智能體使用的 token 通常是普通聊天的 4 倍左右，而多智能體系統更是達到了 15 倍。

要讓多智能體系統在經濟上可行，任務本身必須有足夠的價值來支撐這種性能提升的成本。

另外，某些場景目前還不太適合多智能體系統，比如需要所有智能體共享同一個上下文的任務，或者智能體之間存在大量依賴關系的情況。

舉例來說，大部分編碼任務的可并行部分比研究任務少得多，而且 LLM 智能體目前還不太擅長實時協調和分配任務給其他智能體。我們發現，多智能體系統最適合那些價值高、需要大量并行處理、信息量超出單個上下文窗口、需要與多個復雜工具交互的任務。

02多智能體架構設計

我們的研究系統采用了編排器-工作器模式的多智能體架構：一個主智能體負責協調整個過程，同時指揮多個專門的子智能體并行工作。

多智能體架構實際運行示意：用戶查詢首先到達主智能體，主智能體分析后創建多個專門的子智能體，讓它們并行搜索不同方面的信息。

用戶提交查詢后，主智能體會分析需求、制定策略，然后生成多個子智能體同時探索不同維度。如上圖所示，子智能體就像智能過濾器，通過反復調用搜索工具收集信息（本例中是搜索 2025 年的 AI 智能體公司），然后將整理好的公司列表返回給主智能體，供其編寫最終答案。

傳統的檢索增強生成（RAG）方法采用靜態檢索——找出與查詢最相似的文本塊，然后基于這些文本生成回答。相比之下，我們的架構采用多步動態搜索，能夠靈活地尋找相關信息，根據新發現調整策略，通過深入分析得出高質量答案。

上圖展示了多智能體研究系統的完整工作流程。用戶提交查詢后，系統會創建一個主研究員（LeadResearcher）智能體，開始迭代式的研究過程。

主研究員首先思考研究方案，并將計劃保存到內存中——這很重要，因為當上下文超過 20 萬個 token 時會被截斷，必須保留研究計劃。接著，它會創建多個專門的子智能體（圖中顯示了兩個，但實際可以是任意數量），給每個子智能體分配特定的研究任務。

每個子智能體獨立工作：執行網絡搜索，通過交錯思考來評估工具返回的結果，然后將發現匯報給主研究員。主研究員綜合這些結果，判斷是否需要繼續研究——如果需要，它可以創建更多子智能體或調整策略。

收集到足夠信息后，系統退出研究循環，將所有發現傳遞給引用智能體（CitationAgent）。引用智能體會處理文檔和研究報告，為每個論述找到具體的引用位置，確保所有觀點都有據可查。最后，完整的研究結果連同引用一起返回給用戶。

03多智能體的提示詞原則

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

像你的智能體一樣思考。要迭代提示，你必須了解它們的效果。為了幫助我們做到這一點，我們使用我們的控制臺構建了模擬，使用系統中的確切提示和工具，然后逐步觀察智能體工作。這立即揭示了失敗模式：智能體在已經有足夠結果時還繼續工作，使用過于冗長的搜索查詢，或選擇不正確的工具。有效的提示依賴于開發智能體的準確心理模型，這可以使最有影響力的更改變得明顯。

教會編排器如何分配任務。在我們的系統中，主智能體需要把查詢拆解成子任務，然后清楚地向子智能體說明任務要求。每個子智能體都需要明確的目標、輸出格式、工具使用指南和任務邊界。如果任務描述不夠詳細，子智能體就會出現重復勞動、遺漏關鍵信息或找不到必要資料的情況。

起初，我們讓主智能體只給出簡短指令，比如「研究半導體短缺」，但發現這種模糊指令經常被誤解——子智能體要么理解偏差，要么做著完全相同的搜索。比如有一次，一個子智能體在研究 2021 年的汽車芯片危機，另外兩個卻在重復調查 2025 年的供應鏈現狀，完全沒有合理分工。

根據查詢復雜度調整資源投入。智能體很難判斷不同任務需要多少努力，所以我們在提示中直接給出了資源分配規則。

簡單的事實查詢只需 1 個智能體執行 3-10 次工具調用；對比類任務可能需要 2-4 個子智能體，每個執行 10-15 次調用；復雜研究則可能需要 10 個以上職責明確的子智能體。這些明確的指導幫助主智能體高效分配資源，避免了早期版本中常見的「小題大做」問題。

工具設計和選擇至關重要。智能體與工具的接口設計和人機界面一樣重要。使用對的工具不僅高效，往往還是成功的前提。比如，如果需要的信息只存在于 Slack 中，而智能體卻在網上搜索，那從一開始就注定會失敗。

當使用 MCP 服務器給模型提供外部工具訪問時，這個問題變得更加復雜——智能體會遇到各種質量參差不齊的陌生工具。

我們給智能體設定了明確的選擇策略：先瀏覽所有可用工具，根據用戶意圖選擇合適的工具，需要廣泛外部信息時搜索網絡，優先使用專門工具而非通用工具。糟糕的工具描述會把智能體引向歧途，所以每個工具都必須有獨特明確的用途和清晰的說明。

讓智能體學會自我提升。我們發現 Claude 4 模型本身就是出色的提示工程師。給它一個提示和失敗案例，它就能診斷失敗原因并提出改進建議。我們甚至創建了一個專門的工具測試智能體——給它一個有問題的 MCP 工具，它會嘗試使用并重寫工具描述來避免錯誤。

通過幾十次測試，這個智能體發現了許多關鍵細節和 bug。經過這樣優化的工具描述，讓后續使用的智能體任務完成時間縮短了 40%，因為它們避開了大部分常見錯誤。

先廣后精的搜索策略。搜索策略應該模仿專家研究者的做法：先縱覽全局，再深入細節。智能體往往傾向于使用過長、過于具體的查詢詞，結果返回的信息很少。我們通過提示引導智能體從簡短、寬泛的查詢開始，評估搜索結果的整體情況，然后逐步聚焦到具體內容。

引導思考過程。擴展思考模式讓 Claude 輸出額外的思考過程 token，這就像一個可控的思維草稿本。主智能體利用這個功能來規劃研究方案：評估哪些工具適合當前任務、判斷查詢的復雜程度和需要的子智能體數量、明確每個子智能體的職責。

我們的測試表明，擴展思考顯著改善了指令遵循、推理質量和執行效率。子智能體也會先做規劃，然后在獲得工具結果后使用交錯思考來評估信息質量、識別缺失內容、優化下一步查詢。這讓子智能體在應對各種任務時都更加靈活有效。

并行工具調用帶來速度和性能的飛躍。復雜的研究任務天然需要探索多個信息源。我們早期的智能體按順序執行搜索，速度慢得讓人難以忍受。為了提速，我們引入了兩層并行化：（1）主智能體同時啟動 3-5 個子智能體，而不是一個接一個；（2）每個子智能體并行使用 3 個以上的工具。

這些改變讓復雜查詢的研究時間縮短了高達 90%，使研究功能能在幾分鐘內完成原本需要幾小時的工作，同時覆蓋的信息量也遠超其他系統。

我們的提示策略核心是培養良好的思維習慣，而非制定死板的規則。我們研究了人類專家如何進行研究，并將這些策略編碼到提示中：把復雜問題分解成小任務、仔細評估信息源的質量、根據新發現靈活調整搜索方向、準確判斷何時該深挖細節何時該廣泛探索。同時，我們也設置了明確的防護措施，防止智能體失控。最終，通過建立快速迭代、可觀察、有測試用例的開發流程，我們打造出了可靠的系統。

04智能體的評估需要更靈活

優秀的評估體系是構建可靠 AI 應用的基石，智能體系統也不例外。但評估多智能體系統面臨著獨特挑戰。

傳統評估通常假設：給定輸入 X，系統應該按照路徑 Y 產生輸出 Z。但多智能體系統不是這樣運作的。即使起點完全相同，智能體也可能選擇截然不同但同樣有效的路徑來達成目標。

一個智能體可能搜索三個信息源，另一個可能搜索十個；它們可能用不同的工具找到相同的答案。由于我們往往無法預知「正確」的步驟，所以不能簡單地檢查智能體是否遵循了預設路徑。我們需要更靈活的評估方法，既要判斷智能體是否達成了正確結果，也要評估其過程是否合理。

從小規模測試立即開始。在智能體開發早期，每個改動都可能帶來巨大影響，因為有大量容易改進的地方。一個提示調整就可能把成功率從 30%提升到 80%。效果如此顯著，只需幾個測試用例就能看出變化。

我們從大約 20 個代表真實使用場景的查詢開始，測試這些查詢通常就能清楚看到改動的效果。我們經常聽到 AI 開發團隊推遲創建評估系統，因為他們認為只有包含數百個測試用例的大型評估才有價值。但實際上，與其等待構建完善的評估系統，不如立即用幾個例子開始小規模測試。

用LLM做評判可以實現規模化。研究輸出很難用程序化方式評估，因為它們是自由格式的文本，很少有唯一正確答案。LLM 天然適合為這類輸出打分。

我們使用 LLM 評判者根據評分標準來評估每個輸出：事實準確性（論述是否與資料相符？）、引用準確性（引用的資料是否支撐論點？）、完整性（是否涵蓋了所有要求？）、資料質量（是否優先使用了一手資料而非質量較低的二手資料？）、工具效率（是否合理地使用了正確的工具？) .

我們嘗試過用多個評判者分別評估各個維度，但發現使用單個 LLM 調用、單個提示、輸出 0.0-1.0 的分數和通過/失敗判定的方式最穩定，也最符合人類判斷。

當測試用例有明確答案時，這種方法特別有效——我們可以讓 LLM 評判者直接檢查答案是否正確（比如是否準確列出了研發預算最高的三家制藥公司）。使用 LLM 作為評判者讓我們能夠規模化地評估數百個輸出。

人工評估發現自動化遺漏的問題。人工測試智能體時總能發現自動評估遺漏的邊緣情況，比如在特殊查詢上的幻覺回答、系統故障或微妙的信息源選擇偏差。

在我們的案例中，測試人員發現早期智能體總是選擇 SEO 優化過的內容農場，而忽視了權威但搜索排名較低的學術 PDF 或個人博客。在提示中加入信息源質量的判斷標準后，這個問題得到了解決。即使在自動化評估的時代，人工測試依然不可或缺。

多智能體系統會表現出涌現行為——這些行為并非刻意編程而自然產生。比如，對主智能體的微小調整可能會意想不到地改變子智能體的行為模式。要想成功，必須理解智能體間的交互模式，而不僅僅是單個智能體的行為。

因此，這些智能體的最佳提示不應是死板的指令集，而應是協作框架——定義好分工方式、解決問題的方法和資源預算。要做好這一點，需要精心的提示和工具設計、可靠的經驗法則、良好的可觀察性以及緊密的反饋循環。您可以在我們的 Cookbook 中查看系統使用的開源提示示例。

05多智能體的調試需要新思路

在傳統軟件中，bug 可能導致功能失效、性能下降或服務中斷。但在智能體系統中，微小的改動會引發連鎖反應，造成行為的巨大變化。這使得為需要長時間維護狀態的復雜智能體編寫代碼變得異常困難。

智能體有狀態，錯誤會累積。智能體可能運行很長時間，在多次工具調用中保持狀態。這要求我們持久化執行代碼并妥善處理錯誤。如果沒有有效的應對措施，小小的系統故障對智能體來說都可能是災難性的。

出錯時，我們不能簡單地從頭重啟——重啟既昂貴又讓用戶沮喪。相反，我們構建了能從錯誤發生點恢復的系統。

我們還利用模型的智能來優雅地處理問題：比如，告訴智能體某個工具出現故障并讓它自行調整，效果出奇地好。我們將基于 Claude 的 AI 智能體的適應能力與確定性保障（如重試邏輯和定期檢查點）相結合。

調試需要新思路。智能體會動態決策，即使用相同提示，每次運行結果也不盡相同，這讓調試變得更加困難。比如，用戶反饋智能體「找不到明顯的信息」，但我們看不出原因。是搜索詞不當？選錯了信息源？還是工具出了故障？增加完整的生產環境追蹤功能后，我們才能診斷失敗原因并系統性地修復問題。

除了標準的可觀察性指標，我們還監控智能體的決策模式和交互結構——這一切都不涉及具體對話內容，以保護用戶隱私。這種高層次的可觀察性幫助我們診斷根本原因、發現意外行為并修復常見故障。

部署需要精心協調。智能體系統是由提示、工具和執行邏輯組成的高度狀態化網絡，幾乎持續運行。這意味著每次部署更新時，智能體可能正處于執行過程的任何階段。我們必須確保善意的代碼更改不會破壞正在運行的智能體。

我們不能同時把所有智能體更新到新版本，而是采用彩虹部署策略——在保持新舊版本同時運行的情況下，逐步將流量從舊版本遷移到新版本，避免中斷運行中的智能體。

同步執行造成瓶頸。目前，我們的主智能體同步執行子智能體，必須等待每批子智能體完成后才能繼續。這簡化了協調工作，但也在智能體間的信息流動中制造了瓶頸。

比如，主智能體無法實時指導子智能體，子智能體之間也無法相互協調，而且當某個子智能體搜索時間過長時，整個系統都會被阻塞。異步執行將帶來更多并行性：智能體可以同時工作，按需創建新的子智能體。

但異步化也會在結果協調、狀態一致性和錯誤傳播等方面帶來新挑戰。隨著模型能夠處理更長更復雜的研究任務，我們相信性能提升將證明這種復雜性是值得的。

06一些額外的建議

以下是關于多智能體系統的一些額外建議。

面向多輪對話中會持續修改狀態的智能體，采用「最終狀態評估」方法。在評估那些會在多輪對話中持續修改持久狀態的智能體時，我們會遇到獨特的挑戰。與只讀型的研究任務不同，此類智能體的每一步操作都會改變隨后步驟所處的環境，產生傳統評估方法難以處理的依賴關系。

我們的實踐表明，聚焦「最終狀態評估」而非逐步分析會更加有效。與其檢驗智能體是否按照某一特定流程操作，不如直接評估它是否達成了正確的最終狀態。這種做法承認智能體可能通過不同路徑實現同一目標，同時也能確保其輸出符合預期。對于復雜的工作流，可將評估拆分為若干離散的檢查點，在每個關鍵節點上確認預期狀態變化是否發生，而不是嘗試驗證所有中間步驟。

長時間對話的管理策略。生產環境的智能體經常要進行跨越數百輪的對話，這需要精心的上下文管理策略。隨著對話延長，標準的上下文窗口會變得不夠用，需要智能的壓縮和記憶機制。

我們實現了這樣的模式：智能體在進入新任務前，會總結已完成的工作階段并將關鍵信息存儲在外部內存中。當接近上下文限制時，智能體可以生成具有全新上下文的子智能體，同時通過精心設計的交接保持連續性。

此外，它們可以從內存中檢索存儲的上下文（如研究計劃），而不是在達到上下文限制時丟失之前的工作。這種分布式方法既防止了上下文溢出，又在長時間交互中保持了對話的連貫性。

子智能體直接輸出到文件系統，減少「傳話游戲」。對于某些類型的結果，讓子智能體的輸出繞過主協調器可以提高保真度和性能。與其要求子智能體通過主智能體傳遞所有內容，不如實現工件系統，讓專門的智能體創建獨立持久的輸出。

子智能體調用工具將工作存儲在外部系統中，然后只將輕量級引用傳回協調器。這防止了多階段處理中的信息損失，并減少了在對話歷史中復制大量輸出的 token 開銷。這種模式特別適合結構化輸出，如代碼、報告或數據可視化，因為子智能體的專門提示能產生比通過通用協調器過濾更好的結果。

07挑戰很多，但成果也很顯著

構建 AI 智能體時，最后一英里往往會變成大部分旅程。在開發機上運行良好的代碼，要成為可靠的生產系統還需要大量工程工作。

智能體系統中錯誤的復合效應意味著，傳統軟件中的小問題可能徹底搞垮智能體。一個步驟的失敗就可能讓智能體走上完全不同的軌跡，導致難以預料的結果。基于本文所述的種種原因，從原型到生產的距離往往比預期的要遠得多。

盡管挑戰重重，多智能體系統在開放式研究任務上已經證明了其價值。用戶反饋說，Claude 幫助他們發現了從未考慮過的商機、理清了復雜的醫療選擇、解決了棘手的技術難題，通過發現他們獨自無法找到的研究關聯，節省了數天的工作時間。

通過精心的工程設計、全面的測試、細致的提示和工具設計、穩健的運維實踐，以及深諳當前智能體能力的研究、產品和工程團隊的緊密協作，多智能體研究系統能夠大規模可靠運行。我們已經看到這些系統正在改變人們解決復雜問題的方式。

上圖是 Clio 嵌入圖，展示了用戶目前使用研究功能的主要方式。排名前幾的使用場景包括：開發跨專業領域的軟件系統（10%）、開發和優化專業技術內容（8%）、制定業務增長和收入策略（8%）、協助學術研究和教材開發（7%）、研究和驗證關于人員、地點或組織的信息（5%）。

08AI Coding 的多智能體實踐

此文章由 Cognition（Devin 母公司） 于 6 月 12 日在其官方 Blog 發布，作者為 Cognition 聯合創始人 Walden Yan。

LLM Agents 框架的表現令人意外地令人失望。我想基于我們自己的試錯經驗，提供一些構建 agents 的原則，并解釋為什么一些誘人的想法在實踐中實際上相當糟糕。

讓我們從可靠性開始。當 agents 需要在長時間運行中保持可靠并維持連貫的對話時，你必須采取一些措施來控制錯誤累積的可能性。否則，如果不小心，事情很快就會崩潰。可靠性的核心在于上下文工程。

2025 年，模型將變得極其智能。但即使是最聰明的人類，如果沒有被要求執行任務的具體上下文，也無法有效地完成工作。「提示工程」這一術語被創造出來，指的是需要以理想格式為 LLM 聊天機器人編寫任務的努力。「上下文工程」則是這一概念的進階。它關乎在動態系統中自動完成這一過程。這需要更多的細致考量，實際上成為了構建 AI agents 的工程師們的首要任務。

以一個常見類型的 agent 為例。這個 agent

1. 將其工作分解為多個部分

2. 啟動子 agents 來處理這些部分

3. 最終將這些結果結合起來

這是一個誘人的架構，尤其是在處理具有多個并行組件的任務領域時。然而，它非常脆弱。關鍵失敗點在于：

假設你的任務是「構建一個 Flappy Bird 克隆版」。這被分解為子任務 1「構建一個帶有綠色管道和碰撞盒的移動游戲背景」和子任務 2「構建一個可以上下移動的鳥」。 結果子 agent 1 誤解了你的子任務，開始構建一個看起來像《超級馬里奧兄弟》的背景。子 agent 2 為你制作了一只鳥，但它看起來不像游戲資源，動作也完全不像《Flappy Bird》中的那只。現在，最終 agent 不得不承擔起將這兩個誤解結合起來的棘手任務。

這看似有些牽強，但現實世界中的大多數任務都包含許多細微差別，每一層都有可能被誤解。你可能會認為，一個簡單的解決方案是將原始任務作為上下文直接復制給子 agents。這樣，它們就不會誤解自己的子任務。但請記住，在實際的生產系統中，對話很可能是多輪次的，agent 可能需要進行一些工具調用來決定如何分解任務，而任何細節都可能對任務的解釋產生影響。

原則一 共享上下文，并共享完整的 agent 軌跡，而不僅僅是單獨的消息

讓我們再次審視我們的 agent，這次確保每個 agent 都擁有之前 agents 的上下文。

不幸的是，我們還沒有完全擺脫困境。當你給你的 agent 同樣的 Flappy Bird 克隆任務時，這次，你可能會得到一個鳥和背景視覺風格完全不同的結果。子 agent 1 和子 agent 2 無法看到對方的操作，因此它們的工作最終彼此不一致。

子 agent 1 采取的行動和子 agent 2 采取的行動是基于事先未規定的相互矛盾的假設。

原則二 行動包含隱含的決策，而沖突的決策會帶來不良后果

我認為原則一和原則二非常關鍵，且很少值得違反，因此你應該默認排除任何不遵守這兩條原則的 agent 架構。你可能會覺得這很受限，但實際上你仍然可以探索許多不同的 agent 架構。

遵循這些原則的最簡單方法就是使用單線程的線性 agent：

這里，上下文是連續的。然而，對于包含許多子部分的非常大型任務，你可能會遇到上下文窗口開始溢出的問題。

說實話，簡單的架構已經能帶你走很遠，但對于那些真正需要長時間任務且愿意付出努力的人來說，你可以做得更好。有幾種方法可以解決這個問題，但今天我只介紹其中一種：

在這個世界中，我們引入了一種新的 LLM 模型，其主要目的是將一系列動作和對話的歷史壓縮成關鍵細節、事件和決策。這很難做到準確。需要投入精力去確定哪些信息是關鍵的，并創建一個擅長此任務的系統。根據不同領域，你甚至可以考慮微調一個較小的模型（這實際上是我們在 Cognition 所做的事情）。

你獲得的好處是一個在較長上下文中依然有效的 agent。不過，你最終仍會遇到限制。對于熱衷閱讀的讀者，我鼓勵你思考更好的方法來管理任意長度的上下文。

8.2 多 Agent 的落地案例

如果你是一個 agent 構建者，確保你的 agent 的每一個動作都基于系統其他部分所做的所有相關決策的上下文。理想情況下，每個動作都能看到所有其他信息。不幸的是，由于上下文窗口的限制和實際權衡，這并不總是可能的，你可能需要決定為了達到你期望的可靠性水平，愿意承擔多大的復雜度。

當你考慮設計你的 agents 以避免決策沖突時，以下是一些值得思考的現實案例：

Claude Code 子 agents

截至 2025 年 6 月，Claude Code 是一個會生成子任務的 agent 示例。然而，它從不與子任務 agent 并行工作，且子任務 agent 通常只負責回答問題，而不編寫任何代碼。為什么？因為子任務 agent 缺乏主 agent 所擁有的上下文，它無法完成除回答明確定義的問題之外的任何工作。如果它們運行多個并行的子 agents，可能會給出相互矛盾的回答，從而導致我們在前面的 agents 示例中看到的可靠性問題。在這種情況下，擁有子 agent 的好處是，子 agent 的所有調查工作都無需保留在主 agent 的歷史記錄中，這樣就可以在超出上下文之前進行更長時間的跟蹤。Claude Code 的設計者采取了一個有意為之的簡單方法。

編輯應用模型

在 2024 年，許多模型在編輯代碼方面表現非常差。編碼 agents、集成開發環境（IDE）、應用構建器等（包括 Devin）中常見的做法是使用「編輯應用模型」。其核心思想是，給一個小模型提供你想要更改的說明（以 markdown 格式），讓它重寫整個文件，比讓一個大模型輸出格式正確的 diff 更可靠。因此，構建者讓大模型輸出代碼編輯的 markdown 說明，然后將這些說明交給小模型去實際重寫文件。然而，這些系統仍然存在很多缺陷。例如，小模型經常會因為說明中的細微歧義而誤解大模型的指令，導致錯誤的編輯。如今，編輯的決策和應用更常由單個模型一次性完成。

8.3 多 Agents 需要更長上下文的支持

如果我們真的想從系統中獲得并行性，你可能會認為讓決策者彼此「交流」并協同解決問題。

這就是我們人類在意見不合時的做法（在理想情況下）。如果工程師 A 的代碼與工程師 B 的代碼產生了合并沖突，正確的做法是通過溝通解決分歧并達成共識。然而，現在的 agents 還無法進行這種長上下文主動對話，其可靠性遠不如單個 agent。人類在傳遞最重要的信息時非常高效，但這種高效需要非凡的智慧。

自從 ChatGPT 發布不久后，人們就開始探索多個 agents 相互交互以實現目標的想法。雖然我對 agents 相互協作的長期可能性持樂觀態度，但顯而易見的是，在 2025 年，運行多個 agents 協作只會導致系統脆弱。決策過程過于分散，agents 之間無法充分共享上下文。目前，我還沒有看到有人專門致力于解決這一困難的跨 agent 上下文傳遞問題。我個人認為，隨著我們讓單線程 agents 更擅長與人類溝通，這個問題將自然而然地得到解決。屆時，將釋放出更大規模的并行性和效率。

原文：

https://www.anthropic.com/engineering/built-multi-agent-research-system

https://cognition.ai/blog/dont-build-multi-agents

轉載原創文章請添加微信：founderparker