周末继续卷！Hermes 两天更新超 100 个提交，这 8 个关键变化建议关注

这个周末 Hermes 基本没有休息。

我重新把最近两天已经进入 main 分支的提交往回翻了一遍，提交量已经轻松超过 100 个。这里面当然有测试、格式整理、回归修复这些普通维护工作，但真正影响使用体验的变化也非常密集。

而且这一次有个很明显的感觉：Hermes 最近关注的重点，正在从“还能给 Agent 加什么新工具”，转到“怎么让一个长期运行、多 Bot、多设备的 Agent 系统真正可靠起来”。

我从这批已经合并的改动里挑了 8 个最值得各位朋友关注的变化。很多单独看只是一个功能点，连起来看，却能看出 Hermes 接下来到底准备往哪里走。

一、Bot Mode 真正跨机器了：一台 Desktop 开始管理一群 AI 同事

我觉得周末最重要的一条变化，还是 Bot Mode。

以前我们说 Hermes 可以建立多个 Bot，更多还是在一套 Hermes 环境里理解这件事。比如研究 Bot、开发 Bot、测试 Bot，各有自己的 Profile，然后互相通过 message_agent 联系。

现在这个边界已经被直接打破。

只要 Hermes Desktop 已经连接了一台机器，不管它是：

本机Remote URLSSHHermes CloudDocker

这台机器上的 Bot 都可以逐渐进入同一套 Bot Mode 协作体系。

更关键的是，message_agent 已经能够沿着 Desktop 现有的连接，把消息送到另外一台 Gateway 上的 Bot。

整个结构开始变成：

                   Hermes Desktop┌────────────────┼────────────────┐│                │                │本机             SSH 主机        Hermes Cloud│                │                │Research Bot       Dev Bot          Ops Bot│                │                │└──────── message_agent ──────────┘

Desktop 在这里很像一个总调度台。

各个 Gateway 不需要互相拿到对方的 Credential（凭据），Desktop 利用已经建立好的认证连接在中间转发消息。

与此同时，Bot Mode 的界面也在往 Fleet View（实例群视图）发展。多 Gateway 环境下，可以统一看到不同机器上的 Bot，并按照 Gateway、类型、活跃状态去搜索和筛选。

甚至某一个 Profile 现在都可以直接在 Desktop 里单独指定：

Connect to a remote host…

以前这类配置还需要手工修改 connection.json，现在已经开始变成正常的图形界面能力。

这件事的意义其实很大。

以后“一个 Bot”未必代表“我电脑上开的另一个 Agent”，它可能是真正在另外一台电脑、服务器或者云主机上工作的 AI 同事。

Hermes Desktop 则越来越像这些 AI 同事的总管家。

二、Bot 能互相说话以后，Hermes 开始解决“消息到底靠不靠谱”

Bot 跨机器只是第一步。

真正让多个 Agent 长期协作，马上就会碰到另外一堆问题：

对方离线了怎么办？消息卡在队列里怎么办？两个任务同时塞给同一个 Bot 怎么办？后台 Bot 出错以后，人怎么知道？

这个周末 Hermes 一口气把这一整条链路补了很多。

首先，Bot 的错误不再只是一大段模型返回的英文错误。

现在开始拥有结构化的 Failure Reason（失败原因），例如：

provider_auth_or_accessprovider_quota_limitprovider_rate_limitprovider_server_errorcontext_overflowmissing_configmodel_unavailableruntime_offlinequeued_expiredtarget_busy

这样 Hermes 才能真正区分：

重新登录就能解决余额没了模型不存在对方 Bot 根本不在线

这听起来像一个小改动，其实很关键。

只有错误被机器真正理解，后面才可能自动决定：

该不该重试该不该等该不该提醒用户还是应该直接停止

Desktop 也开始给后台 Bot 增加黄色的 Needs Attention（需要关注）提示。如果 Bot 因为认证、额度、缺少配置或者被阻止而失败，不需要你主动打开它的聊天记录才发现。

下一次 Bot 成功运行以后，这个警告又会自动消失。

这种设计越来越像真正的工作团队：

正常工作的时候别烦我，真的处理不了再来找我。

三、Bot 通信明显变快了，而且“离线、过期、撞车”都有了规则

这条我觉得特别能说明 Hermes Bot Mode 已经进入第二阶段。

之前跨 Gateway 的 Bot Relay（Bot 消息中继）主要靠轮询。

简单理解就是 Desktop 每隔几秒去问：

有新消息吗？

于是最坏情况下，单跳消息可能要等大约 4 秒才被发现。

现在增加了主动通知：

Bot 写入新消息Gateway 发现 Outbox 变化主动通知 DesktopDesktop 很快开始 Drain

官方给出的最坏单跳延迟，大约从：

约 4 秒约 1.25 秒

而原来的轮询还保留着，作为失败时的兜底。

这其实是非常成熟的做法：

Push负责快Poll负责稳

