Agent Skills：让智能体掌握真实任务 SOP 的机制

AI Agent 正在从“能回答问题”走向“能完成工作”。但一个智能体能聊天，并不代表它能立刻处理真实业务任务。

真实任务通常不只是问答，而是包含流程、文件、工具、模板、权限、数据位置和组织习惯。一个大语言模型（LLM，Large Language Model，大语言模型）即使推理能力很强，如果不知道“事情应该按什么步骤做”，也不知道“需要的资料放在哪里”，执行效果仍然会不稳定。

Agent Skills 解决的正是这个问题：把某类任务需要的过程知识、脚本和资源整理成可发现、可加载、可复用的能力包，让智能体在合适的时机读取它们，并按照任务 SOP 完成工作。

Agent 做真实任务时缺什么

可以把 Agent 想象成一个很聪明的新员工。它理解能力强，能读文档、写代码、调用工具，但刚进公司时仍然会卡在两个地方。

这两个缺口对应的是“会不会做”和“知不知道用什么材料做”。

flowchart LR
    A[真实任务] --> B{Agent 是否具备任务上下文}
    B -->|缺少过程知识| C[不知道步骤、规则和检查点]
    B -->|缺少组织背景| D[不知道模板、配置和资料位置]
    C --> E[执行不稳定]
    D --> E
    E --> F[需要 Skill 补足任务能力]

仅靠系统提示把所有流程都塞给模型并不现实。团队里的任务越多，流程越复杂，提示词就越长；上下文窗口被大量低频信息占用后，模型反而更难抓住当前任务真正需要的内容。

Skill 的思路不是一次性灌入全部知识，而是在任务需要时再加载相关能力。

Skill 是什么

Skill 可以理解为 Agent 使用的任务 SOP 包。它通常是一个结构化文件夹，里面放着完成某类任务所需的说明、脚本和资源。

一个 Skill 由三类内容组成：

一个典型的目录可以长这样：

skills/
  generate-business-report/
    SKILL.md
    scripts/
      build_chart.py
      validate_data.py
    resources/
      report_template.pptx
      style_guide.json
      sample_input.csv

其中 SKILL.md 是入口文档，负责告诉 Agent 这个 Skill 适合什么任务、该怎么用、什么时候需要调用脚本、输出应该满足哪些要求。脚本负责执行确定性强的步骤，资源负责提供组织内约定好的模板和配置。

比如“生成业务汇报 PPT”这个任务，如果只给 Agent 一个目标，它可能会自由发挥版式、字段和结构；如果配上 Skill，它可以读取公司模板、遵守固定章节顺序，并用脚本校验数据格式。这样做不是让模型变得更聪明，而是让它少猜、多按规则做。

Skill 如何补上 Agent 的两个能力缺口

Skill 的三类内容，刚好对应 Agent 在真实任务中的两个短板。

flowchart TB
    A[Agent Skills] --> B[Instructions 指令]
    A --> C[Scripts 脚本]
    A --> D[Resources 资源]

    B --> E[补充过程知识]
    C --> E
    D --> F[补充组织背景]

    E --> G[知道任务怎么做]
    F --> H[知道材料在哪里]
    G --> I[更稳定地完成真实任务]
    H --> I

指令和脚本主要解决“怎么做”的问题。指令描述流程、判断条件和输出标准；脚本把复杂或重复的动作固化下来，减少模型手工操作导致的不一致。

资源主要解决“用什么做”的问题。模板、配置文件、示例数据和内部规范都可以放进 Skill，让 Agent 不必把组织信息记在模型参数里，也不必每次从零询问。

这种设计的价值在于，Skill 把任务能力从模型本身拆了出来。模型负责理解任务和决策，Skill 负责提供可执行的流程和上下文。

渐进式披露：需要时才加载

Skill 的关键机制是动态发现和加载，而不是把所有任务说明都写进系统提示。

这种方式被称为渐进式披露（Progressive Disclosure）：Agent 先看到一份简短的 Skill 索引，知道自己有哪些能力可用；当任务需要某个 Skill 时，再读取对应的详细说明、脚本和资源。

flowchart LR
    A[用户任务] --> B[LLM 判断任务类型]
    B --> C[查看可用 Skill 索引]
    C --> D{是否匹配某个 Skill}
    D -->|是| E[读取对应 SKILL.md]
    E --> F[按指令加载脚本和资源]
    F --> G[调用 Tool 执行任务]
    G --> H[生成结果]
    D -->|否| I[使用通用能力处理或请求更多信息]

这种机制有几个直接好处：

所谓“近似无限上下文”，不是说模型真的拥有无限窗口，而是大量任务知识不必常驻上下文。它们可以存放在文件系统里，需要时再被读取进来。

Skill 在系统架构中的位置

Skill 同时涉及两个层面：Agent 的配置层和执行环境。

这张架构图表达的是：LLM 位于 Agent 的配置侧，负责理解任务、选择 Skill 和决定下一步动作；Skill 的实体文件位于 Agent 虚拟机侧，和 Bash、Python、文件系统等执行能力放在一起。

可以把左侧看成“大脑”，右侧看成“电脑和双手”。

当 LLM 判断某个任务需要使用 PDF 处理 Skill 时，它不会凭空知道完整步骤，而是通过工具去读取虚拟机里的文件，例如：

cat skills/pdf/SKILL.md

读取到的内容进入 LLM 上下文后，模型再根据说明决定是否继续读取模板、执行脚本，或者调用其他工具。

完整调用过程可以表示为：

