两者都是给 AI 助手"加能力"的机制，但解决的问题完全不同。MCP 是"接外部能力"的协议，Skills 是"长内部专长"的封装。本文用图解 + 决策树帮你一次选对。
Model Context Protocol，是一个开放协议。它让 AI 助手连上外部系统——数据库、API、文件系统、SaaS 工具（GitHub、Slack、Notion…）。
MCP 解决的是："助手怎么安全、标准化地调用外面的世界"。它提供的是能力接口，不是知识。
技能（Skill），是一包领域知识 + 标准流程 + 提示词模板。它把"某类任务怎么做才专业"固化下来——比如"怎么合规地装一个 MCP""怎么系统化排查数据库慢查询"。
Skills 解决的是："助手怎么把某件事做得更专业、更稳"。它提供的是方法与专长，不是连接。
MCP 是 Anthropic 在 2024 年底提出的开放标准协议，目标是给 AI 应用提供一个"USB-C 接口"——统一地连接各种外部数据源和工具。在此之前，每个工具都要为每个 AI 应用单独写一个集成，N 个应用 × M 个工具 = N×M 集成地狱；MCP 把它变成 N+M。
可被模型调用的动作——执行函数、写数据、发请求。有副作用，模型主动决定何时调用（如"创建一个 issue"）。
可被读取的上下文——文件内容、DB 查询结果、API 响应。无副作用，作为给模型的"参考资料"。
预定义的交互模板——把常见任务的提示词固化，用户一点即用（如"代码审查模板"）。
Skills 是 WorkBuddy / 同类 Agent 体系里的能力封装单元。它把"完成某类任务的专业方法"打包成一份可复用、可触发的知识包——包含说明文档（SKILL.md）、可选的脚本、参考材料、资源文件。模型在合适时机自动加载或按名调用，从而把某件事做对、做专业。
核心。用自然语言写明：这个技能解决什么问题、何时触发、标准操作步骤、注意事项、调用哪些脚本/工具。模型靠它判断"该不该用、怎么用"。
可选的 scripts/ —— 把繁琐、易错、需要确定性执行的步骤脚本化（如批量重命名、生成报告、调用某 API）。
references/ 放长文档、规范、API 手册，需要时才读入上下文，避免污染主提示。
assets/ 放图片、模板、样例，支撑输出质量（如生成 PPT 的版式、PDF 表单）。
| 维度 | MCP MCP（协议） | Skills Skills（技能） |
|---|---|---|
| 本质 | 连接外部系统的开放标准协议 | 封装专业方法的能力包/知识包 |
| 解决什么 | "助手怎么碰到外面的数据/工具" | "助手怎么把某类事做专业" |
| 方向 | 向外（接外设） | 向内（长脑子） |
| 谁提供运行环境 | 独立的 MCP Server 进程/服务 | 宿主 Agent 内部加载 |
| 典型产物 | 一个可连的 Server（GitHub/DB/…） | 一份 SKILL.md + 脚本/参考 |
| 是否有网络/进程 | 是（跨进程甚至跨机器通信） | 否（本地上下文 + 本地脚本） |
| 可移植性 | 跨任何支持 MCP 的客户端通用 | 绑定特定 Agent 体系（如 WorkBuddy） |
| 触发方式 | 模型在需要时调用 Tool/读 Resource | 模型按 SKILL.md 触发条件自动或按名加载 |
| 类比 | 给电脑插 USB 外设 | 给员工做岗位培训手册 |
| 场景 | 选谁 | 为什么 |
|---|---|---|
| 让助手读取你公司 MySQL 里的数据 | MCP | 数据在外面，需要连接 + 鉴权 + 查询接口 → MCP Server。 |
| 让助手按规范安全地安装并配置 MCP | Skills | 这是"怎么做才对"的流程，装完还要安全审计 → Skill。 |
| 助手既要查 GitHub 又要发 Slack | MCP | 两个外部系统，各起一个 MCP Server 即可，协议统一。 |
| 每次生成 PDF 都按固定版式/合规要求 | Skills | 方法/模板在内部，不需要外部连接 → Skill 装载模板。 |
| 助手查数据库后还要"专业地分析报告" | 两者 | MCP 负责连库取数，Skill 负责教它怎么专业解读。 |
| 希望能力在 Cursor / Claude / WorkBuddy 都能用 | MCP | 开放协议跨客户端通用；Skill 绑定具体 Agent 体系。 |
需要访问外部数据/工具 → 看 2（MCP）；想把某类任务做专业 → 看 4（Skills）。
是 → MCP（标准协议，一次开发处处用）。否但仍是外部连接 → 仍建议 MCP，除非只是临时脚本。
有 → 直接连；没有 → 自己写一个 MCP Server（暴露 Tools/Resources）。
是 → Skills 把它固化（SKILL.md + 脚本/模板）。否 → 也许只需普通提示词。
若任务既要"连外部"又要"专业干" → MCP + Skill 组合：MCP 给手，Skill 教招。
错。它们是不同层：MCP 管连接，Skills 管方法。多数成熟场景是组合——用 MCP 接上能力，用 Skill 规范使用方式。
Skill 是知识与流程，不是网络桥接。要访问外部实时数据，仍需要 MCP（或等价连接器）把数据接进来。
MCP 只提供"能调用"，不保证"调得对"。比如连接了数据库，模型未必知道怎么安全写 SQL——这得靠 Skill 教。
Skill 默认在宿主内运行，跨进程/跨机器的安全连接仍要走 MCP Server，Skill 本身不解决鉴权与网络边界。
轻量、一次性需求直接调 API/写脚本更快。MCP 的价值在标准化复用与跨客户端，别为小需求过度设计。
Skill 会占用上下文并增加触发误判。只在"确实有反复、易错、需固化"的任务上建 Skill，保持精简。