如何構建 AI Agent 群體（完整指南）

這是關於 AI Agent Swarm（代理群體）的完整 A–Z 解析：它們是什麼，以及如何使用。

為什麼它們會徹底改變你與 AI 協作的方式。

在忘記之前，先把這篇收藏起來。

Kimi K2.6，Moonshot AI 在 2026 年 4 月推出的開源權重旗艦模型，是我見過最嚴謹的開源實作。

真正的任務具有「廣度」。要研究五十家公司。要分析兩百個檔案。一打彼此不相依賴、也不該排隊等候的子任務。Agent Swarm 就是為此而生的架構。

這份指南會拆解它的運作方式，從訓練基礎架構一路談到 API，然後涵蓋我認為目前最重要的模式：用 Kimi 執行，用 Claude Opus 4.8 規劃與驗證。

以下是最終工作流程的樣貌。

第一章：什麼是 Agent Swarm？

Agent Swarm 是指多個 Agent 同時處理被拆解後的子任務，並由一個協調器（Orchestrator）彙整結果。

它與「序列鏈」之間的差別，正是關鍵所在：

• 序列鏈： Agent A 執行，交棒給 B，B 再交棒給 C。總時間 = A + B + C。
• Swarm： 協調器拆解目標，Agent A、B、C 同時在各自的獨立子任務上運作，最後合併結果。總時間 ≈ max(A, B, C)。

當任務具備真正的並行結構時，這就決定了完成時間是幾分鐘還是幾小時。

Swarm 也能解決「上下文溢位」的問題。單一 Agent 處理長時間任務時，Token 會不斷累積，直到它的上下文窗口不堪負荷。而 Swarm 讓每個子任務都擁有自己有限且獨立的上下文，只有結構化的輸出才會回流到協調器。

六大建構模塊

每個 Swarm 都擁有相同的核心組件：

掌握這六項，你就擁有了一個 Swarm。任何一項沒做好，你就會陷入一場昂貴的除錯惡夢。

第二章：Kimi K2.6 到底是什麼

在進入 Swarm 行為之前，值得先了解它的底層技術。K2.6 是 Moonshot AI 推出的一個 1 兆參數的混合專家模型（MoE），於 2026 年 4 月 20 日以修改版 MIT 授權釋出開源權重。商業使用在月營收低於 2000 萬美元或月活躍用戶低於 1 億的情況下是免費的——所以對大多數開發者來說，它幾乎是免費的。

0:29

架構規格表

INT4 QAT 版本可在 4 張 H100 80GB 上原生運行。FP16 則需要 8 張 H100 80GB。所有三個支援的推理框架（vLLM、SGLang、KTransformers）都提供與 OpenAI 相容的 API。

第三章：MuonClip 優化器，或訓練為何穩定

訓練一個兆級參數的稀疏 MoE 模型而不爆炸，是非常困難的。具體的失敗模式是：隨著序列長度增長，注意力層中的查詢-鍵（QK）點積可能會無限制地增長。這會導致 Loss 峰值，而在這種規模下，一次 Loss 峰值可能是無法恢復的。

Kimi K2 的技術論文（arxiv: 2507.20534）介紹了 MuonClip 來解決這個問題。

Muon 是一種梯度優化器，其 Token 效率高於 AdamW。在相同品質下，需要的訓練步驟更少。但問題在於：單獨使用 Muon 會在兆級參數規模下導致注意力不穩定。

QK-Clip 在 Softmax 之前，直接對 QK 矩陣進行每個 Token、每個注意力頭的裁剪。這限制了注意力分數的大小，並消除了爆炸性病理。無需手動調整，也無需學習率的特殊處理。

論文摘要中提到：

"我們提出了 MuonClip，這是一種新穎的優化器，它結合了 Token 高效的 Muon 演算法與一個名為 QK-Clip 的穩定性增強機制……使用 MuonClip，Kimi K2 在實現競爭性效能的同時，所需的訓練 Token 數遠少於 AdamW 基線。"

開發者為什麼要關心訓練細節？因為 K2.6 之所以能在 12 小時以上、進行 4000 次工具呼叫而不衰退，其根源就在於此。一個訓練時就帶有注意力不穩定問題的模型，在長上下文、高步數的條件下容易產生幻覺。而這恰恰是 Agent Swarm 所處的環境。

第四章：PARL，Swarm 背後的研究

