自学习 Agent 的臃肿悖论与 Hermes 的应对

原始问题

“MCP 不是越用越聪明，而是越用越臃肿、越痴呆。那 Hermes 自己学习用户行为学会的 Skill 也会不断使得体系变得臃肿啊，这个 Hermes 有解决办法吗？”

用户发现了一个自学习 Agent 的经典死亡螺旋：Agent 学得越多 → Skill 积累越多 → System Prompt 越胀 → 注意力被稀释 → 越痴呆。如果 Hermes 真的用了五年，会不会被自己学的 500 个 Skill 压垮？

Skill 膨胀 ≠ MCP 膨胀（数量级差 10 倍以上）

MCP 的臃肿和 Skill 的臃肿，毒性完全不是一个级别：

	MCP 膨胀	Skill 膨胀
一个单元占多少	一个 Playwright MCP = 13,700 tokens	一个 Skill 在 Level 0 = 一行目录，约 30 tokens
100 个的代价	无法承受（数十万 tokens）	100 行目录，约 3,000 tokens
什么时候真正占 token	每次 API 调用都带着全部定义	Level 0 只有目录（~3K）。真正内容在 Level 1 按需展开，不用不加载

Hermes 就算装了 100 个 Skill，System Prompt 里的固定开销也只是 100 行目录 ≈ 3K tokens。一个 MCP Server 的固定开销就是 13K。不是一个数量级的问题。

三道防线

防线一：Skill 不会在 System Prompt 里堆积

Skill 采用三层加载（见 Hermes Agent 功能详解 §4.2）：

• Level 0：一行目录（“这个 Skill 叫什么 + 一句话描述”），常驻 System Prompt，约 30 tokens/Skill
• Level 1：Agent 说”我要用这个”，Harness 才把完整 SKILL.md 注入对话。正文不进 System Prompt，不影响前缀缓存
• Level 2：引用的外部参考文件进一步按需加载

防线二：Agent 自己会删（自清理）

skill_manage 工具不止能 create，还能 patch 和 delete：

• 长期没被触发过的 Skill → 删除
• 被更好版本替代的旧 Skill → 删除
• 实践后发现不准确的 Skill → 修正（patch），而非叠加新的

真正的学习不光”记住”，还包括”忘掉没用的”。

防线三：条件激活

Skill 用 fallback_for_toolsets 和 requires_toolsets 控制何时可见：

DuckDuckGo 搜索 Skill：
  fallback_for_toolsets: [web]
  → 有 Firecrawl API key 时不出现
  → 没 key 时才作为降级方案露出

这意味着 100 个 Skill 中可能只有 15 个在当前场景可见。其他 85 个虽存在，但不占模型注意力。

为什么 MCP 不能也做成”按需加载”

这里有一个隐藏的经济机制——前缀缓存（Prefix Caching）。LLM 服务商会记住已经算过的 System Prompt，如果下一次请求的 System Prompt 没变，直接复用结果，只算新增的对话内容。这能省一大笔 token 费用。

MCP 把工具定义放在 System Prompt 里。 如果改成”用到哪个 MCP 才把哪个加载进 System Prompt”，那 System Prompt 每轮都在变 → 前缀缓存报废 → 每轮要从零重算整个 System Prompt → 反而更贵。所以 MCP 宁可交”垃圾税”（全量加载、次次带着），也不敢动 System Prompt——稳定 = 缓存命中 = 省钱。

Skill 把正文放在对话中间，不走 System Prompt。 Level 0 目录放 System Prompt（稳定，缓存不破），Level 1 正文作为 tool_result 注入对话。对话历史本来就每轮在变、前缀缓存本来就不覆盖，所以注入 Skill 正文没有额外的缓存损失。两头都不得罪。

MCP 在 Harness 层（System Prompt），是固定房租——交了省缓存，不交没缓存。 Skill 在 Agent Loop 层（对话中间），是按需外卖——吃什么点什么，不吃不花钱。

未来的方向：MCP 的”渐进式公开”

MCP 目前做不到按需加载，不是因为它本质上做不到，而是因为 MCP 协议的设计假设是”工具发现是一次性的”——Server 启动 → 暴露工具列表 → Agent 连接 → 工具定义进入 System Prompt → 不再变化。动态连接/断开的模式需要协议层面支持”会话中途的热插拔（Hot Swap）“，目前标准没有覆盖这个场景。

但这条路是通的。如果未来 MCP 协议支持”工具渐进式公开”——像 Skill 一样，Level 0 放一个轻量目录在 System Prompt，具体工具定义在 Agent 表达意图时动态注入对话中间——那 Mario 对 MCP 的核心批评（垃圾税）就不再成立了。

这不是不可解的问题，只是 MCP 协议还不够成熟。当那一天到来，MCP 和 Skill 的底层哲学——“按需消费 token”——将走向统一。

坦率的边界

如果 Hermes 真的用了五年，积累了 500 个 Skill，Level 0 目录也会有 500 行 ≈ 15,000 tokens。会有压力。

但区别在于：

• MCP 的臃肿是立竿见影——装三个当天就痴呆
• Skill 的臃肿是渐进式——自清理机制在对抗，且目录远轻于全量定义

核心比喻

MCP 是不管用不用都塞进脑子的垃圾税。Skill 是书架上有一本目录，需要哪本抽哪本——书架大一点没关系，你不会每次进书房都把 500 本书摊在桌上。