Function Calling、MCP、Agent 工具调用到底有什么区别?

发布时间:2026/7/7 13:17:23
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参数是orderId12345。真正执行函数的是你的程序。你的程序拿到模型给出的函数名和参数自己去查数据库、调内部 API、处理异常再把结果丢回模型让模型组织成用户能看懂的话。所以 Function Calling 的核心不是“AI 拥有了函数”而是模型输出从自然语言变成了结构化调用请求。这件事很重要。以前模型说“我建议你查询订单接口”程序还要从文本里猜它的意思。现在模型直接给一个 JSON程序就好接了。它让 LLM 从聊天机器人往应用组件靠近了一大步。但 Function Calling 也有一个很明显的边界函数是谁定义的一般是应用开发者定义的。函数在哪里执行一般在当前应用代码里执行。工具列表怎么发现通常也是你在代码里写死或者配置进去。如果只是做一个客服助手、数据问答助手、内部审批助手这够用了。你的系统就那几个工具开发团队自己维护也没打算让别的 AI 客户端来复用。问题出在规模变大以后。Function Calling 的麻烦每个应用都要重新接一遍工具假设公司里有 10 个 AI 应用客服、销售、运营、BI、研发助手、工单助手、知识库助手、合同助手、财务助手、人事助手。它们都需要查用户信息、查订单、读知识库、拿文件、调用搜索、查权限。如果只靠 Function Calling每个应用都要自己定义一遍工具 schema自己写一遍鉴权自己处理一遍连接方式。A 应用里叫query_customerB 应用里叫getUserInfoC 应用里参数叫uidD 应用里参数叫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 ServerAI 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”。更准确的问题是我现在的问题是在应用内部调一个函数还是要标准化接一批工具还是要让系统自己完成一个多步任务问题问对了技术选型就简单很多。