Function Calling会被MCP取代吗？一个管模型怎么表达、一个管工具从哪来，到底该一起用还是二选一？

一、导语：一个被反复问错的问题

“Function Calling 会不会被 MCP 取代”这个问题，在过去一年多里反复出现在技术社区、架构评审会和选型讨论中。提问者的直觉往往来自一个表面观察：两者都涉及“让模型调用外部工具”，既然 MCP 更新、更标准化、生态更热，那么旧的 Function Calling 是否就该退场？

这个推理的漏洞在于，它把“模型输出一段结构化调用意图”与“外部工具如何被描述、发现和连接”当成了同一件事。实际上，前者是模型推理能力的一部分，后者是系统集成协议的一部分。把两者对立，类似于问“HTTP 会不会取代 JSON”——它们在不同层工作，一个负责传输语义，一个负责数据表示，取消任何一个都会让系统失去完整性。

笔者认为，要真正回答这个问题，必须先建立一个清晰的分层模型，把“模型侧表示”“工具侧供给”“运行时编排”三个层面拆开，再逐层追问：每一层解决什么问题、依赖什么前提、失效时表现为何。只有在这个框架下，“一起用还是二选一”才有可讨论的意义。本文即围绕这条主线展开。

二、背景与问题定义：两个正交的抽象层

2.1 概念界定：先给两个术语下准确定义

Function Calling（函数调用）：指大语言模型在生成过程中，按照预先给定的工具模式（schema），输出一段结构化数据（通常是 JSON），用以表达“我建议调用名为 X 的工具，参数为 Y”。其本质是模型的一种受约束解码能力，模型本身并不执行工具，执行由外部运行时完成。OpenAI 于 2023 年 6 月在 API 中引入该能力，此后 Anthropic、Google、Meta 等厂商的模型相继支持类似机制，业界逐步以“工具调用（tool use）”统称。

MCP（Model Context Protocol，模型上下文协议）：由 Anthropic 于 2024 年 11 月开源的开放协议，用于标准化“AI 应用（Host）—客户端（Client）—服务器（Server）”之间的上下文与工具交换。它定义了资源（Resources）、提示（Prompts）、工具（Tools）三类原语，以及基于 JSON-RPC 2.0 的消息格式与生命周期。MCP 的定位是连接协议，回答“工具和能力如何被标准化地暴露给模型宿主”。

本文评述：把二者放在同一句话里比较“谁取代谁”，前提是它们争夺同一资源。但从定义看，Function Calling 争夺的是“模型输出格式的话语权”，MCP 争夺的是“工具接入方式的话语权”，二者并不在同一竞争维度。真正可能被替代的，是 MCP 出现之前那些各自为政的私有工具接入方案，而非 Function Calling 本身。

2.2 问题的真实来源：三个常见混淆

混淆一：把“工具定义”与“工具调用”混为一谈。MCP 的 Tools 原语确实包含工具描述（名称、描述、输入 schema），这与 Function Calling 所需的 schema 高度相似，导致很多人以为 MCP 已经“包含了 Function Calling”。但 MCP 提供的是“描述如何送达模型”，模型收到描述后是否、如何生成调用，仍取决于模型自身的 Function Calling 能力。

混淆二：把“协议标准化”等同于“能力替代”。标准化降低的是集成成本，不是替代某一层能力。MCP 让工具接入更统一，但模型仍需要一种语法来表达调用意图；即便未来所有模型都通过 MCP 获取工具，调用意图的表达依然需要一个表示层。

混淆三：把“生态热度”当作“技术必要性”。MCP 在 2025 年获得大量客户端与服务器实现，生态扩张迅速，这是事实；但生态热度说明的是采用速度，不能直接推导出“底层表示机制不再需要”。

2.3 本文的分析主线

基于上述界定，本文确立一条贯穿全文的分析主线：工具调用系统可分解为“表示层—供给层—编排层”三层，Function Calling 主攻表示层，MCP 主攻供给层，编排层由宿主应用承担。三层各自有独立的失效模式与优化目标，工程决策应逐层进行，而非在整体上做“二选一”。后续章节将依次拆解表示层与供给层的机制，再讨论二者在编排层的交汇与协同。

