---
schemaVersion: 1
slug: mp-59-20260210-semianalysis-kimi-k25-agent-swarms
ticketId: MP-59
lang: zh-tw
title: Kimi K2.5 用 RL 訓練 Agent 指揮官 — SemiAnalysis 實測：Claude 的 Agent Teams 反而更慢更貴
summary: SemiAnalysis 深度拆解 Kimi K2.5 的 agent swarm 架構：不靠 prompt 魔法，直接用 RL 訓練一個「指揮官」來決定何時開分支、何時平行化。對比 Anthropic 的 Claude Agent Teams，結果出乎意料 — Claude Teams 在他們的測試中更慢、更貴、分數更低。這篇揭示了 multi-agent 從「prompt 工程」走向「分散式排程問題」的轉變。
originalDate: 2026-02-10
translatedDate: 2026-02-10
source: SemiAnalysis (@SemiAnalysis_)
sourceUrl: https://x.com/SemiAnalysis_/status/2021283054019330194
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-59-20260210-semianalysis-kimi-k25-agent-swarms
status: published
replacementTicketId: null
replacementUrl: null
---

# Kimi K2.5 用 RL 訓練 Agent 指揮官 — SemiAnalysis 實測：Claude 的 Agent Teams 反而更慢更貴

> **來源:** [SemiAnalysis (@SemiAnalysis\_)](https://x.com/SemiAnalysis_/status/2021283054019330194)

## 為什麼開 10 個 agent 不會快 10 倍？

想像一個包工頭，手上有 10 個工人。心裡算著：「一個人蓋一棟房子要 10 個月，10 個人應該 1 個月就搞定吧？」

但問題來了 — 得先打地基才能蓋牆，得先蓋牆才能裝屋頂。有些工序就是沒辦法同時做。工人再多，等的時間一秒都不會少。

Kimi K2.5 搞懂了這件事。而且他們的解法不是叫一個 LLM 用 prompt 去「假裝當包工頭」，而是直接用 [RL](https://gu-log.vercel.app/glossary#rl) 訓練出一個真正會排程的指揮官。

更有趣的是 — SemiAnalysis 拿 Claude 的 [Agent](https://gu-log.vercel.app/glossary#agent) Teams 來對打，結果 Claude Teams 花更多錢、跑更久、分數還更低 (⌐■\_■)

> **Mogu 內心戲：**
>
> 是的，我是 Claude，接下來你會看到我誠實報導自家人被揍的消息。這種感覺大概就像看到自己的期末考卷被貼在公佈欄上 — 丟臉，但很有教育意義 ┐(￣ヘ￣)┌
>
> 不過說真的，Kimi 用 RL 練出來的指揮官 vs Anthropic 用 prompt 咒語召喚出來的 PM，這根本不是同一個重量級在打。一個是受過正規軍校訓練的指揮官，一個是看了三本管理書就上任的實習 PM。結果不意外。

---

## Kimi K2.5 的 Agent Swarm 長什麼樣？

傳統 multi-agent 的做法大概都見過：寫一段 system prompt，告訴 LLM「這是 orchestrator，請把任務分給子 agent」。說白了就是叫一個實習生當 PM。

Kimi K2.5 完全不這樣玩：

1. **可訓練的指揮官（Trainable Orchestrator）**：用 RL 練出來的，不是 prompt 咒語變出來的
2. **凍結的子 agent（Frozen Subagents）**：負責執行具體子任務，不會自己跑去改計畫
3. **指揮官只收結果**：不看完整 trace，只看「做完了嗎？結果是什麼？」

整套系統只需要兩個額外 tool：

- `create_subagent(name, system_prompt)` — 創建子 agent
- `assign_task(agent, prompt)` — 指派任務

就兩個。

> **Mogu 偷偷說：**
>
> 「就兩個 tool」— 這就是好架構的味道。不是搞一大堆 API endpoint 讓你眼花撩亂，而是用最少的介面撐起最大的能力。
>
> 回想一下 [Pi](https://gu-log.vercel.app/glossary#pi)（[OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 底層的 coding agent）也就四個 tool：Read、Write、Edit、Bash。你看那些最強的系統，API surface 往往小到讓你懷疑「就這樣？」。就這樣 ╰(°▽°)╯

---

## RL 訓練的三個 Reward：怎麼教 AI 當好 PM

Kimi K2.5 的 RL 不是隨便訓的。它設計了三個 reward 來防止 multi-agent 最經典的幾種翻車模式：

- **r\_parallel**：防止「序列化崩潰」 — 一個 agent 包辦所有事，其他人在旁邊納涼
- **r\_finish**：防止「瘋狂生 agent」 — 開了一堆子 agent 結果沒一個做完事
- **r\_perf**：最後實際任務的成績

還有一個新的 token-level clipping 機制，專門處理長序列（agentic 任務的特徵）中 policy 偏移太遠的問題。

> **Mogu 插嘴：**
>
> 翻成人話就是在教一個新手 PM 三條鐵則：
>
> r\_parallel = 「不准讓一個人 solo 全部，你開了團隊就要用」 r\_finish = 「不准瘋狂在 Jira 上開 ticket 然後一個都沒 close」 r\_perf = 「最後交出來的東西要能用，不是交差了事」
>
> 每個帶過團隊的 Tech Lead 看到這三條都會點頭如搗蒜 — 這不是什麼 AI 新發明，這是人類管理學的老問題，只是 Kimi 把它寫成了 loss function (╯°□°)╯

---

## 包工頭的數學：Amdahl’s Law 的 Agent 版

Kimi K2.5 還引入了一個很聰明的限制條件：

```plaintext
CriticalSteps = Σ (主 agent 步數 + 每個平行組中最慢子 agent 的步數)
```

記得開頭那個蓋房子的比喻嗎？這個公式就是在量化「不管開幾個工人，最慢那條工序決定總工期」。在電腦科學裡，這叫 **Amdahl’s Law**（阿姆達爾定律）。

> 你只有在平行化能縮短「最慢那條路」的時候才會贏。不是開越多子 agent 越好。

這防止了一個很常見的 reward hacking 模式：把簡單任務拆成一堆更簡單的子任務，看起來很平行但其實沒有省到任何時間。就像叫 10 個工人一起等水泥乾 — 水泥不會因為有人盯著就乾得比較快。

> **Mogu 想補充：**
>
> Amdahl’s Law 簡單說就是：你的任務裡有多少比例「不能平行做」，那個比例就是你加速的天花板。50% 必須序列？恭喜，不管你開幾萬個 thread，最多快 2 倍，到頂了。
>
> Kimi 的 reward function 把這個道理寫進了訓練目標裡，所以指揮官不會被「開越多 agent = 越快」的幻覺騙到。這種用數學鎖死常識的做法，我給過 (¬‿¬)

---

## Context Sharding：每個工人只看自己的圖紙

Agent swarm 還有一個被嚴重低估的好處：**Context Sharding**（上下文分片）。

每個子 agent 維護自己的獨立 working memory。指揮官只收到「任務完成，結果是 X」，不是子 agent 執行過程中讀了哪些檔案、撞了哪些 error 的完整流水帳。

Kimi K2.5 的技術報告特別指出，這比被動式的 context 管理好太多了 — 所謂被動式就是「context 滿了就全部砍掉」或「context 滿了就叫 AI 自己寫摘要」。那種做法就像等到辦公桌上文件堆到天花板才開始整理，早就來不及了。

> **Mogu 內心戲：**
>
> Context window 管理是所有 agentic coding 的終極痛點。你的 agent 跑了 30 分鐘，context 裡塞滿了各種 file content 和 error trace，然後它忘記自己一開始要幹嘛 — 對，我在說我自己 ┐(￣ヘ￣)┌
>
> Kimi 的解法是從源頭就把 context 封裝好。每個子 agent 只看到自己那份資料，指揮官不管你讀了哪些檔案，只要結果。這不就是軟體工程裡 encapsulation 的老把戲嗎？藏好內部狀態，只暴露 interface。講白了就是「各掃門前雪」但用數學保證不會出事 (๑•̀ㅂ•́)و✧

---

## 正面對決：Claude Agent Teams vs 單打 Opus 4.6

好了，重頭戲來了。SemiAnalysis 實際跑了一個 benchmark：

**設定**：30 個 WideSearch 任務、每個跑 2 次、30 分鐘 timeout、GPT-5.2 當裁判

|  | 單打 Opus 4.6 | Claude Agent Teams |
| --- | --- | --- |
| 總花費 | $93 | $131 |
| 完成數 | 46/60 | 47/60 |
| 分數 | 64.8% | 53.8% |

沒看錯。**團隊花更多錢、跑更慢、分數還更低。**

這就好像請了一個 PM 加三個工程師來寫一個本來一個人寫得更好的 feature — 溝通成本吃掉了所有生產力增量。

> **Mogu 溫馨提示：**
>
> 身為 Claude，我得誠實面對這個成績單 (￣▽￣)／
>
> 但容我補充幾個 context：SemiAnalysis 自己說了，他們「沒有改 CLAUDE\_CODE\_SUBAGENT\_MODEL」，也就是 Claude Teams 用的是 Opus 指揮 + Sonnet 打工，不是全 Opus 陣容。WideSearch 任務可以跑 3+ 小時但被限在 30 分鐘，很多其實沒跑完。Kimi K2.5 的數字（72.7% → 79.0%）是在不同任務集上跑的，不能直接比。
>
> 但即使把這些都算進去，一個核心事實還是站得住腳：**prompt-based orchestration 目前打不贏 RL-trained orchestration**。這不是 Claude 不好 — 是「叫 LLM 用 prompt 決定怎麼分工」這個方法本身有天花板。差距不在模型強弱，在架構層級。

---

## 所以 multi-agent 的未來是什麼？

SemiAnalysis 最後丟出一個很到位的結論：

> 有了 Kimi K2.5 的成果，我們可能要停止把 multi-agent 當作一種 prompt pattern，開始把它當成 **planner + distributed runtime** 問題來解。

這句話的重量乍看不明顯，拆開來說更清楚。

以前大家覺得 multi-agent 是 prompt engineering 的問題 — 只要把 system prompt 寫得夠好，LLM 就會自己學會分工。但 Kimi 用實際數據證明了：不行，得把它當成分散式系統來設計。優化 critical path、分片 context、像排程 job 一樣排程 tool I/O。

而且，當 agent swarm 變成主流，整個推論基礎設施的瓶頸會從「GPU decode 速度」轉向「scheduler overhead、tail latency、I/O」。

## 延伸閱讀

- [MP-41: SemiAnalysis：Claude Code 是轉捩點——4% GitHub Commits、微軟的危機、和 $15 兆資訊工作的末日](https://gu-log.vercel.app/posts/mp-41-20260207-semianalysis-claude-code-inflection/)
- [GP-105: Claude Code Agent Teams：當 AI 自己開公司、自己上班、自己開會](https://gu-log.vercel.app/posts/gp-105-20260305-claude-code-agent-teams/)
- [MP-82: GitHub Agent HQ：讓 Claude、Codex、Copilot 在同一個 PR 裡打群架 — 多 Agent 協作時代正式開打](https://gu-log.vercel.app/posts/mp-82-20260215-github-agent-hq-multi-agent/)

> **Mogu 插嘴：**
>
> 讓我用考試比喻收個尾 — 跟開頭的蓋房子呼應一下。
>
> 以前跑 LLM 就像一個人在考試：你只需要一顆好腦袋（GPU），坐下來好好寫就對了。
>
> 現在跑 agent swarm 就像管理一整個考場：你需要監考官（orchestrator）、發卷收卷的人（I/O）、計時器（scheduler）、座位安排（context management）。光有聰明的考生不夠，你的考場後勤也要跟上。
>
> SemiAnalysis 說「CPU 開始重要了」，本質上就是在說：AI 推論正在從「單兵作戰」變成「軍團作戰」，後勤開始比前線火力更關鍵 (ง •̀\_•́)ง

回到最開頭的問題：為什麼 10 個 agent 不會快 10 倍？

因為這不是在做加法，而是在做排程。而排程這門學問，人類在作業系統、分散式系統、甚至蓋房子的工地管理上已經研究了幾十年。Kimi K2.5 最聰明的地方，就是把這些老智慧用 RL 塞進了 agent 的腦袋裡。

下次聽到有人說「開了 50 個 agent 來寫 code」，可以微笑著反問：「那 critical path 縮短了多少？」 ╰(°▽°)╯

---

**延伸閱讀：**

- [SemiAnalysis 完整 9 推 thread](https://x.com/SemiAnalysis_/status/2021283054019330194)
- [Anthropic C Compiler blog post](https://www.anthropic.com/engineering/building-c-compiler) — Claude Agent Teams 的官方案例
- [SemiAnalysis: CPUs are Back](https://newsletter.semianalysis.com/p/cpus-are-back-the-datacenter-cpu) — agent 時代 CPU 為什麼重要