简介：在构建基于大语言模型的应用时，Function Call、Skills 与 MCP 常被混为一谈，但它们分别对应能力调用机制、能力管理抽象与标准化互联协议三个层级。本文从技术架构、功能边界、接入成本、适用场景等维度系统对比三者的相同点与核心差异，帮助开发者理解“模型如何输出参数”“工具如何被统一管理”“系统间如何互通”三个不同问题，并给出可落地的选型建议与迁移注意事项。
基于大语言模型构建应用系统时，开发者面临的早已不只是“如何调用模型”这一个问题，而是逐渐分化为三个相互关联但层次不同的问题：
这三类问题分别催生了 Function Call、Skills 和 MCP 这三种技术形态。它们常常被放在一起讨论，是因为在实际项目中三者可能同时出现、互相依赖，甚至在某类平台中被整合在同一套框架里。但若不能清晰区分它们各自的定位与边界，就容易在架构设计时做出错误判断——例如把 Function Call 当作完整的工具管理方案来用，或者把 MCP 理解为 Function Call 的替代品，又或者把 Skills 简单等同于“工具列表”。
本文的目标是从技术本质出发，系统拆解三者的定义、相同点、核心差异、适用场景以及迁移与使用注意事项，帮助读者建立清晰的决策框架。
Function Call 在本质上并不是模型“真正调用”了某个函数，而是指模型经过训练或提示工程引导后，能够按照预定义的 Schema 生成一段结构化文本——通常为 JSON 格式。这段文本包含了调用某个工具所需的全部参数。后续由外部系统解析这段 JSON，决定是否执行对应的函数，并将执行结果返回给模型。
因此，Function Call 的核心问题是：如何让模型稳定、准确地输出符合预期的参数结构。它解决的是“模型如何表达意图”的问题，而不是“工具如何被执行”的问题。
在实现层面，Function Call 的关键技术包括：
Skills 通常出现在应用层或平台层的 Agent 框架中。它的本质是对工具能力的抽象与管理，将一个个可执行的工具包装成“技能”，并围绕技能提供权限控制、版本管理、参数校验、工作流编排、命名空间隔离等能力。
可以这样理解：Function Call 解决的是“单次调用如何完成”，而 Skills 解决的是“大量能力如何被组织起来”。一个 Skill 内部可能包含多个 Function Call 定义，也可能包含更复杂的调用逻辑，比如多步骤执行、条件分支、依赖关系、回退策略等。
在 Skills 这一层，开发者关注的核心问题从“模型输出什么格式”转移到了：
MCP 是近年来兴起的一种开放协议，目标是解决模型与外部数据源、工具之间的标准化连接问题。它的核心思路是定义一套通用的 Client-Server 架构，Server 端将资源、工具、提示词等能力以标准化的形式暴露出来，Client 端通过统一的协议进行发现、调用和管理。
MCP 解决的问题与前两者有本质不同：Function Call 解决的是模型输出参数的可靠性问题，Skills 解决的是工具在特定平台内的管理问题，而 MCP 解决的是跨系统、跨进程、跨服务的互操作问题。
在没有 MCP 这类协议之前，一个模型应用若要接入多个外部系统，通常需要为每个系统单独编写适配器，处理各自的认证方式、数据格式、错误语义和调用约定。MCP 的价值在于将这些适配成本抽象为一套标准接口，让 Client 与 Server 之间可以相对独立地演进。
尽管三者定位不同，但它们之间存在明显的共同之处：
共同服务于“让模型具备执行能力”这一目标。 无论 Function Call、Skills 还是 MCP，最终都要回到“模型根据用户意图触发某个外部动作”这条主线上。它们各自在不同的层次上为这一目标提供支撑。
都依赖结构化的工具描述。 在三者的实现中，都不可回避地需要定义“一个工具有哪些参数、参数类型是什么、返回值是什么”。这种描述可能以 JSON Schema、接口定义语言或协议规范的形式出现，但核心逻辑是相通的。
都涉及模型与外部环境的交互闭环。 三者的完整流程都包含“模型产生调用意图 → 外部系统执行 → 执行结果返回模型 → 模型继续推理”的循环。差异在于这个循环的哪一段被抽象和标准化了。
这是最根本的差异。Function Call 处于模型侧，是模型输出能力的一部分；Skills 处于平台层或应用层，是对工具能力的封装与管理；MCP 处于协议层，定义的是连接与传输的标准。
用一个形象的比喻：Function Call 相当于“一个人学会了如何填一张标准化的申请单”；Skills 相当于“公司建立了一套内部流程来管理各类申请单的审批、归档与版本”；MCP 则相当于“不同公司之间约定了一套通用的电子数据交换格式，使得申请单可以跨组织流转”。
| 技术概念 | 核心问题 | 关键产出 |
|---|---|---|
| Function Call | 模型如何输出可靠的结构化参数 | 符合 Schema 的 JSON 文本 |
| Skills | 工具能力如何被统一组织与管理 | 可编排、可授权的技能集合 |
| MCP | 不同系统间的模型与工具如何标准化连接 | 统一的 Client-Server 通信规范 |
Function Call 的边界局限于模型推理引擎内部。它不关心外部工具的实际执行环境，只负责“把参数说清楚”。一旦结构化输出完成，Function Call 的职责就结束了。
Skills 的边界跨越了模型与工具执行环境。它需要感知工具的生命周期、当前状态、调用历史以及权限策略。一个 Skill 的完整生命周期可能包含创建、发布、授权、调用、监控、下线等多个环节。
MCP 的边界则进一步扩展到了跨进程甚至跨网络。它关心的是 Client 与 Server 之间的通信协议、消息格式、错误处理、能力发现机制等。MCP 本身不定义模型如何输出参数，也不定义工具如何被编排，而是定义“当模型侧需要与某个外部能力交互时，双方按什么规则通信”。
Function Call 本身是无状态的。每一次调用都是独立的，模型根据当前上下文输出参数，执行权随后交给外部系统。实际工程中的重试、状态保持、多轮对话中的上下文延续，都必须在 Function Call 之外另行设计。
Skills 由于处于平台层，天然带有状态管理的能力。平台可以记录每个 Skill 的调用历史、当前版本、启用状态、权限变更等，从而在多次调用之间提供一定的状态一致性保障。
MCP 则需要在协议层面对连接的建立、保持、断开以及会话状态做出约定。不同的实现可能支持有状态会话，也可能采用无状态的设计，但协议本身必须对这些行为给出明确的语义定义。
Function Call 的错误主要分为两类：一是结构化输出错误——模型生成的 JSON 格式不合法或参数越界；二是外部执行错误——工具本身执行失败。前者可以通过语法约束解码大幅降低，后者则依赖“错误回传模型再决策”的循环来缓解。
Skills 的错误处理更加复杂。一个 Skill 的执行失败可能来自于单个工具调用失败、多工具编排中的中间环节失败、版本兼容性问题或者权限校验失败。这要求平台层提供更丰富的错误分类和回退策略。
MCP 的错误处理则更偏向通信层与协议层。连接中断、消息格式不匹配、Server 不可用、能力发现失败等都属于 MCP 需要面对的问题。MCP 的错误语义通常需要标准化，以便 Client 端能够一致地处理来自不同 Server 的异常。
Function Call 的接入成本相对最低。开发者只需要定义 Schema 并将函数描述注入模型上下文，配合一定的解析和校验逻辑即可运行。其门槛在于对 Schema 设计合理性和推理阶段约束解码的调优。
Skills 的接入成本中等偏上。它要求有一个平台或框架来承载技能的注册、管理和调度。如果所在团队没有现成的平台支持，从零搭建一套 Skills 体系的成本不可忽视。
MCP 的接入成本取决于标准化程度和生态成熟度。如果 Client 和 Server 两端都严格遵循协议实现，则接入新外部系统的边际成本会显著下降；但在协议自身仍在演进、各方实现尚不完全一致的阶段，初期适配成本可能并不低。
| 对比维度 | Function Call | Skills | MCP |
|---|---|---|---|
| 技术层级 | 模型侧能力 | 平台层/应用层抽象 | 标准化连接协议 |
| 核心关注 | 结构化参数输出 | 工具生命周期管理 | 系统间互操作 |
| 状态管理 | 无状态，需外部补充 | 平台内可维护状态 | 协议层定义会话语义 |
| 错误类型 | 格式错误、执行失败 | 编排失败、权限失败、版本冲突 | 连接失败、协议不匹配 |
| 接入成本 | 低 | 中高，依赖平台能力 | 中，取决于实现成熟度 |
| 系统边界 | 模型推理引擎内 | 跨模型与工具执行环境 | 跨进程、跨网络 |
| 适用粒度 | 单次工具调用 | 多工具编排与管理 | 多系统能力互通 |
如果需求仅仅是让模型在特定场景下输出一个可执行的参数结构，例如查询天气、预订机票、调用一个内部 API，且工具数量不多、调用逻辑简单，那么直接使用 Function Call 是最直接的选择。不需要引入额外的平台层或协议层。
当系统中存在几十甚至上百个工具，且不同角色需要不同的调用权限、不同工具之间存在依赖关系时，Skills 的价值就凸显出来。此时需要的是一个能够管理工具全集、控制版本发布、记录调用审计的平台层能力。
当模型应用需要连接多个独立开发、独立部署的外部系统——例如企业内部的数据仓库、第三方数据服务、自建工具服务等——并且不希望为每个系统写一套专属适配器时，MCP 类协议是更合适的方向。它提供了一种统一的连接约定，降低了长期维护多系统集成的复杂度。
在实际生产系统中，三者往往不是互斥的，而是叠加使用。一个典型的组合方式是：用 MCP 连接外部工具 Server，将 MCP 暴露的工具注册到平台的 Skills 体系中加以管理和编排，最终在模型推理时通过 Function Call 生成调用参数。这种分层组合能够将每一层的职责清晰隔离，便于独立演进与替换。
选型时建议先问自己三个问题：
第一，当前最大的不确定性在哪一层？ 如果问题是“模型输出的 JSON 总是格式错误”，那优先优化 Function Call 的 Schema 设计和约束解码；如果问题是“工具太多了，权限和版本混乱”，那需要引入 Skills 层；如果问题是“每接一个新系统都要写一堆胶水代码”，那应该考虑 MCP 类协议。
第二，团队的技术栈和运维能力如何？ Function Call 的落地门槛最低，适合小步快跑；Skills 需要一定的平台建设或平台选型投入；MCP 则需要团队对协议设计、分布式系统通信有基本理解。不要因为某个概念“听起来更先进”就盲目引入。
第三，未来半年到一年的扩展预期是什么？ 如果预期工具数量会快速增长，提前设计 Skills 管理能力是合理的；如果预期需要频繁对接多个外部系统，标准化协议的价值会随系统数量增加而放大。
如果当前系统已经大量使用原生 Function Call，迁移到 Skills 体系时需要注意：
无论选择哪种方案，都建议保持工具描述与执行逻辑的解耦。工具的业务逻辑应当独立于模型侧的 Schema 定义，也独立于平台层的管理策略。这样当模型的输出格式需要调整、或者平台的权限策略需要变更时，不会波及到核心业务代码。
Function Call、Skills 与 MCP 不是同一层面上的竞争概念，而是分别对应“模型如何输出参数”“工具如何被管理”“系统如何互联”三个不同层级的工程问题。Function Call 关注单次调用的结构化输出可靠性，Skills 关注多工具场景下的组织与治理，MCP 关注跨系统连接的标准化。
理解三者的本质区别，可以帮助开发者在架构设计时做出更有针对性的选择：先用 Function Call 解决最基础的调用问题，在工具规模增长后引入 Skills 层进行统一管理，当面临多系统互联需求时再引入 MCP 类协议实现标准化连接。三层各司其职、叠加使用，通常能构成一个清晰、可扩展的大模型应用工具体系。