v0.14.0 出貨了一摞效能優化，疊起來之後，Hermes Agent 用起來像換了一個程式。release notes 上的三條頭條：
- •冷啟動削掉約 19 秒。 散落在 import 圖、doctor 檢查、模型目錄查詢、歡迎橫幅之間。
- •
browser_console快 180 倍。 一條常駐的 CDP 連線，替掉每次呼叫都開一個 DevTools 會話。 - •Claude prompt cache 跨會話保留 1 小時。
/new之後你那份溫熱的 prefix 快取不會丟。
這裡面沒有一條是「推倒重寫」。每一條都是一串小的、能定位的 PR，專門修一個熱路徑。這篇按 PR 拆給你看——哪兒慢、改了什麼、以及對任何寫 agent 的人來說哪些經驗可以複用。
起點是什麼樣
2026 年 5 月初你跑 hermes，冷啟動路徑大概是這樣：
- 1.Python 直譯器啟動（約 100 ms）
- 2.
import hermes把剩下整張 import 圖都拉起來（約 5–10 s） - 3.
hermes插件發現掃一遍已裝插件（約 2–3 s） - 4.
hermes doctor順序跑 API 連通性探測（約 3–5 s） - 5.skills 索引載入，經常重新從網路拉一遍（約 2–4 s）
- 6.歡迎橫幅渲染（約 1 s）
- 7.提示符出現
到你能開始打字過去了 15–25 秒。這種時長夠讓你出戲了。v0.14.0 這波優化是逐步把上面每一步都修一遍。
冷啟動那一波（10+ 個 PR）
skills 快取 + 適配器 lazy import（#22138）
最大的那一筆。兩件平行改動：
- 1.skills 索引寫到磁碟快取。 之前的行為：每次跑
hermes都重讀 skills 目錄，跑一遍輕量索引。新行為：索引存在一份快取檔裡，只有目錄有變動（看 mtime）才重建。 - 2.重量級適配器 SDK 改 lazy。 之前：import
hermes會順帶 import Feishu SDK、WhatsApp SDK、所有 voice/TTS provider、所有圖像生成 SDK。現在：每個都推遲到首次使用時才載入。你從不用 Feishu，Feishu SDK 就從來不會被載入。
這兩件事都在 #22138 裡，砍掉約 5–8 秒。lazy import 這個套路是默默無聞的英雄——它在整個程式碼庫上機械地鋪開，沒有作為單獨一個有戲劇性的 PR 出現。
已知子指令跳過插件發現（#22120）
你跑 hermes config set X Y 的時候，根本用不到插件發現。hermes tools、hermes model、hermes doctor 也一樣。dispatcher 現在在指令是已知內建時直接短路掉插件發現。絕大多數 CLI 呼叫省下約 2 秒。
models.dev 改 cache-first 查（#22808）
Hermes 會問 models.dev 拿規範模型目錄。v0.14.0 之前每次 hermes 啟動都打一次 HTTP。新版本：先從磁碟快取讀；只在過期了（>24 h）才重新拉。快取命中是約 5 ms，而不是約 200–500 ms（一次網路來回）。
hermes doctor 的 API 探測並行化（#22766）
hermes doctor 檢查「我能不能連上 Nous Portal、OpenRouter、Anthropic、OpenAI」是順序跑的。新版本：asyncio.gather 起來一起跑，順手把那個在非雲機器上經常 timeout 的 IMDS（實例元資料服務）探測去掉。典型情況下 doctor 砍掉約 3–5 秒。
chat -q 跳過歡迎橫幅（#22904）
你在單次查詢模式（hermes chat -q "what's the time"）下，歡迎橫幅就是噪聲。v0.14.0 把這種情況下的渲染跳掉。腳本/自動化場景拿回約 1 秒。
import 圖上散落的延遲化
一長串 PR，每一個延遲一個重型 import：
- •google chat adapter 裡的
google-cloud——首次用到 google chat 時再載入（#22681） - •
QQAdapter、YuanbaoAdapter——透過 PEP 562 在模組層級延遲（#22790） - •teams adapter 裡的
httpx——只在第一次 webhook 呼叫時（#22831） - •
fal_client——只在第一次圖像生成時（#22859）
每個 PR 都不大。疊起來又是 2–4 秒。
快取 Nous 鑑權和 .env 載入（#25341）
hermes tools All-Platforms 那一屏過去會按平台同步跑鑑權探測。快取落地之後，從 14 秒掉到 1.5 秒以下。這一屏功能沒變；只是不再每次呼叫都燒 14 秒的網路時間。
淨效果
把每一筆加起來就是頭條上那 19 秒。單獨看沒有一條驚天動地的；合起來程式就有了反應速度。
browser_console 快 180 倍那段故事（#23226）
Hermes 裡的 browser 工具走的是 Chrome DevTools Protocol（CDP）來驅動一個 headless Chrome。v0.14.0 之前，每一次 browser_console 求值大概是這樣：
- 1.跟 Chrome 開一條新的 CDP WebSocket
- 2.等握手（約 1–2 s）
- 3.把要求值的 JavaScript 發過去
- 4.讀回結果
- 5.關掉 WebSocket
一條連著求值的鏈路——比如 agent 在一步步檢查一個頁面——每次求值大概 1.5 s。典型的「看一眼這個頁面然後跟我說說」流程慢得讓人難受。
v0.14.0 的改法：每個 supervisor 一條常駐 WebSocket，所有 browser 工具呼叫共用。CDP 握手每個會話只發生一次；後續求值跳過 1–2 步，直接發 payload。
結果：每次呼叫的延遲從約 1.5 s 掉到約 8 ms。也就是 約 180×。
這個經驗是通用的。任何地方你的 agent 要打 N 次工具呼叫、每次都開新連線——對於聊天節奏的負載來說，連線池比並行更值錢。總工作量都在建連這一步，不在做事本身。
prompt cache 跨會話保留 1 小時（#23828, #25434, #24778）
Claude 的 prompt cache（Anthropic API 的一項功能）讓你能把一段上下文標成「可快取」。在 TTL 之內的後續請求——歷史上是 5 分鐘——會以低得多的成本和延遲複用那段 prefix。
v0.14.0 之前，Hermes 在會話內已經在用這個：system prompt + 當前啟用的 skill 會被快取，同一段對話裡的命中更快也更便宜。但你一旦跑 /new，快取就失效了，下一段對話從冷開始。
v0.14.0 這一摞三個 PR 把快取 TTL 拉到 1 小時，並且讓快取 key 跨 /new 還能複用。新開的會話第一條回應能蹭上你上一段會話留下的熱快取。對那些一天裡要開很多段短會話的人，這是實實在在的成本+延遲節省。
快取也覆蓋到了 後台 memory review 那一支（#25434）——週期性回看並整合你 memory 檔案的那個行程，現在也吃這層 prompt cache，不用每次都付全價。
這塊還有一個配套的小修：prompt cache key 現在用只到日期的時間戳，快取不會因為跨時區炸掉。Gateway-DB 來回的吵鬧日誌也整理了一遍，可觀測性更好。
這些勝利是怎麼被發現的
作者怎麼定位到這些具體熱路徑的？兩個答案：
- •在真實安裝上做冷啟動 profiling。 拿計時跑
hermes，盯著哪些 import 最慢。然後一個一個挨著收拾。 - •使用者報告「Hermes 卡卡的」。
hermes toolsAll-Platforms 那一屏慢，本來就是一條具體的 bug 報告——一旦定位到，修起來就直接。
沒有任何魔法。這些勝利都是用 python -X importtime、cProfile、加上聽人抱怨，挖得出來的。
寫 agent 的人可以學走什麼
你要是在做自己的 agent，v0.14.0 這一波抽象成幾條規則：
- 1.不用的別 import。 每一個 adapter 和 provider SDK 都延遲載入。import 圖就是你的冷啟動。
- 2.能穩定快取的全快取。 skills 索引、模型目錄、鑑權 token。只在確認 stale 時重新拉。
- 3.複用連線。 一次會話裡要打同一個 API 或 CDP 伺服器超過一次，就一定要把連線握住。
- 4.互相獨立的探測並行跑。 doctor 檢查、健康檢查，任何順序不重要的地方。
- 5.不必要的 UI 別渲染。 歡迎橫幅、裝飾輸出——非互動路徑上跳過。
這裡沒有一條是新的。整套就是任何一個 CLI 都該用的標準效能 playbook。v0.14.0 有意思的地方是把整本 playbook 在一個發版窗口裡全跑了一遍——使用者一升級，第一時間就能感覺到。
你那個 Hermes 五月初要是用著挺糟心，v0.14.0 就是那條冷路徑消失的那一版。