你在一台机器上跑了三个 profile 的机器人：一个盯着客服群，一个每天定时发日报，还有一个在后台默默巡检。周一你想再加一个新的，结果它死活不出现在桌面的 Bots 名单里，旁边的网关状态还写着已停止——你只好把整个网关重启一次，另外两个正在干活的实例也一起被打断。比这更让人心里没底的是另一个问题：这些跑在同一台机器上的 profile，会不会互相看到对方的凭据、记忆和会话记录？

v0.21.2 对这两件事都给了回答。这一版没有大张旗鼓的新功能，主角是两个很朴素的目标：让一台机器上的每个 profile 都守好自己的东西，以及让桌面别再为每个 profile 各开一个后端。

一个后端进程，三套机器人

先说清楚多 profile 是什么。一个 profile 基本就是一份独立的 Hermes 安装：自己的配置、自己的凭据、自己的记忆和会话记录。为了让一台机器上的多个 profile 不必各自起一个网关，Hermes 提供了多路复用（multiplexer）——一个网关进程同时托管多个 profile 的机器人。共享同一个进程是它的价值所在，也正是它的风险所在：进程里任何“按全局解析”的东西，都可能从一个 profile 漏到另一个 profile。

这类安装的日常形态，就是一台机器上同时有主 profile 和若干个次级 profile，它们共用一套进程和一部分运行时状态。想知道怎么把自己的机器组织成这样，可以先看多实例 profile 指南：什么该共享、什么必须分开，里面讲得很具体。

v0.21.2（tag v2026.9.11，2026 年 9 月 11 日发布，官方昵称 “The state.db Patch Release”）是紧接 v0.21.1 的补丁发版，规模并不小：自 v0.21.1 以来有 947 个非合并提交、1,869 个改动文件（+182,504 / -15,564）、312 个已合并 PR，来自 140 位贡献者。完整的按块清单在 v0.21.2 发版页面上；下面挑出跟 state.db 无关、但会影响你日常使用的几块。

七个泄漏口，一次堵上

多 profile 安装最怕的不是崩溃，而是“安静地串味”——某个 profile 的权限、密钥或文件被另一个 profile 用上了，界面上一切正常，你根本不会发现。这一批发版里有 7 个 PR 专门堵这类口子：

PR	泄漏了什么	现在的行为
#107616	次级 profile 的机器人继承了默认 profile 的 allow-list，权限白名单被跨 profile 继承	每个 profile 各自解析自己的白名单
#107617	适配器可能把凭据发往默认 profile 的主机	凭据只随它所属的 profile 走
#107630	stdio MCP 服务器收到了默认 profile 的 vault 密钥	stdio MCP 服务器只拿到当前 profile 的密钥
#107609	MEDIA: 投递可能带上另一个 profile 的 .env、auth.json 或 state.db	投递被限制在发起它的 profile 内
#107620 / #107626	飞书 drive 回调、以及 profile 专属路径下的 webhook 回复可能落到别的 profile	回调与回复留在被路由的那个 profile
#107611	次级 profile 可能从进程内记忆里拿到兄弟 profile 的 Nous bearer token	token 不再跨 profile 复用

其中 #107616 最值得单独说一句。allow-list 决定了一个机器人的权限边界，而它此前是按“默认 profile”解析的：你在主 profile 上放开了什么，次级 profile 就跟着放开什么。对不上一块干活的两个机器人来说，这等于把主 profile 的权限顺手送给了它。这一条的历史背景可以看多 profile 白名单那篇。

把这张表连起来看，能得到一个有用的判断方法：凡是“进程级共享”的东西——进程内记忆、vault、适配器主机、投递通道——都曾经是多 profile 的薄弱面。这次不是一个个打补丁，而是把这些解析点统一钉回 profile 边界。

桌面不再为每个 profile 开一个后端

第二块是桌面端 Bot Mode 的启动行为，症状非常直观。此前，桌面在启动时、以及每一轮 roster tick 都会为每个 profile 生成或拨号一个后端；把鼠标悬停在 Bots 名单上，会为每一行生成一个后端；切换 profile 时还可能生成重复的 primary 后端。你机器上有几个 profile，就乘以几倍的后端进程，多出来的那些还会互相抢同一个网关。

