![[MCP·Skill #3] MCP、Skill 与子代理：何时该用哪个？ 封面图](/assets/images/posts/1bb00db5-c156-4575-854c-7218ac263b2c/1.jpg)
扩展 AI 编程工具的方法越来越多：用 MCP 连接工具，用 Skill 注册流程，再把任务委派给子代理。
问题在于，三者都被描述为“扩展模型的能力”，所以实际选择时很容易感到困惑。
用一句话总结：MCP 是手，Skill 是手册，子代理是同事。
本文将整理三者各自扩展的内容、选择标准，以及组合后的整体架构。
先从核心摘要开始。
- MCP 扩展模型能做的事（工具和数据访问）
- Skill 扩展模型知道如何做的事（工作流程和领域知识）
- 子代理扩展做事的人手（拥有独立上下文的执行主体）
- 三者不是竞争关系，而是组合关系。由子代理读取 Skill 并使用 MCP 工具，是很自然的架构
三者各自扩展的内容
先用表格比较，再逐一介绍。
| 分类 | MCP | Skill | 子代理 |
|---|---|---|---|
| 扩展对象 | 能力（工具·数据） | 知识（流程·经验） | 执行主体 |
| 实体 | 协议·服务器进程 | Markdown 文件夹 | 独立上下文会话 |
| 比喻 | 手 | 手册 | 同事 |
MCP 是伸向模型外部系统的通道。它能让模型单独无法在物理上完成的任务成为可能，例如查询数据库、调用内部 API 或操作浏览器。其特点是存在一个运行代码的独立服务器。
Skill 不是提供新能力，而是帮助模型把已经能做的事做好。它把版本说明格式、审查清单、内部文档规则等关于“如何做”的知识保存到文件中。其实体就只是 Markdown。
子代理是拥有独立上下文窗口的另一个模型实例。它可以在不污染主会话记录的情况下，接手探索和调查等任务。即使让它搜索大量文件，主上下文中也只会收到结论。
选择工具时要问的三个问题
选择困难时，按顺序问自己下面三个问题。
第一，这是模型现在在物理上无法完成的事吗？如果像查询内部数据库一样，连访问本身都不可能，答案就是 MCP。无论加入多少知识，也不会凭空长出一只不存在的手。
第二，虽然能做，但每次都要解释方法吗？那就用 Skill。所有重复出现的提示词都可以作为 Skill 的候选。
第三，工作量太大，导致上下文被污染吗？如果调查和探索结果让对话变得杂乱，就该交给子代理隔离处理了。
反过来说，没有访问能力就用 MCP，没有诀窍就用 Skill，没有上下文（或上下文不足）就用子代理。
在实践中组合使用三者
三者并不是非此即彼。实际设计良好的自动化，大多是这种结构。
以自动化代码审查为例：定义一个审查子代理（主体），让它遵循团队的审查清单 Skill（方法），再通过 GitHub MCP 服务器留下 PR 评论（能力）。
可以看出，三者不是角色重叠，而是处于不同层次，分别对应“谁／如何／用什么”这三个问题。
两个常见的错误选择
看清边界后，反模式也会随之显现。
一种错误是为 Skill 足以处理的工作创建 MCP 服务器。例如，“应用提交消息规范”是知识问题，几行 Markdown 就能解决；为此编写服务器反而得不偿失。服务器还会带来维护成本和安全审查成本。
另一种错误是把所有事情都放在一个主会话中处理。如果直接在主会话里探索大型代码库，文件转储会填满上下文，真正用于实现的空间就消失了。标准做法是把探索委派给子代理，主会话只接收结论。
总结
总结来说，没有能力就用 MCP，没有诀窍就用 Skill，没有人手就用子代理。
MCP 篇和 Skill 篇分别详细介绍了相关内容。请根据本文的标准，先判断你要构建的自动化属于哪一层的问题。