---

引言

在人工智能快速发展的今天，我们见证了 AI 从简单的对话工具向能够真正执行任务的智能助手的转变。这个转变的核心技术演进路径中，Function Calling（函数调用） 和 MCP Server（Model Context Protocol Server） 是两个关键的里程碑。它们不是替代关系，而是层层递进的演化关系。

---

一、Function Calling 的诞生：打破 AI 的"对话墙"

1.1 为什么会出现 Function Calling？

在 Function Calling 出现之前，大语言模型（LLM）面临一个根本性的限制：它们只能生成文本，无法与外部世界交互。

典型困境：

• 用户问：“今天北京天气如何？” → 传统 LLM 只能根据训练数据猜测，无法获取实时信息
• 用户说：“帮我发送一封邮件给张三” → LLM 只能告诉你怎么发邮件，但无法真正执行

这就是所谓的对话墙——AI 被困在纯文本的世界里，无法触及真实世界的数据和操作。

1.2 Function Calling 解决了什么问题？

Function Calling 的出现，让 LLM 从"知道怎么做"变成了"能够真正去做"。

核心调用流程：

示例代码：

// 声明一个获取天气的函数
{
  "name": "get_weather",
  "description": "获取指定城市的天气信息",
  "parameters": {
    "city": { "type": "string", "description": "城市名称" }
  }
}

Function Calling 解决的核心问题：

• ✅ 实时数据获取（天气、股票、新闻等）
• ✅ 外部系统操作（发送邮件、创建日程、数据库操作）
• ✅ 复杂计算（调用专业计算工具）
• ✅ 多步骤任务编排（先查询后操作）

---

二、Function Calling 的局限：标准化的困境

Function Calling 虽然强大，但随着应用场景的扩展，暴露出一些问题：

2.1 缺乏统一标准

每个 AI 平台（OpenAI、Anthropic、Google 等）都有自己的 Function Calling 实现方式，导致开发者需要为不同平台编写不同的集成代码，维护成本高昂。

2.2 工具发现困难

• 每次会话都需要重新声明所有可用函数
• 无法动态发现新工具
• 工具之间缺乏组织和分类

2.3 上下文传递不灵活

• 函数只能接收参数和返回结果
• 无法提供持久化的上下文（如文件系统、数据库连接）
• 每次调用都是孤立的

2.4 安全性和权限管理

• 缺乏统一的权限控制机制
• 难以实现细粒度的访问控制

---

三、MCP Server 的诞生：Function Calling 的标准化与增强

3.1 什么是 MCP（Model Context Protocol）？

MCP 是由 Anthropic 提出的开放协议，旨在为 AI 模型与外部工具、数据源的交互建立统一标准。

MCP Server 可以理解为：Function Calling 的标准化、模块化、工业级实现

3.2 MCP Server 解决了什么问题？

---

四、Function Calling vs MCP Server：关系与演进

4.1 对比总览

维度	Function Calling	MCP Server
定位	AI 调用外部工具的能力	外部工具的标准化封装
标准化	各平台实现不同	统一的开放协议
复用性	每次会话需重新声明	独立服务，可跨会话复用
上下文	仅函数参数和返回值	支持 Resources 持久化上下文
发现机制	静态声明	动态发现和连接
架构	紧耦合在应用中	独立服务，松耦合
适用场景	简单工具调用	复杂系统集成

4.2 演进关系

关系总结：

• Function Calling 是"能力"（Capability）— 定义了"AI 可以调用函数"这个概念
• MCP Server 是"标准"（Standard）— 定义了"函数应该如何被标准化地提供和调用"
• MCP Server 是 Function Calling 的工业化、标准化升级

---

五、实际案例对比

5.1 传统 Function Calling 方式

// 每次都需要在应用中定义函数
const functions = [
  {
    name: "search_files",
    description: "搜索文件",
    parameters: { query: "string", path: "string" }
  },
  {
    name: "read_file",
    description: "读取文件",
    parameters: { path: "string" }
  }
];

// 调用 OpenAI API
const response = await openai.chat.completions.create({
  model: "gpt-4",
  messages: messages,
  tools: functions  // 每次都要传递
});

// 手动执行函数
if (response.tool_calls) {
  const result = executeFunction(response.tool_calls[0]);
}

5.2 MCP Server 方式

// 1. 一次性配置 MCP Server（如 filesystem server）
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"]
    }
  }
}

// 2. AI 自动发现并使用工具
// 用户：搜索所有包含 "TODO" 的文件
// AI 自动调用 filesystem MCP Server 提供的 search_files 工具
// 无需每次重新声明，Server 独立管理这些能力

---

六、MCP Server 的架构优势

架构对比

MCP 架构优势：

• ✅ 工具独立开发和部署
• ✅ 版本管理更清晰
• ✅ 社区可以贡献标准化的 MCP Servers
• ✅ 跨应用复用（IDE、CLI、Web 都可以用同一个 Server）

---

七、未来展望

Function Calling 不会消失，它是基础能力，但会：

• 被集成到更多 LLM 平台
• 语法更加简洁统一

MCP Server 代表了未来方向：

• 建立 AI 工具的"生态系统"（类似 npm、pip）
• 出现更多标准化的 MCP Servers
• 企业可以构建私有 MCP Server 集市
• 跨平台的 AI 应用成为可能

---

总结

模块	层级	职责（要点）	控制方/备注
Function Calling	LLM 层	解析 tools 数组；自主判断是否使用工具；选择使用哪个函数；自动生成合法 JSON 参数；输出固定格式的工具调用报文	大模型厂商；纯模型能力，写在训练/微调里，无法由业务侧修改
MCP / MCP Server	应用层 / 业务层	向外暴露可用工具列表；约束工具入参/出参与协议；实际执行工具逻辑（硬件/接口/文件/命令行）；做权限、限流与安全沙箱	开发者/业务侧自定义实现；与模型无关

	Function Calling	MCP Server
时代	1.0 探索期	2.0 标准化期
核心贡献	打破 AI 对话墙，实现工具调用	建立标准生态，实现工业化落地
类比	单体应用 → 微服务的"能力"	npm/pip 一样的"生态系统"

它们的关系不是替代，而是继承与演进。 AI 工具生态也正在经历同样的标准化和工业化进程，而 MCP 正是这个进程中的重要一步。