90%用户都没注意！Hermes v0.21.7 后更新机制彻底变了，附命令解析

你看到 Hermes 仓库又合并了一大批代码，兴冲冲地打开终端，准备把新功能装上。

你熟练地输入更新命令，结果程序告诉你：没有更新的正式版本。

你可能会纳闷：网上明明都在讲新功能，怎么轮到自己的电脑，Hermes 就突然“不认账”了？

先别急着重装。

问题可能不在网络，也不在你的操作，而在于 Hermes 改变了“更新”这两个字的默认含义。

随着 v0.21.7 发布，官方源码安装的更新目标，不再默认追逐 main 主分支的每次提交，而是跟踪正式发布的版本。

换句话说，以前你按下更新，拿到的通常是开发仓库里最新的代码。

现在，你按下更新，默认拿到的是正式发布的版本。

命令看起来没变，背后的路线却变了。

这就像你以前订阅的是作者每天修改的草稿，现在改成了等出版社正式出书。作者今天又写了十页，不代表你的书架马上就会多一本新书。

这次变化还不只是增加一个开关。桌面端怎么选择通道、为什么有时更新反而会退回旧代码，以及程序更新后后台服务是否真正跟上，都值得一次讲清楚。

一、Stable和Main：一个追正式版，一个追最新提交

先把最关键的两个名字弄明白。

Stable（稳定通道），跟踪官方正式发布的 vX.Y.Z 版本。

Main（主分支通道），跟踪开发主分支的最新提交。

对官方仓库的源码安装来说，Stable 现在是默认选择。正式版本之外的草稿发布、预发布标签，不会因为名字里带着新版本号，就被当成稳定版安装。

例如，你正在使用一个正式版本。

开发者随后又合并了几十个 PR，里面有新工具、界面调整，也有修复代码。

选择 Stable 的用户，会等到下一个正式发布节点再更新。

选择 Main 的用户，则可以在下一次执行更新时获取这些新提交。

这里有个容易产生误解的地方。

“跟踪每次提交”并不是说 Hermes 会在后台看到一条提交，就自动替你安装一次。它决定的是你执行更新时，应该把哪一份代码作为目标。

两种方式可以这样选：

使用习惯

更适合的选择

每天处理资料、写文章、运行定时任务，希望少折腾

Stable

经常研究新功能，愿意排查问题，有测试环境

Main

我的建议是，不要把“更新得最勤”直接等同于“用得最好”。

如果 Hermes 已经承担了实际工作，你更需要的是可预期的运行环境，而不是每天都重新熟悉一次刚变化的代码。

二、命令解析：保存通道、检查更新和执行更新，是三件事

这次最值得记住的，不是某一条神奇命令，而是几个参数之间的区别。

先看当前版本和更新目标：

hermes --versionhermes update --check

第一条查看当前安装的版本。

第二条按当前选择的通道检查更新，不应用新代码、不安装依赖，也不重启网关。它可能获取用于比较版本的 Git 元数据，因此更准确地说，它是“不执行升级”，而不是完全不接触磁盘。

想长期跟踪稳定版，可以执行：

hermes update --set-channel stable

想长期跟踪主分支，则使用：

hermes update --set-channel main

这两条最容易被误解。

--set-channel 的意思是保存更新通道，不是立即更新程序。

你可以把它理解成在导航软件里选择路线。路线选好了，车还没有出发。

真正执行更新的是：

hermes update

它会按照已经保存的通道处理。通道选择按安装记录保存，不是你在聊天里换个模型，更新路线就跟着改变。

还有一种情况很常见。

你平时使用稳定通道，但今天想看看主分支是不是有值得尝试的新东西。

可以临时检查：

hermes update --channel main --check

这条命令只针对本次检查使用 Main，不修改长期保存的选择。

如果确认要临时更新到主分支，才执行：

hermes update --channel main

注意，少了 --check，这条就会实际更新。

而且，“临时”指本次使用的通道设置，不是代码只保留几分钟。更新后，电脑上的代码已经改变，不会因为命令结束就自动恢复原来的版本。

记住这三个区别就够了：

--set-channel 负责长期选择。

--channel 负责本次选择。

--check 负责只检查、不升级。

三、桌面用户怎么选？先分清源码构建和独立安装包

不喜欢命令行的朋友，也有图形化入口。

