AI的四次觉醒：从聊天到干活，大模型是这样进化的

还记得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个时，系统会遇到两个致命问题：

1. 成本暴涨：每个工具的定义都要占用prompt tokens。58个工具能吃掉55,000 tokens——这意味着一次请求就花掉几块钱。
2. 选择困难：工具越多，模型选错的概率越高。就像给你一个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包含：

1. 触发条件：什么时候该用这个Skill
2. 工作流程：按什么步骤执行
3. 最佳实践：行业经验和注意事项
4. 资源文件：模板、脚本、配置

比如一个"微信公众号写作"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后，整个团队都能用。这就像把"老师傅的手艺"变成了"工业标准"。

四次进化的本质

回顾这段历史，我们会发现一条清晰的演进逻辑：

这四次跨越，本质上是在回答同一个问题：如何让AI从"通用对话"走向"专业执行"？

• Function Call解决了"能不能做"
• Tools解决了"能做多复杂的事"
• MCP解决了"能不能大规模推广"
• Skills解决了"能不能做得专业"

尾声：2026年的AI已经不一样了

2026年的今天，当你打开Claude、ChatGPT或任何AI工具，背后已经不是单纯的语言模型。它可能连接着：

• 75+个MCP服务器
• 数千个开源Skills
• 你公司的内部数据库、CRM、代码仓库...

AI已经从"聊天伙伴"进化成了"数字同事"。它不仅能理解你的需求，还能：

1. 自动选择正确的工具（Tool Search）
2. 高效编排多步操作（Programmatic Tool Calling）
3. 通过标准接口访问任何系统（MCP）
4. 按照行业最佳实践执行任务（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