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 就是那条冷路径消失的那一版。