Skills的本质：Function Call、Skills与MCP对比解析

作者：rousong2026.11.04 12:35浏览量：0

简介：本文系统对比大模型应用中极易混淆的三个概念：Function Call（能力调用机制）、Skills（能力管理抽象）与MCP（标准化互联协议），从技术层级、状态管理、扩展性、安全治理等维度剖析相同点与核心差异，并结合典型场景给出选型建议与迁移注意事项，帮助开发者分清“模型如何输出参数、工具如何统一管理、系统间如何互通”三类问题，做出正确的架构决策。

一、对比背景：为什么需要分清这三个概念

在构建基于大语言模型（LLM）的应用系统时，“让模型调用外部能力”是绕不开的环节。无论是查询天气、检索知识库，还是执行一次下单操作，都需要模型与外部系统协同完成。围绕这一诉求，行业中先后出现了 Function Call、Skills 和 MCP 三个高频概念。

这三者处于不同的技术层级，分别回答三个不同的问题：

  • 模型如何输出结构化参数？——Function Call
  • 工具能力如何被统一管理？——Skills
  • 不同系统之间如何标准化互通？——MCP

混淆三者的直接后果是架构错配：有人试图用 Function Call 的机制去解决工具治理问题，导致工具数量失控、权限混乱；有人引入了重型协议却只对接两三个工具，平白增加运维负担。因此，本文把三者放在同一对比框架下，从对象定义、相同点、核心差异、场景选择到迁移注意事项逐层展开。

二、对象定义：三者分别是什么

2.1 Function Call：模型侧的调用机制

Function Call 是模型侧的原生能力（或推理服务暴露的接口能力），核心机制是：开发者将工具名称、参数结构（通常以 JSON Schema 描述）随请求传入，模型在合适的时机输出一段符合 Schema 的结构化数据，由外部代码解析并执行，再把执行结果回传给模型继续生成。

需要强调：模型并没有真的“学会调用函数”，它只是通过训练或提示工程，被引导生成一段格式正确的文本。执行权始终在外部系统手中，工程上应将其视为结构化生成任务。

2.2 Skills：应用层的能力管理抽象

Skills 通常是应用层或平台层（例如某低代码智能体开发平台、早期智能体框架）对工具能力的封装。它的关注点不是“模型怎么输出参数”，而是“工具作为一类资产怎么被管理”，典型要素包括：

  • 权限：哪些智能体、哪些用户可以调用这个工具；
  • 版本：参数结构或行为升级时如何灰度发布与回滚；
  • 工作流编排：多个原子工具如何串联成复合流程；
  • 描述元数据：向模型解释“这个工具能做什么、什么时候该用”。

在实际落地中，主流云厂商的智能体开发能力（如百度智能云提供的智能体与应用编排类通用能力）普遍采用了这种 Skills 化封装思路，把调用机制、权限、版本与流程编排统一收敛到平台层，让业务开发者无需关心底层模型的输出细节。

2.3 MCP：标准化互联协议

MCP（Model Context Protocol，模型上下文协议）是近期由行业头部模型厂商推动的开放协议，定位是解决模型与数据源、工具之间的标准化连接问题。它定义了一套通用的 Client-Server 架构：

  • 服务端暴露资源（Resources）、工具（Tools）、提示词（Prompts）三类原语；
  • 客户端负责发现、选择与调用；
  • 双方按统一的消息格式与生命周期通信。

MCP 的价值不在“更聪明的调用”，而在“更标准化的互通”——任何支持该协议的客户端，理论上都能接入任何实现该协议的服务端，工具生态得以跨系统复用。

三、相同点分析

尽管层级不同，三者存在明显的共同基础：

  1. 目标同源：都为了让 LLM 突破纯文本生成的边界，获得读写外部数据、执行真实动作的能力。
  2. 流程闭环一致：都遵循“工具描述 → 模型决策 → 参数生成 → 外部执行 → 结果回传”的基本闭环。
  3. 依赖描述质量：无论哪个层级，工具描述文本的清晰度都直接影响模型选择工具与填参的准确率。
  4. 安全不可缺席：鉴权、越权防护、输入校验、审计日志在三个层级都需要落实。
  5. 组合而非互斥：成熟系统往往三者叠加——MCP 负责连接，Skills 负责管理，Function Call 负责最后一公里的结构化输出。

