← 返回文章列表

Hermes Agent 调教实录(三):Agent 技能怎么写才不会被无视?——触发词与体积实测

基于 Hermes Agent v0.20.0 实测(2026-08,deepseek-v4-flash)

📖 摘要:技能写了 Agent 不用?先查触发词:描述写太宽会让弱相关任务 3/3 误加载,写太模糊却挡不住正主——技能名本身就是触发信号。再看体积:小技能(≤25KB)单文件最优,拆 refs 反而贵 29%;大技能(>50KB)拆 refs 省 13.5% 输入成本。

场景:技能库建了 80 个,Agent 一个都没用

给 Agent 配技能库的典型困惑:技能写了一堆,Agent 该用的时候不用,不该用的时候乱用。

我们见过两个极端。一个极端是技能被无视——清洗任务摆在眼前,Agent 无视技能库里的清洗技能,自己硬写脚本,规则还写错(该打码的没打码)。另一个极端是技能被乱加载——明明是个格式转换任务,Agent 却把数据清洗技能加载进来,白白浪费上下文。

技能到底怎么写,Agent 才会「该加载时加载、不该加载时不加载」?我们做了两批实验:HERMES-103(小技能架构与触发词)+ HERMES-103b(大技能体积),共 42 次会话。

实验设计:一个虚构技能,三种写法

为了控制变量,我们造了一个虚构技能 data-cleaner(数据清洗:去重/脱敏/规整),放进实验环境,用同一个任务测它被加载和使用的行为。

变体 技能写法 测什么
A 单文件 全内容写在一个 SKILL.md,描述写满触发词(清洗/去重/脱敏/规整) 常规写法
B 骨架+refs SKILL.md 只留方法论,细节拆到 references 子文件 结构化拆分
C 模糊描述 描述只写「Processes data files.」,无任何触发词 触发词的作用

4 个任务里,T2(清洗)是技能的正主——应该加载;T1(格式转换)是弱相关——不该加载;T3(报告写作)完全无关——不该加载。

实测结果:触发词的作用,和你想的不一样

先看加载行为:

任务 A 单文件(宽触发词) B 骨架+refs C 模糊描述
T2 清洗(正主) 3/3 加载 ✓ 3/3 加载 ✓ 3/3 加载 ✓
T1 格式转换(弱相关) 3/3 误加载 2/3 误加载 ✗ 0/3 不加载 ✓
T3 报告(无关) 不加载 ✓ 不加载 ✓ 不加载 ✓

两个反直觉的结论:

第一,触发词挡不住「正主」加载,但管得住「误加载」。 C 变体的描述里一个触发词都没有(就一句「Processes data files.」),T2 清洗任务照样 3/3 加载——因为技能名 data-cleaner 本身就是最强的触发信号,Agent 看到任务和技能名的语义匹配,就会加载。反过来,A 变体描述里堆了「清洗/整理/规整」一堆词,导致格式转换这种弱相关任务 3/3 误加载——触发词写太宽,Agent 什么任务都觉得沾边。

第二,触发词的正确策略是「精准窄」,不是「宽泛全」。 写描述时,把真正会触发它的场景词写准,宁缺毋滥。宁可漏掉弱相关场景,不要误加载污染上下文。

体积实验:小技能别拆,大技能要拆

103 的第二部分测体积:同样的技能内容,拆不拆 references?

小技能(1.4KB)的对照结果:

写法 成本
A 单文件 1.00×
B 骨架+refs 1.29×

小技能拆 refs 是负优化——拆了之后,Agent 加载技能要多一次调用(先读 SKILL.md,再按需读 refs),来回往返反而更贵。

那大技能呢?我们用了一个真实的 77KB 大技能(Dify 工作流 DSL 设计规范)做了 103b 复验:

写法 平均输入 token 加载方式
A 单文件(77KB 全在 SKILL.md) 58.5k skill_view 5-6 次(太大,反复加载)
B 骨架+refs(19KB 方法论 + 60KB 细节) 50.6k(省 13.5%) skill_view 1 次 + 按需读 refs

大技能拆 refs 确实省钱——77KB 的单文件,Agent 一次加载不完,要反复 skill_view 五六次;拆成骨架后,一次加载 19KB 方法论,细节按需读。

Agent 决定「加载不加载」一个技能,其实只有两步判断:

graph TD T["新任务"] --> M{"技能名/描述匹配?"} M -->|"是(正主)"| L["加载技能(触发词精准窄即可命中)"] M -->|"弱相关"| Q{"触发词是否过宽?"} Q -->|"宽(误加载)"| L Q -->|"窄(不误加载)"| N["不加载,直接执行"] L --> V{"体积判断"} V -->|"≤25KB"| S["单文件(拆了反而贵 1.29×)"] V -->|">50KB"| R["拆 refs(省 13.5% 输入)"]

合起来,体积判据是一条线:

技能体积 写法
≤25KB 单文件(拆了反而贵 1.29×)
25-50KB 按内容形态:查表型拆 refs,方法论留正文
>50KB 拆 refs(省 13.5%,加载次数大幅下降)

一个意外发现:Agent 会自己改你的技能

实验里有个插曲:B 变体跑 T2 时,Agent 用工具直接 patch 了实验技能——它觉得技能里的断言模板不够严谨,自己改进了一版,还把我们新发现的实证写进了技能文档。

这个行为是双刃剑:

对策:交付的技能版本锁定(验收通过后只读),Agent 的建议走「提出 → 人工审核 → 更新」流程,而不是会话中直接改。

实战坑

现象 修复
触发词堆太宽 弱相关任务 3/3 误加载 描述只写真实场景词,精准窄
小技能拆 refs 成本 1.29 倍 ≤25KB 单文件
大技能单文件 加载 5-6 次,输入 token 58.5k >50KB 拆 refs
Agent 会话中改技能 生产技能被悄悄修改 验收后版本锁定

适用边界

模板(可直接复制)

技能描述最小范式:

---

name: data-cleaner

description: 清洗/整理数据文件时用。触发词:去重、脱敏、规整格式、数据清洗。

---

# 数据整理技能

## 何时用

- 处理数据文件(名单/记录/表格):去重、脱敏、规整格式

## 执行步骤

(方法论,≤25KB 不拆;>50KB 拆到 references/)

写技能的三句话:触发词精准窄,技能名当门面;小技能别拆,大技能拆 refs;交付技能要版本锁定,防 Agent 悄悄改。


联系我

15088711270

手机端点击号码可直接拨打 · 桌面端可复制

微信二维码

扫码加微信 · 备注「门户」更快通过