一句话看懂：MCP 更像“可调用的工具接口”，适合稳定、精确、可预测的外部操作；Skill 更像“本地操作手册”，适合用自然语言约束 Agent 的行为和工作流程。
最近关于 Agent 应该使用 Skills 还是 MCP 工具，讨论很多。两者确实有一部分重叠：都能增强 Agent 的能力，都能让 Agent 更好地完成特定任务。
但它们在配置方式、执行方式、适合人群和维护成本上差别很大。理解这些差别，才能避免把 Skill 写成低质量提示词，也避免把所有需求都硬塞进 MCP。
MCP：适合精确、可预测的工具调用
MCP，全称 Model Context Protocol，是一种让大模型连接外部工具和上下文的协议。通过 MCP，Agent 可以使用第三方服务提供的工具，也可以访问额外资源和预设提示。
从使用门槛看，MCP 通常更偏开发者。配置 MCP Server 往往会涉及授权、传输方式、命令行、stdio 通信、本地服务或网络端点。对普通用户来说，这些概念不一定友好。
但一旦配置好，MCP 在“确定性执行”上很强。
比如有一个网页抓取 MCP 工具：输入一个 URL，它就抓取对应网页内容并返回结果。Agent 的交互流程通常是：
MCP 工具调用流程
这个流程很直接：
| Agent 理解用户需求 | Agent 选择 MCP 工具 | Agent 按 schema 提供参数 | MCP 工具执行请求 | Agent 拿到返回结果并完成回答 |
|---|
MCP 工具的范围通常比较窄，输入和输出也比较明确。只要输入条件相同，返回结果大体可预测。
因此，MCP 更像一种功能接口：在特定条件下执行特定逻辑，给 Agent 提供它需要的精确结果。
MCP 的三个常见问题
MCP很强，但不是没有代价
第一，工具数量一多，发现和选择会变复杂。
每个 MCP 工具都需要名称、描述和参数 schema。Agent 要先判断该用哪个工具，再按正确参数调用。工具越多，选择成本越高，所以才会出现 MCP gateway、工具发现中间件等方案。
第二，工具返回内容可能污染上下文。
如果某个工具没有控制返回长度，很容易把大量内容塞进 Agent 的上下文，影响后续推理和成本。
第三，每次调用通常都有延迟。
MCP 工具经常需要访问外部服务或本地进程，调用链路里会有网络或进程通信开销。对于本身不需要外部数据的操作，MCP 可能显得重。
Skills：适合本地行为指导和流程约束
Skill 是一组面向特定领域的本地指令。它通常写在 Markdown 文件里，也可以链接到参考资料、脚本或模板。
简单说，Skill 不是给 Agent 新增一个 API，而是给 Agent 一份“遇到这类任务时应该怎么做”的操作说明。
Skill 的典型结构可能是这样：
| .claude/skills/ | ├── pdf-parsing/ | │ ├── script.py | │ └── SKILL.md | ├── python-code-style/ | │ ├── REFERENCE.md | │ └── SKILL.md | └── web-scraping/ | └── SKILL.md |
|---|
每个 Skill 文件夹里，最重要的是 SKILL.md。例如：
| name: web-scraping | description: Scrape web pages based on a provided URL using the scpr CLI app. | When asked to scrape a web page, use the `scpr` command line interface in this way: |
|---|
scpr --url https://example.com
| This will allow you to read the page content as markdown. |
|---|
有些 Skill 还会带脚本，例如 pdf-parsing/script.py。有些 Skill 会带更完整的说明文档，例如 REFERENCE.md，供 Agent 在 Skill 激活时按需查看。
同样以网页抓取为例，Skill 的交互流程大致是：
Skill 指导 Agent 执行任务的流程
用户体验看起来和 MCP 类似，但底层逻辑不一样。
MCP 是 Agent 调用一个明确工具，背后通常是一次 API 调用，输入和输出 schema 比较清晰。
Skill 则是 Agent 读取自然语言说明，再自己理解和执行。它可以非常灵活，但也更依赖模型的理解能力。
Skill 的优势和风险
Skill 最大的优势是轻量。
它通常只是本地文件，不需要部署服务，不需要配置接口，不需要复杂授权。对创作者和普通用户来说，用 Markdown 写一份流程说明，比写 MCP Server 容易得多。
Skill 也更适合表达行为风格和业务经验。
例如：
| 论坛帖子发布前，先检查标题是否清楚； | 再检查是否有母帖回链； | 再检查是否有引用来源； | 最后给出可直接发布的 Markdown。 |
|---|
这种“判断 + 流程 + 风格”的要求，用 Skill 很自然。
但风险也在这里：Skill 是自然语言说明，不是确定性 API。Agent 可能理解错，也可能漏掉某一步。
所以对 Agent 来说：
| 使用 MCP 的难点：判断该不该用这个工具。 | 使用 Skill 的难点：判断该不该用这个 Skill，以及该如何执行里面的说明。 |
|---|
换句话说，MCP 的“怎么做”通常由工具实现；Skill 的“怎么做”很大程度仍然由 Agent 自己推理。
什么时候用 MCP，什么时候用 Skill
原文作者在构建 LlamaAgents Builder 的 Agent 编码能力时，遇到过这个选择：到底是使用 LlamaIndex Documentation MCP，还是编写自定义 Skill，让 Agent 学会使用 LlamaParse SDK 和 Agent Workflows。
最开始，他们两种方式都用了。
设想是：MCP 可以提供更大的知识库，帮助 Agent 做规划；Skill 可以在写代码时提供更具体的行为指导。
测试后发现：
- 很多时候，文档 MCP 提供的上下文已经足够让 Agent 写出正确代码模式。
- Skills 很少被调用，即使被调用，效果也没有明显优于只使用文档 MCP。
这是一个很有代表性的案例：不是 Skill 不好，而是这个场景下，知识更新很快，文档本身才是最可靠的单一事实来源。
关键维度对比
下面是 MCP 和 Skill 在几个关键维度上的对比：
| 维度 | MCP | Skills |
|---|---|---|
| 配置复杂度 | 中等，需要理解授权、传输方式、CLI 等开发概念 | 低，通常只需要 Markdown 文件 |
| 执行模型 | 基于固定 schema 的确定性 API 调用 | LLM 解释自然语言指令 |
| 性能 | 每次调用可能有网络或服务延迟 | 本地文件，无额外网络开销 |
| 最适合 | 输入输出明确、要求精确和可预测的操作 | 行为指导、流程约束、上下文适配 |
| 维护方式 | 集中维护，服务更新后所有调用方受益 | 本地维护，需要手动更新 Markdown |
| 扩展挑战 | 工具多了以后，发现和选择变复杂 | 添加容易，但 Skill 多了以后选择也会变复杂 |
| 失败模式 | 选错工具、参数错误、服务失败 | 理解错说明、漏执行步骤、选错 Skill |
MCP 与 Skills 的关键维度对比
一个简单判断标准
如果任务需要的是“拿到某个系统里的确定结果”，优先考虑 MCP。
例如：
- 查询数据库。
- 读取 GitHub issue。
- 调用公司内部 API。
- 获取最新文档。
- 访问外部 SaaS 服务。
如果任务需要的是“让 Agent 按某套经验做事”，优先考虑 Skill。
例如：
- 按团队风格写周报。
- 按论坛规则检查帖子。
- 按固定流程整理会议纪要。
- 按内容运营标准筛选选题。
- 按项目规范生成代码说明。
如果两者都需要，就组合使用：
| MCP 负责拿数据 | Skill 负责规定怎么处理数据 | Agent 负责把流程跑完 |
|---|
为什么快速变化的知识更适合 MCP
原文最后给了一个很重要的经验：如果 Agent 工作在快速变化的领域，单一事实来源会非常重要。
比如 LlamaParse SDK、LlamaIndex、开发者文档、API 示例都在持续变化。如果把最佳实践写死在本地 Skill 里，就需要不断手动更新，否则很快过期。
而文档 MCP 可以随着官方文档更新自动提供最新上下文。这种场景下，MCP 更合适。
反过来，如果你的流程变化不快，例如：
- 论坛发帖检查。
- 周报结构。
- 客户资料归档。
- 简历筛选规则。
- PDF 处理流程。
这些更适合做成轻量 Skill。
对 Skill 工坊创作者的启发
在论坛发 Skill 内容时，不要把 MCP 和 Skill 混在一起讲。
Skill 内容更应该强调：
- 这个 Skill 解决什么重复场景。
- 用户什么时候触发它。
- 它如何指导 Agent 行动。
- 哪些步骤需要脚本或工具配合。
- 哪些信息需要人工确认。
如果内容涉及外部系统、API、数据库、账号授权，就要明确说明：这部分可能属于 MCP 或工具集成，不是 Skill 本身能直接解决的。
这样能避免 Skill 工坊出现两类垃圾内容：
- 把一段普通提示词包装成 Skill。
- 把需要 MCP/API 的能力夸成“安装 Skill 就能用”。
小结
MCP 和 Skill 都能增强 Agent，但它们解决的问题不一样。
MCP 更像工具接口，适合精确、可预测、需要连接外部系统的任务。
Skill 更像本地操作手册，适合把团队经验、流程规范和输出要求交给 Agent。
选择时不要问“哪个更高级”，而要问：
| 这件事需要的是外部访问能力，还是本地流程指导？ | 这件事需要确定性执行，还是需要行为约束？ | 这份知识会快速变化，还是相对稳定？ |
|---|
如果知识变化快，优先让 Agent 连接最新事实来源。
如果流程稳定、需要长期复用，就把它写成 Skill。