提到让大模型连接外部工具，总绕不开三个概念：Function Call、Skill 和 MCP。它们层次不同，混淆起来也容易——我见过不少团队在初期把 Skill 当 MCP 用，或者反过来。简单讲，Function Call 是原子级的调用接口，Skill 是给用户打包好的功能模块，MCP 则是希望统一底层连接方式的开放协议。
Function Call：模型突破语言边界的原语
Function Call 其实没有听起来那么玄。本质上，就是你定义几个函数，告诉模型它们的签名（名字、参数、描述），然后模型在需要的时候，返回一个结构化的 JSON 让你去执行。比如你有个 get_weather 函数，当用户问'北京天气怎么样'，模型大概率会回复：{"name": "get_weather", "arguments": {"location": "Beijing"}}。你的应用拿到 JSON 后真去调 API，再把结果塞回给模型，最后用自然语言回答用户。整个过程里，用户根本不知道背后有个函数在忙活。
这个机制2023年由 OpenAI 推火之后，现在几乎成了主流模型的标配。它是原子级别的——无论上层的 Skill 或 Agent 封得多复杂，最后落到执行，还是得靠一次次的 Function Call。对开发者来说，它是最直接、最灵活的方式；对用户则完全无感。
Skill：端到端的功能封装
Skill 更多出现在 Coze、Dify、GPTs 这类 AI 应用平台上。你可以把几次 Function Call、提示词、知识库甚至一个小工作流揉在一起，封装成一个'技能'。用户感知到的就是一个完整能力，比如'全网搜索'技能，说一句'最近有什么科技新闻'，bot 自动去搜、去整理，回复自然语言。
它最大的好处是产品化。一个懂技术的产品经理都能用可视化编排搭出一个 Skill 给团队用，不用再拼积木式地敲 Function Call。缺点也明显：灵活性有限。要是想深度定制流程里的某个环节，最终还得钻到底层去看函数怎么调。
MCP：让工具连接有个标准协议
MCP（Model Context Protocol）是 Anthropic 抛出来的开放协议，想解决每个 AI 应用都要重复造轮子对接各种工具的问题。打个比方：以前的工具对接像每台设备都用自己的专有数据线，MCP 就像 USB-C 标准。你只要按协议实现一个 MCP server，任何支持 MCP 的客户端都能连上直接用。
我试过在 Claude Desktop 里接 filesystem 和 sqlite 两个 MCP server，体验挺顺：聊着天就让 AI 读本地目录里的 schema 文件，顺便跑个 SQL 查表结构。不需要写一堆 Function Call 的配置代码。它的'动态发现'机制尤其实用——server 启动后，客户端能自动识别它提供了哪些工具和资源，不用硬编码。目前 MCP 的生态还在早期，现成的 server 没那么多，但它对安全的本地化连接和资源控制很加分。
一张表看清区别
| 维度 | Function Call | Skill | MCP |
|---|---|---|---|
| 抽象层级 | 模型原生接口，原子操作 | 面向用户的功能模块 | 通信协议，基础设施 |
| 谁在用 | 开发者直接调 API | 终端用户或低代码搭建者 | 工具开发者、AI 应用开发者 |
| 典型场景 | 快速集成简单工具，一次调用 | 构建复杂 Agent，组合多步操作 | 企业级多模型/多工具集成，需要统一标准 |
| 互操作性 | 低，各厂商格式不同 | 中，依赖具体平台 | 高，开放标准，一次实现到处使用 |