在源码构建的 Hermes Desktop 中，可以进入：

设置 → 关于 → 更新

找到 Update channel（更新通道），选择 Stable releases 或 Every commit。

从 Main 切回 Stable 时，界面会先要求确认，因为之后的实际更新可能把代码切回较旧的正式版本。

但如果你的设置页面里没有这个开关，先别怀疑自己找错地方。

Hermes 的不同安装方式，本来就由不同的更新程序管理：

安装方式

应该从哪里更新

官方源码安装

hermes update

源码构建的 Desktop

应用内更新，交给源码更新流程处理

Microsoft Store 安装

微软商店

Windows 侧载 MSIX

应用内更新入口及 Windows App Installer

macOS 独立打包应用

应用内更新程序

Docker 部署

拉取目标镜像，保留数据挂载并重新创建容器

所以，hermes update 不是一把能修改所有安装包的万能钥匙。包管理渠道拥有的应用文件，应由对应渠道更新。

另外，独立桌面包还有 Stable 和 Canary（预览构建）之分。

官方把它们设计成可以并存的不同应用，各自在打包时确定的通道内更新。切换这类发行渠道，需要安装对应应用，而不是套用源码版的通道开关。

不过，两款应用并存，不代表数据天然隔离。使用同一个 Hermes 数据目录时，配置、Profile（配置档案）和会话仍可能共用。准备试预览构建时，最好另外安排测试数据环境。

一句话总结：

源码版是在选择“这套代码以后跟谁走”。

独立安装包是在选择“安装哪个发行渠道的软件”。

四、为什么切回稳定版，反而可能变成一次回退？

这一点最值得老用户认真看看。

假设你一直跟踪 Main，已经安装了正式版本之后的新提交。

这时，你的代码可能比最新正式版更新。

Hermes 对两种情况作了区分。

如果你从未主动选择通道，只是遇到了新的 Stable 默认规则，系统不会因此强行把较新的代码退回去，而是保留当前位置，等待后续正式发布。

但如果你明确保存了 Stable 选择，就表示你希望之后的更新落到正式发布的确切代码上，即使那份代码比当前的旧。保存选择和实际回退，仍然是两个步骤。

这不是文字游戏，而是已经发生过真实问题。

10 月 13 日的修复记录中，有用户原本选择了稳定版，重新运行 Hermes-Setup 安装器后，却被安装器内部指定的 main 参数带到了开发提交。

更绕的是，桌面端随后又发现当前代码与稳定版本不同，提示“有新更新”。

用户以为自己要升级，实际上却是准备回到较旧的正式版。

这就像你刚被导航带上另一条路，它又告诉你：“前面有捷径。”

结果所谓捷径，是掉头回到刚才的路口。

PR #137780 针对这个问题完善了两个环节。

安装器再次运行时，尊重已保存的更新通道，不再随意覆盖选择。

更新检查识别到目标是较旧的正式代码时，明确显示 Rollback（回退），而不是继续把它包装成普通升级。

因此，以后看到“回到稳定版本”的提示，不必紧张，但要看清楚：这是你主动选择的路线，还是安装器出了问题。

“正式版”代表发布渠道，不一定代表比你当前的开发代码更新。

五、一次更新不只是拉代码：备份、检查、重建和重启都在里面

很多人对更新的理解，仍然停留在下载几个文件。

但 Hermes 已经不是一个只负责聊天的简单程序。

它可能保存着长期记忆、技能、账号授权，还运行着 Gateway（网关）和定时任务。更新时，旧代码、新依赖和后台进程必须衔接好。

当前源码更新流程中，有几项值得了解的保护措施。

首先是更新前快照。

默认的 Quick（快速快照）模式，会保存选定的重要状态文件。需要更完整的更新前备份时，可以使用：

hermes update --backup

这条会实际执行更新，并请求额外的完整数据归档；它不是“只做备份”。大数据目录可能花费更多时间，备份中的授权信息也要妥善保管。

还要留意执行结果：快照失败时，更新流程可能警告后继续，所以看到“备份失败”不能当作已经留好了退路。

其次是关键代码检查。

更新后的流程会检查九个启动关键文件是否存在语法问题。如果出现无法解析的代码，可以退回更新前的提交，避免连基本启动入口都打不开。

这里保护的是这类明确的启动故障，不是所有使用问题都能自动回滚。

