MCP 是接口，Skill 是手册

如果你在 2026 年的技术群里问"MCP 和 Skill 该用哪个"，大概率会得到三种回答：一种说 MCP 是协议、Skill 是应用；一种说 Skill 会取代 MCP；还有一种说都上。

三种回答都错过了问题的形状。这从来不是一道选择题——它更像在问"该用 USB，还是该写说明书"。

一句话分清

MCP 回答的是"Agent 能不能碰到这个系统"。

Skill 回答的是"它知不知道正确做法"。

用两个具体的动作对比：

你想让 Agent 查 Jira 上的工单。它需要知道"Jira 在哪、怎么认证、用什么接口查"——这是 MCP 的活。一个 Jira MCP Server 接上去，Agent 就获得了这个能力。
你想让 Agent 从一堆工单里提取需求、写成规格文档、按模板评审。它需要知道"这个团队认为什么算好需求、评审要看哪几项、格式长什么样"——这是 Skill 的活。

前者的失败表现是"我查不到"；后者的失败表现是"我查到了，但做得不对"。

一个更形象的比喻：MCP 让 Agent 长出手，Skill 让它学会套路。

MCP：一份给工具的接口契约

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月 25 日发布的开放协议。它解决的是一个具体的乘法问题。

在它出现之前，如果你有 3 个 Agent、5 个要接入的系统，你得写 15 套对接代码；每加一个 Agent 或一个系统，工作量都要重算。MCP 把这个 N×M 变成了 N+M：系统方各写一个 Server，Agent 方各实现一个 Client，中间按协议通信。

三层概念

层	是什么	谁负责
Server	把某个系统的能力包装成标准工具	系统提供方，或社区
Client	在 Agent 侧连接 Server、调用工具	Agent 框架，或你自己
传输	Server 与 Client 之间的通信方式	协议规定（stdio 或 Streamable HTTP）

Server 暴露三类原语：Tools（可调用的动作）、Resources（可读取的数据）、Prompts（预设的提示模板）。日常用得最多的是 Tools，但 Resource 与 Tool 的分离很重要——它让"读"和"做"在权限上可以分开管。

2026 年的生产化

2024 年发布时，MCP 更像一份规范而非基础设施。2026 年 7 月 28 日的版本做了几件关键的事：

无状态化：Server 不再依赖会话状态，可以水平扩展，一个请求打到哪里都行
确定性工具顺序：规范要求 Server 以稳定顺序返回工具（原文："Servers should return tools in a stable order"）
明确中间层边界：网关、代理这类中间件，能持有什么、不能持有什么，有了明确规定

这三件事听起来平淡，但它们是从"能演示"到"能上生产"的分水岭。无状态解决了扩容，确定顺序解决了缓存与可复现性，中间层边界解决了安全审计。

设计 MCP Server 的四个建议

第一，粒度对齐"一次判断"，不对齐接口。 不要因为后端有 list_contacts 这个接口，就把它原样暴露成工具。Agent 需要的通常是"按条件找一个联系人"，那就给 search_contacts，而不是让它拉全量再自己筛。

第二，返回要精简，别把原始 JSON 直接吐出去。 工具返回的每一个字段都在消耗上下文。把 UUID 换成语义化的名字、去掉用不上的技术字段，这一改动对检索精度的提升，比换模型更明显。

第三，错误信息要写给模型看。 不要返回 500 Internal Error。返回"查询失败：项目键 ABC 不存在，可用的项目键有……"。模型读到这句话，才知道下一步该改什么。

第四，按域命名空间。 jira_search、jira_create、jira_transition 比三个各自叫 search、create、transition 的工具好得多——后者在有多个系统时会立刻混淆。

MCP 的边界

MCP 不是万能的，它有三个明确的代价：

上下文成本：工具定义会常驻在上下文里。接上二十个 Server 之后，光是工具描述就可能吃掉几千 token，而这些 token 每一轮都要重发
权限扩散：每接一个 Server，就多一处需要审计的权限入口。接得越多，攻击面越大
工具膨胀：这是最隐蔽的一个。当同屏候选工具超过五六个，模型选错的概率就开始上升

第三条有个实用的判据，值得刻在墙上：

如果人类工程师都无法确定该用哪个工具，就不能指望 AI 做得更好。

Skill：把"怎么做"变成可维护的资产

Skill 是 Anthropic 在 2025 年 10 月提出的机制，同年 12 月 18 日成为开放标准。

它的形态朴素得让人意外：一个文件夹，里面一个 SKILL.md，加上任意数量的辅助文件。 就这么简单。

官方的类比很准：给 Agent 搭一个 Skill，就像给新员工准备一份入职手册。

三层渐进式披露

这是 Skill 最关键的设计，也是它区别于"更长的提示词"的地方。

层级	内容	何时进入上下文
第一层	`name` + `description`（YAML 元数据）	启动时全部预载
第二层	`SKILL.md` 正文	模型判断相关时读入
第三层	附加文件（参考文档、脚本、模板）	真正需要时才读

这套设计的效果是：Skill 里能打包的上下文，实际上是无上限的。

因为第一层只放一两句话的摘要，几十个 Skill 同时存在也只占很少的上下文；真正的内容只在被触发时才加载。

这也是它和"把流程写进系统提示词"的根本差别：后者是常驻成本，前者是按需成本。

代码作为工具

Skill 可以带脚本，让模型在需要时执行。

这解决了一个真实的矛盾：某些操作，用传统代码做比用 token 生成便宜几个数量级。

