Hermes Agent v0.19.0：水银快闪版，AI Agent 终于开始“跑得快、跑不丢、管得住”

⚡ 这不是普通更新，而是一次“速度重构”

Hermes Agent v0.19.0 的官方名字很有意思：The Quicksilver Release。

水银、快银、Quicksilver，核心不是“多了几个按钮”，而是让整个 Agent 从启动、思考、调用工具到返回消息，都减少等待和丢失。

官方给出的规模也相当夸张：从 v0.18.0 到这一窗口，大约有：

• 2,245 次提交；
• 1,065 个合并 PR；
• 2,465 个文件发生变化；
• 约 30 万行新增、3.6 万行删除；
• 约 3,300 个 issue 关闭；
• 超过 450 位社区贡献者参与。

这也解释了为什么 v0.19.0 的变化看起来不像一个小版本：它更像是把过去一段时间积累的大量基础设施改造，集中打包成了一个稳定节点。

🏎️ 第一重升级：首轮响应快了约 80%

以前，Hermes 在第一次真正向模型发起请求前，可能要经历初始化 Agent、探测能力、检查本地服务等步骤。官方 Release 给出的对比是：冷启动阶段从大约 4.3 秒降低到 0.9 秒左右，减少约 80%。

这类改进不一定会出现在功能列表里，却会直接影响“这个工具好不好用”。

因为用户对 Agent 的第一印象，往往不是模型最终回答得多聪明，而是：

我按下回车后，它是不是马上有反应？

这次改造覆盖了 CLI、Gateway、TUI、桌面端和 Cron 任务，而不是只优化某一个入口。具体包括：

• 将 Discord 能力探测移出关键路径；
• 对探测结果做基于 Token 的 24 小时磁盘缓存；
• 对已知非 Ollama provider 跳过不必要的探测；
• 删除阻塞 Agent 初始化的工作；
• 缓存 Prompt 构建和时区解析；
• 混合工具批次重新分段，尽量恢复并发；
• 避免每次请求都重复序列化 Base64 数据。

这说明 Hermes 团队优化的不只是“代码执行速度”，而是首轮感知延迟：用户什么时候开始看到系统真的动起来。

🧠 第二重升级：不再对着 Spinner 等模型思考

v0.19.0 默认打开了 display.show_reasoning。对于支持推理流的模型，用户可以实时看到思考过程，而不是盯着一个转圈动画等待几十秒。

同时，响应框从“按行刷新”改成了更细的“按 Token 绘制”，终端和 TUI 的反馈会更连续。

这件事的价值不只是好看。

对 Agent 来说，长任务中的等待特别容易让人误判：用户可能以为程序卡住、网络断了，或者工具没有执行。把推理流和回答流逐步显示出来，可以让等待变成可观察状态。

不过，这也带来一个边界：实时展示的 reasoning 不应该被当成最终事实或完整解释。它更像一种运行状态反馈，不能替代最终答案、工具结果和日志。

🖥️ 第三重升级：桌面端终于开始为“大上下文”优化

Hermes Desktop 这次有 20 多个针对性能的 PR。官方特别提到：长回复在 Markdown 拆分器上的 CPU 消耗最多降低约 14 倍；大型 diff 不再因为一次性运行完整 Shiki 高亮而冻结审查面板；大型会话之间切换也更顺滑。

背后的思路很典型：不要让每一个 Token 都触发整个界面重新计算。

桌面端这次集中处理了很多“看不见但很烦”的性能问题：

• 流式输出时不再每个 Token 都重绘侧栏和工具行；
• 工具参数和结果不再被无条件 JSON.stringify；
• diff 审查窗采用虚拟化，只渲染可视区域；
• 会话切换时减少布局级联重排；
• 鼠标悬停到 Profile 时预热后端连接；
• 隐藏面板延迟到空闲时挂载；
• 侧栏会话数据尽量通过一次 Profile 数据库读取完成；
• 分割栏尺寸调整使用 requestAnimationFrame 合并刷新。

这是一种从“功能开发”转向“交互工程”的信号：当 Agent 产生越来越长的日志、diff 和工具轨迹时，界面本身也必须成为高性能系统。

🔐 第四重升级：智能审批默认开启，但控制权没有消失

v0.19.0 将 Smart Approvals 设为默认模式。

以前，Hermes 遇到需要审批的命令，可能频繁询问用户：是否执行？是否允许？对于连续任务，这会变成审批疲劳。

