别再纠结用 Skill 还是 Subagent 了，这一篇讲透 Claude Code 的「分身术」

很多人装上 Claude Code 之后，第一反应都是：“好，接下来我该搞 Skill，还是写个 SubAgent？”

文档一看一大堆：SKILL.md、subagents.md、Agent、工具、工作流……
明明只是想让 Claude 帮我干点正事，结果先被概念整懵了。

但冷静想想，你真正想解决的问题，从来不是：

“我该用 Skill 还是 Subagent？”

而是：

“在我的这个场景里，谁来干活、干到什么程度、状态怎么保留，最合适？”

这篇就干一件事：
把Skill vs Subagent讲到你能立刻拍板，用哪个、怎么用、为什么用。

---

一、同样的“做饭技能”，只是谁来下厨不同

先不谈 Claude，先说吃饭。

我们来做一道红烧肉，有两种选择：

Skill 模式：
你打开菜谱，自己按步骤做红烧肉。
菜谱 =SKILL.md，厨师 = 你自己。

Subagent 模式：
你把菜谱交给餐馆，说“按这个做一份红烧肉，做好给我送来”。
菜谱 =subagents.md，厨师 = 餐馆（一个独立的“分身”）。

你会发现，两边写下来的“做红烧肉流程”几乎一样：

• 都有食材清单

• 都有步骤顺序

• 都有注意事项

唯一的不同是：谁来花时间、谁在执行过程里亲自参与。

对着 Claude 来翻译就是：

1）SKILL.md 方式 = 把技能「刻进自己」

• 你（主 Agent）学习了一份SKILL.md

• 之后在主会话中，你随时可以调用这个技能

• 所有思考、上下文、文件状态，都留在这一次主对话里

就像你学会红烧肉之后，以后每次做饭都能加一道这菜，而且你会越做越熟练。

2）subagents.md 方式 = 把任务「外包给分身」

• 你只需要描述任务，把它丢给某个 Subagent

• Subagent 在自己的小世界里执行：有自己的上下文、工具、权限

• 做完之后，只把结果带回给你

• 它的整个思考过程、临时状态，不会占用你的主对话空间

就像你下班点个外卖，你只关心“好不好吃”，不关心后厨是几口锅、炒了多久。

---

二、本质差异：同一份“工作说明书”，不同的执行环境

再抽象一层，其实很简单：

Skill vs Subagent 的区别，不在文档写了什么，而在「执行环境」在哪。

• 内容本质相同：
  无论是SKILL.md还是subagents.md，本质都是给 Claude 的「工作说明书」：

• 任务是什么

• 输入输出是什么

• 步骤怎么走

• 要注意什么风格/边界

• 执行环境不同：

• SKILL.md：在主上下文里执行，跟你当前这场对话，融成一个世界

• subagents.md：在独立上下文里执行，像开了一个“子工程”，做完再把结果丢回来

这就是为什么，同样一个“做红烧肉”的流程：

• 写成 Skill：是“我学会这个菜了，以后在家自己炒”

• 写成 Subagent：是“以后这道菜我都叫这家餐厅做”

---

三、Skill vs Subagent：一张表看懂关键区别

很多人迷惑的点在于：“功能看起来都能实现啊，我到底选哪个？”

从“能不能做”这个角度，两者确实都能做。

但从“体验和成本”这个维度，差别就出来了。

可以先看一张粗暴对比表：

维度	Skill	Subagent
执行环境	主会话上下文内	独立上下文，像单独开了一个“子进程”
谁在执行	主 Agent 亲自下场	某个专门的 Subagent 分身
中断方式	随时停，不影响 Skill 文档本身	可以终止当前任务，但这个分身的本次状态就没了
恢复方式	靠对话历史 + 继续引用同一个SKILL.md	无法“恢复上一实例”，只能重新调用一次
状态保留	状态混在主会话的对话历史 + 文件系统里	任务结束后实例销毁，只把结果带回主会话
上下文占用	会把所有中间思考塞进主上下文	中间过程在子上下文，只把必要结果返回
与主会话关系	像是给主 Agent 装了一个「新技能插件」	像是给主 Agent 配了一个「外包团队」
适合的场景	需要长期记忆、反复迭代、一步步交互的工作流	需要隔离、并行、单次执行、权限差异明显的任务

