基于 Hermes Agent + 技能体系实测（2026-08）。文中重构数据均来自我们自己的实测记录；理论部分以「已验证 / 推断待验证」标注边界。

📖 摘要：AI Agent 的技能文件越用越大，大到连它自己都查不到沉淀过的经验——这只是一个症状。完整的治理不是一次重构，而是四层：拆（字典化拆分）、固（检查脚本化）、露（触发词与索引）、防（创建门槛）。我们用这四层把 12 个技能从 716KB 瘦到 472KB，并让治理本身变成一键执行。

📌 本文要解决的核心痛点

• Agent 明明「有经验」，关键时刻却查不到——技能文件太大，加载时被截断，经验物理丢失
• 查某个节点/某类任务的坑，要跨 3-4 个文件拼凑，还容易漏
• 技能体积无限增长，每次使用都付全量加载成本，token 越花越多
• 技能里明明写了经验，任务来了却没触发这个技能——加载都没发生，经验等于不存在

🎯 适合谁读：用 AI Agent（Hermes / Cursor / Claude 等）沉淀过技能或知识文件，且遇到过「明明记过却查不到」「技能根本没被触发」的人。不适合：只有 1-2 个小技能、远未膨胀的早期阶段（文末的四型判据会告诉你不需要拆）。

结论

Agent 技能的可达性由四层共同决定——拆、固、露、防——任何一层失守，经验都会「沉淀了却用不上」。

• 拆（组织）：查表型经验与方法论混在一个文件里 → 体积膨胀、加载截断、查表靠运气——解法是字典化拆分
• 固（执行）：治理检查靠手动重复 → 做第一次新鲜、做第三次被跳过——解法是把检查固化成脚本
• 露（可达）：技能没被触发 → 加载都没发生，经验等于不存在——解法是触发词审计与检索索引
• 防（预防）：新技能先建后膨胀 → 三个月后重复第一次的治理——解法是创建门槛

四条可证伪、可推导、可操作（每条都有反例证据见下文）。一个 100KB 的干净技能文件（组织好）依然可用，但它救不了「任务没触发这个技能」——所以治理必须是四层，不是一次瘦身。

场景

一个 AI 开发助手沉淀经验的方式，和程序员记笔记没有本质区别：每解决一个问题，就把结论写进自己的知识文件。今天补一条「LLM 节点配置坑」，明天记一条「代码节点参数规则」，后天再加一节「某平台接入的排障链」。

问题出在沉淀的「落点」——全部往同一个主文件里塞。三个月后，这个文件长到 168KB（约 5 万 token），包含 400 多行、十几个主题的内容。然后出现了一个很荒诞的现象：

它自己写的经验，它自己看不到了。

加载这个文件时，上下文窗口装不下，后半段被截断；偶尔装下了，114 行的「关键踩坑表」把几十个节点的坑混在一张表里，查某个具体节点的坑要在这张表里大海捞针。用户问「你不是踩过这个坑吗」，Agent 一脸茫然——不是没踩过，是踩过之后沉进了一个再也捞不出来的文件。

推导链：为什么膨胀必然导致经验不可达

四条约束叠加，没有一条能靠意志力绕开：

1. 经验只进不退——沉淀是增量操作，解决新问题就加新条目，几乎没人主动删旧条目
2. 加载全量读入——技能主文件整体注入上下文，越大越贵，超过预算就截断——截断掉的恰是后半段的经验堆积区
3. 查询线性扫描——无索引无归类，混合大表让「查到」变成概率事件
4. 触发是前置条件——系统只读技能描述的前 57 字符，触发词不在窗口内 = 技能根本不被加载

任何「只沉淀、不治理」的技能体系，都会走向经验不可达——要么体积爆炸（约束 1+2+3），要么触发失守（约束 4）。

第一步·拆（组织层）：把查表型经验拆出去

2026 年 8 月，我们对技能体系做了一次系统性重构，核心动作就是「字典化拆分」——把查表型经验按主题拆进独立文档，主文件只留方法论与索引。实测结果：

技能	重构动作	体积变化
DSL 设计技能（最大）	拆出 14 个「节点字典」「模块字典」文档	168KB → 76KB
技术文章写作技能	拆出 7 个「文章类型字典」	93KB → 35KB
应用测试技能	拆出 2 个「验收形态字典」	92KB → 72KB
应用验证技能	操作流程迁出，主文件留流程骨架	41KB → 11KB
平台接入技能	飞书/企微/钉钉拆成 3 个平台字典	40KB → 27KB
……（其余 7 个同类处理）
合计 12 个	新增 24 个字典/归档文档	716KB → 472KB（-34%）

重构后的使用路径：加载主文件（体积减半，方法论完整）→ 查「字典总索引」→ 按需打开对应字典文档（该主题全部经验聚合）。

代价：字典化拆分需要一次性的重构投入，且拆完的字典文档需要维护——这正是第二步「固」要解决的问题：把维护动作变成一键。

