MCP服务器 vs Function Calling：选择你的武器

很有诱惑力。真的。

现在每个LLM供应商都有function calling。OpenAI有。Anthropic有。Google有。你选个最喜欢的，读二十分钟文档，用JSON Schema定义你的函数，然后上线。能用。你的演示看起来很棒。投资人印象深刻。

问题在于，"能用"和"在多个供应商间大规模运行"是两个完全不同的说法。前者是一个周二下午的工作。后者是一份全职工作。

当你把function calling硬编码到一个供应商上时，你选的不只是一个vendor。你选择了他们的schema格式、参数惯例、错误处理语义和发布节奏。你在写按定义就不可移植的胶水代码。而且你是在可移植性最重要的那一层做这件事——你的应用和它依赖的智能之间的边界。

大多数人直到需要支持第二个LLM时才意识到这一点。到那时，胶水代码已经扩散了。

做个练习。去你的代码库里数一下，有多少行代码纯粹是为了在你的内部工具定义和某个特定LLM供应商的function calling格式之间做转换。

一个集成？也许一百行。可以管理。两个集成？你开始注意到OpenAI和Anthropic对可选参数的表达方式有微妙的分歧。三个？你在维护一个兼容性矩阵。五个？你不小心建了一个框架。

而且框架永远不会停止增长。每个供应商每季度都会改API。有时候加功能。有时候废弃东西。有时候他们"改进"schema格式，结果在周六凌晨两点把你的生产环境搞崩。

多供应商function calling的维护税不是线性的。是组合式的。每增加一个供应商就让攻击面倍增。每次API变更都会级联到每个集成。你"简单"的function calling层变成了技术栈中最脆弱的部分——那个所有人都不敢碰的文件。

没人把这个成本写进架构文档。没人在sprint计划中估算它。它只是默默积累，直到有一天你发现一半的工程时间花在了维持集成运转上，而不是构建功能。

MCP不是一个产品。不是某个创业公司的API。它是一个协议。这个区别比人们想象的重要得多。

写MCP服务器时，你只描述一次工具。一套schema。一组描述。一种错误格式。完了。每个会说MCP的LLM都能发现并使用你的工具，无需你写一行供应商特定的代码。

没有适配器。没有版本矩阵。没有"if openai then 格式A, elif anthropic then 格式B"的分支。协议就是契约，任何实现了协议的客户端都能免费获得你的工具。

这和让HTTP成功的模式一样。没人为Chrome、Firefox和Safari写不同的API。你实现协议，每个遵循协议的客户端都能工作。MCP对AI工具集成做了HTTP对Web内容分发做的事——让传输层变得无聊，这样你就能专注于应用层。

实际结果是，你的工具定义变成了资产而不是负债。写一次，测一次，文档写一次。新的LLM供应商出现时，你不需要重写任何东西。只要指向你的MCP服务器就行。

如果我不承认这一点就太不诚实了：有时候function calling确实是正确的选择。

如果你在构建一个只会用一个LLM的应用，你知道是哪个，而且你没有在这件事上自欺欺人——直接function calling更简单。更少的抽象。更少的活动部件。你用可移植性换取直接性，有时候这个交换是值得的。

如果你需要MCP还没有对应的供应商特定功能——比如结构化输出模式、计算机使用API或者供应商特定的流式行为——直接集成是合理的。协议没暴露的东西你访问不了。

如果你在做原型，在"先让它跑起来"的阶段，function calling让你更快到达目的地。MCP有初始搭建成本。对于一个周末黑客马拉松，这个成本是实在的。

但有个问题你必须诚实回答："永远只用一个供应商"真的描述了你的未来吗？因为根据我的经验，说"我们只会用OpenAI"的公司，就是六个月后用户开始要求时疯狂添加Claude支持的那些公司。说"我们只是在做原型"的公司，就是两年后还在生产环境跑那个原型的那些公司。

从function calling切换到MCP的成本每天都在涨。从MCP开始的成本大致保持不变。

我认为大多数人忽略了这一点：MCP和function calling不是敌人。它们是同一个技术栈中的不同层。

MCP工具可以作为函数暴露给任何支持function calling的LLM。协议是真相之源——你的工具做什么、接受什么、返回什么的权威描述。Function calling适配器是生成的，不是手写的。你的MCP服务器是唯一的源头；供应商特定的格式是投影。

这意味着你不需要选择。你可以用MCP作为工具定义层，同时继续用function calling作为向每个LLM交付的机制。区别在于，有了MCP，那些函数定义是从单一源头派生的，而不是按供应商独立维护的。

不管行业是否意识到，这就是它前进的方向。"一个权威描述，多个派生格式"这个模式在其他所有领域都赢了——数据库schema、API规范、类型系统。AI工具集成会收敛到相同的模式，因为替代方案是一个比任何工程团队增长都快的维护负担。

现在想明白这一点的公司会把时间花在构建更好的工具上。后来才想明白的公司会把时间花在重写胶水代码上。两组人最终都会到达同一个地方。唯一的问题是他们在路上浪费多少时间。