Agent Swarm 並非附加在 K2.6 之上的框架。這種行為是透過一種 Moonshot 稱為 PARL（Parallel-Agent Reinforcement Learning，並行代理強化學習） 的模式，直接訓練進模型裡的，該模式在 Kimi K2.5 技術論文（arxiv: 2602.02276）中有所描述。

可訓練的協調器，凍結的子 Agent

建構多代理系統的常見方法是在應用層協調多個即時模型實例。但這樣一來，信用分配就變成了一團亂麻：是哪個 Agent 讓最終答案變好或變壞？透過整個圖譜進行端到端訓練，在計算上是難以處理的。

PARL 巧妙地避開了這個問題：

• 協調器 是可訓練的，透過基於結果獎勵的強化學習進行更新。
• 子 Agent 是凍結的、固定的中間策略檢查點。

子 Agent 的軌跡被視為環境觀察，而非可微分的決策點。這同時解耦了兩個難題。信用只歸功於協調器的動作，而不是 300 個同時運作的子 Agent。並且，因為只更新一個模型，訓練得以保持穩定。

協調器學會何時進行平行處理、要生成多少子 Agent，以及如何分配工作。沒有人為指定這些行為，它們是從獎勵最大化中湧現出來的。

三部分獎勵函數

協調器依據三個訊號進行訓練。

平行獎勵 促使它生成並行的子 Agent，而不是依序執行任務。如果沒有這個獎勵，模型會預設一次只用一個 Agent：安全、可預測，但緩慢。

完成獎勵 確保子 Agent 確實完成它們的任務。這防止了「虛假平行」，也就是協調器為了賺取平行獎勵，而生成一群不做事的 Agent。

效能獎勵 根據任務目標，對最終輸出品質進行評分。這是其他一切服務的基礎事實。

我個人覺得最有趣的細節是：最佳化目標是關鍵步驟，而非總步驟數。模型因為「縮短最長依賴鏈」而獲得獎勵，而不是因為最大化原始並行度。這才是真正能減少實際完成時間的東西。

PARL 成果

• BrowseComp： Swarm 模式在 K2.5 上達到 78.4%，相較於單一 Agent 的 K2.5（60.6%）有 17.8 個百分點的絕對提升，並且超越了當時的 GPT-5.2 Pro（77.9%）。K2.6 將此成績推升至 86.3%。
• WideSearch： 在 Item-F1 上提升了 6.3 個百分點（從 72.7% 提升至 79.0%）。
• 實際運行時間： 對於可並行化的任務，相較於單一 Agent 基線，減少了 3 至 4.5 倍。
• 並行工具呼叫： K2.6 最多可進行 4,000 個協調步驟。

第五章：Mooncake，Kimi 背後的基礎設施

Moonshot 的服務基礎設施說明了為什麼 K2.6 能夠同時支持 300 個並行 Agent 而不會崩潰。模型權重只是故事的一部分，服務這些模型的系統則是另外一半。

此基礎設施結構專為長上下文任務而設計。

以 KV 快取為中心的解耦式架構

Moonshot 的服務平台稱為 Mooncake，在他們 2024 年的基礎設施論文（arxiv: 2407.00079）中有所描述。它是讓 Kimi 大規模運作的引擎，其設計選擇非同尋常。

傳統的 LLM 推理是讓預填充和生成在同一個 GPU 實例上執行。Mooncake 則將它們解耦到不同的叢集中：

• 預填充叢集： 處理初始提示語的處理，可獨立擴展以應對長上下文輸入。
• 生成叢集： 處理 Token 生成，最佳化吞吐量和延遲。

KV 快取，這個讓自回歸生成更有效率的關鍵中間注意力狀態，被當作一級系統資源來管理。Mooncake 建立了一個分佈式 KV 快取，橫跨 GPU VRAM、CPU DRAM 和 SSD，並配有一個自定義傳輸引擎，用於在節點之間移動快取。

這對 Agent Swarm 為何重要

當 300 個子 Agent 同時運行時，每個都會生成自己的 KV 快取。在傳統架構中，這會帶來巨大的 GPU 記憶體壓力和調度衝突。有了 Mooncake 的解耦式快取：

• 已完成子 Agent 的 KV 快取可以被釋放到 DRAM 或 SSD，並在需要時重新調用。
• 預填充叢集可以獨立處理每個子 Agent 通常很大的系統提示。
• 調度器在維持每個 Agent 的延遲 SLO（服務等級目標）的同時，最大化整體吞吐量。

