前言

在 Agent 系统逐渐走向复杂化的过程中，一个问题开始变得越来越突出：当模型需要调用越来越多工具、执行越来越复杂任务时，如何组织这些能力，并在保证效果的同时控制成本？

在这样的背景下，Agent Skills 逐渐成为一个被频繁提及的概念。它并不是一个单一的技术，而是一种围绕“能力组织与调用”的工程范式，尤其在多工具、多步骤的 Agent 系统中表现出重要价值。

一、什么是 Agent Skills

1. 概念的由来

在早期的 Agent 系统中，开发者通常会把所有能力直接暴露给模型。例如，将所有工具的说明、参数定义、使用方式一次性写入 Prompt 或系统上下文中，让模型“自己决定”该调用哪个工具。

这种方式在工具数量较少时尚且可行，但随着系统复杂度提升，很快暴露出两个问题：

一方面，上下文迅速膨胀，模型的注意力被大量无关信息分散，反而降低了决策质量；另一方面，模型在面对复杂工具集合时，容易出现误用、乱用甚至完全忽略工具的情况。

因此，工程实践开始从“把所有能力都给模型”转向“只在需要时提供能力”，Agent Skills 正是在这一转变中逐渐形成的。

2. Agent Skills 的本质

从工程角度来看，Agent Skills 可以理解为：

对 Agent 能力的一种模块化封装与按需暴露机制

一个 Skill 通常包含以下几个要素：

• 能力描述（它能做什么）
• 调用条件（在什么场景下使用）
• 执行逻辑（可能包含多步操作或工具组合）
• 输入输出规范（结构化接口）

与“工具（Tool）”相比，Skill 往往是更高层的抽象。工具是原子能力，例如“搜索”、“读取文件”、“调用 API”；而 Skill 更像是对这些能力的组合，例如“分析文档风险”、“生成产品报告”。

换句话说，Skill 并不是简单地增加能力，而是在能力之上增加了一层组织与调度逻辑。

3. 为什么需要 Skills

随着 Agent 从“回答问题”转向“执行任务”，系统面临的核心问题不再是单次生成是否正确，而是整条任务链路是否稳定。

在这种情况下，如果仍然让模型直接面对所有底层工具，等价于让一个人同时记住所有 API 文档、业务规则和执行流程，这在实践中几乎不可控。

Skill 的出现，本质上是在做一件事情：

将复杂能力结构化、分层化，让模型在更小的决策空间中做判断。

这不仅降低了错误率，也为后续的优化（如调度、缓存、复用）提供了基础。

二、Agent Skills 与 MCP 协议的区别

在讨论 Agent 能力组织时，另一个常被提及的概念是 MCP（Model Context Protocol）。两者虽然都与“能力调用”相关，但关注点完全不同。

1. MCP 的定位

MCP 更偏向于一种通信协议或标准接口，其核心目标是：

定义模型如何与外部工具、数据源进行交互

它解决的是“怎么连”的问题，包括：

• 工具如何被描述
• 参数如何传递
• 返回结果如何结构化
• 多个服务如何统一接入

从这个角度看，MCP 更像是 Agent 生态中的“基础设施”。

2. Skills 的定位

相比之下，Agent Skills 更关注的是：

在已有能力之上，如何组织、选择并调度这些能力

它解决的是“怎么用”的问题，例如：

• 在什么情况下调用某个能力
• 是否需要组合多个能力
• 如何拆解复杂任务
• 如何控制执行路径

因此，可以把两者关系理解为：

MCP 提供能力接入的标准方式，Skills 负责能力的组织与使用策略。

3. 一个直观对比

可以用一个类比来理解：

• MCP 类似于“USB 接口标准”，解决设备如何接入
• Skills 类似于“应用程序”，决定如何使用这些设备完成任务

一个系统可以没有复杂的 Skills，但只要涉及多个工具协同，就几乎离不开 MCP；而一旦任务复杂度上升，Skills 就成为提升系统稳定性的关键。

三、Skills 如何通过渐进式披露节省 Token

在实际工程中，Agent Skills 最直接的价值之一，是显著降低上下文消耗。这一点主要体现在“渐进式披露（Progressive Disclosure）”这一设计思路上。

1. 传统方式的问题

在没有 Skills 的情况下，常见做法是将所有工具信息直接放入上下文，例如：

• 工具说明
• 参数定义
• 使用示例

当工具数量达到十几个甚至几十个时，这部分内容会占据大量 Token，带来两个直接问题：

首先是成本问题，上下文越长，调用模型的成本越高；其次是效果问题，信息过多会导致模型注意力分散，反而降低决策准确率。

2. 渐进式披露的核心思路

Skills 的一个关键设计是：不一次性暴露全部能力，而是在需要时逐步提供信息。

典型流程如下：

第一步，只向模型提供一个“能力列表”，每个 Skill 只有简要描述，例如：

• 文档分析
• 数据查询
• 报告生成

此时上下文非常精简，模型只需要做一件事情：判断当前任务属于哪个能力范围。

第二步，当模型选择某个 Skill 后，系统再将该 Skill 的详细信息（包括步骤、参数、约束等）注入上下文。

第三步，在执行过程中，如果需要调用具体工具，再进一步补充对应工具的细节。

3. 为什么这样可以节省 Token

这种分阶段注入信息的方式，本质上是在做两件事情：

其一，减少“无关信息”的长期占用。模型在大多数时间内只看到与当前任务相关的能力描述，而不是整个系统的全量能力。

其二，将复杂信息延迟到“真正需要的时刻”。只有在模型已经确定使用某个 Skill 时，才引入详细上下文，从而避免早期决策阶段的信息干扰。

从结果上看，这种方式不仅降低了 Token 使用量，也提高了模型在关键步骤上的专注度。

4. 工程学上的进一步延伸

在实际系统中，渐进式披露往往还会结合以下策略：

• 对 Skill 进行分层设计（基础能力 / 高级能力）
• 动态加载上下文，而非静态拼接
• 对历史上下文进行压缩或替换
• 在多 Agent 场景下，仅传递结构化结果而非原始文本

这些手段的共同目标，是让上下文始终保持“最小但足够”。

四、总结

随着 Agent 系统从简单问答走向复杂任务执行，能力的组织方式逐渐成为影响系统稳定性的关键因素。

Agent Skills 的出现，本质上是对这一问题的工程化回应。它通过将能力模块化、结构化，并结合渐进式披露机制，在保证能力表达完整性的同时，有效控制了上下文规模与系统复杂度。

如果说 MCP 解决的是“能力如何接入”，那么 Skills 解决的是“能力如何被高效使用”。两者共同构成了现代 Agent 系统中不可或缺的基础。