Skill 与 MCP | Agent 与 Skill | 做产品
Skill 与 MCP
这两个词经常被当成同一个东西。但它们解决的是两类完全不同的问题：一个给模型「怎么做」，一个给系统「怎么接」。
你会遇到的现象
-
文档里两个词混着写，会上讨论半天才发现说的是两件事
-
以为装了 MCP 模型就会做事了，结果它还是不会
-
想「让 Agent 会写周报」，不知道该做成 Skill 还是 MCP
两个词分别解决什么
**Skill 装的是「怎么做」。**它是一份给模型的说明：做某类任务时要遵循的步骤、要用的格式、要注意的边界、可以参考的例子。它不碰任何外部系统，只影响模型「用脑子办事」的方式。
**MCP 装的是「怎么调」。**它是一套接口接入的标准：把你的系统（数据库、订单服务、邮件）按统一格式包装起来，让 Agent 通过一套规范就能调用这些能力。它解决的是连接问题，不管模型会不会用这些能力做事。
用一个比喻：**Skill 是操作手册，MCP 是插线板。**手册告诉人怎么操作，插线板让人能通上电。两件事都重要，但它们是两件事。
Skill 怎么组织
一个 Skill 通常由几部分组成：
**触发条件。**什么时候该用这个 Skill。是用户提到了相关需求，还是检测到某个动作。
**步骤说明。**完成这类任务要按什么顺序做。这是主体。
**规范和边界。**哪些不能做、格式要求、质量底线、出错怎么办。
**示例。**一到两个完整的输入输出例子，比任何抽象描述都有用。
一个 Skill 就是一个文件夹，打开来几乎全是文本
写周报/
必需 触发条件 + 步骤说明，主体在这里
reference/
可选 规范、边界、术语表——用到才读
examples/
可选 一两个完整的输入输出，最管用
scripts/
可选 确定性的活交给代码，别让模型算
改 Skill = 改文档，不碰一行代码 模型只在需要时才展开读，不占常驻上下文
只有 SKILL.md 是必需的，其余按需增补。模型先读 SKILL.md 的说明，判断要用哪部分才去展开对应文件——所以把长材料拆到子目录，比全塞进一个文件更省上下文。
所以 Skill 本质上是一份高质量的提示与参考资料。它最大的价值是组织化的：把散落在各处的最佳做法收进一个可复用的包里。改 Skill 就是改文档——不碰一行代码，改完即生效，这比改逻辑便宜得多。
这也引出它的边界：Skill 改变不了模型会不会推理。它只能让模型按更好的流程去用已有能力。若任务本身超出模型能力，Skill 写得再细也白搭。
MCP 解决什么
MCP 解决的是接入的标准化问题。在它出现之前，每个 Agent 要接一个新系统，都得写一套专用的适配代码，格式五花八门。MCP 定义了一套统一的形状：
**工具。**外部系统暴露的可调用操作，以及各自的参数说明。
**资源。**可读取的数据和文件。
**提示。**可复用的指令模板。
对产品经理来说，MCP 最重要的含义不是协议本身，而是生态：主流系统和工具越来越多地原生提供 MCP 接口，意味着「接一个新服务」的成本大幅下降，就像 USB 取代了一堆专用线缆。
但要注意它的边界：**MCP 只是把接口摆到 Agent 面前，不保证 Agent 会正确使用。**工具说明写得差、权限没配好、数据不可信——这些问题 MCP 都管不了，照样会翻车。
什么时候用哪个
一个实用的判断法：
**问题出在「它不会做事」→ Skill。**需要它遵循某种流程、格式、规范——这是知识层面的事，用 Skill 解决，改起来也便宜。
**问题出在「它够不着」→ MCP（或自定义工具）。**需要它真的去查数据库、发消息、操作某个系统——这是连接层面的事。系统已有 MCP 接口就用 MCP，没有就写自定义工具。
**两者常常一起用。**一个成熟的 Agent 通常是：MCP 提供一组外部能力，Skill 告诉它怎么把这些能力组合成一件完整的事，提示词分层管住整体的行为框架。
最后一条提醒：**别为了用而用。**只有一个接口要接，写个简单的工具函数就够了，不必上一整套 MCP。只有当接入的系统多、要统一管理时，MCP 才真正划算。
工具调用 MCP 之上的那层基础机制，工具到底怎么被调用。
提示词的分层 Skill 里的内容，最终要落到提示词的哪一层。
多 Agent 协作 能力组织起来之后，怎么分工才是下一步。