Function Calling 与 MCP：Agent 工程中的工具调用边界与协议选择

过去一年，很多团队在做 AI Agent 时都会遇到同一个问题：模型已经能理解自然语言，也能推理下一步动作，但它到底应该怎样调用外部系统？是直接给大模型声明几个函数，让模型返回参数，然后应用层执行？还是引入 MCP 这类协议，把外部工具、资源、上下文统一接入 Agent？

这个问题看似是技术选型，实际关系到产品形态、系统边界、权限治理、可维护性和团队协作方式。Function Calling 和 MCP 都在解决“让模型连接真实世界”的问题，但它们站的位置不同：Function Calling 更靠近模型推理接口，解决的是“模型如何表达要调用哪个函数以及参数是什么”；MCP 更靠近能力接入层，解决的是“Agent 如何以统一协议发现、访问和治理外部工具与上下文”。

如果把 Agent 看成一个会思考、会行动的数字员工，Function Calling 像是给它一份可用操作清单；MCP 则更像给它接入一套标准化工作台，工作台里有系统、数据、文件、工具、权限和运行约束。两者不是简单替代关系，而是经常组合使用：模型可以通过 Function Calling 决定调用动作，应用层再通过 MCP Server 去访问真实能力。

封面主图：Function Calling vs MCP

一、先统一概念：它们分别解决什么问题

Function Calling，通常指大模型 API 提供的一种工具调用机制。开发者向模型声明一组函数名称、描述和参数 schema，模型在对话过程中根据用户意图和上下文，输出结构化的调用请求，例如选择query_order_status并填入order_id。应用拿到这段结构化结果后，自行执行函数，再把执行结果返回给模型，模型继续回答或进行下一步动作。

它的关键价值是把“自然语言意图”转成“结构化程序调用”。相比让模型输出一段自由文本命令，Function Calling 更稳定、更容易校验，也更适合接入业务接口。对开发者来说，它降低了意图识别、参数抽取和多轮补槽的实现成本。

MCP，Model Context Protocol，是一种面向模型应用的上下文接入协议。它定义了客户端与服务端之间如何暴露 tools、resources、prompts 等能力，让不同 Agent 或应用可以用统一方式连接外部系统。MCP Server 可以封装一个订单系统、监控平台、工单系统、知识库、数据库查询代理，MCP Client 则通常嵌入在 Agent 框架或智能应用中。

它的关键价值是标准化“能力供给方式”。过去每接一个系统都要写一套适配器、鉴权逻辑、工具描述和数据读取方式；有了 MCP，团队可以把外部系统包装成标准服务，让多个 Agent 复用同一套能力接入层。

简单说：Function Calling 关注模型怎么发起调用，MCP 关注外部能力怎么被标准化接入。

架构对比图：模型/应用层 vs 协议/能力层

二、核心差异：一个是调用机制，一个是能力协议

很多争论来自把两者放在同一层比较。实际上，它们处在不同抽象层。

Function Calling 是模型接口层能力。它通常由模型厂商或推理框架提供，输入是工具定义和对话上下文，输出是结构化函数调用。它不关心函数背后连接的是数据库、HTTP 服务还是本地脚本，也不规定工具如何发现、如何授权、如何复用。开发者必须在自己的应用里维护函数注册、执行逻辑、错误处理、重试和审计。

MCP 是协议层能力。它规定 Agent 与外部能力服务之间的交互方式。工具可以由不同团队维护，运行在独立进程、容器或远端服务中，通过统一协议被发现和调用。MCP 更关心工具列表如何暴露、资源如何读取、能力如何描述、服务如何隔离，以及客户端如何与多个能力源协作。

可以用一个工程类比：Function Calling 像编程语言里的函数签名与调用约定；MCP 像一套插件协议或服务接入规范。函数签名解决“我调用什么、传什么参数”，插件协议解决“这些能力由谁提供、如何加载、如何隔离、如何被多个应用复用”。

因此，问“Function Calling 和 MCP 选哪个”并不总是准确。更合理的问题是：当前系统只需要模型在应用内调用少量固定函数，还是需要构建可扩展、可治理、跨应用复用的 Agent 能力生态？

调用链路图：从用户请求到可审计结果

三、从一次工具调用看完整链路

假设用户问：“帮我查一下订单 A123 的物流是否异常，如果异常就创建客服工单。”

使用 Function Calling 的典型链路是：应用把get_order_logistics和create_support_ticket两个函数描述传给模型；模型先返回对get_order_logistics的调用，参数是订单号；应用执行查询，把物流状态返回给模型；模型判断异常后，再返回对create_support_ticket的调用；应用创建工单，再把结果交给模型组织回复。

这个流程清晰直接，适合单个应用内的明确业务动作。但所有能力都由应用自己维护：函数定义写在哪里、接口凭证放在哪里、调用失败怎么处理、哪些用户能创建工单、日志如何追踪，都需要应用自行设计。

