Skills、MCP、命令、子代理——一张决策表选清楚

Skills、MCP、命令、子代理——这四个词你一定在文档里见过，可能一篇教程里就出现了好几次。新手最容易的反应是：它们好像都是"扩展 Claude Code 的方式"？然后就停在这里，不知道什么时候该用哪个，结果要么每次都去翻文档，要么靠直觉乱选。

其实这四种方式的定位非常清晰，一张表就能分清。这篇就是要把这张表给你。

---

先把四个概念各自钉住

在看决策表之前，先给每种方式一句话定位——这是后续所有判断的基础。

Skills（技能）：教 Claude Code "怎么做事"的方法卡。你在 .claude/skills/ 里写一个 Markdown 文件，描述一套流程、规范或过程知识，Claude Code 以后做相关任务时就会遵循它。比如"代码审查要按这个 checklist 来"、"提 commit 信息要用这个格式"。

MCP（Model Context Protocol）：给 Claude Code 连外部系统的插头。Slack、GitHub、数据库、内部 API——这些外部系统 Claude Code 本身不认识，通过 MCP Server 接入后，它就能直接调用这些系统的能力。

自定义命令（Slash Commands）：把一套固定指令打包成一个 /关键词。你在 .claude/commands/ 里定义，以后输入 /review 就触发一整套代码审查流程，省得每次手敲。

子代理（Sub-agents）：让 Claude Code 孵化出独立的子任务执行器。主任务拆成几个独立部分，交给不同子代理并行跑，每个子代理有自己的上下文隔离，互不干扰。

---

决策表：需求到选型的直通路

拿到一个需求，对着这张表走一遍，基本不会选错。

你的需求是…	选这个	为什么
想让 Claude 以后做某类任务时遵循某套规范/流程	Skills	Skills 是"过程知识"载体，一次写好，永久复用，渐进式披露——Claude 只在相关场景激活它
需要读写外部系统（数据库、Slack、GitHub API、内部服务…）	MCP	MCP 专门解决"连接"问题，为外部系统提供标准化接口
有一套每次都重复输入的指令组合，想一键触发	自定义命令	命令是"指令固化"工具，把高频操作包装成可重复调用的入口
任务可以拆成独立部分，想并行跑或需要上下文隔离	子代理	子代理专门处理"拆活/并行/隔离"，避免长上下文互相污染
想教 Claude 一套方法论，同时需要它调用外部数据	Skills + MCP	两者定位不同，组合才能覆盖完整需求
有标准化流程要一键触发，里面还要调外部系统	命令 + MCP	命令负责触发，MCP 负责连接，各司其职
大任务要拆成多个子任务，每个子任务又有自己的规范	子代理 + Skills	子代理管拆分和隔离，Skills 管每个代理的行为规范

---

判断口诀

如果你记不住表，记这四句口诀：

要教它怎么做 → Skills
要连外部系统 → MCP
要固化重复指令 → 命令
要拆隔离并行 → 子代理

实际判断时，先问"我这个需求的核心动作是什么"——是在教方法、还是在连外部、还是在省重复输入、还是在拆任务？答案出来，对号入座。

---

为什么 Skills 是日常主力，MCP 要按需开

很多人第一直觉是：MCP 能连外部系统，功能更强，是不是应该多装几个？

这个直觉是反的。

Skills 的成本极低：一个 .md 文件，写好放在项目里，不占资源，不影响响应速度，任何任务场景都能用，Claude Code 会智能判断什么时候激活它。Skills 入门和 skill.md 渐进式披露的写法里有详细说明——你会发现一个写得好的 Skill 文件，比每次在对话里重新解释规范高效得多。

MCP 的成本相对高：每多开一个 MCP Server，就多一个进程、多一份网络连接、多一份安全面——Claude Code 在决策时需要考虑更多工具的调用可能性，反而容易"工具过载"。MCP 的价值在于你真的需要访问那个外部系统，不是"万一以后用得上"就提前开着。

具体原则：

• 本地项目规范、代码风格、审查流程、commit 规范 → 全部用 Skills
• 要读写数据库、调第三方 API、接 Slack / GitHub → 才考虑 MCP
• 不确定的时候，先用 Skills，发现 Skills 解决不了了再加 MCP

关于 MCP 的接入方式和开销管理，可以参考 MCP 按需接入与线程 Server 管理（3.11节会专门讲）。

---

子代理的适用边界