官方举的例子很典型：处理 PDF 表单。让模型"读"表单字段既费 token 又容易错；但如果在 Skill 里放一个 Python 脚本提取字段，模型只需要调用它——脚本和 PDF 都不进入上下文，而结果是确定性的、可重复的。

所以 Skill 是一个混合体：知识部分（Markdown）给理解，代码部分（脚本）给确定性。

写 Skill 的四条纪律

第一，从评估开始，别凭想象。 先让 Agent 跑一批真实任务，看它在哪里出错，再针对性地建 Skill。凭空设想的 Skill 往往解决的是不存在的问题。

第二，为扩展而组织。 SKILL.md 一旦超过几百行，就该拆文件。互斥的上下文要分开存，否则每次触发都加载一堆用不上的内容。

第三，从 Agent 的视角审视。 观察它怎么用你的 Skill：有没有走意外路径？有没有过度依赖某个字段？这些观察比你自己读一遍有效。

第四，和 Agent 一起迭代。 让它把成功的做法、常见的错误写进 Skill。这是 Skill 能持续变好的唯一方式。

Skill 的边界：两个被忽略的前提

第一个前提：Agent 必须有文件系统访问能力。

渐进式披露依赖"按需读取文件"。如果一个 Agent 只能调 API、没有 shell 或文件工具，那 Skill 就只能被一次性全文塞进去——它的核心优势直接消失。

这个前提在中文讨论里几乎没人提，但它决定了 Skill 只对"有环境访问权的 Agent"有效。

第二个前提：你得信任 Skill 的来源。

Anthropic 自己在官方文里写了这句话：

恶意 Skill 可能在使用环境中引入漏洞，或引导模型外泄数据、执行意外操作。

这不是理论风险。Skill 是"指令 + 可执行脚本"的组合，等于给 Agent 开了一个可以自定义行为的后门。所以安装第三方 Skill 之前，至少要审计它的脚本内容和网络请求。

为什么这是个伪问题

把两者放在一张表里，答案就清楚了：

维度	MCP	Skill
本质	连接协议	知识打包格式
格式	JSON-RPC	Markdown + YAML
解决	能不能碰	知不知道怎么做
状态	有状态连接（2026 版趋向无状态）	无状态文件
认证	内置 OAuth 与 scope	继承宿主权限
加载	工具定义常驻	渐进式披露
规模	对接大量外部系统	沉淀领域工作流

它们不在同一个抽象层上。MCP 是接口层，Skill 是流程层。 问"该用哪个"，等同于问"该写驱动程序还是该写用户手册"。

有实测数据印证这一点。2026 年 10 月，有人在 Bedrock + Strands 上做了一组对比，结论很干脆：

只有 MCP 没有 Skill：Agent 能拿到真实数据（知道耳机卖 249 美元、正在打折），但用错方式。

只有 Skill 没有 MCP：Agent 知道正确流程，但拿不到真实数据。

两者结合：错误率显著下降。

另一篇分析把这句话总结得更漂亮："它们合起来才减少错误——Agent 既知道能做什么，也知道该怎么做。"

什么时候用什么：决策树

你要解决的问题是什么？  
│  
├─ 让 Agent 连上一个外部系统（数据库、API、SaaS）  
│   └─ 用 MCP  
│       理由：标准化、有认证、可复用、生态大  
│  
├─ 教 Agent 一套这个团队特有的做法  
│   └─ 用 Skill  
│       理由：轻量、可读、渐进式披露、易版本管理  
│  
├─ 两件事都要  
│   └─ MCP 管连接 + Skill 管流程（推荐组合）  
│       例：MCP 提供 jira_search，  
│           Skill 教"如何从 issue 里提取需求并写 spec"  
│  
└─ 只是想给 Agent 一段固定指令  
    └─ 直接写系统提示词，别上 Skill

最后一条经常被忽略。Skill 的价值在"复用"和"按需加载"，如果一段指令只用一次、只有二十行，写进系统提示词就够了——为它建一个 Skill 是过度设计。

三条实用判断

第一，先看有没有现成的 MCP Server。

2026 年中，MCP 生态大约有两万个 Server，覆盖了主流 SaaS。在自建之前，先搜一遍——大部分"我需要一个工具"的需求，已经有人做过了。

第二，Skill 该不该建，看复用次数。

同一套流程会被用三次以上，才值得建成 Skill。只用一两次的，写进提示词或者直接手工做，成本更低。

第三，两者的投入时机不同。

MCP 处在"标准化 → 商品化"之间，是投入的最佳窗口——现在接入，未来能吃到生态红利。Skill 处在标准化初期，规范有了但生态还在长，适合先把团队内部的流程沉淀下来。

结语

这场"MCP vs Skills"的争论，九成是命名之争，一成是技术之争。

"Skill"这个词太宽泛，容易被理解成"另一种 MCP"。实际上一个比喻就能分开：MCP 是接口，Skill 是手册。

争论之所以持续，是因为两边都在抢生态位——谁定义标准，谁受益。但从工程角度看，这从来不是二选一：

你既要让 Agent 能碰到系统，也要让它知道碰了之后该做什么。缺一个，另一个的价值都发挥不出来。

参考来源：Anthropic《Writing effective tools for agents》(2025-09-11)、《Equipping agents for the real world with Agent Skills》(2025-10-16)、《Effective context engineering for AI agents》(2025-09-29)；MCP 2026-07-28 版本说明；FactualMinds 在 Bedrock + Strands 上的对比实测(2026-10-23)；Codersarts《Skills and MCP: Understanding the Difference》(2026-10-23)。