第二步·固（执行层）：把检查固化成脚本

重构完成不等于治理完成——每次新增经验、每次发布文章、每次升级系统，都有一串固定检查要做。这些检查如果靠手动，做第一次是新鲜、做第二次是负担、做第三次就被跳过了。

我们把「做过一次的手动检查」全部固化成脚本（判据：固定步骤 + 可机械化 + 重复执行）：

脚本	干什么	何时跑
技能健康体检	体积/章节结构/索引↔文件一致性/重复节	每次新增或大改技能后
跨技能重复扫描	同名文件内容 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 个修复，成本极低。

第四步·防（预防层）：新技能从第一天就规范

前三层是「治理存量」，第四层是「防止增量再膨胀」——新技能创建前强制过五查：

1. 查重复：先跑重复扫描 + 搜索——同主题技能已存在？能扩展吸收？禁止重复建
2. 四型定位：按架构判据定初始形态（操作手册型拆骨架 / 多主题型建字典 / 历史型归档 / 单主题手册型留正文）
3. 触发词前置：description 前 57 字符必须含核心触发词
4. 沉淀纪律：初始就按「坑进字典 / 纪律进正文 / 新主题建文档」建
5. 体检通过：建完跑健康体检，达标才交付

这五查已经固化成创建标准，写进了技能维护手册——以后每个新技能都是「创建即规范」，不用三个月后再治理一次。

四层治理汇总

层	动作	解决什么问题	实测效果
拆（组织）	查表型经验迁字典文档	体积膨胀 / 加载截断 / 查表低效	12 技能 716→472KB（-34%）
固（执行）	手动检查固化成脚本	检查靠自律、做一次就烦	7 个脚本一键体检
露（可达）	触发词审计 + 检索索引	技能没被触发 = 经验不存在	137 技能审计，修复 4 个
防（预防）	新技能五查门槛	先建后膨胀、重复治理	创建即规范，杜绝再膨胀

反例实证：三个事故

事故一：168KB 文件后半段被截断，经验当场消失。 现象：主文件超过上下文预算，加载被截断，后半段的经验堆积区（恰恰是最近沉淀的坑）进不了上下文。根因：全量读入机制 + 无上限膨胀。修复：字典化拆分后体积减半。

事故二：114 行混合踩坑表，查坑靠运气。 现象：几十个节点的坑混在一张表里，查具体节点经常漏；用户报「你明明踩过这个坑」，Agent 翻不到。根因：线性扫描 + 无归类。修复：按节点拆字典文档后一次看全。

事故三：触发词在 57 字符窗口外，技能根本没被加载。 现象：技能里明明有「订单评估」经验，用户说「这个单子接不接」时技能没被触发。根因：description 里塞了非触发内容。修复：触发词前置。

实践动作：四层清单

① 拆——先体检：按四型判据过一遍（操作手册型→骨架+ref / 多主题混杂→字典 / 历史记录→归档 / 单主题手册→不动）。出现「查表跨多文件」「同类经验重复」「加载截断」任一信号，立即拆。

② 固——先固化：问自己「这个检查动作我手动做过一次以上吗？」——是，就固化成脚本（参数化、输出可断言）。修脚本一次，手动检查是每次。

③ 露——先审计：description 触发词是否在 57 字符窗口内？参考文档超过 10 个建 INDEX.md 索引。两个动作都是小时级成本。

④ 防——先五查：新技能创建前过五查（查重复→四型定位→触发词前置→沉淀纪律→体检通过）——创建即规范。

适用边界

• 已验证：文本化技能体系（主文件/参考文档两级结构）适用；四层治理收益已验证（-34% / 一键检查 / 触发修复 / 创建门槛）
• 推断待验证：字典文档数量增长后索引本身可能成为新瓶颈；方法论密度极高的技能（84KB 判定不动）拆分是否仍有收益；触发词审计的触发率提升需长周期观察
• 实测环境：Hermes Agent（2026-08）——治理机制本身版本无关，文中数值为实测快照
• 不适合：纯 GUI 操作无文本化配置的场景；只有 1-2 个小技能、远未膨胀的早期阶段（四型判据会告诉你不需要拆）

收尾

回到结论：Agent 技能的可达性由组织、执行、触发、创建四层共同决定。治理不是一次性的瘦身，是一套持续运转的机制——知识总量在涨，可用性也一直在涨。

💬 讨论区：你的 AI 助手（或笔记系统）有没有出现过「明明记过却找不到」或「根本没触发」的情况？你是怎么解决的？欢迎聊聊你的知识组织方式。

如果这篇文章对你有帮助，点个赞 + 收藏 + 关注，后续继续沉淀 AI 技能治理的实测方法论。

本文基于真实项目经验撰写（Hermes Agent 技能体系，2026-08 实测）。文中所有数据均来自我们自己的实测记录（12 技能重构前后字节数、137 技能触发词审计、7 个治理脚本、加载截断与触发失守事故），理论部分以「已验证 / 推断待验证」标注边界。