四、核心差异分析

4.1 技术层级与职责边界

  • Function Call 位于模型推理层，边界最小：把“我要调用某工具、参数如下”这一意图变成合法结构化数据；
  • Skills 位于应用编排层，负责工具的注册、发现、权限、版本与编排；
  • MCP 位于协议层，负责定义通信契约，使连接方与被连接方解耦。

一个直观类比：Function Call 像函数签名与调用约定，Skills 像依赖管理系统，MCP 像统一的通信协议。

4.2 状态与执行模型

Function Call 本身是无状态的：模型输出参数后，执行权交给外部系统，模型不感知执行细节。这带来两个工程痛点：一是执行失败后的重试，需要把错误信息回传给模型再决策；二是多轮对话中“已经调用过什么、结果是什么”的状态保持，需要外部系统维护。Skills 层通常引入执行状态机与工作流上下文，把状态管理固化下来；MCP 则在协议中定义会话生命周期与能力协商，使状态管理有章可循。

4.3 扩展性与上下文成本

  • Function Call：所有工具描述都要进入请求上下文，工具数量增多时提示词膨胀、选择准确率下降，需要应用侧自己做工具检索与裁剪；
  • Skills：平台通常提供注册与检索机制（如按需加载技能描述），对工具规模更友好；
  • MCP：支持动态发现服务端能力，客户端按需列出与选择工具，天然面向海量工具生态设计。

4.4 接入方式与改造成本

Function Call 改造成本最低：定义 Schema、写执行函数、处理回传即可，适合快速原型；Skills 需要按平台规范组织工具并学习其权限与编排模型，成本中等；MCP 需要实现或引入协议客户端/服务端、处理握手与能力协商，初期成本最高，但换来生态互通。

4.5 安全与治理

Function Call 的权限控制完全由应用侧自建，灵活但容易遗漏；Skills 由平台层提供统一权限模型与版本管控，治理能力强；MCP 在协议层提供标准化鉴权与能力边界协商，安全责任分布在客户端与服务端两侧，需共同落实。运维重心也各不相同：Function Call 关注解析成功率与重试策略，Skills 关注版本、权限审计与编排调试，MCP 关注服务端可用性、协议版本兼容与连接治理。

五、深入 Function Call：底层实现与常见陷阱

Function Call 是三层中的地基，有必要展开其实现细节。

5.1 语法约束解码（Grammar Constrained Decoding）

早期 Function Call 依赖“先生成、再后处理解析”，JSON 格式错误率较高（引号缺失、枚举值拼错等）。主流改进做法是在解码阶段直接介入：把工具的 JSON Schema 转换为一棵语法规则树，每一步解码时限制模型只能生成合法 token。示意性伪代码如下：

  1. schema = {
  2.   "name": "get_weather",
  3.   "parameters": {
  4.     "type": "object",
  5.     "properties": {
  6.       "location": {"type": "string"},
  7.       "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
  8.     },
  9.     "required": ["location"]
  10.   }
  11. }
  13. grammar = build_json_grammar(schema)        # Schema → 语法规则树
  14. for step in decode(model, prompt):
  15.     allowed = grammar.allowed_tokens(state) # 当前状态下合法的 token 集合
  16.     token = sample(step, mask=allowed)      # 只在合法集合内采样
  17.     state = grammar.transition(state, token)

当模型生成到 unit 字段时，解码器强制其只能在 celsius 与 fahrenheit 对应的 token 序列中选择，从机制上消除这类解析失败，而不是事后报错。

5.2 状态管理与幂等性

无状态特性要求工程侧自行补齐两件事：

第一，幂等设计。 对下单、扣款、发消息等有副作用的操作，必须设计幂等键（如请求 ID + 工具名 + 关键参数摘要），避免重试造成重复执行；是否重试、重试几次，应在应用侧有明确策略，而不是简单把错误抛回模型。

第二，错误回传与再决策。 例如用户说“帮我订一张明天去北京的票”，模型调用订票工具后工具返回“库存不足”。合理做法是把结构化的错误信息（错误码、原因、可选项）回传给模型，让模型决定是推荐临近时段、更换方案，还是向用户说明情况。错误回传的信息设计会显著影响模型的再决策质量。

