AgentScope Ep 4：Skill——agent 能力的可携带单元

框架和智能体都宣称自己有"技能"机制，但 Skill 到底是什么、解决什么问题、两种实现差在哪？这一期拆到机制层。 锐Owl · 解构系列 · Agent 编排（Ep 4/4）

---

一、为什么是 Skill：agent 能力结构的第三块

一个 agent 的能力由三层构成：

1. 模型（推理层）——决定"想不想得明白"
2. 工具（执行层）——决定"做不做得到"
3. Skill（方法层）——决定"同一件事是不是每次都做得对"

模型和工具解决"能不能"，Skill 解决"稳不稳"。没有 Skill 的 agent，每次执行同一类任务都是从头推理一遍：步骤可能漏、顺序可能乱、质量标准可能漂移。Skill 把一次做对的方法固化成可复用的单元——模型负责调用，工具负责执行，Skill 负责流程。

这个母题不是某一家发明的。2025 年 Anthropic 提出 skill 模式（SKILL.md + 结构化 frontmatter）之后，行业快速收敛：框架（AgentScope）和智能体（Hermes）各自实现了自己的版本。结构同构，工程深度完全不同。这篇文章拆的就是这个差异。

---

二、AgentScope 的 Skill：面向企业平台的完整管线

AgentScope（阿里）的 Skill 机制，在 Java 版 Harness 中是一套完整的生命周期管理，六个环节：

1. 结构：能力包

一个 skill 是一个目录：

code-reviewer/
├── SKILL.md          # 必需：YAML frontmatter（name + description）+ 指令
├── references/       # 可选：长篇参考资料，agent 按需读取
└── scripts/          # 可选：shell 可调脚本

frontmatter 只有两个字段：name 和 description。这是刻意的——description 是 agent 决定"用不用这个 skill"的唯一依据，官方建议写触发场景（"当用户需要代码评审时使用"），而不是名词描述（"代码评审工具"）[1]。

2. 装载：市场 + 工作区双通道

• 技能市场：Git 仓库、Nacos、MySQL、classpath、自定义后端，统一入口 skillRepository(...)，可重复注册（后注册优先）
• 工作区：workspace/skills/ 团队共用；<userId>/skills/ 按用户隔离

3. 优先级：四层覆盖规则

同名冲突时，从低到高：项目全局目录 → 市场 → 工作区共用 → 用户隔离。下层独有的 skill 保留，只在重名时被上层覆盖。这是典型的企业多租户设计——平台管理员、团队、个人三个层级各有修改权，互不踩踏。

4. 执行：元数据注入 + 按需加载

每轮推理，system prompt 注入 <available_skills> 块，每个 skill 只带 name/description/files-root 四个字段。agent 判断相关性后，用 load_skill_through_path(skillId, path) 按需读取 SKILL.md 或任意资源文件。底层查找顺序：内存命中 → 文件系统读取 → 找不到返回可用路径清单（传错 path 不会死路）。

5. 脚本执行：files-root 抽象

skill 自带脚本时，框架自动计算 <files-root> 绝对路径前缀（工作区 skill 和市场上 skill 落点不同），agent 发出 execute_shell_command("python3 <files-root>/scripts/foo.py")——不用猜路径，不用记来源。市场 skill 每轮推理前物化到 .skills-cache/（SHA-256 去重、孤儿清理、shebang 恢复执行位）。

6. 治理：自学习闭环

AgentScope 的 Skill 不只是一套读写机制，还有完整的生命周期治理：

• 写：enableSkillManageTool 让 agent 自己起草 skill（propose_skill 写草稿，skill_manage 编辑）
• 审：enableSkillPromotionGate 审核闸门——草稿转正式必须经过审批（内置三种：直接拒绝/本地人工/推消息），配套可见性过滤（按环境、灰度比例、白名单）
• 理：enableSkillCurator 后台周期整理——30 天没用标 stale，90 天归档
• 记：每次读取自动记使用计数到 .usage.json，为清理和灰度提供数据

沙箱执行是另一个关键设计：skill 脚本在隔离容器里跑，宿主不受影响。流程三步：物化（市场 skill 写宿主缓存）→ 投影（workspace 静态资产 tar 进容器 /workspace）→ 容器内执行。值得注意的细节：读 SKILL.md 不需要沙箱（走内存/宿主 FS），只有 shell 跑脚本才需要文件进容器；快照（snapshotSpec）可跨调用保留脚本副作用（npm/pip 装过的不重装）。

