做 Agent 时常见两种卡法：一种是手里有 API 却不知道怎么让模型稳定调起来，另一种是能调工具但输出格式每次都不一样。MCP 和 skill 常被当成同义词，其实管的是两件事。这篇不吹概念，只讲它们各自解决什么问题、什么时候该用哪个、两个一起上时怎么分工，以及判断不适用的情况。
做 Agent 的人基本都会撞上两种卡法：一种是手里明明有 API，模型却调得七零八落，换一个客户端又得重写一遍接入；另一种是工具能调，但每次输出的格式、步骤、判断都不一样，像换了个人在干活。这两种卡法表面看都是「模型能力不够」，其实是两个不同层面的问题。
MCP 和 skill 经常被当成同义词混着说，实际管的是两件事：一个解决「模型能连到什么」，一个解决「连上之后按什么套路用」。下面按这个分界逐层拆，附选型判断和落地顺序。不吹概念，只说什么时候该动哪个，以及什么时候两个都不该动。
先分清它们各自解决什么问题
- MCP
- 连接层：把外部工具和数据源用统一协议暴露给模型，换客户端不用重写接入代码
- skill
- 行为层：把一类任务该走的步骤、输出格式、判断标准固化成一个可复用单元
打个比方：MCP 是插线板，负责让设备通上电；skill 是操作规程，负责让活干得对。插线板通电了，不代表工人会按你要的顺序拧螺丝。反过来，规程写得再细，插线板没接上，一样干不了活。
| 观察到的现象 | 大概率卡在 | 先动哪个 |
|---|---|---|
| 模型压根看不到这个数据源或工具 | 连接层 | MCP |
| 工具能调，但每次输出结构都不一样 | 行为层 | skill |
| 换个客户端就要重写一遍接入 | 连接层 | MCP |
| 同一任务三次结果差异大，主要差在表述 | 行为层 | skill |
| 只是单次调用一个简单函数 | 都不是 | 原生工具调用 |
判断分界就一句话：痛点是「模型够不着」，先看 MCP；痛点是「够得着但每次做出来不一样」，先看 skill。两个都痛的时候，别同时改，顺序在后面一节讲。
什么时候该上 MCP，什么时候是白折腾
MCP 的收益来自复用。同一个外部能力要被多个客户端、多个项目用到，或者工具数量会持续增长、接口需要统一鉴权和生命周期管理，这时候上协议才划算。反过来，只给一个客户端用、只调一两次、逻辑极简单，直接写函数调用可能更省事。
- 同一个外部能力要在多个客户端间复用，倾向 MCP
- 工具清单会持续增加，需要统一鉴权与生命周期管理，倾向 MCP
- 只服务单个客户端、调用次数屈指可数，先别上协议
- 动手前先想清楚三件事：谁维护这个 server、凭证放哪、出错时谁来兜
- 现成实现能复用就别自己写，到站内 MCP 服务器大全 对照已有清单
要注意 MCP 不保证任务正确。它只保证「模型够得着」。至于调用参数对不对、权限边界有没有越界，那是另外两件事，各有各的处理方式。另外，如果你所在环境明确不允许引入外部进程或需要离线运行，MCP 这条路本身就不适用，老老实实走原生工具调用。
skill 的价值在于把「怎么做」写死
skill 本质上是把提示词、步骤、输出格式、边界条件打包成一个可复用单元，减少每次现场发挥。它治的是「结果不稳定」，治不了「拿不到数据」。权限、网络、凭证这些问题，仍然归 MCP 或你自己的代码管。
| 做三次同类任务 | 差异来源 | 结论 |
|---|---|---|
| 结果差异主要在措辞和格式 | 表述不统一 | 用 skill 固化套路 |
| 结果差异主要在数据缺失或过期 | 拿不到数据 | 先修连接层 |
| 有时步骤顺序乱，有时格式崩 | 流程没定死 | 用 skill 写清步骤与格式 |
| 每次都卡在同一步调不通 | 工具本身不通 | 跟 skill 无关 |
判断方法很土但有效：同一类任务做三次，看差异主要来自「表述不同」还是「拿不到数据」。前者用 skill，后者用 MCP。如果差异既有又有，先修拿不到数据的那部分，因为流程写得再细也补不了空数据。
还有一点容易忽略：skill 不是越细越好。把每个字段的取值都写死，换个场景整套就废了。留出判断空间，只固化真正需要一致的环节，比如步骤顺序、输出结构、必填项、失败时的兜底动作。现成 skill 可以到站内 AI Skills 大全 对照，别自己从零编一套已经有了的。
两者一起用时，边界画在哪
推荐分工：MCP 负责取数与执行，skill 负责决定先拿什么、再算什么、最后怎么输出。这条线画清楚，两边都能单独替换：换数据源只动 MCP，换业务流程只动 skill。
- 先确认数据能拿到把 MCP 侧跑通，用最小调用验证工具能返回预期结构，拿不到数据就别往下走
- 再确认流程稳定在 skill 里把步骤、输出格式、失败兜底写清楚，同一输入跑三次看结果是否一致
- 最后才调模型质量前两步都稳定了再看模型表现，否则你分不清是模型不行还是管道不通
两种常见反模式值得记一下：一种是把业务规则塞进 MCP server 里，结果换个场景整个 server 不可用；另一种是把取数步骤写进 skill，模型只能干等。前者把行为层混进了连接层，后者把连接层的事写进了行为层，边界一乱，两边都难维护。
- MCP server 里只放取数与执行，不放业务判断
- skill 里只写流程与格式，不写具体调用凭证
- 换数据源时只动 MCP 侧，skill 不动
- 换业务流程时只动 skill 侧，MCP 不动
- 两边同时改，出了问题分不清是哪一侧的责任
- 工具调用参数报错、越权调用这类问题不属于本文范围，各自有专文
五分钟选型清单
下面这张清单按顺序问一遍，五分钟能定下来先动哪个。注意每条都给了不适用的情形，别硬套。
| 问题 | 是 | 否 |
|---|---|---|
| 外部能力需要在多个客户端或项目间复用吗 | 倾向 MCP | 看下一行 |
| 痛点是不是结果不稳定、格式不对 | 倾向 skill | 看下一行 |
| 只是单次、单客户端、简单函数吗 | 先用原生工具调用，别上协议 | 再回到第一行重新判断 |
补一句不适用的情况：如果团队只有一个人维护、工具半年才动一次，上 MCP 的维护成本可能高过收益，这时候把调用逻辑直接写在代码里反而更省心。skill 也有不适用的时候，比如任务本身就是开放式的、每次目标都不同，固化流程反而会限制模型发挥。
先修连接，再固流程，最后才怪模型——顺序错了，排查永远在原地打转。
判断这两个东西的区别，不需要记协议细节，只要记住它们站在不同层：一个管够不够得着，一个管干得对不对。真正省时间的做法是把这两层分开验证，哪层出问题查哪层。想动手接工具之前，可以先到站内工具目录看看别人是怎么做的、常见坑在哪，再决定自己那套要不要上协议。
下一步选型定下来之后，先去看现成的 MCP server 和 skill 有没有能直接复用的，别从零造轮子；站内按类别整理了可用的清单，也有接入时的排错思路。→常见问题
MCP 和 skill 能互相替代吗？
不能。MCP 管的是「模型能不能够到外部能力」，skill 管的是「够到之后怎么按规矩用」。没有 MCP，skill 常常拿不到数据；没有 skill，MCP 接上了也可能每次输出都不一样。两者是叠加关系，不是二选一。
我只有一个客户端、两三个工具，需要上 MCP 吗？
通常不需要。MCP 的收益来自复用和统一管理，工具少、客户端单一时，直接写函数调用成本更低。等工具数量上去了、或者同一能力要在多个客户端用，再考虑抽象成 server 也不迟。
skill 会不会限制模型的发挥？
会，但这正是它的用途。skill 适合流程固定、格式要求严的任务；如果任务本身需要模型自由探索，硬套 skill 反而拖后腿。判断标准是这类任务做十次，你希望十次一样还是允许不同。
