Skill 与 MCP

这两个词经常被当成同一个东西。但它们解决的是两类完全不同的问题：一个给模型「怎么做」，一个给系统「怎么接」。

你会遇到的现象

两个词分别解决什么

Skill 装的是「怎么做」。它是一份给模型的说明：做某类任务时要遵循的步骤、要用的格式、要注意的边界、可以参考的例子。它不碰任何外部系统，只影响模型「用脑子办事」的方式。

MCP 装的是「怎么调」。它是一套接口接入的标准：把你的系统（数据库、订单服务、邮件）按统一格式包装起来，让 Agent 通过一套规范就能调用这些能力。它解决的是连接问题，不管模型会不会用这些能力做事。

用一个比喻：Skill 是操作手册，MCP 是插线板。手册告诉人怎么操作，插线板让人能通上电。两件事都重要，但它们是两件事。

一个 Skill 通常由几部分组成：

触发条件。什么时候该用这个 Skill。是用户提到了相关需求，还是检测到某个动作。

步骤说明。完成这类任务要按什么顺序做。这是主体。

规范和边界。哪些不能做、格式要求、质量底线、出错怎么办。

示例。一到两个完整的输入输出例子，比任何抽象描述都有用。

只有 SKILL.md 是必需的，其余按需增补。模型先读 SKILL.md 的说明，判断要用哪部分才去展开对应文件——所以把长材料拆到子目录，比全塞进一个文件更省上下文。

所以 Skill 本质上是一份高质量的提示与参考资料。它最大的价值是组织化的：把散落在各处的最佳做法收进一个可复用的包里。改 Skill 就是改文档——不碰一行代码，改完即生效，这比改逻辑便宜得多。

这也引出它的边界：Skill 改变不了模型会不会推理。它只能让模型按更好的流程去用已有能力。若任务本身超出模型能力，Skill 写得再细也白搭。

MCP 解决的是接入的标准化问题。在它出现之前，每个 Agent 要接一个新系统，都得写一套专用的适配代码，格式五花八门。MCP 定义了一套统一的形状：

工具。外部系统暴露的可调用操作，以及各自的参数说明。

资源。可读取的数据和文件。

提示。可复用的指令模板。

对产品经理来说，MCP 最重要的含义不是协议本身，而是生态：主流系统和工具越来越多地原生提供 MCP 接口，意味着「接一个新服务」的成本大幅下降，就像 USB 取代了一堆专用线缆。

但要注意它的边界：MCP 只是把接口摆到 Agent 面前，不保证 Agent 会正确使用。工具说明写得差、权限没配好、数据不可信——这些问题 MCP 都管不了，照样会翻车。

一个实用的判断法：

问题出在「它不会做事」→ Skill。需要它遵循某种流程、格式、规范——这是知识层面的事，用 Skill 解决，改起来也便宜。

问题出在「它够不着」→ MCP（或自定义工具）。需要它真的去查数据库、发消息、操作某个系统——这是连接层面的事。系统已有 MCP 接口就用 MCP，没有就写自定义工具。

两者常常一起用。一个成熟的 Agent 通常是：MCP 提供一组外部能力，Skill 告诉它怎么把这些能力组合成一件完整的事，提示词分层管住整体的行为框架。

最后一条提醒：别为了用而用。只有一个接口要接，写个简单的工具函数就够了，不必上一整套 MCP。只有当接入的系统多、要统一管理时，MCP 才真正划算。