三、原理拆解：Function Calling 的表示层机制

3.1 数据流：一次调用的完整生命周期

一次典型的 Function Calling 交互包含四个阶段：工具声明注入、模型受约束生成、运行时解析执行、结果回填再生成。第一阶段，宿主把工具 schema 以特定格式（如 OpenAI 的 tools 字段）随消息一起送入模型；第二阶段，模型在解码时若判断需要调用，则输出符合 schema 的结构化片段；第三阶段，宿主解析该片段，实际执行函数并捕获返回值；第四阶段，将返回值作为工具消息追加进上下文，触发模型继续生成。

{
  "model": "example-model",
  "messages": [{"role": "user", "content": "查询北京今天天气"}],
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "查询指定城市的实时天气",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string", "description": "城市名称"},
          "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
        },
        "required": ["city"]
      }
    }
  }]
}

上述结构的关键在于 parameters 字段遵循 JSON Schema 子集，模型据此约束输出。本文评述：这一设计的工程价值常被低估——它把“工具契约”变成了可校验的机器可读对象，使调用合法性可以在执行前静态检查，而不必依赖自然语言解析。这是 Function Calling 相对早期“让模型输出一段文本再正则提取”方案的本质进步。

3.2 受约束解码与并行调用

从模型侧看，Function Calling 的实现通常依赖受约束解码（constrained decoding）或专门的调用标记。前者在解码时对候选 token 施加语法约束，保证输出符合 JSON Schema；后者通过特殊控制 token 划分“思考”与“调用”片段。不同厂商实现细节不同，但共同点是：调用意图的表达被内化为模型能力，而非外部提示工程的产物。

并行调用（parallel tool calls）是另一项重要能力：模型可在单轮中输出多个调用请求，宿主并发执行后统一回填。这在多源信息聚合场景（如同时查天气、汇率、库存）中显著降低往返轮次。但并行也带来依赖问题——若第二个调用依赖第一个的结果，并行就会失败。工程上通常通过提示或 schema 约束引导模型串行处理有依赖的调用。

3.3 表示层的固有边界

Function Calling 的边界非常清晰：它只负责“表达”，不负责“供给”。工具从哪来、如何鉴权、如何发现新工具，都不在其职责范围内。宿主必须自行维护工具清单，并在每次请求时把 schema 注入上下文。这带来两个直接后果：其一，工具数量增长会线性推高上下文 token 成本；其二，工具变更需要宿主侧同步更新，缺乏标准化的发现机制。

笔者认为，正是这两个后果催生了 MCP。换言之，MCP 不是来取代 Function Calling 的，而是来补足表示层之外那块长期由各宿主“手工拼接”的供给层。理解这一点，是理解二者关系的关键。

四、原理拆解：MCP 的供给层机制

4.1 架构：Host—Client—Server 三角

MCP 采用三层架构：Host 是面向用户的 AI 应用（如 IDE、桌面助手），Client 是 Host 内部为每个 Server 维护的连接器，Server 是暴露能力的独立进程或服务。通信基于 JSON-RPC 2.0，支持 stdio 与可流式 HTTP 两种传输。Server 可暴露三类原语：Resources（可读取的上下文数据）、Prompts（可复用的提示模板）、Tools（可调用的函数）。

这一架构的核心贡献是把“工具供给”从宿主内部逻辑中剥离出来，变成可独立部署、独立升级、独立鉴权的服务。本文评述：这与微服务架构中“服务发现与注册中心”的思路同构——MCP Server 类似服务提供方，Client 类似服务消费者，协议本身承担了契约与发现的双重角色。

4.2 能力协商与生命周期

MCP 连接建立时，Client 与 Server 通过 initialize 请求交换协议版本与能力声明（capabilities），随后进入正常消息交换阶段。能力协商的意义在于：双方可以明确知道对方支持哪些原语与特性，避免在不支持的操作上浪费往返。这一机制在异构生态中尤为重要——不同 Server 实现的能力集并不一致。

