Hermes Agent 调教实录三Agent 技能怎么写才不会被无视——触发词与体积实测Hermes Agent 调教实录 · 3/8 | 实验批次HERMES-103/103b基于 Hermes Agent v0.20.0 实测2026-08deepseek-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 骨架refsSKILL.md 只留方法论细节拆到 references 子文件结构化拆分C 模糊描述描述只写「Processes data files.」无任何触发词触发词的作用4 个任务里T2清洗是技能的正主——应该加载T1格式转换是弱相关——不该加载T3报告写作完全无关——不该加载。实测结果触发词的作用和你想的不一样先看加载行为任务A 单文件宽触发词B 骨架refsC 模糊描述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 骨架refs1.29×小技能拆 refs 是负优化——拆了之后Agent 加载技能要多一次调用先读 SKILL.md再按需读 refs来回往返反而更贵。那大技能呢我们用了一个真实的 77KB 大技能Dify 工作流 DSL 设计规范做了 103b 复验写法平均输入 token加载方式A 单文件77KB 全在 SKILL.md58.5kskill_view 5-6 次太大反复加载B 骨架refs19KB 方法论 60KB 细节50.6k省 13.5%skill_view 1 次 按需读 refs大技能拆 refs 确实省钱——77KB 的单文件Agent 一次加载不完要反复 skill_view 五六次拆成骨架后一次加载 19KB 方法论细节按需读。Agent 决定「加载不加载」一个技能其实只有两步判断是正主弱相关宽误加载窄不误加载≤25KB50KB新任务技能名/描述匹配加载技能触发词精准窄即可命中触发词是否过宽不加载直接执行体积判断单文件拆了反而贵 1.29×拆 refs省 13.5% 输入合起来体积判据是一条线技能体积写法≤25KB单文件拆了反而贵 1.29×25-50KB按内容形态查表型拆 refs方法论留正文50KB拆 refs省 13.5%加载次数大幅下降一个意外发现Agent 会自己改你的技能实验里有个插曲B 变体跑 T2 时Agent 用工具直接 patch 了实验技能——它觉得技能里的断言模板不够严谨自己改进了一版还把我们新发现的实证写进了技能文档。这个行为是双刃剑好的方面Agent 在「维护」技能沉淀新经验——像团队里主动改进文档的同事危险方面交付环境里Agent 会话中改动技能 生产技能被悄悄修改下次交付用的技能已经不是验收过的版本对策交付的技能版本锁定验收通过后只读Agent 的建议走「提出 → 人工审核 → 更新」流程而不是会话中直接改。实战坑坑现象修复触发词堆太宽弱相关任务 3/3 误加载描述只写真实场景词精准窄小技能拆 refs成本 1.29 倍≤25KB 单文件大技能单文件加载 5-6 次输入 token 58.5k50KB 拆 refsAgent 会话中改技能生产技能被悄悄修改验收后版本锁定适用边界技能描述是 Agent 的「目录页」——它先看技能名和描述决定加载不加载具体内容加载后才读「技能名是强信号」意味着命名很重要技能名要直观表达能力data-cleaner比utils-v3好 100 倍体积判据基于 Hermes 的 skill_view 机制单次加载上限不同框架的加载机制不同阈值要实测模板可直接复制技能描述最小范式--- name:> Hermes Agent 调教实录（三）：Agent 技能怎么写才不会被无视？——触发词与体积实测
Hermes Agent 调教实录三Agent 技能怎么写才不会被无视——触发词与体积实测Hermes Agent 调教实录 · 3/8 | 实验批次HERMES-103/103b基于 Hermes Agent v0.20.0 实测2026-08deepseek-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 骨架refsSKILL.md 只留方法论细节拆到 references 子文件结构化拆分C 模糊描述描述只写「Processes data files.」无任何触发词触发词的作用4 个任务里T2清洗是技能的正主——应该加载T1格式转换是弱相关——不该加载T3报告写作完全无关——不该加载。实测结果触发词的作用和你想的不一样先看加载行为任务A 单文件宽触发词B 骨架refsC 模糊描述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 骨架refs1.29×小技能拆 refs 是负优化——拆了之后Agent 加载技能要多一次调用先读 SKILL.md再按需读 refs来回往返反而更贵。那大技能呢我们用了一个真实的 77KB 大技能Dify 工作流 DSL 设计规范做了 103b 复验写法平均输入 token加载方式A 单文件77KB 全在 SKILL.md58.5kskill_view 5-6 次太大反复加载B 骨架refs19KB 方法论 60KB 细节50.6k省 13.5%skill_view 1 次 按需读 refs大技能拆 refs 确实省钱——77KB 的单文件Agent 一次加载不完要反复 skill_view 五六次拆成骨架后一次加载 19KB 方法论细节按需读。Agent 决定「加载不加载」一个技能其实只有两步判断是正主弱相关宽误加载窄不误加载≤25KB50KB新任务技能名/描述匹配加载技能触发词精准窄即可命中触发词是否过宽不加载直接执行体积判断单文件拆了反而贵 1.29×拆 refs省 13.5% 输入合起来体积判据是一条线技能体积写法≤25KB单文件拆了反而贵 1.29×25-50KB按内容形态查表型拆 refs方法论留正文50KB拆 refs省 13.5%加载次数大幅下降一个意外发现Agent 会自己改你的技能实验里有个插曲B 变体跑 T2 时Agent 用工具直接 patch 了实验技能——它觉得技能里的断言模板不够严谨自己改进了一版还把我们新发现的实证写进了技能文档。这个行为是双刃剑好的方面Agent 在「维护」技能沉淀新经验——像团队里主动改进文档的同事危险方面交付环境里Agent 会话中改动技能 生产技能被悄悄修改下次交付用的技能已经不是验收过的版本对策交付的技能版本锁定验收通过后只读Agent 的建议走「提出 → 人工审核 → 更新」流程而不是会话中直接改。实战坑坑现象修复触发词堆太宽弱相关任务 3/3 误加载描述只写真实场景词精准窄小技能拆 refs成本 1.29 倍≤25KB 单文件大技能单文件加载 5-6 次输入 token 58.5k50KB 拆 refsAgent 会话中改技能生产技能被悄悄修改验收后版本锁定适用边界技能描述是 Agent 的「目录页」——它先看技能名和描述决定加载不加载具体内容加载后才读「技能名是强信号」意味着命名很重要技能名要直观表达能力data-cleaner比utils-v3好 100 倍体积判据基于 Hermes 的 skill_view 机制单次加载上限不同框架的加载机制不同阈值要实测模板可直接复制技能描述最小范式--- name:>