多智慧體到底該不該建？Anthropic、Cognition與LangChain的三種解法

2025-06-25 08:21 夕小瑤科技說

大模型驅動的 AI 智慧體（Agent）架構最近討論的很激烈，其中一個關鍵爭議點在於：
多智慧體到底該不該建？
Anthropic 的《How we built our multi-agent research system》、Cognition 的《Don’t Build Multi-Agents》與 LangChain 的《How and when to build multi-agent systems》三篇文章不謀而合地聚焦這一問題。
事情的起因是這樣子的——
兩家領先的 AI 公司—Anthropic 和 Cognition（知名 AI 程式設計智慧體 Devin 的母公司）前後腳發表了觀點不同的文章！（Ps：為了方便大家記憶，我們分為正方和反方）
正方 Anthropic 團隊釋出了文章《How we built our multi-agent research system》，表達立場：“多智慧體值得，而且已經在生產環境跑通”，並且詳細闡述了構建多智慧體系統的經驗和可行性。

反方 Cognition 團隊（Devin 的母公司）發表了《Don’t Build Multi-Agents》，雖然不是全盤否定多智慧體系統理念，但是確實“吐槽”他們多智慧體系統研發路上的遇到的血與淚，以及現有模式的弊端。

正方 Anthropic：為什麼“該建”

  • 業務需求：面向開放式研究查詢，單代理容易卡在 context 視窗與序列搜尋瓶頸。
  • 架構：Lead Agent 負責規劃與分工，隨需動態生成 Sub-agents 並行檢索，再由 Citation Agent 標註引用，閉環交付。
  • 效果：在內部 BrowseComp/自研評測裡，多智慧體架構成功率提升 ~90%，但代價是巨量 token 與複雜運維。
而且還給出了八條經驗，核心是降低協調複雜度與觀察可除錯性。

Cognition：為什麼“先別建”

  • 痛點來源：Devin 要寫可執行程式碼，任何上下文不一致都會直接編譯/邏輯出錯。
  • 遵循兩大原則
    • Share context — 子代理必須拿到完整決策鏈，而不僅是任務文字；
    • Actions carry implicit decisions — 並行寫入時衝突幾乎難以自動調解。
  • 替代方案：
    • 單執行緒長上下文代理；
    • 或引入專門“小模型”做上下文壓縮，把長曆史摘要後再續寫。
  • 結論：今天的多智慧體更適合“讀多寫少”的任務；寫程式碼這種強一致任務，單體可靠性 > 並行吞吐
一個代表“大模型工具鏈 + 搜尋”用例，另一個代表“AI 程式設計”用例——恰好覆蓋當前最熱門的兩條 Agent 落地路線。
看似碰撞，其實共識多過分歧，兩家的核心都把“Context Engineering”視作決定性難題，只是在研究檢索與程式碼生成這兩類任務上的權衡點不同。
而 LangChain 隨後也發表了一篇綜述《How and when to build multi-agent systems》，指出兩家其實都強調同一件事——什麼時候、怎樣傳遞上下文，把兩篇打擂臺的文章折中成一條共識路線。

讓我們分別看看 Anthropic、Cognition 與 LangChain 三家公司各自的解法。

Anthropic 正方陳述

背景：Anthropic 近期升級了 Claude ，現在的 Claude 可以透過訪問網際網路、Google Workspace 等資料來源，自主搜尋資訊來完成複雜的任務。
基於此能力，Anthropic 面向研究場景，研發了一套多智慧體系統，是一種基於“協調者-工作者”模式的典型多智慧體架構：
  • 主智慧體（Lead Agent ，協調者）：負責整個研究流程的規劃和協調。
  • 子智慧體（ Sub-agents ，工作者）：根據主智慧體的指示，並行執行特定的研究任務。

工作流程：
  1. 接收查詢並規劃： 當用戶提交一個研究查詢時，主智慧體首先分析查詢內容，並制定一個詳細的研究策略或計劃。
  2. 建立並分配任務： 主智慧體根據計劃，建立多個專門的子智慧體，併為每個子智慧體分配具體的、可並行執行的研究任務。這個計劃會被儲存在系統的內部記憶（Memory）中，即使在處理大量資訊導致上下文超出限制時，也能保持研究方向的一致性。
  3. 並行搜尋與評估： 每個子智慧體獨立行動收集資訊。例如，在研究“2025 年 AI 智慧體公司”時，不同的子智慧體可能同時搜尋市場預測、公司新聞、技術報告等，並且評估搜尋結果的有效性將收集到的資訊返回給主智慧體。
  4. 資訊綜合與迭代： 主智慧體接收並綜合所有子智慧體返回的資訊。根據這些資訊，主智慧體判斷是否已經收集到足夠回答查詢的內容。如果需要更多資訊，它可以調整策略、建立新的子智慧體或讓現有子智慧體進行更深入的搜尋，形成一個迭代迴圈，直到資訊充分。
  5. 生成引用與最終報告： 一旦主智慧體認為研究完成，所有收集到的結果會被傳遞給一個專門的引用智慧體（CitationAgent）。這個智慧體負責梳理所有的原始資料，精確地找出每項資訊或主張的出處。

