面试题 · Agent
搜索「大模型 Agent」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请对比分析Model Context Protocol (MCP) 与 Function Calling 在架构设计、功能特性和应用场景方面的主要区别。
| 维度 | MCP | Function Calling |
|---|---|---|
| 本质 | 开放协议标准（应用层） |
学习内容与项目面试，在同一条路上。
| 模型原生能力（模型层） |
| 设计目标 | 统一AI与外部系统的交互接口 | 让LLM自主决策调用外部工具 |
| 主导方 | Anthropic开源，社区驱动 | OpenAI首创，各模型厂商实现 |
MCP 的架构特点
tools/list 动态暴露能力，支持运行时热更新Function Calling 的架构特点
| 特性 | MCP | Function Calling |
|---|---|---|
| 跨模型兼容 | ✅ 一次实现，多模型复用 | ❌ 各模型 schema 语法差异大 |
| 工具生态 | 可复用社区 Server（如GitHub、Slack官方MCP） | 需自行实现或依赖平台封装 |
| 动态发现 | 支持运行时工具增减 | 需重启或重新构造 prompt |
| 调试体验 | 有 Inspector 等官方工具链 | 依赖模型厂商的 playground |
| 延迟 | 多一跳网络/进程通信 | 直接模型输出，更低 |
优先选 MCP
优先选 Function Calling
MCP 是 "AI 的 USB-C 接口"——标准化、可插拔、生态化；Function Calling 是 "内置工具箱"——简单直接、性能最优、但各玩各的。两者并非互斥，实际可结合：MCP 作为工具层的标准化封装，底层仍通过 Function Calling 触发模型。
场景切入
假设你在做一个电商客服助手，需要让模型调用订单查询、物流跟踪这些工具。现在有两种方式：一种是模型自带的Function Calling，另一种是MCP协议。你之前接触过类似的选型吗？你会怎么权衡？
层层追问
模型调用外部工具你一般怎么实现的？……那如果换一个模型，那些工具定义是不是得重新写？……有没有一种方式能让工具的定义和模型解耦，一次写好到处用？
直球架构
聊聊MCP和Function Calling的区别。从架构设计、功能特性、应用场景三个角度，对比一下两者的优缺点和适用情况。
这道题其实问的是，当大模型需要跟外部工具交互时，我们到底是在哪个层面做这件事。[[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 就够了。