跳至主要內容
EMil Wu
EN

#07

Agent Team：當 Subagent 不夠用時

技術框架 4 分鐘閱讀
目錄
對比圖：左邊主管派發任務給各自隔離的承包商，右邊五人圍坐圓桌協同合作 對比圖：左邊主管派發任務給各自隔離的承包商，右邊五人圍坐圓桌協同合作
從「派遣」到「協作」— Subagent 與 Agent Team 的本質差異

前六篇我們從 Model ≠ Runtime 一路走到 Skill + Subagent 的組合模式。在這個過程中，有一件事情正在發生：Skill 不再只屬於某一家。

2025 年底，Anthropic 把 Agent Skills 規格開放為開放標準 [4]。OpenAI 的 Codex CLI 採用了同一格式。同一時間，Anthropic 把 MCP 捐贈給 Linux Foundation 的 Agentic AI Foundation，OpenAI 跟 Block 成為共同創辦者。

回到第四篇的預測：Skill 生態系競爭已經開始了。 但走的方向不是碎片化，而是標準化。Tool 層有 MCP，Skill 層開始有共通格式。這代表第四篇講的「誰先建立 Skill 生態系，誰就佔優勢」正在成真 — 只是方式不是各家各做，而是大家搶著定義標準。

但標準化解決的是知識的可攜性。當任務本身需要的不只是知識，而是 多個 Agent 之間的協作 時，我們碰到了一個新的架構問題。

Subagent 的天花板：hub-and-spoke

第六篇結尾我們提到，Subagent 的模式是一對一的：主 Agent 派出去，Subagent 做完回來。所有溝通都經過 parent [5]。

graph TD M["Main Agent"] A["Sub A"] B["Sub B"] C["Sub C"] M --> A M --> B M --> C A -- "回報" --> M B -- "回報" --> M C -- "回報" --> M
Hub-and-spoke 模式：所有溝通必須經過 Main Agent

這個模式在大部分情況下夠用。但有一種場景它處理不了：

Sub A 發現了一個關鍵事實，這個事實會改變 Sub B 的研究方向。

在 hub-and-spoke 模式下，A 必須先回報給 Main，Main 再決定要不要通知 B。但 Main 的 Context Window 已經在處理 A、B、C 三個 Subagent 的回報了 [6]，他可能根本沒注意到 A 的發現對 B 有影響。

官方文件寫得很明確 [1]：

Subagents cannot spawn other subagents.

Subagent 之間沒有通訊管道，不能互相發訊息，每一個都是獨立隔離的。當你需要的不是「派人去做事」，而是「讓人一起合作」，Subagent 就碰到極限了。

Agent Team：從 hub-and-spoke 到 mesh

2026 年 2 月，Anthropic 推出了 Agent Teams [1]（目前是 experimental 功能）。它解決的就是 Subagent 間無法協作的問題。

用比喻來說：Subagent 是你派出去的 專案外包商 — 給他一個任務，做完回來交報告。Agent Team 是你的 專案團隊 — 成員之間會開會、互相更新進度、根據彼此的發現調整方向。

但要注意一件事：Agent Team 不是「共享 Context Window」。

對比：上方主管派承包商各自帶工具箱離開（Subagent 模式），下方專案團隊共同指著白板協作（Agent Team 模式） 對比：上方主管派承包商各自帶工具箱離開（Subagent 模式），下方專案團隊共同指著白板協作（Agent Team 模式）
承包商各做各的，專案團隊彼此協調 — 兩種根本不同的工作方式

用 Context 流向來理解三者

第五篇我們用 Context 流向來區分 Skill 跟 Subagent。同一個框架可以直接套到 Agent Team 上，把三者放在一起看：

Skill — Context 共存

graph TD subgraph WIN["Main Agent Context Window（一個 Window，越來越擠）"] SP["System Prompt"] SK["Skill 知識（載入後留在這裡）"] HIS["對話歷史"] MID["任務中間狀態"] end
Skill：知識直接住在 Main Context，互動即時但 Context 越擠越滿

