MCP 和 Function Calling 有什么区别？真实项目选型、API Gateway 与组合架构

先给结论：两者不是替代关系，而是不同层级

MCP vs Function Calling 的核心 difference 是：Function Calling 解决“模型如何提出一次结构化工具调用”，MCP 解决“AI 应用如何用统一协议连接、发现和复用外部能力”。

30 秒选型

只有一个应用 + 少量固定 API
→ Function Calling

同一组工具要被多个 AI Host 复用，或需要连接文件、数据库与代码仓库
→ MCP + Function Calling

后端还涉及企业鉴权、限流、租户与审计
→ MCP Server 后面继续保留 API Gateway

不要因为工具数量从 5 个变成 10 个就立刻迁移 MCP。真正的分界线是能力是否需要跨客户端复用、是否存在独立资源边界、连接生命周期是否需要协议化管理。模型侧仍然可以使用结构化 Function Calling；Host 再把选中的动作路由到 MCP Client。

只做一个天气查询、订单查询或内部接口调用时，Function Calling 已经足够。你把函数的名称、说明和 JSON Schema 交给模型，模型生成调用参数，应用执行函数，再把结果送回模型。

当项目逐渐出现这些需求时，MCP 才开始体现价值：

• 同一组工具要被 IDE、桌面客户端、内部 Agent 和自动化系统复用。
• 工具不只是一组 HTTP API，还包含本地文件、代码仓库、SQLite、NAS 或企业知识库。
• 不同工具由不同进程、团队或服务维护。
• 客户端需要发现工具、Resources 和 Prompts，并协商双方支持的能力。
• 需要把连接生命周期、通知、订阅和远程认证放进统一协议。

但有三个边界必须先说清楚：

1. MCP 不是天然沙箱。 Server 可以作为本地进程或远程服务运行，真正的进程隔离、文件权限和网络隔离仍要靠操作系统、容器和部署策略。
2. MCP 不会自动完成授权和人工确认。 规范要求 Host 管理权限、同意与授权决策，并建议敏感工具调用提供确认界面，但具体能力必须由产品实现。
3. MCP 不保证自动节省 Token。 它提供工具与资源发现机制，最终向模型加载多少 Schema 和上下文，仍由 Host 的路由与上下文策略决定。

一张表看懂 Function Calling、MCP 和 API Gateway

对比项	Function Calling	MCP	API Gateway
主要解决什么	模型如何输出结构化工具调用	AI Host 如何连接并发现 Tools、Resources、Prompts	后端 API 如何统一鉴权、限流、路由和审计
核心参与者	模型、应用、业务函数	Host、Client、Server	调用方、网关、后端服务
常见描述格式	JSON Schema / Custom Tool	MCP Schema + JSON-RPC 消息	OpenAPI、HTTP、RPC、网关策略
工具发现	应用在请求或工具搜索阶段提供	Client 通过 tools/list 查询 Server	不负责模型工具发现
资源模型	通常把数据包装成函数结果	原生区分 Tools、Resources、Prompts	只暴露 API，不定义模型上下文语义
会话与连接	由模型 API 和应用管理	Client 与特定 Server 建立有状态会话	通常处理无状态或业务层会话
权限责任	应用自己实现	Host、Client、Server 分层实现	网关和后端服务实现
部署成本	最低	中等，需维护 Host/Client/Server	中高，面向服务治理
最合适场景	少量固定工具、单应用、快速上线	多客户端复用、本地资源、多能力服务器	企业服务、外部 API、配额和访问治理

选型规则：先看复杂度，不要先看概念热度

优先 Function Calling 的情况

满足下面大部分条件时，不需要为了“架构先进”额外搭 MCP：

• 只有一个应用使用这些工具。
• 工具数量少，接口稳定。
• 工具主要是现有 HTTP API 或业务函数。
• 不需要把工具共享给其他 AI Host。
• 团队更关注尽快上线，而不是协议复用。

典型例子：

• App 内查询天气、物流和订单。
• 客服助手调用三到五个固定业务接口。
• 内容工具调用搜索、摘要和发布接口。
• 后台系统让模型生成结构化筛选条件。

优先考虑 MCP 的情况

出现下面两到三项后，引入 MCP 才有明显收益：

• 同一工具要同时接入多个 AI 客户端。
• 工具由不同语言或独立进程实现。
• 需要接入文件、代码库、数据库 Schema 等 Resources。
• 工具列表会持续变化，希望客户端动态发现。
• 需要本地 stdio 与远程 HTTP 两种接入形态。
• 需要统一处理能力协商、通知和连接生命周期。

典型例子：

• Cursor、桌面助手和内部 Agent 共用同一套代码审查工具。
• AI Host 需要读取限定目录内的项目文件和 NAS 文档。
• 多个部门分别维护财报、合同、知识库和工单 MCP Server。
• 一个 Host 同时连接本地 Server 与远程企业服务。

