别再纠结用 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：

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

• 中断：随时可以，不影响 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 的正确打开方式