子代理是四种方式里最容易被高估的一个。它解决的问题非常具体：任务之间真正独立，并且能并行跑。

什么叫真正独立？就是任务 A 的进展不依赖任务 B 的结果。比如：

• 同时给三个不同的模块写单测 → 适合子代理
• 先分析需求、再写代码、再跑测试 → 不适合，这是顺序依赖，用单个会话更合适

子代理的另一个价值是上下文隔离。长上下文会让模型的注意力被无关内容稀释，复杂任务里容易出现"前面说的规则后来忘了"的问题。子代理每个都有自己干净的上下文，不受其他任务的干扰。

但注意：启动子代理有开销——每个子代理都要初始化自己的上下文。任务量不够大、不够独立的情况下，强行拆成子代理反而更慢、更难调试。子代理拆活与并行隔离的完整用法会在 3.3 节详细讲，这里只需要记住：子代理是"并行隔离"专用工具，不是"所有复杂任务"的万能方案。

---

四者怎么组合

实际项目里，这四种方式几乎不会单独出现，更常见的是搭配使用。几个典型组合：

日常编码工作流（最常用）：

• Skills 里定义代码审查规范、测试覆盖标准
• 自定义命令 /review 一键触发审查流程（调用那个 Skill）
• 不需要 MCP，不需要子代理

接第三方服务的功能开发：

• MCP 接入 GitHub（读 issue、提 PR）
• Skills 里定义 PR 描述格式规范
• 命令 /pr 一键按规范提 PR，同时通过 MCP 写到 GitHub

大型重构任务：

• 主任务拆成"分析影响范围"、"改各个模块"、"更新测试"三个子代理并行跑
• 每个子代理各自加载相关的 Skills（比如"改模块时遵循这个编码规范"）
• 改完后用命令 /summarize 聚合结果

组合的原则很简单：每种工具只做自己最擅长的那件事，不要让 Skills 去做连接工作，不要让 MCP 去存流程知识，不要让命令去管并行隔离。

---

常见问题

Q：Skills 和 CLAUDE.md 有什么区别？

CLAUDE.md 是项目级的全局上下文，每次启动都加载，适合放项目背景、架构说明这类信息。Skills 是按需激活的过程知识，只在相关任务场景下加载，不会每次都占用上下文窗口。规范类、流程类的内容放 Skills，项目介绍类的内容放 CLAUDE.md。

Q：MCP Server 怎么知道选哪个？

看你要连的外部系统有没有官方或社区维护的 MCP Server。Anthropic 维护了一份官方 MCP Server 列表，GitHub、Slack、PostgreSQL 等主流系统都有。没有现成的，可以自己写（MCP 协议是开放的），或者先用命令行方式绕过去，等需求稳定了再包装成 MCP。

Q：子代理和直接开多个 Claude Code 会话有什么不同？

手动开多个会话是你来管理上下文同步；子代理由主会话统一调度，结果会汇总回主会话，适合有明确"主任务→子任务→汇总"结构的场景。如果你只是想同时开几个独立项目，手动开多个会话反而更直接。

Q：自定义命令能调用 Skills 吗？

可以。命令文件里可以显式引用一个 Skill 文件的路径，或者在命令描述里说明"按照 XXX Skill 的规范来做"。命令负责触发时机，Skills 负责行为规范，两者配合是很自然的用法，详见 Skills 术语页 和 MCP 术语页。

Q：四种方式都配置了，Claude Code 怎么决定用哪个？

它根据你当前任务的自然语言描述来判断：检测到需要外部系统访问就走 MCP 工具调用；识别到你输入了 / 开头的命令就触发对应命令；任务描述里涉及某个流程领域就激活相关 Skills；主会话里明确拆出子任务才启动子代理。一般不需要你显式指定，除非任务描述本身不够清晰。

---

回顾一下

四种扩展方式，各有专属赛道：

• Skills：过程知识，日常主力，成本低，优先用
• MCP：外部连接，按需开，开销大，用到才加
• 命令：固化重复指令，一键触发
• 子代理：并行隔离，拆真正独立的任务

口诀：要教它怎么做→Skills；要连外部系统→MCP；要固化重复指令→命令；要拆隔离并行→子代理。

这四种方式学明白了，你就有了一套完整的"扩展工具箱"。回到 AI 编程教程大全 看整条 L3 线，每一节都会在这个框架里找到自己的位置。

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。