// 初始化请求（示意，字段以官方规范为准）
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {"roots": {"listChanged": true}},
    "clientInfo": {"name": "example-host", "version": "1.0.0"}
  }
}

4.3 供给层解决了什么，没解决什么

MCP 解决的是工具的可发现性、可移植性与接入标准化：一个 Server 写好，多个 Host 可复用；鉴权、传输、错误码有统一约定；工具清单可动态刷新（listChanged 通知）。但它不解决模型如何表达调用——MCP 规范本身并不规定模型必须输出何种格式的调用意图，这部分仍由宿主与模型之间的表示层决定。

换言之，MCP 把工具“送到模型面前”，但“模型伸手去拿”的动作，仍由 Function Calling 这类表示机制完成。二者在数据流上是串联关系：MCP 提供工具描述 → 宿主转换为模型可识别的 schema → 模型生成调用意图 → 宿主通过 MCP Client 转发执行。这条链路清晰地说明，取消任何一环都会断裂。

五、关键对比：职责、成本与失效模式

5.1 职责对照表

这张表的核心信息是：两者的失效模式几乎不重叠。Function Calling 出错多发生在“语义—参数”映射，MCP 出错多发生在“连接—权限”层面。这意味着在排障时，可以按层定位，而不必在整体上猜测。

5.2 上下文成本的结构性差异

Function Calling 的成本随工具数量线性增长：每个工具的 schema 都要占用上下文。假设单个工具 schema 平均 120 token，50 个工具就是 6000 token 的固定开销，且每轮对话都要重复。MCP 本身不消除这一成本——工具描述最终仍要进入模型上下文——但它提供了按需加载的可能：Host 可以先只暴露工具名称与摘要，待模型表达“需要某类能力”后再拉取完整 schema。

本文评述：这种“渐进式披露”是 MCP 生态中值得关注的工程方向，但它依赖 Host 的编排策略，而非协议强制。换言之，MCP 给了工具按需加载的可能性，能否兑现取决于宿主实现质量。这一点在选型评估中常被忽略。

5.3 一个容易忽视的边界：模型不支持时怎么办

并非所有模型都原生支持 Function Calling。对于不支持或支持不完善的模型，宿主可采用“提示 + 解析”的降级方案：在提示中描述工具格式，要求模型输出特定标记包裹的 JSON，再正则提取。这种方案可靠性低于原生受约束解码，但在成本敏感或私有化部署场景中仍有价值。MCP 在此场景下依然可用——它负责把工具描述送达，表示层则退化为提示工程。

六、协同落地路径：五步工程方法

6.1 第一步：先画数据流，再选协议

落地前先把完整数据流画出来：用户请求 → 宿主组装上下文 → 工具描述注入 → 模型生成 → 调用解析 → 执行 → 结果回填。在这条链上标注每一环由谁负责。若工具来源单一、数量少、变更不频繁，直接用 Function Calling 手工注入即可，引入 MCP 反而增加运维面；若工具来源多、需要跨应用复用、需要独立鉴权，则 MCP 的收益开始显现。

6.2 第二步：把工具契约当作 API 来治理

无论用哪种机制，工具契约的稳定性都是第一位的。建议为每个工具定义版本号、输入输出 schema、错误码枚举与幂等性说明。schema 描述要写清“何时该用、何时不该用”，因为模型选错工具往往源于描述模糊，而非能力不足。可参考 OpenAPI 规范的组织方式，把工具契约纳入代码仓库与 CI 校验。

# 工具契约校验的伪代码思路
for tool in registry.list():
    assert tool.schema.valid_json_schema()
    assert tool.description.length >= 20      # 描述过短易致误选
    assert tool.version is not None
    assert tool.idempotent in (True, False)   # 显式声明幂等性

6.3 第三步：在宿主层做统一适配

推荐在宿主内部设一个“工具网关”层，向上对模型暴露统一的 schema 格式，向下对接 MCP Server 或本地函数。这样模型侧无需感知工具来源，供给侧的变更也不会波及表示层。网关同时承担三件事：schema 转换、调用路由、结果归一化。这一层是协同架构的枢纽，也是可观测性的埋点位置。

6.4 第四步：建立调用链的可验证性

