芥末
发布于 2026-04-01 / 0 阅读
0
0

Agent Skills 入门:用可复用技能包封装 AI 任务流程

Agent Skills 是给 AI Agent(Artificial Intelligence Agent,人工智能智能体)准备的标准能力包。它把某个任务需要的流程、规则、脚本、模板和参考资料组织到一个文件夹里,让 Agent 不只是“回答怎么做”,而是能按照既定方法把事情做完。

很多人使用大模型时会遇到一个典型问题:模型通用知识很强,但一进入具体业务场景,就容易缺少上下文、流程不稳定、输出格式不一致。比如让模型“写一份周报”,它能写;但如果要求它遍历本机多个 Git 仓库、读取最近 14 天 commit message、按公司模板整理成周报,还要在没有仓库路径时主动询问用户,单靠一次 Prompt(提示词)就会变得脆弱。

Agent Skills 解决的正是这类问题:把可复用的专业任务流程沉淀成工程资产。

flowchart LR
    A[用户任务] --> B[Agent 理解意图]
    B --> C{是否匹配 Skill}
    C -- 否 --> D[普通对话或通用工具调用]
    C -- 是 --> E[加载 Skill 元数据和主指令]
    E --> F[按需读取 references 模板或规范]
    F --> G[执行 scripts 脚本]
    G --> H[调用外部工具或本地命令]
    H --> I[生成结构化结果]

1. Agent Skills 是什么

Agent Skills 可以理解为一种约定好的目录结构。一个 Skill 通常就是一个文件夹,里面包含:

  • SKILL.md:必需文件,描述技能是什么、什么时候用、怎么执行。
  • scripts/:可选目录,放 Python、Bash、JavaScript 等可执行脚本。
  • references/:可选目录,放规范、模板、领域知识、检查清单等参考资料。
  • assets/:可选目录,放静态资源,例如图片、文档模板、表格示例。

典型目录结构如下:

my-skill/
├── SKILL.md          # 必需:技能描述、使用条件、任务流程、核心指令
├── scripts/          # 可选:可执行脚本,例如 .py、.sh、.js
├── references/       # 可选:参考文档、规则、模板、规范
└── assets/           # 可选:图片、模板文件、示例素材

这种设计的重点不在“文件夹”本身,而在工程化边界:
Prompt 适合表达一次性意图,脚本适合执行确定性操作,参考文档适合承载长规则,而 Skill 把它们打包成一个可安装、可复用、可版本管理的能力单元。

2. SKILL.md 的结构

SKILL.md 是一个 Skill 的入口文件,通常由两部分组成:

  1. YAML(YAML Ain’t Markup Language,一种常用配置格式)元数据。
  2. Markdown 格式的任务说明和执行指令。

示例:

---
name: pdf
description: Comprehensive PDF toolkit for extracting text and tables, merging or splitting documents, and filling forms.
license: Apache-2.0
compatibility: Requires Python 3.10+, poppler-utils, and internet access.
allowed-tools: Bash(pdftotext:*) Bash(python:*) Read
metadata:
  owner: "platform-team"
  version: "1.0.0"
---

# PDF 处理技能

当用户需要提取 PDF 文本、解析表格、拆分文档、合并文档或填写表单时,使用该技能。

## 执行规则

- 提取文本时优先使用 `scripts/extract_text.py`。
- 表格解析失败时,读取 `references/table_extraction_guide.md` 中的回退策略。
- 输出必须包含文件名、页码范围和处理结果摘要。

2.1 必填字段

namedescription 是最核心的字段。Agent 通常会先读取所有已注册 Skill 的元数据,再根据用户任务匹配合适的 Skill。

字段是否必需作用示例
nameSkill 名称,通常要求简短、唯一、便于识别name: weekly_git_report
description说明 Skill 能做什么、适合什么任务,最好包含关键触发词description: Generate weekly reports from recent Git commit messages.
license许可证信息license: Apache-2.0
compatibility运行环境要求Requires git and Python 3.10+
allowed-tools预批准工具列表,用于约束可调用能力allowed-tools: Bash(git:*) Read
metadata自定义元信息,例如版本、维护团队、适用平台version: "1.0.0"

