背景
我们知道，以前的大模型只能在聊天框里跟人一问一答。它虽然懂得多、也很全面，但它的知识有几个天然的“盲区”：
- 时效性：它是用过去某个时间点之前的数据训练出来的，这个时间点之后发生的事（比如今天的新闻、某个库的最新版本）它一概不知道。
- 私有数据：你公司内部的数据库、你电脑里的文件，它同样看不到。
一旦问到它不知道的内容，它往往不会老实说“我不知道”，反而会一本正经地胡编乱造——这就是常说的“幻觉”。
工具
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 看的具体操作步骤。
--- 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，自动沉淀出属于你自己的工作流。
