主题
高频面试题
Agent 系统中的 Function Calling 和 MCP 有什么区别？各自的优缺点是什么？
这是工具调用体系的高频分层题。面试官想确认你知道 Function Calling 解决“模型怎么提出工具调用”，MCP 解决“工具怎么被 Agent 标准化接入”。
面试官角度分析，想考什么
Function Calling 和 MCP 是替代关系吗？
考分层：前者是模型如何表达调用意图，后者是工具如何标准化接入。一次调用从模型到外部系统怎么走？
考链路：模型输出 tool call，Host 或应用层执行，或经 MCP Client 调 Server，结果再回灌。什么时候引入 MCP？安全边界在哪？
考取舍：工具要跨 Agent 复用再上 MCP；权限、确认和审计仍在 Host 和应用层。
可直接抄走的 30 秒参考答案
text
Function Calling 和 MCP 不在同一层。Function Calling 是模型 API 层能力，解决模型怎么用结构化 JSON 表达“我要调哪个工具、参数是什么”；MCP 是 Agent 或 Host 到工具进程的标准协议，解决外部工具、资源和 prompt 怎么被不同 Agent 复用。小型应用里几个自有函数直接用 Function Calling 就够了；如果工具要跨应用、跨团队、跨 Agent 复用，或者需要动态发现和独立部署，就适合引入 MCP。生产上两者通常组合：模型用 Function Calling 决策，Host 通过 MCP 执行工具调用。面试回答详解，知其所以然
这道题最重要的是不要把它们放在同一层比较。Function Calling 是模型能力，MCP 是工具接入协议。它们经常一起出现，但解决的问题不同。
1. Function Calling 是模型 API 层能力
Function Calling 的基本流程是：
text
应用声明 tools schema -> LLM 返回 tool_calls -> 应用执行函数 -> 工具结果回传 LLM它关注的是模型如何稳定输出结构化调用请求。你把函数名、描述和 JSON Schema 给模型，模型判断需要调用工具时，返回工具名和参数。真正执行函数的是应用代码。
优点：
- 简单直接：一个应用、几个自有函数，很快就能接起来。
- 模型原生支持：主流模型 API 对工具调用、结构化参数和并行 tool calls 支持越来越成熟。
- 低运维成本：不需要额外起 MCP Server 或处理长连接协议。
- 适合强业务内聚：工具只服务当前应用，不需要复用给其他 Agent。
缺点：
- 复用性差：每个应用都要重新声明工具、写适配层、处理鉴权和错误格式。
- 跨厂商差异：不同模型厂商的 tools 格式、tool_choice、返回结构不完全一样。
- 发现能力弱：工具通常由应用静态传入，动态发现、订阅和版本管理要自己做。
- 工具生态难扩展：第三方工具无法“一次实现，到处可用”。
2. MCP 是 Agent 到工具进程的标准协议
MCP 的基本链路是：
text
Host/Agent -> MCP Client -> MCP Server -> 外部工具 / 数据源MCP Server 暴露 tools、resources、prompts。Host 连接 Server 后，可以通过 tools/list 发现工具，通过 tools/call 调用工具，通过 resources/read 读取资源。Host 再把这些工具转译成模型 API 能理解的 Function Calling / Tool Calling schema。
优点：
- 标准化接入：一个 MCP Server 可以被多个支持 MCP 的 Host 或 Agent 使用。
- 动态能力发现：Server 可以暴露工具列表、资源列表和 prompt 模板。
- 工具与应用解耦：工具方独立发布，Host 方统一连接，不必 N 个应用乘 M 个工具重复适配。
- 更适合生态：数据库、GitHub、浏览器、文件系统、内部平台都可以包装成 MCP Server。
- 资源和 prompt 不是硬塞成函数：MCP 把可读资源、可执行工具和可复用 prompt 分开建模。
缺点：
- 架构复杂度更高：要运行 server、处理 transport、初始化握手、鉴权、超时和错误。
- 安全面更大：MCP Server 可能是供应链风险入口，尤其是本地文件、shell、浏览器和数据库工具。
- 调试链路更长：失败可能发生在模型选择、Host 转译、MCP Client、Server、外部 API 任一层。
- 不是所有模型都直接理解 MCP：模型通常仍然通过 Function Calling 表达调用意图，MCP 在 Host 执行层。
3. 两者如何组合工作
最常见的组合链路是：
text
① Host 连接 MCP Server，拉取 tools/list
② Host 把 MCP tool schema 转成模型 API 的 tools
③ 模型通过 Function Calling 返回 tool_call
④ Host 根据 tool 名找到对应 MCP Server
⑤ MCP Client 发送 tools/call
⑥ MCP Server 执行并返回结果
⑦ Host 把结果作为 tool result 回传给模型所以 Function Calling 和 MCP 不是“谁替代谁”，而是上下游：
- Function Calling 让模型能说：“我要调用
search_docs，参数是这些。” - MCP 让 Host 能说：“
search_docs来自这个 MCP Server，我用标准协议去调用它。”
4. 什么时候选哪个
直接用 Function Calling：
- 工具数量少，且只服务当前应用。
- 工具就是你代码里的几个函数或内部 API wrapper。
- 你需要最低延迟、最低运维复杂度。
- 团队还在原型阶段，协议标准化收益不明显。
引入 MCP：
- 同一批工具要给多个 Agent、IDE、桌面应用或团队复用。
- 工具来自第三方生态，或者你希望对外发布工具能力。
- 需要动态发现 tools/resources/prompts。
- 工具需要独立进程隔离、独立部署、独立版本管理。
- 企业内部有统一工具网关，希望模型应用只接标准协议。
组合使用：
- 多数生产 Agent 会组合使用：模型侧仍用 Function Calling，工具生态和外部系统接入走 MCP。
5. 安全取舍
Function Calling 的安全重点在应用执行层：
- 校验模型返回的参数。
- 做用户级 ACL 和业务规则检查。
- 高风险函数人工确认。
- 函数执行超时、重试、幂等和审计。
MCP 的安全重点除了执行层，还多了供应链和进程边界：
- 审核 MCP Server 来源和版本。
- 限制 Server 可访问的文件、网络、环境变量和凭据。
- 为每个 Server 配最小 scope token。
- 记录 tools/list、tools/call、参数和结果摘要。
- 防止工具描述或返回内容携带 prompt injection。
面试官追问3个问题
追问一：模型能直接调用 MCP Server 吗？
- 考察点：是否理解执行主体。
- 回答方向：通常不能。模型返回的是工具调用意图，Host/Agent Runtime 负责把它路由到 MCP Client，再由 MCP Client 调 MCP Server。模型本身不直接连 Server。
追问二：MCP tools 和 OpenAI tools schema 能完全一一映射吗？
- 考察点：协议差异意识。
- 回答方向：常见工具名、描述、参数 schema 可以映射，但 MCP 还有 resources、prompts、capabilities、transport、连接状态等概念，不是简单 JSON Schema 等价。Host 需要做适配。
追问三：什么时候不该引入 MCP？
- 考察点：是否会控制复杂度。
- 回答方向：工具很少、只服务单个应用、生命周期跟应用强绑定、延迟敏感、团队没有运维 MCP Server 的需求时，直接 Function Calling 更合适。
扩展知识
一个完整工具调用链路
text
MCP tools/list
-> Host 转成 LLM tools schema
-> LLM 返回 Function Calling tool_call
-> Host 路由到 MCP Client
-> MCP tools/call
-> 外部系统执行
-> tool result 回到 LLM这个流程能帮你在面试里避免一句“模型调 MCP”说糊。严格说，是 Host/Agent Runtime 把模型的 tool call 转成 MCP 调用。
Resource 不应该都做成 Function
MCP 把 Resource 单独建模很重要。文件、数据库 schema、文档片段这类“可读上下文”不一定要让模型主动调用函数读取。很多时候由用户或 Host 选择资源放进上下文更安全、更可控。
MCP 不会消灭自定义函数
项目内部的小工具、强业务逻辑、强事务操作，仍然适合直接写在应用层。MCP 更适合边界清晰、可复用、可独立部署的能力。不要为了标准化把所有内部函数都包装成 MCP Server。