---

三、Hermes 的 Skill：面向个人 agent 的轻量封装

Hermes（Nous Research）的 Skill 机制，走的是另一条路线——单用户、本地优先、宿主执行。

结构：同构

SKILL.md 的格式与 AgentScope 基本一致：YAML frontmatter（name + description）+ 指令正文，可选 references/、templates/、scripts/。frontmatter 校验规则同样聚焦 name 和 description（description 上限 1024 字符，且系统提示中只展示前 57 字符——所以触发条件必须写在开头）[2]。

装载：本地目录 + 社区源

• 本地：~/.hermes/skills/<category>/<name>/SKILL.md，个人私有
• 社区：skills hub 搜索/安装、GitHub tap 添加源
• profile 级隔离：多 profile 各有一套独立 skills/（与配置、会话、记忆一起隔离）

执行：描述注入 + 按需加载

与 AgentScope 同一模式：系统提示中注入可用 skill 的 name+description 索引，agent 判断相关性后通过 skill_view(name) 加载完整 SKILL.md。没有 <available_skills> XML 块，但信息流等价——先看描述，再决定加载。

脚本执行：宿主直跑

Hermes 的 skill 脚本直接在当前机器上执行（terminal 工具），没有沙箱层。这是因为 Hermes 的信任模型是"宿主即本机"——它本来就跑在你的终端里，能碰到的就是你机器上的一切。

治理：人工维护 + 社区 curator

• 写：skill_manage 工具支持创建/编辑/删除
• 审：没有强制审核闸门——作者就是使用者，自己审自己
• 理：社区 curator 定期检查更新/清理过时技能（非本机自动化，是维护流程）
• 记：无自动使用计数

---

四、同一母题，两种工程深度

← 表格可左右滑动查看

三个关键分叉，体现的是信任模型的差异：

分叉一：信任模型。 AgentScope 默认不信任——skill 脚本进沙箱、草稿进审核、变化进审计。Hermes 默认信任——脚本宿主直跑、作者自己审。这不是能力差距，是定位差异：AgentScope 要承载企业多租户（一个平台跑几十个团队的 agent），沙箱是安全底线；Hermes 是个人 agent（agent 就是你自己），宿主直跑是效率选择。

分叉二：多租户 vs 多 profile。 AgentScope 的 <userId>/skills/ 是用户级覆盖——同一个人名下，个人版本盖掉团队版本。Hermes 的 profile 是完整隔离——每个 profile 的 skills、记忆、配置全部分开，不存在"覆盖"概念。前者适合"一个平台、多人协作、层级管理"；后者适合"一个机器、多身份、互不污染"。

分叉三：生命周期。 AgentScope 把 skill 当组织资产管理：起草→审核→发布→灰度→清理，全链路可审计。Hermes 把 skill 当个人积累管理：写了自己用，坏了就改。自学习闭环（agent 自己写 skill 自己审）在单用户场景价值有限——因为没有第二双眼睛，审核闸门只是给自己走流程；但在多 agent 企业场景，这是质量红线。

---

五、结论：Skill 机制会收敛到什么形态

1. 结构性收敛已经发生：SKILL.md + frontmatter + references/scripts 会成为事实标准。AgentScope 和 Hermes 的格式几乎可以互相移植——这降低了生态碎片化的风险。

2. 分层是必然：个人场景用轻量版（宿主直跑、无审核），企业场景用治理版（沙箱、闸门、审计）。不是谁更好，是场景不同。个人 agent 上沙箱是过度工程，企业平台上无沙箱是不可接受。

3. 对使用者的启示：Skill 的价值不在格式，在维护纪律——description 写触发场景、SKILL.md 保持精简、细节放 references。这一点两家官方建议完全一致。工具帮你管格式，管不住内容质量。

Skill 是 agent 能力的第三块拼图：模型决定上限，工具决定边界，Skill 决定下限——同一件事，是不是每次都能做到合格线以上。框架和智能体都在做这块拼图，只是各自为不同的信任场景打磨。

---

参考来源

[1] AgentScope Java 文档 · Skill 机制：https://java.agentscope.io/v2/zh/docs/harness/skill.html [2] Hermes Agent 文档与 skill 规范：https://hermes-agent.nousresearch.com/docs/ [3] AgentScope GitHub 仓库：https://github.com/alg-agent-superlab/AgentScope