MCP 与 Skill 的区别
MCP 负责把 agent 接到能力上；Skill 负责把「怎么用」这件事打包下来。它们解决的是不同问题，而真正跑起来的 agent 通常两个都要。
先记住一句话
MCP 是接入层：agent 靠它发现和调用工具、读取资源、连到外部系统。Skill 是任务知识层：agent 靠它知道一个可重复的任务 该按什么步骤做、遵守什么规则、输出长什么样。
区分它们最快的方法是问两个不同的问题。MCP 回答"agent 能碰到什么"，Skill 回答"agent 该做什么"。 两者谁也不能替代谁。
MCP 给的是访问能力，Skill 给的是做事方法。单独用任何一个都能跑，但真正有价值的流程是把两者合起来。
并排看
| 维度 | MCP | Skill |
|---|---|---|
| 角色 | 协议与连接 | 可复用任务包 |
| 形态 | 客户端 + 服务端 | 文件夹 + 指令 + 资源 |
| 目标 | 暴露工具、资源和提示词 | 指导可重复执行 |
| 模型看到什么 | 可发现、可调用的能力 | 任务匹配时被激活的指令 |
| 加载方式 | 作为常驻能力被发现 | 通过渐进披露按需激活 |
| 出问题时的表现 | 工具找不到、连不上或报错 | Skill 不激活，或在错误的任务上激活 |
| 最适合 | 调用工具、查询数据、集成服务 | 重复流程、领域规则、输出模板 |
| 典型产物 | 暴露一个或多个工具的服务端 | SKILL.md 加上可选的 references 和 scripts |
各自处在哪一层
把一次请求想象成在 agent 内部走一遍。用户提出需求，agent 判断自己需要什么。MCP 决定 agent 能碰到什么， Skill 决定 agent 一旦决定动手、应该按什么方式做。
客户端发现服务端以及服务端暴露的能力。这一层是管道：权限、schema、传输、错误面都在这里。
当任务描述匹配上某个 Skill，它就会被加载，告诉 agent 走哪些步骤、读哪些参考、输出应该长什么样。
agent 通过 MCP 调用工具，再按 Skill 的要求组织答案。访问和方法在同一个回答里汇合。
常见的四个误解
围绕这组对比的混乱，基本都来自下面这四种假设。
什么时候用哪个
从问题出发，而不是从格式出发。
| 如果你的问题是…… | 该用 | 原因 |
|---|---|---|
| agent 碰不到它需要访问的系统 | MCP | 你需要的是连接和可调用能力，不是方法。 |
| agent 什么都碰得到，但活儿干不对 | Skill | 访问已经解决了，缺的是方法。 |
| 不同的人反复做同一个多步骤任务 | Skill | 方法值得打包一次、重复使用。 |
| 你需要凭据、权限和审计边界 | MCP | 这些关注点属于连接层。 |
| 你希望输出格式和质量检查保持一致 | Skill | 模板和评审规则都属于方法。 |
| 任务既需要实时系统，也需要固定方法 | 两个都要 | 这才是生产环境 agent 的常态。 |
它们怎么配合
举个具体例子最清楚。假设任务是"复盘上周的客户工单，写一份摘要"。可访问的数据在服务端后面， 而"你们团队怎么写这份摘要"是 Skill。
工具: search_tickets （通过 MCP 暴露）
输入: { "range": "last_7_days", "status": "open" }
返回: { "tickets": [ { "id", "subject", "severity", "body" } ] }
Skill: ticket-digest （由任务描述激活）
步骤: 1. 按严重程度给工单分组
2. 归纳前三个主题
3. 标出没有负责人处理的工单
输出: 固定结构的 markdown 摘要，含一个"需要关注"区块MCP 服务端从不去决定"一份好摘要该长什么样"；Skill 也从不建立连接、不持有凭据。各自待在自己那一层， 这正是它们能组合得好的原因。
"够不够得到"归 MCP，"该不该做、怎么做"归 Skill。把这两件事混在一起，服务端就会长出它不该拥有的业务规则，Skill 也会开始硬编码它永远不该看到的凭据。