如果引入 MCP，链路会变成：Agent 连接订单 MCP Server 和客服 MCP Server；订单服务暴露查询订单、查询物流、读取异常规则等工具或资源；客服服务暴露创建工单、查询工单、补充备注等工具。Agent 在运行时发现这些能力，模型仍可通过上层工具调用机制选择动作，但真实执行由 MCP Server 完成。

这种方式的优势是边界更清楚。订单团队可以维护订单 MCP Server，客服团队维护客服 MCP Server，Agent 应用无需理解每个系统内部细节。权限、审计、限流、脱敏也可以沉到服务侧治理，而不是散落在每个智能应用里。

四、对开发者：Function Calling 更轻，MCP 更可扩展

如果你是 AI Agent 应用开发者，最直观的差异是开发复杂度和长期维护成本。

Function Calling 上手很快。你只需要定义函数 schema，写好执行函数，然后把模型返回的调用请求映射到本地代码即可。对于原型验证、单一应用、少量工具、固定流程，它非常高效。例如内部运维助手只需要支持查询主机状态、重启某个无状态服务、查询最近告警三类动作，用 Function Calling 就能快速落地。

但随着工具数量增加，Function Calling 的维护压力会快速上升。几十个函数混在同一个应用里，工具描述会膨胀，模型选择工具的准确率可能下降；不同业务域的鉴权和异常处理逻辑耦合在一起；多个 Agent 项目重复定义同一批工具；工具版本升级后还要逐个应用适配。

MCP 的引入成本更高，因为你需要设计 MCP Server、能力边界、部署方式和权限策略。但它在规模化之后更有价值。一个风控 MCP Server 可以被审批助手、客服助手、交易分析助手复用；一个监控 MCP Server 可以同时服务故障诊断 Agent、值班助手和容量分析系统。能力沉淀下来后，新增 Agent 不再从零接接口，而是连接已有能力源。

所以开发者可以遵循一个经验：工具少、生命周期短、只服务一个应用时，优先 Function Calling；工具多、跨团队复用、需要统一治理时，引入 MCP。

五、对产品经理：差异会影响产品边界和交付方式

从产品视角看，Function Calling 更像“在当前产品里增强几个智能动作”。它适合把已有页面或流程变成对话式操作，例如让客服系统支持自然语言查询订单、让运维平台支持自然语言查看告警、让 CRM 支持自动补全客户跟进记录。产品边界仍然是原来的系统，AI 只是新的交互入口。

MCP 更像“把企业能力开放给多个智能入口”。当一个组织希望不同 Agent 都能使用统一的客户、订单、库存、监控、权限、知识等能力时，MCP 会改变产品交付方式。能力不再只嵌在某个前端页面里，而是以标准协议对 Agent 开放。

这意味着产品经理需要考虑的不只是某个功能能不能做，还要考虑能力如何被复用：这个工具应该属于哪个业务域？哪些用户和哪些 Agent 能使用？结果展示要不要标准化？调用失败时应该给出业务解释还是技术错误？能力升级是否影响已有 Agent？

举例来说，一个“退款风险判断”能力，如果只用于客服助手，可以直接作为 Function Calling 函数接入；如果未来还要给订单审核、商家运营、异常交易分析等多个场景使用，就更适合包装成风控 MCP Server 的标准工具，并定义清晰的输入输出、权限和审计策略。

六、对架构师：真正的分水岭是治理与边界

架构师最应该关注的不是调用能不能跑通，而是系统能否在规模化后仍然可控。

Function Calling 的风险在于应用层膨胀。每个 Agent 都维护自己的工具注册、鉴权、日志、限流和错误处理，短期看灵活，长期看会形成大量重复实现。更严重的是，安全策略容易不一致：某个 Agent 允许查询全量客户信息，另一个 Agent 做了脱敏，第三个 Agent 又绕过了审计。

MCP 的价值在于把能力边界前移到服务层。业务系统通过 MCP Server 暴露经过设计的工具，而不是把底层接口直接交给 Agent。Server 可以内置权限检查、字段脱敏、参数校验、速率限制、操作审计和环境隔离。Agent 只看到可用能力，而看不到不该暴露的内部接口。

但 MCP 也不是银弹。它会引入新的基础设施复杂度：服务注册、连接管理、版本兼容、运行隔离、观测指标、故障降级都需要设计。对于小团队或早期项目，一上来就铺 MCP 可能会让交付变慢。架构上更推荐渐进式演进：先用 Function Calling 验证高价值场景，再把稳定、复用、风险较高的能力沉淀为 MCP Server。

一个成熟架构通常会是分层组合：模型层负责理解意图和推理计划；工具选择层使用 Function Calling 或类似机制产生结构化动作；能力接入层通过 MCP 连接外部系统；治理层负责权限、审计、策略、监控和回放。