另外，消息现在还有默认 TTL（存活时间）。

默认：

900 秒

也就是 15 分钟。

假设你让 Research Bot 给另一台机器上的 Dev Bot 发消息，而 Dev Bot 一直没有处理，这条消息不会在队列里躺几个小时后突然执行。

超过时间，就明确返回：

queued_expired

如果已经明确知道对方离线，甚至根本不会傻傻入队等待，而是直接：

runtime_offline

更有意思的是并发。

以前两个任务差不多同时冲进同一个 Bot，有可能两个 Turn（轮次）一起跑，争同一份上下文和状态。

现在开始给 Profile 加 Turn Lock（轮次锁）：

任务 ABot 正在执行任务 B排队等待

默认最多等待 120 秒，依然轮不到就返回：

target_busy

看到这里我反而觉得，Hermes 最近真正开始做的已经有点像“Agent 操作系统”了。

因为消息队列、超时、过期、锁、状态码这些东西，本来就是传统分布式系统里绕不开的问题。

多个 AI 真正开始长期协作以后，一样绕不过去。

四、Group Chat 也开始像真的团队了：“停下”终于不是一句普通聊天

多人 Bot 协作这次还有两个很有意思的修复。

第一个是重复回复。

真实的四 Bot Group Room（群组房间）里曾经出现过这种情况：

用户发一条消息Bot 开始回答中间状态发生变化旧的一轮和新的一轮都把结果写回来同一条回复出现 2～3 次

现在 Hermes 会在 Bot 完成工作以后再次检查：

这轮任务还是当前有效的吗？

已经被新任务取代的旧结果直接丢掉，同时再加一层相邻重复消息保护。

第二个变化我觉得更有意思。

以前你在 Group Chat 里说：

stop @researcher

Bot 可能回答：

Stopped.

但这个“停止”实际上只是聊天记录里的文字。

等房间下一次出现新变化，这个 Bot 又可能重新领取工作。

现在开始变成真正的 Durable Hold（持久暂停状态）。

stop @researcherResearcher 被 Hold后续房间变化也不能自动重新工作

直到你明确：

@researcher resume

或者重新直接给它任务，它才恢复。

甚至：

@all stop

也开始真正暂停所有成员。

这个细节非常值得注意。

Agent 系统里，人说一句“停”，如果只是写进对话历史里，其实没有多大意义。

真正可靠的系统需要把人的意图转换成系统状态。

“停止”应该是一种状态，不应该只是一句话。

五、Codex 的 900K 上下文终于改成“你自己决定要不要开”

这条对经常用 Codex 的朋友非常实用。

前面 Hermes 验证出部分 GPT Codex 模型实际上可以跑非常大的上下文窗口，于是曾经把部分模型自动提高到了 900K。

能力当然很爽。

问题也很直接：

大上下文不是免费的。

上下文越大，Hermes 越容易把大量历史一起带入后续请求，Input Token 消耗自然会上去。

社区里已经有人反馈，本来并没有主动要求 900K，结果订阅 Usage 在几个小时内快速消耗。

所以现在规则重新改了。

例如：

gpt-5.6-sol

默认重新按照：

272K

使用。

真想开大窗口，则明确选择：

gpt-5.6-sol-900k

Hermes 会把它当成 900K 上下文处理，但真正向 Codex API 发请求的时候，还是会把 -900k 这个 Hermes 自己添加的标记去掉。

它其实是在 Hermes 这一层新增了一种：

上下文档位。

甚至 Compression（上下文压缩）策略也跟着分开了。

272K 的基础模型会更晚压缩，尽量利用有限窗口；900K 大窗口则尊重正常的全局压缩阈值，不会因为“窗口很大”就一直拖到几十万 Token 后才整理。

我很赞同这种设计方向。

以后模型选择不应该只是：

哪个模型最强？

还应该多一个问题：

这个任务到底需要多大的上下文？

日常任务 272K 已经非常夸张。

900K 更适合真正需要超长历史、超大代码库或者持续几十轮工作的任务。

大上下文应该是一项主动选择，而不是一个偷偷打开的耗油模式。

六、Hermes Desktop 的语音链路也变短了

这个周末还有一条容易被 Bot Mode 抢掉风头的更新：Voice。

以前 Desktop 语音的一些链路比较绕。

大概可以理解为：

麦克风DesktopGatewaySTTGatewayDesktop

播放回复也有类似的中转。

现在在支持的 Provider 上，Hermes 开始采用 Client Direct（客户端直连）。

麦克风音频可以：

Desktop直接调用当前 Profile 的 STT

而 Hermes 的回复文字本来就已经通过 Chat Socket 到了 Desktop，于是 TTS 也可以：

回复文字Desktop直接调用当前 Profile 的 TTS播放

这样 Desktop 和 Gateway 之间主要传文字，而不是再绕一圈音频。

Hermes 也没有为此创建第二套 API Key 仓库。

