从 Agent 的架构设计来看，Function Calling（函数调用）和 MCP（Model Context Protocol，模型上下文协议）在复用性上的差异，本质上是“硬编码集成”与“标准化插件系统”的区别。

当我们在多次请求（或多个 Agent）的场景下对比两者，差异主要体现在以下几个维度：

1. 协议层面的“即插即用” (Standardization)

• Function Calling: 具有高度的模型依赖性。虽然 OpenAI 定义了一套标准，但不同模型（Claude, Gemini, Llama）的 Schema 格式和调用逻辑往往存在细微差别。
  • 复用痛点： 如果你想把为 GPT-4 开发的一套工具复用到 Claude 上，你可能需要重写 JSON Schema 或调整提示词工程。
• MCP: 是一种跨模型、跨平台的通用协议。
  • 复用优势： MCP 像是一个“USB 接口”。开发者编写一次 MCP Server（包含工具和数据），任何支持 MCP 协议的 Agent（如 Claude Desktop、IDE、自定义 Agent）都可以直接连接。这种复用是跨生态的。

2. 传输成本与“Payload”管理 (Payload Efficiency)

在多次请求中，Agent 需要维持上下文，复用性的差异会直接影响 Token 消耗：

• Function Calling:
  • 每次请求都必须在 Prompt 中携带完整的函数定义（JSON Schema）。
  • 如果 Agent 有 50 个工具，即使本次请求只用 1 个，通常也要把 50 个工具的描述全部发给模型。这种“重复定义”在多次对话中非常浪费 Token。
• MCP:
  • 采用 Client-Server 架构。Agent 只需要知道如何连接到 MCP Server。
  • 动态发现： Agent 可以根据需要向 Server 灵活查询工具列表或特定资源。在多轮对话中，它更倾向于“按需拉取”或通过标准化的方式引用资源，降低了重复发送冗长 Schema 的负担。

3. 资源与上下文的复用 (Resources vs. Tools)

这是 MCP 降维打击 Function Calling 的地方。

打个比方：
Function Calling 像是你每次去餐厅都要自带厨师和食材（Schema + Data）；
而 MCP 像是餐厅已经装修好了（Server），你只需要带上你的胃（Agent）直接连接到餐厅的接口即可。

4. 工程化的解耦 (Decoupling)

从 Agent 架构的生命周期来看，复用性体现在维护成本上：

• Function Calling (紧耦合): 工具逻辑通常直接写在 Agent 的业务代码里。当你修改一个 API 接口时，你可能需要更新所有引用该工具的 Agent 提示词。
• MCP (强解耦):
  • 逻辑下沉： 工具的实现逻辑、权限控制、数据转换都在 MCP Server 端完成。
  • 多端同步： 一旦 MCP Server 升级，所有连接到该 Server 的 Agent（无论是你的 CLI 工具还是你的 Web 助手）都会自动获得最新的能力，无需逐一修改 Agent 层的 Prompt。

总结

在多次请求和复杂 Agent 系统中：

• Function Calling 是点对点的适配，适合简单的、单一模型的快速实现，但在工具集规模化和跨模型复用时会面临“JSON 疲劳”和维护地狱。
• MCP 是中心化/总线式的适配，它将“能力提供方”与“模型推理方”彻底解耦。对于追求长效复用、跨平台协同的 Agent 开发，MCP 提供了更高级别的抽象。

如果你正在构建一个需要频繁调用外部数据库或复杂 API 集的 Agent 系统，尽早转向 MCP 架构会节省大量的重构时间。