跳到主要内容

Skill 体系概述与生态位

目录​

Skill 在工程里解决什么问题​

没有 Skill 时，团队往往把流程散落在：口头约定、飞书文档、某个人电脑里的提示词片段。结果是：同样的事每次重新讲一遍，质量随当班的人波动，复盘时找不到「当时到底按什么标准做的」。

Skill 把「可重复流程」固化成可被 Agent 或人类引用的说明书，核心解决三件事：

  1. 一致性：同样输入得到同样步骤，而不是每次模型自由发挥。
  2. 可交接：新成员按 Skill 执行，不必依赖老员工口传心授。
  3. 可演进：Skill 可以版本化、评审、回滚，像代码一样管理。

Skill 与 Prompt、工具、RAG 的分工​

层负责什么Skill 是否替代它
System prompt / 人设语气、边界、安全红线不替代；Skill 应与人设一致
工具（Tools/MCP）真实执行：读库、HTTP、浏览器不替代；Skill 描述「何时、如何」调用
RAG / 检索动态证据不替代；Skill 可规定「检索后如何引用与校验」
Skill重复业务流程的步骤、输入输出、质量标准本层

若你把所有东西都写进「超长 System prompt」，会导致：难维护、难 diff、难复用。Skill 适合承载流程型知识；人设适合稳定短约束。

与开放标准一致的「渐进披露」​

agentskills.io 把 Skill 的运行方式概括成三步，和「不要把全部说明书一次性塞进上下文」的工程直觉一致：

  1. 发现：会话开始时，Agent 只加载每个 Skill 的名称与简短描述（足以判断「可能相关」）。
  2. 激活：当用户任务与描述匹配时，再加载完整 SKILL.md 正文。
  3. 执行：按正文操作，必要时再读取同目录下的脚本、参考文档或模板文件。

这样可以在多 Skill 并存时，避免每条会话都付满「全部 Skill 全文」的 token 成本。本站 编写规范 与 规范对照 里对字段与篇幅的约定，与上述机制是同一套故事的不同侧面。

生态位：工作区 Skill、平台 Skill、标准 agentskills​

  • 工作区 Skill：例如 OpenClaw 的 ~/.openclaw/workspace/skills/<name>/SKILL.md，随用户环境走，适合个人或小团队（见 OpenClaw Skills 文档）。
  • 平台/产品内 Skill：由产品定义加载顺序与权限，常与计费、审计绑定。
  • 开放标准：如 agentskills.io 推动跨工具互操作；Hermes 亦声明兼容该标准（见 Hermes README 与 Skills 文档）。

选型建议：先在工作区把 Skill 写稳，再考虑抽成独立仓库或 Plugin 分发。

一张图：Skill 在 Agent 循环中的位置​

与招聘/协作的关系​

招聘中提到的「会写 Skill」通常指：能把复杂任务抽象成可复用模板，并配合评测与文档。协作上，Skill 是代码评审之外另一类需要 review 的资产：改一个字可能影响全团队输出风格。

延伸阅读​