Hermes 0.19.1史诗级更新：十天千项更新，五大亮点

北京时间 7 月 31 日早上，Hermes Agent 发布 v0.19.1，对应标签是 v2026.7.30。

官方对它的定义很低调：Patch Release，也就是补丁版本。

可发布说明里的数字一点都不“小”：

距离 v0.19.0：约 10 天合并 PR：1000+提交：约 2789 次变更文件：约 4748 个新增代码：约 44.2 万行删除代码：约 39.23 万行

这组规模放在普通项目里，已经够做一次大版本了。Hermes 却只把版本号从 0.19.0 提到了 0.19.1。

原因也很直接：这次发布更像一次“稳定标签封包”。过去 10 天进入主分支的大量修复、兼容改造和新平台能力，被集中装进一个正式标签，方便 Docker、托管部署和新安装用户拿到。

完整的分类更新说明、功能亮点和贡献者名单，官方准备留到 v0.20.0 再统一整理。

所以，看到“1000+ PR”先别理解成新增了 1000 多个功能。里面包含：

故障修复旧 PR 重新整理合并自动化测试代码重构平台兼容安装与发布基础设施新功能的后续补丁文档和配置迁移

对普通用户来说，没有必要追完全部 PR。

这次真正值得优先关注的，是下面 5 项。它们会直接影响升级安全、会话可靠性、语音体验、Telegram 任务投递，以及 Hermes 最近正在推进的团队协作能力。

重点一：三个更新入口同时运行，曾把安装倒退 9160 次提交

v0.19.1 里最该先看的，可能不是 Buzz，也不是语音，而是更新器本身。

官方收到过一个很典型的 Windows 故障。

用户先在 Dashboard 点击更新，几秒后又在 Hermes Desktop 里点了一次更新。与此同时，后台还存在另一个更新流程。

35 秒内，三个更新器同时修改同一套安装目录。

结果出现了非常反常识的一幕：较旧的桌面安装器携带一个构建时保存的 Commit，重试安装时把当前代码直接切回了几个月前的版本。

最终倒退了：

9160 次提交

代码已经退回旧版，虚拟环境却处于更新到一半的状态。后面的依赖安装自然继续失败。

用户表面看到的可能只是：

Update didn't finishnpm error虚拟环境被占用桌面端无法重新启动反复更新仍然失败

真正的根因却是多个更新器互相踩了安装目录。

新逻辑主要修了三层问题。

第一，一次只允许一个更新器运行。

命令行的：

hermes update

Dashboard 的更新按钮，以及 Desktop 的安装器，现在会共用一把跨进程更新锁。

已经有更新流程在运行时，第二个更新器会拒绝继续修改同一目录，不再强行抢占。

第二，旧安装器不能再静默降级当前代码。

如果安装器携带的 Commit 已经是当前代码的祖先，说明它比当前安装更旧。新逻辑会跳过这个旧 Pin，不再自动执行回退。

确实需要主动回滚时，仍然保留显式的强制参数。

第三，崩溃留下的更新锁能够回收。

系统会检查锁文件里记录的进程是否还活着，以及锁是不是已经超过有效时间。更新器崩溃后，不会让一把失效的锁永久挡住所有后续升级。

这项修复给普通用户的提醒很明确：

一次只从一个入口更新更新过程中不要再点击其他更新按钮不要同时运行 Desktop、Dashboard 和独立安装器看到更新失败，先检查是否仍有更新进程

即使新版本已经增加锁，保持单入口更新仍然是最稳妥的习惯。

重点二：多个 Hermes 共用 state.db，短暂写锁不再轻易毁掉当前回合

第二项与长期运行关系更大。

Hermes 的会话、消息、部分任务状态和运行数据会进入：

~/.hermes/state.db

普通使用时，这只是一个 SQLite 数据库。

当一台机器同时运行下面这些组件时，情况就复杂了：

Hermes GatewayHermes Desktop多个 Worktree Agent后台委派任务多个 Profile会话恢复或数据库维护任务

多个进程都可能访问同一份 state.db。

官方调查的一个真实环境里，数据库已经达到 10.8GB，同时有 9 个 Hermes 进程工作。

旧逻辑面对 SQLite 写锁时，实际耐心很有限。短暂重试后仍然拿不到写入权，就可能中止当前回合，甚至让进程关闭后续会话持久化。

最麻烦的是，它可能把“另一个健康进程暂时正在写入”，表现成“数据库出问题了”。

用户看到的结果包括：

Agent 已经完成工作，消息却没有保存当前回合突然中止重启后刚才的对话消失Gateway 能运行，但新消息无法持久化系统提示数据库异常

