Agents Skills入门

目录

Agents Skills的价值

Agent Skills 的最大价值是：把「能力」从模型里剥离，变成可治理、可组合、可演进的系统单元。
把 Agent 从「语言模型驱动」升级为「能力编排系统」。

例子：做智能客服Agent，实体抽取、意图识别是内部实现细节
Agent（LLM）并不知道：有哪些能力，什么时候该用，能不能组合，扩展能力 = 改代码 + 改流程

有 Agent Skills 的做法
每个 skill 都有：明确的能力描述,输入 / 输出 schema,适用条件,可调用接口；
能力是可被 Agent 调度的资源，哪些 skill 要被调用，是由大模型参与识别并给出决策建议，再由 Agent 执行调度。

维度 传统业务逻辑 Agent Skills
是否有逻辑 ✅ ✅
是否有代码 ✅ ✅
是否模块化 有，但面向工程师 有，且面向 agent
能力是否显式 ❌ 隐含在流程中 ✅ 显式声明
是否可发现 ❌ ✅
是否可组合 ❌（靠代码改） ✅（靠调度）
是否可治理 ❌ ✅

工程实践上的好处采用渐进式披露：

  • 减少上下文消耗：仅加载任务所需的2-3项技能，而非全部可用技能
  • 赋能团队自主性：不同团队可独立开发专业技能
  • 高效扩展：添加数十或数百项技能而不致上下文过载

要不要我帮你把这些要点整理成一份渐进式披露方案要点清单，方便你在文档或会议中直接使用？

Agent Skills定义

“Agent Skills are folders of instructions, scripts, and resources that agents can discover and use to do things more accurately and efficiently.”
Agent Skills 是一类包含指令、脚本和资源的集合，agent 可以发现并使用它们，从而更准确、高效地完成任务。

agent 不用事先硬编码这些技能，它可以 发现（自动找到）并 使用 这些技能来完成任务。
比如，当 agent 需要生成报表，它可以自动找到相关的 Skill 来完成数据查询、格式化、生成 PDF 等操作。

instructions：指令

告诉 agent 如何执行某些操作

instructions：指令，告诉 agent 如何执行某些操作

举个例子：

假设 agent 的任务是 给客户生成 PDF 报告。

  1. Instruction 示例（文本形式）：
Instruction: 
1. 从数据库获取客户交易数据。
2. 将数据按月汇总。
3. 插入图表和表格。
4. 生成 PDF 文件并命名为 "客户姓名_月度报告.pdf"。
5. 将 PDF 发送到客户邮箱。

这里的每一条都是 instructions，告诉 agent 具体做什么、顺序是什么。

  1. agent 如何使用：
  • agent 读取 instruction 中的步骤
  • 自动执行每一步：先抓数据 → 再生成图表 → 最后发邮件
  • 如果 instruction 有明确规则，agent 就能准确高效完成任务，不容易出错。

指令 vs workflow

Instruction 是原子动作，Workflow 是原子动作的组合流程。

特性 Instruction（指令） Workflow（工作流）
粒度 单步操作 多步组合
作用 告诉 agent 怎么做 告诉 agent 做哪些事、顺序如何
独立性 可以独立执行 依赖多条 instruction 才完整
例子 “生成 PDF” “抓取数据 → 生成报表 → 发邮件”

例子：

  • Workflow: “生成客户月度报告并发送给客户”

    1. Instruction: “抓取客户交易数据。”
    2. Instruction: “按月汇总数据并生成表格。”
    3. Instruction: “生成 PDF。”
    4. Instruction: “发送到客户邮箱。”

  • 这个 workflow 把多个 instruction 串起来，形成完整流程。

scripts

脚本，可以自动执行具体任务。

  • Scripts = 一段可执行的程序/指令序列
  • 它告诉 agent “按顺序执行某些操作”
  • 不局限于某种语言，也可以是 Python、JavaScript、Shell、甚至低代码工具的可执行流程

Agent 的脚本作用是让 agent 自动化执行任务，不管语言

  • 例子：

    • Python 脚本：抓取数据、处理表格、生成报告
    • Shell 脚本：批量移动文件、重命名文件
    • JavaScript：操作网页数据、调用 API
    • JSON/配置脚本：定义任务流程（低代码环境里）