description 写得越准确,Skill 越容易被正确触发。不要只写“处理文档”,而要写清楚“提取 PDF 文本、解析表格、合并或拆分 PDF 文档”,因为 Agent 需要依靠这些关键词判断是否加载该技能。

2.2 可选目录的职责

目录放什么适合承载的内容
scripts/可执行程序Git 日志读取、文件转换、接口请求、数据清洗
references/长文档、规则、模板代码规范、单测规范、周报模板、业务术语表
assets/静态资源表格模板、图片素材、示例文件

一个常见误区是把所有规则都塞进 SKILL.md。这样会让上下文变重,也会增加模型误读的概率。更好的做法是让 SKILL.md 只保留核心流程,把细节规则拆到 references/ 中,等任务真正需要时再读取。

3. 渐进式披露:为什么 Skill 不应该一次性加载所有内容

Agent Skills 的一个关键机制叫 Progressive Disclosure(渐进式披露)。它的思路很简单:先加载最少信息,只有在需要时才加载更多内容。

启动或索引阶段,Agent 只需要读取 Skill 的 namedescription。当用户任务匹配到某个 Skill 后,再读取 SKILL.md 的主体说明。执行过程中,如果发现需要模板、规范或脚本,再按路径加载对应文件。

flowchart TD
    A[Agent 启动] --> B[读取所有 Skill 的 name 和 description]
    B --> C[用户发起任务]
    C --> D{匹配到某个 Skill?}
    D -- 否 --> E[按普通任务处理]
    D -- 是 --> F[加载该 Skill 的 SKILL.md]
    F --> G{需要参考资料?}
    G -- 是 --> H[读取 references 中的指定文件]
    G -- 否 --> I[继续执行]
    H --> I
    I --> J{需要确定性操作?}
    J -- 是 --> K[运行 scripts 中的脚本]
    J -- 否 --> L[生成结果]
    K --> L

这种机制有三个好处:

好处具体含义
控制上下文长度不把无关规范、模板、示例一次性塞给模型
降低干扰当前任务不需要的知识不会影响推理
便于维护长规则可以拆分成多个文件,独立修改和版本管理

SKILL.md 通常建议保持简洁,几百行以内更容易维护。超过这个规模时,应优先拆分到 references/

4. Prompt、MCP 和 Skills 的边界

Agent Skills 经常和 Prompt、MCP 混在一起讨论,但三者解决的问题不同。

MCP(Model Context Protocol,模型上下文协议)负责让模型安全、标准化地连接外部工具,例如数据库、文件系统、浏览器、命令行工具或业务 API(Application Programming Interface,应用程序编程接口)。Prompt 负责表达任务意图。Skills 负责封装完整任务流程。

维度PromptMCPAgent Skills
定位一次性指令工具通信协议标准能力包
主要问题告诉模型要做什么让模型能发现并调用工具让模型按固定方法完成一类任务
粒度对话级工具接口级任务应用级
可复用性低,需要复制粘贴和人工维护中,工具可复用,但流程仍需编排高,流程、脚本、模板整体复用
典型内容角色、目标、输出格式工具名称、参数、权限、返回值SKILL.md、脚本、模板、规范
工程化方式Prompt 模板工具服务文件包、版本控制、安装分发

三者的协作关系可以这样理解:

sequenceDiagram
    participant U as 用户
    participant A as Agent
    participant S as Skill
    participant M as MCP 工具
    participant R as 外部资源

    U->>A: 提出任务
    A->>A: 根据意图匹配 Skill
    A->>S: 加载 SKILL.md
    S->>A: 返回流程、规则、脚本路径
    A->>M: 通过 MCP 调用工具
    M->>R: 访问文件、数据库或 API
    R-->>M: 返回数据
    M-->>A: 返回工具结果
    A-->>U: 输出最终结果

