问题：Skill 越多，Agent 越笨？
你的 AI Agent 是不是装了越来越多的 Skill（技能包），但体验却越来越差？每次对话的 Token 消耗悄悄涨上去了，Agent 的回复速度变慢了，更奇怪的是——它经常「忘掉」你刚才说了什么。
这不是你的幻觉。这是 Skill 膨胀在物理上稀释了 Agent 的注意力。
一条数据：我们对一个跑了三个月的 Hermes Agent 做了全量 Skill 审计。结果触目惊心——
MEDIA:/home/cronuser/workspace/已发表文章/2026-06-06/skill-token-chart.html
- 242 个已安装 Skill，仅 SKILL.md 文件就占 720K tokens
- 加上 References 文件，总计 4.5M tokens——如果全量加载，相当于每次对话前先塞给模型一本《战争与和平》
- 第一名的 wechat-login 单个 Skill 就吃掉 35K tokens
Agent 不是记不住——是它的注意力被这些「看似是知识，实则是噪音」的 Skill 挤爆了。
根因：Skill 膨胀的三个系统性坑
这个问题不是个别 Skill 写得不好，而是整个 Skill 生态存在三个系统性缺陷。这是 SkillReducer 论文（arXiv:2603.29919）对 55,315 个公开 Skill 做大规模审计后的发现： | 缺陷 | 数据 | 后果 | |---|---|---| | 描述缺失或冗余 | 26.4% 的 Skill 根本没用 routing 描述，有描述的又普遍冗长（平均 48 tokens） | Router 找不到该触发哪个 Skill，白吃 Token 却永不被调用 | | 正文 60% 是废物 | 只有 38.5% 的段落内容是可执行的规则，其余是背景介绍（40.7%）、示例（12.9%）和模板 | 每加载一个 Skill，60% 的 Token 打了水漂 | | 引用文件黑洞 | 14.8% 的 Skill 带有 Reference 文件，100 个 SkillHub Skill 合计 1.67M tokens 的引用文件 | 引用文件无论是否相关都会全量注入 | 一句话总结：Skill 作者把说明书、背景论文、示例代码全塞进了一个文件。Agent 被迫全部吞下去，然后在垃圾海洋里找珍珠。
解法：SkillReducer 两步瘦身 + 三条运行时铁律
SkillReducer：构建时压缩
SkillReducer 提出了一个两阶段优化框架，在 Skill 发布前就完成压缩： 阶段一：路由层压缩（描述瘦身 48%） 用 Delta Debugging 算法，从 Skill 描述中提取「最少但足够」的语义子集，确保 Router 能准确匹配。实测在 600 个 Skill 上： - 描述 Token 平均减少 48%（中位数 59%） - 路由准确率不变 阶段二：正文结构化（体积瘦身 39%） 通过分类学驱动的分类，将 Skill 正文拆成「核心可执行规则」和「按需加载的补充材料」。效果： - 正文 Token 减少 39% - 功能质量反而提升 2.8%——少即是多效应：去掉噪音后 Agent 注意力更聚焦
运行时：三条铁律锁死 Token 浪费
SkillReducer 解决的是「发布前」的问题。但 Agent 在运行时的上下文膨胀，需要另外三条自动规则来控制。我们将其写入了 System Prompt（SOUL.md）： MEDIA:/home/cronuser/workspace/已发表文章/2026-06-06/context-optimization-flow.html 规则 #1：工具输出瘦身（Observation Masking）
触发条件：web_extract / browser_snapshot / web_search 等工具返回 >2000 字符
执行动作：提取关键结论/数据，原文标记为可检索引用
控制目标：瘦身 60-80%，信息损失 <2%
规则 #2：上下文压缩（Context Compaction）
触发条件：对话 + 工具输出超过约 70% 利用率（约 40-50 轮密集交互）
执行动作：结构化总结——保留决策、修改的文件、关键方案、待办事项
丢弃中间探索过程、已解决的报错堆栈、重复输出
控制目标：削减 50-70%，关键信息丢失 <5%
规则 #3：输出生命周期（Output Lifecycle）
触发条件：某次工具调用的原始输出连续 3 轮未被引用
执行动作：丢弃，后续需用 session_search 回溯
例外情况：当前任务调试中、Sir 明确要求保留的内容
铁律之上：Sir 的指令优先
这里有一个关键的设计细节：规则是死的，用户指令是活的。 如果规则说「工具输出超过 2000 字符要压缩」，但用户说「全量给我看」——规则必须让路。我们在 SOUL.md 铁律的顶部加了一行元规则：
铁律之上：用户的明确指令优先于一切自动规则。冲突时以用户原话为准。 这是我们从一次真实事故中学到的教训：Agent 自动压缩了用户明确要求全量输出的内容，导致用户不得不重复提问。加了这行元规则后，再没出现过同类问题。
效果：四两拨千斤
三条铁律落地后，一个典型的 50 轮密集开发 Session： - 优化前：上下文膨胀到约 15 万 Token，Agent 注意力下降，开始漏答问题 - 优化后：自动控制在约 5 万 Token 以内，关键信息零丢失 - 额外收益：Agent 选择性漏答的比例从「偶尔发生」降为零（因为用户指令优先级已经被写死）
给你的 Agent 装这三条规则
如果你的 Agent 支持 System Prompt 级别的指令（Claude Code 的 CLAUDE.md、Cursor 的 .cursorrules、Hermes 的 SOUL.md），直接把这三条抄进去：
## Token 控制铁律
1. **工具输出瘦身**：工具返回 >2000 字符 → 提取结论，原文标引用。目标 -60~80%
2. **上下文压缩**：利用率 >70% → 结构化总结。目标 -50~70%
3. **输出生命周期**：连续 3 轮未引用 → 丢弃。例外：调试中或用户要求保留
4. **用户优先**：如果用户明确要求相反行为 → 以用户为准
十分钟，零代码改动，让你的 Agent 不再被自己的知识库淹死。
本文基于以下开源工作：SkillReducer (arXiv:2603.29919)、Agent-Skills-for-Context-Engineering (GitHub 16k⭐)、以及 Hermes Agent 生产环境三个月的实战数据。
本文由 admin 原创，转载请注明出处。
评论
0