上一页显示了如何让代理执行操作 — 调用函数、查询 API、搜索 Web。 但是，当你生成更多代理时，会出现一种模式：相同的工具、指令和参考材料群集一起显示。 “提交支出报告”功能不仅仅是一个工具，它是一个验证脚本、一组策略文档、有关如何填写表单的分步说明以及有关支出限制的知识。 最终，这个包会在代理之间被复制粘贴，并逐渐失去同步。
技能 可解决此问题。 技能是一个可移植包，可将指令、参考资料和可选脚本捆绑到任何代理可按需发现和加载的单个单元中。 技能遵循 开放规范 ，使其可在代理、团队甚至产品之间重复使用。
何时使用此项
在以下情况下向代理添加技能：
- 你有一 个相关知识（ 说明、参考文档和脚本）的群集，这些知识在逻辑上属于一起（例如“费用报告”或“代码评审指南”）。
- 多个代理 需要相同的域专业知识，并且需要一个事实来源，而不是重复的指令。
- 你想要以独立包的形式跨团队、项目或组织 共享和分发 代理功能。
- 你需要 有效地管理上下文 — 技能使用渐进式披露，以便代理仅在需要时加载所需的详细信息。
注意事项
| 注意事项 | 详细信息 |
|---|---|
| 可 重用 | 技能是一个自成一体的模块。 创建后，任何代理人都可以选取它 — 无需复制粘贴，也不存在副本间的偏移。 |
| 上下文效率 | 技能使用渐进式披露：代理首先会看到简短说明（约 100 个标记），并且只有在必要时才加载完整说明。 当不需要技能时，它会让上下文窗口保持简洁。 |
| 抽象成本 | 技能在工具之上添加抽象层。 对于单个独立函数工具，添加技能包装器是不必要的开销。 |
| 设计工作 | 你需要提前考虑技能边界：属于技能内的内容以及留在外部的内容。 糟糕的界限导致技能过于宽泛（浪费上下文）或太窄（失去捆绑的好处）。 |
技能与工具有何不同
工具和技能是互补的，而不是竞争的。 了解区别有助于决定何时选择。
工具是单个可调用操作 ， 一个具有名称、说明和参数架构的函数。 当模型确定工具时，它会生成结构化调用，代理框架将执行该工具，结果返回到模型。 工具是代理行为的原子。
技能是一系列领域专业知识。 它可以包括：
- 说明 - 分步指导、决策规则和示例，告知代理 如何处理 域。
- 参考资料 - 策略文档、常见问题解答、模板和其他知识，代理可按需咨询。
- 脚本 - 代理可以运行的可执行代码来执行特定操作（例如，根据策略规则检查费用数据的验证脚本）。
主要区别在于范围之一：工具使代理能够执行 一个操作;技能为代理提供处理 整个域的知识和资源。
| 工具 | 技能 | |
|---|---|---|
| 它提供的内容 | 单个可调用操作 | 说明 + 参考资料 + 可选脚本 |
| 代理如何使用它 | 在需要采取行动时调用它 | 遇到相关任务时加载它，读取说明，并可以调用脚本或咨询资源 |
| 上下文成本 | 工具模式总是显示在提示中 | 只有技能名称和说明（约 100 个令牌）处于提示中;按需加载完整内容 |
| 可移植性 | 绑定到注册该对象的代理 | 任何兼容的代理都可以发现的自包含包 |
| 最适用于 | 单个操作（查询数据库，发送电子邮件） | 域专业知识（费用策略、代码评审准则、载入过程） |
小窍门
将工具视为动词（搜索、预订、验证），技能视为专业知识（旅行预订知识、费用政策知识）。 代理使用工具来操作和技能来了解如何操作。
技能的工作原理：渐进式披露
技能设计为在上下文中高效。 技能采用三阶段模式，而不是在一开始就把所有内容都注入到提示中。
┌──────────────────────────────────────────────────────────────────┐
│ Stage 1: Advertise │
│ Agent sees skill names and descriptions (~100 tokens each) │
│ in its system prompt at the start of every run. │
└──────────────┬───────────────────────────────────────────────────┘
▼ (task matches a skill's domain)
┌──────────────────────────────────────────────────────────────────┐
│ Stage 2: Load │
│ Agent calls load_skill to get the full instructions │
│ (< 5000 tokens recommended). │
└──────────────┬───────────────────────────────────────────────────┘
▼ (agent needs more detail)
┌──────────────────────────────────────────────────────────────────┐
│ Stage 3: Read resources │
│ Agent calls read_skill_resource to fetch supplementary files │
│ (FAQs, templates, reference docs) only when needed. │
└──────────────────────────────────────────────────────────────────┘
该模式意味着拥有 10 个注册技能的代理需要支付大约 1,000 个令牌的上下文开销，而不是 50,000 个。 代理仅在当前任务要求时加深其知识。
此外，技能是基于工具基础结构构建的。 代理框架在代理的系统提示中展示可用的技能，然后将 load_skill 和 read_skill_resource 作为工具调用公开给代理，以便逐步加载内容。
小窍门
有关技能结构、设置和代码示例的完整详细信息，请参阅 代理技能 参考。
何时使用技能与其他模式相比
随着代理变得更为强大，您有多种方式来组织其行为。 以下是技能与工具的比较方式：
| 图案 | 最适用于 | 示例 |
|---|---|---|
| 单个工具 | 不需要共享上下文的一次性操作 |
get_weather 函数工具 |
| 技能 | 包含说明、参考和可选脚本的领域专业知识 | 包含策略文档、验证脚本和分步归档说明的“费用报告”技能 |
常见错误
| 陷阱 | Guidance |
|---|---|
| 过度广泛的技能 | 一种名为“财务万事通”的技能，试图涵盖会计、税务、费用报告和薪资单，但其说明会过于冗长且缺乏重点。 使技能专注于一个领域。 |
| 跳过安全评审 | 技能说明将注入代理的上下文中，脚本执行代码。 像第三方依赖项一样对待技能 — 在部署之前查看它们。 请参阅技能参考中的 安全最佳做法 。 |
| 忽略渐进式披露 | 如果 SKILL.md 长度为 2,000 行，则代理在加载技能时会支付大量上下文处理成本。 请保持说明简洁，并将详细的参考资料移动到单独的资源文件，以充分利用渐进式披露。 |
后续步骤
代理拥有工具和技能后，下一步是添加 中间件 — 交叉行为，例如防护栏、日志记录和应用于每个交互的内容筛选，而无需修改代理的核心逻辑。
更深入：