你以为 YOLO 还开着，其实重启那一刻就关了

你在 Telegram 里给 Hermes 敲了一句 /yolo，它回你“YOLO 模式已开启，所有命令自动批准”。之后你让它跑一串自动化步骤，心里默认“它会自己动手，不会来问我”。半夜你升级了一次 Hermes，网关重启，第二天你接着发指令——它开始一条一条地问你“是否允许执行”。你翻了半天配置：YOLO 不是开着吗？答案有点扎人：它在你没注意的时候被关掉了，而且关得悄无声息。反过来说，这个修复也会带来另一个方向的风险，两个方向都得说清楚。

之前的问题：开关只存在于内存里

/yolo 在消息平台上的实现，原来只是翻转 tools.approval 里的一个内存集合。这意味着：

  • 重启网关（hermes update、崩溃重启、systemd 拉起、桌面端重开）→ 内存清零 → 这个聊天静默回到手动审批；
  • 而用户界面里没有任何提示说“你的 YOLO 已经没了”，所以你仍然以为它在放行。

结果就是两件事同时发生：你以为它在自动执行，它却在等你逐条批准；如果你的自动化依赖“不用人工确认”，它就会卡在那里直到超时。官方把这类报告写成一句话：用户仍然相信 YOLO 是开着的。

现在：跟着会话存下来，但只跟着会话

新的实现把标记放到了这个聊天自己的路由条目上（SessionEntry.yolo，和 /model 覆盖一起持久化在 gateway_routing 里）。具体规则值得逐条看，因为它决定你在哪种情况下会被“惊到”：

  • /yolo 会先写持久化副本，再翻转实时标记；第一次发消息就切换时，会顺手把这个条目创建出来。
  • 每一轮都会从已解析的条目重新装配实时标记——所以重启之后第一轮就把状态恢复回来了，而不是等你再敲一次 /yolo。
  • 跨压缩、跨会话绑定的重指（switch_session）时，标记会一起带过去。
  • 会话边界的“安全漏斗”会同时清掉持久化副本和内存副本：/new、/resume、/branch、自动重置。这样设计的目的很明确——重启绝不可能让一个你已经放弃的旁路“复活”。

官方文档现在把范围写得很直白：/yolo 只作用于它被输入的那个会话；它跟着会话保存，所以能跨重启存活——消息平台的聊天跨网关重启保留，TUI 和桌面端在你重新打开或恢复这个会话时保留；而在消息平台上，/new 和 /resume 会让下一段对话回到“审批开启”。

看一眼会话状态就很直观：

# 查当前会话的 YOLO 状态（以及它是不是被持久化了）
hermes status

# 关闭并同时清掉持久化副本：开一段新对话
/new

顺手纠正一个流传很广的说法：文档以前写着“/yolo 会设置 HERMES_YOLO_MODE 环境变量“。它从来没有这么做过——两者是互相独立的三种开启方式：命令行启动参数 hermes --yolo（或 hermes chat --yolo）、会话里的 /yolo 开关、以及环境变量 HERMES_YOLO_MODE=1。前两个是会话级的，第三个是进程级的，别混着推理。

两个方向都会坑人

方向一：你以为它开着，其实关了。 就是开头那个场景。现在不会了。

方向二：你以为它关了，其实还开着。 这才是修复带来的新增风险——毕竟旁路现在能扛过重启了。为此有两条现成的防线，请务必利用起来：

  • 视觉提醒不会消失。 YOLO 激活时，Hermes 会持续显示两处提示：会话开始时的一行红色横幅 ⚠ YOLO mode — all approval prompts bypassed（关闭时不显示，免得默认横幅变吵），以及状态栏里一个 ⚠ YOLO 片段——它覆盖所有宽度档位，会在你开关的那一刻实时变化。
  • 两个边界动作一定会清掉它：/new（以及别名 /reset）和 /resume。前者是你“我不再需要它”时的正解，后者是你想回到一段干净会话时的正解。

还有一点必须说清楚，免得你把 YOLO 当万能钥匙：YOLO 绕过的只是“危险命令审批”这一段。它不能绕过硬性黑名单（hardline blocklist），也不能绕过“受监督网关生命周期”那道守卫——从网关自己的进程里重启或杀掉网关，仍然是拒绝的，用户审批、YOLO 和 force=True 都不例外。原因也很实在：那样做会把执行这条命令的工具自己干掉，然后触发监管进程的重启/自动恢复循环。

什么时候该用，什么时候该关

  • 适合：一次性的、容器里的、脚本化的自动化；你确实要它不问就动手，并且已经确认过它会生成什么。
  • 不适合：交互式探索、不确定的破坏性命令、以及任何“多个人共用同一个聊天”的场景。
  • 通用建议：用完就 /new。既然重启不再会替你关掉它，那“自己关”就成了唯一的兜底；而 /new 是那条最顺手、也最不容易忘的路。

小结

  • 之前 /yolo 只改内存集合，网关一重启就静默失效，用户却以为它还开着。
  • 现在它存在会话的路由条目里（SessionEntry.yolo），能跨重启、跨压缩存活，TUI / 桌面端恢复会话时也保留。
  • /new、/resume、/branch、自动重置会同时清掉持久化和内存副本——重启不会复活你已经放弃的旁路。
  • YOLO 只免除审批提示，硬性黑名单和受监督网关的生命周期守卫不受影响。
  • 文档里“/yolo 会设置 HERMES_YOLO_MODE“的说法是错的，那是另一种独立开启方式。

审批这件事我们写过好几篇，可以接着读：YOLO 的七种模式到底差在哪、无人值守场景下的审批配置，以及审批规则的 dry-run 自测——最后一篇尤其适合“我改了审批规则但不确定会不会误拦”的时候。