Function Calling、MCP、Agent 工具调用到底有什么区别？
最近很多人聊 AI 应用，几句话里会同时出现 Function Calling、MCP、Agent、工具调用、插件。听起来都差不多：模型不会自己查数据库，也不会自己改文件，所以我们给它一个工具，它想用的时候就去调。
但如果真这么理解，后面很容易踩坑。比如有人会问：既然 OpenAI 已经有 Function Calling 了，为什么还要 MCP？既然 MCP 能连接工具，那它是不是 Agent？既然 Agent 会调工具，那是不是把所有 API 都包装成工具就行？
这些问题不是术语洁癖，是真会影响工程设计。你要是把 Function Calling 当成 MCP，就会把一堆工具协议、鉴权、资源发现都塞进业务代码里。你要是把 MCP 当成 Agent，就会误以为接了一个 MCP Server，系统就自动会规划任务。你要是把 Agent 当成普通接口调用，就会低估它带来的权限、日志、回滚问题。
我用一句话先压住：
Function Calling 是模型“怎么描述我要调用哪个函数”；MCP 是工具“怎么标准化暴露给 AI 应用”；Agent 是系统“怎么围绕目标自主选择、调用、检查这些工具”。
这三个不是替代关系，更像三层东西。
先从最熟悉的 Function Calling 说起
Function Calling 最好理解。你在代码里定义几个函数，比如：
{"name":"query_order","description":"查询订单状态","parameters":{"type":"object","properties":{"orderId":{"type":"string"}},"required":["orderId"]}}然后你把这个函数描述交给模型。用户问“帮我查一下 12345 订单到哪了”，模型不会真的执行函数，它只会返回一个结构化意图：我想调用query_order，参数是orderId=12345。
真正执行函数的是你的程序。你的程序拿到模型给出的函数名和参数，自己去查数据库、调内部 API、处理异常，再把结果丢回模型，让模型组织成用户能看懂的话。
所以 Function Calling 的核心不是“AI 拥有了函数”，而是模型输出从自然语言变成了结构化调用请求。
这件事很重要。以前模型说“我建议你查询订单接口”，程序还要从文本里猜它的意思。现在模型直接给一个 JSON，程序就好接了。它让 LLM 从聊天机器人往应用组件靠近了一大步。
但 Function Calling 也有一个很明显的边界：函数是谁定义的？一般是应用开发者定义的。函数在哪里执行？一般在当前应用代码里执行。工具列表怎么发现？通常也是你在代码里写死或者配置进去。
如果只是做一个客服助手、数据问答助手、内部审批助手，这够用了。你的系统就那几个工具，开发团队自己维护，也没打算让别的 AI 客户端来复用。
问题出在规模变大以后。
Function Calling 的麻烦：每个应用都要重新接一遍工具
假设公司里有 10 个 AI 应用：客服、销售、运营、BI、研发助手、工单助手、知识库助手、合同助手、财务助手、人事助手。
它们都需要查用户信息、查订单、读知识库、拿文件、调用搜索、查权限。
如果只靠 Function Calling，每个应用都要自己定义一遍工具 schema，自己写一遍鉴权，自己处理一遍连接方式。A 应用里叫query_customer，B 应用里叫getUserInfo，C 应用里参数叫uid，D 应用里参数叫user_id。
短期能跑，长期会乱。
这就像早年每个系统自己写数据库连接，没有统一驱动，没有统一连接池，也没有统一迁移方式。不是不能用，是一多就难管。
MCP 要解决的就是这类问题。
MCP 解决的是“工具怎么被 AI 应用发现和使用”
MCP，全称 Model Context Protocol。它不是某个模型能力，也不是某个 Agent 框架。更准确地说，它是一个协议：规定 AI 应用和外部工具、资源之间怎么通信。
官方规范里把 MCP 里的能力大致分成几类：工具、资源、提示词等。工具可以被模型调用，资源可以被客户端读取，提示词可以作为可复用模板暴露出来。它的目标不是让某个应用多一个函数，而是让工具方可以用统一方式暴露能力，让多个 AI 客户端都能接。
你可以把它理解成：
Function Calling 更像“我这个 App 内部有几个可调用函数”；
MCP 更像“我这个工具服务，用统一协议告诉 AI 客户端：我有哪些能力、参数是什么、怎么调用、能读哪些资源”。
举个更接地气的例子。你有一个 Git 仓库工具，里面能读文件、搜索代码、看 diff、跑测试。如果每个 AI IDE 都自己写一套接入逻辑，那重复得很厉害。用 MCP 的思路，Git 工具可以变成一个 MCP Server，AI IDE 作为 MCP Client 连接它，动态发现它提供哪些工具。
这时候 AI IDE 不需要提前把所有工具写死。它可以问 MCP Server：你有什么工具？参数怎么填？你能提供哪些资源？然后再把这些能力组织给模型使用。
这里有个关键点：MCP 不等于替代你的业务 API。
业务 API 面向的是确定性业务流程，讲的是性能、版本、事务、权限、稳定性。MCP 面向的是 AI 应用接工具，讲的是工具发现、上下文接入、模型可理解的能力描述。
一个订单查询接口本身还是订单查询接口。你可能在它外面包一层 MCP 工具，让 AI 助手能用它，但不是把原有 API 全部废掉。
Agent 又是什么？
Agent 是另一个层次。
普通聊天机器人主要做一件事：用户问，模型答。它可以有上下文，可以有记忆，但核心还是问答。
Agent 不一样。Agent 往往有一个目标，然后围绕目标做多步动作。比如用户说：“帮我分析一下这个项目为什么测试失败，能修就修一下。”
一个 Agent 可能会这样做：
- 读取错误日志；
- 搜索相关代码；
- 判断失败原因；
- 修改文件；
- 运行测试；
- 如果失败，继续看错误；
- 最后给出修改说明。
这里面每一步都可能调用工具。读文件是工具，搜索代码是工具，运行测试是工具，修改文件也是工具。
所以 Agent 的关键不只是“能调工具”，而是能决定什么时候调哪个工具、调完以后怎么根据结果继续下一步。
Function Calling 给它结构化调用能力。MCP 给它更多标准化工具来源。Agent 框架负责循环、状态、规划、错误处理和权限控制。
这就是三者的位置。
用一个实际场景串起来
假设我们要做一个“代码审查助手”。
第一版很简单：用户贴一段代码，模型给建议。这时候什么都不用，普通聊天就行。
第二版想让它能查项目里的文件。你可以用 Function Calling 定义一个read_file(path)和search_code(keyword)。模型看到问题以后，返回函数调用请求，你的程序执行，再把结果给模型。这个阶段 Function Calling 就够了。
第三版你希望这个审查助手能在不同 IDE、不同仓库工具、不同知识库里复用。你不想每个客户端都重新实现 read_file、search_code、get_diff。于是你把这些能力做成 MCP Server，让 AI 客户端用统一协议接。这个阶段 MCP 开始有价值。
第四版你希望它不只是回答“哪里有问题”，还可以自己读取 diff、判断风险、查调用链、运行测试、必要时生成修复补丁。这时候它就是 Agent。它会使用 Function Calling 或 MCP 暴露出来的工具，但 Agent 本身还需要任务循环、上下文管理、审批机制、失败重试。
这四版不是谁替代谁，而是复杂度逐步上来。
最容易混淆的三个点
第一个误区：Function Calling 是工具协议。
不是。Function Calling 是模型和应用之间的一种结构化输出方式。工具怎么部署、怎么发现、怎么鉴权、怎么复用，不是它主要解决的问题。
第二个误区：MCP 接上以后，模型就会自动变成 Agent。
也不是。MCP Server 只是把工具和资源暴露出来。模型是否会规划任务、是否会循环执行、是否会检查结果，要看客户端和 Agent 框架怎么设计。
第三个误区：Agent 就是多调几次工具。
这也太轻了。真正的 Agent 难点在“不确定性”。它可能选错工具，可能读错上下文，可能参数填错，可能被恶意文本诱导，可能执行了用户没意识到的动作。所以 Agent 系统一定要有边界：哪些工具只读，哪些工具要审批，哪些操作要 dry-run，哪些结果要落日志。
工具调用只是 Agent 的手，权限和状态才是它能不能进生产的底盘。
什么时候用哪个？
如果你只是做一个单应用，工具数量少，调用路径明确，用 Function Calling 就很好。比如客服查订单、助手查天气、BI 助手查几个固定指标。别一上来就搭 MCP，没必要。
如果你有多个 AI 客户端都要接同一批工具，或者工具来自不同团队，希望被复用、被动态发现，那 MCP 更合适。比如公司内部知识库、代码仓库、工单系统、数据库查询工具、浏览器自动化工具。
如果你的目标不是“回答一个问题”，而是“完成一个任务”，并且中间需要多步推理、多次工具调用、状态跟踪，那就进入 Agent 范围。比如代码修复、数据分析报告生成、自动化运维排查、复杂采购比价。
但有一点要记住：越往 Agent 走，越不能只盯模型能力，要盯工程约束。
单次 Function Calling 出错，通常就是一次回答错。Agent 出错，可能是连续执行错。它可以把一个小误判放大成一串动作。所以 Agent 一定要限制工具权限，一定要记录轨迹，一定要让关键动作可审计。
一个比较实用的架构判断
我自己会用三个问题判断该放在哪一层：
第一，这个能力是不是只服务当前应用？
如果是，Function Calling 就行。不要为了显得先进上 MCP。
第二，这个能力是不是会被多个 AI 客户端复用？
如果是，考虑 MCP。尤其是工具本身有资源列表、权限、参数说明、动态发现这些需求。
第三，用户交给系统的是不是一个需要多步完成的目标？
如果是，就别只按接口调用设计，要按 Agent 工作流设计。你要考虑任务状态、工具选择、失败恢复、审批、日志、回滚。
这三个问题比背概念有用。
最后总结一下
Function Calling、MCP、Agent 工具调用看起来都和“让 AI 调工具”有关，但它们关心的问题不一样。
Function Calling 解决模型输出结构化调用意图的问题。它让模型不只是说话，还能告诉程序“我想调用哪个函数，参数是什么”。
MCP 解决 AI 应用和外部工具/资源之间的标准化连接问题。它让工具可以被不同客户端发现、理解和调用。
Agent 解决目标驱动的多步执行问题。它把模型、工具、上下文、状态、权限组合起来，让系统尝试完成任务。
所以别问“有了 MCP 还要不要 Function Calling”，也别问“Agent 是不是 MCP”。更准确的问题是：我现在的问题是在应用内部调一个函数，还是要标准化接一批工具，还是要让系统自己完成一个多步任务？
问题问对了，技术选型就简单很多。