把 Hermes 升级到 v0.21：一串假报错、一个真问题、一处上游缺口

先把结论放前面：升级成功了。日志里那堆"报错"，查下来大半是虚惊；真问题只有一个；另外顺手逮到一处上游的识别缺口，已经给官方提了 issue 和 PR。

背景一句：Hermes 是我平时在用的开源 AI agent 系统（Nous Research 出的），挂在几个聊天平台上帮我干活。这次把它从 v0.19 升到了 v0.21.5+2630 这个 canary 版。

升级完，报错刷了一屏

跑完升级看日志，差点心跳漏拍：

• 更新收据显示 exit 120、outcome: failed —— 其实更新是成功的，这只是新旧升级器交接时透传的退出码
• "Another Hermes update is already running" —— 防并发锁的提示，不是错误
• 重启后一串启动噪音：微信 session not ready、飞书 disconnect、MCP parked…… —— 部署顺序问题，半分钟后自己就没了
• state.db 的 FTS5 索引损坏警告 —— 旧账，重建索引就行
• 还有一条 pydantic 报错 —— 重启一次就恢复了

单看每条都吓人，合起来看：真故障是零。

真问题：新版强制"单 host 网关"

这个版本把网关改成了"一个 host 管全部平台"。旧的按 profile 拆的单元不符合新规矩，直接被拒，一轮轮崩溃重启（exit 78）。

官方迁移命令跑一下：

hermes gateway migrate --multiplex

迁完 QQ、微信、飞书三个平台全部恢复。

顺手逮到的上游缺口

迁移工具一直提示"未确认网关在服务中"，但网关明明活着、所有平台都在线。查下来发现：新版自生成的启动器（长这样：python3 -I -c "<bootstrap>" gateway run），它的命令行不被自己的身份探针认——自己认不出自己😅，pid 记录还被当陈旧条目清掉了。

给上游提了 issue #124120，附上函数级实测：

_record_matches_live_gateway_pid(...)          # False
looks_like_gateway_runtime_command_line(...)   # False
_gateway_command_subcommand(...)               # None

pid 记录和 runtime lock 都能验过，卡点就在命令行识别这一环。

后来发现有修复 PR #124297，把 diff 打在本地 checkout 上测了下：同一条命令行现在正确识别成 run，配套测试 78/78 通过。实测结果补在 PR 底下了。

两个链接：

• issue: https://github.com/NousResearch/hermes-agent/issues/124120
• PR: https://github.com/NousResearch/hermes-agent/pull/124297

收个尾

1. 看"失败"先懂语义：升级收据的退出码不是成败，交接有交接的码
2. 大版本先看破坏性变更：这次的单网关改造，不迁移就是崩溃循环
3. 报错分层看：噪音 / 旧账 / 真问题，别一锅炖

继续折腾别的去了。