API Gateway 仍然不可少的情况

只要 MCP Server 后面连接的是正式业务服务，API Gateway 依然有价值：

• OAuth 或企业身份认证。
• 限流、配额和计费。
• 多租户隔离。
• WAF、审计和请求追踪。
• 后端服务路由与版本治理。

MCP 不应该绕过现有服务治理。更稳的做法是让 MCP Server 成为受控适配层，后端 API 继续经过网关。

Function Calling 的真实调用链

以 OpenAI Function Calling 为例，基础流程是：

1. 应用把可调用工具及参数 Schema 提供给模型。
2. 模型返回工具调用名称和参数。
3. 应用校验参数并执行对应代码。
4. 应用把工具结果返回模型。
5. 模型结合结果生成最终回答，或继续调用其他工具。

用户请求
   ↓
模型判断是否调用工具
   ↓
返回 tool call + arguments
   ↓
应用校验并执行函数
   ↓
把结果返回模型
   ↓
生成答案或继续调用

Function Calling 的优势在于简单直接。应用完全掌握工具执行、权限检查、超时、重试和结果处理，不需要额外协议层。

为了提高参数可靠性，应优先使用严格的 JSON Schema 约束。OpenAI 官方文档建议启用 strict mode，使函数调用尽可能符合提供的 Schema。工具很多时，也不必把所有工具无差别放进每次推理：官方 API 已提供 deferred tool loading、tool search 和 allowed tools 等机制，用来缩小当前可调用工具范围。

参考：

• OpenAI Function Calling Guide
• OpenAI Tools Guide

MCP 的真实架构：Host 才是协调者

MCP 使用 Client-Host-Server 架构，并建立在 JSON-RPC 之上。

AI Host
├── MCP Client A ── MCP Server A
├── MCP Client B ── MCP Server B
└── 模型与用户界面

其中：

• Host：管理多个 Client、模型接入、上下文聚合、权限策略、用户授权和确认流程。
• Client：与一个特定 Server 建立会话，完成初始化、能力协商、消息路由、通知和订阅。
• Server：暴露聚焦的 Tools、Resources 和 Prompts，可以是本地进程，也可以是远程服务。

官方架构明确把安全策略、同意要求和用户授权决策放在 Host 侧，而不是宣称 Server 自动安全。一个 Host 通常为每个 Server 创建独立 Client 连接，减少 Server 之间直接共享上下文的机会。

参考：MCP Architecture

MCP Tools：可以发现和调用，但不等于可以无条件执行

支持 Tools 的 MCP Server 需要声明 tools capability。Client 可以通过 tools/list 获取工具列表，再通过 tools/call 调用工具。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

工具定义包含名称、描述、输入 Schema，也可以包含输出 Schema。Server 应校验工具输入、执行访问控制、限流并清理输出；Client 对敏感操作应展示参数、请求用户确认、设置超时并记录审计日志。

这里最容易被误解的一点是：规范建议提供 Human-in-the-loop，不代表所有 MCP 客户端都自动实现了相同确认流程。 产品仍需明确哪些工具只读、哪些写入、哪些必须审批。

参考：MCP Tools Specification

MCP Resources：是标准化上下文，不是自动挂载整块硬盘

Resources 用于让 Server 以 URI 暴露文件、数据库 Schema 或应用数据。Client 可以使用 resources/list 发现资源，用 resources/read 获取内容。

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.ts"
  }
}

但 Resources 是 application-driven 的：由 Host 决定如何展示、搜索、筛选和加入模型上下文。协议没有规定“发现资源后自动全部发送给模型”。

订阅和资源列表变更通知也是可选能力，只有 Server 声明支持后才能使用。因此，不能把 Resources 写成“模型天然拥有整个本地文件系统”。真正可访问的目录和数据必须由 Server 白名单、操作系统权限和 Host 策略共同限定。

参考：MCP Resources Specification

MCP 是否比 Function Calling 更省 Token

不能只根据协议名称下结论。

Function Calling 的 Token 成本取决于：

• 当前请求向模型提供了多少工具定义。
• Schema 是否过长。
• 是否使用工具搜索、允许列表和提示缓存。
• 工具结果是否被过量塞回上下文。

MCP 的 Token 成本取决于：

• Host 是否把所有 MCP 工具都转换后交给模型。
• 是否先按 Server、任务和权限筛选工具。
• Resources 是按需读取还是整批注入。
• 工具结果是否经过裁剪、摘要和结构化。

因此，MCP 的优势是提供标准化发现与连接，不是保证“Schema 只传一次”或“Token 自动下降数倍”。真正降低成本的是路由、延迟加载、结果裁剪和上下文治理。

MCP 是否天然更安全

同样不能。

MCP 提供了更清晰的角色边界，但安全仍然是系统工程：

