很多人第一次看到 MCP会把它理解成 Function Calling 的升级版。这个说法不准确。MCP 和 Function Calling 不是谁淘汰谁而是解决的问题不在同一层。更通俗一点Function Calling 负责把“模型这一次要调哪个函数、参数是什么”说清楚MCP 负责把外部工具做成标准服务让不同 AI 应用都能发现、连接和复用。实际落地时两者经常一起用MCP 把工具接进来Function Calling 让模型在对话里选择并触发工具。1. Function Calling解决“一次调用怎么表达”Function Calling 的重点是单次调用格式。你把工具说明发给模型模型判断需要工具时返回一个结构化调用请求你的业务代码拿到参数后才真正执行函数。所以Function Calling 不是让模型直接访问数据库、写文件、发消息。模型只负责生成调用意图真正执行动作的是应用侧代码。比如定义一个查询天气的工具模型看到用户问“上海今天热不热”就可以选择调用 get_weather。工具定义一般会用 JSON Schema 描述参数。Function Calling 工具定义{type:function,function:{name:get_weather,description:Get weather by city name.,parameters:{type:object,properties:{city:{type:string}},required:[city],additionalProperties:false},strict:true}}模型返回的一次工具调用{type:function_call,name:get_weather,arguments:{\city\:\Shanghai\}}这就是 Function Calling 的边界它让模型用结构化方式表达动作但工具从哪里来、怎么注册、怎么跨项目复用、怎么统一治理不是它主要解决的问题。2. 只靠 Function Calling工具多了会重复建设如果只有一两个工具Function Calling 很轻巧。但当多个应用都要接同一批工具时问题会变明显每个应用都要写一份 schema每个应用都要写执行逻辑每个应用都要处理权限、异常和日志。比如客服 Agent、运营 Agent、研发 Agent、数据 Agent 都要接 GitHub、Slack、数据库和文件系统。如果只靠 Function Calling很容易变成“每个项目复制一遍工具定义”。3. MCP解决“工具怎么接入、发现和复用”MCP 的思路是不要让每个 AI 应用都重复对接外部系统而是把外部系统封装成 MCP Server。AI 应用作为 Host通过 Client 连接 Server自动发现可用工具和资源。MCP 官方把它定义为连接 AI 应用和外部系统的开放标准。它不是某个具体工具而是一套通信和能力暴露规范。比如在客户端配置一个天气 MCP Server。配置好之后支持 MCP 的客户端就可以启动它、连接它并读取它暴露出来的工具清单。MCP Server 配置示例{mcpServers:{weather:{command:node,args:[./weather-mcp-server.js]}}}向 MCP Server 请求工具列表{jsonrpc:2.0,id:1,method:tools/list,params:{}}调用 MCP Server 暴露的工具{jsonrpc:2.0,id:2,method:tools/call,params:{name:get_weather,arguments:{city:Shanghai}}}注意这个区别MCP 不是替模型执行思考也不是替代 Function Calling。它是把工具接入标准化让工具可以被发现、被连接、被复用。4. 两者怎么配合MCP 接工具Function Calling 触发工具一个实际系统可以这样跑MCP Client 先从 MCP Server 拿到工具清单AI 应用把这些工具整理成模型能理解的工具描述模型通过 Function Calling 选择工具应用侧再把调用转成 MCP 的 tools/call 请求。下面是一个简化版伪代码。它表达的是模型产生 Function Calling 结果之后应用侧再去调用 MCP Client。应用侧把 Function Calling 转成 MCP 工具调用importjsoniftool_call.nameget_weather:argsjson.loads(tool_call.arguments)resultmcp_client.call_tool(nameget_weather,arguments{city:args[city]})messages.append({role:tool,tool_call_id:tool_call.id,content:json.dumps(result,ensure_asciiFalse)})5. 什么时候只用 Function Calling什么时候上 MCP选择时不要看名字新不新而要看工具规模和复用需求。工具少、应用单一用 Function Calling 更直接工具多、多个应用都要用就适合 MCP。6. 实际落地可以这样做比较稳妥的做法是先轻后重少量工具先用 Function Calling 跑通业务闭环当某些工具被多个项目重复使用时再抽成 MCP Server。•第一阶段业务里只有少量工具先用 Function Calling 定义 schema快速上线。•第二阶段工具被多个 Agent 复用把它们封装成 MCP Server。•第三阶段统一做工具权限、参数校验、审计日志、限流和异常处理。•第四阶段把常用工具沉淀成内部工具市场让不同 AI 应用按需连接。7. 生产环境必须管住工具风险无论是 Function Calling 还是 MCP只要工具能读数据库、写文件、发消息、创建工单就不能只关注“能不能调通”。工具调用本质上是系统执行能力必须有边界。至少要做五件事工具白名单、参数校验、用户确认、权限隔离、审计日志。尤其是有副作用的动作比如删除文件、发邮件、创建工单、转账支付一定不能让模型绕过确认流程。8. 一句话讲清楚MCP 和 Function Calling 不是替代关系。Function Calling 解决的是一次工具调用的结构化表达MCP 解决的是工具接入、发现、复用和治理。小项目、少量工具用 Function Calling 就够多项目、多工具、多客户端复用就应该考虑 MCP。真正落地时MCP 往往在工具管理层Function Calling 在模型调用层MCP 负责把工具接进来Function Calling 负责让模型触发这一次调用。