← → 翻页 · 空格前进
费曼学习法 · 第一性原理 · 三个视角

Skill 与 MCP
到底差在哪?

一个给模型接上世界,一个教模型怎么做事
本讲从"大模型究竟是什么"推起,用小学生、中学生、大学生三层讲透原理与运作流程。

MCP

模型上下文协议

一根标准插头,让模型够得到外面的数据和工具。

SKILL

智能体技能

一份可折叠的说明书,让模型按你的方法把事做对。

关系

不是二选一

它们分属两个维度,最强的用法是两个一起上。

手机端 · 卡通大图版 20 图 →

先说结论

一句话:MCP 管"能不能够到"Skill 管"会不会做"

MCP · Model Context Protocol
能力的通道

一套开放通信协议。它规定"模型这边"和"外部系统那边"如何握手、如何互相报家底、如何调用。接上以后,模型才真的能查数据库、发飞书、读文件。

  • 本质:协议 + 进程,要跑起来、要联网、要授权
  • 解决:模型被关在盒子里,够不到外部世界
  • 类比:USB-C 接口标准
SKILL · Agent Skill
方法的封装

一个文件夹:一份 Markdown 说明书,外加可选的脚本和参考资料。它不带来任何新能力,只是把"这件事在我们这儿该怎么做"写清楚,需要时才展开。

  • 本质:文字 + 文件,不需要服务、不需要联网
  • 解决:模型有手有脚,但不懂你的规矩和流程
  • 类比:入职手册 / 菜谱卡
观点:把它们放在一起比"谁更强",是个假问题——就像问"电源插座和菜谱哪个更重要"。真正的问题是:你现在缺的是通道,还是方法?
第一性原理 · 第一步

先拆到底:一个大模型,本质上是什么?

剥掉所有产品包装,它只是一个函数:文字进 → 文字出。没有手,没有眼睛,没有记忆,也不知道今天几号。

一堵看不见的墙:模型进程之外的一切,它都碰不到 大语言模型 一个纯粹的文字函数 f(上文) → 下一个词 你的文字 Prompt 它的文字 Completion 墙外有:你的数据库、文件、飞书、订单系统、公司规范、行业黑话……

事实:模型权重里存的是"读过的公共文本的统计规律",不含你公司的任何私有数据,也不含任何执行能力。

第一性原理 · 第二步

于是必然出现两个、且只有两个缺口

大语言模型 聪明,但是空的、瞎的 缺口 ① 够不到 看不到你的数据,也动不了任何东西。 "帮我查一下这个月订单" → 它只能编。 缺口 ② 不会做 不知道你们家这件事的标准做法。 "写个周报" → 写得像别人家的周报。 解法 ① MCP 给它一条标准通道, 通向真实的数据与工具。 解法 ② Skill 给它一份你的做法说明, 需要时才翻开来看。

推论:任何"让 AI 真正能干活"的方案,最终都会落在这两条路径之一。MCP 与 Skill 不是竞品,而是分别长在两个缺口上的补丁。

第一性原理 · 第三步

所以:一个横向扩能力,一个纵向补方法

MCP → 扩展"能做什么"

加一个 MCP Server,模型的动作集合就变大一圈:本来只会说话,现在会查库、会建日程、会提交代码。

增加的是动词

Skill → 提升"做得多好"

加一个 Skill,模型的能力边界不变,但它在这件事上的判断、顺序、口径、避坑,都跟你们家对齐了。

增加的是副词

批判性提醒:很多团队一上来就堆 MCP,装了十几个 Server,结果模型工具选错、参数填错、流程乱套——那是方法缺口,堆再多通道也补不上。反过来,只写 Skill 不接 MCP,模型说得头头是道,一到落地就"我无法访问"。
第一讲 · 讲给小学生

把 AI 想成一个被关在空厨房里的大厨

他手艺很好,什么菜都听说过。但是——厨房里空空的,而且他不知道你们家口味。