所以,Skills 不是 Prompt 的替代品。一个 Skill 里面通常就包含高质量 Prompt。
Skills 也不是 MCP 的替代品。Skill 可以通过 MCP 调用外部能力,也可以运行本地脚本完成确定性操作。

更准确的关系是:

  • Prompt 表达意图和约束。
  • MCP 提供工具连接能力。
  • Skills 把任务方法论封装成可复用资产。

5. 什么场景适合做成 Skill

并不是所有任务都需要 Skill。判断标准可以围绕“是否重复、是否有流程、是否需要外部资源、是否需要稳定输出”来定。

场景是否适合 Skill原因
临时问一个概念普通对话足够
改写一段短文本通常不需要Prompt 模板就能解决
按团队规范生成单元测试适合有固定规范、文件读取、代码生成流程
从多个 Git 仓库生成周报适合需要扫描目录、执行命令、套模板
财务报税辅助适合领域规则多、流程固定、容错要求高
一次性数据分析实验看情况如果后续会重复执行,可以沉淀成 Skill
调用某个单一 API不一定MCP 工具可能就够,除非还要封装完整流程

Agent Skills 最适合沉淀“专业工作流”,例如:

  • 代码审查 Skill:读取变更、套用团队规范、输出问题列表和修复建议。
  • 单元测试 Skill:分析目标类、读取测试规范、生成测试用例并运行测试。
  • 周报生成 Skill:读取提交记录、归类项目进展、按模板输出。
  • 设计规范 Skill:读取品牌规范、检查页面文案和视觉元素。
  • 数据分析 Skill:读取数据、执行清洗脚本、生成图表和分析报告。

6. 实战:用 Git commit message 生成双周周报

用一个具体例子说明 Skill 的组织方式:根据本地 Git 仓库最近 14 天的 commit message 自动生成双周周报。

目标流程如下:

flowchart TD
    A[用户输入: 生成近双周周报] --> B[匹配 weekly_git_report Skill]
    B --> C[检查代码父目录是否存在]
    C -- 不存在 --> D[询问用户提供 Git 仓库父目录]
    C -- 存在 --> E[遍历一级子目录]
    D --> E
    E --> F[识别包含 .git 的仓库]
    F --> G[执行 git log 获取最近 14 天 commit]
    G --> H[读取周报模板]
    H --> I[按项目归类和总结]
    I --> J[输出周报和 commit 附录]

6.1 目录结构

weekly_git_report/
├── SKILL.md
├── scripts/
│   └── fetch_git_commits.py
└── references/
    └── weekly_report_template.md

6.2 编写 SKILL.md

---
name: weekly_git_report
description: Generate a structured biweekly work report from recent Git commit messages across local repositories. Use this skill when the user asks for weekly report, biweekly report, work summary, Git commit summary, or project progress report.
license: MIT
compatibility: Requires git and Python 3.10+
allowed-tools: Bash(git:*) Bash(python3:*) Read
metadata:
  version: "0.1.0"
---

# 双周 Git 周报生成技能

## 能力范围

基于本地多个 Git 仓库最近 14 天的 commit message,生成结构化双周工作报告。

## 默认输入

- 默认代码父目录:`~/code`
- 如果该目录不存在,询问用户提供 Git 仓库父目录。
- 只扫描代码父目录下的一级子目录。
- 只有包含 `.git` 目录的子目录才视为 Git 仓库。

## 数据获取

使用脚本:

`scripts/fetch_git_commits.py`

脚本输出按项目分组的 commit message。执行时可以传入代码父目录:

```bash
python3 scripts/fetch_git_commits.py --parent-dir ~/code --days 14

报告模板

生成报告时必须参考:

references/weekly_report_template.md

输出要求

  • 按项目归类主要工作内容。
  • 从 commit message 中提炼功能开发、问题修复、重构、测试、依赖升级等事项。
  • 不要凭空编造没有 commit 支撑的工作。
  • 如果没有找到任何 commit,输出“过去两周没有找到 Git 提交记录”,并提示用户检查仓库路径。
  • 报告末尾保留 Git commit message 附录,方便用户核对。

这里有几个关键点:

- `description` 包含 `weekly report`、`biweekly report`、`Git commit summary` 等触发词,方便 Agent 匹配。
- `allowed-tools` 限制可用命令范围,避免 Skill 获得过宽权限。
- 输出规则明确要求“不凭空编造”,因为周报生成很容易被模型补充不存在的工作项。
- 模板路径和脚本路径写清楚,让 Agent 能按需加载。

### 6.3 编写 Git 提交读取脚本

`scripts/fetch_git_commits.py`:

```python
#!/usr/bin/env python3

import argparse
import subprocess
import sys
from datetime import datetime, timedelta
from pathlib import Path


def is_git_repo(path: Path) -> bool:
    """判断目录是否为 Git 仓库。"""
    return (path / ".git").is_dir()


def get_commits(repo_path: Path, days: int) -> list[str]:
    """获取指定仓库最近 N 天的非 merge commit message。"""
    since_date = (datetime.now() - timedelta(days=days)).strftime("%Y-%m-%d")

    try:
        result = subprocess.run(
            [
                "git",
                "log",
                f"--since={since_date}",
                "--pretty=format:%s",
                "--no-merges",
            ],
            cwd=repo_path,
            capture_output=True,
            text=True,
            check=True,
        )
    except subprocess.CalledProcessError as exc:
        print(f"跳过仓库 {repo_path}:git log 执行失败,{exc}", file=sys.stderr)
        return []

    output = result.stdout.strip()
    if not output:
        return []

    return [line.strip() for line in output.splitlines() if line.strip()]


def scan_repositories(parent_dir: Path, days: int) -> dict[str, list[str]]:
    """扫描父目录下一级 Git 仓库,并返回 commit message。"""
    reports: dict[str, list[str]] = {}

    if not parent_dir.exists():
        raise FileNotFoundError(f"代码父目录不存在:{parent_dir}")

    for child in sorted(parent_dir.iterdir()):
        if not child.is_dir():
            continue

        if not is_git_repo(child):
            continue

        commits = get_commits(child, days)
        if commits:
            reports[child.name] = commits

    return reports


def print_reports(reports: dict[str, list[str]]) -> None:
    if not reports:
        print("过去两周没有找到 Git 提交记录。")
        return

    for repo_name, commits in reports.items():
        print(f"### 项目:{repo_name}")
        for commit in commits:
            print(f"- {commit}")
        print()


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument(
        "--parent-dir",
        default="~/code",
        help="代码仓库父目录,默认 ~/code",
    )
    parser.add_argument(
        "--days",
        type=int,
        default=14,
        help="统计最近多少天的 commit,默认 14 天",
    )

    args = parser.parse_args()
    parent_dir = Path(args.parent_dir).expanduser().resolve()

    try:
        reports = scan_repositories(parent_dir, args.days)
    except FileNotFoundError as exc:
        print(str(exc), file=sys.stderr)
        sys.exit(2)

    print_reports(reports)


if __name__ == "__main__":
    main()

脚本把错误信息输出到 stderr,把可供 Agent 处理的数据输出到 stdout。这点很重要:Agent 读取命令结果时,清晰的数据边界能减少解析错误。

6.4 编写周报模板

references/weekly_report_template.md

# 本双周工作周报({{start_date}} 至 {{end_date}})

## 一、主要工作内容

按项目分组,总结最近 14 天完成的功能开发、问题修复、重构优化、测试补充、依赖升级等事项。

示例:

### 1. 项目 A

- 完成 XXX 功能开发。
- 修复 YYY 模块的空指针问题。
- 补充 ZZZ 相关单元测试。