六、Skills 封装的核心要素

回到标题的问题——Skills 的本质是什么？可以概括为一句话：Skills 是把“工具”从一段 Schema 描述升级为“可治理的能力资产”的抽象层。其核心要素包括：

  1. 描述即能力：给模型看的说明文档本身就是能力的一部分；
  2. 权限与租户隔离：谁能用、在什么场景用、数据边界在哪里；
  3. 版本与灰度：参数结构变更时新旧版本如何并存与回滚；
  4. 编排与组合：把原子工具组合成复合流程供业务复用；
  5. 触发策略：由模型自主选择，还是由流程强制绑定。

一句话总结：Function Call 解决“能不能调”，Skills 解决“管不管得住”。

七、对比表格

维度 Function Call Skills MCP
技术层级 模型推理层 应用/平台层 协议层
核心问题 模型如何输出结构化参数 工具如何被统一管理 系统间如何标准化互通
状态管理 无状态，需外部补齐 工作流状态机 会话生命周期
扩展性 受上下文长度约束 平台注册与检索 动态发现，面向生态
接入成本 低 中 初期较高
安全治理 应用自建 平台统一权限模型 协议级鉴权+服务端权限
典型使用者 应用开发者 平台/团队 生态建设者
适合规模 少量工具、快速验证 中等规模、多角色协作 大规模、跨系统互联

八、典型场景选择

  • 场景一：单一应用、少量工具、快速验证。 内部查询助手只有三五个接口，直接用 Function Call 即可，引入更重的管理层不划算。
  • 场景二：企业内多智能体、多团队共享工具。 工具多、调用方多、权限复杂，应引入 Skills 层做注册、权限、版本与编排管理；运维能力有限的团队可优先考虑托管化程度更高的云上智能体开发平台（如百度智能云的智能体应用编排类通用能力），把治理交给平台、精力聚焦业务。
  • 场景三：连接外部数据源与工具生态。 希望自家工具被多方接入，或避免每个连接单独定制，此时标准化互联协议是更合适的底座。
  • 场景四：混合形态。 大多数生产系统最终是三者叠加：底层 Function Call、中层 Skills 治理、外层协议互通。

九、选型建议

  • 痛点是“参数经常生成错”：优先在 Function Call 层做语法约束解码与错误回传设计，而不是急着引入新抽象；
  • 痛点是“工具越加越多、权限乱、版本没人管”：优先建设 Skills 层的治理能力；
  • 痛点是“每个工具都要单独对接、无法复用”：优先评估标准化互联协议；
  • 自研能力强、定制诉求重的团队可按分层思路自建；团队规模有限时优先选择托管化方案；
  • 不要用“谁取代谁”理解三者：它们解决不同层级的问题，取代关系并不成立。

十、迁移与使用注意事项

  • 从裸 Function Call 迁移到 Skills 化管理：重点是工具描述的规范化迁移与权限模型重建，注意保留原有幂等与重试策略，避免封装过程中丢失；
  • 从私有封装迁移到标准化协议：评估现有工具语义能否映射到协议原语（工具/资源/提示词），关注协议版本的兼容性与升级节奏；
  • 稳定性风险：协议层与平台层会新增故障面（连接失败、能力协商失败、版本不兼容），需配套监控告警与降级路径，例如协议不可用时回退到内置工具；
  • 安全审计：无论哪一层，都要保证“谁在什么时机调用了什么工具、参数与结果是什么”可被完整审计，这是企业落地最容易缺的一环。

十一、总结

Function Call、Skills 与 MCP 并非三选一的竞争关系，而是“调用机制—管理抽象—互联协议”三个层级的分工：Function Call 是地基，把调用意图变成结构化数据，配合语法约束解码与幂等设计即可稳定可靠；Skills 是治理层，把工具变成可管理的能力资产；MCP 是生态层，用统一契约解决跨系统互通。选型的正确姿势是先定位自己真正要解决的问题属于哪一层，再决定在该层投入多少自建、引入多少平台能力——分清层级，才不会用错工具。

最热文章