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 由两部分组成：

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

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

# PDF 处理

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

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

其中 name 和 description 是必填项：

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

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

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 的行为。

例如：

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

这些规则可能存在于：

• 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，自动沉淀出属于你自己的工作流。