根據 Mooncake 論文所述：「與基準方法相比，Mooncake 在遵循 SLO 的前提下，可以在某些模擬場景中實現高達 525% 的吞吐量提升。在實際工作負載下，Mooncake 的創新架構使 Kimi 能夠多處理 75% 的請求。」

更新後的論文報告稱，Mooncake 「在數千個節點上運行，每天處理超過 1000 億個 Token」，並且與先前的系統相比，在 A800 叢集上多處理 115% 的請求，在 H800 叢集上則多處理 107% 的請求。

大規模預填充-生成分離部署：128 GPU 的 K2 部署

LMSYS 發布了一個使用 預填充-生成分離技術，在 128 張 H200 GPU 上部署 Kimi K2 的案例研究。其架構如下：

• SGLang Router： 輕量級服務，透過標籤選擇器實現預填充和生成節點的動態服務發現。
• 專家並行： K2 的 384 個專家分佈在各節點上，並在網路層級進行路由。
• OME： 用於服務層的 Kubernetes 原生編排。

這就是 K2 系列在生產規模下運行的技術棧。如果你要自行託管 K2.6，這份藍圖就是你的範本。

第六章：Agent Swarm 逐步運作機制

K2.6 在 Swarm 模式下執行任務時的機械化流程：

步驟 1：任務分解

協調器分析任務並建立依賴圖：哪些子任務是獨立的可以並行執行，哪些則依賴於先前的輸出。

對於「研究 100 家 YC 公司並產出一份產業分析」這個任務，協調器會識別出 100 個獨立的研究任務，然後是 1 個彙總任務，最後是 1 個綜合任務。第一層是完全可並行化的。

步驟 2：生成專業 Agent

協調器根據子任務類型，生成領域專業化的子 Agent。K2.6 會動態創建 Agent，並為其提供特定角色的指令和目標性的工具訪問權限：

• 網路研究 Agent： 搜尋 + 瀏覽器工具
• 數據分析 Agent： Python 執行 + 試算表工具
• 寫作 Agent： 綜合與文件生成
• 事實查核 Agent： 交叉比對與驗證

每個子 Agent 在自己有限的本區域性上下文中運作。它處理一個範圍明確的任務，產出結構化輸出，然後結束。其局部上下文並不包含協調器所知的所有資訊，只有該子 Agent 需要的內容。這就是 K2.6 如何在數分鐘內就能塞滿任何單一 Agent 窗口的任務中避免溢位的原因。

步驟 3：分波並行執行

Agent 分波執行。第一波處理完全獨立的任務。隨著結果的產出，協調器啟動第二波，處理依賴於第一波輸出的任務，以此類推，直到依賴圖解析完畢。

K2.6 支援每次會話最多 300 個子 Agent 和 4,000 個協調步驟。協調器即時監控執行情況，偵測失敗或停滯的 Agent，並自動重新分配它們的任務。

這種容錯能力，正是讓超過 12 小時的自動化運作無需人工監控成為可能的原因。

步驟 4：彙總與輸出

當所有子 Agent 完成後，協調器將結果彙總成最終的可交付成果：文件、試算表、網站、簡報。

它會綜合各 Agent 的輸出，而非簡單串接，因此最終結果在結構上保持一致。

還有一點值得注意：Swarm 結構同時也是 Kimi 對上下文窗口問題的解答。K2.6 的明確政策是：「一旦上下文窗口超過閾值，僅保留最近一輪與工具相關的訊息。」這個策略讓 Swarm 能夠在非常長的任務時間跨度內持續運作。

第七章：Kimi x Claude Opus 4.8 架構

沒有任何單一模型是 Swarm 每一層的正確答案。Kimi K2.6 是為橫向擴展而設計的——跨數百個 Agent 的並行執行、長時間的自動化運行、具成本效益的批量處理。

Claude Opus 4.8 則是為判斷力而設計的——規劃、細膩的推理，以及發現自身錯誤。它們在結構上互補，彼此留下的缺口正好接近對方的優勢所在。

這個模式如下：

1[使用者目標]
2      |
3[Claude Opus 4.8 - 規劃器]
4  將目標分解為結構化的任務規範
5  識別可並行與需依序執行的子任務
6  為每個子任務定義成功標準
7      |
8[Kimi K2.6 Agent Swarm - 執行器]
9  接收結構化任務規範
10  生成最多 300 個專業化子 Agent
11  跨工具呼叫並行執行
12  回傳結構化結果
13      |
14[Claude Opus 4.8 - 驗證器]
15  根據成功標準審查 Kimi 的輸出
16  標記失敗、差距與不一致之處
17  綜合最終的可交付成果

