止观
Hermes实战

AI 圈拼了：7 天 1800 个 PR，Hermes 0.21.4 把你的 AI 助手先修到不炸

止观 2026-09-22 · 14 阅读

昨天例行看版本，Hermes 又双叒出新版了：v0.21.4（2026.9.21）。距离 v0.21.3 那次“三天连发放”，整整七天。

先给这版定性，免得你被数字吓到：官方 tag 说明里写得很直白——这是一个 patch rollup（补丁集合包），收了自 0.21.3 以来合并的约 1800 个 PR，目的是给 Docker 镜像和 Hermes Cloud 一个稳定标签，“完整的策展版说明留给 0.22.0”。

翻译成人话：这一版不憋新玩法的大招，而是把上一个大版本周期里所有“用户报了什么火，我们就灭什么火”的修复钉成一个稳定点。我在本机仓库数了下两个 tag 之间的提交（git log v2026.9.14..v2026.9.21 --no-merges），5173 个非合并提交，按 conventional commit 前缀分桶：

类型数量占比
fix 修复309561%
test 测试62112%
chore 杂务3156%
feat 新功能2886%
docs 文档2495%
refactor 重构2455%

六成是修复，新特性只占 6%。对追新的人这版“没意思”；对把 Hermes 当生产工具挂 24 小时跑的人，这种版本才是一年里的硬通货。改动最集中的模块：desktop（710 条）、gateway（366）、cron（190）、kanban（133）、agent（165）、update（109）。

0.21.4 修复分布

下面挑跟“你的日常”关系最近的讲。每个特性都按“以前什么行为 → 现在什么行为”来过源码（cron/jobs.py、agent/、hermes_constants.py）。

※ ※ ※

📅 定时任务：终于不用挨个改模型

这是对运维人群最有用的改动：feat(cron): jobs follow the main agent model at fire time; pinned locks it on request。

以前的痛点：你在 config 里换了主模型（比如从 A 模型切到 B 模型），已建好的 cron 任务还咬着创建那一刻的模型不放。想全家换引擎？挨个 job 重编辑。换了忘了，第二天发现简报任务还在烧旧模型的额度。

现在的行为：任务在触发那一刻跟随主 agent 的当前模型。你要想让某个 job 锁死在特定模型上（比如某个重任务只认某模型的长上下文），建任务时加 pinned，锁就锁上——我在 cron/jobs.py 里确认了实现：pinned 不落库存储，它改写的是每个任务的 model pin，“True 且没显式指定模型”就用当时的主模型去锁。也就是说：pin 是快照动作，不是一种状态字段，语义干净。

顺手的好处：配合上一版（0.21.3 那篇我写过）修好的“cron 静默输出、投递失败兜底”这条线，定时任务这一层在这版基本完成了从“能跑”到“改起来不用回头看”的过渡。

※ ※ ※

🧹 Hermes 有了自己的临时抽屉

feat: Hermes-owned scratch dir replaces the system temp dir for every process and child。

以前所有 Python 进程共用 /tmp，重启清空、互相踩踏、多用户机器上还有一堆权限和符号链接的坑。现在 Hermes 在 $HERMES_HOME/cache/scratch 下开了自留地，环境变量（TMPDIR 那套）统一重定向进去，所有子进程继承，条目超过保留时限自动清理——但保留期是 Hermes 自己定的策略，不再看系统重启的脸色。

源码注释里连细节都有：AF_UNIX socket 路径有长度上限，个别系统上 /tmp 反而是短路径，所以 socket 单独退回系统默认根目录，“其他一切都留在 scratch 里”。这就是 patch rollup 的价值：连这种边界都有人替你踩过。

※ ※ ※

🧠 两个“不慌”补丁：错误分级和压缩兜底

其一，feat: model-provider plugins classify their own API errors via ProviderProfile.classify_api_error。以前各家 API 报错混在一起，“这到底是限流、鉴权失效还是配额用尽”由通用逻辑猜，猜错了 fallback 链就乱触发。现在每个 provider 插件自己交分类器——你的 OpenRouter、Anthropic 兼容网关的 429 是不是配额问题，由最懂它的人说了算。配套还有 feat(agent): bounded auto-recovery ladder after retries and fallback are spent：重试和 fallback 全部打完之后，进入有界的自动恢复阶梯，而不是直接摆烂或无限重试。一句话：模型出故障从“要么慌要么死”变成了“按梯子一层层试，试完体面报错”。