resources：资源

  • Resources → 支持执行的所有辅助资料，不仅仅是模板文件，还包括：

    1. 模板文件（Templates）

      • 例如 Word、Excel、PDF 模板，用来生成报告或文档

    2. 数据文件（Data files）

      • 客户列表、历史数据、配置文件

    3. 参考文档 / 配置 / 字典（Other references）

      • 公式表、术语表、规则文件等

明白了，我们来详细讲讲 数据文件、参考文档 / 配置 / 字典 在 Agent Skills 中具体是怎么被 agent 使用的。

1️⃣ 数据文件（Data files）

作用：提供实际内容，让 agent 可以生成结果或执行计算。

例子：生成月度报告

文件类型 内容 agent 如何用
CSV / Excel 客户数据 每个客户的交易记录 Script 读取数据，汇总计算销售额、利润等
JSON / 数据库导出 客户信息、产品信息 Instruction 指示 agent 按规则抓取字段，生成报表

执行方式：

  1. agent 读取文件内容
  2. 根据 instruction 或 script 提取需要的字段
  3. 处理数据 → 填入模板 → 输出结果

2️⃣ 参考文档（Reference docs）

作用：提供业务规则、标准、模板说明或背景信息，帮助 agent 做出正确判断。

例子：

  • PDF / DOCX 文件：包含公司 KPI 定义或报表格式要求
  • 术语表：告诉 agent “Revenue = 销售额 + 服务费”

执行方式：

  • agent 在生成报表或内容时，查阅这些文档，确保数据计算或文本输出符合规范

3️⃣ 配置文件（Config files）

作用：定义任务执行的参数或规则，让 agent 可复用、可自定义。

例子：

  • JSON / YAML 配置：报告输出路径、文件命名规则、邮件模板、数据筛选条件
  • Script 读取配置文件，而不是硬编码每次都改代码

执行方式：

  1. agent 读取配置文件参数
  2. Script 按配置执行操作
  3. 这样可以在不同任务或客户之间复用同一套 instruction + script

4️⃣ 字典（Dictionary / Lookup tables）

作用：提供映射关系或标准化数据，让 agent 统一处理不同格式或类别的数据。

例子：

  • 客户等级字典：
  • 产品分类字典：把不同名称映射到标准分类

执行方式：

  • Script 遇到“高端客户” → 查字典得到标准代码
  • Agent 输出报表时用统一的分类或代码，保证格式和统计口径一致

✅ 总结使用方式

Instruction: 定义任务步骤
Script: 执行任务逻辑
Resources:
   - Template: 填充数据生成报告格式
   - Data file: 提供实际内容
   - Reference doc: 提供规则/标准
   - Config: 定义参数/路径/条件
   - Dictionary: 标准化/映射数据

Agent 的工作流程就是：读取 instruction → 调用 script → 使用 resources → 生成结果

如果你愿意，我可以画一张 模板 + 数据 + 参考文档 + 配置 + 字典在 Agent 执行任务中的关系图，直观地展示每种资源的用途。

你希望我画吗？

流程图

┌─────────────────────────────┐
│         任务需求(Task)       │
│  例如：生成客户月度报告       │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   发现可用资源(Discover)     │
│  - Instruction 文件           │
│  - Scripts 文件               │
│  - Templates / 数据 / 配置     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   匹配资源(Match)            │
│  选择与任务对应的 instruction │
│  选择执行该 instruction 的 script │
│  选择需要的模板或数据          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   执行资源(Execute)          │
│  1️⃣ 按 instruction 步骤执行   │
│  2️⃣ 调用对应 script 自动化执行 │
│  3️⃣ 使用模板/数据生成最终结果 │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   输出结果(Output)           │
│  生成报告、发送邮件等          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   反馈(Feedback / Optimize) │
│  记录执行结果，优化下次资源调用 │
└─────────────────────────────┘

✅ 说明：

  • Instruction：告诉 agent 每一步要做什么

  • Script：agent 执行操作的程序代码

  • Template/Other Resources：辅助执行，提供数据或格式。在 Agent Skills 里的 Template / Other Resources，主要作用就是 辅助 agent 执行任务，而生成报告时用到的 格式模板 就是典型例子。

  • Workflow（虽然没画成独立框）：就是把 instruction + script + template 按顺序组合成端到端流程

Agents Skills跟RAG结合

简短结论先给出：