sequenceDiagram
    participant U as 用户
    participant L as LLM
    participant T as Tool
    participant V as Agent 虚拟机
    participant S as Skill 文件

    U->>L: 提交任务
    L->>L: 判断需要哪类能力
    L->>T: 请求读取 Skill 入口文档
    T->>V: 执行文件读取命令
    V->>S: 读取 SKILL.md
    S-->>V: 返回指令内容
    V-->>T: 返回读取结果
    T-->>L: 写入上下文
    L->>T: 按 Skill 指令调用脚本或工具
    T-->>L: 返回执行结果
    L-->>U: 输出最终结果

这里有一个重要边界：Skill 本身不是执行引擎。它提供的是流程、代码和资源；真正执行命令、运行脚本、访问文件系统的仍然是 Tool 和虚拟机。

Skill 和 Tool 的区别

Skill 和 Tool 经常被放在一起讨论，但它们解决的问题不同。

Tool 回答的是“我能做什么”。比如读文件、运行 Bash、调用搜索接口、访问数据库、生成图片，这些都是可被调用的原子能力。

Skill 回答的是“我应该怎样把这些能力组合起来，把某件事做好”。它描述流程、约束、模板、检查点和资源位置。

一个直观类比是：

• Tool 像烤箱，可以加热食物，但不会告诉你怎么做烤鸡。
• Skill 像烤鸡食谱，说明温度、时长、腌制方式和检查方法，但它自己不会发热。
• Agent 根据 Skill 的说明去使用 Tool，才能把任务完整做出来。

所以 Skill 不是 Tool 的替代品。没有 Tool，Skill 只能停留在说明层；没有 Skill，Tool 虽然能执行动作，但 Agent 仍然缺少完成复杂任务的流程知识。

一个 Skill 可以怎么写

为了让 Skill 真正可用，入口文档要写得像给 Agent 的操作手册，而不是像给人看的长篇说明。它需要明确任务适用范围、输入要求、执行步骤、脚本调用方式和输出标准。

示例结构：

# 业务周报生成 Skill

## 适用场景

当用户要求根据 CSV 数据生成业务周报，并输出为 PPTX 时使用。

## 输入要求

- 必须提供业务数据 CSV 文件
- CSV 至少包含 date、channel、revenue、cost 四列
- 如果缺少字段，需要先向用户确认，不能自行猜测

## 执行步骤

1. 使用 scripts/validate_data.py 校验 CSV 字段和数据类型
2. 使用 scripts/build_chart.py 生成趋势图和渠道对比图
3. 使用 resources/report_template.pptx 作为 PPT 模板
4. 按照 resources/style_guide.json 中的颜色和字体规范填充内容
5. 生成 PPTX 后，检查页数、标题和图表是否完整

## 输出要求

- 返回生成文件路径
- 简要列出使用的数据范围
- 如果校验失败，返回具体字段和失败原因

对应的目录可以是：

skills/weekly-business-report/
  SKILL.md
  scripts/
    validate_data.py
    build_chart.py
  resources/
    report_template.pptx
    style_guide.json

脚本可以承担数据校验这种确定性强的工作：

# scripts/validate_data.py
import csv
import sys

REQUIRED_COLUMNS = {"date", "channel", "revenue", "cost"}

def validate(path: str) -> None:
    with open(path, newline="", encoding="utf-8") as f:
        reader = csv.DictReader(f)
        columns = set(reader.fieldnames or [])

    missing = REQUIRED_COLUMNS - columns
    if missing:
        raise ValueError(f"CSV 缺少字段: {', '.join(sorted(missing))}")

if __name__ == "__main__":
    validate(sys.argv[1])
    print("数据字段校验通过")

Agent 使用这个 Skill 时，不需要自己逐行猜测 CSV 格式，而是按说明调用脚本。这样可以把“判断字段是否齐全”这类稳定规则交给代码完成，把“如何解释结果、如何组织汇报语言”留给模型处理。

设计 Skill 时要注意什么

Skill 的目标是让 Agent 更稳定地完成特定任务，但写得不好也会引入新问题。

一个好的 Skill 通常满足四个条件：

1. 边界清楚：Agent 能判断什么时候该用，什么时候不该用。
2. 步骤明确：任务流程不是一句目标描述，而是可执行的检查清单。
3. 资源可定位：模板、配置、示例文件都能通过稳定路径找到。
4. 脚本可复用：重复、确定、容易出错的动作尽量交给脚本。

Skill 适合哪些场景

Skill 特别适合那些“流程固定，但每次输入不同”的任务。

判断一个任务是否值得做成 Skill，可以问三个问题：

flowchart TD
    A[任务是否经常重复] -->|否| B[直接让 Agent 处理]
    A -->|是| C[流程是否相对固定]
    C -->|否| B
    C -->|是| D[是否依赖模板、脚本或组织资料]
    D -->|否| E[可以写轻量指令]
    D -->|是| F[适合做成 Skill]

只要任务频繁出现、流程稳定、依赖特定资源，就适合沉淀成 Skill。这样做可以减少重复提示，让 Agent 每次按同一套规则执行。

核心结论

Agent Skills 的本质，是把“怎么做事”的知识从一次性提示里拆出来，整理成可发现、可加载、可执行的任务能力包。

它由指令、脚本和资源组成：

• 指令告诉 Agent 流程和规则；
• 脚本处理稳定、重复、确定性强的步骤；
• 资源提供模板、配置和组织上下文。

Tool 提供底层执行能力，Skill 提供使用这些能力的 SOP。Agent 通过渐进式披露机制，在需要时读取相关 Skill，再调用 Tool 完成任务。

当 Agent 从聊天助手走向真实工作流时，关键不只是模型参数有多强，还包括它能否在正确时间拿到正确流程、正确工具和正确资料。Skill 提供的正是这套任务级上下文。