AI 中的 MCP、Skills、Rules 到底是什么？

背景

我们知道，以前的大模型只能在聊天框里跟人一问一答。它虽然懂得多、也很全面，但它的知识有几个天然的"盲区"：

时效性：它是用过去某个时间点之前的数据训练出来的，这个时间点之后发生的事（比如今天的新闻、某个库的最新版本）它一概不知道。
私有数据：你公司内部的数据库、你电脑里的文件，它同样看不到。

一旦问到它不知道的内容，它往往不会老实说"我不知道"，反而会一本正经地胡编乱造------这就是常说的"幻觉"。

工具

Function Call

那要怎么补上这些盲区？人们想到的办法是：得让大模型学会使用工具，比如让它上网搜索、查数据库，去拿到自己知识库之外的内容。

2023 年 6 月，OpenAI 在一次 API 更新中正式推出了 Function Call（函数调用）的概念

模型负责"决定用哪个工具、传什么参数"，真正干活的还是外部代码。

MCP 的出现

在 MCP 出现之前，不同大模型厂商的 Agent 框架都有自己的一套 tool 接口。这些方案有一个共同的问题：

每个模型 ✖️ 每个工具，都要单独适配一次。

假设有：

N 个 AI 应用（Claude、ChatGPT、DeepSeek......）
M 个工具（GitHub、数据库、浏览器等）

那么就需要维护 N ✖️ M 套集成，数量一上去就是灾难。

于是 Anthropic 在 2024 年 11 月开源了 MCP（Anthropic，2024），希望像 USB-C 接口一样把这件事统一起来：

一个工具只要实现一次 MCP server，任何支持 MCP 的 AI 客户端都能调用它。

Skills

在使用各类 Agent 工具的时候，AI 往往没法一次就按你的想法把需求做完，于是我们得不断地"纠正"它。可等到下一次再让它做类似的需求时，它早就忘了上次的流程，我们只能从头再"调整"一遍。Skills 的出现，就是为了把"完成某项需求的工作流"封装成一个可复用的技能模块，省下这些重复劳动。

Skills 的结构

一个 skill 本质上就是一个文件夹 ，里面最核心的文件是 SKILL.md。它就像你给新同事写的一份"入职指南"：告诉 AI 这件事该怎么做、用到哪些工具、有哪些参考资料。

SKILL.md 由两部分组成：

开头的 YAML 元数据（frontmatter）：用来描述这个技能"是什么"以及"什么时候该用"。
下面的正文：给 AI 看的具体操作步骤。

markdown 复制代码

---
name: pdf-processing
description: 从 PDF 中提取文字和表格、填写表单、合并文档。当用户提到 PDF、表单或文档抽取时使用。
---

# PDF 处理

## 操作步骤
用 pdfplumber 提取 PDF 文字......

## 示例
[具体的使用例子]

其中 name 和 description 是必填项：

name：技能名，最多 64 个字符，只能用小写字母、数字和连字符。
description：既要说清楚"这个技能能做什么"，也要说清楚"什么时候用它"------这句话直接决定了 AI 能不能在合适的时机想起这个技能。

除了 SKILL.md，一个技能还可以捆绑额外的文件，常见的有三类：

text 复制代码

pdf-skill/
├── SKILL.md          # 主说明（必需）
├── FORMS.md          # 填表单的详细指南（指令）
├── REFERENCE.md      # 完整 API 参考（指令）
├── scripts/
│   └── fill_form.py  # 可直接运行的脚本（代码）
└── templates/
    └── invoice.json  # 发票模板等参考资料（资源）

指令（Instructions）：额外的 markdown 文件，写一些更细的流程和最佳实践。
代码（Code）：可以直接运行的脚本，把确定性的操作交给程序，结果稳定又不占用上下文。
资源（Resources）：数据库结构、API 文档、模板、示例等参考资料。

不过这些参数内容根本不用记。因为这个技能我们压根不需要手写：只要正常用 Agent"鞭策"它把需求做完，再让它把整个过程总结成一份 skill 就行，这样就能自动攒出一份专属于你自己的工作流。

Skills 的执行过程

你可能会担心：要是装了几十个技能，是不是一开始就把 AI 的"脑容量"（上下文窗口）撑满了？

并不会。skills 的精髓在于 渐进式披露（Progressive Disclosure）------内容分层、按需加载，用到哪一层才读哪一层。

层级	什么时候加载	内容
第一层：元数据	启动时就加载	frontmatter 里的 `name` 和 `description`
第二层：正文指令	技能被触发时	`SKILL.md` 的正文
第三层：资源与代码	真正需要时	捆绑的其他文件，通过命令行读取/执行，内容不进上下文

Rules

rules 指的是：

通过显式规则约束 Agent 的行为。

例如：

text 复制代码

- 回复必须使用中文
- 修改代码前先生成计划
- 未经确认不能删除文件
- 遇到不确定的问题先搜索文档

这些规则可能存在于：

System Prompt（Agent 开发时写死）
Agent 配置文件 （例如 Claude Code 的 CLAUDE.md）
IDE 的 AI 配置 （例如 Cursor 的 .cursorrules）

和 Skills 最大的区别在于触发方式：Skills 是"需求匹配上了才按需加载"的工作流，而 rules 在 Agent 里通常是一直生效的，会持续约束它的每一步行为。

总结

这四个东西其实处在不同层面，并不互相替代，而是层层叠加：

概念	解决什么问题
Function Call	让模型能"决定调用工具"
MCP	统一工具的接入方式
Skills	复用一整套工作流
Rules	持续约束模型行为

Function Call 让模型"会用工具"

MCP 让工具"好接入"

Skills 让流程"能复用"

Rules 让行为"有边界"

常见疑问

MCP 取代 Function Call 了吗？

没有。Function Call 解决的是"模型怎么决定调用哪个工具"，MCP 解决的是"工具怎么被统一地暴露和连接"，二者是上下两层的关系，配合使用。

装很多 Skills 会不会撑爆上下文？

不会。靠渐进式披露分层加载，启动时只读每个技能的 name 和 description，真正用到时才加载正文，资源和脚本则更晚才读。

Skills 和 Rules 有什么区别？

Skills 是"需求匹配才触发"的可复用工作流，偏向"怎么把某件事做好"；Rules 通常一直生效，偏向"做任何事都要守的约束"。

我需要自己手写 Skills 吗？

不必。最省事的做法是先用 Agent 把某个需求做完，再让它把整个流程总结成一份 skill，自动沉淀出属于你自己的工作流。