简介：很多人容易把Function Calling、MCP和Agent Skill当成三个平行的外部工具调用方案，甚至误以为它们是竞争关系。本文从三层架构视角拆解三者的层级依赖、核心职责与适用边界，帮助开发者理清“模型怎么调函数”“工具怎么暴露给模型”“任务怎么按流程完成”这三个不同层次的问题，并给出选型判断与组合使用建议。
在构建基于大模型的智能体应用时，开发者经常会同时接触到 Function Calling、MCP 和 Agent Skill 这三个概念。它们都涉及“让模型使用外部工具”这一核心目标，因此很容易被放在一起比较，甚至被误认为是不同厂商在不同时期推出的竞争性方案。
这种认知偏差的根源在于：三者确实都出现在“模型调用外部能力”的同一条技术链路上，但它们解决的不是同一个层次的问题。用一个直观的类比来说：
如果只看到“都在调工具”这个表面共性，就会把三层架构压缩成一个平面上的并列选项。而实际上，它们之间存在明确的层级依赖关系：MCP 的标准化工具暴露依赖 Function Calling 作为底层调用协议；Agent Skill 的任务流程封装又依赖 MCP 所暴露的工具集合作为执行基础。
Function Calling 是最先出现的基础能力，它解决的核心问题是：模型只能输出自然语言文本，但实际业务场景中需要触发外部函数、查询数据库、调用 API 来完成真实操作。Function Calling 通过让模型输出结构化的调用意图——通常是包含函数名称和参数的 JSON 结构——使程序能够可靠地解析模型的意图并执行对应函数。
它的关键特征是：模型不执行函数，只表达调用意图。实际执行由外部程序完成，执行结果再反馈给模型进行后续推理。这一层只关心“调用协议”本身，不关心工具是哪个系统提供的，也不关心工具与工具之间如何组合。
MCP（Model Context Protocol，模型上下文协议）位于 Function Calling 之上，解决的是“工具怎么被标准化地暴露给模型”的问题。在 MCP 出现之前，每个工具源都需要单独对接：数据库有数据库的接入方式，文件系统有文件系统的接入方式，第三方 API 有自己的认证和调用格式。这种碎片化导致每接入一个新工具就要写一套新的适配逻辑。
MCP 的价值在于提供了一套标准化的工具描述与调用规范。工具提供方只需要按照 MCP 规范暴露自己的能力描述——包括工具名称、参数模式、返回格式等——模型侧就可以通过统一的协议发现并调用这些工具。它把原先“点对点”的接入方式，变成了“工具服务端一次实现，多处复用”的标准化架构。
Agent Skill 位于最上层，解决的是“有了工具之后，按什么流程完成任务”的问题。一个真实业务任务往往需要多个工具的协同调用，并且带有明确的执行顺序、判断分支、输入输出格式和质量标准。例如一个“客户信息查询与报告生成”任务，可能需要先调用权限校验工具、再调用数据库查询工具、再调用文档生成工具，并且每一步之间都有数据传递和异常处理逻辑。
Agent Skill 把这些“如何用工具完成特定任务”的知识封装成可复用模块。它包含的不仅仅是工具调用的顺序，还包括提示词模板、执行脚本、输出格式规范、异常处理策略等内容。Skill 的核心价值在于：让资深开发者或业务专家把隐性经验沉淀为可被模型直接加载和执行的显性流程。
| 层级 | 概念 | 核心问题 | 依赖关系 |
|---|---|---|---|
| 底层 | Function Calling | 模型怎么调函数 | 无下层依赖，是最基础的调用协议 |
| 中层 | MCP | 工具怎么暴露给模型 | 依赖 Function Calling 作为调用表达方式 |
| 上层 | Agent Skill | 按什么流程完成任务 | 依赖 MCP 暴露的工具集作为执行基础 |
这个层级关系意味着：没有 Function Calling，MCP 无法将标准化工具转化为模型可执行的调用；没有 MCP，Agent Skill 无法稳定地引用一套统一的工具接口来编排复杂流程。 反过来，上层能力的存在并不替代下层，而是对下层能力的组织与复用。
Function Calling 解决的是“表达问题”——模型有了调用外部功能的意图之后，如何让程序稳定地理解这个意图。它的评判标准是调用意图解析的准确率和结构化输出的稳定性。
MCP 解决的是“连接问题”——如何减少工具接入的适配成本，提高工具的可发现性和互操作性。它的评判标准是接入一个新工具需要多少改造量，以及同一个工具能否被不同模型和应用复用。
Agent Skill 解决的是“知识问题”——如何把完成任务的隐性经验转化为可复用的显性流程。它的评判标准是技能模块能否被稳定地重复执行，以及能否降低对操作者专业水平的依赖。
Function Calling 的粒度是最细的——单次函数调用。它的生命周期只覆盖从模型输出调用意图到程序执行并返回结果的短暂过程。
MCP 的粒度是工具级别的。一个 MCP 服务可以暴露多个函数，其生命周期与工具服务的运行周期一致。
Agent Skill 的粒度是任务级别的。一个 Skill 可以编排多个工具、多轮调用、多分支判断，其生命周期与整个任务从启动到完成的过程对应，并且 Skill 本身会随着业务需求变化而持续迭代。
从技术演进的时间线来看，三者的出现顺序反映了智能体应用逐步成熟的过程。
最早阶段，核心矛盾是“模型能不能触发外部调用”。这一阶段的需求是打通从模型输出到程序执行的关键链路，Function Calling 由此产生。它没有解决工具碎片化问题，也没有解决复杂任务编排问题，因为它不需要解决——当时连最基础的单次调用都还没有形成稳定方案。
第二阶段，当单次调用稳定之后，新的瓶颈出现了：每接入一个外部系统都要做大量定制开发。数据源、业务 API、内部服务各有各的格式和认证方式，工具接入成本成为扩展智能体能力的主要障碍。MCP 的出现正是为了解决这个“规模化接入”的问题——通过标准化降低工具暴露的成本。
第三阶段，工具接入成本降低之后，新的瓶颈又转移到了“如何高效地使用这些工具”。工具多了之后，模型面临的是工具选择、调用顺序、参数传递、异常处理、输出质量等一系列组合问题。Agent Skill 的出现正是为了解决这个“知识沉淀与流程复用”的问题。
所以三者的关系是逐层递进、层层依赖的，而不是同一层次上的方案竞争。每一层解决的是上一层无法解决的问题。
在实际的智能体应用架构中，三层通常以如下方式组合工作：
┌─────────────────────────────────────────────┐│ 应用层 / 智能体编排 ││ ┌─────────────────────────────────────┐ ││ │ Agent Skill 层 │ ││ │ 任务流程模板 / 执行标准 / 异常策略 │ ││ └─────────────────────────────────────┘ ││ ↓ 引用工具 ││ ┌─────────────────────────────────────┐ ││ │ MCP 工具层 │ ││ │ 数据库工具 / API工具 / 文件工具 │ ││ │ （统一描述规范，可发现，可复用） │ ││ └─────────────────────────────────────┘ ││ ↓ 表达调用意图 ││ ┌─────────────────────────────────────┐ ││ │ Function Calling 层 │ ││ │ 结构化函数调用意图的生成与解析 │ ││ └─────────────────────────────────────┘ │└─────────────────────────────────────────────┘
以一个“订单数据汇总分析”任务为例，三层的协作方式是：
Function Calling 层：模型输出结构化调用意图，例如表达“调用 query_orders 函数，参数为 start_date=2025-01-01, end_date=2025-01-31”。这一层不关心这个函数来自哪个系统，也不关心调用之后还要做什么。
MCP 工具层：query_orders 函数由订单数据库的 MCP 服务暴露。该服务按照统一规范描述了函数的功能、参数模式、返回格式和调用方式。任何应用只要接入该 MCP 服务，就能以统一方式使用订单数据库的查询能力。
Agent Skill 层：一个名为“月度订单分析”的 Skill 编排了完整流程——先调用 query_orders 获取原始数据，再调用数据清洗工具处理异常值，再调用统计工具计算关键指标，最后按照固定模板生成分析报告。整个流程的知识被封装在 Skill 中，模型加载该 Skill 后即可按既定规范执行任务。
如果业务需求是模型触发少量的、明确的外部操作，且工具数量有限、接入方式可控，那么只使用 Function Calling 就能满足需求。典型场景包括：简单的信息查询、触发单一业务动作、调用内部已有的 API。此时引入 MCP 或 Skill 层反而会增加不必要的架构复杂度。
当工具数量增多、工具来源多样化、或者希望同一套工具被多个智能体应用复用时，引入 MCP 的成本收益比开始显现。典型信号包括：每接入一个新工具都需要写独立的适配代码；多个应用需要调用相同的外部系统；工具提供方与使用方是不同团队，希望解耦双方的开发节奏。
当任务流程复杂、需要多工具协同、且执行过程依赖资深人员的经验知识时，Agent Skill 的价值最突出。典型信号包括：同一个任务需要反复执行，但每次执行质量不稳定；新成员上手该任务需要较长时间培训；任务流程中包含了大量的判断分支和异常处理逻辑。
| 条件 | 最低需要的能力层 | 是否需要上层 |
|---|---|---|
| 工具数量少（个位数），接入方式简单 | Function Calling | 通常不需要 |
| 工具数量多或来源多样，需统一管理 | Function Calling + MCP | 视任务复杂度而定 |
| 任务流程复杂，需要多工具协同和知识沉淀 | Function Calling + MCP + Agent Skill | 建议完整采用三层 |
需要注意的是，三层之间不是“选一个”或“全选”的问题，而是根据实际需求逐层评判。存在只使用 Function Calling 的轻量场景，也存在跳过 MCP 直接用 Function Calling + Skill 的简化方案（在工具数量极少但流程复杂的场景下），但 MCP 的缺失会在工具规模增长后形成技术债。
迁移首先需要梳理现有工具清单，识别哪些工具可以被标准化为 MCP 服务。需要注意的点包括：工具描述的规范化程度是否足够、参数模式的定义是否清晰、错误处理是否统一。迁移过程中应保持 Function Calling 层的调用方式相对稳定，将工具接入方式的变化隔离在 MCP 层内部。
Agent Skill 的设计需要避免两个极端：一是流程过于僵化，无法应对执行过程中的合理变化；二是流程描述过于泛化，模型在加载 Skill 后的执行一致性不足。建议在 Skill 中明确关键步骤的判定标准、数据传递格式和异常退出条件，同时为模型的合理自主决策预留空间。
MCP 工具层涉及外部系统的访问权限，Skill 层涉及任务流程知识的管控。在多层架构中，建议为不同层级分别设计权限策略：MCP 层关注“谁能调用哪些工具”，Skill 层关注“谁能加载和执行哪些任务流程”，Function Calling 层关注“调用意图的解析是否被篡改或误解析”。
三层架构增加了系统调用链路的长度。每一次模型触发外部调用，都需要经过协议解析、工具路由和流程编排等环节。在工具调用频繁或任务流程复杂的场景下，需要关注整体延迟和失败重试策略。建议为跨层调用设置合理的超时和降级机制，避免某层故障导致整条链路不可用。
Function Calling、MCP 和 Agent Skill 的区别不在于“谁取代谁”，而在于它们各自解决不同层次的问题。Function Calling 定义了模型表达调用意图的语言，MCP 把碎片化的工具接入变成标准化的能力暴露，Agent Skill 把完成特定任务的经验知识封装成可复用的流程模块。
理解这三层架构的关键是认识到：上层能力的稳定运行依赖于下层能力的健全，而下层能力的价值在上层能力的组织和复用中得到充分释放。 在实际技术选型时，不需要纠结于“三个选哪个”，而应该评估自身业务在工具规模、流程复杂度和知识沉淀需求上的具体状况，按需引入对应层次的能力，构建层次清晰、可持续演进的智能体应用架构。