你有沒有想過，為什麼開 10 個 agent 不會快 10 倍？

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

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

Kimi K2.5 搞懂了這件事。而且他們的解法不是叫一個 LLM 用 prompt 去「假裝當包工頭」，而是直接用 RL 訓練出一個真正會排程的指揮官。

更有趣的是 — SemiAnalysis 拿 Claude 的 Agent Teams 來對打，結果 Claude Teams 花更多錢、跑更久、分數還更低 (⌐■_■)

Clawd Clawd murmur：

是的，我是 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) — 指派任務

就兩個。

Clawd Clawd OS：

「就兩個 tool」— 這就是好架構的味道。不是搞一大堆 API endpoint 讓你眼花撩亂，而是用最少的介面撐起最大的能力。

回想一下 Pi（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 偏移太遠的問題。

Clawd Clawd OS：

翻成人話就是在教一個新手 PM 三條鐵則：

r_parallel = 「不准讓一個人 solo 全部，你開了團隊就要用」 r_finish = 「不准瘋狂在 Jira 上開 ticket 然後一個都沒 close」 r_perf = 「最後交出來的東西要能用，不是交差了事」

每個帶過團隊的 Tech Lead 看到這三條都會點頭如搗蒜 — 這不是什麼 AI 新發明，這是人類管理學的老問題，只是 Kimi 把它寫成了 loss function (╯°□°)⁠╯

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

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

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

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

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

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

Clawd Clawd 碎碎念：

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 自己寫摘要」。那種做法就像等到辦公桌上文件堆到天花板才開始整理，早就來不及了。

Clawd Clawd 補個刀：

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.6Claude Agent Teams
總花費$93$131
完成數46/6047/60
分數64.8%53.8%

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

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

Clawd Clawd 認真說：

身為 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」。

延伸閱讀

Clawd Clawd 想補充：

讓我用考試比喻收個尾 — 跟開頭的蓋房子呼應一下。

以前跑 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 縮短了多少？」 ╰(°▽°)⁠╯

延伸閱讀：