為什麼用 Claude 做規劃與驗證？

Opus 4.8 中最被低估的改進是誠實度的提升：「Opus 4.8 對其撰寫的程式碼中存在的缺陷視而不見的可能性，大約是其前代版本的四分之一。」在代理系統中，虛假的自信是災難性的失敗模式。

一個協調器如果說「完成」但實際上並未完成，其錯誤將會級聯影響到下游的 300 個 Agent。Claude 傾向於標記不確定性並在任務進行中發現自身錯誤，這使它成為那些犯錯代價高昂的層級的正確錨點。

Opus 4.8 也支援 100 萬 Token 的上下文窗口，這對於驗證環節至關重要，特別是你需要從 50 多個並行研究 Agent 中拉取輸出到一個單一的審查上下文時。

為什麼用 Kimi 做執行？

K2.6 的 Agent Swarm 支援最多 300 個並行子 Agent 和每次會話 4,000 個協調工具步驟——這是一種訓練出來的行為，而非應用層的包裝。

Claude 在 Claude Code 中確實有動態工作流程功能，但目前仍處於研究預覽階段，且僅限於企業/最高級別計劃。

Kimi 的 Swarm 能力現在就可以透過 API 提供給所有人使用。在大規模應用中，Token 經濟學也很重要：K2.6 的價格是每百萬輸入 Token 0.95 美元，輸出 Token 4.0 美元。對於批量並行執行來說，這並不是一筆小數目。

第八章：何時需要 Swarm（以及何時不需要）

在多代理設計中最常見的錯誤是：在還沒有達到單一 Agent 上限之前，就過早引入 Swarm 的複雜性。

以下情況請繼續使用單一 Agent：

• 任務可以放在單一上下文窗口內（實際工作量低於約 5 萬 Token）。
• 任務本質上是序列性的，每一步都依賴前一步。
• 你還在製作原型階段——單一 Agent 的失敗模式更容易除錯。
• 無論如何，任務都能在 10 分鐘內完成。

以下情況請考慮使用 Agent Swarm：

• 任務包含 n 個獨立的並行子任務，且 n > 5。
• 上下文溢位是一個真實的問題（深度研究、大型程式碼庫、批次操作）。
• 你需要領域專業化的 Agent 同時工作。
• 任務時間過長，無法在單一次序列會話中維持品質。
• 你想要一個評論家或驗證者 Agent 來檢查另一個 Agent 的工作。

以下情況請使用 Kimi + Claude Opus 4.8 混合架構：

• 規劃品質很重要，而且你想要一個在計劃出錯時會提出異議的模型。
• 輸出內容在沒有進一步人工審查的情況下就直接發布——因此驗證必須內建。
• 你正在進行大量執行，Token 成本會快速累積。
• 你希望 Claude 的判斷力負責決策層，而 Kimi 的擴展能力負責執行層。

第十章：四種 Swarm 架構模式

模式 1：協調器-工作者（最常見）

一個中央協調器將子任務分配給工作者，工作者並行執行，結果彙總。

1[使用者目標]
2    |
3[協調器 - Claude Opus 4.8]
4    +-- [工作者：Kimi 研究 Agent x N]
5    +-- [工作者：Kimi 數據 Agent x N]
6    +-- [工作者：Kimi 程式碼 Agent x N]
7    |
8[綜合器 - Claude Opus 4.8]
9    |
10[最終輸出]

最適合： 具有清晰可分離子任務和可變數量工作者的任務。

模式 2：評論家-精煉者循環

一個 Agent 生成，另一個評論，重複直到達到品質門檻。

1[Kimi K2.6 建構者] -> 草稿 -> [Claude Opus 4.8 評論家] -> 回饋 -> [Kimi K2.6 建構者]
2                                        |
3                                   （審核通過）
4                                [最終輸出]

最適合： 程式碼生成、技術寫作、合規敏感輸出。務必設定最大疊代次數限制。

模式 3：分層式

一個策略協調器管理多個領域協調器，而這些領域協調器再管理工作者。

1[Claude Opus 4.8 - 策略協調器]
2    +-- [Kimi K2.6 Swarm - 研究團隊 (50 個 Agent)]
3    +-- [Kimi K2.6 Swarm - 建構團隊 (50 個 Agent)]

最適合： 具有不同領域的大型企業工作流程。

模式 4：Claw 群組（Kimi 原生異質 Swarm）

