不少团队在大模型接入外部系统时，第一反应就是纠结选型：到底该用各家模型自带的函数调用，还是上一套 MCP？这个问题问错了方向。两者根本不在同一层，真正该问的是：意图解析用谁，工具接入用谁。
一个输出格式，一个通信标准
函数调用是模型自带的一项输出能力。用户说"查一下北京天气"，模型吐出一段结构化 JSON：{"name": "get_weather", "arguments": {"city": "北京"}}。至于这段 JSON 之后由谁执行、怎么执行，模型一概不管——那是宿主应用的事。
MCP 则是另一回事。它是 2024 年 11 月由 Anthropic 开源的协议规范，基于 JSON-RPC 2.0，专门解决"模型和工具之间如何说同一种话"的问题。形象一点：函数调用解决模型"说得准"，MCP 解决工具"接得住"。把二者摆在对立面比较，就像比较翻译官和电话交换机。
差异藏在七个细节里
| 维度 | 函数调用 | MCP |
|---|---|---|
| 本质 | 模型输出能力 | 独立开放协议 |
| 工具发现 | 静态列表，每次请求带全量 | 运行时 tools/list 动态发现，支持热插拔 |
| 会话状态 | 无状态，应用层自理 | 有状态，靠 Mcp-Session-Id 维持 |
| 耦合度 | 各家格式不一，换模型常要重写定义 | 模型无关，一套 Server 多家通用 |
| 部署形态 | 函数在应用进程内执行 | Stdio 本地进程或 Streamable HTTP 远程服务 |
| 权限控制 | 应用代码自己实现 | 协议层可做细粒度授权与审计 |
| 生态 | 依赖模型厂商 | 社区 Server 持续增长 |
值得注意的是传输层的演进：早期 MCP 规范用 HTTP+SSE 做远程传输，2025 年 3 月的修订版将其合并为 Streamable HTTP——SSE 端点单独维护的路由、鉴权问题曾让不少人踩坑，升级规范后才干净下来。查老教程时要留意版本。
一段真实部署里的报错
用 Stdio 方式接 MCP Server，最常碰到的两类故障值得提前知道。其一是握手超时：客户端发 initialize 请求后，如果 Server 进程的 stdout 里混进了非协议日志（很多 Python 脚本习惯性 print 调试信息），JSON-RPC 解析直接失败，表现就是"连接后一直卡死无响应"。规范要求 Server 的标准输出只能承载协议帧，调试日志必须走 stderr——这个约束没有任何提示，全靠踩坑换经验。
其二是子进程残留：宿主应用异常退出后，Stdio 模式拉起的 Server 进程可能变成孤儿进程继续占用端口和内存。生产环境建议在启动脚本里加进程组管理，退出时整组回收。
选型不是二选一，而是分层
哪些场景函数调用更划算？工具数量少（五十个以内）、任务链路短、深度绑定单一模型生态的快速原型——此时引入协议层纯属自找复杂度。
哪些场景必须上 MCP？企业内 CRM、ERP、文件系统等异构工具需要被多个 AI 应用共享；或者对权限审计有硬要求，需要在协议层拦截危险调用；或者明确不想被单一模型厂商锁死。
成熟的生产架构通常两者叠加：模型用函数调用做意图解析，产出结构化指令；MCP 客户端接收指令完成协议调度、路由到真正的工具执行，再把结果回传。各干各的强项。
上线前怎么验证
三层检查建议写进发布流程。第一层，参数合规：用 JSON Schema 校验模型产出的调用指令，字段缺失或类型错误直接拒绝执行。第二层，行为回归：用 mock 工具替身跑单测，固定输入断言调用序列，防止模型升级后工具选择漂移。第三层，联调诊断：官方的 MCP Inspector 可以直接列出 Server 能力、模拟调用，排查握手与权限问题比看日志快得多。
还有一个常见的认知误区值得单独点破："上了 MCP 就不需要函数调用了"——错。MCP 负责的是工具侧的标准化接入，模型侧的意图到指令转换依然要靠函数调用完成，把它当替代品来设计的系统，最后都会发现少了关键一环。
评论0