# 精简论文：渐进式披露式 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 能力体系的实用范式。