桌面程序的构建，也采用先准备、后替换的方式。

新程序先在临时位置构建和验证，通过以后再替换旧构建。某些构建失败会保留旧的桌面程序，同时记录还需要完成的后续步骤。

网关方面，Linux 和 macOS 上的更新器会在修改源码前，尝试暂停属于当前安装的网关，准备好代码与依赖后再恢复，减少运行中的进程混用新旧文件。

如果更新时长时间显示等待，也不一定是程序卡死。

网关重启会先尝试让正在进行的工作收尾，默认等待上限为 30 分钟，并显示正在等待的任务。达到上限或任务被判定为异常时，处理方式会变化，所以不能把它理解成任何任务都能无限等待。

对普通用户来说，最实用的习惯是：更新前先看看正在运行什么，而不是遇到等待就连续按中断。

六、更新完成后，用这几条命令确认“真的更新好了”

我建议把日常更新分成三步：先看计划，再执行，最后验证。

更新前，尤其是同时运行多个 Profile 的用户，可以先执行：

hermes update --plan

它会列出安装类型、正在运行的 Hermes 服务、服务使用的代码版本，以及计划如何重启。这个计划检查本身不执行升级。

确认目标和运行任务以后，再按需要选择普通更新，或者前面介绍的带备份更新。

完成后，先检查：

hermes --versionhermes doctor

如果使用了网关，再检查：

hermes gateway status

这些检查分别帮助你确认版本、配置与依赖健康，以及网关运行状态。

为什么不能只看终端最后有没有“成功”？

因为新代码已经安装，与所有后台服务已经切换到新代码，并不是同一件事。

Hermes 会在更新后核对网关版本。某个网关仍使用旧代码时，它会提示对应的重启操作，并把未完成事项写入更新记录；代码更新本身仍可能以成功退出。

遇到问题，可以查看更新日志。

在 macOS 或 Linux 的常见默认数据路径下：

tail -f ~/.hermes/logs/update.log

更新过程的结构化记录，则位于：

~/.hermes/logs/update_receipts/

这些记录能帮助你分清楚：到底是代码没有更新，依赖没有准备好，桌面构建没有完成，还是某个网关没有重启。自定义数据目录的安装，应在自己的 Hermes 数据目录里查找。

还有一个容易混淆的命令：

hermes pm update 不是 Hermes 应用更新的替代方案。PM 负责依赖和工具准备，不能因为看到同样的 update，就把它当成普通升级入口。

七、干货提炼：先选路线，再按更新

把这轮变化放在一起看，Hermes 正在把以前比较粗放的更新习惯，拆成几个更清楚的问题。

你要跟踪正式版本，还是最新开发提交？

你使用的是源码安装，还是由商店和安装包管理的应用？

本次操作只是检查，还是会真正修改程序？

代码更新之后，后台服务有没有一起完成切换？

真正值得记住的命令，可以浓缩成这张表：

你准备做什么

对应命令

查看当前版本

hermes --version

按当前通道检查更新

hermes update --check

查看更新与服务重启计划

hermes update --plan

长期选择稳定通道

hermes update --set-channel stable

长期选择主分支

hermes update --set-channel main

临时检查主分支，不改变长期选择

hermes update --channel main --check

按当前通道更新，并请求完整备份

hermes update --backup

这些参数的分工已经写进官方命令文档：选择通道、检查目标和执行升级，要分开理解。

对于日常工作，我更建议保持稳定通道，把时间花在真正要完成的任务上。

对于新功能研究，则可以准备独立测试环境，主动跟踪 Main，而不是让工作环境承担每一次尝鲜的代价。

回到文章开头的问题。

Hermes 仓库明明有新提交，电脑却提示没有新的正式版本，两句话可以同时成立。

仓库回答的是：“开发又往前走了多少？”

稳定通道回答的是：“有没有下一份正式发布的代码？”

弄清楚这层区别，就不必一看到新功能消息，立刻怀疑自己的更新坏了。

短结论：v0.21.7 这一轮最重要的变化，是让用户真正拥有更新路线的选择权。Stable 管正式发布，Main 管开发进度；--set-channel 只保存选择，--check 只检查，实际更新还要另行执行。

以后使用 Hermes，不妨先问一句：我这次想更新到哪里？

知道自己要到哪一站，比反复点击“更新”更重要。

#探寻人工智能，从技术到真实世界#