现在，系统可以让一个独立的 LLM 审查器对被标记的命令进行判断。重要的是，每次审查只覆盖当前这一条具体命令，不会因为某条命令通过，就自动放行后续同模式命令。

这是一种比较谨慎的自动化：

• 让低风险、重复性的审批减少人工打断；
• 不把一次批准扩大成永久授权；
• 仍然允许用户定义 deny rules；
• 即使打开 yolo 模式，用户拒绝规则仍然可以阻断命令；
• /deny 可以告诉 Agent 为什么拒绝，帮助它调整方案。

这里的关键不是“让 AI 替你批准一切”，而是把审批从纯人工确认，变成命令级、可解释、可拒绝的风险判断。

当然，智能审批并不等于安全证明。审查模型可能误判，用户定义的 deny 规则和命令权限边界仍然必须认真配置。

🧾 第五重升级：API Key 不必继续裸奔在 .env 里

v0.19.0 新增了可插拔的 SecretSource 接口，支持从 Bitwarden 和 1Password 在加载时读取密钥，也支持 op:// 引用和多个 Vault。

这解决的是一个很现实的问题：很多 Agent 项目为了方便，把 API Key 直接放进明文 .env。一旦日志、备份、截图或错误上传把文件带出去，后果就很麻烦。

新的 SecretSource 机制提供了：

• 多个 Vault 同时启用；
• 确定性的优先级；
• 冲突警告；
• 每个变量的来源记录；
• 未来通过插件扩展其他密码管理器的接口。

这项能力的意义不在于“支持了两个密码管理器”，而在于 Hermes 正在把凭证来源从硬编码环境变量，提升为可审计、可扩展的配置层。

🧵 第六重升级：后台 Agent 不会再悄悄消失

Hermes 的 delegate_task 可以把工作分派给子 Agent。v0.19.0 进一步加入了实时 transcript：子 Agent 启动后，可以马上 tail -f 它的日志，查看工具调用、返回结果和流式回复。

更重要的是，后台 delegation 的完成结果变得持久化。

过去，一个后台任务已经完成，但 Gateway 恰好在发送结果前重启，结果可能就消失了。现在 Hermes 引入了持久化的 delivery-obligation ledger：

1. 最终回复先记录到 state.db；
2. 再尝试发送到 Telegram、Discord、Slack 等平台；
3. 如果发送过程发生崩溃，下一次启动时继续检查；
4. 只有经过所有权校验后，才重新投递结果。

这解决了 Agent 系统里一个非常严重、但经常被忽略的问题：任务完成了，不代表结果一定送达了。

对于几分钟甚至几小时的后台任务，可靠交付和模型能力同样重要。

🌐 第七重升级：一个 Gateway，多个 Profile

v0.19.0 支持一个复用 Bot Token 的多路 Gateway，将不同 Guild、频道或线程路由到不同 Profile。

例如：

• 工作 Discord 进入 work Profile；
• 个人频道进入 personal Profile；
• 每个 Profile 使用独立的配置、Skills、Memory 和 Secrets。

这比简单地给不同对话设置不同 System Prompt 更彻底。Profile 是运行边界：它可以承载不同模型、工具、记忆和凭证，不同场景之间不会因为共享状态而互相污染。

同时，新的 Multiplex 加固也避免一个配置错误的 Profile 拖垮整个 Gateway。

🧰 第八重升级：模型和提供商不再是固定菜单

这一版同时扩展了 Provider 和模型目录：

• Fireworks AI 成为一等 Provider，并提供成本估算；
• DeepInfra 集成进一步加固；
• Upstage Solar 通过适配进入；
• GPT-5.6 的多个版本被端到端接入；
• grok-4.5、kimi-k3、claude-fable-5、claude-sonnet-5 等进入目录；
• LM Studio 支持 JIT 模型加载；
• 可以通过 enabled: false 隐藏不使用的 Provider；
• /model 和桌面模型选择器对同一 endpoint 的模型做更清晰分组。

对用户而言，最实用的变化可能不是“又增加了多少模型”，而是模型选择开始从一张越来越长的清单，变成可筛选、可隐藏、可按成本和能力组织的目录。

🎚️ 第九重升级：推理深度变成独立旋钮

v0.19.0 新增 max 和 ultra reasoning effort 等级，并支持在不同层面控制思考深度：