工具调用最怕“看起来成功、实际错误”。建议为每次调用记录：请求参数、原始返回、耗时、是否命中缓存、模型给出的调用理由（若模型支持）。对关键工具设置结果校验（如返回值 schema 校验、业务规则校验），校验失败时触发重试或降级。可观测性不是附加项，而是协同架构能否长期运行的前提。

6.5 第五步：按场景做渐进式引入

不要一次性把所有工具迁移到 MCP。建议从“跨应用复用需求最强、鉴权最复杂”的工具开始试点，验证连接稳定性与权限模型后再扩展。对于高频、低风险的内部工具，保留 Function Calling 直连可能更简单。渐进式引入的判据是：该工具的复用方是否超过两个、变更频率是否高于宿主发布频率、是否涉及敏感权限。

拓展阅读：MCP 官方规范与示例服务器可参考 modelcontextprotocol.io；OpenAI 函数调用文档见 platform.openai.com；JSON Schema 规范见 json-schema.org。

七、局限、风险与治理边界

7.1 安全边界：工具即权限

每一个被暴露的工具都是一条潜在的攻击面。MCP 的标准化在降低集成成本的同时，也放大了“工具被滥用”的风险：一个配置不当的 Server 可能把文件系统或数据库能力暴露给不该访问的模型会话。治理上应遵循最小权限原则，工具粒度尽量细，敏感操作要求显式确认，并对 Server 做来源校验与版本锁定。

7.2 可靠性边界：协议不保证语义正确

MCP 保证消息格式正确、连接可用，但不保证模型选对了工具、传对了参数。Function Calling 保证输出符合 schema，但不保证参数在业务上合理。两层都通过校验，仍可能出现“格式正确但语义错误”的调用。因此，业务层校验不可省略，尤其在写操作场景中。

7.3 生态边界：标准化的双刃剑

标准化带来互操作性，也带来同质化与锁定风险。若某宿主深度绑定特定 MCP 实现，迁移成本可能高于预期。本文评述：在协议快速演进期，保持工具契约与宿主实现的解耦，比追逐最新协议版本更重要。协议版本会变，稳定的工具语义不会。

八、结论与展望

回到标题的问题：Function Calling 会被 MCP 取代吗？基于前文的分层分析，答案是否定的。Function Calling 是模型表达调用意图的表示层能力，MCP 是工具供给与连接的协议层设施，二者在数据流上串联、在职责上互补。把它们对立，源于对抽象层级的误读。

笔者认为，更值得关注的趋势是：表示层与供给层的接口正在收敛为“工具契约”这一共同对象。未来无论协议如何演进，谁能把工具契约治理得稳定、可校验、可观测，谁就能在工具调用这件事上获得工程优势。协议是手段，契约才是资产。

对从业者的建议是：先建立分层心智模型，再按场景做渐进式引入；把工具契约当作 API 治理，把调用链当作可观测系统建设；在选型上避免“非此即彼”，在架构上保留适配层以应对协议演进。工具调用的复杂度不会因为某个协议的出现而消失，它只会从“接入”转移到“治理”。

九、主要参考文献

1. Anthropic. Model Context Protocol Specification. 2024. 规范链接
2. OpenAI. Function Calling Guide. 2023–2025. 文档链接
3. JSON Schema Organization. JSON Schema Specification. 规范链接
4. JSON-RPC Working Group. JSON-RPC 2.0 Specification. 规范链接
5. Schick T, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761, 2023.
6. Qin Y, et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. arXiv:2307.16789, 2023.
7. Patil S G, et al. Gorilla: Large Language Model Connected with Massive APIs. arXiv:2305.15334, 2023.
8. Yao S, et al. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629, 2022.
9. Wang L, et al. A Survey on Large Language Model based Autonomous Agents. arXiv:2308.11432, 2023.

说明：本文涉及的工具数量与 token 估算为工程经验性模拟数据，用于说明成本结构，非实测基准；协议字段以官方规范最新版本为准。近三年文献占主要参考文献多数，完整文献清单（60 篇以上）因篇幅从略，引用时请以原始文献为准。