这一批修复覆盖了启动路径和名单渲染路径：#108069、#108107、#108118、#108134、#107969、#108112。效果就是前面那个场景里的事不会再发生——新增一个 profile 不再需要你半夜重启网关，Bots 名单里也不会再冒出状态可疑的“幽灵”实例。

顺手修掉的那些“说不通”的行为

除了上面两块，这一版还清理了一批长期让人觉得别扭的小行为。它们单独看都不算大事，但凑在一起就是每天都要撞一次的墙。

定时任务（cron）。 非整点的“立即运行”不再取消下一次计划运行（#106306）；被手动杀掉的一次运行不再阻塞接下来的 5 分钟窗口（#106733）；由一次性改成周期性的任务会继续触发（#106532）；没有固定模型的任务按创建时快照的模型运行（#106499）；hermes profile create --clone-all 不再把 cron 任务一起复制过去（#106478）。最后一条对多 profile 用户尤其重要，因为“克隆一个 profile”的意图通常是复用配置，而不是把同样的定时任务在第二个 profile 上再跑一遍——那等于每个周期多跑一次。

看板（Kanban）。 kanban promote 现在会拒绝未完成的父任务（#106550），kanban_request_review 会拒绝未知的 reviewer profile（#106547）。两条都是把“静默接受一个坏输入”改成“明确拒绝”。

工具与记忆。 stdio MCP 服务器在调用中途死亡时，工具调用不再被重放（#106546）——重放意味着一个可能已经执行过的写操作再来一次，这条修得挺关键。只含技能的背景评审不再能删除记忆条目（#106310）；mem0 记忆不再丢长轮次（#106542）；tool_search 宁可返回空，也不返回五个只共享一个词的无关工具（#106676）；远端 NOPASSWD sudo 不再弹审批（#107939）；RSS 与 Reddit 读取不再默认启用（#105873）。

更新与额度。 更新检查改为每天轮询一次 GitHub API，不再每 30 分钟做一次 git fetch（#107648）；hermes update 会说出真实的失败原因，也不会卡在一次 stalled fetch 上（#108053）。

Provider 与路由。 /model 与 auxiliary 的自动路由不会账单到你没选的 provider（#107366）；绝不自动切换到你没有凭据的 provider（#107281）；Bedrock Guardrails 生效（#107815）。

缓存。 Desktop 与 TUI 之间来回切换不再重建 system prompt，因此不再打破 prompt cache（#105844）——对天天在两个界面之间跳的人，这是实打实的省钱。

你要做什么

升级就一条命令：

hermes update

升完之后，有几件事值得顺手确认：

• 如果你在多 profile 机器上配过权限白名单，现在每个 profile 各自解析它（#107616），值得看一眼次级 profile 的白名单是不是你真正想要的。
• 如果你以前依赖 hermes profile create --clone-all 把 cron 任务一并带过去，升级后需要手动重建（#106478）。
• 如果你想继续用 RSS 或 Reddit 取内容，得显式打开，默认已经关闭（#105873）。
• 如果你的定时任务没固定模型，它现在跑的是创建时快照的那个模型（#106499）。
• 更新检查变成每天一次（#107648），别再以为它变慢了——它只是不再每半小时去 fetch 一次。

另外，state.db 那条线不是这一篇的重点，但需要一句话交底：v0.21.0 重写了会话存储的连接处理，之后部分安装的 state.db 变得脆弱，v0.21.2 关闭了那一类问题。这条线我们单独写过，细节见 state.db 锁与写入冲突。

小结

v0.21.2 是一个很典型的“加固型”补丁发版：没有新功能可以炫耀，947 个非合并提交、312 个已合并 PR 大多花在把边界收回来。对只跑一个 profile 的人来说，最明显的变化大概是桌面不再卡着一堆幽灵后端；对在一台机器上跑多个 profile 的人来说，这一版的意义要大得多——从权限白名单、vault 密钥、凭据主机到进程内 token，跨 profile 的七个泄漏口一起关上了。

换句话说，多 profile 从此不再是一个“能跑但心里没底”的用法：每个 profile 守自己的东西，桌面只开它需要的后端。这就是这次发版真正在修的东西。