顺带两个 auth 修复值得知道：treat credential-resolution 429 as quota, not auth（配额 429 不再误判成登录失效把凭据拉黑）、one primary_failure_wording() helper labels quota vs auth failure at all three fallback surfaces（三处报错界面对“没额度”和“没登录”的措辞统一）。被“Invalid API key”假报错骗过的人，这版会安静很多。

其二，上下文压缩（compression）这一路修了 50 条，三条最有代表性：cap the protected tail at 20% of the context window（压缩时被保护不许动的“尾巴”封顶在窗口 20%，防止某次压缩把大半个窗口锁死）；an auto-resolved summary model that fails falls back to the main model and is named in the warning（自动选的摘要小模型挂了会回退主模型，且警告里点名是哪个模型挂的）；fix(compression): stop detached stale attempts writing shared compressor state（已经脱手的过期压缩任务不许再回头写共享状态）。压缩是最容易“静默毁上下文”的模块，这一批修的全是静默类问题。

※ ※ ※

🔄 升级器自己修了一堆升级事故

update 作用域 109 条改动，几乎全是 hermes update 之后“gateway 该重启没重启、不该重启被重启”这类事故：never disarm the host restart obligation（主机的重启义务不许被解除）、pending fleet restart leaves gateways already on the checkout code alone（多 gateway 场景里，代码已经切过去的实例不再被重复折腾）、a supervised serve backend no longer pins the fleet-restart warning on forever。另外 feat(update): hermes update --list-venv-holders prints the venv guard's holders as JSON, exit 3——升级被“有进程占着 venv”挡住时，现在能直接打印是谁占着的。谁在 gateway 里跑过 hermes update 结果把自己杀了的，懂这个 JSON 输出的含金量。

※ ※ ※

📱 桌面端与多 Profile：一次架构收敛

desktop 710 条是最大头，值得单独说的是后端池的收敛：refactor(desktop): collapse the per-profile backend pool onto one host backend 加 feat(desktop): attach to the running host backend instead of spawning a second one。以前每个 profile 可能各拉一个后端进程，桌面 App 打开多 profile 时机器里全是重复的 Python 后端；现在向“主机单一后端、桌面 attach 上去”收敛。profile 隔离的是数据目录、凭据作用域、terminal 作用域，不再是“每个 profile 养一个进程”。内存小的 VPS 和轻薄本对这个改动感受最直接。

Bot Mode（多 bot 群聊）也修了一批数据一致性问题：解散过的群如果同名重建、恰好落在同步窗口内，不会再被误删（durable disband memory is keyed by roomId only），跨机器房间的消息归属也补齐了。

※ ※ ※

🛡️ 安全的毛细血管

挑三个小的，都是会出大事的类型：

  • ▪ fix(kanban): scrub the dispatcher's credentials from another profile's worker——看板派发器不再把别的 profile 的凭据混进子 worker 环境；
  • ▪ fix(approval): cover zsh/ksh/dash in every pipe-to-shell pattern——curl | sh 审批拦截以前按 bash 语法识别，换 zsh/ksh/dash 的马甲能绕，这版全堵上；
  • ▪ fix(tts): reject MEDIA directives and control chars in output_path——TTS 的 output_path 参数不许再塞 MEDIA 指令伪造“发送文件”动作。这条修的是把工具参数当指令执行的老攻击面。

※ ※ ※

📨 平台侧：微信、飞书、Telegram

你日常收通知的三条通道各有实质修复：