v0.19.1 把写锁等待改成了按时间判断。

当前策略大致是：

普通数据库写入：最多等待约 20 秒会话和消息关键写入：最多等待约 60 秒

这不是把所有数据库问题都掩盖掉。

它解决的是短暂竞争。例如另一个进程正在做：

WAL Checkpoint数据库恢复会话压缩批量状态写入VACUUM旧进程退出前的收尾

只要对方很快释放写锁，当前任务就能继续，而不是 1 秒多以后直接判死刑。

错误信息也会更清楚：系统会告诉用户，当前写锁可能由另一个 Hermes 进程持有，而不是只让人去检查磁盘空间和文件权限。

升级后，长期多进程用户可以重点观察：

hermes gateway status

然后检查是否还有旧进程：

ps aux | grep -E '[h]ermes|[g]ateway'

Windows PowerShell 可以查看：

Get-Process | Where-Object {$_.ProcessName -match "hermes|python|node"}

等待时间增加不等于可以无限制地开进程。

如果十几个旧 Gateway、Worktree Agent 和桌面后端长期争抢同一个数据库，60 秒也只是让系统更有耐心，无法替代进程管理。

重点三：语音开始边生成边说，不用等完整回答

第三项是用户最容易直接感受到的变化。

以前 Hermes 开启文字转语音后，常见链路是：

模型生成完整回答整段文字交给 TTS语音服务合成开始播放

回答越长，开始说话前的等待越明显。

有时模型已经写了几百字，用户仍然听不到声音，只能面对一个正在处理的状态。

新的 Streaming TTS（流式语音合成）会按句子或分句处理模型输出。

链路变成：

模型持续生成文字缓存到一个完整分句第一段立即交给 TTS播放第一段后台继续生成和合成后文

它带来的改善主要有两个。

第一，首段语音出现得更早。

Hermes 不必等待整篇回答完成，只要积累到一段适合朗读的内容，就可以启动合成。

第二，模型和语音可以并行工作。

用户听前一段时，模型仍在生成后面的内容，TTS 也在准备下一段。整体体验更接近实时交谈。

当前文档中，流式语音还会做几项清理：

按完整句子切分过滤 Markdown 符号移除不应朗读的思考标签避免太短碎片频繁送入 TTS

OpenAI、ElevenLabs、Gemini、xAI 等提供商可以进入统一的流式语音路径；不能流式合成的服务会继续使用原来的整段回退方式。

这项更新没有让模型本身变快。

它减少的是“模型明明已经开始回答，用户却要等全文完成才能听见”的空白期。

使用语音模式的朋友升级后，可以测试一个长度稍长的任务：

请用语音给我解释量化交易的基本逻辑，分成背景、流程、风险和入门路径四部分。

重点观察：

第一句话多久开始播放句子之间是否出现长时间空白Markdown 标记会不会被读出来中途调用工具后语音能否继续

重点四：Telegram 长命令被拆成多条，不再反过来打断 Agent

Telegram 单条文本存在大约 4096 字符的限制。

用户粘贴一段很长的任务时，客户端可能自动拆成多个消息更新。

例如：

/queue 请检查整个项目……

后面跟着几千字需求、约束、目录和验收条件。

旧版 Hermes 收到第一块时，会把它当成完整的 /queue 命令立即开始执行。

几百毫秒后，第二块和第三块继续到达，却已经没有开头的斜杠命令。Hermes 会把它们当成新的普通消息。

结果可能变成：

第一块启动任务Agent 开始工作第二块被识别成新消息正在运行的任务被打断或改向完整需求从未作为一个整体进入 Agent

用户明明只发送了一次粘贴，Hermes 却像收到多次互相冲突的指令。

v0.19.1 中的处理方式，是给接近 Telegram 长度上限的文本增加一个很短的聚合窗口。

系统发现第一块很可能属于被客户端拆分的长消息时，会先暂存，等待后续块到达，再合并成一条完整消息交给 Agent。

大致过程是：

收到接近 4096 字符的第一块短暂等待同一用户、同一会话继续发来后续块拼接完整只触发一次任务

/stop、/approve 等短命令仍然会立即执行，不会因为聚合机制变迟钝。

这项修复很适合下面几类场景：

通过 Telegram 粘贴长任务发送长日志让 Hermes 排查使用 /queue 排多个步骤把完整需求说明交给远程 Gateway

升级后可以自己做一个低风险测试：准备一段超过 4096 字符的文本，通过 Telegram 发送给测试会话，然后观察 Hermes 是否只启动一次任务。

不要拿生产目录或危险命令做第一次验证。