## 二、遇到的问题与解决方案

只从 commit message 中能推断出的内容整理问题和解决方案,不要虚构。

示例:

- 问题:登录过滤器配置不完整。
  解决:更新过滤器配置,并补充相关依赖。

## 三、后续计划

如果 commit message 中无法推断后续计划,可以给出与当前工作自然衔接的待办方向,并标注为“建议”。

## 四、Git commit message 附录

保留原始 commit message,按项目分组列出,方便核对。

模板不需要包含真实业务内容。它只定义结构、约束和示例,实际周报由 Git 数据驱动生成。

6.5 期望输出示例

当用户输入:

帮我生成近双周周报

Agent 匹配 weekly_git_report 后,会执行脚本并读取模板,最终输出类似结果:

# 本双周工作周报(2026-05-24 至 2026-06-07)

## 一、主要工作内容

### 1. order-service

- 完成订单状态同步逻辑调整。
- 修复订单取消场景下库存回滚失败的问题。
- 补充订单查询服务的单元测试。

### 2. admin-web

- 新增运营后台导出任务入口。
- 优化用户列表筛选条件。
- 升级前端构建依赖。

## 二、遇到的问题与解决方案

- 问题:订单取消后库存回滚存在遗漏。
  解决:补充取消流程中的库存回滚分支,并增加回归测试。

## 三、后续计划

- 建议继续补充订单异常状态的测试覆盖。
- 建议检查导出任务在大数据量下的执行耗时。

## 四、Git commit message 附录

### order-service

- fix(order): rollback stock when order is cancelled
- test(order): add unit tests for order query
- refactor(order): simplify status sync flow

### admin-web

- feat(export): add export task entry
- chore(deps): upgrade build dependencies

这种输出不是简单改写 commit message,而是把提交记录转成面向工作汇报的结构化表达,同时保留附录用于追溯。

7. 在 Qoder CLI 中注册 Skill

Claude Code 和兼容 Agent Skills 标准的命令行工具都可以加载 Skill。Qoder CLI(Command Line Interface,命令行界面)支持类似的 Skill 存储结构,常见位置有两类:

类型路径作用范围
个人 Skill~/.qoder/skills/<skill-name>/当前用户所有项目可用
项目 Skill.qoder/skills/<skill-name>/只在当前项目可用

weekly_git_report 放到个人目录:

mkdir -p ~/.qoder/skills
cp -r weekly_git_report ~/.qoder/skills/

目录结果应类似:

~/.qoder/skills/
└── weekly_git_report/
    ├── SKILL.md
    ├── scripts/
    │   └── fetch_git_commits.py
    └── references/
        └── weekly_report_template.md

进入 Qoder CLI 后,可以使用技能列表命令检查是否被识别:

/skills

如果技能已注册,输入自然语言任务即可触发:

帮我生成近双周周报,代码目录是 ~/workspace

完整调用链路如下:

sequenceDiagram
    participant U as 用户
    participant Q as Qoder CLI
    participant S as weekly_git_report
    participant P as Python 脚本
    participant G as Git 仓库

    U->>Q: 帮我生成近双周周报
    Q->>S: 根据 description 匹配 Skill
    S->>Q: 返回执行说明、脚本路径、模板路径
    Q->>P: python3 fetch_git_commits.py --parent-dir ~/workspace --days 14
    P->>G: git log --since=...
    G-->>P: 返回 commit messages
    P-->>Q: 输出按项目分组的提交记录
    Q->>S: 读取 weekly_report_template.md
    Q-->>U: 生成结构化双周周报

8. 工程化注意事项

8.1 不要把 Skill 写成超长 Prompt

SKILL.md 应该像任务入口,而不是一本完整手册。核心流程留在主文件,长规范放到 references/

references/
├── code_review_rules.md
├── unit_test_spec.md
├── report_template.md
└── troubleshooting.md

这样 Agent 在代码审查时读取 code_review_rules.md,生成报告时读取 report_template.md,不会让无关内容污染上下文。

