大模型应用开发实战（15）——MCP 真的会取代 Function Calling 吗？很多人从一开始就理解错了

‍♂️ 个人主页小李同学_LSH的主页✍ 作者简介LLM学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注目录一、它们不是替代关系而是分层关系二、Function Calling它解决的不是“会不会用工具”而是“怎么让模型输出可执行参数”一个最简单的抽象Function Calling 最适合什么场景三、MCP它不是“一个函数”而是一层外部世界的标准接口MCP 的核心对象不是单个函数而是外部能力集合一个极简 MCP server 的感觉MCP 和 Function Calling 的真正区别四、Agent它不是“会调工具”而是“会围绕目标做多步决策”一个简化的 Agent 表达五、最容易搞错的一句话有工具 ≠ 有 Agent六、一个更实用的理解三者回答的是三个不同问题Function Calling 回答的是MCP 回答的是Agent 回答的是七、真实项目里什么时候该用谁场景 1你只是想让模型按结构化参数调用一个接口场景 2你要接很多工具和数据源而且希望统一标准场景 3你不只是调一次工具而是要做一整段任务八、一句话终于讲明白这几年做大模型应用开发最容易乱的不是代码而是概念。尤其是这几个词几乎每隔几天就会一起出现Function CallingMCPAgentWorkflowTool Use很多人一开始会把它们理解成同一类东西结果越学越乱明明只是让模型调用一个函数却说自己做了 Agent明明只是接了外部工具却以为这就是 MCP明明只是固定流程又非要包装成“智能体系统”问题就在这里这几个东西根本不在同一层。OpenAI 官方把 Function Calling 定义成一种让模型按你提供的工具定义生成结构化参数、从而连接外部数据和系统的能力MCP 官方把 Model Context Protocol 定义成连接 LLM 应用与外部数据源、工具的开放协议并把服务器能力分成 tools、resources、prompts而 OpenAI 的 Agents 文档和 Anthropic 的工程文章都强调Agent 关注的是围绕目标组织工具、状态和控制流而不是单次工具调用本身。这篇文章就只干一件事把 MCP、Function Calling、Agent 这三个最容易混的概念彻底拆开。一、它们不是替代关系而是分层关系最短的理解方式是Function Calling告诉模型“你可以按这个结构输出要调用的函数和参数”MCP告诉系统“外部工具和数据源怎么用统一协议接进来”Agent告诉模型“你不只是回答还要围绕目标决定下一步做什么”所以它们更像三层能力Function Calling 是工具调用格式层MCP 是外部能力接入层Agent 是任务决策与执行层。Function Calling 更像“怎么调一个函数”MCP 更像“怎么把外部世界标准化接进来”Agent 更像“谁来决定什么时候调、调什么、调几次”。二、Function Calling它解决的不是“会不会用工具”而是“怎么让模型输出可执行参数”Function Calling 其实是这三个概念里最底层、也最容易理解的一个。OpenAI 官方文档写得很清楚Function Calling 让模型能够依据你提供的工具定义返回结构化参数从而连接外部系统或访问训练数据之外的数据。当前 OpenAI 文档里函数工具通常通过JSON Schema来定义输入字段。所以 Function Calling 解决的核心问题不是“模型能不能连接现实世界”而是“如果模型要调用一个函数它该用什么标准格式把参数吐出来”一个最简单的抽象假设你定义了一个函数get_weather(city: str)那 Function Calling 的本质就是让模型从自然语言问题里抽取出结构化参数这里x是用户输入模型输出的不是最终答案而是“该调哪个函数、参数是什么”例如用户说帮我查一下北京天气模型返回{name:get_weather,arguments:{city:北京}}这就是 Function Calling 的精髓。tools [ { type: function, name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } ] user_input 帮我查一下北京天气 # 模型并不是直接执行函数 # 而是返回类似这样的结构化结果 tool_call { name: get_weather, arguments: {city: 北京} } # 你的应用程序再真正执行它 result get_weather(**tool_call[arguments]) print(result)这段代码想表达的重点只有一个模型本身不真的执行函数函数是你的应用层执行的。OpenAI 文档里的 Function Calling 也是围绕“模型生成工具调用参数应用执行工具再把结果交回模型或交给用户”这个范式来写的。Function Calling 最适合什么场景它特别适合单次函数调用结构化参数提取表单式任务工具数量不多、流程较简单的场景一句话概括Function Calling 更像“让模型学会按你的接口说人话”。三、MCP它不是“一个函数”而是一层外部世界的标准接口MCP 比 Function Calling 高一层而且经常被误解。MCP 官方定义非常明确Model Context Protocol 是一种连接 AI 应用与外部系统的开放标准。它让像 Claude、ChatGPT 这类应用能够连接数据源、工具和工作流官方甚至把它类比成 AI 应用的“USB-C 接口”。规范层面MCP server 可以暴露三类能力Tools、Resources、Prompts。这意味着 MCP 解决的问题不是“某个函数怎么调”而是“各种外部工具、数据库、文件、API怎么用统一协议暴露给 AI 应用”MCP 的核心对象不是单个函数而是外部能力集合你可以把 MCP 抽象成这样一层它关心的是外部能力怎么发现能力怎么描述数据怎么暴露协议怎么统一一个极简 MCP server 的感觉下面这段不是完整生产代码只是帮助你理解MCP 更像“把能力暴露出去”而不是“直接写死在模型 prompt 里”。# 伪代码表达 MCP server 暴露工具的感觉 class MCPServer: def list_tools(self): return [ { name: query_orders, description: 查询订单信息 } ] def call_tool(self, name, arguments): if name query_orders: user_id arguments[user_id] return {orders: get_orders_from_db(user_id)}这里的重点不是具体 SDK而是思路AI 客户端先“发现”有哪些能力再按统一协议去调用这些能力这些能力背后可以是数据库、API、文件系统、业务系统MCP 和 Function Calling 的真正区别这是全文最关键的一点之一。Function Calling更像“我已经知道有哪些函数请模型按 JSON 参数格式选一个来调。”MCP更像“我先用统一协议把外部世界接进来让 AI 应用能发现和使用这些能力。”所以你可以把它们的关系理解成Function Calling 管“调用格式”MCP 管“接入协议”。它们不是冲突关系而是完全可以叠在一起。OpenAI 的 Responses API 文档里就明确写了一次响应里模型可以在一个 agentic loop 中调用包括自定义函数和remote MCP servers在内的多种工具。四、Agent它不是“会调工具”而是“会围绕目标做多步决策”现在轮到最容易被滥用的词Agent。OpenAI 的构建 Agents 指南把 Agent 拆成模型、工具、状态/记忆、编排几个基本原语Anthropic 的工程文章则强调真正有效的 agent 系统往往是由简单、可组合的模式搭起来的而不是一堆看起来高级的框架。OpenAI 的 Agents Orchestration 文档也明确区分了 handoffs 和 agents-as-tools说明 Agent 的核心问题是如何组织控制流与职责分配。所以 Agent 的关键不在于“有没有工具”而在于模型是不是在围绕目标动态决定下一步做什么。一个简化的 Agent 表达你可以把 Agent 抽象成一个循环state {goal: 帮我分析这个月退款异常, done: False, history: []} while not state[done]: action planner(state) # 决定下一步做什么 observation run_tool(action) # 调工具 state[history].append((action, observation)) state update_state(state, action, observation)五、最容易搞错的一句话有工具 ≠ 有 Agent这是很多人最容易踩的坑。你有一个函数get_weather(city)模型能把参数提出来并调它。这说明你有Function Calling。你把数据库、文件系统、搜索工具都通过统一协议接了进来。这说明你有MCP。但如果整个流程是用户问一句模型调一个工具工具回结果直接结束这依然不一定是 Agent。它更可能只是一个带工具调用能力的单步系统。只有当模型开始围绕目标做多步决策与状态迭代时才更接近 Agent 的定义。维度Function CallingMCPAgent核心问题模型怎么输出可执行参数外部世界怎么统一接进来模型怎么围绕目标做多步决策关注点调用格式接入协议任务执行逻辑是否一定需要外部系统不一定是通常需要是否天然多步否否是更像什么JSON 参数调用机制工具/数据总线标准任务执行系统六、一个更实用的理解三者回答的是三个不同问题你以后只要记住这三个问题就不会再乱。Function Calling 回答的是“如果模型要调用一个函数它该怎么把参数讲清楚”MCP 回答的是“如果我要接很多外部系统怎么统一接法”Agent 回答的是“面对一个目标谁来决定下一步做什么”这三个问题完全不是一回事。所以真正成熟的系统经常会是这样意思是Agent负责决策和执行逻辑MCP负责把外部能力接进来Function Calling负责模型和具体工具之间的参数交换格式七、真实项目里什么时候该用谁这个问题比定义更重要。场景 1你只是想让模型按结构化参数调用一个接口用Function Calling就够了。比如查天气下单发消息提交表单场景 2你要接很多工具和数据源而且希望统一标准上MCP。比如接数据库接工单系统接监控接文档库接内部服务场景 3你不只是调一次工具而是要做一整段任务考虑Agent。比如查日志 → 定位问题 → 生成修复建议搜文档 → 对比结论 → 生成分析报告读需求 → 改代码 → 跑测试 → 提交 PROpenAI 的编排文档里甚至把多代理编排拆成handoffs和agents as tools两种模式这本身就说明到了 Agent 这一层重点已经变成“怎么组织任务”而不是“怎么定义一个函数”。八、一句话终于讲明白如果你只想记一句最短的总结就记这个Function Calling 是调用格式MCP 是接入标准Agent 是决策与执行系统。再展开一点就是Function Calling让模型能规范地“说出要调哪个函数、传什么参数”MCP让外部工具和数据源能以统一协议接进 AI 应用Agent让模型围绕目标自主决定调用什么、调用几次、下一步怎么走所以它们不是替代关系而是经常叠在一起工作的三层能力。最后再给你一句适合放在文章结尾的版本别再问 MCP 会不会取代 Function Calling 了。一个是接入层一个是调用层真正该问的是你的系统现在缺的是“接入能力”还是“调用能力”还是“决策能力”。