简单解释：

• Skill：

• 状态：记录在当前对话和文件系统里，像“长期记忆”

• 中断：随时可以，不影响 SKILL 的后续执行

• 恢复：因为在主会话中，有记忆感知，可恢复

• 与主会话：高度融合，天然一体，连续

• Subagent：

• 状态：任务完成即销毁，只留结果，主会话没有其执行的中间记忆

• 中断：可以终止，但此次执行就结束了

• 恢复：不能回到“上一次的 subagent 实例”，只能新开一轮

• 与主会话：典型的“委托—返回”模式，状态天然隔离

---

四、一个例子

回到 Claude Code 自带的一个功能：Plan 模式。

Plan 模式本质上是一个Plan Subagent：

当你切到“计划模式”时，Claude 会自动调用这个 Subagent 来做：研究代码库、联网检索、分解任务、生成执行计划。

为什么官方把它做成 Subagent，而不是一个 Skill？

关键在于两个字：「干净」。

如果 Plan 做成 Skill，会发生什么：

1. 所有研究、检索、分析过程，全都塞进主对话上下文

2. 你的主会话会被各种“思维垃圾”和中间版本污染

3. token 占用飞涨，窗口很快被挤爆，还影响你后面正常写代码、改文案

而做成 Subagent：

• Plan 在自己的小天地里疯狂思考、查资料、拆任务

• 主会话只拿到一份“精简后的计划结果”

• 中途的搜索痕迹、试错过程，统统不会拖累主上下文

所以在这个场景下，Plan 做成 Subagent 明显更优：

• 对主会话更友好

• 对 token 更节省

• 对心智负担更低（你只面对最后那个“计划片段”）

---

五、两步选好 Skill 还是 Subagent

很多人纠结半天，其实选型逻辑可以压缩成一个简单决策树：

第一步：要不要“记住这个过程”？

• 需要历史上下文 / 长期连续性 / 反复迭代：优先考虑Skill

  场景例子：

• 长期维护一个知识库 / 技术栈助手

• 持续打磨一篇长文、一个 PRD、一份教程

• 需要频繁在上下文中“回顾之前我们怎么做的”

• 不需要记住整个过程，只要结果：直接上Subagent

  场景例子：

• 临时生成一份脚本、一次性报告

• 跑一次批处理分析

• 把脏活累活（如大规模检索、批量处理）丢出去做一轮

第二步：需不需要「并行、隔离、特殊权限」

• 需要并行、权限隔离、工具集不同、风险更可控：选Subagent

  比如：

• 某个 Subagent 只能访问特定目录或特定 API

• 某些操作你希望“在沙盒里执行完再把结果拿回来”

• 你希望同时让多个 Subagent 各自跑各自的任务

• 权限差不多、工具差不多，也不强调隔离：完全可以只写一个Skill

不要为了“酷炫”和“概念完整”而过度设计。

---

六、先干起来

最后一个很容易被忽略的点：

Skill 和 Subagent 之间的“形态切换成本”，其实很低。

你在大多数情况下，完全可以这样操作：

1. 先只做 Skill：

• 先把任务拆清楚、流程梳顺

• 用 Skill 的方式，先让主 Agent 真正帮你把事儿干起来

• 真·跑顺了之后再问自己：

• 这个东西要不要隔离出去？

• 要不要给它单独权限？

• 要不要并行、多开多个？

如果答案是“要”——再把这一套 Skill 的逻辑包装成一个 Subagent，是非常容易的迁移。

同一个剧本：

• 可以一个演员从头演到尾（Skill）；

• 也可以请多个演员在不同舞台、排成不同场次演（Subagent）。

剧本内容没有变，只是舞台和调度方式不同。

真正决定体验好坏的，从来不是“用了几个名词”，而是：你想把 Claude 放在什么位置、让谁来为谁打工。

所以别再卡在“我到底要 Skill 还是 Subagent？”。

更实在的做法是：

先选一个看起来靠谱的形态，
让 Claude 真的帮你把一件事做完，
然后再用数据和体验去反向校正你的设计。

——这才是工程化 Agent 的正确打开方式