Hermes Agent 0.19 补齐延迟与结果持久化
Quicksilver 集中交付低延迟、逐命令审批、秘密来源与两类耐久交付机制。
本文要点
- 首轮阻塞路径被拆分，项目自测的 CLI 冷提交至请求分发显著缩短。
- 被标记命令从默认人工审批转为逐条 LLM 复核，显式模式保持不变。
- 秘密可由 Bitwarden 和 1Password 加载，并保留优先级与变量来源。
阅读辅助
先看数字、证据和来源，再读正文。
v0.19.0 在目标窗口内正式发布，功能代码则在此前两周陆续合并。
2026-07-06 04:37 UTC · PR #59332 合并，项目自测将 CLI 冷启动提交至请求分发从约 4.3 秒降至 0.9 秒。
Hermes Agent 0.19 值得看的地方，不是一次性塞入更多模型名称，而是把 Agent 常驻运行时最容易暴露的四类摩擦放进同一个正式版本：首次请求前的阻塞、危险命令审批、秘密加载，以及任务完成后结果能否跨进程故障送达。
确定事实是，Nous Research 在 2026 年 7 月 20 日 18:35:55 UTC 发布 GitHub Release；换算北京时间是 7 月 21 日 02:35:55。发布提交、签名标签与 Release 在约半分钟内依次生成，包版本从 0.18.2 升至 0.19.0。因此，本期的 news peg 是 Quicksilver 正式成版并进入可安装发布渠道。
不确定部分主要在效果数字。所谓约 80%，是项目方把 CLI 冷进程的“提交到请求分发”从约 4.3 秒测到 0.9 秒；所谓 14×，是桌面端对 128KB 长回复进行 200 次流式刷新时，Markdown splitter 的累计 CPU 从 990 毫秒降至 72 毫秒。两者都有直接 PR、代码与测试说明，但都没有第三方复现。
对开发者而言，升级带来的直接收益是更短的首轮等待、可接入 Bitwarden 与 1Password，以及进程重启后的结果恢复。对管理员而言，升级前更需要核对的是默认审批模式变化、秘密来源优先级和“至少一次”重送可能产生的重复消息，而不是只看速度宣传。
先把版本日与功能合并日分开
Quicksilver 的 Release 汇总口径是相对 v0.18.0 约 2245 次提交、约 1065 个合并 PR。这是一段版本窗口的累计量，不是 7 月 20 日当天突然合入的代码量。本文核对的核心功能 PR 最早在 7 月 6 日合并，最晚在 7 月 19 日合并；7 月 20 日新增的是版本提交、签名标签与发布说明。
| 项目 | 直接相关 PR 合并时间 | 0.19 中形成的状态 | 不能写成 |
|---|---|---|---|
| 首轮提交至请求分发优化 | 7 月 6 日 | 随 v0.19.0 正式成版 | 7 月 20 日才首次写入代码 |
| Bitwarden 与 1Password SecretSource | 7 月 6 日 | 成为本版本秘密加载入口 | Hermes 托管了完整密码库 |
| 智能审批默认值 | 7 月 12 日 | 新配置默认使用 smart | 所有旧配置被强制改写 |
| 后台委派完成事件账本 | 7 月 13 日 | 跨重启恢复完成事件 | 任意运行中任务都会自动重跑 |
| 桌面 Markdown splitter 优化 | 7 月 18 日 | 长回复流式分块复用已结集 | 整个桌面应用快 14 倍 |
| 最终回复交付账本 | 7 月 19 日 | 网关最终回复可在重启后重送 | 所有消息类型都恰好投递一次 |
| v0.19.0 Release | 7 月 20 日 | 上述改动进入 Quicksilver 正式版 | 每项功能都是当天独立发布 |
发布说明还写明本版本卷入约 3300 个关闭 issue与 450+ 社区贡献者。不过，GitHub 签名标签的消息写的是 420+，当前 Release 正文写的是 450+。两份官方元数据存在口径差异，本文只把 450+视作当前发布页自报，不据此推导精确贡献者增量。
两个速度数字不是同一个基准
最容易误读的是约 80%。PR #59332 的原始测试对象不是模型开始生成首 Token 的纯网络 TTFT，而是冷进程下 CLI 从用户提交到请求分发的前置路径。PR 给出的环境包含 OpenRouter，以及设置了 Discord bot token 的冷进程；改动把 Discord 能力探测移出阻塞路径，跳过已知非 Ollama 提供商的无效探测，并预热 Python 工具链与部分导入。
| 原文措辞 | 忠实中文表述 | 适用边界 |
|---|---|---|
cold submit→request-dispatch ~4.3s → ~0.9s | CLI 冷提交到请求分发约从 4.3 秒降至 0.9 秒 | 项目方特定环境自测，不是模型端首 Token 时间 |
agent-side (non-import) 2.9s → 0.6s on every platform | 非导入的 Agent 侧前置耗时约从 2.9 秒降至 0.6 秒 | 代码路径覆盖网关、TUI、桌面与 cron，不等于各端完整端到端延迟相同 |
~80% cut | 以上述 4.3 秒为基准，降幅约为 79%，官方取整写约 80% | 不能改写成模型推理提速 80% |
这项优化的价值在于减少请求真正发出前的等待。它不会改变上游模型的排队、首 Token 网络延迟、生成吞吐和工具执行时间。换言之，用户可能更快看到请求进入模型，但长任务的总体完成时间仍主要由模型、网络与工具链决定。
第二个数字 14× 来自完全不同的桌面端基准。PR #67154 测试的是一条 128KB 回复经过 200 次流式刷新时，Markdown 分块器反复解析全文的 CPU 开销。改成复用已经稳定的块、只解析尾部后，累计 splitter CPU 从 990 毫秒降至 72 毫秒，单次刷新从 4.95 毫秒降至 0.36 毫秒，按前后比约为 13.75×。
这个结果只说明桌面端长流式 Markdown 的 splitter CPU 降低。PR 明确写道，小于 16KB 的普通回复原本约为每次刷新 1 毫秒，优化前后基本不受影响；基准还使用 Node 24 与 Apple Silicon。它不能泛化为桌面应用整体性能提升 14×，更不能扩展到 CLI、网关、模型输出速度或所有硬件。
默认审批改变的是决策入口
智能审批的准确状态是“新配置和默认配置的 approvals.mode 由 manual 改为 smart”。显式选择 manual 或 off 的配置保持不变，因此升级不能被概括成“所有用户都自动打开 LLM 审批”。
当 Hermes 准备执行一条被规则标记的命令时，smart 模式会让独立 LLM reviewer 评估这一条准确命令。一次 APPROVE 不再为整个会话的同类 detector pattern 发通行证；后续即使出现模式相似的命令，也会重新评估。发布说明还把它与用户自定义 deny rules 和 /deny <reason> 放在一起：前者即使在 yolo mode 下也可阻断命令，后者把拒绝原因反馈给 Agent。
| 模式或规则 | v0.19 的行为 | 管理边界 |
|---|---|---|
| 默认配置 | smart | 只改变新建或采用默认值的配置 |
显式 manual | 保持人工确认 | 不被升级自动改为 smart |
显式 off | 保持关闭 | 风险由管理员原有选择承担 |
| smart 的一次批准 | 仅覆盖当前准确命令 | 不授权后续相似命令 |
| 用户 deny rule | 可阻断命中命令 | 仍需验证规则覆盖率与绕过路径 |
这种设计减少了审批疲劳，却没有证明审批模型不会犯错。项目 PR 报告了两条被标记命令触发两次独立审查和 300 项定向测试；它没有公布真实危险命令上的误放行率、正常命令上的误拦截率，也没有给出不同 reviewer 模型之间的差异。企业使用时仍应把审计日志、强制 deny rules 与最小权限环境放在 LLM 判断之前。
密码管理器接入不是把整个保险库交给 Agent
秘密管理改动由 PR #59498 提供。它建立统一的 SecretSource 接口，并把 Bitwarden 与 1Password 作为首批来源。Hermes 在加载阶段通过来源适配器获取所需变量；1Password 使用显式 op:// 引用，Bitwarden 可作为批量来源。多个保险库可同时启用，系统按确定性优先级处理冲突，并记录每个变量来自哪个来源。
这里的适用范围是“秘密变量加载”，不是“让 Agent 自由浏览密码管理器”。1Password provider 会校验引用，通过 op read 逐项读取，并以受限子进程环境运行；Bitwarden 与 1Password 的冲突遵循显式映射优先于批量来源的规则。PR 还描述了缓存权限、超时、冲突告警与 per-variable provenance，但这些都是项目实现与测试结果，不能替代对本地进程、日志、插件和备份路径的独立安全审计。
对团队最实际的变化，是 API key 不必长期写在普通明文 .env 中，同时管理员能知道某个变量由哪一来源提供。新的风险则转向密码管理器 CLI 会话、来源优先级、缓存文件和插件接口。若同名变量在多个保险库存在，冲突告警是否被运维流程及时处理，可能比“支持几个密码管理器”更重要。
两类账本解决的是不同丢失窗口
发布说明把“后台委派结果耐久化”和“最终回复交付账本”放在相邻位置，容易被合并成一个无所不包的恢复系统。实际上，它们是两个 PR、两类记录和两个恢复边界。
| 账本 | 记录对象 | 崩溃后动作 | 明确不保证 |
|---|---|---|---|
| 后台委派账本，PR #63494 | 子 Agent 的派发所有权、终态结果与完成事件 | 重启后由具备所有权的消费者恢复未送达完成事件 | 被遗弃的运行中任务不会自动重跑；只标为 unknown |
| 最终回复账本，PR #67181 | 网关中已生成但尚未确认平台送达的最终回复 | 下次启动重新认领并重送 | 不是恰好一次；中途崩溃可能导致可见重复 |
最终回复账本在平台发送前把 obligation 写入 state.db，发送确认后再标记 delivered。如果网关在发送中途死亡，系统无法确定平台是否已经收到，于是下次启动会重送，并添加“Recovered reply — may be a duplicate”提示。这是诚实的“至少一次”语义：优先避免静默丢失，同时承认重复消息无法完全消除。
它的范围也有硬边界。记录点位于消息平台最终回复的基础适配器路径，覆盖 Telegram、Discord、Slack 等经过该 chokepoint 的渠道；斜杠命令回复、临时回复和空回复会跳过。Cron 与 proactive message 仍由另一条 DeliveryRouter 路径负责，不在这份账本的覆盖范围内。账本调用采用 best-effort，以免数据库问题反过来阻塞发送。
恢复也不是无限重试。处于不确定状态的记录最多尝试 3 次，或在 24 小时后进入 abandoned；已完成记录还有 7 天保留和 500 行上限。后台委派账本同样使用至少一次交付与所有权检查，但对进程死亡时仍处于 running 或 finalizing 的记录只标为 unknown，不会假装知道任务是否完成，也不会自动再次执行可能带副作用的任务。
为什么这组改动比模型目录更重要
Agent 从一次性 CLI 工具变成常驻服务后，最难处理的往往不是“会不会调用更多模型”，而是四段契约能否连接起来：请求何时真正发出，危险动作由谁批准，秘密如何进入进程，以及结果生成后谁负责确认送达。0.19 把这些问题放进同一个发行版，说明 Hermes 的竞争变量正在从功能覆盖转向运行时摩擦与故障语义。
性能优化减少的是模型调用前的固定成本。固定成本从 4.3 秒量级降至 0.9 秒，对短问答与频繁唤起尤其敏感；长任务中的占比则会迅速下降。桌面 splitter 优化同理，它主要帮助超长流式回复，普通短回复不会获得同样幅度的收益。把两者拆开，才能知道哪些用户会真正感到变化。
审批与秘密来源改变的是权限边界。逐命令 smart review 比会话级模式通行更细，但最终仍由一个概率模型参与安全决策；SecretSource 减少明文配置暴露，却把信任扩展到密码管理器 CLI、缓存和来源协调器。它们都是更好的工程默认值，不是“默认安全”的证明。
耐久账本改变的是故障语义。过去网关在生成答案后、平台确认前崩溃，用户可能付出一次模型调用成本却看不到答案；现在系统宁可提示可能重复也要重送。这个选择适合消息型 Agent，但对有副作用的外部动作仍不能照搬。回复重送与任务重跑必须分开，正是这两个账本分别建模的原因。
早报判断是，Quicksilver 把 Agent 运行时不可消除的不确定性摆到了产品主线上。性能数字被限定在具体路径，审批被限定到准确命令，交付恢复明确采用至少一次而非恰好一次；这些边界比一个笼统的“更快、更安全、更可靠”更有价值。
其中最成熟的设计是结果账本对重复风险的处理。分布式发送无法在网关崩溃时总能判断远端是否已收到，系统没有假装实现 exactly-once，而是用恢复提示暴露歧义。这会产生偶发重复，却比静默丢失更可审计，也让运维人员知道需要在哪一层做幂等。
最需要警惕的是智能审批默认值。把人工疲劳交给 LLM reviewer，确实能提高 Agent 常驻运行的可用性；但默认开启会把安全模型的误差直接带入更多新安装。若后续没有误放行率、模型选择、审计记录和组织级策略，便利性可能先于治理能力扩张。
性能部分则应保持克制。4.3 秒降至 0.9 秒是可信度较高的项目自测线索，990 毫秒降至 72 毫秒也有具体基准与代码路径；二者仍不是跨硬件、跨提供商的产品级基准。真正决定这次优化能否成为长期优势的，是第三方复现和回归数据，而不是发布页上的倍数。
接下来验证哪些硬指标
第一，看性能复现。首轮测试需要拆出 Python 导入、Agent 初始化、网络握手、提供商排队与模型首 Token；至少覆盖本地模型、OpenRouter、其他云提供商、不同硬件和冷热缓存。桌面基准则应同时报告短回复、长回复、复杂表格、代码块与数学公式的 CPU、内存和掉帧。
第二，看智能审批的错误账本。项目应公布危险命令集上的误放行率、正常命令上的误拦截率、人工改判率，以及 reviewer 模型变化后的回归结果。管理员还需要能锁定模式、集中下发 deny rules，并导出逐命令判定依据。
第三，看秘密来源的独立审计。重点不是再增加提供商数量，而是核对 CLI 子进程环境、缓存权限、日志脱敏、插件注册、变量冲突与来源追踪。任何一个环节泄漏，都可能抵消不再使用明文 .env 的收益。
第四，看账本的真实恢复数据。最有价值的指标包括待重送记录数、成功恢复率、重复投递率、进入 abandoned 的比例、平均恢复时延，以及各消息平台是否存在差异。Cron 与主动消息仍走另一条路径，也应单独公布可靠性边界。
第五，看发布后的修复节奏。约 2245 次提交和跨 CLI、网关、桌面、TUI、秘密与数据库的改动扩大了回归面。若短期出现补丁版，应逐项核对修复对应的 commit 与 release 时间，不能再把后续修复倒灌成 0.19 首发能力。