Hermes 又暴露一个最后一公里边界问题：system notices 与后台记忆都需要 tenant-aware gates
Hermes PR #24365 指出，WhatsApp 和 Discord gateway 并没有完整执行 suppress_system_messages，所以面向客户的部署仍可能发出操作者本来想隐藏的内部平台提示，例如 “No home channel is set”、 “Session reset”、dangerous-command approval prompts，以及 assistant narration。PR #24392 则修另一个 profile-home isolation 问题：WebUI 在非默认 profile 下完成一轮对话后，后台 memory / skill review 线程可能等到进程级 HERMES_HOME 被恢复后才初始化，于是加载 default profile 的 config，甚至把 memory 写到 default profile，而不是 parent run profile。PR #24376 较小但同属运维边界：CLI 遇到危险命令 approval prompt 时，可以复用已有 bell / dock-bounce 提醒，让人真的注意到高风险动作正在等待审批。
共同主题是 visible answer 结束之后的边界纪律。Messaging gateways 要清楚哪些 notices 可以给客户看，后台 reviewers 也必须继承用户可见运行的同一 profile scope。否则，本来“有帮助”的平台提示或 memory maintenance，可能泄露实现细节、误导客户，或者把私人上下文写进错误 home。对把一个 Agent 栈部署到多个频道 / profiles 的团队和服务商来说，这是实打实的生产风险。
- PR #24365 列出具体泄漏到 WhatsApp / Discord 的消息：no-home-channel notices、session resets、dangerous-command approval prompts 和 assistant narration
- 该 PR 在此前需要手工 patch 的 gateway delivery paths 中实现 suppress_system_messages checks
- PR #24392 说明 WebUI race：process-level HERMES_HOME 在 background review thread 构造 AIAgent 前已恢复
- PR #24392 增加 thread-local Hermes home override，让 post-turn background review 仍绑定 parent run profile
- PR #24376 复用 display.bell_on_complete，在危险命令等待 approval 时提醒 CLI 用户
- 这些仍是 open PR，不是 tagged Hermes release
- suppress_system_messages 需要按平台实测，因为每个 gateway path 可能有自己的 delivery helper
- profile-home isolation 只降低一种 race；shared installations 仍需要明确 tenant separation、backup review 与 audit trails