Multi-Agents：什麼才是真正有效的做法
AI 語音朗讀 · Edge TTS
Multi-Agents：什麼才是真正有效的做法
10 個月前，我寫了《不要構建 Multi-Agents》，當時我的觀點是大多數人都不應該嘗試構建多 Agent 系統 [1]。並行運作的 Agent 會在風格、邊緣案例（edge cases）和程式碼模式上做出隱性的選擇。在當時，這些決策往往會互相衝突，導致產品變得非常脆弱。但從那時起，情況已經發生了很大的變化。
在 Cognition，我們已經開始部署在實務上真正有效的多 Agent 系統。我們最初對於「並行寫作群體（parallel-writer swarms）」的觀察至今依然適用：該領域中大多數看似誘人的想法，至今仍未獲得實質性的採用。但我們發現了一類更窄、但確實有效的模式：由多個 Agent 為任務貢獻智慧，同時保持「單執行緒（single-threaded）」寫入的架構。在這篇文章中，我將總結我們在構建這些系統時學到的經驗。
Context Engineering 的回顧
在上一篇文章中，我們鼓勵讀者將構建 Agent 的思維從「Prompt Engineering」轉向「Context Engineering」。Prompt Engineering 往往鼓勵一些投機取巧的技巧，例如「你是一位資深軟體工程師」或「請多思考一下」。而 Context Engineering 則更具持久性，它專注於在假設模型能力會隨時間增強的前提下，為模型提供正確的 context。由於種種原因，Context Engineering 在多 Agent 架構中會變得極具挑戰性。過去，我們建議遵循以下原則：
在 Agent 之間共享盡可能多的 context。確保它們看到相同的資訊來源，保持在同一頁面上（待辦事項、計畫文件），並對它們需要完成的整體任務共享相同的先驗知識（priors）。必要時協助它們進行溝通。
行動會帶來隱性決策。當一個 Agent 進行某些變更或編輯時，它可能會做出隱性選擇（風格、程式碼模式、如何處理特定邊緣案例），這些選擇可能會與其他並行 Agent 的隱性選擇發生衝突。因此，在多個 Agent 同時執行寫入動作的多 Agent 世界中，決策過程可能會變得相當破碎。
儘管過去幾個月發生了很多變化，但對深思熟慮的 Context Engineering 的需求並未改變。由於原則 2 的影響，世界上大多數多 Agent 架構仍僅限於「唯讀（readonly）」子 Agent，例如網頁搜尋子 Agent 和程式碼搜尋子 Agent。例如，Devin 可以呼叫 Deepwiki 子 Agent 來獲取程式庫的 context。但這類子 Agent 更像是工具呼叫，而非真正的多 Agent 協作。我們希望探索當 Agent 以更具互動性的方式協作時，能解鎖哪些能力。
過去 10 個月發生了什麼變化
首先，模型已經變得更加「Agent 化（agentic）」。它們能直觀地理解工具使用、自身的 context 限制，以及如何為協作者（無論是人類還是其他 Agent）提煉 context。結果就是，Agent 的使用量出現了……驚人的成長。即使觀察我們最大型企業客戶群體中 Devin 的使用情況（這類客戶通常對採用新技術持謹慎態度），我們也看到了過去 6 個月內出現了爆炸性成長（約 8 倍）。
這種使用量的爆炸式成長，同時帶來了對多 Agent 的推力與拉力。
在推力方面，能力的提升讓使用者自然地嘗試更多多 Agent 架構。當你使用這麼多 Agent 時，自然會開始在這些 Agent 周圍的所有環節遇到瓶頸：管理、規劃和審查。例如，有些人編寫了腳本讓 Devin 來管理其他 Devin。許多人也傾向於讓他們的程式撰寫 Agent 與審查 Agent 進行來回迭代。
在拉力方面，Agent 使用量的爆炸導致了成本的激增。隨著新一代 Mythos 等級、更大型且更強大的模型即將問世，人們自然會問：如何在降低成本的同時實現前沿能力？而多 Agent 系統可能就是一個自然的答案。
此外，網路上也出現了一波將大量 Agent 投入大型工程專案的轟動演示。著名的例子包括構建網頁瀏覽器（20 萬行程式碼）、構建 C 編譯器（10 萬行程式碼）以及優化 LLM 訓練腳本（1 萬次以上迭代）。這些演示很令人興奮，但它們都有一個大多數真實軟體所不具備的特性：一個簡單、可驗證的成功標準。真實的軟體需要一個能夠擴展人類品味與決策能力的系統，這正是我們探索多 Agent 系統的背景。
一些實用的 Multi-agent 實驗
1) 笨到不該有效，卻意外有效的 Code-Review-Loop
你可能會認為讓模型審查自己的程式碼不會有任何有用的發現。但即使是 Devin 自己寫的 PR，Devin Review 平均每個 PR 仍能抓出 2 個 Bug，其中約 58% 是嚴重的（邏輯錯誤、遺漏邊緣案例、安全漏洞）。系統通常會進行多輪程式碼審查循環，每次都能發現新的 Bug（這並不總是好事，因為這可能很耗時）。今天，我們讓 Devin 和 Devin Review 原生進行相互迭代，這樣當人類打開 PR 時，大多數 Bug 都已經解決了。
反直覺的部分在於：有趣的是，我們發現當程式撰寫 Agent 和審查 Agent 事先不共享任何 context 時，這種技術效果最好。為什麼？
這背後有哲學和技術上的理由。首先，我們必須記住，將同一個模型放入兩個 Agent 中，即使 Agent 的 harness 完全相同，也不會讓它們產生你想像中那種「一個人同時做兩件事」時會有的自我偏見或相關性。這些 Agent 終究是根據其 context 運作的系統。它們沒有自我，任何可能存在的共享偏見最終都來自於它們的訓練過程，而我們現在可以假設這些訓練過程的品質相當高。
審查 Agent 擁有完全乾淨的 context，也有助於它深入挖掘原始程式撰寫 Agent 可能忽略的領域。一方面，這是因為它被迫在沒有規格說明的情況下，從實作中進行反向推理，並且可以公開質疑原始 Agent 可能因使用者指令錯誤（例如使用者要求 Agent 實作不安全的模式）而忽略的問題。但更重要的是，擁有乾淨的 context 讓 Agent 因為 Attention 機制的數學原理而變得更聰明。「Context Rot」是一個有據可查的現象，即模型在 context 長度越長時，做出的決策越不聰明。模型通常有有限的 Attention Head 數量，當它們需要處理不斷增長的指令、Prompt、程式碼等 context 時，重要的細節可能無法完全納入決策。當程式撰寫 Agent 已經花費數小時處理任務、閱讀儲存庫、執行指令、思考不同方法、修復錯誤時，它會迅速累積大量的 context。而專職的審查 Agent 可以跳過這些無關的 context，只看 diff，並在從頭開始閱讀程式碼時重新發現它所需的任何 context。由於 context 較短，提升的智慧自然會增加對細微問題的檢測能力。
讓這個系統運作良好的最後一個關鍵部分，是程式撰寫 Agent 與審查 Agent 之間的溝通橋樑。基本上，Devin 是否能正確利用其更廣泛的使用者指令、決策等 context，來過濾來自 Devin Review 的 Bug？這對於防止循環、違背使用者意圖、執行範圍外的工作等至關重要。我們發現，透過一些專門的 Prompting，現今的模型可以在這裡做出合理的判斷，最終你能在兩個 Agent 與人類之間獲得一些非常有趣的互動。
重點總結： 在使用「生成器-驗證器（generator-verifier）」循環時，乾淨的 context 會顯著提升能力。但與整體 context 的清晰溝通與整合，對於獲得一致的體驗至關重要。
2) 大型、昂貴的模型回歸了——介紹「Smart Friend」
如果你觀察過去幾個月最受歡迎的模型，會發現為了效能，市場明顯從 Anthropic 的 Sonnet 級別等中型模型，轉向了 Anthropic 的 Opus 級別等大型模型。隨著 Mythos 的到來，我們基本上可以說「Scaling 回來了」。
這背後隱含的意義是，前沿智慧很快就會因為太昂貴（或許也太慢）而無法用於大多數日常任務。同時，你也會面臨小型模型的兩難：任務可能比預期更困難。
我們如何兩全其美？在 Windsurf 中，我們在 10 月份推出 SWE-1.5（一款 950 tok/sec 的次前沿模型）時進行了一項實驗。我們發現，當它與 Sonnet 4.5 搭配進行「規劃」時，我們能夠彌補一小部分效能差距，同時保持低成本和快速的反應速度。
我們實現這一點的實際架構是：將更聰明/更強大的模型作為一個「Smart Friend」工具，供主要/較小的模型呼叫。基本上，讓主要/較小的模型決定何時情況足夠棘手，值得諮詢更聰明/昂貴的模型。但我們很快發現，設計 context 傳輸和溝通非常棘手：
- 主要模型需要知道如何與 Smart Friend 交談。
這種架構的核心難點在於「較笨的模型如何知道自己已達極限？」與那種由聰明的主要模型將任務委派給較小次 Agent 的常見反向架構不同，這裡決定何時委派的模型並非較聰明的那一個。這裡有幾個潛在的解決方案。首先，你可以鼓勵主要 Agent 至少呼叫一次 Smart Agent，以評估它是否認為有遺漏的棘手之處。你也可以透過 Prompt-tuning 或訓練主要模型，使其對此決策更加校準。根據主要模型的智慧程度，可能需要特定領域的指導方針，例如在遇到合併衝突時總是呼叫 Smart Friend。
這種溝通方法的另一個棘手問題是：主要模型應該與 Smart Friend 共享什麼 context？此外，主要模型應該問 Smart Friend 什麼？如果主要模型只共享其總 context 的一部分，那麼聰明的模型可能無法做出完全知情的決策。我們發現，對於現今的模型來說，一個合理的 80/20 解決方案是直接與聰明模型共享主要模型完整 context 的一個分支（fork）。同樣地，我們發現鼓勵主要模型提出廣泛的問題（「我該怎麼做？」），並讓聰明模型決定討論什麼內容比較有趣，效果更好。
- Smart Friend 需要知道如何回應主要模型。
無論你如何調整 (1)，你都可能會發現由於 context 遺失而導致的品質差距。調整另一個方向的溝通可以彌補這些差距。例如，假設主要模型從未查看過 important_file.py，並詢問了需要該檔案內容知識的問題。在這種情況下，聰明模型的正確答案不是編造一些理論（這通常是預設行為），而是明確指示主要模型去調查該檔案，然後稍後再問。同樣地，要求 Smart Friend 超越主要模型提出的問題，並根據 Agent 的軌跡提供任何重要的指導，通常也很有成效，即使主要模型沒有主動詢問。我們發現這種「超範圍（over-scoped）」的 Smart Friend 通常會帶來更有趣的互動。
Smart Friend 實際的運作結果
我們必須坦誠：SWE 1.5 作為這種架構的主要模型，表現還不夠好，無法真正發揮作用。它與 Sonnet 4.5 之間的差距，恰好就在對這種架構至關重要的環節：知道何時升級（escalate）、知道該問什麼。成本和速度的優勢是真實存在的，但品質上限是由主要模型決定的，而主要模型不夠強。SWE 1.6（最近的一個後續版本，在 SWE-bench 上達到了 Opus-4.5 級別的效能）明顯更好，並縮小了足夠多的差距，使得這種模式開始產生回報，但它仍未達到我們想要的程度。我們相當有信心這是一個訓練問題，未來的 SWE 模型將會考慮到這種來回互動進行訓練 [2]。
這種模式真正運作良好且效果顯著的地方，是在前沿模型之間。我們在生產環境中讓 Claude 和 GPT 在這種架構下共同運作了一段時間，它在最棘手的場景中產生了真正的收益。有趣的發現是，Prompt-tuning 的問題與「小模型對大模型」的情況不同。跨前沿模型的溝通，與其說是較弱的模型知道何時詢問較強的模型，不如說是路由到最擅長特定子任務的模型。有些模型除錯能力更好，有些處理視覺推理更好，有些寫測試更好。委派邏輯變成了一個「能力路由器（capability router）」，而不是一個「難度升級器（difficulty escalator）」。
重點總結： 當兩個模型都很強時，Smart-friend 在今天就能運作。要讓它與不對稱的較弱主要模型一起運作（這是能帶來最大解鎖的版本），仍然是一個懸而未決的問題，我們認為這是一個訓練問題。如果你想交流心得，歡迎聯繫我們。
展望未來：更高層次的委派
上述兩種模式共享一個結構：一個寫入者，由其他在周圍貢獻智慧的 Agent 輔助。下一個顯而易見的問題是，這是否能擴展到讓 Agent 擁有更大的範圍，例如一個跨越十個 PR 的產品功能、一個涉及十幾個服務的遷移，或者是一週的工作量而非一個下午。
這在今天的 Devin 中已經實現。一個管理型 Devin 可以將更大的任務拆解成小塊，生成子 Devin 來執行它們，並透過內部的 MCP 協調它們的進度。要讓它感覺連貫，所需要的 Context Engineering 比我們預期的要多。習慣於小範圍委派的管理型 Agent，預設會過於教條，當管理型 Agent 缺乏深度的程式庫 context 時，這會適得其反。Agent 會假設它們與子 Agent 共享狀態，但事實並非如此。跨 Agent 溝通（子 Agent 將訊息寫回給管理型 Agent，以便傳遞給 Agent 團隊中的其他 Agent）不會預設發生，因為模型並未在需要這種溝通的環境中受過訓練。每一個問題都需要專門的工作來修復，我們仍在持續改進這些方面。
那麼非結構化的群體（unstructured swarms）呢？我們認為非結構化群體的方法，即 Agent 之間任意協商的網路，大多是一種干擾。實務上的形態是「Map-Reduce-and-Manage」：管理者拆分工作，子 Agent 執行，管理者進行綜合並回報。讓這類系統感覺像單個 Agent 處理單個任務一樣連貫，是我們 2026 年部分工作重點。
我們今日的認知
所有這些實驗都有一個共同點：多 Agent 系統在「寫入保持單執行緒」且「額外的 Agent 貢獻智慧而非動作」時，效果最好。一個乾淨 context 的審查者能抓到寫入者看不到的 Bug。一個前沿級別的 Smart Friend 能捕捉到較弱主要模型遺漏的細微之處。一個管理者在不碎片化決策的情況下協調子 Agent 的範圍。
目前懸而未決的問題都是溝通問題。較弱的模型如何學習何時升級？子 Agent 如何浮現一個應該改變其兄弟 Agent 工作的發現？如何在不淹沒接收者的情況下在 Agent 之間傳輸 context？你可以透過 Prompting 走得很遠，但我們也預期下一代模型（包括我們自己訓練的模型）將開始縮小這些差距。
我們正朝著一個智慧在軟體開發生命週期的每個階段——規劃、編碼、審查、測試和監控——都被注入的世界邁進。這不是作為一群自主行動者的群體，而是一個能擴展人類品味的協調系統。
歡迎你透過 devin.ai 或 windsurf.com 嘗試我們的工作。如果你有興趣與我們一起探索這些 Agent 構建原則，請聯繫 [email protected]。
[1] 巧合的是，Anthropic 在第二天發布了一篇關於構建多 Agent 研究系統的相關部落格文章。兩篇文章都觸及了 Context Engineering 的類似挑戰，並對「唯讀 Agent 是第一個適用領域」這一點得出了類似的結論。
[2] 最近，Anthropic 發布了一個類似的 Beta 實驗，允許他們的小型模型以同樣的方式呼叫大型模型。至少，這表明「Smart Friend」端的模型在與主要模型溝通時也會變得更好。