语音会话启动时，Desktop 从已经认证的 Gateway 获取当前 Profile 实际解析出来的 Provider、Model、Language 和凭据。

不支持 Client Direct 的情况继续退回原来的 Relay（中继）模式。

所以整个结构是：

能直连→ 走最短路径不能直连→ 原方案兜底

我觉得这类变化看起来没有新增一个按钮那么显眼，但很可能比加按钮更影响体验。

实时语音最怕的就是延迟。

每少绕一层，实际说话体验都会更自然一点。

七、截图越来越多以后，Hermes 开始认真控制“图片吃上下文”

Hermes 最近浏览器和视觉能力越来越多，一个新问题也跟着出来了：

截图特别吃上下文。

尤其 Browser Agent 做网页 QA 时，很容易出现：

截图分析再截图再分析又截图

如果每一张高清截图都永久塞进历史记录，再大的 Context Window 也经不起这么折腾。

这次 Hermes 把 History Embed（历史图片嵌入）控制到：

最大约 256 KB最大长边约 1568 px

而且只保留最近几张真正需要模型继续看的图片，旧截图在后续 Compression 中可以退化成文字占位。

这里还有一个很实用的后续优化。

以前 PNG 太大以后，因为 PNG 没有类似 JPEG 那样的 Quality（质量）压缩档位，只能：

1568 px直接砍尺寸784 px

网页截图里的小字一下就看不清了。

现在会优先：

保持 1568 px 分辨率转 JPEG逐步降低质量直到进入大小限制

也就是：

尽量牺牲一点图片压缩质量，而不是先牺牲文字可读性。

对于让 Hermes 检查网页、识别界面、找按钮来说，这个取舍明显更合理。

这背后其实也是一个非常重要的 Agent 设计问题：

模型上下文里真正贵的，并不只有文字。

以后桌面 Agent 越来越多地处理：

截图PDF网页视频帧文件

怎么管理这些 Multimodal History（多模态历史），会直接决定一个 Agent 能不能连续工作几个小时甚至几天。

八、最值得关注的变化：Hermes 开始给“无限运行”装护栏

最后这条我反而觉得特别重要。

Hermes 越来越强调让 Agent 长时间工作，某些 Turn 的默认 Iteration（迭代次数）甚至已经接近 Unlimited（无限）。

但“可以一直工作”和“任何错误都可以一直重试”，完全是两件事。

最近就出现了一个非常典型的问题。

当某种永久错误穿过正常的 Retry/Fallback 机制以后，外层 Conversation Loop 可能不停重试。

实测速度大约能达到：

约 64 次 / 秒

结果就是：

一个 CPU Core 打满错误日志疯狂刷屏几分钟覆盖几天的轮转日志

现在外层错误有了独立上限：

最多 8 次

超过以后明确结束为失败，而不是继续烧资源。

同一批更新里还有另外一个更夸张的案例。

state.db 损坏以后，Hermes 的自动修复曾经因为错误地判断“这是新的损坏文件”，不断：

备份修复文件时间变化认为又是新的损坏重新备份重新修复

真实报告里：

11 天89 GB

不是业务数据增加了 89GB，而是修复机制自己进入了循环。

现在损坏判断、尝试次数以及 Forensic Backup（取证备份）机制都进一步收紧，备份也开始采用更严格的原子发布和回滚。

我觉得这两个 Bug 放在一起看特别有意思。

Agent 系统最危险的事情很多时候并不是“一次做错”。

而是：

它很勤奋地把错误重复做了几十万次。

所以未来 Agent 系统一个非常重要的设计原则应该是：

能力可以越来越强重试要有上限队列要有过期任务要有锁存储要有预算危险失败要 Fail Closed

这其实比再增加几个 Tool 更重要。

最后聊聊：这个周末的 Hermes，已经很不像单纯的 AI 聊天工具了

把这两天超过 100 个提交里真正重要的变化放在一起，我看到的其实是三条非常清晰的路线。

第一条是：

单机 Agent多个 Bot跨 Gateway跨电脑一个 Desktop 管理整支 AI 团队

第二条是：

Bot 能通信通信有错误类型有离线判断有消息 TTL有并发锁有 Push有人工 Attention

第三条则是：

无限上下文无限任务自动修复自动重试开始全部增加明确边界

所以我觉得这个周末最值得关注的，其实并不是 Hermes 又堆了多少功能。

真正的变化是，它越来越认真地处理一个成熟 Agent 系统迟早必须面对的问题：

如果 AI 要真的替人持续工作，那么它必须知道自己在哪台机器上、该联系谁、什么时候应该等、什么时候应该停，以及什么时候必须回来找人。

这也是我现在越来越关注 Hermes Bot Mode 的原因。

AI 同事真正难的部分，从来都不是“再开几个聊天窗口”。

真正困难的是：

怎么让这些 AI 同事长期协作以后，依然不会乱、不会丢、不会抢、不会死循环。

而这个周末的大量提交，明显已经开始往这里走了。