Skills关键机制-渐进式披露

正如 《有效的Context工程》文中所论证的，上下文过长容易导致模型能力下降，由于 Skills 的本质就是 Context 工程，所以这个问题也需在 Skill Agent 中注意。一个完整装载了 Skill 的 Agent 架构是这样的：

skill层级划分

Skill 包放在 Agent 文件系统（右侧）中，并非默认全量加载在 Context Window 中。根据 Context 加载顺序、优先级的不同，Skill 被划分为了 3 种层级：

Level 1（元数据，始终加载）

SKILL.md 文档内的元数据，包含名称与用途描述。长度约 100 tokens。
Agent 启动时，就在 Context Window 中加载 Skill 元数据，将其包含在系统提示中。
AI 通过理解用户消息与 Skills 元数据的匹配情况，判断是否需要自动使用技能

---
name: pdf
description: 全面的 PDF 操作工具包，用于提取文本和表格、创建新 PDF、合并/拆分文档以及处理表单。当 Claude 需要填写 PDF 表单或大规模地程序化处理、生成或分析 PDF 文档时使用。
---

• 默认只加载元数据 → 意味着可以给一个 Agent 同时安装很多 Skills 但不影响上下文性能

Level 2（指令，触发时加载）

SKILL.md 文档内的正文内容，也就是主要技能指令，一般包含工作流程、最佳实践和指导。
建议少于 5000 tokens。
当用户发出的消息与Skill 元数据的描述匹配，需要调用 Skill 时，Agent 才会用 bash 读取文档正文 。读取时文档内容加载到 Context Window 中。

Level 3（子技能指令 / 资源 / 代码，按需动态加载）

由子技能文档、代码脚本、参考文档、可用资源等文件构成。
也有 Agent Skill 规范文档将它们统称为「Resource」。相对来讲，Level 3 结构要求没那么严谨。
· Sub-SKILL.md 子技能文档：相对独立、复杂的子技能指令，单独放在 Level3 拆分加载

随着一个 Skill 的复杂度提升，可能因为技能知识的上下文过长，或者有些知识仅在特定场景使用，而不适合放入单个SKILL.md，可被分拆为独立指令文档，仅在必要时加载。

• Scripts 代码脚本:视作“Agent 的可执行资源”，而不算 tool use（tool use 是 Agent 外部调用的独立服务）,Agent 在 Agent 电脑（虚拟机）中直接调用脚本，脚本代码本身不进 Context Window，只有脚本运行完成后的输出会进 Agent 的 Context。
• Reference 参考文档、Assets 可用资源:当然都是 Level 3，仅在必需时动态读取加载。Level 3 因为按需加载的特性，文件在被访问前不会占用 Context 长度，所以没有内容大小限制，可按业务实际说明需要添加材料。

渐进式披露

• 整个 Skill 运行过程中，Agent 自动判断哪些技能与任务相关，根据 skills 的元信息，动态判断、加载完成任务所需模块

Level 1: SKILL.md 元数据（name + description）
         ↓
Level 2: SKILL.md 完整内容
         ↓
Level 3: Resources 中的具体文件（按需读取）

• 不过，即使 Agent Skill 支持「渐进式披露」。但在商业化的 Agent 产品中，单个或多个 Skills 联用，如何稳定控制运行过程中的 Context 长度，依然是绕不过的工程问题。

Skills对AI产品设计的影响

• 基于 Skills 做的垂直 Agent 应用，会不会有依赖推理，响应速度降低的问题？

启发：
  1. Skills 是一种非常宽容的 Agent 设计架构
  2. Skills 可以被设计为很多 tokens 的指令文档，引导模型思考；也可以是无需思考的简单指令，直接指向可直接运行的脚本代码
  3. 因为 Skills 能直接调用代码逻辑，不进 Context 窗口。所以用 skill 也不需要 agent 一直推理，agent 也可以只承担类似 hook 的角色，实质上和正常程序运行并无差别
  4. 所以 Skills 慢起来可以是 prompt，快起来也可以是 workflow

另外，再结合两个趋势的极端判断：
  token 价格会下降
  agent 速度会提升
这么看来，以 Skills 为基础的垂直 Agent，在性能、开销上的问题，也不是不可解决的持续性问题了。

• 进一步推演未来 ai native 产品的发展趋势，我目前的猜测是

1.继承上一代产品的快速处理性能
2.用户信息输入入口更简化，甚至唯一（chatbot包含一切）
3.应对预期内需求，能智能规划、分配任务的处理逻辑（产品预定义，类似skill）
4.能应对未规划的边缘情况or满足用户个性化需求

• 拿笔记类 APP 举例

大部分 APP 的逻辑还是：新笔记 -> 代码 -> 处理。新笔记完全用代码逻辑，原模原样直接入库。
但如果是 ai native 式的笔记 APP，他们可能会内置一些类似 skill 的指引，包括笔记入库、智能纠错、冗余笔记合并等。这些 skill 有些可能以 prompt 为主（需要生成），有些基本只有代码逻辑（快速响应）。
当用户写新笔记时，ai 快速自行判断：能不能直接入库？要不要智能纠错？有没有冗余的历史相似笔记需要合并？
每种情况，都由 agent 拿着各种 skills 自动匹配来处理。

总的来说，Skills-based的 Agent产品，就能用同一个多模态输入框，处理用户各种不同的输入，也能灵活应对未被规划的边缘问题、为用户提供绝对个性化的生成需求了。