从函数到 Skills：这两年 AI 名词演进的完整故事

你有没有这种感觉 —— AI 领域的新名词,比手机型号更新还快?

昨天刚搞懂「函数调用」(Function Calling) 是怎么回事,今天又冒出来个「Skills」。前天有人跟你说「MCP」,你还没反应过来,后天又有人聊「Agent」。每次看到这些词,第一反应都是：我是不是又落伍了?

别慌。今天咱们把这几年的事儿掰开揉碎了讲清楚。

更重要的是,我会告诉你这些概念之间到底是什么关系。你会发现,这不是一堆孤立的新词,而是一层一层往上搭的台阶。搞懂了这个演进逻辑,以后再出什么新词,你也能自己判断它在哪一层。

AI 技术演进

第一层：起点 - 编程里的「函数」

咱们从最熟悉的东西开始：编程里的「函数」。

你可以把函数理解成一个「小助手」。你告诉它要做什么（给它一个输入）,它帮你做完后告诉你结果（给你一个输出）。就像餐厅里的服务员：你点菜,他端菜,每次都按照固定流程来。

举个例子,程序员写一个叫 calculate_tax(income) 的函数。你把收入数字扔进去,它把该交多少税算出来还给你。下次还要算?再调用一遍就行。不用每次都重写一遍算税的逻辑。

函数的价值,说白了就三个字：封装、重用、标准化。

把一件事情的做法「打包」起来,以后谁都能用,每次用的方式都一样。这是程序员几十年来最基本的生产力工具。

但函数有个局限 —— 它只活在代码世界里。

程序员在代码里写 getWeather(),这个函数 100% 会被执行。可是普通人不会写代码,AI 也不会直接「运行」这些代码。那怎么让 AI 也能用上这些「小助手」呢?

第二层：架桥 - Function Calling（2023 年）

2023 年前后,一个叫「函数调用」（Function Calling）的概念火了起来。

你可以把它理解成：给 AI 配备了一个「任务派遣中心」。

以前的 AI,你问它「今天北京天气怎么样」,它要么从训练数据里瞎猜一个,要么老老实实说「我不知道」。因为它没有「手脚」,不能真的去查天气。

有了函数调用之后,情况变了。

开发者事先告诉 AI：「现在你有一个任务派遣中心,里面有个叫 get_weather 的专业小助手,你想查天气就派他去查。」AI 收到「今天北京天气怎么样」的问题后,它会自己判断：「哦,这个问题我得派遣 get_weather 小助手去查才能回答。」

然后它生成一段标准格式的「便签」（叫 JSON）,上面写着：

{
  "function": "get_weather",
  "arguments": {
    "city": "北京"
  }
}

这段便签被外部程序接收、解析、执行。真正去气象台查数据的,是那个被派遣的小助手（外部程序）,不是 AI 自己。执行完后,结果返回给 AI,AI 再用人话告诉你：「北京今天晴,15 度。」

关键转折：从确定性到概率性

这里有个关键的细节,初学者容易忽略。

传统函数是「确定性」的 —— 程序员在代码里写了 getWeather(),100% 会执行。
LLM 的函数调用是「概率性」的 —— AI 看到「今天天气怎么样」,它要自己判断该不该调用天气函数。这个判断是基于理解,不是基于规则。有小概率它会判断错误,比如把「天气」理解成某个人名。

函数调用的本质：让 AI 能「派遣小助手」,但派不派、派谁去,它自己决定。

这是一个巨大的进步 —— AI 不再只是「知识库」,它开始变成「行动者」。

但函数调用还有个问题：它是零散的、一次性的。

你给 AI 配了十几个函数,它每次只能派遣一个小助手。如果一个任务需要连续派遣五六个小助手、中间还有逻辑判断、还需要参考一些文档,函数调用就不够用了。

而且,每个厂商的函数调用格式都不一样,OpenAI、Google、Anthropic 各搞各的,开发者想给 AI 配工具,得写三套代码。这太痛苦了。

第三层：修路 - MCP 协议（2024 年底）