Anthropic 團隊還介紹了為什麼要在研究任務中使用多智慧體系統：
  1. 開放式與動態的研究任務非常適合： 研究工作往往是探索未知，很難提前規劃好所有步驟。研究過程是動態的，後續步驟常常依賴於先前的發現（即“路徑依賴”）。好的研究者會根據發現調整方向，追尋新的線索。這種靈活性是線性、固定流程難以做到的。多智慧體特別適合這種任務，因為它們可以在多輪互動中自主執行，根據中間結果調整策略。
  2. 並行搜尋更高效： 搜尋的本質是從海量資訊中提煉關鍵見解。透過讓多個子智慧體同時在各自獨立的工作空間（上下文視窗）中搜索資訊，系統能並行處理更多資料。每個子智慧體專注於不同方面或使用不同工具，減少了路徑依賴，確保研究更全面和獨立。它們將提煉出的重要資訊再彙總給主智慧體。
  3. 多體協作 > 單體力量： 就像人類社會透過集體協作變得更強大一樣，多智慧體系統也能提升 AI 的整體能力。即使單個智慧體很聰明，協同工作的群體往往能完成更復雜的任務。
根據 Anthropic 的內部測試顯示，由一個強大的 Claude Opus 智慧體作為主導，配合多個 Claude Sonnet 子智慧體組成的系統，在研究任務中的表現比單個 Claude Opus 智慧體高出 90.2%。
然而，多智慧體強大的能力也伴隨著顯著的成本：
  1. 高昂的 Token 消耗： 一個智慧體完成任務通常比簡單的聊天互動消耗約 4 倍的 Token，而多智慧體系統甚至可能消耗約 15 倍的 Token。
  2. 不適合高依賴性任務： 多智慧體系統並不適合所有型別的任務。特別是一些要求所有智慧體共享完全相同的即時資訊，或者智慧體之間的步驟高度依賴、需要頻繁和緊密協調的任務，目前多智慧體系統難以勝任。
與單智慧體系統相比，多智慧體系統最顯著的挑戰在於協調複雜度的急劇增加。Anthropic 團隊提煉出了一些關鍵提示的原則和經驗：
  1. 有效的提示詞，必須理解智慧體如何處理資訊，透過模擬其工作流程，能發現問題所在（如過度工作、搜尋無效、工具選擇錯誤），從而更有針對性地改進提示詞。
  2. 明確分派任務： 主智慧體向子智慧體分配任務時，必須提供詳細指令，包括目標、輸出格式、工具使用指南和任務邊界。指令模糊會導致重複工作、資訊遺漏或誤解任務。
  3. 根據任務複雜度調整工作量： 智慧體難以自行判斷任務難度，因此需要將“規模調整規則”嵌入提示詞中。明確指導主智慧體應根據查詢複雜度（簡單、對比、複雜）建立多少子智慧體和執行多少次工具呼叫，避免資源浪費。
  4. 工具設計與選擇至關重要： 智慧體能否高效完成任務，很大程度上取決於它能否選擇並正確使用工具。工具需要清晰的用途描述，並且提示詞應包含工具選擇的策略指導（如優先使用專業工具、匹配工具與意圖），避免智慧體因工具問題而失敗。
  5. 賦能智慧體自我改進： 高階模型（如 Claude 4）能診斷自身失敗原因並提出改進建議。構建“工具測試智慧體”等機制，讓智慧體自動測試和最佳化工具描述，能顯著提升未來任務效率（如最佳化後的工具可使任務時間減少 40%）。
  6. 遵循從寬到窄的搜尋策略： 模仿人類專家研究過程，先進行廣泛搜尋瞭解概況，再逐步聚焦細節。提示詞應引導智慧體避免一開始就使用過於具體的查詢。
  7. 引導思維過程（CoT）： 利用思維鏈（Chain of Thought, CoT）等技術，讓智慧體先規劃、再執行。主智慧體用 CoT 規劃整體研究方法和資源分配；子智慧體用 CoT 評估搜尋結果並最佳化後續步驟。這能提升指令遵循、推理能力和整體效率。
  8. 並行化提升速度： 複雜研究任務涉及多來源探索。透過讓主智慧體並行啟動多個子智慧體，以及讓子智慧體並行使用多個工具，可以將複雜查詢的研究時間大幅縮短（高達 90%）。
