開一個新 session，第一句話之前 context window 已經被佔掉一塊。這塊有多大、由哪幾項組成、哪一項裁掉最有效，要量過才知道。Hermes 有一個離線指令可以直接把它拆開，以下是量測方法與實際數字。

量測方法與條件

hermes prompt-size 報的是一個全新 session 的固定開銷，官方說明列出的欄位是 system prompt 總量、技能索引、記憶、使用者檔案與工具 schema JSON，並且明講離線執行，量測本身的配額用量為零。

它只有兩個旗標：

• --platform：模擬 cli、telegram、discord 等通道
• --json：輸出可重複比對的結構化結果

以下所有數字的量測條件如下，換一組條件數字就會不同：

• profile：空 profile，記憶為空，MCP server 數量為零
• 模型：gemini-3.5-flash-lite
• 單位：UTF-8 byte
• 量測日期：2026-09-18，Hermes v0.21.0

報表的單位是 UTF-8 byte，hermes_cli/prompt_size.py 的 _bytes() 算的是 len(s.encode("utf-8"))，指令輸出的只有這一種單位，而 context window 的上限以 token 計，token 數又取決於各家模型自己的 tokenizer，因此以下的 byte 數用於同一組條件之間的差分比較，不換算成剩餘的 token 額度。

基準線：固定開銷 54 KB

在 cli 通道、專案目錄下執行的結果：

$ hermes prompt-size
Prompt-size breakdown (platform=cli, model=gemini-3.5-flash-lite)

  System prompt total :   20,010 B  (19.5 KB, 19,556 chars)

  Major blocks:
    skills index       :    5,076 B  (5.0 KB)
    memory             :        0 B  (0.0 KB)
    user profile       :        0 B  (0.0 KB)

  Tool schemas         :   34,093 B  (33.3 KB, 20 tools)

兩大項相加是 54,103 B：

工具 schema 比整個 system prompt 還大七成。 要縮固定開銷，改 system prompt 的效益低於裁工具。

記憶與使用者檔案目前都是 0 B，這是空 profile 的狀態，兩者會隨使用增長。

system prompt 內部分三層

同一份報表把 system prompt 依變動頻率拆開：

技能索引 5,076 B 計在 volatile 這一層，佔 system prompt 總量的四分之一。hermes_cli/prompt_size.py 的註解寫明它從 stable 移了出來，理由是技能改動不要作廢已快取的身分前綴，stable 那一列的標籤保留了舊的歸屬。

佔用量由 schema 的大小決定

工具 schema 依 toolset 拆開之後，數量與 byte 各自獨立：

• 單一工具的成本差距是 4.4 倍：delegation 的一個工具 3,751 B，vision 的一個工具 845 B
• 四個檔案工具合計 5,404 B，一個 delegation 工具 3,751 B
• 拿掉一個參數複雜的工具，省下的比拿掉四個便宜的工具多

工具的裁減效益由 schema 的 byte 決定

技能索引：漸進式揭露的實際比率

技能的常駐成本與它的完整內容差三個數量級：

58 個技能全部索引進去共 5,076 B，平均每個約 87 B。完整的 SKILL.md 只有在模型判定該技能相關、真的要用時才會被讀進來。

掛技能與掛工具的成本結構不同。 技能是每個約 87 B 的常駐加上用到時才付的讀取成本，工具 schema 則是從第一個 token 就全額計入。

通道改變 system prompt，工具 schema 維持同一個值

同一個 profile 換三種通道量測：

• 三個通道的工具 schema 完全相同
• 差異只有 3.6 KB，集中在 stable 與 context 兩層
• 訊息平台的 context 這一層是 0，執行目錄只存在於 cli

執行目錄會改變量測結果

同樣是 cli 通道，換一個目錄執行：

差距 3,190 B。那個專案目錄裡查無 AGENTS.md、CLAUDE.md 與 .cursorrules，這 1.9 KB 來自目錄本身的其他內容。

用來做決策的數字，只有在實際會執行的目錄下量才成立。 在空目錄量一次然後套用到所有情境，會低估將近兩成。

兩個旗標的實際效果

--ignore-rules 與 --safe-mode 各量一次，結果不對稱：

• --ignore-rules 之後報表的每一個數字維持原值，context 那一層仍然是 1,902 B
• --safe-mode 動到的主要是工具：web 這一組兩個工具整組消失，code_execution 的 schema 從 2,955 B 縮到 2,496 B，system prompt 只少了 14 B

要確認 --ignore-rules 對執行期注入的抑制效果，要從實際執行的行為去看，這份報表的範圍止於固定開銷。

這些數字改變了什麼取捨

固定開銷的量測結果直接決定裁減的順序，順序反了就是花力氣在 37% 的那一半

心得

system prompt 是唯一看得到全文的那一份，身分宣告、行為規則、技能索引都寫在裡面，讀起來就很長，工具 schema 則是程式產生的 JSON，平常只會看到工具的名字。量出來是 34 KB 對 20 KB，看得見的那一份是小的那一個。

大的那一份還隨操作習慣成長，每接一個 MCP server 就多一批工具，參數描述寫得越詳細佔得越多，工具描述的品質與 context 的開銷互相拉扯。

佔最多的那一項，平常只以工具名稱的形式出現在眼前

明天

Session 的生命週期、context 壓縮的觸發點，以及狀態怎麼回復。