大模型四次觉醒:从聊天到干活的全进化
还记得2023年第一次让ChatGPT帮你查天气时的惊喜吗?那种“AI终于能干实事了”的兴奋感,背后是一场从聊天机器人到行动系统的革命。短短两年间,大模型经历了四次关键进化:function_call → tools → MCP → skills。每一步都在重新定义AI能做什么。
今天,我们来拆解这段波澜壮阔的进化史。
第一幕:Function Call——从“能说”到“能做”
2023年6月,OpenAI发布Function Calling。
这是一个里程碑时刻。在此之前,GPT-4再聪明也只能“纸上谈兵”——它能告诉你怎么查天气,但自己查不了。Function Calling改变了这一切:它让LLM学会了主动调用外部工具。
技术原理其实很简单:当你问“北京今天天气怎么样”,模型不再生成一段文字,而是输出一段JSON:
{“function”: “get_weather”,“arguments”: {“city”: “北京”}}开发者接收这个JSON,调用真实的天气API,再把结果返回给模型。一来一回,AI就从“空谈家”变成了“实干家”。
Function Calling迅速成为AI应用的基础设施。聊天机器人开始能查数据库、订机票、发邮件。2026年的调查显示,超过80%的企业AI应用都依赖Function Calling。
但问题也随之而来:当一个系统需要接入50个工具时,怎么办?
第二幕:Tools——从“单打独斗”到“协同作战”
2024年,Anthropic推出Advanced Tool Use。
Anthropic的工程师发现,当工具数量超过50个时,系统会遇到两个致命问题:
- 成本暴涨:每个工具的定义都要占用prompt tokens。58个工具能吃掉55,000 tokens——这意味着一次请求就花掉几块钱。
- 选择困难:工具越多,模型选错的概率越高。就像给你一个100页的菜单,点菜准确率会直线下降。
Anthropic的解决方案是Tool Search:不再一次性加载所有工具定义,而是让Claude先搜索、再调用。这就像从“翻整本字典”变成了“用搜索引擎”。
与此同时,另一个突破性功能出现了:Programmatic Tool Calling(程序化工具调用)。
以前,每次工具调用都需要一次API往返:
用户 → 模型 → 调用工具A → 等待结果 → 调用工具B → 等待结果...现在,Claude可以直接写一段代码,一次性编排多个工具:
# Claude自己写的代码
weather = call_tool(“get_weather”, {“city”: “北京”})
if weather[“temp”] > 30:
result = call_tool(“send_alert”, {“message”: “高温预警”})这意味着什么?从10次API调用降到1次。速度快了10倍,成本降低90%。
Tools时代的核心突破是:让AI学会了工具的“组合拳”,而不是简单的单个调用。
但新的问题又来了:每家公司都在造自己的工具接口标准,开发者需要为OpenAI、Anthropic、Google分别适配三套代码。这像极了智能手机早期的混乱——每个品牌都有自己的充电接口。
第三幕:MCP——从“各自为政”到“统一标准”
2024年11月,Anthropic发布Model Context Protocol。
如果说Function Call是“发明电话”,Tools是“建立通话规则”,那么MCP就是“制定统一的通信协议”。
MCP的核心理念是:让AI和外部系统的连接标准化。就像HTTP协议统一了网页访问方式,MCP要统一AI的工具接入方式。
看看这个时间线:
- 2024年11月:Anthropic推出MCP
- 2025年3月:OpenAI CEO Sam Altman宣布“全力支持MCP”
- 2025年12月:Anthropic将MCP捐赠给Linux基金会下的Agentic AI Foundation
- 2026年初:社区已经开发了数千个MCP服务器,所有主流编程语言都有SDK
为什么MCP能成为事实标准?因为它解决了三个关键问题:
1. 接口统一
以前,每个工具都要为不同的AI平台写不同的适配器:
你的数据库 → OpenAI适配器
你的数据库 → Claude适配器
你的数据库 → Gemini适配器现在,只需要写一个MCP服务器:
你的数据库 → MCP服务器 → 所有AI模型2. 安全可控
MCP服务器运行在本地,数据不需要上传到云端。这对企业来说至关重要——财务数据、客户信息可以放心接入AI,而不用担心泄露。
3. 生态爆发
Claude官方目录已经有75+连接器,覆盖:
- 开发工具(GitHub、GitLab、Docker)
- 企业软件(Salesforce、Jira、Confluence)
- 数据库(PostgreSQL、MongoDB、Redis)
- 云服务(AWS、Azure、Google Cloud)
这就像App Store的诞生——开发者只需要发布一次,就能被所有AI应用使用。
但MCP还有一个局限:它是基础设施层面的标准,开发者仍然需要写大量代码来定义“AI该怎么用这些工具”。
这就引出了第四幕。
第四幕:Skills——从“工具箱”到“专家系统”
2025-2026年,Claude Agent SDK引入Skills。
如果把Function Call比作“锤子”,Tools比作“工具箱”,MCP比作“标准化接口”,那么Skills就是“会用工具的专家”。
Skills和前三者的本质区别
假设你要让AI帮你“审核代码”:
- Function Call时代:你需要告诉AI“先读文件,再检查语法,再查重复代码...”,每次都要重复指导
- Tools时代:AI可以自动组合多个工具,但你还是要在prompt里写清楚流程
- MCP时代:工具接入变简单了,但使用逻辑还是要你写
- Skills时代:你创建一个
code-review.md文件,写好审核标准和流程,以后AI看到代码就自动按这个标准审
Skills的核心是“封装领域知识”。一个Skill包含:
- 触发条件:什么时候该用这个Skill
- 工作流程:按什么步骤执行
- 最佳实践:行业经验和注意事项
- 资源文件:模板、脚本、配置
比如一个“微信公众号写作”Skill:
# 触发条件
用户说“写一篇公众号文章”
# 工作流程
1. 搜索相关资料(优先X/Twitter、Reddit)
2. 按1000-1500字撰写
3. 生成5个爆款标题
4. 优化排版
# 最佳实践
- 开头要有故事化场景
- 每段3-5行
- 数据单独成段加粗2026年的Skills生态
Skills正在成为AI应用的“插件系统”:
- Microsoft Agent Framework支持Claude Skills,企业可以共享内部专家知识
- GitHub上的Skills仓库已有数百个开源Skills,涵盖代码审查、文档生成、测试编写、安全审计...
最关键的是:Skills是可复用的。一个高级工程师花一周总结的代码审核经验,封装成Skill后,整个团队都能用。这就像把“老师傅的手艺”变成了“工业标准”。
四次进化的本质
回顾这段历史,我们会发现一条清晰的演进逻辑:
| 阶段 | 核心能力 | 类比 |
|---|---|---|
| Function Call | AI能调用单个工具 | 学会用锤子 |
| Tools | AI能组合多个工具 | 学会用工具箱 |
| MCP | 工具接入标准化 | 统一接口标准 |
| Skills | 封装领域专家知识 | 成为各领域专家 |
这四次跨越,本质上是在回答同一个问题:如何让AI从“通用对话”走向“专业执行”?
- Function Call解决了“能不能做”
- Tools解决了“能做多复杂的事”
- MCP解决了“能不能大规模推广”
- Skills解决了“能不能做得专业”
尾声:2026年的AI已经不一样了
2026年的今天,当你打开Claude、ChatGPT或任何AI工具,背后已经不是单纯的语言模型。它可能连接着:
- 75+个MCP服务器
- 数千个开源Skills
- 你公司的内部数据库、CRM、代码仓库...
AI已经从“聊天伙伴”进化成了“数字同事”。它不仅能理解你的需求,还能:
- 自动选择正确的工具(Tool Search)
- 高效编排多步操作(Programmatic Tool Calling)
- 通过标准接口访问任何系统(MCP)
- 按照行业最佳实践执行任务(Skills)
这场从Function Call到Skills的进化,用了不到3年。而下一个3年,又会发生什么?
也许到2029年,我们会惊讶地发现:今天觉得AI已经很强大,就像2023年的人觉得“AI能查天气”很厉害一样。
技术的进化永不停歇。我们能做的,就是理解趋势、拥抱变化。
参考资料
- AI in 2026: Function Calling, Reasoning Models, and a New Runtime Era
- Anthropic Advanced Tool Use
- Donating the Model Context Protocol
- Agent Skills in the SDK - Claude API Docs
- Tool Calling Explained: The Core of AI Agents (2026 Guide)
- OpenAI's API Evolution: Responses API vs. Chat Completions API
