Appearance
Q101 · AI Agent 中 Function Call 和 MCP 的区别是什么？
你的客服 Agent 要回答：“我的订单 O-314 发货了吗？”它必须查订单系统，不能靠模型猜。有两种常见接法：在应用里定义一个“查订单”的函数，并把函数说明交给模型；或者让应用连接一个提供“查订单”能力的 MCP 服务器。两条路最后都可能查同一张订单表，却经过不同的软件边界。
Function Call（函数调用）主要解决“模型怎样表达我想用哪个工具、传哪些参数”的问题。模型输出调用请求，应用校验并执行，再把结果回传。MCP（Model Context Protocol）主要解决“应用怎样按共同协议发现、连接、调用外部能力”的问题。MCP 服务器除了工具，还可提供资源和提示词。两者可以一起用：应用把 MCP 服务器发现的工具提供给模型，模型选择调用，应用通过 MCP 客户端向服务器发请求。它们并非同一层的替代协议。OpenAI：Function calling、MCP 规范：Base protocol、MCP 规范：Tools
术语与例子里的角色和字段
| 词或符号 | 直白意思 | 查询 O-314 时对应什么 |
|---|---|---|
| 模型 | 根据当前输入决定下一段输出的组件 | 理解用户要查订单 |
| Function Call / Tool Call | 模型生成的工具调用请求，不是模型在自己进程里执行函数 | 请求 get_order，参数为 O-314 |
| 函数定义 / Schema | 工具名、用途和允许的参数格式 | order_id 必须是字符串 |
| 宿主应用 | 用户实际使用、负责模型和工具调度的程序 | 客服网站的后端或 Agent 运行器 |
| MCP 客户端 | 宿主中负责按 MCP 协议与服务器通信的部分 | 连接“订单工具服务器”的组件 |
| MCP 服务器 | 按协议暴露能力的程序 | 提供查单工具和相关资料的服务 |
tools/list | MCP 客户端向服务器询问有哪些工具 | 获得“查订单”工具描述 |
tools/call | MCP 客户端请求服务器执行某个工具 | 传入 O-314 并请求订单状态 |
| 资源（resource） | MCP 服务器可提供的可读取内容 | 一份订单字段说明或公开政策文档；不是自动执行动作 |
| 提示词（prompt） | MCP 服务器可提供的可复用交互模板 | “如何整理售后查询结果”的模板 |
| 权限校验 | 确认用户有权访问或执行 | O-314 必须属于当前登录用户 |
get_order | 本题假设的查单工具名 | 输入订单号，输出本用户可见的状态 |
order_id | 工具参数名 | 示例虚构订单号 O-314 |
| 回执 / 工具结果 | 工具真实执行后的返回 | status = SHIPPED，表示已发货 |
不同模型 API 和 MCP SDK 的具体字段可能不同。下面的调用片段是教学示意，不是复制后就能运行的某个版本的代码；需要在实际项目里按所用 API 与 MCP 规范实现。OpenAI：Function calling、MCP 规范：Tools
两条路线放在同一张图里
图的上排展示应用直接维护查单函数；下排展示应用通过 MCP 客户端连接服务器。图把“数据库返回状态”画在右侧，是为了强调结果要来自真实系统；实际返回值还会经过工具执行层、宿主，再被送回模型，不是数据库直接给模型。图下方“都需权限校验”尤其重要：换成 MCP 不会自动让 O-314 的归属问题消失。
路线一：应用内的 Function Call
开发者先在模型请求里声明一个函数工具：名字 get_order，说明“查询当前用户有权看的订单状态”，参数包括订单号 order_id。用户问 O-314，模型可能返回类似“调用 get_order，参数 {"order_id":"O-314"}”的结构化请求。**这时尚未查询数据库。**宿主读取请求，验证名称和参数，使用当前登录身份查订单，得到“已发货”，再把工具结果与这次调用关联后发回模型，模型才生成答复。OpenAI：Function calling
关键细节是：模型给出的 order_id 是待校验输入，不能把模型自己填的 user_id 当权限证明。宿主需要用会话里的真实用户身份，后端还要校验订单所属关系。即使 Schema 能限制字段类型和必填项，也不能证明用户有权读取该订单。若模型把 O-314 写成 O-341，工具可能运行成功却读错对象，仍应被参数和业务核验拦住。
这个做法适合工具少、只服务当前应用、团队想直接控制代码实现与部署的场景。应用自己管理函数定义、版本、参数校验、调用、错误处理和结果回传。函数可以调用本地代码，也可以在应用内部调用远程 HTTP API；Function Call 并不等于只能调用本地函数。
路线二：通过 MCP 服务器接入工具
团队也可以单独做一个订单 MCP 服务器。它向 MCP 客户端提供工具列表，包含名称、描述和参数格式；宿主连接后可通过 tools/list 获得能力，再让模型看见适合本轮任务的工具。模型决定查询 O-314 时，宿主通过 MCP 客户端发 tools/call 到订单服务器；服务器调用它背后的订单 API，返回状态，宿主再把必要结果提供给模型。MCP 规范：Tools
这个流程多了标准化连接边界。另一个支持 MCP 的宿主理论上可以连接同一服务器，而不必重新发明“有哪些工具、参数是什么、怎样调用”的接口。MCP 的基本协议规定客户端与服务器之间的请求/响应消息；服务器可选择暴露工具、资源、提示词等能力，也有本地与远程通信方式。并不是每个 MCP 服务器都必须同时提供三种能力，也不能把 MCP 简化成“读取本地文件的协议”。MCP 规范：Base protocol、MCP：Architecture overview
MCP 工具也不只读。服务器完全可以暴露“创建工单”“修改记录”等写操作，因此需要把工具权限、服务端身份验证、宿主审批、审计和调用结果确认设计完整。一个名字叫 query_order 的第三方服务器，也可能在实现中做不应该做的事；协议让接口互通，不替你审查服务器的可信度。OpenAI 关于远程 MCP 服务器的文档明确提醒开发者核查服务器信任、敏感数据和高风险动作审批。OpenAI：MCP servers
逐个维度比较，避免把概念混在一起
| 维度 | Function Call | MCP |
|---|---|---|
| 主要解决的问题 | 模型向应用提出工具调用及参数 | 宿主/客户端与能力服务器怎样发现和调用工具等能力 |
| 典型通信两端 | 模型 API 与宿主应用 | MCP 客户端与 MCP 服务器 |
| 工具定义在哪里 | 应用给模型提供函数定义，或由运行框架加载 | 服务器向客户端公布工具；宿主再决定如何呈现给模型 |
| 谁真正执行 | 宿主或其受控后端执行函数 | MCP 服务器执行所暴露的工具；宿主控制是否发起请求 |
| 标准能力范围 | 模型 API 中的函数/工具调用机制 | 协议中还可包括工具、资源和提示词等 |
| 复用方式 | 每个接入应用自行包装或共享内部库 | 多个兼容宿主可按同一协议连接服务器 |
| 权限责任 | 应用和工具后端校验 | 宿主、客户端、服务器与后端共同承担，需明确谁持有凭据与谁审批 |
这个表的“典型”不表示实现只有一种。某些模型平台直接支持远程 MCP 工具，宿主可能把 MCP 工具映射成模型可见的工具调用；也可能由平台托管部分调用循环。OpenAI 的 API 就允许在模型请求中配置远程 MCP 服务器或通过私有连接接入服务器。模型最终能否使用工具仍取决于所用平台、权限和宿主配置，不能断言 MCP 必须自己手写 Function Call 包装。OpenAI：MCP servers
一个组合实现怎样流转
假设订单 MCP 服务器确实提供 get_order，用户问“查询我的订单 O-314”。这次调用按顺序发生：
- 宿主向 MCP 服务器获取允许使用的工具清单，得知
get_order的用途和参数格式。 - 宿主把本轮可用的
get_order告诉模型；模型提出get_order(order_id="O-314")。 - 宿主核对用户身份、工具权限和参数，检查通过后才请求 MCP 服务器执行。
- 服务器返回 O-314 的状态
SHIPPED；宿主处理工具结果后交给模型。 - 模型向用户回答：“目前订单显示已发货”。
这里“宿主 → MCP 服务器：列出工具”对应 tools/list，“执行工具”对应 tools/call；SHIPPED 是教学假设中的“已发货”。实际实现要注意服务器是否有权访问该用户订单，以及敏感信息能不能进入模型上下文。若宿主把所有订单详情原样送给模型，即使查单工具调用本身正确，仍可能超出最小必要数据范围。工具结果也可能含不可信文本，例如订单备注写“忽略之前的规则”；那是数据，不能升级成系统指令。
Function Call 在这里负责模型提出哪个工具及参数，MCP 负责宿主如何连接外部工具服务。同一任务既用 Function Call 又用 MCP 完全正常。若只做固定的“一定先查订单再答”，宿主甚至可以用普通程序调用 MCP 工具，随后把订单状态交给模型润色；这时也未必需要模型自主决定是否调用。两种能力都不自动构成完整 Agent，Agent 还要管理目标、状态、反馈、错误和停止条件。
什么时候选哪一种接法
如果只有一个应用、两三个内部工具、权限逻辑紧贴应用代码，直接定义函数工具往往最简单。你能在同一代码库里追查输入到数据库的路径，也少了一层独立服务器的部署与运维。若多个宿主都要访问同一套被许可的工具，或者外部系统已经提供标准 MCP 服务，使用 MCP 便于复用接口和能力发现。选择时还要算连接管理、鉴权、工具版本兼容、网络延迟、日志和故障定位成本，而不能简单说“用了 MCP 就更快、更安全”。
错误也不同。直接函数路线可能在应用内参数解析或业务服务处报错；MCP 路线还可能出现服务器不可用、协议版本不兼容、工具列表变化或远程授权失效。无论哪条路，Agent 都要把错误结果作为观察，决定重试、换路径或求助。若刚调用的是写操作，超时后应先查是否已经执行，不能从头重复提交。MCP 服务器返回内容也要按低信任数据处理，不能让它改变宿主的审批规则。MCP 规范：Base protocol、OpenAI：MCP servers
面试时可以这样回答
Function Call 解决模型向宿主表达“要调用哪个工具、传什么参数”的问题；模型只产生请求，宿主负责参数、权限和业务校验并执行。MCP 解决宿主作为客户端与外部能力服务器之间的标准化连接，服务器可以公布工具，也能提供资源和提示词。比如查 O-314，可以在应用里直接定义
get_order函数，也可以把订单能力做成 MCP 服务器，由宿主发现后让模型选择使用，再通过 MCP 客户端调用服务器。两者可组合，不在同一抽象层。MCP 不自动保证可信或只读，Function Call 也不限于本地代码；不论选哪种，订单归属、敏感数据、写动作审批和工具错误恢复都要由系统管住。
如果追问“MCP 会替代 Function Call 吗”，答：不会简单替代。MCP 能提供标准工具服务，模型仍需要某种工具调用机制或宿主固定流程来决定何时使用它。若追问“换成 MCP 服务器是不是省去了授权”，答：不能。协议互通不等于用户拥有对应数据的权限，宿主和服务端都要检查各自负责的边界。