微信（weixin）：ret=-2 “prepare failed” that survives recovery is a session error, not a rate limit (#80125)——以前 iLink 的这个错误码恢复失败后仍被归为“限流”，触发无谓的冷却重试；现在正确归类为会话错误。媒体发送也补了 honoring ret 与 stale token 重发的修复。一句话：走微信投递的自动化，误判限流的次数会肉眼可见地减少。

飞书（feishu）：retain attachments in text batches——长文本分批发送时，批次里的附件不再被丢掉。发图文混排报告的场景这版更稳。

Telegram：一组限流与媒体修复——按 chat 共享发送节奏槽位（pace sends and edits against a shared per-chat slot）、大视频带真实几何参数和缩略图（不再糊成正方形）、所有 Bot API 发送加挂钟 deadline（300s 媒体单独计）、冷启动可选择保留离线队列不丢消息。

※ ※ ※

跟 0.21.3 的关系：一张对照表

上篇写 v0.21.3 时我说过，那版把主要火力砸在定时任务与投递链路上（cron 静默哨兵、投递失败告警、fallback 链治理）。0.21.4 是它的延长线，层次关系是“止血 → 包扎 → 复查”：

维度v0.21.3（2026.9.14）v0.21.4（2026.9.21）
定位补丁卷，重点修 cron/投递补丁卷，约 1800 PR 稳定标签，供 Docker/Cloud
模型配置config 兼容层收口cron 触发时跟随主模型 + pinned 锁定
故障处理fallback 链治理provider 自分类错误 + 有界恢复阶梯
压缩—尾部保护封顶、摘要模型回退、过期任务围栏
升级更新检查重启义务状态机大修 + venv 占用者 JSON 输出
桌面若干修复后端池向单 host backend 收敛
新特性少量288 个 feat（含 skills.auto_load、声明式 OAuth PKCE 登录）

另外两个不起眼但我喜欢的新项：skills.auto_load 配置键可以把指定技能钉进每个新会话的提示词（常用工作流不用再靠模型自己想起来加载）；feat: declarative OAuth Authorization-Code+PKCE login for provider plugins——provider 插件从此可以用声明式配置走 OAuth 登录，不用每家手写一遍授权流。

※ ※ ※

要不要升

我的判断标准：把 Hermes 当“挂着的系统”用的（cron、gateway、多平台投递），升；当“周末玩一下的 CLI”用的，等 0.22.0 的完整说明再一次性看完。

升级动作本机实测过，两条路。官方渠道：hermes update。git 安装（我的环境，GFW 服务器走 gh-proxy 拉 tag）：git fetch --tags 确认 v2026.9.21 的 pyproject.toml 里 version = “0.21.4”，git checkout v2026.9.21，venv 里 pip install -e .，最后外部重启 gateway。我的旧 HEAD 恰好是新 tag 的祖先，快进零冲突，升级后 hermes --version 输出：

Hermes Agent v0.21.4 (2026.9.21) · upstream 524041b9
Install directory: ~/.hermes/hermes-agent
Install method: git

一个提醒：官方说全量策展说明随 v0.22.0 发布，按这个节奏，大概率是下个功能版本前还有一批新特性在路上。0.21.4 是这段狂奔的“扎营点”——先修稳，再出发。

下一篇预告：skills.auto_load 与技能加载机制细看一眼——Hermes 怎么决定“哪些技能常驻提示词、哪些按需加载”，以及提示词缓存（prompt caching）在这条链路上被怎样小心翼翼地保护。

※ ※ ※

资料来源

  • ▪ Hermes Agent 官方仓库（NousResearch/hermes-agent）tag v2026.9.21 的附注文本与 pyproject.toml；v0.21.4 release 说明
  • ▪ 分类统计与提交清单：作者本机仓库 git log v2026.9.14..v2026.9.21 --no-merges（5173 条非合并提交）程序化统计，fix/feat/test 等按 conventional commit 前缀归桶
  • ▪ 源码核对：cron/jobs.py（pinned 语义）、hermes_constants.py（scratch 目录与 AF_UNIX 注释）、agent/error_classifier.py 与 agent/chat_completion_helpers.py（classify_api_error 调用链）
  • ▪ hermes --version 升级后终端输出为本机实跑记录
  • ▪ 文中示例均为通用场景描述，未使用作者真实服务器的运行数据与账号信息；升级命令中的路径已做通用化处理

生成日期：2026-09-22

评论 (0)