MCP vs 函数调用：智能体工具选型的决策框架

浏览智能体工程圈，几乎满屏都在传递同一个信号：MCP（Model Context Protocol）正在成为 AI 智能体的新标准。新框架、新模型、新 demo 竞相宣布支持 MCP server，它承诺用统一方式让 LLM 发现并连接 API、数据库、git、本地文件和 SaaS 服务，省去为每个工具手写函数定义的麻烦。

但如果你正在搭建生产级智能体系统，可能会发现一个尴尬的现实：不少团队选择 MCP，理由其实是错的。MCP 和传统函数调用解决的是不同层面的问题。选错方向，只会带来额外的运维负担、系统复杂度和故障模式。

核心差异：静态定义 vs 动态发现

传统函数调用（OpenAI function call / Anthropic tool use）与 LLM 提示词紧密耦合。你要在提示词开头给出一个静态函数列表，包含 JSON schema、描述和参数，模型从固定集合中挑选并输出结构化 JSON 来触发调用。

这套方案在几种场景下表现优异：工具集小且固定、智能体在既定工作流中只需 2–5 个工具、工具权限和 schema 很少变化、对简单自动化任务有低延迟要求。

代价也很明显：每增加一个工具，就得手动更新系统提示词和 schema 定义。工具数量一多，上下文窗口迅速膨胀。跨模型可移植性差，为一家提供商的工具解析器写的 schema，换到另一家 LLM 上常常直接失效。

MCP 则翻转了这个模型。它不再把所有工具定义塞进提示词，而是由 MCP server 动态暴露工具、资源和提示词。智能体可以在运行时发现可用工具、读取其 schema，并通过标准化的 JSON-RPC 接口进行调用。模型不需要预先加载全部工具定义。

MCP 的优势场景包括：工具生态庞大且持续增长、希望更换 LLM 时不必重写所有工具定义、多个智能体共享同一套后端服务、需要运行时动态发现工具（例如浏览文件系统或代码仓库）。

JSON-RPC 是一种基于 JSON 的轻量级远程过程调用协议，它规定请求、响应和通知的统一结构（如 method、params、id 字段），不依赖特定传输层，可通过 stdio、HTTP 或 WebSocket 承载。MCP 选用 JSON-RPC 作为通信基石，使 MCP server 能以语言无关、框架无关的方式暴露工具、资源和提示词。对客户端而言，这意味着无需为每个后端实现定制适配器，只需按协议约定发送和接收消息，从而在不同 LLM 提供商与不同工具服务之间建立一致的调用契约。

MCP 被低估的运维成本

大多数教程不会告诉你，MCP 有实实在在的工程代价。

一个 MCP 智能体栈需要与 LLM 服务并行运行和维护 MCP server。每个 server 都要部署、健康检查、认证、权限控制、日志和故障处理。对于“调用一个 REST API 拉取用户数据”这类简单需求，MCP 完全是杀鸡用牛刀。函数调用更轻量、更易调试、更易监控。在这里加一层 MCP，只是徒增活动部件、故障点和延迟。

另一个实际痛点是调试。函数调用失败时，你直接检查提示词、模型输出和 API 响应即可。而 MCP 智能体失败时，你需要跨三层追踪：LLM 规划器、MCP 客户端和远端 MCP server。在尤其强调响应速度的生产环境，排查速度会显著变慢。

活动部件（moving parts）是软件架构中的一个经验性概念，指系统中需要独立部署、配置、监控和协调的组件数量。每一个活动部件都会引入新的故障模式、升级路径和潜在延迟。函数调用模式下，工具逻辑通常内嵌在应用代码中，活动部件少；而 MCP 模式至少额外增加 MCP 客户端和 MCP server 两层，每个 server 又可能对应独立的认证与网络边界。活动部件越多，系统在高并发或部分故障时的行为越难预测，运维和排障成本也呈非线性上升。

智能体工具选型的决策框架

以下是我在设计智能体工作流时使用的实用规则：

1. 小型固定工具集（少于 6 个工具）→ 坚持原生函数调用。 保持栈简单，没必要引入 MCP 复杂度。
2. 动态、多工具、多服务环境 → 可以考虑 MCP。 尤其当工具频繁增删或需要被多个智能体复用时。
3. 低延迟、高吞吐自动化任务 → 避开 MCP。 额外的往返调用和 server 编排会叠加延迟。
4. 共享后端资源的多智能体系统 → MCP 的标准化优势显现。 智能体可以复用同一批 MCP server 来访问数据库、读取文件和调用外部 API。

这个框架背后的逻辑是：先看工具集是否稳定、是否跨模型复用、是否对延迟敏感，再决定要不要引入 MCP 这一层。

常见误区：把 MCP 当成万能药

MCP 标准化的是工具的传输与发现层，它不会提升模型推理能力，不会减少幻觉，也不会让 LLM 更擅长判断何时调用工具。

如果你的智能体失败是因为 LLM 选错了工具或传了无效参数，从函数调用切到 MCP 并不能解决这个问题。MCP 只改变智能体“如何”调用工具，不改变模型的判断力。这是营销话术里经常被模糊掉的关键区别。

工具选择判断是指模型在给定任务上下文时，决定是否调用工具、调用哪一个工具以及如何填充参数的能力。这属于模型推理与规划层面的问题，取决于模型自身的训练质量、提示词设计以及上下文信息的完备程度。MCP 协议本身不介入这一决策过程，它只负责在模型已经决定调用某个工具后，提供标准化的发现与传输通道。因此，若智能体频繁误选工具或传错参数，应优先优化提示词、工具描述和模型选型，而非更换工具协议。

结语

MCP 是迈向可互操作智能体基础设施的重要一步，对复杂的多工具智能体系统而言，它有望成为基础组件。但它并非可以无条件替换函数调用的通用升级方案。

好的智能体工程在于让架构匹配问题规模。在给技术栈加入 MCP 之前，先问自己：我是否真的需要动态工具发现和跨模型可移植性？如果答案是否定的，原生函数调用仍然是更简单、更便宜、更易维护的选择。