精简论文：渐进式披露式 Agent Skills 对上下文效率的影响

作者：示例作者团队（Anthropic 风格 Agent 研究，示例数据）

摘要

现代 LLM Agent 需要覆盖越来越多的专业任务，传统做法是把所有指令塞进单一 系统提示词，导致 token 消耗膨胀、注意力被稀释、KV Cache 前缀频繁失效。 本文提出并评估一种「渐进式披露（Progressive Disclosure）」的 Agent Skills 机制：先向 Agent 注入各 Skill 的薄目录（仅 name + description），当任务确实 需要时再按需加载完整的 SKILL.md 与子文档。实验表明，该机制在保持任务成功率的 同时显著降低常驻上下文长度。

1. 研究背景与问题

• 随着 Agent 支持的任务种类增长，单一系统提示词呈线性膨胀。
• 长提示词带来三重代价：token 成本、注意力稀释、缓存前缀失效。
• 核心问题：能否在「Agent 知道自己有哪些能力」与「不为此长期占用上下文」之间取得平衡？

2. 方法概述

• 三层渐进式披露：
• 第一层（元数据）：启动时只注入每个 Skill 的 name + description（数百 token）。
• 第二层（核心流程）：任务触发时加载完整 SKILL.md 作为 tool result。
• 第三层（细则）：按需读取 reference.md、脚本源码等子文档。
• 路由决策依赖 description：描述应写成「路由条件」而非「功能介绍」， 并给出反例（Don't use when），以降低误触发。
• 捆绑可执行脚本：Skill 不止是文档，还可附带脚本与模板，把知识升级为能力。

3. 关键结果

• 常驻上下文从「全量塞入」的数千 token 降到目录级的数百 token。
• 因为工具数量恒定、前缀稳定，KV Cache 命中率显著提升。
• 在需要专业 Skill 的任务上，成功率与「全量注入」基线持平（无明显下降）。
• 反例（Don't use when）能明显提升路由准确率，减少不相关任务上的误触发。

4. 局限性与讨论

• 触发依赖模型的「元认知」：模型需判断自己何时需要某个 Skill，判断失误会漏加载。
• 第三方 Skill 是新的提示注入面，加载前需审查其内容。

5. 结论

渐进式披露把「一次性塞满」变为「按需加载」，在几乎不损失任务成功率的前提下， 大幅降低常驻上下文并改善缓存友好度，是构建可扩展 Agent 能力体系的实用范式。