层级	必须做的控制
Host	可信 Server 清单、敏感操作确认、上下文隔离、结果校验
Client	超时、取消、消息校验、连接生命周期和审计
Server	输入校验、访问控制、限流、输出清理、最小权限
操作系统	目录权限、用户权限、容器隔离、网络出口限制
远程服务	OAuth、Token 生命周期、TLS、网关策略和租户隔离

不要因为用了 stdio 就认为进程天然安全，也不要因为用了远程 MCP 就把 OAuth Token 直接交给第三方 Server。未受信任的 Server 应放进独立用户、容器或沙箱环境，写操作默认关闭。

最稳的组合架构

真实项目不必在 MCP 和 Function Calling 之间二选一。常见组合是：

用户
  ↓
AI Host / Agent Runtime
  ↓
模型选择工具（Function Calling）
  ↓
Host 路由到 MCP Client
  ↓
MCP Server
  ↓
API Gateway / 数据库 / 文件系统 / SaaS

在这套架构里：

• Function Calling 负责模型侧的结构化选择。
• MCP 负责 Host 与能力服务器之间的标准化连接。
• API Gateway 负责正式后端服务治理。
• Host 负责把用户权限、模型决策和 Server 能力连接起来。

这比“全部改成 MCP”更符合生产系统的分层原则。

三个具体场景怎么选

场景一：App 内查询天气和订单

选择：Function Calling。

原因：工具少、接口固定、只服务一个 App。直接在应用中完成参数校验、用户身份校验和 API 调用，复杂度最低。

场景二：IDE、桌面助手和内部 Agent 共用代码工具

选择：MCP + Function Calling。

原因：代码搜索、文件读取、测试执行等能力需要被多个 Host 复用。MCP Server 提供统一能力，Host 再决定哪些工具暴露给模型。

场景三：企业财报分析与内部数据

选择：MCP + API Gateway + 人工审批。

原因：MCP Server 负责把财报解析、知识库和审计工具标准化；API Gateway 负责身份、配额和审计；涉及写入、导出和敏感数据访问时由 Host 发起确认。

从 Function Calling 迁移到 MCP 的顺序

不要一次重构全部工具，按下面顺序更稳：

1. 先统计现有工具的调用方、权限和数据来源。
2. 把只服务一个应用的简单工具留在 Function Calling。
3. 选择一组确实需要跨客户端复用的只读工具做 MCP Server。
4. 给 Server 配置目录白名单、输入校验、超时和审计日志。
5. 在 Host 中建立可信 Server 清单与敏感操作确认策略。
6. 再处理远程认证、OAuth 和 API Gateway 对接。
7. 最后才迁移写文件、执行命令和修改生产数据等高风险工具。

常见错误

错误一：把 MCP 当作新的模型工具调用格式

MCP 不替代模型 API 中的 Function Calling。它定义的是 Host、Client、Server 之间的协议连接。Host 仍需要把可用能力以模型能理解的形式提供给模型。

错误二：把 MCP Server 当作安全沙箱

Server 只是独立能力提供者。它是否隔离，取决于进程用户、容器、目录权限和网络策略，而不是协议名称。

错误三：把所有 Server 的工具全部交给模型

这会重新制造工具过多、描述相似和上下文膨胀的问题。Host 应先根据任务、用户权限和 Server 信任级别筛选工具。

错误四：让 MCP 绕过现有后端鉴权

MCP Server 不应该持有不受约束的超级权限。访问企业 API 时，仍应经过 OAuth、API Gateway、租户隔离和审计。

错误五：把 Resources 自动塞满上下文

Resources 应按需读取。先列目录和元数据，再读取必要内容；大文件应分页、分段或通过检索定位，避免一次性注入。

最终决策表

你的项目情况	建议
一个应用，1-5 个固定 API	Function Calling
一个应用，工具较多但仍由同一代码库维护	Function Calling + 工具搜索/允许列表
多个 AI 客户端复用同一组能力	MCP
需要标准化接入文件、代码库、数据库 Schema	MCP Resources / Tools
正式企业 API、配额、租户和审计	API Gateway，必要时外接 MCP
高风险写操作或命令执行	MCP 或 Function Calling 都必须加审批与最小权限
想降低 Token 成本	先做工具筛选、延迟加载和结果裁剪，不要只换协议

下一步阅读

• MCP 专题：从协议边界到生产治理
• MCP 协议指南：先理解边界，再开始接工具
• MCP 与 Function Calling、API Gateway 的组合架构
• MCP 和 Semantic Kernel 有什么区别？协议、Plugin 与 Agent 编排
• MCP OAuth 认证：远程 Server 怎么做授权
• MCP Server 生产治理：权限、审计与生命周期
• MCP 安全实践：allowedRoots、最小权限与提示注入

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅更新