问题：仓颉越勤快，Agent 越慢
仓颉的定位是"蒸馏所有值得蒸馏的高价值内容"——这会产生大量的 skill packs。以本仓库的产出为例：巴菲特 20 个、毛选 25 个、黄帝内经 22 个……21 个 packs 累计 300+ 个技能。
但问题来了：skill 是产出了，怎么"装"得下？
以 Hermes 为例（我的环境）：安装 250+ 技能后，系统会把全部技能的名称+描述注入 system prompt，每轮对话固定开销约 6,100 tokens。蒸馏得越多，上下文越膨胀——"造技能的机器"反而拖慢 agent 本身。
Claude Code / OpenClaw 有同样的问题：CLAUDE.md 里挂几十个 skill 后，索引开销肉眼可见。
解法：渐进式披露（progressive-skill）
我开发了 progressive-skill，核心机制四步：
用量评分(时间衰减) → 分类降级 → 预算截断 → 按需展开
- 用量追踪：记录每次 skill 加载，评分 = count × exp(-Δdays/30)——闲置技能自动降级
- 分级披露：高频分类完整展示，低频压成一行（
leadership (25)），被压的仍可完整发现
- 硬预算：完整分类按 4,600 字符截断，高分技能优先保留
实测：6,100 → 1,800 tok（-70%），压缩后 agent 仍能正确发现并加载技能。
关于通用性（诚实说明）
插件本体目前是 Hermes 专属（依赖其 compact_categories 机制），暂不支持 Claude Code / OpenClaw。
但设计思想是通用的——任何把 skill 注入 system prompt 的 agent 都有同样的膨胀问题，用量评分 → 分级披露 → 预算截断 这套机制可以直接移植。如果仓颉生态后续要考虑"蒸馏产出的 packs 怎么管理"，这个思路可以参考。
👉 https://github.com/freehul/progressive-skill（MIT，欢迎试用/参考/移植）
问题：仓颉越勤快，Agent 越慢
仓颉的定位是"蒸馏所有值得蒸馏的高价值内容"——这会产生大量的 skill packs。以本仓库的产出为例：巴菲特 20 个、毛选 25 个、黄帝内经 22 个……21 个 packs 累计 300+ 个技能。
但问题来了：skill 是产出了，怎么"装"得下？
以 Hermes 为例（我的环境）：安装 250+ 技能后，系统会把全部技能的名称+描述注入 system prompt，每轮对话固定开销约 6,100 tokens。蒸馏得越多，上下文越膨胀——"造技能的机器"反而拖慢 agent 本身。
Claude Code / OpenClaw 有同样的问题：CLAUDE.md 里挂几十个 skill 后，索引开销肉眼可见。
解法：渐进式披露（progressive-skill）
我开发了 progressive-skill，核心机制四步：
leadership (25)），被压的仍可完整发现实测：6,100 → 1,800 tok（-70%），压缩后 agent 仍能正确发现并加载技能。
关于通用性（诚实说明）
插件本体目前是 Hermes 专属（依赖其
compact_categories机制），暂不支持 Claude Code / OpenClaw。但设计思想是通用的——任何把 skill 注入 system prompt 的 agent 都有同样的膨胀问题，
用量评分 → 分级披露 → 预算截断这套机制可以直接移植。如果仓颉生态后续要考虑"蒸馏产出的 packs 怎么管理"，这个思路可以参考。👉 https://github.com/freehul/progressive-skill（MIT，欢迎试用/参考/移植）