• CLI、TUI、Desktop 等入口都可以选择；
• 不同模型可以配置不同的 reasoning effort；
• 辅助模型可以单独设置思考深度；
• MoA 预设中，不同槽位可以使用不同 effort；
• /reasoning 可以在当前会话范围内调整。

这对实际工作很重要。并不是每个步骤都值得让模型“想得最深”：

• 代码定位可以快速；
• 架构设计可以深度推理；
• 多个顾问模型可以高 effort；
• 最终汇总器可以保持低延迟。

把思考深度从全局开关变成按模型、按任务、按槽位的控制参数，可以在质量、速度和成本之间做更细的平衡。

🛡️ 第十重升级：安全修补覆盖了整条凭证链

Release 中有一整组安全与可靠性修复，包括：

• Vertex 凭证和项目区域通过 Profile secret scope 管理；
• 敏感环境变量不再随意进入子进程；
• 媒体、视觉、图片生成读取本地文件时走统一凭证读取检查；
• Webhook 服务补齐 body size 上限；
• Telegram 传输错误中隐藏 Bot Token；
• Fireworks Token 前缀加入脱敏规则；
• 浏览器、MEDIA、.env 等文件访问边界继续加固；
• OAuth Token 使用原子写入和 0o600 权限，减少 TOCTOU 风险；
• CI 不再把不可信 Ref 直接插入 run: 字符串；
• Docker 终端增加网络开关和更完整的路径覆盖。

这些修复说明 Hermes 的安全重点正在从“不要把 Key 打印出来”，扩展为凭证从哪里来、进入哪个进程、能读取哪些文件、如何进入日志和 Webhook的全链路治理。

📦 还有哪些值得注意的使用变化？

除了大功能，这一版还带来很多更贴近日常的改进：

• /subscription 和 /topup 可以直接在终端管理 Nous 订阅；
• /model --once 支持只对下一轮请求临时换模型；
• 可以连续加载多个 Skill；
• hermes sessions export 支持 Markdown、HTML、Quarto、Prompt-only 和 Hugging Face trace 等格式；
• 支持更完整的会话过滤、脱敏和压缩后 lineage；
• TUI 可以增量渲染 Markdown；
• Telegram、Discord、Matrix 支持 /reasoning 和 /fast 的原生按钮；
• WhatsApp 支持原生 Poll、位置和更丰富的入站元数据；
• Dashboard 支持粘贴/拖入图片、终端会话保持和重新连接；
• Desktop 增加能力页、Keybind 设置、Worktree 对话框、Profile 色彩和后台任务提示。

这些项目单看都不惊天动地，但它们共同把 Hermes 从一个“可以调用工具的聊天程序”，推向一个更完整的 Agent 操作系统。

🧭 如何理解 v0.19.0：四个关键判断

1. Hermes 开始把“等待”当成产品问题

首轮响应、流式 reasoning、增量 Markdown、虚拟化 Diff，本质上都在回答同一个问题：Agent 很强，但用户不能一直盯着空白屏幕。

2. Hermes 开始把“丢结果”当成可靠性问题

后台 delegation transcript、持久化完成状态和 delivery ledger，说明任务完成与消息送达被拆成了两个必须分别保证的环节。

3. Hermes 开始把“自动化”放进安全框架

Smart Approvals、deny rules、SecretSource、Profile secret scope，不是让系统无限自动化，而是让自动化有边界、有来源、有记录。

4. Hermes 开始从单 Agent 走向 Agent 基础设施

多 Profile Gateway、模型路由、MoA、Skills、MCP、Cron、Kanban、Desktop、Dashboard 和 ACP，已经不再是一个简单命令行助手的功能集合，而是一套可以承载不同工作流的运行时。

🏁 结语：水银快闪，快的不只是第一句话

Hermes Agent v0.19.0 最值得关注的，不是“又加入了多少模型”，而是它在处理 Agent 产品最难的几件事：

• 启动要快；
• 等待要可见；
• 长文本要流畅；
• 后台任务要可观察；
• 完成结果要送达；
• 密钥要有来源；
• 审批要有控制；
• 多 Profile 要彼此隔离；
• 模型、工具和渠道要能持续扩展。

如果说前几版 Hermes 在搭建能力边界，v0.19.0 则是在打磨“规模化使用”的基础设施。

它真正的 Quicksilver 时刻，不是模型回答突然变快，而是一个 Agent 开始具备了长期运行所需要的耐力、速度和可靠性。