不必须 100% 按这个目录结构来；这是一个“约定结构（convention）”，不是“强制规范（hard spec）”。可以扩展，也可以把 skill 放进 RAG，但要清楚“谁负责发现、谁负责执行”。

下面我分层说清楚。

1️⃣ 这个目录结构本质是什么？

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

这是一个对 Agent 友好的 Skill 封装约定，解决 3 个问题：

  1. 可发现性（discoverable）
    Agent 或 Skill Registry 一看就知道：

    • 这是一个 skill
    • 入口在哪（SKILL.md）

  2. 可理解性（understandable）

    • instructions 在哪
    • 能不能执行代码
    • 有哪些参考资料 / 模板

  3. 可执行性（executable）

    • scripts 能直接跑
    • assets 能直接用

👉 本质：让 agent “少推理，多复用”

2️⃣ 哪些是“强约定”，哪些是“弱约定”？

✅ 几乎是强约定的

SKILL.md

  • Skill 的入口

  • 描述：

    • 这个 skill 能干什么
    • 什么时候用
    • 输入 / 输出
    • 调用规则

👉 没有它，agent 很难“发现并正确使用”

⚠️ 其他目录是弱约定（可以变）

目录 是否必须 说明
scripts/ ❌ 没代码就不需要
references/ ❌ 没文档就不需要
assets/ ❌ 没模板/资源就不需要

👉 Agent 只关心：有没有资源 + 怎么用，不关心你文件夹叫什么名字

3️⃣ 那能不能“扩展结构”？——可以，而且很常见

常见扩展例子

my-skill/
├── SKILL.md
├── scripts/
├── assets/
├── schemas/          # JSON schema / 输出结构
├── prompts/          # 子 prompt / 子 instruction
├── tests/            # 行为测试
└── evals/            # skill 评估用例

只要在 SKILL.md 里说明清楚：

“schemas/ contains output validation schema”
“prompts/ contains reusable sub-instructions”

agent 就能用。

👉 Skill 的“协议”在 SKILL.md，不在目录名

4️⃣ 重点问题：Skill 能不能放进 RAG？

✅ 能，但角色不一样

这是关键区别：

放哪里 Agent 如何使用 适合什么
Skill folder 直接执行 自动化、确定性流程
RAG 检索 + 推理 知识密集、规则多变

两种典型模式（非常重要）

🔹 模式 A：Skill + RAG（推荐）

Skill
 ├─ instructions（流程）
 ├─ scripts（执行）
 └─ references → 来自 RAG
  • Skill 定义 怎么做
  • RAG 提供 做的时候要查什么

📌 你之前提到的：

“引用国标 / 安全检测报告”

👉 国标 = RAG
👉 生成报告流程 = Skill

这是工业级 Agent 的标准做法

🔹 模式 B：Skill 本身存在 RAG（不推荐单独用）

  • 把 skill 当成纯文档
  • agent 检索后“照着理解去做”

问题：

  • agent 每次都要重新推理
  • 不可控
  • 不可复用
  • 不稳定

👉 更像 Prompt Library，不是真正的 Skill

5️⃣ 一个非常清晰的判断标准（你可以记住）

能不能“直接执行”，决定它是不是 Skill

内容 放哪里
可执行流程 Skill
稳定规则 / 国标 / 手册 RAG
模板 / schema assets
参数 / 约束 config
业务知识 references 或 RAG

编写注意事项

  • 请注意，代理程序会在决定激活技能时加载整个（skill）文件。建议将较长的SKILL.md内容拆分成多个引用文件。
  • 保持各个参考文件（reference）的简洁性。代理程序按需加载这些文件，因此文件越小，对上下文信息的依赖就越少。
  • 使用skills-ref参考库来验证您的技能：
skills-ref validate ./my-skill

这会检查您的SKILL.mdfrontmatter 是否有效并符合所有命名规则。

https://github.com/agentskills/agentskills/tree/main/skills-ref

FAQ

assets 和 references 目录存放内容的区别

维度 assets/ references/
谁用 Script / Tool Agent / LLM
使用阶段 执行时（execution-time） 推理时（reasoning-time）
是否结构化 通常是 通常不是
是否参与计算 是 否
模板 ✅ ❌
查找表 / schema ✅ ❌
国标 / 规范 ❌ ✅
说明文档 ❌ ✅
posted @ 2026-02-02 10:44  向着朝阳  阅读(8)  评论(0)    收藏  举报