七、常见误区：不要把 MCP 当成更高级的函数列表

第一个误区是认为 MCP 只是把函数换了个地方。这样用当然也能工作，但会浪费协议价值。MCP 不只是 tools，还可以表达 resources 和 prompts。比如监控系统不只暴露“查询告警”工具，还可以暴露服务拓扑、运行手册、指标资源和诊断提示模板。Agent 能获得的不只是动作入口，还有上下文材料。

第二个误区是把所有内部接口都原样开放给 Agent。无论 Function Calling 还是 MCP，都不应该把底层能力不加筛选地暴露。Agent 工具应该是面向任务设计的业务动作，而不是数据库表或内部 RPC 的机械映射。好的工具粒度应该让模型容易理解、参数容易校验、结果容易解释。

第三个误区是忽视权限。模型会“选择调用”，但不应该“决定是否有权调用”。权限必须由应用层或服务层强制执行。尤其是涉及订单修改、账户冻结、服务重启、风险处置等动作时，必须有最小权限、二次确认、审批流或人类兜底。

第四个误区是只看成功路径。真实业务里，工具会超时、参数会缺失、系统会限流、结果会冲突。Function Calling 和 MCP 都需要配套错误语义，让模型知道是应该追问用户、重试、降级，还是停止操作并解释原因。

八、工程落地建议：从工具清单走向能力产品化

第一步，先梳理 Agent 的任务边界。不要从“有哪些接口能接”开始，而要从“用户希望完成哪些任务”开始。比如客服场景中的任务可能是查询订单、判断售后条件、创建工单、补充处理记录；运维场景中的任务可能是定位告警、查询变更、查看日志摘要、执行低风险恢复动作。

第二步，为每个任务设计工具契约。工具名称要表达业务语义，参数要尽量结构化，返回值要稳定。不要让模型解析一大段混乱文本，也不要让工具返回过多无关字段。一个好工具应该像产品 API，而不是临时代码入口。

第三步，先用 Function Calling 快速验证。验证重点不是模型能不能调用函数，而是用户意图是否真实、任务闭环是否顺畅、异常处理是否可接受、调用结果是否能支撑决策。这个阶段追求快，避免过早建设复杂平台。

第四步，把高复用、高风险、高价值能力沉淀为 MCP Server。判断标准包括：是否被多个 Agent 使用，是否需要独立权限治理，是否由专门业务团队维护，是否涉及敏感数据或关键操作，是否需要统一审计与监控。

第五步，建立统一观测。无论采用哪种方式，都要记录模型输入摘要、工具选择、参数、执行结果、耗时、错误类型和最终响应。没有观测，就无法评估工具描述是否清晰、模型是否误调用、权限策略是否有效，也无法做问题回放。

第六步，设计人类介入点。对于不可逆或高影响动作，例如批量冻结账号、回滚生产服务、调整风控策略，不应该让 Agent 自动执行到底。更稳妥的方式是让 Agent 完成信息收集和方案建议，由人确认后再执行。

选型决策图：什么时候用 Function Calling，什么时候引入 MCP

九、如何选择：用四个问题快速判断

第一个问题：这个能力只服务一个 Agent，还是会被多个 Agent 复用？如果只服务一个应用，Function Calling 足够简单；如果跨多个入口复用，MCP 更合适。

第二个问题：这个能力是否需要独立治理？如果涉及敏感数据、关键操作、复杂权限和审计要求，应优先考虑 MCP Server，把治理放在能力提供方。

第三个问题：工具数量是否会持续增长？少量稳定工具可以直接放在 Function Calling 中；大量工具需要分类、发现、复用和版本管理时，MCP 的收益会更明显。

第四个问题：团队组织是否分域协作？如果订单、客服、风控、运维由不同团队维护，各自提供 MCP Server 会比让一个 Agent 团队维护所有适配逻辑更健康。

最终推荐的不是二选一，而是组合：Function Calling 负责模型与应用之间的结构化动作表达；MCP 负责应用与外部能力之间的标准化接入。前者让模型会“下指令”，后者让系统能“接得住”。

十、结语：Agent 能力建设的重点是边界清晰

Function Calling 让 Agent 从“会说”走向“会做”，MCP 让 Agent 从“单点能做”走向“体系化接入”。前者解决交互闭环，后者解决规模化协作。对于真正要落地的 Agent 项目，最重要的不是追逐某个新名词，而是把模型、工具、协议、权限和业务责任边界设计清楚。

如果你的目标是快速验证一个智能流程，从 Function Calling 开始没有问题；如果你的目标是建设企业级 Agent 平台，让多个智能应用安全、稳定、可复用地接入业务系统，就应该尽早规划 MCP 或类似协议层。成熟的 Agent 工程实践，往往不是选择某一个技术，而是在正确的层次使用它们。