Skill 跟 Subagent 到底差在哪？

前四篇我們建立了完整的 AI Agent 框架：

1. Model ≠ Runtime：Skill 活在 Runtime 裡
2. 五層架構：Command → Agent → Tool + Skill → Context
3. Context Engineering 是地基：JIT、Token 預算、Progressive Disclosure
4. 未來競爭在 Skill 生態系

現在，我們開始來聊聊 Agent 跟 SubAgent，因為當你真的開始建 Agent 系統時，你遇到的第一個問題就是：

這個技能/工具，我該包成 Skill 還是 Subagent？

大部分人的直覺是看「這個工具有多複雜」— 簡單的包 Skill，複雜的包 Subagent，但這個直覺不太準確，因為複雜度不是關鍵，Context 才是 (對，又是 Context)

他們不在同一層

很多人會把 Skill 跟 Subagent 放在同一個光譜上，覺得 Subagent 就是「更強版的 Skill」，但回到第二篇的五層架構：

Command → Agent → [Tool + Skill] → Context

Skill 是 Agent 旁邊的知識層，它告訴 Agent「怎麼思考」，而 Subagent 是 另一個 Agent，他有自己的 Context Window、自己的工具、自己的權限。

Main Agent
├── Tool（執行動作）
├── Skill（提供知識）
└── Subagent（獨立的 Agent，有自己的一切）
      ├── Tool
      ├── Skill
      └── Context（完全隔離）

• Skill → 知識模組，載入主 Agent 的 Context
• Subagent → 獨立執行者，有自己的 Context

這個差異看起來很微小，但它決定了整個系統的 Context 流向。

Context 流向才是關鍵

第三篇我們講過：每一個不必要的 token，都在主動降低系統表現。 把這個觀點套到 Skill 跟 Subagent 上：

用 Skill 時：

Skill 透過 Progressive Disclosure 控制載入量，但一旦載入，它就留在主 Context 裡， 任務過程中的中間輸出，也就是產出，全部都會累積在主 Context Window。

用 Subagent 時：

如果你遵循第三篇講的 Subagent Return Contract：探索深入，回傳淺層 策略，Subagent 的中間過程會留在自己的 Context Window 裡，只有主 Agent 需要的資訊摘要回到主 Agent，

所以選擇 Skill 還是 Subagent，本質上在回答一個問題：

這個任務的中間過程資訊，對主對話有沒有價值？

有 → 留在主 Context → Skill 沒有 → 隔離掉，只拿結果 → Subagent

但界線正在模糊

上面的區分在概念上很乾淨，但實際上 Skill 的能力正在擴張。2025 年底 Anthropic 推出了 Skills 2.0，Skill 現在可以：

• 用 context: fork 把自己丟進 Subagent 的隔離環境裡跑
• 用 allowed-tools 限制可用工具
• 用 model 覆寫使用的模型

換句話說，一個 Skill 現在可以自己變成一個 Subagent 的配置。 這代表 Skill 不再只是「靜態知識」，他可以是一個完整的 agent 設定檔。

那這樣 Skill 跟 Subagent 還有區別嗎？

有的，核心部分的區分仍然成立：

• Skill 的出發點是知識 — 「你要怎麼想這件事」，可以 inline 也可以 fork
• Subagent 的出發點是隔離 — 「去做完回來報告」，天生就是獨立 Context

Skills 2.0 讓 Skill 「可以選擇」要不要隔離，但 Subagent 是「天生就」隔離的。就像一個人可以選擇獨立作業，但不代表他跟天生的獨立承包商是同一件事，出發點不同，設計意圖不同。

用 Token 消耗量來決定？

理解了 Context 流向之後，很多人會發展出一個快速判斷：

Token 消耗多 → Subagent Token 消耗少 → Skill

其實這個直覺大部分時候是對的，Token 消耗高通常意味著中間過程多，而中間過程多通常代表對主對話來說這些資訊沒有保留價值。

但這邊有兩個盲點：

盲點一：Token 少，但需要隔離

一個輕量任務只產生幾百 tokens，但你需要限制工具權限的時候，比如你希望你的 Code Reviewer 只能讀不能寫，以策安全，雖然他耗的 Token 不多，因為你不想讓他有寫入權限，就該用 Subagent。

盲點二：Token 多，但需要互動

你在討論一個複雜的架構設計，整個過程中需要來回對話、討論、反覆修正，這時如果你用 Subagent，他做完事情就關閉回來了，沒辦法中途介入互動，但用 Skill 的話，所有中間資訊全部留在主 Agent 的 Context Window 中，Context 又會爆炸，該怎麼辦？

第一個盲點好解決，直接用 Subagent，但第二個盲點是真正的兩難：Skill 會塞爆 Context，Subagent 又失去互動，我們該怎麼解決？

答案不是選其中一個，而是把它們 組合起來，這就是我們下一篇要聊的。

延伸閱讀

• Anthropic: “Extend Claude with Skills” (官方文件) [1] — “skill descriptions are loaded into context so Claude knows what’s available, but full skill content only loads when invoked”；context: fork 讓 Skill 在隔離環境執行 link

• Anthropic: “Create Custom Subagents” (官方文件) [2] — “Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions” link

• Anthropic: “Subagents in the SDK” (API 文件) [3] — “Each subagent runs in its own fresh conversation. Intermediate tool calls and results stay inside the subagent; only its final message returns to the parent” link

• Anthropic: “Effective Context Engineering for AI Agents” [4] — “Each subagent might explore extensively… but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)” link

• Anthropic: “Skills Explained” (Blog) [5] — Skills 適合跨對話的可攜知識；Subagents 適合保持主對話專注的 context 隔離 link

參考資料：

[1] Anthropic: “Extend Claude with Skills” (官方文件) https://code.claude.com/docs/en/skills

[2] Anthropic: “Create Custom Subagents” (官方文件) https://code.claude.com/docs/en/sub-agents

[3] Anthropic: “Subagents in the SDK” (API 文件) https://platform.claude.com/docs/en/agent-sdk/subagents

[4] Anthropic: “Effective Context Engineering for AI Agents” https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[5] Anthropic: “Skills Explained” (Blog) https://claude.com/blog/skills-explained