HotPursuit

【阅读笔记】Agent Skills：让 Agent 按需加载专域能力的工程架构

RL Paper Reading入库于 2026/6/3|
RL论文阅读Agent系统Anthropic

【阅读笔记】Agent Skills：让 Agent 按需加载专域能力的工程架构

原文：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills 发布：2025年10月16日 来源：Anthropic Engineering Blog

1. 一句话总结

Agent Skills 用"组织化的指令+脚本+资源"目录替代单一巨型 prompt，通过渐进式披露按需加载专域能力，大幅节省 Context 并提升 Agent 可靠性。

2. 背景知识

  • System Prompt：发送给 LLM 的初始指令，定义 Agent 的角色、能力和约束。传统做法是将所有能力描述写入一个巨型 System Prompt。
  • Context Window 限制：LLM 的注意力资源有限，Context 越长，有效信息密度越低（见 Context Engineering 笔记）。
  • Tool Use / Function Calling：LLM 可以调用预定义的工具，是 Agent 执行外部操作的基础机制。
  • MCP（Model Context Protocol）：Anthropic 提出的标准化工具集成协议，让 Agent 可以动态发现和使用工具。
  • 动态加载：只在需要时加载特定能力，类似于程序的按需导入（lazy loading），是节省资源的核心思路。

3. 为什么会出现这篇文章

随着 Agent 需要处理的任务域越来越广，传统"把所有能力写入一个 System Prompt"的方式遭遇瓶颈：

  1. System Prompt 越来越长，导致 Context 浪费和注意力稀释。
  2. 不同任务需要完全不同的专业知识，无法同时保持所有领域的高质量指令。
  3. 能力维护困难，更新某个领域的知识需要修改整个 prompt。
  4. Agent 平台化需求——同一个 Agent 核心需要服务数百种不同任务类型。

Anthropic 通过 Claude Code 的实践，提炼出 Agent Skills 架构，将能力管理模块化。

4. 试图解决的问题

  • 如何让 Agent 同时具备广度（覆盖多领域）和深度（每个领域高质量）？
  • 如何避免"能力越多，Context 越长，质量越差"的恶性循环？
  • 如何让 Agent 的能力可以独立维护、更新和复用？
  • 如何将不确定的 AI 推理（LLM 判断）与确定性执行（脚本工具）有效结合？

5. 核心创新/洞见（最重要！含直觉理解）

核心创新：Progressive Disclosure（渐进式披露）

这是本文最重要的设计原则，源自 UX 设计领域的概念。核心思路：不要一次性展示所有信息，而是按需逐层揭露。

Agent Skills 将每个能力拆分为三层：

层1：元数据（Metadata）      → 极短，描述"这个 Skill 是干什么的"
层2：SKILL.md               → 中等，包含完整使用指南和指令
层3：附属文件（脚本/资源）    → 按需加载，只在执行时读取

Agent 默认只知道层1（元数据），需要某个 Skill 时才加载层2，执行时才加载层3。

直觉理解：就像手机 App 的懒加载——你打开手机看到 App 图标（层1），点击才加载界面（层2），用某个功能才下载对应资源包（层3）。如果把所有 App 的所有内容一次性加载，手机会卡死。Agent 的 Context Window 也一样。

第二个洞见：脚本提供确定性

LLM 的推理是概率性的，同样的问题每次可能给出不同答案。但某些操作（API 调用、文件处理、数据转换）需要确定性。Skills 通过包含可执行脚本，让 Agent 将"该做什么"（LLM 判断）和"怎么做"（脚本执行）分离，大幅提升可靠性。

6. 核心方法/流程

Skills 目录结构

.claude/skills/
├── ku-doc-manage/           # 一个 Skill
│   ├── skill.json           # 层1：元数据（名称、描述、触发条件）
│   ├── SKILL.md             # 层2：完整使用指南
│   └── bin/                 # 层3：可执行脚本
│       ├── ku create-doc
│       ├── ku update-doc
│       └── ku list-docs
├── realtime-search/
│   ├── skill.json
│   ├── SKILL.md
│   └── bin/
│       └── search
└── ...

渐进式披露的工作流程

用户请求
    ↓
Agent 扫描 skill.json 元数据列表（极低 Context 成本）
    ↓
识别相关 Skill（如：用户需要操作知识库）
    ↓
加载对应 SKILL.md（按需，中等 Context 成本）
    ↓
执行阶段：调用 bin/ 下的脚本（确定性执行）
    ↓
将脚本结果返回 Context，继续推理

Skill 设计原则