空厨房 大厨 = AI 手艺一流 但手上没东西、心里没数 ① 先接上管道和插座 = MCP 🧊 冰箱 = 你的数据、文件 🔥 烤箱 = 能真的干活的工具 📦 送货窗口 = 发消息、下单、提交 ② 再给一张菜谱卡 = Skill 📋 妈妈的红烧肉菜谱 1. 五花肉切两指宽 2. 冰糖炒糖色,别炒糊 3. 小火 40 分钟 4. 我们家不放八角 → 平时收在抽屉里,做这道菜才拿出来 菜谱不会变出食材, 但它决定这盘菜好不好吃。
第一讲 · 为什么两个都要

有没有管道 × 有没有菜谱,结果差很远

→ 有 MCP(能拿到东西) → 有 Skill(知道怎么做) 📖 只有菜谱,没有食材 "红烧肉要小火四十分钟"——说得很对, 但是他手上一块肉也没有。 现实里:AI 侃侃而谈,一让它查真实数据就说"我无法访问"。 🍲 又有食材,又有菜谱 ← 目标 拿得到、也做得对。 端上来的是你们家那个味道。 现实里:AI 自己去系统取数,按你们的口径出报告。 🚪 空厨房 既没东西,也不知道你想吃啥。 只能凭想象,容易"编"。 现实里:裸模型直接聊天,什么都靠猜。 🔪 食材满地,乱做一气 冰箱塞满、烤箱开着,但他不知道先后顺序, 拿错锅、放错料,每次做出来都不一样。 现实里:装了一堆 MCP,模型选错工具、参数乱填。
第一讲 · 记住这一句

MCP 是 把厨房接通水电煤,
Skill 是 把菜谱贴在墙上。

接通水电煤,靠的是统一的插头标准——不管哪个牌子的冰箱,插头都一样,所以能随便换。

贴菜谱,靠的是写清楚——而且平时折起来不占地方,做这道菜的时候才展开。

检验方法:问自己"AI 现在够得到那个东西吗?"够不到 → 你缺 MCP。

检验方法:问自己"AI 做得对吗、稳定吗?"每次都跑偏 → 你缺 Skill。

第二讲 · 讲给中学生 · MCP 的由来

MCP 要解决的真问题:接口爆炸

在 MCP 出现之前,每个 AI 应用要接每个外部系统,都得单独写一遍适配代码。3 个应用 × 4 个系统 = 12 套。加一个系统,所有人重写一遍。

没有标准:M × N 套私有对接 AI 应用 A AI 应用 B AI 应用 C 数据库 飞书 GitHub 文件系统 新增 1 个系统 → 3 个应用各改一次 有了 MCP:M + N 套标准对接 AI 应用 A AI 应用 B AI 应用 C MCP 统一协议 数据库 飞书 GitHub 文件系统 新增 1 个系统 → 只写一个 Server,所有应用即插即用

事实:MCP 由 Anthropic 于 2024 年 11 月开源发布,定位就是"AI 应用的 USB-C 接口"。目前 OpenAI、Google DeepMind 等也已支持。

第二讲 · MCP 怎么运作

一次握手,交换三样东西

AI 客户端 Claude / IDE… MCP Server 飞书 / 数据库… ① 你好,我支持这些能力 ② 我有这些工具,用法如下 ③ 调用 send_message(…) ④ 执行结果 / 报错 全程 JSON-RPC 2.0 消息

🔧 Tools(工具)

模型可以主动调用的动作:发消息、建记录、跑查询。会改变世界,所以通常需要你授权。

📄 Resources(资源)

可以被读取的内容:文件、表格、日志。只读,像给模型开一个文件柜。

💬 Prompts(提示模板)

服务方预置的标准问法,用户可以一键调用。

关键点:工具的说明书(名字、参数、干什么用)会被塞进模型的上下文里。装得越多,占用越大——这也是 MCP 的代价。
第二讲 · Skill 怎么运作

Skill 朴素得令人意外:就是一个文件夹

📁 周报生成/ 📄 SKILL.md ← 必需,唯一的入口 开头几行写:叫什么名字、什么时候该用我 📁 references/ ← 可选 口径定义、历史范例、字段说明 📁 scripts/ ← 可选 确定性的活儿交给代码,比模型算得准

没有服务,没有端口

不用启动进程、不用配密钥。放进目录,模型就能"看见"它。

