MCP、function calling 这两者有什么区
来来，这个问题我可太有共鸣了！你肯定也踩过类似的坑。
前两天一个读者在后台问我：“Function Calling、MCP、Agent 这三样东西到底是什么关系？我快被搞疯了。” 我当时一拍桌子——问得太好了！因为网上翻来覆去都在讲概念，但没一个人告诉你：它们仨不是同辈的，它们是不同时代冒出来的三样东西，一层叠一层，少了谁你都玩不转。
说到这儿，我先讲个我自己的血泪史，你听完就明白了。
我的踩坑史：先有的 FC，然后才有其他
2023 年，我接了个客服 Agent 项目。当时 OpenAI 刚把 Function Calling 放出来，我兴奋得差点跳起来！以前想让模型输出 JSON 都得靠硬写 prompt 碰运气，这下终于有标准格式了，爽啊！
但我很快就笑不出来了😅。
这个项目要对接 5 个工具：查订单、查物流、查退款、查商品库、查用户信息。每个工具我都得手动写调用代码、Schema、错误处理、参数校验，再一个个注册进模型调用链。
你以为这就完了？第二周，甲方突然说：“供应商换了，API 地址全部更新。” 我咬着牙一个一个改。第三周：“再加 3 个工具。” 我当时就想摔键盘了！
那时候 Function Calling 唯一的价值，就是解决了“模型只会吐文本，怎么让它吐动作”的问题。 但工具一多你就发现，它只给了你一个 JSON 格式的空壳子，至于工具怎么注册、怎么发现、怎么调用，没人管你，全得自己撸。
这就像快递公司只告诉你包裹上要写地址，但怎么打包、怎么发货、怎么中转，它说：“关我啥事，你自己搞定。”
MCP：把工具从代码变成服务
到了 2024 年底，Anthropic 发布 MCP 协议的时候，我第一反应是：“又来一个协议？烦不烦？”
但看完文档，我直接真香了——它解决的就是我 2023 年那个痛点！MCP 做的事情其实特朴素：把工具从“代码片段”变成了“独立服务”。
来，说人话。
传统用 Function Calling，你写一个工具的逻辑是：写一个 Python 函数 → 注册进模型调用链。每个工具都死死绑在你的应用代码里，换个应用就重写一遍。反复造轮子，纯属自虐。
MCP 呢？写一个独立的 MCP Server，跑在单独的进程或网络上。你的应用通过 MCP Client 连上去，自动发现这个 Server 有哪些工具，然后自动把工具描述转成模型能理解的 Function Calling 格式，喂给模型。
说白了，MCP 就是 Function Calling 的上层封装，目的是让每个工具只实现一次，到处都能用。
我给你举个真事。Cursor 在 0.46.x 版本后支持了 MCP。我配了一个 JSON 文件，连上文件系统的 MCP Server，然后 Cursor 就能直接操作本地文件了——一行代码没写！放到以前，你得自己写一套文件读写的 Function Calling 调用链，累不累啊？
而且你猜怎么着？现在 Smithery 上已经有 2000 多个 MCP 服务了！这个生态生长速度，炸裂得快。
那 Function Calling 就废了？当然不！
这是很多人会搞混的地方。MCP 和 Function Calling 根本就不是竞争关系，它们是两层东西！
你去看 MCP 的架构图就懂了：MCP Client 从 MCP Server 拿到工具列表，转成 Function Calling 格式，再喂给 LLM。看到了吧？MCP 的底座还是 Function Calling，它只是在外面包了一层标准化服务。
拿 USB-C 来类比：Function Calling 相当于设备内部的电路连接方式，MCP 相当于 USB-C 接口标准。没有内部电路，接口就是摆设；没有接口，内部电路只能给一个设备用。
所以 OpenAI 一开始扭扭捏捏不想支持 MCP，直到 2025 年 3 月底才宣布入局。奥特曼发了个推，我心里想：早该如此了！这事儿你不能拧着来。
Skill：比工具更高一层的存在
好，现在有 FC 能调工具，有 MCP 让工具标准化。那 Agent 是不是就做成了？
对不起，还差一步！
我 2024 年做另一个项目时又翻车了：给了 Agent 十个工具，它知道怎么调，但面对“帮我写一份季度报告”这种任务，它直接懵了——因为它不知道该先查数据、再分析异常、再写文案、最后调整格式。它手里有锤子有扳手，但不知道按什么顺序拧螺丝。
这就是 Skill 要解决的问题！
我用 Claude 的 Skill 机制时发现，它的核心就是一个 Markdown 文件，里面写明任务分几步、每步用什么工具、输出结果什么样、遇到异常怎么处理。
举个例子，一个“代码审查”的 Skill 长这样：
1. 从 GitHub 拉取 PR 的变更内容
2. 逐行检查：规范、安全、性能
3. 有问题就在对应行留评论
4. 最后生成总结报告
这套流程你当然可以用代码写在 MCP 的工具函数里，但用 Skill 的话，你写的是自然语言，LLM 自己理解流程，自己决定每一步怎么走。它保留了灵活性，但代价是——模型可能犯错。
这就回到核心了：Skill 的本质是 sub-agent 的包装，它把决策权完全下放给了模型和 Prompt，能处理以前用代码搞不定的不确定性场景，但代价是不可能 100% 准确。
三者的层级关系，一张表就能看懂
我画过一张表，今天直接甩出来：
| 维度 | Function Calling | MCP | Skill |
|------|-----------------|-----|-------|
| 谁和谁通信 | 模型和函数之间 | AI 客户端和工具服务之间 | Agent 和知识模块之间 |
| 解决什么问题 | 让模型触发外部调用 | 工具接入标准化 | 任务流程复用 |
| 发生在哪里 | 单个 Agent 内部 | 跨应用之间 | Agent 启动时自动发现 |
| 粒度 | 单次调用 | 单个工具 | 多个步骤 + 多个工具 |
看出门道了吗？从 FC 到 MCP 到 Skill，是一层包一层的架构关系。
FC 是：“我来帮你调一个函数”；
MCP 是：“好，我帮你包装了一下，你别管函数在哪了”；
Skill 是：“再往上，我告诉你这些函数按什么顺序调”。
Agent 和这三者的关系
最后说说 Agent。
很多人对 Agent 误解太深，觉得非得用 MCP 或 Skill 才能叫 Agent。非也！Agent 可以简单到就是一个 Model 配几个 Function Calling，也可以复杂到配 MCP Server 外加 Skill。
我自己的判断：Agent = LLM + 工具调用能力 + 流程控制能力。工具调用能力由 Function Calling 提供，标准化接驳由 MCP 提供，流程复用由 Skill 提供。三件套凑齐了，Agent 就有了“观察 → 决策 → 行动 → 观察 → 决策 → 行动”的闭环。
回到开头那个读者的困惑，我最后给了这么一个比方，他瞬间懂了：
Function Calling 是 CPU 指令，MCP 是总线和接口标准，Skill 是操作系统里的脚本。 你写程序可以只用 CPU 指令，但换个主板就得重写；用了 USB 标准，插拔设备变得简单；加上脚本，你才能自动化跑复杂流程。三者的关系不是替代，是叠层。
我的判断
现在大家都在吹 MCP，但我跟你说句掏心窝的话：长远来看，Skill 这个概念的颠覆性比 MCP 大多了。
为什么？因为 MCP 本质上只是解决了“重复对接”的问题，属于效率优化。但 Skill 解决的是“AI 能不能按流程干活”的问题，这直接决定了 Agent 的上限。
而且 Skill 的逻辑特别反传统编程思维——用自然语言写流程，交给模型自己去理解和执行。老派工程师会觉得：“这玩意儿太虚了，我直接用代码写回调更确定啊！” 但问题是，代码写不了不确定性场景。你试过用代码写“根据上下文判断要不要加一个异常处理步骤”吗？写着写着条件分支就爆炸了。
当然，Skill 的短板也很明显：模型行为不可控。你没法保证同一个 Skill 每次执行的流程一模一样。
所以我说，未来大概率会出现混合模式：流水线上确定的部分用传统代码，需要灵活应变的部分用 Skill。谁也不可能完全替代谁。
对了，最后送你一句话：不管你现在做不做 Agent，MCP 值得先了解起来。因为五年后回过头看，MCP 会像今天的 HTTP 协议一样，变成基础设施。你天天在用，但没人会开会讨论“要不要支持它”。它已经沉到水下，变成水电煤了。
今天就聊到这儿吧。如果你有什么不同的看法，评论区见——咱们好好掰头一下！😄
读者评论 4