Skills的本质是什么？

一、从一个高频困惑说起

在基于大语言模型构建应用系统的过程中，开发者经常会遇到三类听起来高度相关、实际却处于不同层面的概念：Function Call、Skills 和 MCP。

很多人会直观地认为它们都是“让模型调用工具”的方案，于是在架构设计时混用这些词，甚至把任意一种工具调用能力都称作 Skills。真正进入实现阶段后，又容易被接口设计、权限管理、版本升级、跨系统复用等问题卡住。

要理解 Skills 的本质，首先需要把这三者放回各自的层级中去观察：

• Function Call 更像是一种模型侧的能力调用机制；
• Skills 更接近一种应用层或平台层的能力管理抽象；
• MCP 则是一种面向标准化互联的协议。

本文重点讨论 Skills。它不是一个模型原生概念，也不是一个通信协议，而是一套对工具、流程和知识能力进行封装、组织与治理的工程方案。

---

二、Skills 是什么

2.1 从技术视角看

Skills 是应用系统或开发平台对可复用能力的一种抽象封装。

一个 Skill 通常不只是“调用一次函数”。它可能包含：

• 工具调用逻辑；
• 输入输出约束；
• 权限范围；
• 版本信息；
• 执行策略；
• 失败处理规则；
• 与其他 Skill 的依赖关系。

换句话说，Function Call 解决的是“模型如何表达一次调用意图”，而 Skills 解决的是“一个可被模型或流程使用的能力单元如何被定义、管理和复用”。

2.2 从业务视角看

从业务角度看，Skills 是团队将开发能力产品化的一种方式。

例如，一个“查询订单状态”的能力，如果只停留在函数层面，它可能只适合某一个 Prompt 或某一个流程使用。一旦将它封装成 Skill，就可以：

• 被多个智能体共享；
• 配置不同角色的调用权限；
• 随业务变化独立升级；
• 在流程编排中被组合使用。

因此，Skills 往往不只是技术抽象，也承担了业务治理和组织协作的功能。

2.3 从使用视角看

对使用者来说，Skills 是一组“可被模型或编排器选择的能力资源”。

在很多智能体平台中，开发者不会直接描述每个函数参数，而是为模型提供一组可用 Skill 的描述。模型根据用户意图，选择调用某个 Skill，并按照其输入模式生成参数。

这种交互方式更接近“能力选择”，而不是“函数签名匹配”。

---

三、为什么需要 Skills

理解 Skills 的价值，可以从一个典型演化路径出发。

3.1 早期阶段：直接使用 Function Call

在早期 LLM 应用开发中，常见做法是：

• 定义一组函数；
• 将函数名、描述和参数 schema 提供给模型；
• 模型输出结构化调用信息；
• 应用层解析并执行函数。

这种方式在工具数量较少、流程简单时非常高效。

3.2 工具数量增长后的问题

当工具数量从几个增长到几十个甚至上百个时，问题开始出现：

命名冲突

不同团队可能都实现了“查询订单”，但函数命名和参数结构不同。

权限难以隔离

某些工具只能由部分用户或部分流程调用，但函数级调用通常缺少统一控制。

版本管理困难

函数签名一旦变化，所有依赖它的 Prompt 和流程都需要同步调整。

复用成本高

同一工具需要在不同应用、不同智能体中反复接入，难以沉淀为组织级能力。

可观测性不足

函数调用散落在代码各处，调用成功率、异常模式、时延等信息难以统一收集。

3.3 Skills 作为工程化回应

Skills 正是为了回应这些问题而出现的抽象层。

它并不替代 Function Call，而是在 Function Call 之上增加了一层工程化能力：

• 统一能力描述；
• 统一输入输出约束；
• 统一权限与版本策略；
• 统一调用入口；
• 统一执行与观测机制。

因此，简单来说：当工具调用从“一次性行为”变成“可管理资产”时，Skills 就会自然出现。

---

四、Skills 的核心组成

一个相对完整的 Skills 体系，通常包含以下几个关键部分。

4.1 能力描述

每个 Skill 都有清晰的元信息，例如：

• Skill 名称；
• 功能说明；
• 适用场景；
• 输入结构；
• 输出结构；
• 错误码定义；
• 调用示例。

这些信息既服务于人类开发者，也服务于模型。模型正是根据这些描述来决定是否调用该 Skill，以及如何生成参数。

4.2 权限与作用域

Skills 通常会声明自己的权限范围。例如：

• 是否需要访问数据库；
• 是否需要读取用户信息；
• 是否能触发外部写操作；
• 是否允许在自动执行流程中被调用。

权限与作用域的分离，使得 Skills 可以在更复杂的组织环境中安全使用。

4.3 版本与生命周期

Skill 通常具有独立的版本管理能力。不同版本的 Skill 可以并存，应用或流程可以选择绑定特定版本。

这种机制为渐进式升级和回滚提供了空间，也避免了函数签名的“牵一发动全身”问题。

4.4 执行策略

一个 Skill 不只是描述“能做什么”，还需要描述“如何执行”。执行策略可能包括：

• 同步或异步执行；
• 超时时间；
• 重试次数；
• 幂等处理；
• 降级方案；
• 人工确认策略。

这些策略使 Skills 更适合生产环境，而不仅仅是演示场景。

4.5 观测与审计

在生产系统中，Skill 的调用过程应当可追踪。常见的观测信息包括：