2024 年 11 月,Anthropic 推出了 MCP（Model Context Protocol）。

你可以把 MCP 理解成「统一插座标准」。

以前,你想给 AI 配工具,得：

给 OpenAI 的 AI 写一套接口
给 Claude 写一套接口
给 Google 的 AI 写一套接口

就像你家以前买电器,每个电器都得用不同形状的插头,插座也不通用,特别麻烦。

有了 MCP 之后,情况变了。

MCP 是一个开放标准,定义了 AI 和工具之间如何对话。只要你按照 MCP 标准开发工具,所有支持 MCP 的 AI 都能用。就像现在所有电器都用 USB-C 接口,一个充电器走天下。

MCP 解决了什么问题?

标准化：一套工具代码,多个 AI 平台都能用
双向通信：AI 不光能调用工具,还能读取文件、查询数据库
可扩展性：任何人都能开发 MCP 服务器,分享给社区

举个例子,你开发了一个「查询公司文档」的 MCP 服务器。用户可以在 Claude Code 里用它,也能在其他支持 MCP 的 AI 工具里用它,不用重复开发。

MCP 的本质：让 AI 和工具之间的对话有了一套「通用语言」。

但 MCP 还有个局限：它主要解决的是「连接」问题,不解决「流程」问题。

如果一个任务需要：

先查文档
再写代码
然后运行测试
最后生成报告

MCP 可以让你调用这四个工具,但「先做什么、后做什么、出错了怎么办」这些逻辑,还得靠 AI 自己判断,或者靠开发者写死在代码里。

能不能把「怎么做事」也打包起来呢?

第四层：跃升 - Skills（2025 年 10 月）

2025 年 10 月 16 日,Anthropic 发布了一个新功能：Claude Skills。

你可以把 Skills 理解成「员工手册」+「工具箱」的组合。

员工手册告诉 AI：「当你遇到某类任务时,应该怎么做,分几步,每一步用什么工具。」
工具箱里装着它需要用的脚本和参考资料。

具体来说,一个 Skill 就是一个文件夹,里面有三样东西：

1. SKILL.md 文件（员工手册）

这是「指令」,用自然语言写的。告诉 AI：

这个 Skill 是干什么的
什么情况下该用
怎么用
有什么注意事项

2. 脚本（工具箱）

可以是 Python、JavaScript 或者其他语言写的代码。当 AI 需要「动手」的时候,就执行这些脚本。

3. 资源文件（参考资料）

比如参考文档、模板、配置文件。AI 在执行任务的时候可以查阅这些资料。

Skills vs Function Calling：有什么区别?

区别在于：函数调用是「单个工具」,Skills 是「整套解决方案」。

打个比方：

函数调用像是给你一把锤子、一把螺丝刀、一把扳手,你得自己知道什么时候用哪个
Skills像是给你一本《如何组装宜家书柜》的说明书,说明书里不仅告诉你步骤,还附上了所有需要的工具和零件

渐进式披露：重要的设计机制

还有一个重要的机制叫「渐进式披露」（Progressive Disclosure）。

AI 的「工作记忆」是有限的（技术上叫「上下文窗口」）。如果你把所有 Skills 的内容一股脑塞进去,AI 会被信息淹没。

Skills 的做法是：平时只告诉 AI「有这么一本说明书」,AI 真正需要的时候再去翻。

就像你不用把整本百科全书背下来,遇到问题再查相关那一页就行。

四层演进：从代码到智能体

现在,咱们把四层放在一起看：

┌─────────────────────────────────────────┐
│           Skills（工作流级）              │
│      员工手册 + 工具箱 + 知识库            │
└─────────────────────────────────────────┘
                    ↑
┌─────────────────────────────────────────┐
│            MCP（协议层）                  │
│         统一的 AI-工具对话标准             │
└─────────────────────────────────────────┘
                    ↑
┌─────────────────────────────────────────┐
│       Function Calling（接口级）          │
│        AI 可以「派遣小助手」执行任务        │
└─────────────────────────────────────────┘
                    ↑
