1.动态提示词与 Agent Skills
1.1 背景：静态提示词的痛点
随着Agent业务场景不断扩充，把全部规则、文档一次性写入系统提示词会带来两大问题：
- 大量无关内容占用token，造成资源浪费；
- 冗余信息稀释模型注意力，产生上下文腐化。 动态提示词是静态提示工程的演进思路：不一次性加载全部知识，按需加载能力，Agent Skills就是这套思想落地的工程方案。
1.2 Skills：领域能力的可组合单元
Agent Skills将Agent能力封装成独立、可按需加载的知识包，遵循渐进式披露思想，先提供目录摘要，需要时再加载完整手册。
-
第一层（元数据） 每个Skill包含
SKILL.md，文件头部YAML元数据块包含name、description。框架启动时，仅把Skill名称与描述（少量token）注入上下文，让Agent知晓可用能力。description是路由核心，推荐采用
Use when / Don't use when写法，必须补充反例；缺少反例极易造成误触发。描述重点写路由触发条件，而非简单罗列功能。 -
第二层（核心流程） Agent判定任务需要该Skill后，调用专用Skill工具，加载完整
SKILL.md，内容以tool result形式写入对话历史。例如PPTX Skill，内置PPT解析、文件解压、路径约定等完整操作流程。 -
第三层（细则） 主文档可引用子文档，Agent按需读取子文档获取更深层技术细节。
Skill除文字指引外，还可绑定代码工具、模板文件，从知识说明升级为可执行能力。
- 工程价值：模块化独立开发、测试、版本管理；能力扩展从修改系统提示词，转向分布式Skill生态，类似npm/pip包管理。
- 重要原则：Agent交互模式需要对齐模型厂商训练范式，使用Claude优先使用Skills，其他模型采用其原生优化的交互方式，获得最佳模型表现。
1.3 Skills 的实现方式与权衡
核心工程决策：Skill内容放在上下文哪个位置，直接影响KV Cache性能与指令遵循效果，包含3种实现方案。
- 方式一：注入system系统提示词 优点：system位置指令遵循效果最强； 缺点：新增/切换Skill会修改system前缀，KV Cache全部失效，频繁切换场景下延迟、成本大幅上涨。
- 方式二：通用文件读取，内容放在上下文中间 优点：不改动system消息，不破坏KV Cache前缀； 缺点：模型容易把Skill文档当成普通参考文本，难以严格执行其中指令；不同模型支持程度差异大。
- 方式三（Claude Code生产方案）：元数据放上下文末尾，完整内容按需工具加载 路由和执行分离，规避前两种方案缺陷：
-
Skill元数据（name+description）以带
<system-reminder>标签的user角色消息追加至上下文末尾；不修改system，不破坏缓存前缀。采用增量发送，仅首次加载，稳态无增量。
取舍：注入当轮注意力效果好，随会话变长，元数据会留在上下文中部，注意力优势衰减。
-
完整Skill文档通过专用Skill工具按需调用返回，作为tool result写入对话。模型对主动调用工具返回内容具备更强的执行倾向，解决指令遵循不足问题。
KV Cache成本澄清："对缓存友好"不等于零成本。首次加载Skill需要一次性写入缓存；方案优势是一次写入，会话全程复用。对比将Skill全部放入system的方案，不会反复触发大规模缓存重建。
1.4 Skills 与工具的关系
若将大量工具定义全部放入system提示词，工具数量膨胀会消耗大量token，变更会破坏前缀缓存。 Skill+通用执行器模式：维持少量核心工具集合，各类领域能力通过Skills渐进披露按需加载，不污染静态前缀。工具、Skill两种能力形态的对比与选型框架详见第四章，Agent自主进化时能力沉淀策略见第八章。
1.5 使用 Agent Skills 从论文生成演示文稿
验证Agent借助动态加载专业Skill完成复杂任务的能力，基于Claude Code + PPTX Skill，输入学术论文PDF，生成10~15页PPT。 执行流程：
- 读取上下文末尾Skill元数据列表，识别PPTX Skill；
- 判断任务匹配，调用Skill工具加载完整
SKILL.md获取核心流程； - 按需加载子文档
html2pptx.md，获取PPT生成详细方法； - 调用配套脚本生成预览，加载设计模板，完成文稿生成。
验收标准： PPT包含标题页、背景、方法、结果、结论；至少3张论文提取图表，图文匹配，文件格式正常可打开。
