从一道面试题说起「Function Calling、Skill、MCP 这三个概念有什么区别」这几乎是这两年 AI 应用面试里最容易被踩雷的一道题。最常见的回答是Function Calling 是 OpenAI 的方案MCP 和 Skill 是 Anthropic 的方案它们是不同时期搞出来的竞争方案。这个答案错在哪错在把三个不同层次的东西硬放到了同一个平面上比较。它们不是并列的三个选项而是一套从底到顶的三层架构Function Calling 是「语言」MCP 是「工具箱」Skill 是「操作手册」。三句话的主语不同、说话对象不同、颗粒度也不同这就是三者的本质差异。Function Calling最底层的「调用语言」Function Calling 解决的是最原始的问题模型只会生成文本怎么让它触发真实世界的动作答案是让模型输出一段结构化的 JSON——tool_calls告诉宿主程序「我要调哪个函数、传什么参数」程序执行完再把结果以 tool 消息喂回给模型。它的颗粒度是「单次、无状态、原子化」的查一条数据、算一个值、调一次接口。它不管工具从哪来也不管这一步之后还要干什么只负责「模型和函数之间这一次通信」这件事。也正因为它如此底层所有上层能力都建立在它之上——没有这套语言模型就没办法告诉外界「我要调什么」后面的一切都无从谈起。MCP标准化的「工具箱」Function Calling 普及之后新的痛点出现了每个应用都要自己写代码去对接各种工具数据库一套、文件系统一套、第三方 API 又一套重复劳动堆积成山。MCPModel Context Protocol模型上下文协议就是在这样的背景下出现的它解决的是「工具怎么标准化地暴露给模型」。一个形象的类比是Function Calling 是那根「数据线」MCP 是那个「USB-C 接口」。数据线你要为每台设备单独配一根而 USB-C 接口一次实现、处处可插。MCP 把原本「M 个应用 × N 个工具」的定制集成压缩成了「M N」工具服务写一次任何讲同一套协议的 AI 应用都能直接连接。这层标准的威力已经超出了单个框架的范畴。MCP 由 Anthropic 于 2024 年底开源后迅速成为事实标准现已由 Linux 基金会治理几乎所有主流科技公司都在为它背书。到 2026 年 3 月MCP 的 SDK 月下载量已达 9700 万次而发布初期只有约 200 万作为参照Kubernetes 花了接近四年才达到同等的普及度。不过要强调的是MCP 本质上仍是对 Function Calling 的封装与管理Server 暴露的工具定义最终还是要转换成 Function Calling 的格式喂给模型由模型来触发调用。Skill可复用的「操作手册」工具有了、接入也标准化了第三个问题随之而来Agent 手里攥着一堆工具面对一个复杂任务它不知道该按什么流程、什么标准去用。Skill 就是为了解决「知识与流程复用」而诞生的。Skill 发生在 Agent 与「知识模块」之间。Agent 启动时扫描可用的 Skill 列表当用户提出任务Agent 自己判断哪个 Skill 相关主动加载其中的执行指令、脚本和模板。「代码审查」是一个 Skill「数据分析报告」是一个 Skill每个 Skill 内部可能涉及多个步骤、调用多个 MCP 工具。它的颗粒度比 MCP 工具粗得多封装的是「完成一件完整业务」的能力而不仅仅是「执行一次动作」。完整的层级链条把三者的依赖关系理顺就是一个从上到下的清晰链条Skill定义流程→ MCP提供工具→ Function Calling模型触发调用。每一层都建立在下一层的基础之上。用一个做菜的类比最好理解Function Calling 是你的「手」能拿刀、点火、翻锅MCP 是「厨房」刀在抽屉里、调料在架子上你走进去就知道有什么可用Skill 是「菜谱」告诉你先热锅凉油、再爆香、再翻炒、最后调味。没有手你拿不了刀没有厨房你找不到食材没有菜谱你不知道按什么顺序做。放在同一个场景里感受各层分工用户对 Agent 说「帮我分析最近三个月的销售数据找出下滑的产品线给改进建议」。Skill 层先起作用——Agent 扫描到「数据分析报告」这个 Skill 并加载它的流程定义执行到「取数据」时MCP 层登场——Client 已经连着数据库和 Python 执行器两个 Server自动知道有哪些工具可用最底层模型输出tool_calls的 JSON 去触发具体调用。三层分工明确缺哪层都不完整。2026 年这套架构正在被加速验证这组概念之所以值得今天拿出来认真讲是因为它正在从「概念辨析」变成「工程底座」。行业里有种说法2024 年是 AI demo 之年2025 年是本地编码 Agent 之年而 2026 年将是通用 Agent 真正开始执行任务的一年其背后的连接层正是这套工具调用架构。MCP 的路线图也在往更上游延伸。近期的协议演进方向之一是 Agent-to-Agent 通信——不再只是「Agent 调工具」而是「Agent 调 Agent」让多个 Agent 之间也能通过标准化协议协作。与此同时Skill 层的价值在软件工程领域被重新放大第一波 AI 编码聚焦于个人效率写得更快、解释得更快第二波则转向运营效率——可重复的发布流程、结构化的代码审查、多 Agent 并行工作流这些恰恰是 Skill 所封装的东西。落到实践该怎么选既然三者是层级关系而非替代关系真正的问题就不是「选哪个」而是「在每一层做什么样的工程决策」底层的 Function Calling 几乎不需要你「选」它是模型自带的调用能力你只需要把函数签名和参数描述写清楚让模型能准确地「说出」它想调什么。中间层的 MCP 适合做「跨应用、跨模型复用」的工具建设。如果你的工具只给一个 Agent 用、场景固定直接写代码对接也完全够用但一旦需要多个 Agent 共享同一批工具、或者希望换掉底层实现而不重写接入MCP 的价值就出来了。最上层的 Skill 适合沉淀「可重复的完整工作流」。当你发现某个任务反复在做、步骤和标准已经稳定就值得把它封装成 Skill让 Agent 下次按手册执行而不是每次重新摸索。一句话收尾Function Calling 让模型「会动手」MCP 让工具「可复用」Skill 让任务「有章法」。理解了这三层各自解决什么问题这道面试题——以及更重要的AI 应用的实际架构设计——就都清晰了。