除了怎麼構建，如何評估多智慧體系統的效果同樣是新課題。Anthropic 分享了他們的經驗：
  • 快速小樣本測試： 開發早期用少量案例快速迭代，高效發現重大問題。
  • 利用 LLM 作為評判者： 對無唯一答案的研究成果，用 LLM 根據標準進行自動化、可擴充套件的評分。
  • 結合人工評估： 人工測試能捕捉自動化遺漏的邊緣問題和微妙偏差（如偏好低質來源）。
與一次性回答不同，Agent 可能長時間執行、呼叫多個工具，其狀態在過程中不斷變化。如果中途出現錯誤，中斷整個流程不僅代價高昂，而且令使用者對產品失去信心，對於開發者也很難回答“Agent 為什麼沒找到明顯資訊？是查詢關鍵詞不佳，還是工具使用失敗？”，所以必須考慮工程和可靠性問題：
  • 智慧體有狀態且長時間執行，微小錯誤會累積，需要具備從錯誤點恢復的能力。
  • 智慧體的動態和非確定性使除錯困，需要全面的生產跟蹤和診斷根源。
  • 持續執行的複雜系統需逐步部署策略（如彩虹部署）以防中斷現有任務。

正方論點

Anthropic 最終總結，儘管有多智慧體系統將原型轉化為可靠生產系統的巨大挑戰，但它最適用於高價值、需並行處理大量資料並與複雜工具互動的任務。這類系統已在開放式研究等領域證明了自身價值，成功幫助使用者發現商業機會、解決複雜問題、節省了大量時間。

Cognition 反方陳述

Cognition 在部落格中開篇就點名市面上一些多智慧體框架“看著性感，落地慘淡”，OpenAI 的 swarm 和微軟的 autogen 的理念都是錯誤的方向。LLM 時代構建 AI 智慧體，除了已經有了一些最基本的共識外，目前還沒有形成統一的構建標準。
如果你只是初級的開發構建，已經有現成的資源協助你搭建基礎框架。但要構建真正可投入生產的應用，則另當別論。核心是把 Context Engineering 做好。
好多人知道 Prompt Engineering，也就是提示詞工程，它只是為 LLM 最佳化任務描述，把任務做好。Context Engineering 是 Prompt Engineering 的進階版，是讓系統在長時間、多輪、動態過程中自動管理上下文，這才是頭號要緊工作。
他們認為，常見的任務分解-子智慧體並行-結果合併模式（類似於 Anthropic 描述的多智慧體協作框架）在實踐中存在嚴重問題。

這個架構非常脆皮，Cognition 舉了個例子：
假設你的任務是“構建一個 Flappy Bird 克隆版”。在目前的框架下，這會被分解為子任務 1 和任務 2。
  • 任務 1:：構建一個帶有綠色管道和碰撞框的移動遊戲背景，
  • 任務 2：構建一個可以上下移動的鳥。
結果子代理 1 誤解了你的子任務，開始構建一個類似《超級馬里奧兄弟》的背景。子代理 2 雖然給你做了只鳥，但這既不像遊戲素材，動作也完全不像《Flappy Bird》裡的鳥。現在最終代理只能硬著頭皮把這兩個錯誤產物拼湊在一起。
現實世界的複雜任務充滿細微差別，每一個小細節都可能被智慧體誤解。僅僅將原始任務作為上下文分享給子智慧體是遠遠不夠的，尤其是涉及到多輪對話、智慧體自身工具呼叫等複雜性任務。任務越細、歧義越多、衝突成本越高。
於是，他們提出了一個原則：
共享上下文環境，並共享完整的智慧體執行軌跡，而非僅展示單條訊息。

但是依舊會生成一隻鳥和背景是完全不同視覺風格。問題就出在當子智慧體被設計成獨立工作時，它們之間還是無法看到彼此的即時行動和狀態。這就導致了它們可能基於相互衝突的假設行動，最終產出不一致或不協調的結果。
所以便提出了第二個原則：
每一步操作都暗含假設；多個智慧體若依據衝突假設行動，結果必然混亂。
Cognition 的這兩條原則，幾乎把當下主流多智慧體框架“一票否決”。
最終他們傾向於構建單執行緒線性智慧體等架構，因為這類結構能更好地保持任務的整體一致性和可控性。

雖然這樣的模式保障了上下文是連續的，但是，對於包含大量子任務的大型任務，一定會會導致上下文視窗溢位。

Cognition 指出，所以有必要增加一個壓縮模型，額外用小模型把歷史對話與行動壓成關鍵摘要，供後續步驟引用。（這正是 Cognition 已經實踐過的方案）

