MCP vs Function Calling 怎么选?
Agent 场景下两种工具调用方式的架构与功能对比
原题：请对比分析Model Context Protocol (MCP) 与 Function Calling 在架构设计、功能特性和应用场景方面的主要区别。
Agent · 百度真题
30 秒回答
- 明确MCP是开放协议、Function Calling是模型能力的本质区别
- 对比两者在架构层级（应用层vs模型层）的差异
- 说明MCP的跨模型兼容性和生态优势
- 分析Function Calling的即插即用和低延迟优势
回答与解析
答案要点
- 明确MCP是开放协议、Function Calling是模型能力的本质区别
- 对比两者在架构层级（应用层vs模型层）的差异
- 说明MCP的跨模型兼容性和生态优势
- 分析Function Calling的即插即用和低延迟优势
- 结合具体场景说明选型依据
核心定位差异
| 维度 | MCP | Function Calling |
|---|---|---|
| 本质 | 开放协议标准（应用层） | 模型原生能力（模型层） |
| 设计目标 | 统一AI与外部系统的交互接口 | 让LLM自主决策调用外部工具 |
| 主导方 | Anthropic开源，社区驱动 | OpenAI首创，各模型厂商实现 |
架构设计对比
MCP 的架构特点
- Client-Server 模式：Host（如Claude Desktop）↔ Client ↔ Server（工具提供者）
- 标准化传输：支持 stdio、SSE、HTTP 等多种传输层
- 能力发现：Server 通过
tools/list动态暴露能力，支持运行时热更新
Function Calling 的架构特点
- 模型内嵌：直接通过 prompt 注入工具 schema，模型输出结构化调用指令
- 紧耦合：工具定义与模型推理绑定，切换模型需重新适配 schema
- 简单直接：无额外服务层，延迟更低
功能特性对比
| 特性 | MCP | Function Calling |
|---|---|---|
| 跨模型兼容 | ✅ 一次实现，多模型复用 | ❌ 各模型 schema 语法差异大 |
| 工具生态 | 可复用社区 Server（如GitHub、Slack官方MCP） | 需自行实现或依赖平台封装 |
| 动态发现 | 支持运行时工具增减 | 需重启或重新构造 prompt |
| 调试体验 | 有 Inspector 等官方工具链 | 依赖模型厂商的 playground |
| 延迟 | 多一跳网络/进程通信 | 直接模型输出，更低 |
应用场景建议
优先选 MCP
- 构建多 Agent 协作平台，工具需要被多个模型复用
- 希望接入成熟的第三方工具生态（如企业已有大量MCP Server）
- 工具提供方与 AI 应用开发方是不同团队，需要明确边界
优先选 Function Calling
- 追求极致延迟的实时场景（如车载语音助手）
- 简单应用，工具数量少且变动不频繁
- 深度绑定单一模型厂商（如纯 OpenAI/Azure 生态）
一句话总结
MCP 是 "AI 的 USB-C 接口"——标准化、可插拔、生态化；Function Calling 是 "内置工具箱"——简单直接、性能最优、但各玩各的。两者并非互斥，实际可结合：MCP 作为工具层的标准化封装，底层仍通过 Function Calling 触发模型。
口语版讲法(约4分钟)
- 一句话定位：MCP是协议标准，Function Calling是模型能力
- 架构差异：MCP的Client-Server vs FC的模型内嵌
- 功能取舍：跨模型兼容 vs 低延迟
- 场景选型：多Agent用MCP，实时场景用FC，实际常结合
- 落地风险：MCP额外延迟，FC锁定厂商
这道题其实问的是，当大模型需要跟外部工具交互时，我们到底是在哪个层面做这件事。MCP 和 Function Calling 本质上是两个不同层级的方案：MCP 是应用层的开放协议，像 AI 世界的 USB-C 接口，标准化、可插拔；而 Function Calling 是模型层的原生能力，更像内置工具箱，简单直接但各玩各的。
具体说一下架构。MCP 走的是 Client-Server 模式，Host 比如 Claude Desktop 通过 Client 跟 Server 通信，Server 可以动态暴露自己的能力，通过 tools/list 这样的接口让客户端发现。好处是工具提供方和 AI 应用方可以解耦，Server 热更新，客户端不用重启。而 Function Calling 是把工具 schema 直接塞进 prompt，模型输出结构化调用指令，没有额外服务层，延迟更低，但工具定义跟模型推理是紧耦合的。你换个模型，schema 语法可能就变了，得重新适配。
再来看功能特性。MCP 最大的优势是跨模型兼容，你实现一个 MCP Server，各个模型都能用，社区已经有很多现成的，比如 GitHub、Slack 的官方 MCP。而且支持运行时动态发现工具，增减不用改代码。Function Calling 的优势是简单直接，延迟少一跳，调试也方便，直接在模型厂商的 playground 就能测。但它的工具生态是割裂的，你得为每个模型单独实现，或者依赖平台封装。
说到场景选型，这里有个清晰的分界线。如果你的场景是多 Agent 协作，工具需要被多个模型复用，或者工具提供方跟 AI 应用方是不同团队，那 MCP 是更合适的选择，因为它明确了边界。反过来，如果你追求极致延迟，比如车载语音助手，或者工具少且固定，深度绑定单一厂商，那 Function Calling 更合适。
但真正落地时，这两者往往不是二选一，而是结合。举个例子，一个电商客服系统，你需要调用订单查询、退款、物流多个工具，可能底层用 Function Calling 触发模型决策，但上层用 MCP 把这些工具包装成标准接口，这样模型切换时不用改工具层，也方便接入第三方服务。
这里有个坑，就是 MCP 会引入额外的网络或进程通信延迟，对毫秒级响应的场景不友好。而且如果 MCP Server 不稳定，整个链路会断。上线前我会特别关注 Server 的可用性和超时策略，必要时做缓存或降级。反过来，Function Calling 虽然快，但容易锁定厂商，哪天你想换模型，工具适配成本很高。
所以我的判断是，MCP 更适合做工具层的标准化封装，而 Function Calling 更适合做模型触发的内联决策。有个值得深入的点是，当 MCP 和 Function Calling 结合时，MCP 的标准输出怎么跟不同模型的 Function Calling schema 对齐？这其实是个协议转换的工程问题，处理不好会引入额外复杂度。
总的来说，我更倾向于把 MCP 看成基础设施，Function Calling 看成能力入口，两者配合使用。如果团队有长期生态建设需求，我会优先推 MCP；如果只是快速验证原型，Function Calling 就够了。
关键一句:MCP与Function Calling结合时，协议转换的工程复杂度问题
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服助手，需要让模型调用订单查询、物流跟踪这些工具。现在有两种方式：一种是模型自带的Function Calling，另一种是MCP协议。你之前接触过类似的选型吗？你会怎么权衡？
- 问法 2 · 层层追问
模型调用外部工具你一般怎么实现的？……那如果换一个模型，那些工具定义是不是得重新写？……有没有一种方式能让工具的定义和模型解耦，一次写好到处用？
- 问法 3 · 直球架构
聊聊MCP和Function Calling的区别。从架构设计、功能特性、应用场景三个角度，对比一下两者的优缺点和适用情况。