面经策

Agent 系统中的 Function Calling 和 MCP 有什么区别？各自的优缺点是什么？ ​

  • 标签：AI、大模型、Agent

🏛 业务架构师 ​

Function Calling 与 MCP 的对比，我从"本质—优劣—选型"讲：

本质区别：Function Calling 是模型厂商的私有能力——函数定义传给某家模型 API，模型输出调用意图；换厂商就要改一套格式。MCP 是跨厂商的开放协议——工具的发现、定义、调用、鉴权全部标准化，工具实现一次、所有应用可用。

Function Calling 的优缺点：优点是轻——无需额外协议层，单应用单模型场景几行代码搞定，延迟最低；缺点是绑定厂商格式、工具不能跨应用复用、没有统一的鉴权审计规范（要自己建）。

MCP 的优缺点：优点是标准化——工具资产化（一次建设全公司复用）、厂商中立（换模型不动工具层）、生态复用（社区现成 Server）；缺点是引入协议复杂度（连接管理、能力协商）、多一层调用链路、本地 stdio 模式下企业管控弱（需远程化部署补齐）。

选型建议：单一应用、单一模型、工具私有 → Function Calling 够用，别过度设计；多应用共享工具、要换模型自由、工具需统一治理 → MCP 必选。两者不冲突——MCP 工具最终仍通过模型的 Function Calling 能力被调用，MCP 是分发与治理层，Function Calling 是执行层。

2026 年趋势判断：MCP 已成事实标准，新项目默认按 MCP 建工具层——协议成本很低，但买到了退出自由和治理抓手，这是性价比极高的架构保险。

🏗 系统架构师 ​

Function Calling 是模型层能力，MCP 是系统集成协议——层次不同，生产中是配合关系。

Function Calling：

  • 原理：开发者把工具定义随请求注入，模型输出结构化调用意图，应用执行后回传结果；
  • 优点：零中间层、延迟最低（无协议开销）、各大模型原生支持、实现简单；
  • 缺点：工具定义与模型方言耦合（各厂商 Schema 有差异）、工具实现与应用进程耦合（无跨应用复用）、无标准化发现/生命周期/鉴权语义——每家自建轮子。

MCP：

  • 原理：工具做成独立 Server，标准协议（JSON-RPC）暴露，任何 MCP Host 复用；
  • 优点：一次实现处处可用（M×N → M+N）、标准化能力协商与传输、生态复用（GitHub/Slack 现成 Server）、工具进程隔离与集中治理（网关鉴权审计）；
  • 缺点：多一层协议与进程（延迟 +几十 ms）、架构复杂度（连接管理、版本兼容）、stdio 本地模式不适合服务端多租户。

场景选择：单体应用内置能力、性能敏感（实时对话补全类）→ 直接 Function Calling；工具需要多应用共享、企业系统接入、生态集成、独立部署治理 → MCP。实际架构：MCP Server 提供工具源，Host 把 tools/list 结果转成模型工具定义注入，模型 Function Calling 决策、MCP Client 执行——两层协作，不是二选一。

💻 全栈开发专家 ​

Function Calling 和 MCP 的区别一句话：FC 是模型层能力（会发起工具调用），MCP 是生态层协议（工具如何被发现、共享、治理）。

Function Calling 优缺点：

  • 优点：原生集成、延迟最低（无中间协议层）、实现最简单——工具定义直接随请求传；
  • 缺点：厂商格式不统一（OpenAI/Anthropic/Gemini 的 schema 各异）；工具定义耦合在应用代码里，无法跨应用复用；工具多了没有统一的管理/发现/鉴权机制。

MCP 优缺点：

  • 优点：标准化（一次封装处处使用）、独立进程部署（升级解耦）、生态现成（GitHub/数据库/浏览器 Server 拿来就用）、统一鉴权与审计收口；
  • 缺点：多一层协议开销（进程间通信/HTTP 往返）；每个工具的 JSON Schema 都要占上下文 token（挂多了烧钱）；跨进程调试链路更长。

工程决策线：

  • 3~5 个自研工具、单应用使用 → FC 直接搞，引 MCP 属于过度设计；
  • 工具需要跨应用/跨团队共享，或要接入现成生态 → MCP；
  • 两者组合是常态：MCP Server 的工具被 Host 拉取后，最终还是转成 FC 格式喂给模型——MCP 没有取代 FC，是站在它上面做了标准化。

注意点：MCP 工具规模上去后要做「工具检索」（按需注入 schema），否则上下文成本失控。