写给模型看的文档

内容就是自然语言:先做什么、后做什么、什么情况停下来问人、哪些坑千万别踩。

组织的经验沉淀

老员工脑子里那套"我们这儿都是这么干的",第一次变成可复制、可版本管理的资产。

所以 Skill 的门槛在于你说不说得清,不在于技术。写不清楚,是因为流程本来就没想清楚。
第二讲 · Skill 的核心机关

渐进式披露:像折叠的地图,用到哪儿展开哪儿

模型的注意力是有限且昂贵的。如果把一百个 Skill 全文塞进去,它会被淹没。所以 Skill 设计成三层,按需展开。

第 1 层 名字 + 一句话描述 开机就常驻在上下文里,只有几十个字,模型靠它判断"这活儿归不归我管" ≈ 几十 tokens 判断相关 → 才加载 第 2 层 SKILL.md 正文 完整流程、判断标准、注意事项。命中任务时才整篇读进来 ≈ 几千 tokens 需要细节 → 再打开 第 3 层 参考资料与脚本 附录文档、样例、可执行代码。模型自己决定要不要读、读哪一段 理论上无上限

这就是 Skill 与"把规范全写进系统提示词"的根本差别:前者按需,后者常驻。规范一多,后者必然挤爆上下文。

第二讲 · 一次真实任务

它们如何配合:Skill 指挥MCP 出手

👤 你 🧠 模型 📋 Skill《周报规范》 🔌 MCP Server(飞书 / 数据库) ① "把这周的周报写了" ② 描述命中 → 展开这份 Skill ③ 返回流程:先取数 → 再按口径归类 → 最后固定格式 ④ 按流程调用工具:查本周订单数据 ⑤ 返回真实数据 ⑥ 交付:数据是真的,格式和口径是你们家的 缺 ④⑤ → 数据靠编;缺 ②③ → 格式和口径每次都不一样。
第二讲 · 一张表看完

八个维度硬碰硬

维度MCPSkill
本质通信协议 + 运行中的服务一个文件夹(Markdown 为主)
解决够不到外部世界不懂你的做法与规矩
提供新的能力(动词)新的方法(怎么做、什么顺序)
加载连接后,工具清单常驻上下文三层渐进式披露,用到才展开
做出来要写代码、部署、配授权把话说清楚,会写文档就行
失败长这样连不上 / 超时 / 没权限连得上但做得不对、每次不一样
谁来做工程团队业务专家本人
类比USB-C 插头标准入职手册 / SOP / 菜谱

观点:这张表里最被低估的一行是"谁来做"。MCP 是工程资产,Skill 是业务资产——它第一次让不写代码的人也能直接改造 AI 的行为。

第三讲 · 讲给大学生 · MCP 的工程剖面

MCP=一套 C/S 架构 + JSON-RPC 2.0 + 能力协商

Host 宿主应用 Claude Code / Desktop / 你自己的 Agent Client 1 (持有一个连接与会话) Client 2 Client 3 Host 负责:权限、用户确认、多 Server 编排 1 : 1 有状态会话 Server · 飞书 Server · Postgres Server · 文件系统 SaaS API 数据库 本地磁盘 协议层:JSON-RPC 2.0  · initialize 握手时双方声明 capabilities · tools / resources / prompts 三类原语 传输层:stdio(本地子进程) · Streamable HTTP(远程,可 SSE 流式;旧版 HTTP+SSE 已弃用)

有状态:连接是长会话,Server 可反向发通知(如工具列表变了)。

反向原语:Server 也能反过来请求 Host——sampling(借模型)、elicitation(问用户)、roots(问目录)。

安全边界在 Host:协议本身不替你做授权,工具调用的确认与权限必须由宿主把关。

第三讲 · Skill 的工程剖面

Skill=在有限注意力预算里做调度

上下文窗口是有限资源,且模型对长上下文的利用效率会衰减。真正的约束不是"能不能塞下",而是"塞进去还找不找得到"。