• 谁发起了调用；
• 模型选择了哪个 Skill；
• 传入了哪些参数；
• 执行耗时；
• 成功或失败状态；
• 是否触发了敏感操作。

这些信息不仅用于排障，也用于审计和安全合规。

---

五、Skills 的工作原理

下面从一次典型调用的角度，描述 Skills 在企业级应用中的工作流程。

5.1 注册与描述

开发者在平台中注册 Skill，提供名称、描述、参数 schema、权限信息和执行配置。

平台会将这些 Skill 描述统一组织成模型可读取的形式。

5.2 意图识别与选择

当用户输入到达系统后，模型会结合上下文和可用 Skill 列表进行判断：

• 当前请求是否需要用某个 Skill；
• 如果需要，应该调用哪一个；
• 需要补充哪些参数；
• 是否缺少必要信息，是否需要向用户追问。

这一步的本质仍然是模型侧的决策，但输入内容已经由“函数列表”上升为“能力列表”。

5.3 参数生成与校验

模型输出结构化调用请求。平台不会直接执行，而是会做多轮校验，例如：

• 参数类型是否匹配；
• 必填字段是否完整；
• 参数值是否在合法范围内；
• 当前用户或流程是否有调用权限。

校验通过后，才会进入真实执行阶段。

5.4 执行与结果处理

执行器根据 Skill 的配置，调用底层工具或业务系统。执行完成后，结果可能：

• 直接返回给用户；
• 返回给模型进行下一步推理；
• 写入上下文供后续步骤使用；
• 触发人工审批或异常处理。

5.5 记录与反馈

调用结束后，系统记录本次 Skill 的选择、参数、执行结果和耗时信息。这些数据可以用于后续优化、审计和能力治理。

---

六、Skills 与 Function Call、MCP 的关系

理解 Skills 的一个关键，是厘清它与另外两者的边界。

6.1 Function Call 是基础机制

Function Call 解决的是“模型如何输出结构化调用参数”的问题。

它让模型可以按照预定义 schema 生成 JSON 或类似结构，从而触发代码执行。这是模型侧非常底层的能力，也是很多上层方案的基础。

6.2 Skills 是工程化抽象

Skills 不会脱离 Function Call 存在，但它的关注点完全不同。

Function Call 关注“一次调用是否成功”，Skills 关注“一组能力是否可管理、可复用、可治理”。

可以把 Function Call 理解为函数调用机制，而把 Skills 理解为一个受控的能力库。

6.3 MCP 是互联协议

MCP 解决的是不同系统之间的标准化连接问题。

它定义了一种统一的 Client-Server 结构，用于传输资源、工具和提示词等信息。其目标是降低模型与外部数据源、工具之间点对点对接的复杂度。

因此，MCP 与 Skills 的关系可以理解为：

• MCP 更像一种“传输和接入标准”；
• Skills 更像一种“能力组织方式”；
• Function Call 则是更底层的“模型输出约束机制”。

三者在实际系统中可以共同存在，但不应被等同视之。

---

七、典型使用场景

7.1 多智能体协作

当系统由多个智能体组成时，不同智能体可能需要共享部分能力。将公共能力封装为 Skills，可以避免重复开发，并统一权限和审计策略。

7.2 低代码或流程编排平台

在这类平台中，业务人员往往不会编写函数，但可以配置已有能力。Skills 提供了更友好的能力抽象，使非专业开发者也能完成业务编排。

7.3 企业级工具治理

对于工具数量多、权限要求复杂的组织，Skills 可以作为统一的工具管理单元。团队可以针对不同部门、不同项目发布不同版本和权限范围的能力。

7.4 频繁变更的业务系统

当底层系统接口频繁变化时，Skills 可以作为缓冲层。上层应用只需依赖稳定的 Skill 描述，底层实现可以在版本范围内调整，从而降低变更影响面。

---

八、设计和使用中的注意事项

8.1 避免 Skills 过度细分

如果每个函数都被包装成独立 Skill，系统复杂度反而会上升。合理的粒度应当是“具备明确业务价值、可独立复用”的能力单元。

8.2 注重能力描述质量

模型能否正确选择 Skill，很大程度上取决于描述是否清晰。描述应避免歧义，明确适用条件和输入输出边界。

8.3 引入访问控制

Skills 涉及外部系统调用，必须具备清晰的权限控制。尤其是在自动执行流程中，应限制高风险操作的调用条件，并保留人工确认机制。

8.4 关注版本兼容性

不同应用可能依赖不同版本的 Skill。平台需要支持版本并存与灰度切换，避免单点升级造成大面积故障。

8.5 建立观测与反馈机制

Skill 的实际调用情况可能与预期存在差异。应通过日志、指标和用户反馈持续评估其效果，并据此优化描述、参数结构和执行策略。

---

九、总结

Skills 的本质，不是一种新的模型调用方式，而是一种对工具能力进行工程化抽象与治理的方案。

它建立在 Function Call 等模型能力之上，把散落的函数调用组织成可管理、可复用、可审计的能力单元。对于任何工具数量较多、协作复杂度较高或业务变化频繁的系统，引入 Skills 都可以显著降低长期维护成本。

理解 Skills 的关键，不在于记住某个平台的实现细节，而在于分清它回答的核心问题：如何把一次性的工具调用，转变成组织内可持续使用的工程资产。