理想情況是智慧體的每個行動都基於系統中其他部分的上下文做決策，但最終仍會觸及上下文的極限。需要開發者在可靠性和複雜性之間自己做平衡。
Cognition 團隊還提供了幾個現實世界案例來佐證其觀點：
  • Claude Code 的子任務智慧體： 儘管會生成子任務，但這些子智慧體通常不併行工作，也不負責實際寫程式碼，只回答特定問題。原因是它們缺乏主智慧體的完整上下文，無法進行更復雜的任務。並行執行時，因缺乏共享上下文，可能產生衝突回應。

  • 編輯應用模型（包括早期 Devin）： 這種模式讓大模型生成編輯指令，由小模型執行。但小模型常因指令歧義而誤解意圖，導致錯誤。

反方論點

對於目前的多智慧體協作模式，Cognition 團隊持保留態度。
他們指出，儘管這種模式在概念上類似於人類並行解決問題，但目前的智慧體尚不具備支撐這類協作所需的長上下文處理能力與主動溝通能力。因此，他們判斷，強行推行多智慧體協作反而會削弱系統，導致決策分散。
他們認為，真正的跨 Agent 的上下文同步尚無人系統性解決。等單執行緒智慧體在長上下文交流上更強時，多智慧體並行才會“水到渠成”。在那之前，先把單體做好。

LangChain：“要靈活的建”

LangChain 的研究團隊在分析了正反雙方關於大語言模型應用的觀點後，發現儘管表面上看論點對立，但實際存在許多共通之處，可以提煉兩大共同見解：

  1. 上下文工程（Context Engineering）至關重要。
  2. 側重“讀取”（Read）的多智慧體系統比側重“寫入”（Write）的更容易構建。

上下文工程：構建可靠 AI Agent 的基石

當前模型雖然智慧，但若缺乏必要的任務背景資訊，仍無法高效工作。
如果說“提示工程”是為 LLM 提供靜態理想格式的任務描述，“上下文工程”則是其進階：在動態系統中自動化地、精確地提供所需上下文。把任務上下文精準、動態地塞進每個 LLM 呼叫，比“提示工程”更復雜， 是 agent 系統的頭號挑戰。
LangChain 研究團隊認為，雖然 Anthropic 的文章雖未明確使用此詞，但其核心理念與此是不謀而合的。
這一見解深刻影響了 LangGraph 的設計。作為一個低階編排框架，LangGraph 賦予開發者完全控制權，可以精確控制傳遞給 LLM 的內容、執行步驟及順序，從而實現必要的精細化上下文工程，避免隱藏提示或強制特定“認知架構”。

讀比寫先落地

側重於“讀取”任務的多智慧體系統（如資訊研究）通常比側重於“寫入”任務（如程式碼生成、內容創作）的系統更易於管理：
讀取操作比寫入操作更易於並行化。嘗試並行化寫入時，需解決代理間的有效溝通及輸出的有機合併兩大挑戰。“操作承載隱含決策，衝突決策導致糟糕結果”——尤其對於寫入操作，衝突決策產生的不可協調的輸出問題更為嚴重。
Anthropic 的 Claude 研究系統很好地例證了這一點：儘管包含讀寫，但多智慧體部分主要負責研究（讀取），而最終的報告合成（寫入）則由一個主智慧體集中處理，避免了協作寫作引入的不必要複雜性。
在智慧體評估方面，LangChain 與 Anthropic 的理念高度重合，長跑式 Agent 需要持久化執行、細粒度日誌與自動/人工混合評測。LangChain 的 LangSmith提供了用來做追蹤、除錯、LLM-as-judge、人類打分的現成能力。
最後，LangChain 研究團隊總結，只有當任務價值高、資訊面寬且可高度並行時，多智慧體的 Token “燒錢”才划算。典型就是廣域資訊研究，而大部分程式碼任務還不夠“寬”。
總之，LangChain 把兩家文章折中成一條共識路線，先把 Context Engineering 做穩，再判斷任務是“讀多還是寫多”，再選單體或多體架構，並用 LangGraph/LangSmith 之類基礎設施把可靠性與評估做到生產級。

結語

家人們！這場由 Anthropic 和 Cognition 圍繞“多智慧體系統”的精彩辯論，雖然沒有勝負，但是也確實印證了當前 A 多智慧體系統的發展確實還是處於充滿探索和試錯的關鍵階段。
而 LangChain 的研究團隊看到兩方辯論的論點後，提出了：核心並非糾結於“是否構建”，而是要看“如何靈活地構建”。
這場爭論的核心，在於如何看待“任務特性”與智慧體架構之間的關係。
Anthropic 面向研究場景， 處理“低依賴、可並行”的研究任務；Cognition 則基於在處理“高依賴、緊密耦合”的程式碼場景，LangChain 則從框架視角出發，討論多智慧體該不該建。
你們覺得呢，歡迎評論區和我們一起討論！
參考文獻https://cognition.ai/blog/dont-build-multi-agents#applying-the-principleshttps://www.anthropic.com/engineering/built-multi-agent-research-systemhttps://blog.langchain.com/how-and-when-to-build-multi-agent-systems/

相關文章