Devin 的開發商 Cognition 的一個負責人 Walden 也發了一篇關於多智能體的文章 告誡大家不要構建多智能體 指出一些常見但實際效果不佳的方法，特別是多智能體架構的弊端 於是對比了一下這兩個公司是如何面對和解決多智能體的問題的

文章在這裡：

關於上下文共享和衝突決策 Cognition的觀點: 子智能體即使共享原始任務上下文，也可能因為無法看到其他子智能體正在做什麼而導致工作不一致，因為它們的行動基於相互衝突的未預設假設。他們強調原則1是“共享完整上下文和完整的智能體追蹤，而不僅僅是單獨的消息”，原則2是“行動帶有隱含決策，衝突的決策會導致糟糕的結果”。 Anthropic 首先也承認了這些限制： “有些領域需要所有智能體共享相同上下文，或者涉及智能體之間許多依賴關係，目前不適合多智能體系統”。他們特別提到，“大多數編碼任務涉及的真正可並行化任務比研究任務少，而且LLM智能體目前還不擅長實時協調和委派給其他智能體”。這與《Don’t Build Multi-Agents》中提到的Claude Code子智能體不併行寫代碼以及“編輯應用模型”中小型模型誤解指令的問題形成了呼應。 然後我們來看一下 Anthropic 是如何克服這些限制的： 協調模式: Anthropic的系統採用“協調者-工作者”模式，由一個主智能體協調整個過程，並委派任務給並行的專業子智能體。主智能體分析查詢，制定策略，並生成子智能體同時探索不同的方面。子智能體將結果返回給主智能體進行綜合。 明確委託: 他們強調“教導協調者如何委託”，即主智能體需要為子智能體提供詳細的任務描述，包括目標、輸出格式、使用的工具和來源指南，以及明確的任務邊界，以避免工作重複、遺漏或任務誤解。例如，如果沒有詳細描述，子智能體可能會重複執行相同的搜索，或者對任務進行不同的解釋。 上下文管理: 對於長期運行的任務和上下文窗口溢出問題，Anthropic的解決方案是主智能體將計劃保存到“內存”中，以持久化上下文，防止上下文窗口過大時被截斷。他們還實現了智能體在完成工作階段後總結關鍵信息並存儲到外部記憶中，並在上下文接近限制時生成新的子智能體，通過仔細交接保持連續性。 最小化“電話遊戲”: 他們通過讓子智能體將輸出直接保存到文件系統來“最小化‘電話遊戲’（game of telephone）”，而不是所有信息都通過主協調器傳遞。這有助於提高保真度和性能，並減少通過對話歷史複製大量輸出所需的token開銷，從而避免信息丟失。

關於單線程線性智能體與多智能體並行性 Cognition的觀點: 推薦最簡單的遵循原則的方法是使用“單線程線性智能體”，其中上下文是連續的。他們認為目前的智能體在長上下文、主動的交流方面不如人類可靠，因此多智能體協作只會導致脆弱的系統。 Anthropic的觀點: Anthropic則積極擁抱多智能體並行性，認為它是“擴展性能的關鍵方式”。 他們認為，對於像研究這樣開放式、不可預測的問題，多智能體系統特別適用，因為它提供了靈活性，能夠根據發現調整方法，並允許子智能體並行操作，從而實現“壓縮”和“關注點分離”。他們通過內部評估發現，多智能體研究系統在廣度優先的查詢上，性能比單智能體系統提高了90.2%。 速度提升: Anthropic通過引入兩種並行化方式大幅提升了研究時間：主智能體並行啟動3-5個子智能體，子智能體並行使用3個以上工具，從而將複雜查詢的研究時間縮短了90%。 Token消耗: 不過，Anthropic也承認這是一個“缺點”：“這些架構在實踐中會快速消耗token”，多智能體系統通常比聊天互動多用約15倍的token。因此，多智能體系統只適用於“任務價值足夠高以支付增加的性能”的場景。 協調瓶頸: Anthropic目前的主智能體是“同步執行子智能體”，即等待每組子智能體完成後再繼續，這簡化了協調，但會在信息流中造成瓶頸。他們提到異步執行將實現更大的並行性，但會增加結果協調、狀態一致性和錯誤傳播的挑戰，並期望未來模型能處理更長的複雜研究任務時，性能提升將證明其複雜性是值得的。