乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > AI 从＂嘴炮＂到＂干活＂,只差了一个协议

AI 从＂嘴炮＂到＂干活＂,只差了一个协议

当前时间： 2026-08-10 10:21:58 分类：办公文件 评论(0)
AI 从＂嘴炮＂到＂干活＂,只差了一个协议

从 Function Calling 到 MCP 协议，AI Agent 演化的关键两步。

这是「Agent 演化之路」系列的第一篇文章。

一、困局：语言与行动的鸿沟

2023年初的 ChatGPT 能做诗、能写代码、能通过司法考试——但当你问它"北京现在多少度"，它会一本正经地撒谎。

可能是"北京今天晴朗，气温25℃"，也可能是"多云，有轻微降雨"。但不管它说什么，都不是真实的天气数据。

原因很简单：模型只能生成文字，干不了实事——查不了 API，读不了文件，发不了邮件。

它被困在"说话"的层面，够不着"做事"的世界。

这就是 Agent 化的第一道鸿沟。

所以问题只有一个：怎么让模型"跳"出文字，去做实事？

早期的做法是让模型输出特定格式的文本，然后由人工解析执行：

用户：帮我查北京天气模型：请调用 weather_api("北京")人工：（解析后手动调用API）→ 返回结果 → 告诉模型

两个问题都很致命：模型输出的格式五花八门，解析困难；而且需要人工介入，根本没法自动化。

二、破局：Function Calling 的诞生

2023年6月，OpenAI 发布了一个新功能：Function Calling（函数调用）。

不是让模型"执行"，而是让模型"决策"

这个思路的转换，直接决定了后来 Agent 的发展方向。

OpenAI 没有让模型去"执行"代码——那会带来安全和可靠性问题。他们做了一个巧妙的分工设计：

  1. 1. 用户说"帮我查北京天气"
  2. 2. 模型看到已定义的工具列表，决定调用 get_weather，参数是"北京"
  3. 3. 模型输出一个结构化的 JSON 对象
  4. 4. 客户端代码拿到 JSON，执行实际的 API 调用
  5. 5. 把结果返回给模型
  6. 6. 模型结合结果，用自然语言回答用户

这个设计好就好在，把"想"和"做"分开了。

模型负责决策：判断需要调用什么工具、参数是什么 代码负责执行：实际调用 API、处理数据

模型输出的是严格格式化的 JSON 数据，解析可靠性大幅提升。所有执行都在客户端代码的控制下——安全性取决于客户端的校验逻辑，而非模型本身。

工具是怎么定义的？

以 Anthropic 的 Claude API 为例，定义一个工具就像填写一张表单：

{  "name": "get_current_weather",  "description": "获取指定城市的当前天气",  "input_schema": { "location": "城市名称，如北京" }}

input_schema 就是告诉模型：这个工具需要一个叫 location 的参数，它是字符串类型，必填。

OpenAI 的 schema 命名略有不同（用 parameters 代替 input_schema），但核心理念一致。

Function Calling 标志着 Agent 化的第一步——模型从"文本生成器"变成了"决策者"。

但这只是第一步。当工具越来越多时，新的问题出现了。

三、新困局：工具碎片化

Function Calling 让模型学会了"做决定"，但工具集成成了新的麻烦。

硬件世界早就遇到过同样的问题

1990年代，电脑外设连接是这样的：鼠标、键盘、打印机、硬盘，每个设备都有自己的专用接口、专用驱动、专用线缆。

1996年 USB 出现，一切改变了——一个接口，什么都能接。鼠标、键盘、打印机、硬盘，全部走同一根线。一次开发，到处连接。

AI Agent 的工具集成，正处在 USB 出现前的那个阶段。

碎片化到底有多痛

假设你想让 AI 能查天气、读数据库、发邮件、操作 GitHub——你需要为每个工具写一套独立的集成代码：

三个痛点：

  • • 每个 AI 应用都要重新写一遍集成代码
  • • 上游 API 一变，所有集成都要更新
  • • Claude 的集成方式和 ChatGPT 的不一样，生态碎片化

四、再破局：MCP 协议的诞生

2024年11月，Anthropic 推出了 MCP（Model Context Protocol） —— Agent 世界的"USB 协议"。

核心架构

工具开发者只需按 MCP 协议开发一次，所有支持 MCP 的 AI 应用都能使用。官方文档的原话是：

"可以把 MCP 理解为 AI 应用的 USB-C 接口。正如 USB-C 提供了连接电子设备的标准化方式，MCP 提供了连接 AI 应用与外部系统的标准化方式。"

与 USB 不同的是，MCP 不仅标准化了接口，还标准化了工具发现、资源订阅等更丰富的协议语义。

三种核心能力

用大白话说：

  • • Resources（资源）：让 AI 能"看"——读取文件、数据库等数据
  • • Tools（工具）：让 AI 能"做"——执行动作、调用 API
  • • Prompts（提示词）：让 AI 有"准备好的话术"——预设模板，一键调用

比如你装了一个"代码审查"的 MCP Server，里面的 Prompts 模板会预设好审查标准，AI 一键就能按公司规范 review 代码，不用你每次都把要求重复一遍。

再比如文件系统 MCP Server 可以暴露项目源代码、文档等资源，模型直接读取，不用手动上传。而 read_file 工具则让模型传入路径参数就能读取文件内容——和 Function Calling 的机制一脉相承，只是通过标准化的 MCP 协议暴露。

生态爆发

MCP 开源后，第三方生态发展很快。数据库类（PostgreSQL、SQLite）、搜索类（Tavily、Exa AI）、企业应用（Slack、Notion）、开发工具（GitHub、Docker）等纷纷推出 MCP Server。目前已有 3500+ 第三方 MCP 服务器。

价值

对开发者：一次开发，到处运行。

开发成本从 N×M 降低到 N+M。写一个 MCP Server，Claude、ChatGPT、Cursor、VS Code 都能用。

对用户：能力即插即用。

在配置文件中声明想要的 MCP Server，AI 应用就立即获得这些能力，不用写代码。

想象一个场景：你在 VS Code 里配置了几个 MCP Server，打开 Claude，它就能查你的数据库、读你的 GitHub、帮你整理文档——全程不用写一行集成代码。

如果说 ChatGPT 是 AI 的 iPhone 时刻，那 MCP 可能就是 AI 的 USB-C 时刻。

五、总结与展望

从 Function Calling 到 MCP 协议，Agent 演化走过了两个关键里程碑：

  1. 1. Function Calling 让模型从"文本生成器"变成"决策者"
  2. 2. MCP 协议 解决了工具碎片化
2023.06  Function Calling  →  2024.11  MCP 协议  →  未来  Skills

但 MCP 只是提供了"原子能力"的标准化连接方式——每个 MCP Server 提供的是单一功能（读文件、查数据库、发消息）。光有原子能力还不够——它们得组合起来，才能做成一件事。

这就是下一篇要聊的：Skills 和 Agentic Coding。工具原子化之后，Agent 怎么从"工具使用者"变成"能力拥有者"？

关于 AiMind Engine

AiMind Engine：专注 AI Agent 技术演化的深度解读。 每周两更，用开发者能听懂的语言，拆解 AI Agent 从概念到落地的每一个关键节点。

你现在用 AI，更多是"聊天查资料"，还是已经开始让它"干活"（写代码、查数据、自动化操作）了？评论区告诉我你到了哪个阶段。