你开着一台跑了好几个 Hermes 并行工作流的机器，某天想清理一下：ls .worktrees/ 一数，二十几个树躺在那里，分支列表滚三屏都见不到底——可你不敢删，因为说不清哪个里面还有没推送的活。另一边，你给 Bot Mode 拉了个群，让三个 bot 分工盯一个项目，结果想让它们看一份 PDF 设计稿，发现群里根本传不了文件。这些“没人点名要求、但每个人都撞到过”的琐事，就是 v0.20.5（tag v2026.8.19，发布于 2026 年 8 月 19 日）这个窗口处理的事。

这个版本自 v0.20.4 以来合并了约 323 个 PR、约 746 个提交，改动约 1,250 个文件。没有单一大 feature，头条是 Bot Mode 群聊终于能收文件、worktree 终于有安全的大扫除命令、更新过程第一次有回执可查、cron 任务有记忆了。逐条来看。

群聊能收文件了，旧消息自动折叠

Bot Mode 群聊过去是纯文字的：想让群里的 bot 看一份 PDF，你得先把文件放进某个路径，再在 prompt 里写路径。现在文件是一等公民——群聊接受 PDF、任意文件和拖拽上传，每个参与这一轮响应的 bot 都能看到附件（PR #97b41f8cf、#b359db72e）。多 bot 盯项目的场景终于不用绕路。

长群聊也有了出路：旧对话自动折叠成一行摘要（“▸ API design … 14 replies · 2h ago”），最新对话始终完整展开（#8505559fa）——群聊不会越滚越长，翻历史也一目了然。头像也换风格了：默认变成由 agent 名字确定性生成的 blob 脸（同一个名字永远同一张脸），还新增了 4 个剪影（blobatar 2.0.0，#a77ee88ce、#cb0fd836a）。想系统了解群聊玩法，可以看我们之前的 Bot Mode 群聊指南。

hermes worktree list/prune：积压 worktree 的安全大扫除

回到开头的场景。多 agent 工作流（hermes -w 或 /worktree new）跑久了，.worktrees/ 下会积压几十个树和上百个已合并分支。启动时的静默清理只敢碰“干净且完全合并”的树，其余永远留着——保守是对的，但意味着你只能手动一个一个看。

v0.20.5 给了显式、可预演的回收命令（#f309f92d3）：

hermes worktree list              # 审计：每棵树一行——年龄、体积、裁决、原因
hermes worktree prune --dry-run   # 只看计划，不改任何东西
hermes worktree prune             # 回收安全树 + 已合并分支

list 会输出一张表格：树名、年龄、体积、verdict（reap/keep）和原因，底部汇总“共 N 棵树、X 总量、其中 Y 现在可回收”。安全不变量和启动清理器完全一致：带跟踪改动的树任何情况下都不删，未推送的独有提交绝不删（git cherry 判断“独有”，浅仓库先无损加深再判断），存活进程锁定的树不碰，分支只在它的 worktree 成功移除后才删，纯未跟踪的杂物先归档到 ~/.hermes/archive/worktree-prune/ 再回收——只收垃圾，绝不丢活物。

更新有回执了：hermes update --plan

“更新到底发生了什么”过去是个黑箱：打印 ✓ Code updated! 就算完，helper 在打印后死了、重启被跳过、桌面端报失败但其实成功了——这些静默失败类（#88848、#74973、#85753、#81193）全靠事后猜。v0.20.5 让更新证明自己做了什么（#0aecadc17、#1d74833d8）：

• hermes update --plan：只读模式，先列出这次更新会碰什么——安装类型（git/docker/nix）、所有 profile 下每个正在运行的 Hermes 服务及其 supervisor 和运行中的代码版本、每个服务将如何重启。在活着的集群上跑完全安全。
• 结构化回执：每次 hermes update 把“发现了什么、做了什么、跳过了什么（及原因）“写成 JSON，存到 <HERMES_HOME>/logs/update_receipts/。更新后还会读取每个 profile 的 gateway_state.json，把每个存活 gateway 的 code_sha 与刚更新的 checkout HEAD 比对，打印一张群版本矩阵——混合版本集群第一次变成醒目的报告，而不是潜伏的状态。

升级前先跑 hermes update --plan 看一眼，升级后查回执，谁在什么版本上一目了然。这和我们之前写的 v0.20.4 里那个对停驻分支说实话的 hermes update 是一脉相承的：更新这件事，正在从“信任我”走向“可验证”。

cron 任务有记忆了，还能按任务调思考档位

cron 任务过去是被区别对待的：skip_memory=True，MEMORY.md/USER.md 从不加载，memory 工具被硬性剥离——即使你在任务的 enabled_toolsets 里点名要 memory 也没用。用户只能靠 hacky 绕过。现在 cron agent 和其他 agent 一样启用持久记忆（#ef04d846e）：任务能读到、也能更新你的持久记忆。

同时每个任务可以单独指定 reasoning effort，独立于全局 agent.reasoning_effort 和按模型的 reasoning_overrides（#4e1dd1a74）：

# 重活跑 high，轻活跑 minimal，全局默认纹丝不动
hermes cron create "0 7 * * *" --reasoning-effort high --prompt "深度分析本周仓库趋势"
hermes cron create "every 5m"  --reasoning-effort minimal --prompt "健康检查并汇报"

档位有 none/minimal/low/medium/high/xhigh/max/ultra；模型不支持的档位会被 provider 自动钳制（在 max 封顶的模型上钉 xhigh 就跑 high）。编辑时传空字符串清除钉住值。cron 的更多玩法见我们的 cron 自动化完全指南。

opencode-free：真正零配置的免费模型

opencode-free 升级为完全 keyless 的 provider——不填环境变量、不注册账号、匿名走线（#ca06b8768），同时目录漂移同步把 live 的 OpenRouter 免费模型拉进列表、清掉死掉的免费 slug（#624723130）。升级后 keyless provider 在所有地方都算“已认证”：opencode-free 直接出现在 /model 和桌面选择器里，零设置可用（#2a2307e68）：

hermes model    # 选 opencode-free，不需要任何 key

如果你还没配过免费模型，这等于开箱就有一个能用的选项。配上我们之前介绍的免费搜索五通道，一台全新安装的 Hermes 可以完全零 key 跑起来。

其他的“没人在做但人人都要”的改进

• 执行纪律与停滞护栏（来自 Composio eval 发现）：后台审查取消同步化、前台优先级正确（#37da0d4d5、#b883756b7），Ox Alpha reasoning effort 钳制后可靠到达线缆（#d4d04098a），提示缓存的 cache-control 装饰幂等化（#0fc52b055）——长跑任务更不容易卡死或乱花 token。
• 桌面性能：Bot Mode 首屏水合、compositor spinner、两个渲染器都启用 React Compiler。
• 编辑老会话里的消息不再失败（#02e270a47）；Telegram DM 草稿流式发送后保留富文本（#790c85014）；Docker stage2 的 API_SERVER_KEY 引导不再依赖 .env 存在（#7a17a1b8a）。

完整的逐条亮点（含 Improvements 和 Fixes 清单）见我们的 v0.20.5 发版说明。升级命令很简单：

hermes update

升级后跑 hermes doctor 验证安装，并重启 gateway（hermes gateway）让平台变更生效。想先看这次更新会碰什么，就先跑 hermes update --plan。这个版本没有炫酷的大招，但它把一群“没人点名要求、但每个人都撞到过”的琐事一次清完了——大扫除这种事，做完了才觉得痛快。