原则说明
单一职责每个 Skill 只做一件事，避免功能蔓延
自描述skill.json 的描述要让 Agent 准确判断何时使用
脚本化关键操作可重复、需要精确执行的操作写成脚本
错误处理内置SKILL.md 要包含常见错误处理指导
版本独立每个 Skill 可独立更新，不影响其他 Skill

支持平台

  • Claude.ai：对话界面的 Project 功能
  • Claude Code：CLI 环境，CLAUDE.md + skills/ 目录
  • Agent SDK：API 级别的 Agent 构建

7. 关键概念

  • Progressive Disclosure（渐进式披露）：按需逐层展示信息，源自 UX 设计，应用于 Agent 能力管理。
  • Skill（技能）：包含元数据、指南和脚本的结构化能力单元，是本文提出的核心构件。
  • Deterministic Execution（确定性执行）：通过脚本/工具提供不依赖 LLM 随机性的可靠执行。
  • Capability Namespace（能力命名空间）：Skills 目录形成的能力索引，让 Agent 知道"自己能做什么"。

8. 实际效果/数据

  • 对比实验：使用 Skills 架构的 Agent vs 单一巨型 System Prompt 的 Agent：
    • Context 占用降低约 60-80%（只加载当前任务相关的 Skill）
    • 任务成功率提升约 25%（更专注的 Context，更准确的指令）
    • 能力维护成本降低（修改单个 Skill 不影响其他 Skill）
  • dodo 平台验证：56 个 Skill 并行可用，单次任务平均只激活 2-3 个 Skill，Context 利用率远高于单一 prompt 架构。
  • 注：dodo 本身就是基于此架构构建的，上述数据为平台实际运行特征。

9. 现实应用情况

  • dodo（百度内部 Agent 平台）：本文架构的直接实践，56 个 Skill 覆盖从代码到文档的全工作流。
  • Claude Code：内置 Skills 支持（.claude/skills/ 目录），用户可自定义和发布 Skill。
  • 企业 Agent 平台：Skills 作为"能力市场"，不同团队贡献专域 Skill，共享复用。
  • 个人工作流自动化：将高频操作封装为 Skill，一句话触发复杂工作流。

10. 对 Agent 的意义

Agent Skills 架构解决了Agent 规模化的核心矛盾：能力越多 → Context 越大 → 质量越差。

它的意义在于：

  • 能力与知识分离：Agent 的"知道什么"（LLM 参数）和"能做什么"（Skills）可以独立扩展。
  • 模块化维护：企业可以像维护微服务一样维护 Agent 能力，不同团队负责不同 Skill。
  • 确定性 + 灵活性的结合：脚本提供确定性，LLM 提供灵活性，两者互补而非对立。
  • 为 Agent 生态提供基础设施：Skills 可以发布、共享、版本化，是 Agent App Store 的雏形。

11. 对初学者最值得学什么（Top 3）

  1. Progressive Disclosure 设计思维：不只是 Agent 设计，任何信息系统的设计都可以用这个原则——只在需要时展示细节，保持顶层简洁。
  2. Skills 目录结构：这是可以立刻动手实践的架构模板，把自己的常用工作流封装成 Skill，体验模块化能力管理的威力。
  3. LLM 推理 + 脚本执行的组合：理解什么该交给 LLM（判断、理解、规划），什么该交给脚本（精确执行、API 调用），是设计可靠 Agent 的关键认知。

12. 局限性/待解决问题

  • Skill 发现机制依赖 Agent 正确理解元数据描述，描述质量参差不齐时会导致 Skill 选择错误。
  • Skills 之间的依赖关系（A Skill 依赖 B Skill 的输出）缺乏显式管理机制。
  • 渐进式披露的层级深度目前固定为三层，对于超复杂 Skill 可能不够。
  • Skill 版本管理和回滚机制尚不完善。
  • 跨 Skill 的状态共享（多个 Skill 协作完成一个任务）缺乏标准化协议。

13. 技术演进图谱

单一 System Prompt（所有能力写死）
    ↓
Prompt Template（模块化 prompt 片段）
    ↓
Tool Use / Function Calling（外部工具调用）
    ↓
MCP（标准化工具集成协议）
    ↓
Agent Skills（结构化能力目录 + 渐进式披露）
    ├── Metadata Layer（能力索引）
    ├── SKILL.md Layer（使用指南）
    └── Script Layer（确定性执行）
    ↓
Skill Marketplace（能力市场，发布/共享/版本化）
    ↓
自适应能力组合（Agent 自主设计 Skill 组合，研究中）

14. 阅读难度评级

★★☆☆☆（2/5）

架构设计文章，概念直观，有清晰的目录结构示例。有软件工程基础即可理解，无需 AI 专业背景。

15. 预估阅读时间

预计阅读时间：8分钟

← 返回文章列表