前陣子我發現一個現象：Hermes Agent 第一次發話時的初始上下文，從之前的 1.6K tokens 左右，悄悄爬升到了 2.8K tokens，增幅接近 75%。
起初以為只是個人設定差異，結果去 Reddit 的 r/hermesagent 一看——好家伙，幾乎 everybody 都在抱怨同樣的事。
這篇就來好好聊聊這個問題：從發現、原因分析、社群反饋到實戰解法，一次講清楚。
什麼叫「初始上下文」？為什麼它很重要？
在深入之前，先釐清一個概念：Hermes Agent 每次發話（無論你只打一個「hi」），都會把完整的 system prompt 送給模型。這包含：
- 核心行為規則與 persona
- 所有已載入工具的 schema 定義
- Skill 清單（名稱 + 描述）
- AGENTS.md（開發者指南）
- Memory、User Profile、SOUL.md 等個人設定
這些全部打包在一起，就是所謂的「初始上下文」或「system overhead」。
為什麼重要？ 因為這塊 overhead 是固定成本。你發一句「今天天氣如何」和發一段 5000 字的程式碼需求，初始上下文幾乎是一樣的。對 token 計費的模型來說，這意味著你在為「沒用到的東西」付費。
更糟的是，如果這個 overhead 持續膨脹，長期下來就是一筆可觀的開銷。
1.6K → 2.8K：增長從何而來？
根據 Reddit 社群的深度 audit，Hermes 每次發話的 token 組成大致如下：
| 組成部分 | Token 佔比 | 說明 |
|---|---|---|
| 工具定義 (Tool Schemas) | ~38% | 50 個工具的 schema，預設全部載入 |
| AGENTS.md | ~22% | 開發者指南，在 repo 內會自動載入 |
| MCP 工具 | ~9% | 如 Shopify 等第三方整合 |
| Skill List | ~7% | 279 個 skills 的名稱+描述 |
| Memory / Profile / Persona | ~12% | 個人設定與記憶 |
| System Prompt | ~12% | 行為規則、格式規範 |
以一個預設安裝來說，初始上下文大約落在 14K–16K tokens。但如果你把 AGENTS.md、MCP 工具、以及大量不用的 skills 排除，可以壓到 4K–6K。
你觀察到的 1.6K → 2.8K 增長，最可能來自三個因素：
- Skill List 持續膨脹：官方 skill hub 不斷新增技能，
<available_skills>區塊每次更新都會吃掉更多 tokens。即使大部分技能根本不會用到。 - AGENTS.md 內容增加：新版可能加入了更多預設規則和最佳實踐。
- Tool Schemas 增加：新版可能加入了新工具，每個工具的 schema 都會增加上下文大小。
社群大震盪：大家都在燒 token
2026 年 5 月到 6 月之間，r/hermesagent 的 token bloat 議題幾乎成了現象級討論。以下是幾個標誌性的帖子：
🔥 「每次發話花 50K+ tokens 為什麼？」（2026-05-15）
一位新手用戶發現，每次發一句話都燒掉 50K+ tokens，不管訊息多短。有人回覆說這其實算正常——Hermes 的最小上下文窗口已經超過 64K tokens，加上 tool calling 的開銷，50K 確實不算誇張。
💥 「上下文超巨大…Hermes 變大但不變好」（2026-05-22）
另一位用戶抱怨系統 prompt 吃掉大量 context，導致在 Codex 上不到 5 分鐘就燒完 5 小時用量，而且一直在觸發 context compression。
📊 「我在預設安裝砍了 71% token overhead」（2026-05-27）
用戶 Jonathan_Rivera 實測發現一個「default-merging bug」——router predictions 是疊加在所有工具上，而不是替換。修掉之後：
- 簡單訊息（“hi”, “."）：從 14,200 → 4,136 tokens
- 一般任務：從 14,200 → 5,000–9,600 tokens
- 零品質退化，零 hard failure
📝 「初始 Prompt 大小與 Cache 失效」（2026-05-26）
這個帖子提到了一個有趣的細節：Claude Code 的 CC 2.1.88 版本引入了 partial compaction，修掉了約 1,627 tokens 的 system prompt overhead。這說明官方也意識到這個問題，並在做微調。
官方已知的 Issue
Nous Research 的 GitHub 上，至少有四個相關 issue 正在追蹤：
| Issue | 問題 |
|---|---|
| #22620 | Skill list bloat 造成上下文膨脹（10-15K tokens） |
| #23767 | 切換 model 後 prompt 超過 context window |
| #40803 | Context compaction 無限循環 bug |
| #32048 | 最小 context window 64K 對小模型太高 |
其中 #22620 最貼近你的問題——skill list 預設全部注入 system prompt，243 個 skills 光這個區塊就吃掉 4,339 tokens。
實戰解法：怎麼把 token 壓下來？
這裡整理社群提出的幾種解法，從輕到重排列：
解法一：手動禁用不用的 Skills（最簡單）
在 config.yaml 中設定：
skills:
disabled:
- gaming.minecraft-modpack-server
- gaming.pokemon-player
- smart-home.ohhue
- social-media.*
有人手動禁用 90 個不用的 skills，直接減少 37% 的上下文。
解法二：調整 Context Compression 參數
預設的 compression threshold 是 0.50，太早觸發壓縮。調整為：
compression:
threshold: 0.75
target_ratio: 0.25
protect_last_n: 30
這樣可以減少不必要的壓縮次數，同時保留更多有效上下文。
解法三：Router-first 架構（效果最顯著）
這是 Reddit 上評價最高的解法。核心概念是：只載入需要的工具，而非全部。
用戶 Jonathan_Rivera 實測從 14,200 → 4,136 tokens（砍 71%），而且零品質退化。原理是修掉了 default-merging bug，讓 router 正確替換而非疊加工具定義。
解法四：使用 Hermes-Talaria 輕量版
Hermes-Talaria 是一個官方 fork，預設載入較少的 skills 和 tools，專注於初始 profile load 的優化。適合想要「開箱即用但別太肥」的使用者。
解法五：Auxiliary Model Offloading
把視覺、網頁提取、壓縮等任務丟給免費的輕量模型（如 gemma-4-26b-a4b-it、nemotron-3-super-120b-a12b），保留主模型的 context 給核心推理。
我的建議：從 audit 開始
如果你也發現 token 消耗異常，建議先做一件事：audit 你的初始上下文。
看看你的 <available_skills> 區塊有多大，AGENTS.md 有多少行，工具定義占了幾個百分比。找到最大塊的那個，優先處理。
不要一上来就砍所有 skills——先了解你的 Hermes 每次發話到底在為什麼付費，再針對性地優化。
結語
Hermes Agent 的上下文膨脹問題不是 bug，更像是「成長的痛」。隨著功能越來越多、skill hub 持續擴充，system overhead 自然會水漲船高。
官方已經在 CC 2.1.88 中引入了 partial compaction，GitHub 上也有多個 issue 在追蹤。但在那之前，善用社群的解法，你的 token 用量絕對可以大幅降低。
最後一句話：不要讓 Hermes 替你決定要花多少 token，你才是那個掌控開銷的人。
有任何優化心得也歡迎分享，一起讓 Hermes 變得更輕、更快、更省錢。