情形 A:接入 10 个 MCP Server(约 150 个工具) 系统提示 工具定义常驻 · 每个工具的名称/描述/参数 schema 都要占位 对话历史 剩余可用 情形 B:装 10 个 Skill 系统提示 名称+描述 命中的那一个才展开正文 对话历史 剩余可用 结论:MCP 的成本随接入数量线性增长且常驻;Skill 的常驻成本近似恒定,重量在触发后才付。

可组合:一个 Skill 可以在正文里指名调用某个 MCP 工具;反过来 MCP 无法规定流程。依赖是单向的。

可执行:确定性的活儿(改图、算数、格式转换)写成脚本,比让模型"想"更准更省。

可版本化:它是纯文本,天然进 Git。组织流程第一次有了 diff 和 code review。

第三讲 · 为什么说它们正交

它们根本不在同一层上

④ 编排层 Agent 循环 决定这一步该想、该查、还是该动手;何时停下来问人 ③ 方法层 Skill 这件事的正确做法:顺序、口径、判据、禁区、交付格式 ② 能力层 MCP(以及内置工具:读写文件、执行命令) 可被调用的动作全集,以及可被读取的资源全集 ① 模型层 权重 通用语言与推理能力,训练完就固定了 依赖单向:③ 方法层可以点名调用 ② 能力层,② 完全不感知 ③。替换任意一层,其余层不必改动——这正是"正交"的工程含义:升级模型不用重写 Skill,换掉数据库 Server 也不用重写流程。
落地 · 怎么选

三个问题,定位你到底缺什么

你的任务 先问第一个问题 三个问题依次自查 Q1 需要碰到外部系统吗? 取数、发消息、写库、跑命令 → 你缺 MCP(或内置工具) 先把通道打通,否则一切流程都是空谈 Q2 结果总跑偏、不稳定? 口径不对、格式每次不同、漏步骤 → 你缺 Skill 把老手的做法写下来,比换更大的模型有用 Q3 这活儿要反复干? 每周、每个人、每个项目都要来一遍 → 两个都要,并且要沉淀成资产 Skill 写流程 + MCP 供能力,进 Git,团队共享 顺序建议:先用最笨的方式把事跑通 → 观察它在哪儿反复出错 → 只把出错的那部分固化成 Skill。不要一上来就设计大而全的体系。
批判性思考 · 五个常见误解

这些说法,听着顺,其实不对

❌ "Skill 是来取代 MCP 的"

✅ 两者维度不同。Skill 不提供任何新能力;很多 Skill 的流程里第一步就是调 MCP 工具。取代关系不成立。

❌ "MCP 装得越多,Agent 越强"

✅ 工具定义常驻上下文,装多了会挤占注意力、增加选错工具的概率。接入是有成本的,要挑。

❌ "Skill 就是提示词模板"

✅ 提示词是一次性输入;Skill 是带触发条件、可分层加载、可携带脚本与资料的持久资产,还能进版本库。

❌ "接了 MCP 就安全可控了"

✅ 协议不负责授权。第三方 Server 拿到的是真实权限,工具返回的内容还可能藏提示注入。信任边界必须自己划。

❌ "写 Skill 是工程师的活"

✅ 恰恰相反。Skill 的价值密度来自业务判断——哪些坑要避、什么情况该停下来问人、口径怎么算。这些只有做这件事的人知道。工程师能写出格式正确但没营养的 Skill。

收尾

把整讲折回一句话

MCP

让 AI 够得着

把模型接进真实世界的标准插头。没有它,一切都是纸上谈兵。

SKILL

让 AI 做得对

把你们家的做法写下来。没有它,能力越大跑偏越远。

小学生:插座 vs 菜谱

中学生:M+N 通道 vs 三层折叠说明书

大学生:能力层协议 vs 方法层上下文工程

资料来源(均为公开一手文档,2026-08-22 核对):
· Model Context Protocol 官方规范与文档 modelcontextprotocol.io (Anthropic 于 2024-11 开源发布)
· Anthropic《Introducing the Model Context Protocol》,anthropic.com/news/model-context-protocol
· Anthropic Agent Skills 工程文档与《Equipping agents for the real world with Agent Skills》,anthropic.com/engineering
· Claude Docs · Agent Skills / MCP 章节,docs.claude.com
本页中标注为"观点""提醒"的内容为作者判断,非官方结论。