一個 Context Window，知識直接住在裡面。好處是互動即時，代價是 Context 越來越擠。

Subagent — Context 隔離，單向回報

graph LR subgraph MAIN["Main Context"] SUM["摘要"] end subgraph SUB["Sub Context（隔離）"] MID["大量中間過程"] end SUB -- "單向回報" --> MAIN
Subagent：Context 完全隔離，做完後單向回傳摘要

兩個 Context Window，完全隔離。Subagent 做完後，單向回傳摘要給 parent。Parent 看不到中間過程，Subagent 之間也看不到彼此。

Agent Team — Context 隔離，但有通訊管道

graph TD subgraph A["Agent A Context（隔離）"] AC["思考過程 A"] end subgraph B["Agent B Context（隔離）"] BC["思考過程 B"] end STL["Shared Task List
（狀態共享，不是 Context 共享）"] A <-- "mailbox（精簡訊息）" --> B A <--> STL B <--> STL
Agent Team：隔離的思考，連通的溝通，共享的狀態

每個 teammate 仍然有自己獨立的 Context Window — 這一點跟 Subagent 一樣，Context 是隔離的。但差異在於多了兩個東西：

Mailbox（雙向訊息通道）：teammate 之間可以直接發訊息，不需要經過 parent。但注意，這不是把整個 Context 丟給對方 — 而是發 精簡的結構化訊息。本質上跟 Subagent Return Contract 的思路一樣（探索深入，傳遞淺層），只是方向從單向變成了雙向。

Shared Task List（狀態共享）：所有 teammate 可以看到同一份任務清單 — 誰在做什麼、什麼已完成、什麼還沒認領。這不是 Context 共享，是 狀態共享。每個 agent 的思考過程還是在自己的 Context Window 裡，但透過 task list 知道整體進度。

所以 Agent Team 的 Context 架構可以這樣理解：

隔離的思考，連通的溝通，共享的狀態。

三層架構示意：上層三個各自獨立的玻璃罐（隔離的思考），中層錫罐電話串線連接（mailbox 通訊），下層一本共享筆記本（shared task list） 三層架構示意：上層三個各自獨立的玻璃罐（隔離的思考），中層錫罐電話串線連接（mailbox 通訊），下層一本共享筆記本（shared task list）
Context 各自隔離，訊息雙向流通，狀態統一共享

跟 Subagent 比，Agent Team 不是「打破隔離」，而是「在隔離的基礎上，加了通訊管道跟協調層」。Context 沒有變大，而是資訊的流動方式變了。

但 Agent Team 很貴

通訊管道跟協調層不是免費的。每一則 mailbox 訊息、每一次 task list 更新，都是 Token。

Anthropic 的研究數據 [2]：

  • Agent 模式的 Token 消耗約 4 倍於普通對話
  • Multi-Agent 系統約 15 倍於普通對話
  • 實際案例 [3]：16 個 agent 合作蓋一個 C compiler，API 成本 $20,000
Loading chart…
16 個 Agent 合作蓋 C compiler 的 API 成本高達 $20,000

15 倍不是小數字。如果一個 Subagent 任務花 $0.10，同樣的工作用 Agent Team 可能花 $1.50。這不是說 Agent Team 不好用，而是你必須問自己：這個任務真的需要 Agent 之間互相溝通嗎？

大部分任務不需要。大部分任務用一個 Agent + 好的 Skill 就夠了（第二篇 Anthropic 的建議）。需要隔離時用 Subagent。只有當任務真的需要多個 Agent 互相協作、結果互相依賴時，才值得開 Agent Team。

完整的決策光譜

把七篇文章的所有工具排在一起：

Skill (inline)  →  Subagent  →  Agent Team
成本：低              中            高（15x）
Context：共存         隔離          隔離 + 通訊管道
互動：即時            單向回報      雙向訊息
協調：無              parent 管理   shared task list
適用：知識載入        獨立任務      需要協作的複雜任務
Loading chart…
沒有「越右邊越好」— 每種架構在不同維度上各有優勢

這不是一條「越右邊越好」的光譜。每一個位置都有它最適合的場景，選錯位置付出的代價不是「不夠好」，而是「花了不該花的錢」或「塞爆了不該塞的 Context」。

從第一篇到第七篇

回顧一下我們走過的路：

  1. Model ≠ Runtime — Skill 活在 Runtime，不是 Model
  2. 五層架構 — Command → Agent → Tool + Skill → Context
  3. Context Engineering — JIT、Token 預算、Progressive Disclosure
  4. Skill 生態系 — 競爭從 Model 轉向 Skill，而且正在標準化
  5. Skill vs Subagent — 核心區分是 Context 流向
  6. 組合模式 — 拆階段、fork、preload，加上成本考量
  7. Agent Team — 隔離的思考，連通的溝通，共享的狀態
七篇文章旅程地圖：從左下到右上的蜿蜒小徑，標有 7 個路標，分別對應每篇文章的核心概念 七篇文章旅程地圖：從左下到右上的蜿蜒小徑，標有 7 個路標，分別對應每篇文章的核心概念
從 Model ≠ Runtime 到 Agent Team — 七篇文章走過的 Context Engineering 之路

貫穿這七篇的主線其實只有一件事：所有決策最終都回到 Context 管理跟成本控制。

最後想說的

寫到這裡，你可能會覺得有一套「正確答案」— 什麼場景用 Skill，什麼場景用 Subagent，什麼場景開 Agent Team。但實務上沒有標準答案。

我們一直在兩件事之間拉扯：

Cost 跟 Performance。

台灣人最喜歡講的 CP 值，在 AI Agent 的世界裡一樣適用。隔離一個 Subagent 能保護 Context，但要花更多 Token。開一個 Agent Team 能讓 Agent 協作，但成本是 15 倍。每一個架構決策背後，都是一筆 CP 值的帳。

同時我們也在 Theory 跟 Practice 之間徘徊。這七篇文章建立了很多原則 — Context 流向、Progressive Disclosure、Subagent Return Contract。這些原則在大部分時候是對的，但它們不是教條。

Skill、Subagent、Agent Team，沒有一個是絕對正確或絕對錯誤的選擇。當你真的在解決問題時，理論是為實用服務的。原則可以打破，但打破的時候，你要清楚知道自己願意付出的 Cost/Performance 比例是多少。

所以當你開始建立你的 AI 團隊時，不要問「哪個架構最正確」，而是問：

在我的限制條件下，這個選擇的 CP 值夠不夠高？

這才是 AI Agent 架構的本質 — 跟所有工程一樣，在限制條件下，做最好的取捨。

參考資料

[1] Anthropic: “Orchestrate Teams of Claude Code Sessions” — 官方對照表：Subagent 只回報給主 Agent；Agent Team 的成員可以直接互傳訊息 https://code.claude.com/docs/en/agent-teams

[2] Anthropic: “How We Built Our Multi-Agent Research System” — “multi-agent systems use about 15x more tokens than chats”；Lead agent 無法引導 subagent、subagent 無法協調 https://www.anthropic.com/engineering/multi-agent-research-system

[3] Anthropic Engineering: “Building a C Compiler with Parallel Claudes” — 16 個 agent 合作建構 C compiler 的實際案例與成本數據 https://www.anthropic.com/engineering/building-c-compiler

[4] SiliconANGLE: “Anthropic Makes Agent Skills an Open Standard” — 報導 Anthropic 開放 Agent Skills 規格 https://siliconangle.com/2025/12/18/anthropic-makes-agent-skills-open-standard/

[5] LangChain: “Choosing the Right Multi-Agent Architecture” — Supervisor pattern（等同 subagent）中通訊只能經過 supervisor https://blog.langchain.com/choosing-the-right-multi-agent-architecture/

[6] Factory.ai: “The Context Window Problem” — Enterprise monorepos 仍然超過 1M token window；naive “stuff everything” 方式不可靠且成本過高 https://factory.ai/news/context-window-problem

支持這個系列

如果這系列文章對你有幫助，考慮請我喝杯咖啡