当前位置：首页 > news >正文

Function Calling 和 MCP：到底什么场景选哪个？

news 2026/7/3 23:22:44

开场：这不是二选一，而是看场景

很多人第一次接触 MCP 时，会把它和 Function Calling 放在一起比较：既然两者都能让大模型调用工具，那是不是用了 MCP 就不用 Function Calling 了？这个理解不够准确。

Function Calling 解决的是“模型如何把调用意图变成结构化参数”。比如用户说“查一下上海天气”，模型输出 get_weather(location=“Shanghai”)，然后由业务代码真正去查天气接口。

MCP 解决的是“工具如何被标准化接入、发现和复用”。它把工具封装成独立 Server，支持 MCP 的客户端可以连接这些 Server，发现工具、读取资源、调用能力。

1. 两者的区别

Function Calling 更像“在当前项目里写几个工具函数，让模型按格式来调用”。它简单、直接、可控，适合快速原型和单应用场景。

MCP 更像“把工具做成标准服务，让多个 AI 客户端都能接”。它多了一层协议和服务管理，但换来的是复用、发现、隔离和长期维护能力。

如果只看表面，二者都在“调用工具”；如果从工程落地看，Function Calling 偏应用内能力，MCP 偏工具生态和协议层能力。

2. 什么时候用 Function Calling 就够了？

Function Calling 更适合轻量、临时、单应用、强控制的场景

第一类是快速原型。你只是想验证一个想法，比如给客服机器人接一个“查询订单状态”的工具，直接在应用里定义工具 schema 和执行函数就行，不需要额外启动 MCP Server。

第二类是单应用专属工具。有些接口只服务当前系统，比如公司内部某张私有表的查询接口，不会给别的 AI 应用复用。此时把工具逻辑放在当前应用里反而更清晰。

第三类是执行逻辑要强控制。比如退款、转账、下单、发通知，这些动作必须做权限校验、参数二次确认、风控判断、日志审计。Function Calling 的优势是所有执行逻辑都在业务代码里，改起来直接。

第四类是部署环境有限制。有些环境不能方便地启动子进程，或者不能长期运行独立服务，这时引入 MCP Server 反而增加部署麻烦。

Function Calling 的重点是让模型输出工具名和结构化参数

一个常见的 Function Calling 工具定义，大概长这样：

tools = [ { "type": "function", "name": "query_order", "description": "根据订单号查询订单状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"], "additionalProperties": False }, "strict": True } ]

这段代码里，模型只知道有一个 query_order 工具，以及参数 order_id 怎么填。真正查数据库、鉴权、记录日志、处理异常，都是你的业务代码完成。

3. 什么时候更应该用 MCP？

MCP 更适合复用、规模化、Agent 工具生态

如果一个工具不是只给当前项目使用，而是要被多个项目、多个团队、多个 AI 客户端复用，那就应该优先考虑 MCP。

举个例子，同一套 GitHub 工具，Claude Desktop 要用，Cursor 要用，内部代码审查 Agent 也要用。如果每个项目都手写 Function Calling，就会出现多份 schema、多份鉴权、多份错误处理。接口一变，所有地方都要改。

MCP 的做法是把 GitHub 工具封装成独立 Server。客户端只要在配置里接入它，就能发现工具和调用工具。工具维护在 Server 一侧完成，多个客户端共享同一套能力。

另外，如果社区已经有成熟的 MCP Server，也没必要再手写一遍接口。例如文件系统、GitHub、数据库、浏览器自动化这类高频工具，直接复用已有 Server 往往更省时间。

图 5：MCP 把工具做成独立服务，AI 客户端按需连接

一个 MCP 客户端配置示例，大概长这样：

{"mcpServers":{"github":{"command":"npx","args":["-y","@modelcontextprotocol/server-github"],"env":{"GITHUB_PERSONAL_ACCESS_TOKEN":"${GITHUB_TOKEN}"}}}}

这段配置的意思是：当前 AI 客户端不需要自己写 GitHub API 调用代码，而是启动或连接一个 GitHub MCP Server，让它负责暴露标准工具。

4. 工具一多，差距会越来越明显

Function Calling 容易出现多处重复接入，MCP 更适合统一复用

工具少的时候，Function Calling 很舒服。一个应用、两个函数、几段 schema，逻辑都在眼前，问题也好查。

但当工具数量上来后，维护成本会快速上升。你会遇到这些问题：schema 散落在多个项目里，鉴权逻辑重复写，调用日志格式不统一，工具接口变更后要同步改很多地方。

MCP 的价值不是让代码更“炫”，而是把工具从应用代码里拆出去：工具自己维护，客户端只负责连接。这样新增工具、下线工具、升级工具，都不会强行牵动主应用。

5. 一个实用判断流程

实际项目里，可以按下面顺序判断。

先看有没有现成 MCP Server。有的话，优先用，不要重复造轮子。没有的话，再看工具是否要跨项目或跨团队复用。需要复用，就封成 MCP Server。

如果工具只给当前应用用，再看是否需要强业务控制。比如付款、删除、发邮件这种敏感动作，Function Calling 写在业务代码里会更直接。

最后再看部署环境。如果你的环境不能起独立进程，或者远程服务访问受限，就不要硬上 MCP；稳定落地比架构好看更重要。

可以把判断逻辑写成一个简单的伪代码：

defchoose_tool(context):ifcontext.ready_mcp_server:return"MCP"ifcontext.reuse_across_projectsorcontext.agent_system:return"MCP"ifcontext.need_fine_controlorcontext.deploy_limited:return"Function Calling"return"看维护成本，选更简单稳定的方案"