大家好，我是玄姐。
装上 Claude Code 后，很多人都会陷入纠结：“该优先搞 Skills，还是写个 Subagents？” 翻完一堆文档，被 SKILL.md、subagents.md、Agent、工具、工作流等概念绕得晕头转向。
但其实你真正要解决的核心问题，从来不是 “选哪个名词”，而是 “在我的场景里，谁来执行任务、执行到什么程度、状态怎么保留，才最高效？” 这篇文章就帮你把核心逻辑讲透，让你看完就能拍板：该用啥、怎么用、为啥这么用。
一、核心类比：同样是 “做红烧肉”，执行主体大不同
先抛开复杂概念，用做饭这件事打个比方。想做一道红烧肉，有两种截然不同的方式，正好对应 Skill 和 Subagent：
Skills 模式：自己照着菜谱做
你手里拿着一份红烧肉菜谱，一步步跟着切肉、焯水、炒糖色、慢炖。这里的 “菜谱” 就是SKILL.md，“厨师” 是你自己。
对应 Claude Code 就是：SKILL.md相当于给主 Agent（你）植入了一项新技能。学会之后，主会话中随时能调用，所有思考过程、上下文信息、文件状态都会留在当前对话里。就像你学会红烧肉后，每次做饭都能轻松上手，还能越做越熟练。
Subagents 模式：把菜谱交给餐馆
你直接把红烧肉菜谱递给餐馆，说 “按这个标准做一份，做好给我送来”。这里的 “菜谱” 是subagents.md，“厨师” 是餐馆：一个独立于你的 “分身”。
对应 Claude Code 就是：主 Agent 不用亲自动手，只需描述任务并交给 Subagent。这个 “分身” 会在独立的上下文环境中执行，有自己的工具和权限，执行过程中的思考、临时状态都不会占用主会话空间，做完只把最终结果反馈回来。就像点外卖，你只关心味道好不好，不用管后厨怎么操作。
两者的核心差异很明确：同样是 “完成任务的流程指南”，但执行主体、占用的上下文环境完全不同。
二、本质区别：执行环境决定选型逻辑
再往深一层看，SKILL.md和subagents.md的内容本质是相通的，都是 “工作说明书”，会明确任务目标、输入输出要求、执行步骤、注意事项。
真正的区别在于执行环境：
Skills：在主会话的上下文里执行，和当前对话深度融合，相当于 “主 Agent 亲自下场干活”；
Subagents：在独立的上下文里执行，像开了一个 “子工程”，和主会话互不干扰，相当于 “外包给专门的分身完成”。
三、关键维度对比：一张表选对不纠结
从 “能不能完成任务” 来看，两者没有绝对界限，但从 “体验、成本、适配场景” 来看，差异十分明显：
对比维度 | Skills | Subagents |
|---|---|---|
执行环境 | 主会话上下文内，深度融合 | 独立上下文，类似 “子进程” 隔离 |
执行主体 | 主 Agent 亲自执行 | 专门的 Subagent 分身执行 |
中断方式 | 随时可停，不影响 Skills 本身 | 可终止任务，但当前分身状态直接消失 |
恢复方式 | 依赖主会话历史，可直接恢复执行 | 无法恢复上一实例，只能重新调用 |
状态保留 | 状态混在主会话历史和文件系统中 | 任务结束后实例销毁，仅返回最终结果 |
上下文占用 | 中间思考过程会占用主上下文 Token | 中间过程不占用主上下文，仅返回必要结果 |
与主会话关系 | 主 Agent 的 “技能插件” | 主 Agent 的 “外包团队” |
适配场景 | 需长期记忆、反复迭代、分步交互的工作流 | 需隔离、并行执行、单次完成、权限差异明显的任务 |
简单总结：
Skills 适合 “长期复用、需要持续优化” 的场景，例如：长期维护知识库、打磨长文档；
Subagents 适合 “一次完成、不想占用主上下文” 的场景，例如：临时生成脚本、批量数据处理。
四、实例验证：为什么 Plan 模式是 Subagent？
Claude Code 自带的 Plan 模式，本质就是一个 Plan Subagents。为什么官方不把它做成 Skills？核心就两个字：干净。
如果 Plan 是 Skills：
所有研究、检索、分析、试错的过程，都会塞进主会话上下文；
主会话会被大量 “思维垃圾” 污染，Token 消耗飙升，上下文窗口容易被挤爆，影响后续写代码、改文案。
而做成 Subagents 后：
Plan 分身在独立环境中完成研究、拆解任务、生成计划；
主会话只收到一份精简后的最终计划，中间过程完全不拖累主上下文；
既节省 Token，又降低心智负担，主会话能保持整洁高效。
这个例子完美说明：需要隔离中间过程、只关注结果的场景，Subagents 是更优选择。
五、两步决策法：快速选对不纠结
不用再反复权衡，记住这个简单决策树，30 秒就能定答案：
第一步：要不要 “记住执行过程”？
需要长期上下文、持续迭代、反复回顾之前的操作 → 选 Skills；场景例子：长期维护技术栈助手、持续打磨 PRD、频繁回顾历史操作逻辑；
不需要记住过程，只要最终结果 → 选 Subagents；场景例子：临时生成报告、单次批处理分析、大规模检索等 “脏活累活”。
第二步：需不需要 “隔离、并行、特殊权限”？
需要权限隔离（例如：仅访问特定目录 / API）、并行执行多个任务、沙盒内风险可控 → 选 Subagents；
权限一致、工具相同、无需隔离 → 直接用 Skills 即可。
核心原则：别为了 “概念酷炫” 过度设计，贴合实际需求就好。
六、落地建议：先干起来，再优化
很多人卡在 “选形态” 上迟迟不行动，但其实 Skills 和 Subagents 的切换成本很低，正确做法是：
先做 Skills：把任务流程拆清楚、梳顺畅，用 Skills 让主 Agent 先把事情落地，验证流程可行性；
再反向优化：跑通之后问自己三个问题：要不要隔离？要不要单独权限？要不要并行执行？
灵活切换：如果答案是 “要”，再把 Skills 逻辑包装成 Subagents，迁移成本极低。
就像同一个剧本，既可以让一个演员从头演到尾（Skills），也可以请多个演员在不同舞台并行演出（Subagents），核心流程没变，只是执行和调度方式不同。
真正影响体验的，从来不是 “用了哪个名词”，而是 “让谁来执行、怎么调度” 更贴合你的需求。别再纠结概念，先选一个靠谱的形态让 Claude 帮你完成一件事，再用实际体验反向校正，这才是 Agent 工程化的正确打开方式。
PS：
▼《每日短视频推荐》
▼大模型能淘汰架构师吗？
—1—
加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即预约！
)