┌─────────────────────────────────────────┐
│           函数（代码级）                  │
│         封装、重用、标准化的代码块          │
└─────────────────────────────────────────┘

从下往上看,抽象层次越来越高：

函数：代码级的封装,程序员用
Function Calling：接口级的桥接,让 AI 能调用函数
MCP：协议层的统一,让工具和 AI 能够标准化对话
Skills：工作流级的打包,把「怎么做」也封装起来

Skills 可以包含函数调用,也可以调用 MCP 服务器。函数调用和 MCP 只是 Skills 的一部分工具。

就像一本菜谱不只是「切菜」「炒菜」「装盘」这几个动作的罗列,它还包括「为什么要这样做」「火候怎么掌握」「如果烧焦了怎么补救」这些知识。

这两年来：AI 从「纸上谈兵」到「能干活的员工」的进化史

如果用一个故事来总结这两年的演进：

2022 年之前：AI 是「纸上谈兵的顾问」

你问它问题,它根据训练数据回答。它有知识,但没行动力。就像一个只看过书、没做过事的书呆子。

2023 年：AI 有了「任务派遣能力」

Function Calling 让 AI 能调用外部工具。它不再只能「说」,还能「做」。就像给那位纸上谈兵的顾问配了一队专业小工,遇到具体任务就能派人去执行。

但这时候,AI 一次只能派一个小工。复杂任务需要协调多人协作,它还是搞不定。

2024 年底：统一了「派遣规范」

MCP 让工具和 AI 的对话标准化了。开发者不用给每个 AI 平台写一套接口。就像所有小工都遵守统一的作业标准,不用重新培训。

但问题还在：复杂任务需要协调多个小工、分多步执行,AI 还是会乱。

2025 年：AI 有了「项目执行手册」

Skills 把「怎么做事」也封装起来了。AI 不再只会派单,它会按照手册执行一整套流程。就像给顾问团队配了一本《项目管理手册》,遇到复杂任务也能一步步协调搞定。

下一步会是什么?

你猜对了 —— Agent（智能体）。

Agent 是什么?就是 Skills 的「自主版」。

Skills：你告诉 AI 做什么,它按照手册执行
Agent：你告诉 AI 目标,它自己规划、自己执行、自己调整

如果说 Skills 是「听话的员工」,Agent 就是「有自主权的经理」。

总结：如何理解这些新名词?

再看到新名词时,你可以问自己三个问题：

它在哪一层?
- 代码级?（函数、脚本）
- 接口级?（Function Calling）
- 协议级?（MCP）
- 工作流级?（Skills）
- 智能体级?（Agent）
它解决了什么问题?
- 封装重用?（函数）
- 让 AI 能动手?（Function Calling）
- 标准化连接?（MCP）
- 打包流程?（Skills）
- 自主决策?（Agent）
它的局限性是什么?
- 函数：只在代码世界有效
- Function Calling：零散、一次性
- MCP：不解决流程问题
- Skills：需要人触发
- Agent：自主性带来的风险

搞懂这三点,你就不会被新名词吓到了。

你会发现,这些技术不是互相替代的关系,而是一层一层往上搭的台阶。每一层都在解决上一层的局限,每一层都让 AI 离「真正的生产力工具」更近一步。

写在最后

AI 领域确实新词多,但别被表面现象迷惑。

从函数到 Function Calling,从 MCP 到 Skills,这条演进线很清晰：

AI 正在从「只会纸上谈兵的顾问」变成「能带队干活的经理」。

这条路才刚开始。

也许明年这个时候,你又会看到一堆新名词。但别慌,记住那个演进框架：代码级、接口级、协议级、工作流级、智能体级。

新名词再花哨,也逃不出这个框架。

延伸阅读：

Claude Code 官方文档： https://docs.anthropic.com/claude-code

MCP 协议规范： https://modelcontextprotocol.io

Claude Skills 使用指南： https://docs.anthropic.com/claude-code/skills

欢迎关注公众号FishTech Notes,一块交流使用心得