Multi-Agent 實測：不會帶團隊，模型幹到死

雷峰網訊 Multi-Agent，就是來讓用戶當皇上的。想必很多人早已習慣睡前把成堆的事情丟給 Agent，讓它跑上一整夜，直到早上自己醒來，看到一份漂亮的交付結果。當然也有很多時候，我們得到的只是一個卡死在凌晨三點的進程，或者不知道從哪步開始，就被幻覺汙染得胡言亂語的上下文。這一點對於複雜任務尤其明顯。而在此類場景中，Multi-Agent 系統因其任務拆解能力和對上下文窗口壓力的緩解，擁有了超越單獨 Agent 的落地能力。話雖如此，一個任務具體如何拆分、各 Agent 的角色如何分配、誰來糾正幻覺以及長流程管理仍然是橫亙在 Multi-Agent 系統面前的考驗。從 CrewAI、AutoGen 到打出三省六部制旗號的 Edict，都在試圖解決這些問題。而我們好奇的是，Multi-Agent 生態經歷了從 2025 年末至今的飛速成長，今天已經發展到了何種程度？在真實的複雜任務場景中，它會作何表現？01Agent Swarm “獨苗”，Kimi K2.6我們選擇了 Kimi K2.6 作為此次的測試模型。即使今天距離這款模型的初次問世已經有了一段時間，它卻仍然有著一眾模型中極為少見的定位，一款針對 Multi-Agent 場景做了針對性優化的模型。官方將其描述為具備 SOTA Coding、Long-Horizon Execution 和 Agent Swarm capabilities 的開源模型。值得注意的是最後一點，300 sub-agents、4000-step coordination 以及 multi-agent swarm orchestration 直接被 Kimi 寫進了官方論文，至今還是止此一份。更能說明問題的是此前 Kimi 官方披露的兩個長程工程案例。K2.6 曾連續運行十幾個小時，通過數千次工具調用優化本地模型推理和金融撮合引擎性能。這些案例共同指向一個判斷，那就是模型不再僅僅負責生成答案，而是開始承擔規劃、執行、調用工具、接受反饋、修正路線並最終交付結果的完整鏈路，這正是 Multi-Agent 系統見長之處。從結構上看，K2.6 採用 1T 級 MoE 架構，每次推理激活約 32B 參數，並支持 256K 上下文窗口。MoE 架構為模型提供了內部“專業化分工”的基礎：面對代碼、推理、工具調用、視覺理解和複雜任務拆解等不同場景時，模型可以通過專家路由機制調動不同能力。而 256K 長上下文，則為長程 Agent 任務提供了關鍵的“工作記憶”，使模型能夠在長鏈路執行中保留任務目標、代碼上下文、工具輸出和多輪迭代歷史。相比單獨 Agent 循環式執行任務，上述底層模型能力外化出的 Agent Swarm 必然會在任務拆解、並行處理和結果合成上有更突出的表現。這種組織能力很難被 Benchmark 體現，但它切實存在。K2.6 討論的不僅是如何讓一款模型更聰明，還在於讓多個子 Agent 圍繞同一個複雜目標協作。事實上，在我們的實測中 K2.6 也確實展現出了類似團隊協作的工作方式。它沒有直接寫代碼，而是先拆解任務、設計 Agent 角色、進行開發，再通過審查、反思和二次迭代，最終在 53 分鐘內生成了一個可運行的瀏覽器版 macOS 原型。這正是我們最關注的問題，即組織能力與智能水平的疊加，如何在複雜任務中為模型性能帶來更大的增益。02 Multi-Agent 實戰測試，把 MacOS 裝進瀏覽器我們為 K2.6 準備了一項非常典型的 Agent Swarm 任務。代碼塊請創建一個精美的、瀏覽器版MacOS系統。請使用多個agent一起完成這項任務，整體遵循“計劃-開發-反思反駁-意見匯-開發”的流程。這項任務的複雜度極高，原因在於 MacOS 的視覺、交互、狀態管理、動效、應用生態、Windows Manager、Menu Bar、Dock 等子系統全部要在瀏覽器中實現，僅靠單 Agent 順序寫代碼，幾乎註定會在半途上下文爆炸。這決定了它天然需要多 Agent 並行協作。一個 Agent 寫基礎架構，另一個 Agent 寫內核，第三個 Agent 寫基礎應用，它們之間必須有清晰的接口契約和風格約定，否則最後拼出來的產物會四分五裂。此外，能否遵循“反思-反駁-彙總-再開發”的循環，也是這項任務隱含的一項考驗。這幾乎等同於 K2.6 所強調的 Multi-Agent Orchestration，即避免多個 Agent 自說自話，而是讓它們彼此質詢、綜合意見、再迭代交付。下面來看看 K2.6 的真實表現。▪ 先搭組織，再寫代碼K2.6 沒有直接進入代碼生成，而是先進入計劃模式，對任務進行了結構化拆解。它首先給出了一份完整的開發計劃，將瀏覽器版 macOS 拆成幾個核心模塊：Desktop 環境、Dock 欄、Menu Bar、Window Manager、內置應用、視覺效果。對於多 Agent 任務而言，最怕的是各個 Agent 各寫各的，最後接口、風格、狀態管理全部錯位。K2.6 在正式開發前，先定義了技術棧、組件目錄、狀態結構和驗證標準，就相當於先搭了一個組織架構。不要說多 Agent 實踐了，有過團隊協作經驗的都知道這一步有多重要。▪ 多 Agent 分工：從開發到審查形成閉環隨後 K2.6 將任務交給六個 Agent 執行，並模擬出清晰的多 Agent 協作流程：1）基礎架構搭建：由 Agent A 負責初始化 Vite、React、TypeScript 項目，配置 Tailwind CSS，並搭建核心狀態管理。2）核心 UI 開發：由 Agent B 負責 Desktop、MenuBar、Dock 和 Window 系統。3）應用開發：由 Agent C 負責 Finder、Safari、Terminal、Settings 等內置應用。4）反思與反駁：由多個 Review Agents 分別從代碼架構、UI/UX、性能優化角度進行審查。5）意見匯聚與改進：將審查意見統一排序，確定修復優先級。6）最終開發迭代：根據審查意見繼續修改代碼，完成測試和優化。這套流程基本覆蓋了真實軟件工程中的幾個關鍵環節，即從設計、開發、審查到修復、驗證的全流程。相比單獨 Agent 一路寫到底，這種更接近團隊協作的流程也更能體現 K2.6 所謂 Agent Swarm 的價值。任務拆解不是簡單地把負責需求拆碎就完事，衡量拆解質量的標準，是模型能否交付一套可協作、可審查、可合併的工作單元拆解方案。▪ 開發階段：遇到失敗後繼續推進在實際開發過程中，K2.6 並非一路順利，但其總能在遇到失敗後找到解決問題的辦法，並繼續推進任務直到完成項目。一個比較典型的例子是，項目初期曾多次出現依賴安裝失敗，報錯包括 npm 網絡連接中斷、安裝命令失敗等。但 K2.6 沒有停在錯誤處，而是調整策略，主動改用新的緩存目錄重新安裝依賴，最終不僅完成了安裝，而且還加裝了各種功能額外依賴。這種報錯和失敗也是真實工程任務的一個環節，甚至可以說是常態，依賴安裝失敗、配置不兼容、文件寫入錯誤、類型報錯、構建失敗都會發生。而 K2.6 的表現顯示，它能在失敗後繼續讀取反饋、調整路徑，並推動任務繼續走下去。▪ 反思與審查：三個 Review Agent 並行指出問題完成首輪開發後，K2.6 進入了“反思與反駁”階段。系統啟動了三個審查 Agent，分別給出了三方面的報告概述。1）代碼架構審查：7 次工具調用，約 30.0k tokens2）UI/UX 體驗審查：32 次工具調用，約 31.2k tokens3）性能優化審查：23 次工具調用，約 30.3k tokens此外令人驚喜的是，三個審查 Agent 對識別出的多類問題，自主劃分出了高優先級和中優先級。這是一種很清醒的工程視角，或者說 K2.6 沒有把審查當成某種形式化的環節，而是意識到它上承開發，下接迭代。將不同審查 Agent 的反饋彙總成優先級列表，意味著二次開發在任務之初就被考慮進了開發進度。▪ 53 分鐘自主完成一個瀏覽器版 macOS 原型在意見彙總後，K2.6 開始執行二次開發。在此次測試任務中，具體內容包括修復了 Tailwind CSS v4 配置問題、修改了 Window 組件、引入 Framer Motion、為窗口添加動畫、修復拖拽事件相關邏輯，以及將部分 emoji 圖標替換為 Lucide React 的 SVG 圖標，使整體視覺風格更加統一。最終 K2.6 完成了項目構建，並生成了一個可運行的瀏覽器版 macOS 原型。打開 http://localhost:5175 ，頁面中已經出現了 macOS 風格的桌面、頂部菜單欄、左側桌面圖標和底部 Dock。這並不是一個靜態 Demo，而是一個具備完整桌面交互結構的瀏覽器版 macOS 原型。分別像使用 MacBook 一樣打開 Finder、Terminal、Safari、VS Code、Settings、Calculator、Notes 等應用，並以不同窗口層級疊放在桌面上。每個窗口都有獨立標題欄和控制按鈕，整體排列符合桌面操作系統的基本邏輯。窗口左上角的紅黃綠控制按鈕、頂部菜單欄和底部 Dock，整體操作方式已經高度接近 macOS 的桌面體驗。到此，可以看出需求中的幾個關鍵工程目標均已得到實現，例如窗口管理系統可用、應用狀態能夠區分、Dock 與應用入口聯動、系統級佈局完整、視覺風格統一。對於一個由 Agent 在不到一小時內完成的前端工程來說，這已經超出了普通代碼補全任務的範疇，更接近一個完整小型應用系統的生成。當然，更關鍵之處在於 K2.6 在這一過程中展現出的 Agent Swarm 能力，並非停留在多個角色分別發言的角色扮演上，相反所有反饋都被落實到了代碼修改中。這既是 Multi-Agent 系統勝任複雜工程任務的原因，也是對於底層模型的考驗。03組織者，模型的新角色Agent 概念興起之初，一種非常簡單的期待是，給大模型加上記憶、工具調用和自主規劃能力，它就能自動完成任何任務。但實踐很快暴露出這一路徑的天花板。對於查詢資料、智能客服、代碼補全等簡單任務，一個 Agent 確實已經足夠。可一旦任務複雜度上升，單獨 Agent 方案對於一次性完成全部流程的傾向，往往註定導致遺漏步驟、邏輯跳躍以及最終的結果質量波動。由此，如何讓多個 Agent 像一個組織一樣協同工作，從而完成單個模型難以穩定完成的複雜任務，成為了催生 Multi-Agent 框架的首要問題。這也是模型層的一塊風向標，底層模型在複雜任務中的組織能力，重要性或許不亞於所謂的智能上限。K2.6 在實測中的表現正體現了這一點，創建瀏覽器版 macOS，並不是讓模型生成一段前端代碼，而是要求它設計一個小型桌面系統：窗口管理、應用狀態、Dock、Menu Bar、Finder、Safari、Terminal、VS Code、設置、計算器和備忘錄都要同時成立。先搭架構，再分工開發，通過審查 Agent 發現問題，最後把反饋迴流到二次開發中，這些環節也都要齊備。有了這些，創建瀏覽器版 macOS 的任務就不能簡單地和代碼補全相提並論，而更像是一次壓縮版的軟件團隊協作。Kimi 官方博客給出的兩個長程工程案例，更能說明這種變化。第一個案例中，K2.6 在本地 Mac 上自主下載並部署 Qwen3.5-0.8B 模型，並用 Zig 語言實現和優化推理。整個過程持續 12 小時以上，累計 4000 多次工具調用，經歷 14 輪迭代，最終將吞吐從約 15 tokens/s 提升至約 193 tokens/s，並比 LM Studio 快約 20%。第二個案例發生在更復雜的系統工程場景中。K2.6 對已有 8 年曆史的開源金融撮合引擎 exchange-core 進行自主改造。官方披露，模型連續執行 13 小時，迭代 12 種優化策略，發起 1000 多次工具調用，修改 4000 多行代碼，並通過分析 CPU 與內存分配火焰圖定位隱藏瓶頸。最終，K2.6 將 exchange-core 的核心線程拓撲從 4ME+2RE 調整為 2ME+1RE，實現中等吞吐提升 185%、性能吞吐提升 133%。這些任務真正的困難之處在於，它們需要模型在一個長程任務中持續讀代碼、跑測試、看 profiling、判斷瓶頸、修改方案，並用最終指標驗證結果。換句話說，模型處理的不是單點的代碼生成，而是工程環境中的持續問題求解。這也是為什麼 K2.6 值得被放在“組織能力”的框架下討論。如果說 Chatbot 時代的模型像一個答題者，Agent 時代是一個執行者，那麼對於 Multi-Agent 來說，模型則更進一步成為組織者。這一點對於開源模型尤為重要。閉源模型可以通過產品形態提供更完整的 Agent 體驗，開源模型的優勢則在於可部署、可改造、可接入企業內部工具鏈。Multi-Agent 場景天然需要和具體業務結合，開源模型因此有機會進入 IDE、CLI、自動化測試、數據分析和企業內部知識系統，成為更靈活的任務執行底座。更大、更快的敘事，已經無法回應 Agent 落地的全部需求。今天的模型更像是專家而非經理，組織能力是一片全新的戰場。K2.6 並沒有終結這場競爭，它只是指出，下一代模型除了思考，還必須成為一個可靠的組織者。補上這份能力的玩家，才有資格爭奪那個更底層的位置。雷峰網文章