重点五：Buzz、Nostr 与更多平台能力，开始被装进正式标签

第五项才轮到最近讨论很多的 Buzz。

Buzz 是 Block 开源的人机协作工作区。人类与 Agent 可以出现在同一套频道、私聊、线程和身份系统里。

Hermes 的原生 Buzz Gateway 插件支持：

频道私聊@提及线程表情反应图片Cron 定时投递Hermes 会话和记忆权限与身份控制

这一能力在 v0.19.0 发布后进入主分支，现在被纳入 v0.19.1 的发布窗口。

这意味着 Buzz 不再只停留在“主分支已经有代码、稳定版用户未必拿到”的状态，正式标签终于覆盖到了这批平台工作。

与此同时，官方在 v0.19.1 的发布说明中还点到了：

Buzz / Nostr 频道能力FLUX3 视频生成与投递Telegram 媒体可靠性语音模式回归修复Gateway、Desktop 和安装器稳定性

不过，v0.19.1 没有给出完整的功能分类清单。官方已经说明，完整整理要等 v0.20.0。

所以当前更合理的判断是：

v0.19.1 把过去 10 天的大量平台能力和修复封进了正式标签，v0.20.0 再负责把这批变化讲明白。

准备尝试 Buzz 的朋友，可以先升级，再检查 Gateway 平台列表：

hermes gateway setup

如果列表中出现 Buzz，再继续配置身份、Relay 和频道。

不要只看到发布说明写了 Buzz，就直接假定所有 Buzz 功能已经自动配置完成。它仍然涉及：

buzz CLIRelay 地址独立 Nostr 身份频道权限Gateway 配置消息触发规则

0.19.1 值得马上升，但升级方式要看清

我的判断是：值得升级。

理由主要来自稳定性，而不是功能数量。

这次修复涉及：

多个更新器同时修改安装目录旧安装器把代码降回旧 Commit多个 Hermes 进程争抢 state.db语音回答开始时间过晚Telegram 长任务被拆开后误触发Gateway 和平台适配器的大量回归

不过，1000+ PR 和 2789 次提交也意味着回归面很大。

升级前先停掉正在运行的组件：

hermes gateway stop

再检查版本和状态：

hermes --versionhermes gateway status

Linux、macOS 或 WSL 用户准备完整备份时，可以在确认所有 Hermes 进程退出后执行：

cp -a ~/.hermes \~/.hermes.backup-$(date +%Y%m%d-%H%M%S)

Windows PowerShell 可以使用：

Copy-Item "$HOME\.hermes" `"$HOME\.hermes.backup-$(Get-Date -Format yyyyMMdd-HHmmss)" `-Recurse

数据目录很大时，至少保留：

config.yaml.envstate.dbprofiles/skills/Cron 配置认证与平台配对数据

然后只从一个入口更新：

hermes update

这里还有一个容易忽略的细节。

Hermes 官方更新文档显示，hermes update 会拉取当前 main，并不只停在最近一个正式标签。v0.19.1 发布之后如果主分支又有新提交，正常更新可能把这些更靠后的改动一起拉下来。

希望严格固定正式标签的用户，不要随便手动修改 Git 状态，先等安装渠道或团队部署方案完成固定版本验证。

更新完成后执行：

hermes --versionhermes config checkhermes gateway status

再完成下面 5 项验证：

Gateway 能停止、启动和重启Cron 能按预定时间触发飞书、微信、Telegram 等渠道能收发消息MCP 能重新连接并执行一个低风险工具旧会话能读取，新消息能保存，重启后仍然存在

语音用户再补一项：

长回答能否提前开始播放

Windows 用户还可以留意：

更新后是否残留旧 Hermes 进程Desktop 是否能正常重新启动安装器是否仍提示另一个更新正在运行

版本号很小，升级动作不能小看

Hermes v0.19.1 的名字容易让人放松警惕。

“补丁版”三个字通常让人想到几十个错误修复，下载以后直接覆盖就行。

这一次的实际规模是：

10 天1000+ PR2789 次提交4748 个文件超过 83 万行增删

它更像把一段高速主分支集中封装成正式发布。

这批变化中，新平台和新能力负责吸引注意力；更新器、数据库锁、Gateway 和消息可靠性，才决定用户升级后能不能安心继续跑。

我的建议很明确：

值得升级先停止旧进程先备份只用一个更新入口升级后逐项验证发现问题及时回滚

v0.19.1 真正的价值，不在版本号从最后一位加了 1。

它把 Hermes 最近 10 天快速扩张产生的大量功能、修复和工程调整，第一次交给了稳定标签用户。

功能越多，升级后的验证越不能省。