基于 Hermes Agent 技能体系实测2026-08。文中重构数据均来自我们自己的实测记录理论部分以「已验证 / 推断待验证」标注边界。摘要AI Agent 的技能文件越用越大大到连它自己都查不到沉淀过的经验——这只是一个症状。完整的治理不是一次重构而是四层拆字典化拆分、固检查脚本化、露触发词与索引、防创建门槛。我们用这四层把 12 个技能从 716KB 瘦到 472KB并让治理本身变成一键执行。本文要解决的核心痛点Agent 明明「有经验」关键时刻却查不到——技能文件太大加载时被截断经验物理丢失查某个节点/某类任务的坑要跨 3-4 个文件拼凑还容易漏技能体积无限增长每次使用都付全量加载成本token 越花越多技能里明明写了经验任务来了却没触发这个技能——加载都没发生经验等于不存在适合谁读用 AI AgentHermes / Cursor / Claude 等沉淀过技能或知识文件且遇到过「明明记过却查不到」「技能根本没被触发」的人。不适合只有 1-2 个小技能、远未膨胀的早期阶段文末的四型判据会告诉你不需要拆。结论Agent 技能的可达性由四层共同决定——拆、固、露、防——任何一层失守经验都会「沉淀了却用不上」。拆组织查表型经验与方法论混在一个文件里 → 体积膨胀、加载截断、查表靠运气——解法是字典化拆分固执行治理检查靠手动重复 → 做第一次新鲜、做第三次被跳过——解法是把检查固化成脚本露可达技能没被触发 → 加载都没发生经验等于不存在——解法是触发词审计与检索索引防预防新技能先建后膨胀 → 三个月后重复第一次的治理——解法是创建门槛四条可证伪、可推导、可操作每条都有反例证据见下文。一个 100KB 的干净技能文件组织好依然可用但它救不了「任务没触发这个技能」——所以治理必须是四层不是一次瘦身。场景一个 AI 开发助手沉淀经验的方式和程序员记笔记没有本质区别每解决一个问题就把结论写进自己的知识文件。今天补一条「LLM 节点配置坑」明天记一条「代码节点参数规则」后天再加一节「某平台接入的排障链」。问题出在沉淀的「落点」——全部往同一个主文件里塞。三个月后这个文件长到 168KB约 5 万 token包含 400 多行、十几个主题的内容。然后出现了一个很荒诞的现象它自己写的经验它自己看不到了。加载这个文件时上下文窗口装不下后半段被截断偶尔装下了114 行的「关键踩坑表」把几十个节点的坑混在一张表里查某个具体节点的坑要在这张表里大海捞针。用户问「你不是踩过这个坑吗」Agent 一脸茫然——不是没踩过是踩过之后沉进了一个再也捞不出来的文件。推导链为什么膨胀必然导致经验不可达四条约束叠加没有一条能靠意志力绕开经验只进不退——沉淀是增量操作解决新问题就加新条目几乎没人主动删旧条目加载全量读入——技能主文件整体注入上下文越大越贵超过预算就截断——截断掉的恰是后半段的经验堆积区查询线性扫描——无索引无归类混合大表让「查到」变成概率事件触发是前置条件——系统只读技能描述的前 57 字符触发词不在窗口内 技能根本不被加载任何「只沉淀、不治理」的技能体系都会走向经验不可达——要么体积爆炸约束 123要么触发失守约束 4。第一步·拆组织层把查表型经验拆出去2026 年 8 月我们对技能体系做了一次系统性重构核心动作就是「字典化拆分」——把查表型经验按主题拆进独立文档主文件只留方法论与索引。实测结果技能重构动作体积变化DSL 设计技能最大拆出 14 个「节点字典」「模块字典」文档168KB → 76KB技术文章写作技能拆出 7 个「文章类型字典」93KB → 35KB应用测试技能拆出 2 个「验收形态字典」92KB → 72KB应用验证技能操作流程迁出主文件留流程骨架41KB → 11KB平台接入技能飞书/企微/钉钉拆成 3 个平台字典40KB → 27KB……其余 7 个同类处理合计 12 个新增 24 个字典/归档文档716KB → 472KB-34%重构后主文件 字典76KB索引一行定位索引一行定位索引一行定位SKILL.md 主文件方法论 字典总索引node-ref 字典文档按节点分module-ref 字典文档按模块分article-type 字典文档按类型分重构前混合大文件168KB加载成本高查表靠扫描方法论每次必读114 行混合踩坑表几十个节点坑混在一起平台配置 / 文章类型 / 历史记录 混杂重构后的使用路径加载主文件体积减半方法论完整→ 查「字典总索引」→ 按需打开对应字典文档该主题全部经验聚合。代价字典化拆分需要一次性的重构投入且拆完的字典文档需要维护——这正是第二步「固」要解决的问题把维护动作变成一键。第二步·固执行层把检查固化成脚本重构完成不等于治理完成——每次新增经验、每次发布文章、每次升级系统都有一串固定检查要做。这些检查如果靠手动做第一次是新鲜、做第二次是负担、做第三次就被跳过了。我们把「做过一次的手动检查」全部固化成脚本判据固定步骤 可机械化 重复执行脚本干什么何时跑技能健康体检体积/章节结构/索引↔文件一致性/重复节每次新增或大改技能后跨技能重复扫描同名文件内容 hash 对比揪出误复制/重复沉淀创建新技能前版本钉扎扫描找「实测结论」未标验证版本的修订技能时文章发布前自查平台违禁词/内部痕迹/本地图片/旧标签/Mermaid 围栏六项每篇文章发布前Dify 升级后验证数据库迁移/插件守护/API/前端四步服务器升级后MCP 桥接健康校验Client 方法数 工具数 分发数三层一致性桥接改完实测价值技能健康体检第一次跑就发现 4 个技能超过 50KB 警戒线真实信号跨技能重复扫描揪出一个文件被误复制到两个技能同大小同内容同时间戳文章自查把原来每次手动 grep 六项变成一条命令。代价脚本本身需要维护本次 7 个脚本真跑修了 5 轮路径层级、误报降级、编码容错——但脚本修一次手动检查是每次。第三步·露可达层让技能能被任务触发组织好了、检查自动化了还有一个更隐蔽的失守点技能没被触发。Agent 根据技能描述description匹配任务决定加载哪个技能——而系统只读取 description 的前 57 字符。我们对全部 137 个技能做了触发词审计发现 4 个技能的核心触发词被挤出了 57 字符窗口「这个单子接不接」订单评估技能——用户的高频真实说法在窗口外「训练 Hermes」技能训练技能——被截断「测试这个应用」应用测试技能——被截断一个纪律技能的前 57 字符被「用户批评原文」占用——触发词根本没写进去修复触发词段前置到窗口内。同时给 4 个 refs 多的技能建了检索索引INDEX.md——每个参考文档一行文件名 | 主题 | 类型查经验先看索引定位不再靠记忆猜文件名。价值这一层解决的是「技能有经验、组织也健康但任务来了根本没加载它」——比查不到更底层。触发词审计是 137 个技能一次扫描 4 个修复成本极低。第四步·防预防层新技能从第一天就规范前三层是「治理存量」第四层是「防止增量再膨胀」——新技能创建前强制过五查查重复先跑重复扫描 搜索——同主题技能已存在能扩展吸收禁止重复建四型定位按架构判据定初始形态操作手册型拆骨架 / 多主题型建字典 / 历史型归档 / 单主题手册型留正文触发词前置description 前 57 字符必须含核心触发词沉淀纪律初始就按「坑进字典 / 纪律进正文 / 新主题建文档」建体检通过建完跑健康体检达标才交付这五查已经固化成创建标准写进了技能维护手册——以后每个新技能都是「创建即规范」不用三个月后再治理一次。四层治理汇总层动作解决什么问题实测效果拆组织查表型经验迁字典文档体积膨胀 / 加载截断 / 查表低效12 技能 716→472KB-34%固执行手动检查固化成脚本检查靠自律、做一次就烦7 个脚本一键体检露可达触发词审计 检索索引技能没被触发 经验不存在137 技能审计修复 4 个防预防新技能五查门槛先建后膨胀、重复治理创建即规范杜绝再膨胀反例实证三个事故事故一168KB 文件后半段被截断经验当场消失。现象主文件超过上下文预算加载被截断后半段的经验堆积区恰恰是最近沉淀的坑进不了上下文。根因全量读入机制 无上限膨胀。修复字典化拆分后体积减半。事故二114 行混合踩坑表查坑靠运气。现象几十个节点的坑混在一张表里查具体节点经常漏用户报「你明明踩过这个坑」Agent 翻不到。根因线性扫描 无归类。修复按节点拆字典文档后一次看全。事故三触发词在 57 字符窗口外技能根本没被加载。现象技能里明明有「订单评估」经验用户说「这个单子接不接」时技能没被触发。根因description 里塞了非触发内容。修复触发词前置。实践动作四层清单① 拆——先体检按四型判据过一遍操作手册型→骨架ref / 多主题混杂→字典 / 历史记录→归档 / 单主题手册→不动。出现「查表跨多文件」「同类经验重复」「加载截断」任一信号立即拆。② 固——先固化问自己「这个检查动作我手动做过一次以上吗」——是就固化成脚本参数化、输出可断言。修脚本一次手动检查是每次。③ 露——先审计description 触发词是否在 57 字符窗口内参考文档超过 10 个建 INDEX.md 索引。两个动作都是小时级成本。④ 防——先五查新技能创建前过五查查重复→四型定位→触发词前置→沉淀纪律→体检通过——创建即规范。适用边界已验证文本化技能体系主文件/参考文档两级结构适用四层治理收益已验证-34% / 一键检查 / 触发修复 / 创建门槛推断待验证字典文档数量增长后索引本身可能成为新瓶颈方法论密度极高的技能84KB 判定不动拆分是否仍有收益触发词审计的触发率提升需长周期观察实测环境Hermes Agent2026-08——治理机制本身版本无关文中数值为实测快照不适合纯 GUI 操作无文本化配置的场景只有 1-2 个小技能、远未膨胀的早期阶段四型判据会告诉你不需要拆收尾回到结论Agent 技能的可达性由组织、执行、触发、创建四层共同决定。治理不是一次性的瘦身是一套持续运转的机制——知识总量在涨可用性也一直在涨。讨论区你的 AI 助手或笔记系统有没有出现过「明明记过却找不到」或「根本没触发」的情况你是怎么解决的欢迎聊聊你的知识组织方式。如果这篇文章对你有帮助点个赞 收藏 关注后续继续沉淀 AI 技能治理的实测方法论。本文基于真实项目经验撰写Hermes Agent 技能体系2026-08 实测。文中所有数据均来自我们自己的实测记录12 技能重构前后字节数、137 技能触发词审计、7 个治理脚本、加载截断与触发失守事故理论部分以「已验证 / 推断待验证」标注边界。
基于 Hermes Agent 技能体系实测2026-08。文中重构数据均来自我们自己的实测记录理论部分以「已验证 / 推断待验证」标注边界。摘要AI Agent 的技能文件越用越大大到连它自己都查不到沉淀过的经验——这只是一个症状。完整的治理不是一次重构而是四层拆字典化拆分、固检查脚本化、露触发词与索引、防创建门槛。我们用这四层把 12 个技能从 716KB 瘦到 472KB并让治理本身变成一键执行。本文要解决的核心痛点Agent 明明「有经验」关键时刻却查不到——技能文件太大加载时被截断经验物理丢失查某个节点/某类任务的坑要跨 3-4 个文件拼凑还容易漏技能体积无限增长每次使用都付全量加载成本token 越花越多技能里明明写了经验任务来了却没触发这个技能——加载都没发生经验等于不存在适合谁读用 AI AgentHermes / Cursor / Claude 等沉淀过技能或知识文件且遇到过「明明记过却查不到」「技能根本没被触发」的人。不适合只有 1-2 个小技能、远未膨胀的早期阶段文末的四型判据会告诉你不需要拆。结论Agent 技能的可达性由四层共同决定——拆、固、露、防——任何一层失守经验都会「沉淀了却用不上」。拆组织查表型经验与方法论混在一个文件里 → 体积膨胀、加载截断、查表靠运气——解法是字典化拆分固执行治理检查靠手动重复 → 做第一次新鲜、做第三次被跳过——解法是把检查固化成脚本露可达技能没被触发 → 加载都没发生经验等于不存在——解法是触发词审计与检索索引防预防新技能先建后膨胀 → 三个月后重复第一次的治理——解法是创建门槛四条可证伪、可推导、可操作每条都有反例证据见下文。一个 100KB 的干净技能文件组织好依然可用但它救不了「任务没触发这个技能」——所以治理必须是四层不是一次瘦身。场景一个 AI 开发助手沉淀经验的方式和程序员记笔记没有本质区别每解决一个问题就把结论写进自己的知识文件。今天补一条「LLM 节点配置坑」明天记一条「代码节点参数规则」后天再加一节「某平台接入的排障链」。问题出在沉淀的「落点」——全部往同一个主文件里塞。三个月后这个文件长到 168KB约 5 万 token包含 400 多行、十几个主题的内容。然后出现了一个很荒诞的现象它自己写的经验它自己看不到了。加载这个文件时上下文窗口装不下后半段被截断偶尔装下了114 行的「关键踩坑表」把几十个节点的坑混在一张表里查某个具体节点的坑要在这张表里大海捞针。用户问「你不是踩过这个坑吗」Agent 一脸茫然——不是没踩过是踩过之后沉进了一个再也捞不出来的文件。推导链为什么膨胀必然导致经验不可达四条约束叠加没有一条能靠意志力绕开经验只进不退——沉淀是增量操作解决新问题就加新条目几乎没人主动删旧条目加载全量读入——技能主文件整体注入上下文越大越贵超过预算就截断——截断掉的恰是后半段的经验堆积区查询线性扫描——无索引无归类混合大表让「查到」变成概率事件触发是前置条件——系统只读技能描述的前 57 字符触发词不在窗口内 技能根本不被加载任何「只沉淀、不治理」的技能体系都会走向经验不可达——要么体积爆炸约束 123要么触发失守约束 4。第一步·拆组织层把查表型经验拆出去2026 年 8 月我们对技能体系做了一次系统性重构核心动作就是「字典化拆分」——把查表型经验按主题拆进独立文档主文件只留方法论与索引。实测结果技能重构动作体积变化DSL 设计技能最大拆出 14 个「节点字典」「模块字典」文档168KB → 76KB技术文章写作技能拆出 7 个「文章类型字典」93KB → 35KB应用测试技能拆出 2 个「验收形态字典」92KB → 72KB应用验证技能操作流程迁出主文件留流程骨架41KB → 11KB平台接入技能飞书/企微/钉钉拆成 3 个平台字典40KB → 27KB……其余 7 个同类处理合计 12 个新增 24 个字典/归档文档716KB → 472KB-34%重构后主文件 字典76KB索引一行定位索引一行定位索引一行定位SKILL.md 主文件方法论 字典总索引node-ref 字典文档按节点分module-ref 字典文档按模块分article-type 字典文档按类型分重构前混合大文件168KB加载成本高查表靠扫描方法论每次必读114 行混合踩坑表几十个节点坑混在一起平台配置 / 文章类型 / 历史记录 混杂重构后的使用路径加载主文件体积减半方法论完整→ 查「字典总索引」→ 按需打开对应字典文档该主题全部经验聚合。代价字典化拆分需要一次性的重构投入且拆完的字典文档需要维护——这正是第二步「固」要解决的问题把维护动作变成一键。第二步·固执行层把检查固化成脚本重构完成不等于治理完成——每次新增经验、每次发布文章、每次升级系统都有一串固定检查要做。这些检查如果靠手动做第一次是新鲜、做第二次是负担、做第三次就被跳过了。我们把「做过一次的手动检查」全部固化成脚本判据固定步骤 可机械化 重复执行脚本干什么何时跑技能健康体检体积/章节结构/索引↔文件一致性/重复节每次新增或大改技能后跨技能重复扫描同名文件内容 hash 对比揪出误复制/重复沉淀创建新技能前版本钉扎扫描找「实测结论」未标验证版本的修订技能时文章发布前自查平台违禁词/内部痕迹/本地图片/旧标签/Mermaid 围栏六项每篇文章发布前Dify 升级后验证数据库迁移/插件守护/API/前端四步服务器升级后MCP 桥接健康校验Client 方法数 工具数 分发数三层一致性桥接改完实测价值技能健康体检第一次跑就发现 4 个技能超过 50KB 警戒线真实信号跨技能重复扫描揪出一个文件被误复制到两个技能同大小同内容同时间戳文章自查把原来每次手动 grep 六项变成一条命令。代价脚本本身需要维护本次 7 个脚本真跑修了 5 轮路径层级、误报降级、编码容错——但脚本修一次手动检查是每次。第三步·露可达层让技能能被任务触发组织好了、检查自动化了还有一个更隐蔽的失守点技能没被触发。Agent 根据技能描述description匹配任务决定加载哪个技能——而系统只读取 description 的前 57 字符。我们对全部 137 个技能做了触发词审计发现 4 个技能的核心触发词被挤出了 57 字符窗口「这个单子接不接」订单评估技能——用户的高频真实说法在窗口外「训练 Hermes」技能训练技能——被截断「测试这个应用」应用测试技能——被截断一个纪律技能的前 57 字符被「用户批评原文」占用——触发词根本没写进去修复触发词段前置到窗口内。同时给 4 个 refs 多的技能建了检索索引INDEX.md——每个参考文档一行文件名 | 主题 | 类型查经验先看索引定位不再靠记忆猜文件名。价值这一层解决的是「技能有经验、组织也健康但任务来了根本没加载它」——比查不到更底层。触发词审计是 137 个技能一次扫描 4 个修复成本极低。第四步·防预防层新技能从第一天就规范前三层是「治理存量」第四层是「防止增量再膨胀」——新技能创建前强制过五查查重复先跑重复扫描 搜索——同主题技能已存在能扩展吸收禁止重复建四型定位按架构判据定初始形态操作手册型拆骨架 / 多主题型建字典 / 历史型归档 / 单主题手册型留正文触发词前置description 前 57 字符必须含核心触发词沉淀纪律初始就按「坑进字典 / 纪律进正文 / 新主题建文档」建体检通过建完跑健康体检达标才交付这五查已经固化成创建标准写进了技能维护手册——以后每个新技能都是「创建即规范」不用三个月后再治理一次。四层治理汇总层动作解决什么问题实测效果拆组织查表型经验迁字典文档体积膨胀 / 加载截断 / 查表低效12 技能 716→472KB-34%固执行手动检查固化成脚本检查靠自律、做一次就烦7 个脚本一键体检露可达触发词审计 检索索引技能没被触发 经验不存在137 技能审计修复 4 个防预防新技能五查门槛先建后膨胀、重复治理创建即规范杜绝再膨胀反例实证三个事故事故一168KB 文件后半段被截断经验当场消失。现象主文件超过上下文预算加载被截断后半段的经验堆积区恰恰是最近沉淀的坑进不了上下文。根因全量读入机制 无上限膨胀。修复字典化拆分后体积减半。事故二114 行混合踩坑表查坑靠运气。现象几十个节点的坑混在一张表里查具体节点经常漏用户报「你明明踩过这个坑」Agent 翻不到。根因线性扫描 无归类。修复按节点拆字典文档后一次看全。事故三触发词在 57 字符窗口外技能根本没被加载。现象技能里明明有「订单评估」经验用户说「这个单子接不接」时技能没被触发。根因description 里塞了非触发内容。修复触发词前置。实践动作四层清单① 拆——先体检按四型判据过一遍操作手册型→骨架ref / 多主题混杂→字典 / 历史记录→归档 / 单主题手册→不动。出现「查表跨多文件」「同类经验重复」「加载截断」任一信号立即拆。② 固——先固化问自己「这个检查动作我手动做过一次以上吗」——是就固化成脚本参数化、输出可断言。修脚本一次手动检查是每次。③ 露——先审计description 触发词是否在 57 字符窗口内参考文档超过 10 个建 INDEX.md 索引。两个动作都是小时级成本。④ 防——先五查新技能创建前过五查查重复→四型定位→触发词前置→沉淀纪律→体检通过——创建即规范。适用边界已验证文本化技能体系主文件/参考文档两级结构适用四层治理收益已验证-34% / 一键检查 / 触发修复 / 创建门槛推断待验证字典文档数量增长后索引本身可能成为新瓶颈方法论密度极高的技能84KB 判定不动拆分是否仍有收益触发词审计的触发率提升需长周期观察实测环境Hermes Agent2026-08——治理机制本身版本无关文中数值为实测快照不适合纯 GUI 操作无文本化配置的场景只有 1-2 个小技能、远未膨胀的早期阶段四型判据会告诉你不需要拆收尾回到结论Agent 技能的可达性由组织、执行、触发、创建四层共同决定。治理不是一次性的瘦身是一套持续运转的机制——知识总量在涨可用性也一直在涨。讨论区你的 AI 助手或笔记系统有没有出现过「明明记过却找不到」或「根本没触发」的情况你是怎么解决的欢迎聊聊你的知识组织方式。如果这篇文章对你有帮助点个赞 收藏 关注后续继续沉淀 AI 技能治理的实测方法论。本文基于真实项目经验撰写Hermes Agent 技能体系2026-08 实测。文中所有数据均来自我们自己的实测记录12 技能重构前后字节数、137 技能触发词审计、7 个治理脚本、加载截断与触发失守事故理论部分以「已验证 / 推断待验证」标注边界。
