简介：在构建大语言模型应用时，Function Call、Skills 和 MCP 经常被混为一谈，但它们分别对应能力调用机制、能力管理抽象和标准化互联协议三个不同层级。本文从架构定位、核心职责、数据流向、接入成本、适用场景等维度系统拆解三者的本质区别，帮助开发者理解“模型如何输出参数”“工具如何被统一管理”“系统间如何互通”这三个不同问题，并给出不同业务阶段下的选型建议与迁移注意事项。
在基于大语言模型构建应用系统的过程中，开发者几乎不可避免地会接触到三种技术形态：让模型调用外部函数的 Function Call，在应用层或平台层对工具进行封装管理的 Skills，以及用于标准化连接的 MCP（Model Context Protocol，模型上下文协议）。
它们之所以容易被混为一谈，是因为三者都围绕同一个核心目标服务：让大语言模型突破纯文本生成的限制，能够触达外部世界、执行真实任务。无论是查询数据库、调用 API、操作文件系统，还是触发一段业务代码，最终都表现为“模型说了什么，系统做了什么”。
但在实际工程实践中，三者所处的软件层级完全不同。Function Call 解决的是模型输出侧的问题，即模型如何以结构化方式表达“我想调用什么、传什么参数”；Skills 解决的是应用或平台内部的问题，即一组工具如何被组织、授权、版本化和编排；MCP 解决的是系统互联的问题，即模型宿主与外部资源之间如何通过统一协议建立连接。
如果不加区分地使用这些术语，会导致架构设计上的模糊——特别是在团队协作、技术选型和系统集成时，容易把“模型能力”“平台功能”和“通信协议”混为一谈，从而做出错误的抽象层次划分。
Function Call 是大语言模型的一种原生能力。它的工作方式是：开发者在请求模型时，预先声明一组可用的函数及其参数 schema（通常采用 JSON Schema 描述），模型在处理用户输入时，可以决定是否调用某个函数，并输出一个符合该 schema 的结构化数据片段，而不是输出纯自然语言。
这个结构化输出的核心意义在于：它让模型的“意图”变成机器可解析的“指令”。后续由开发者编写的执行层代码接收这个结构化数据，完成实际的函数调用，再将结果返回给模型进行下一轮推理。
需要强调的是，Function Call 本身并不执行任何函数。它只负责输出“调用意图”和“参数值”。真正执行函数的是应用程序自身。因此，Function Call 的本质是模型输出格式的约束与约定，它解决的是“模型如何表达参数”的问题。
Skills 通常出现在应用开发平台或早期 Agent 框架中，它并不是模型本身的特性，而是平台对一组可复用能力的封装单元。一个 Skill 可能包含以下要素：工具定义、调用逻辑、权限声明、版本信息、输入输出约定、使用文档，甚至是与该工具配套的提示词片段。
Skills 的核心价值在于将零散的工具调用逻辑组织成可管理、可复用、可授权的单元。在多人协作或复杂业务场景下，Skills 让开发者不必每次都从底层函数开始搭建，而是直接选用一个已经封装好的能力单元，将其嵌入到工作流或 Agent 中。
从抽象层级看，Skills 位于 Function Call 之上。一个 Skill 内部可能使用了 Function Call 来触发实际执行，但 Skill 本身还附加了权限控制、版本管理和编排语义。Skills 解决的是“工具如何被统一管理”的问题。
MCP 是近年来由行业推动的一项开放协议，目标是解决模型宿主（如 IDE、Agent 应用、推理服务）与外部数据源、工具服务之间的连接标准化问题。它采用 Client-Server 架构，定义了一套统一的通信方式来传输三类核心对象：资源（Resources）、工具（Tools）和提示词（Prompts）。
在 MCP 架构中，模型宿主作为 Client，外部能力提供方作为 Server。Client 通过 MCP 协议发现 Server 上暴露了哪些资源和工具，并在需要时发起调用。Server 则负责实际与底层系统交互，将结果返回给 Client。
MCP 的关键价值在于减少重复集成工作。在没有统一协议的情况下，每接入一个新的外部系统，开发者都需要为其编写专门的适配代码。而 MCP 提供了一套通用约定，使得“模型宿主如何发现能力”“如何描述能力”“如何调用能力”“如何传递结果”都有了标准化答案。MCP 解决的是“不同系统间如何互通”的问题。
尽管 Function Call、Skills 和 MCP 处于不同层级，但它们之间并非孤立存在，而是共享一些基础逻辑。
第一，三者都服务于同一个目标：扩展模型的能力边界。 大语言模型本身只能生成文本，三者的出现都是为了将模型接入真实世界，使其能够查询数据、操作资源、执行业务逻辑。
第二，三者都涉及“能力描述”这一核心要素。 Function Call 需要开发者声明函数名、参数类型和描述；Skills 需要在平台上定义工具能力和使用约束；MCP 则通过协议规范定义了资源、工具的元数据格式。无论在哪一层，准确的“能力描述”都是模型能否正确选择和使用外部能力的前提。
第三，三者都依赖结构化数据传递。 Function Call 输出结构化参数，Skills 内部调用也以结构化数据为边界，MCP 协议传输同样遵循规范化的消息格式。结构化的本质是为了消除自然语言的歧义，让机器之间的协作变得可靠。
第四，三者都关注安全与权限。 即使是 Function Call，也需要在执行层做权限校验；Skills 在平台层天然具备权限管理属性；MCP 则需要在协议层考虑身份认证与数据隔离。安全不是某一种技术的专属问题，而是贯穿三者始终的横切关注点。
Function Call 是模型侧的单点能力，它只涉及“模型输出什么”这一个环节。Skills 是应用侧的管理单元，它涉及工具的组织、权限、版本和编排。MCP 是系统间的互联协议，它涉及通信双方的角色定义、消息格式和传输语义。
可以用一个类比来理解：Function Call 相当于“函数签名”，Skills 相当于“封装好的模块”，MCP 相当于“模块之间通信的总线标准”。三者不在同一个抽象平面上。
Function Call 解决的是单次推理中的参数输出问题。它的输入是用户指令和工具声明，输出是结构化调用参数。它的作用域局限于一次模型推理过程。
Skills 解决的是开发和使用过程中的能力管理问题。它的输入是业务需求和平台能力，输出是可复用的能力单元。它的作用域跨越多次调用、多个工作流和多个开发者。
MCP 解决的是生态层面的互联互通问题。它的输入是异构系统和多样化的数据源，输出是统一的能力接入方式。它的作用域跨越不同的产品、不同的运行环境和不同的组织边界。
在 Function Call 场景中，数据流是单向且局部的：模型输出结构化参数 → 应用代码执行函数 → 结果返回模型。整个过程中，模型和应用是紧耦合的。
在 Skills 场景中，数据流变得更加复杂：工作流引擎或 Agent 调度器选择某个 Skill → Skill 内部发起工具调用（可能使用 Function Call）→ 工具执行 → 结果经过 Skill 的封装逻辑处理后返回上层。这里多了一层抽象，调用关系从“模型直连工具”变成了“模型经平台间接使用工具”。
在 MCP 场景中，数据流跨越了进程或网络边界：Client 发起标准化的工具发现请求 → Server 返回可用工具列表 → Client 发起标准化的工具调用请求 → Server 执行并返回结果。关键差异在于，Client 和 Server 之间的通信遵循统一协议，双方可以独立演化。
Function Call 的接入成本主要体现在模型侧兼容性和参数 schema 设计上。不同模型的 Function Call 实现细节可能存在差异，切换模型时需要验证工具声明格式和输出稳定性。
Skills 的接入成本主要体现在平台学习与适配上。开发者需要理解平台的 Skill 定义规范、权限模型和编排方式。如果从平台 A 迁移到平台 B，Skills 往往需要重新定义，迁移成本较高。
MCP 的接入成本主要体现在协议实现与部署运维上。开发者需要实现或部署 MCP Server，处理认证、资源描述和工具调用分发。但如果多个系统都支持 MCP，后续新增集成的边际成本会显著降低。
Function Call 适合场景相对简单、工具数量有限、调用逻辑清晰的应用。例如：让模型从一段文本中提取结构化字段、判断用户意图并调用对应的查询接口、根据对话上下文生成表单填写参数等。在这些场景中，引入额外的抽象层反而增加复杂度。
Skills 适合工具数量多、团队协作频繁、需要权限分级和版本管理的平台型场景。例如：企业内部 Agent 平台需要让不同部门共享和复用各自的工具能力，同时保证数据隔离和权限可控。
MCP 适合需要在异构系统之间建立长期、稳定、标准化连接的场景。例如：一个 Agent 应用需要访问多种外部服务（文件存储、数据库、消息系统、内容平台），且这些服务可能由不同团队、不同组织提供。
| 对比维度 | Function Call | Skills | MCP |
|---|---|---|---|
| 本质定位 | 模型侧的能力调用机制 | 应用层/平台层的能力管理抽象 | 系统间的标准化互联协议 |
| 核心解决的问题 | 模型如何输出结构化参数 | 工具如何被统一管理和复用 | 异构系统如何互通 |
| 所处层级 | 模型推理层 | 应用平台层 | 通信协议层 |
| 主要使用者 | 模型开发者、应用开发者 | 平台开发者、业务开发者 | 系统集成者、平台架构师 |
| 作用范围 | 单次模型推理 | 平台内的多次调用与工作流 | 跨系统、跨进程、跨组织 |
| 权限管理 | 依赖执行层自行实现 | 通常在平台层统一管理 | 协议层支持认证，具体策略由实现方决定 |
| 版本管理 | 由开发者自行维护 schema | 平台提供版本化能力 | 依赖协议版本和 Server 实现 |
| 迁移成本 | 主要受模型切换影响 | 跨平台迁移成本较高 | 协议统一后边际接入成本降低 |
| 典型适用场景 | 轻量工具调用、结构提取 | 企业 Agent 平台、多工具协作 | 多系统集成、生态互联 |
场景一：构建一个简单的问答机器人，需要查询天气和汇率。
在这个场景中，工具数量少，调用逻辑清晰，业务边界明确。最直接的做法是使用 Function Call。开发者在请求中声明两个函数（查询天气、查询汇率），模型根据用户问题输出对应函数的参数，应用代码执行调用并返回结果。引入 Skills 或 MCP 反而会增加不必要的抽象成本。
场景二：企业内部的智能运营平台，需要接入 CRM、工单系统、知识库、数据分析等数十种工具，且不同团队负责不同工具。
这个场景的核心挑战是工具数量多、权限复杂、协作频繁。Skills 的抽象价值开始体现。每个团队将自己负责的工具封装成 Skill，统一注册到平台，配置权限和使用说明。Agent 在运行时根据任务需求选择合适的 Skill 执行。此时 Function Call 仍然在底层发挥作用，但开发者面对的主要接口变成了 Skill 层。
场景三：一个 IDE 或 Agent 产品需要让用户灵活接入各种外部数据源和服务，且希望形成开放的生态。
这个场景本质上是一个集成问题。如果没有统一协议，每接入一种新服务都要写适配代码，生态扩展成本极高。MCP 的价值在于它定义了一套通用规范，让服务提供方按照协议实现 Server，模型宿主按照协议实现 Client，双方即可对接。这类似于“统一了接口标准”，让生态内的多方参与者可以独立开发和演化。
场景四：一个复杂系统同时涉及三种技术。
现实中的大型 Agent 系统往往是三层叠加的。底层使用 MCP 连接外部系统，中层在平台内将各种能力封装为 Skills 进行管理和编排，上层通过 Function Call 让模型在单次推理中精确输出调用参数。三层各司其职，从不同角度解决了同一个复杂问题。
选型的关键不是“哪个技术更好”，而是“你的问题发生在哪一层”。
如果当前问题的核心是模型输出的参数不稳定、格式不符合预期，应该优先优化 Function Call 的设计，包括改善函数描述、精简参数 schema、增加示例示范等，而不是引入新的抽象层。
如果当前问题的核心是工具数量增长导致管理混乱、权限失控、重复开发，那么应该引入 Skills 层的管理机制，在平台内部建立工具能力的注册、审核、版本和权限体系。
如果当前问题的核心是需要对接大量异构系统，且集成工作量持续增长，那么应该评估 MCP 的引入价值，考虑通过标准化协议降低长期集成成本。
从团队能力角度看，Function Call 对团队的要求最低，基本上有模型调用经验即可上手。Skills 需要团队具备平台工程能力，能够设计和维护工具治理体系。MCP 需要团队具备分布式系统和协议设计的基础，能够处理网络通信、认证、容错等问题。
不存在一个需要在所有场景下都优先选择的技术。正确做法是根据系统当前阶段的痛点，选择在对应层级引入合适的技术手段。
从 Function Call 迁移到 Skills 时，需要注意函数声明的归属变化。原来的 Function Call 逻辑可能散落在各业务模块中，迁移到 Skills 后需要统一收口。这会涉及代码重构、权限迁移和调用链调整。同时要关注 Skills 平台对 Function Call 的兼容程度，避免模型输出格式与平台预期不一致。
从 Skills 迁移到 MCP 时，需要注意能力描述的标准化改造。Skills 中定义的权限模型、版本机制和调用约定，在 MCP 协议下可能需要重新映射。特别是当 Skills 依赖平台特有的编排能力时，迁移到 MCP 后这些平台特性可能无法直接保留。
使用 MCP 时，需要关注几个实现层面的风险：一是网络通信的稳定性和延迟，MCP 调用跨越了进程或网络边界，相比本地函数调用，需要更多的容错和超时处理；二是认证与数据隔离，MCP Server 暴露的资源和工具可能需要针对不同 Client 做差异化的权限控制；三是协议版本的兼容性，在协议演进过程中需要制定升级策略，避免 Client 和 Server 版本不匹配导致调用失败。
安全方面的通用原则是：无论使用哪一种技术，都不应该让模型直接获得不受约束的操作权限。Function Call 的执行层必须做参数校验和权限拦截；Skills 平台必须建立完善的审核和授权流程；MCP Server 必须实现严格的认证和资源访问控制。模型输出的结构化参数只是“意图表达”，最终能否执行、以什么权限执行，必须由执行层决定。
Function Call、Skills 和 MCP 三者之所以容易被混淆，是因为它们都服务于“让模型调用外部能力”这一共同目标。但从技术本质来看，它们分别处于三个不同的抽象层级。
Function Call 回答的是“模型如何输出参数”。它是一套模型侧的结构化输出约定，是三者中最基础、最底层的机制。没有这个能力，模型就无法精确表达调用意图。
Skills 回答的是“工具如何被统一管理”。它是应用层或平台层的封装抽象，把零散的工具调用组织成可复用、可授权、可版本化的能力单元，解决的是工程治理问题。
MCP 回答的是“不同系统间如何互通”。它是一套标准化互联协议，通过统一 Client-Server 架构来传输资源、工具和提示词，解决的是生态集成问题。
理解这一层级关系，可以帮助开发者在架构设计时避免常见的抽象错位——比如在只有两个工具的场景下引入完整的 Skills 管理体系，或者在单机应用内部强行使用 MCP 进行进程间通信。正确的做法是识别当前系统的主要矛盾：是模型输出不稳定，是工具管理失序，还是系统集成成本过高。针对不同矛盾，在对应层级选择合适的技术手段，才是最务实的工程决策。