Skill + Subagent：組合模式與判斷模型

上一篇我們建立了 Skill 跟 Subagent 的核心區分：Skill 管知識載入，Subagent 管 Context 隔離，但最後我們遇到一個兩難：

Token 多 + 需要互動，怎麼辦？

官方的建議：先探索，再規劃，再執行

Anthropic 在 Claude Code 的 Best Practices [1] 裡其實有描述一個類似的模式：

Explore first, then plan, then code. Separate research and planning from implementation to avoid solving the wrong problem.

而且官方明確建議用 Subagent 做探索階段 [1]：

Use subagents for investigation… When Claude researches a codebase it reads lots of files, all of which consume your context. Subagents run in separate context windows and report back summaries.

所以官方的建議是：把探索跟決策分開，探索用 Subagent 隔離，決策留在主對話。 基於這個思路，如果再把 Skill 的知識載入加進來，實務上的工作流程可以長這樣：

探索對 Token/Context 的消耗是重量級的，所以我們交給 Subagent 在隔離環境裡做完，只回傳精簡摘要，而決策是輕量且需要互動的，留在主對話，搭配 Skill 提供的知識框架做判斷，決策完成後，再派 Subagent 帶著知識去執行。

舉個具體例子 — 「重新設計資料庫 Schema」：

這樣的拆解跟混合模式讓每個階段都不會踩到「Token 多 + 需要互動」的兩難。

兩個組合方向

除了拆階段，Skill 跟 Subagent 還有兩種直接的組合模式，這兩個方向在 Claude Code 官方文件 [2][3] 裡有明確的對照：

方向一：Skill 跑在 Subagent 裡（context: fork）

當一個 Skill 的執行過程會產生大量 Token 時，可以讓 Skill 在隔離環境裡跑，知識來自 Skill，隔離來自 Subagent，兩者的優勢都拿到了，讓 Skill 定義任務內容，然後你選擇一個 agent type 來執行他 [2]。

方向二：Subagent 預載 Skill（skills field）

反過來，當 Subagent 需要專業知識時，啟動時預載 Skill，補足 Subagent 的專業領域知識，讓 Subagent 控制系統提示，而 Skill 內容在啟動時就可以被完整注入 [3]。

兩個方向的差異：

但這邊有一個重要細節要注意：Subagent 不會自動繼承父對話的 Skill，你必須明確宣告才能使用，這是官方文件裡寫死的行為 [3]，這其實是好的設計，因為這就是第三篇的原則，不需要的東西就不該載入。

成本也是決策因素

到目前為止我們都在講 Context，什麼該載入、什麼該隔離，但在 2026 年的實務中，Token 成本已經成為跟 Context 同等重要的考量。

每多開一個 Subagent，就是多開一個 Context Window，Anthropic 的研究數據顯示 [4]：

• Agent 模式的 Token 消耗約 4 倍於普通對話
• Multi-Agent 系統約 15 倍於普通對話

所以 Subagent 不是 Context 的萬能藥，他解決了 Context 隔離的問題，但付出的代價是更多的 Token 消耗，相反的，Skill inline 執行雖然佔主 Agent 的 Context，但不需要額外開新的 Context Window，成本更低。

所以這樣看起來，這代表判斷模型需要再加一個維度：

Context Engineering 不只是管 Token 的流向，也是管 Token 的花費。 隔離不是免費的，每一次隔離都是一筆 Token 開支。所以最好的做法不是「什麼都隔離」，而是只在值得的時候才隔離。

回到框架

把這兩篇的討論放回第二篇的五層架構：

Skill 讓知識按需要載入，Subagent 讓執行過程被隔離，組合起來就是在不同維度上做 Context 的精準控制，不是「簡單用 Skill、複雜用 Subagent」，而是 該留的留，該隔離的隔離，該組合的組合。

參考資料

[1] Anthropic: “Best Practices for Claude Code” — “Explore first, then plan, then code”；用 Subagent 做調查以保護主 Context https://code.claude.com/docs/en/best-practices

[2] Anthropic: “Extend Claude with Skills” — 兩種組合方式：Skill 定義任務用 context: fork，Subagent 預載 Skill 用 skills field https://code.claude.com/docs/en/skills

[3] Anthropic: “Create Custom Subagents” — “Use the skills field to inject skill content into a subagent’s context at startup”；“Subagents don’t inherit skills from the parent conversation; you must list them explicitly” https://code.claude.com/docs/en/sub-agents

[4] Anthropic: “How We Built Our Multi-Agent Research System” — “agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens” https://www.anthropic.com/engineering/multi-agent-research-system

[5] Zenn: “Skill context:fork vs Sub-agent skills Field” — context: fork 提供固定可預測的任務定義；skills field 提供動態靈活性 https://zenn.dev/trust_delta/articles/claude-code-skills-subagents-approaches

但有一個場景，Subagent 也不夠用

到目前為止，Subagent 都是一個模式：主 Agent 派出去、做完回來。 一對一，hub-and-spoke。

但當任務變成這樣呢？

你需要 3 個 Subagent 同時研究不同方向，而且他們的結果需要互相參考。

Subagent A 的發現可能改變 Subagent B 的方向，B 的結論可能推翻 C 的假設。這不是「派出去、做完回來」能解決的 — 你需要 協作。

但 Subagent 之間沒有共享的 Context，也不能互相發訊息。官方文件寫得很明確：Subagent 只能回報給 parent，不能跟其他 Subagent 溝通。

而且更現實的問題是：如果 Multi-Agent 的 Token 消耗是普通對話的 15 倍，那當你需要多個 Agent 協作時，成本控制就變成跟 Context 管理一樣重要的課題。

這就是 Agent Team 要解決的問題 — 但那是下一篇的事了。