8.2 脚本负责确定性操作,模型负责理解和归纳

适合脚本做的事情:

  • 遍历目录。
  • 执行 git log
  • 解析 JSON(JavaScript Object Notation,一种常见数据交换格式)。
  • 调用固定 API。
  • 生成中间数据文件。

适合模型做的事情:

  • 理解用户意图。
  • 从 commit message 中归类工作内容。
  • 把技术提交转成业务可读表达。
  • 按模板组织语言。

不要让模型猜命令结果,也不要让脚本生成需要复杂语言理解的报告正文。两者分工清楚,Skill 才稳定。

8.3 共享 Skill 前要清理私有信息

Skill 本质上是文件夹,很适合用 Git 管理,也很容易打包分享。但共享前必须检查:

检查项风险
硬编码本机路径其他人无法运行
访问令牌、密钥、Cookie泄露敏感信息
内部域名或业务字段暴露内部系统结构
过宽的命令权限可能执行危险操作
模板中包含真实客户数据数据合规风险

建议用环境变量、配置文件或用户输入替代硬编码路径:

export CODE_PARENT_DIR=~/workspace

8.4 description 要写给 Agent 匹配,不是写给人看

差的描述:

description: A useful report skill.

好的描述:

description: Generate weekly or biweekly work reports from local Git commit messages. Use when the user asks for work summary, weekly report, biweekly report, project progress, or Git commit summary.

后者包含明确任务、数据来源和触发关键词,匹配效果会明显更稳定。

8.5 对外部 Skill 保持最小权限

从社区安装 Skill 时,要像安装命令行工具一样谨慎。重点检查:

  • scripts/ 是否执行网络请求。
  • 是否读取敏感目录,例如 ~/.ssh、浏览器缓存、系统配置。
  • allowed-tools 是否过宽。
  • 是否存在删除文件、上传文件、执行远程脚本等危险行为。

Skill 让 Agent 更会做事,也意味着权限边界更重要。

9. 能力沉淀方式的变化

传统 Agent 开发经常会把能力写死在应用代码和工作流里:某个 Agent 专门写单测,另一个 Agent 专门做数据分析,还有一个 Agent 专门生成营销文案。数量变多后,会出现几个麻烦:

  • 工作流分散,难以统一维护。
  • 多个 Agent 之间需要协调上下文。
  • Prompt 复制粘贴,版本不可控。
  • 同一类经验难以复用到不同工具。

Agent Skills 提供了另一种组织方式:不急着创建更多 Agent,而是把专业能力沉淀成 Skill。一个通用 Agent 可以根据任务动态加载不同 Skill。

flowchart LR
    A[通用 Agent] --> B[代码审查 Skill]
    A --> C[单元测试 Skill]
    A --> D[周报生成 Skill]
    A --> E[PDF 处理 Skill]
    A --> F[数据分析 Skill]

    B --> G[references: 代码规范]
    C --> H[scripts: 测试生成与运行]
    D --> I[scripts: Git 日志读取]
    E --> J[scripts: PDF 工具链]
    F --> K[references: 分析模板]

这种模式的工程价值在于:

能力具体体现
可复用同一个 Skill 可被多个项目、多个成员使用
可组合一个复杂任务可以调用多个 Skill
可版本化用 Git 记录变更,支持回滚和评审
可迁移支持同一标准的客户端可以加载同一套 Skill
可治理权限、依赖、规范都能文件化

10. 生态资源

Agent Skills 已经形成了官方示例、社区集合和标准化讨论。学习和构建 Skill 时,可以参考这些资源:

Agent Skills 的核心价值不是让模型“知道更多”,而是让团队把成熟做法封装成可执行、可分享、可迭代的能力包。对于重复发生、流程稳定、需要外部工具或领域规则的任务,把经验沉淀成 Skill,比反复调 Prompt 更容易维护,也更接近真实工程协作。


评论