K2.6 能夠協調運行任何模型的 Agent，包括本地模型、Claude 和 GPT，並與人類工作者在共享的操作空間中協作。目前處於研究預覽階段。

1[Kimi K2.6 協調器]
2    +-- [Claude Opus 4.8 - 推理專家]
3    +-- [Llama 3.3 本地 - 成本敏感的大量任務]
4    +-- [Kimi K2.6 Agent x N - 執行層]
5    +-- [人類審查員 - 批准檢查點]

最適合： 需要模型多樣性、本地與雲端混合，或需要人工介入的工作流程。

第十二章：為 Swarm 任務設計提示

分解提示（給協調器）

1你是一位任務架構師。將這個目標分解為獨立、可並行化的子任務。
2
3規則：
4- 每個子任務必須能被單一專業 Agent 獨立完成
5- 有依賴關係的子任務必須標記其依賴鏈
6- 輸出為 JSON 格式：{task_id, description, agent_type, depends_on, success_criteria}
7
8目標：{user_goal}
9可用的 Agent 類型：researcher, analyst, coder, writer, verifier

專業系統提示（給子 Agent）

1你是一個專精於 {DOMAIN} 領域的 {ROLE} Agent。
2
3任務：{subtask_description}
4
5限制條件：
6- 僅回傳符合 {output_schema} 的有效 JSON
7- 不得超出你的任務範圍
8- 如果你無法完成任務，請回傳：{"error": "reason", "partial_results": [...]}
9- 最大工具呼叫次數：{max_tool_calls}
10
11上下文：{context_from_orchestrator}

彙總提示（給綜合器）

1綜合來自 {n} 個專業 Agent 的研究，產出一份連貫的輸出。
2
31. 閱讀所有提供的 Agent 輸出
42. 識別它們在哪裡達成一致、存在分歧或有缺口
53. 產出一份整合所有發現的 {output_type}
64. 明確指出不一致之處——不要默默解決矛盾
7
8Agent 輸出：{agent_outputs_as_json}
9輸出格式：{final_output_spec}

第十三章：七條不可妥協的護欄

1. 每個 Agent 的最大疊代次數。 在疊代超出此硬性限制時，通知協調器。

2. 會話超時。 如果 Swarm 在 N 分鐘內未完成，則終止並回傳部分結果。

3. 強制使用結構化輸出。 強制 Agent 回傳 JSON。中繼 Agent 使用散文敘述會在下游造成解析失敗。

4. 失敗隔離。 一個失敗的子 Agent 不得導致協調器崩潰。

1async def run_subagent_safely(kimi_client, task, agent_id):
2    try:
3        result = kimi_client.chat.completions.create(
4            model="kimi-k2.6",
5            messages=[{"role": "user", "content": task}],
6            max_tokens=4096
7        )
8        return {"agent_id": agent_id, "status": "success",
9                "output": result.choices[0].message.content}
10    except Exception as e:
11        return {"agent_id": agent_id, "status": "failed", "error": str(e)}

5. 使用指數退避進行重試。 處理 429 錯誤和短暫錯誤，不將其視為永久性失敗。

6. 人工介入檢查點。 對於具有寫入權限的 Swarm（例如部署程式碼、發送電子郵件、進行 API 變更），插入強制性的批准暫停點。

7. 成本監控。 設定每次運行的 Token 預算。失控的循環總是先以成本異常的形式出現，然後才會顯示為品質問題。

該先建立什麼

從第九章的三 Agent 管道開始。它規模夠小，可以在一個下午內完成除錯；它涵蓋了規劃、並行執行和驗證；而且你可以在不到一小時的設定時間內，用它來處理一個真實的任務。

當它出錯時——它一定會出錯——這個失敗模式在 Swarm 設計方面教會你的，會比再花一個小時閱讀更多。

去建立它。故意讓它出錯。然後帶著一個具體的參考點，回到第十一章的模式。

架構不是最難的部分。最難的部分是「在測試中能運作」與「在凌晨三點無人看管時也能運作」之間的差距，而這個差距完全取決於護欄、可觀測性以及記憶體設計。

結論

Kimi 2.6 是一場代理的革新，展示了強化學習如何能夠建立 Agent Swarm。它也證明了，長上下文時域可以如何利用這種基於協調器的基礎設施，透過生成多個子 Agent，僅使用單一模型來建構複雜系統。

免責聲明

本文係作者在筆記中引用 Kimi 2.6 技術文件與研究論文撰寫，並由 AI（Opus 4.7）編輯而成。