AI 深度技能之-解读Hermes Agent（九）- Hermes Bot

8 月 11 日，xAI 发布 Grok Bot，宣传语是"永不睡觉的雇员"。8 月 17 日，Nous Research 的 Hermes Agent 发布 v0.20.3，Bot Mode 默认开启。中间隔了六天。

社区把这读成一次回击，Nous 的 Teknium 也确实在 8 月 15 日发过一条"48 小时公测 Bot Mode 插件"的征集帖。但看完官方文档、源码仓库和三个月实测记录后，我的结论是：两家卖的是同一种话术，走的是完全相反的路线。这篇文章把 Bot Mode 的功能、架构和工程细节拆开讲清楚，顺带说清楚它和 Grok Bot 到底差在哪。

一、Bot Mode 是什么

一句话：把 Hermes 的 profile 列表换成一个有名有姓的机器人花名册。每个 Bot 有自己的头像、角色、模型、记忆、技能和常驻聊天窗，你像管理一个团队一样管理它们。

关键设计决策只有一个：Bot 就是 profile，没有引入任何新原语 。隔离的配置、记忆、技能、凭据、聊天历史，全部存在 ~/.hermes/profiles/<name>/ 目录下面。Bot Mode 是套在这层已有原语上的 UI。

这个决策的分量在后面的架构部分展开。

二、架构拆解：零新原语意味着什么

先看代码位置。Bot Mode 的实现全部在 apps/desktop/src/plugins/hermes-bots/，是一个标准的桌面端插件：没有 core patch，没有后台守护进程，没有新的存储层。

分层看：

• 最底下是 Profile 原语层，每个 profile 目录里有 config、SOUL.md（人设）、memory、skills、credentials、history，cron 作业按 [bot:<name>] 命名空间挂在调度器上。这一层全部是 Hermes 已经跑了很久的东西。
• 中间是 hermes-bots 插件，做四件事：把 profile 渲染成花名册条目，把永久聊天里的 /new 重定向成 /compact，在 prompt 构建时往 Bot Chat 的系统提示里注入通信协议（agent.bot_mode_protocol: true，默认开启），把类型化错误码翻译成界面角标。
• 最上面是桌面 UI：花名册、Active now 状态条、Bot Chat 窗口、群聊房间、Connections 面板。

三个入口完全等价。你在桌面端建的 Bot，命令行直接用：

hermes -p blogi chat

你在命令行挂的 cron 作业，桌面端花名册里照常显示。UI 不是特权入口，只是渲染层。

代价和收益都来自同一处。收益是插件可以随时关掉（Settings → Plugins → Bots），关掉之后 profile、会话、cron 原地不动，一个字节都不丢，因为 Bot Mode 从不拥有数据。代价是所有重活必须下沉到原语层做，UI 层只做轻逻辑，比如 /new 重定向成 /compact 这种。

独立仓库 NousResearch/Hermes-Bot-Mode 已经转为归档状态，公告写得很直白：开发继续在主仓库进行。一天公测插件直接并入主干并默认开启，这个速度在同类项目里我没见过第二个。

三、七个功能点，每个都有取舍

1. 永久聊天（Canonical Bot Chat）

每个 Bot 出生时就有一个固定的 Bot Chat，点花名册永远回到这个会话。有意思的细节：你在永久聊天里敲 /new 或 /reset，会被重定向成 /compact。新鲜的工作上下文，但关系不断。同一个 profile 下的普通会话不受影响，照常 /new。

这解决的是"每次开新会话，agent 就失忆一次"的老问题。代价是永久聊天无法真正清空，上下文只会被压缩，隐私敏感场景要留意。

2. 花名册与在线状态

左侧一列，每行一个 Bot：头像、最新消息预览、时间戳。上方一条 Active now 状态栏，显示正在工作的 Bot（gateway 忙碌的，或 90 秒内发过消息的），点状态条直达其聊天。花名册永不重排，全员空闲时状态栏消失。

右键可以 Hide Bot，但隐藏只是显示层面：@提及照样命中，routine 照跑，未读照样堆积。想真正退役一个 Bot，得走 Delete Profile。这是原语层决定的：UI 能藏，数据动不了。

3. 建 Bot 的门槛压得很低

新建对话框只要三个字段：名字、头衔、描述。点开 Advanced 才是完整的 profile 配置：从现有 profile 克隆、钉死某个 provider/model、写自定义 SOUL.md、逐技能逐工具集逐 MCP server 勾选开关。凭据默认共享池，刷新一个 Bot 的 token 不会废掉其他 Bot 的。

克隆是双刃剑，后面实测部分会看到它带来的技能漂移问题。

4. 群聊有硬性熔断

任何分组头部点 Open chat，开一个 2 到 6 个 Bot 的共享房间。你发一条消息，触发最多三轮串行发言：被 @ 的 Bot 回应（没人被 @ 就全体回应），每个 Bot 简短回复或直接 pass，一整轮没人说话房间就安静下来。Bot 之间用 @name 互相拉人，遇到需要人拍板的事用 @user 上报，群头部亮 needs you 角标。

每条消息上限 10 条、总轮数 3 轮。这个熔断防的是几个模型客客气气地循环点头，把 token 烧在互相附和上。每个成员各存各的 Group: <name> 会话，房间上下文像普通对话一样持久。

5. 失败重试带类型化错误码

失败回合最多自动重试一次，且只在该重试的时候重试。错误码是结构化的，完整列表 12 个，按重试行为分四组：

# 瞬时故障，原会话重跑一次
runtime_offline · delivery_timeout · provider_rate_limit · provider_server_error

# 先压缩过长的上下文再重跑
context_overflow

# 第二次也没用，从不自动重试，直接上报
provider_auth_or_access · provider_quota_limit · missing_config

# 其余
model_unavailable · queued_expired · target_busy · unknown

重试永远在原会话上跑，不会开新会话，Bot Chat 的历史和上下文原样保留。

调用方 agent 按码分支，不用去解析各家 provider 的错误散文。桌面端的"需要关注"角标用的同一套码。这个设计值得单独抄走：错误分类是 agent 间协作的基础设施，不是 UI 的锦上添花。

6. 跨机器是原生能力

Settings → Connections 里注册的每条连接（本地、远程 URL、SSH、Hermes Cloud、docker）都是一条常开线路，Bot Mode 直接复用。花名册自动传播：桌面端定期告诉每条线路其他连接上有哪些 agent，Bot Chat 的队友列表自动刷新，跨机器同名 Bot 用 @name-device 消歧。

群聊房间镜像进共享 profile 元数据，按 gateway 分版本号，合并而非覆盖。某台 gateway 挂了，桌面端仍持有完整房间副本，回来后重新播种。这是把 CRDT 的思路用在了房间元数据同步上，实现得很轻。

7. 插件整体可拔

前面说过，关插件不丢数据。补一个细节：群聊房间存在共享 profile 元数据里，也不随插件关闭消失，重开插件后房间还在。

四、Bot 互聊走真 CLI：最值得抄的一段

这是整个 Bot Mode 里工程味最重的部分，分两层看。

模型层是一个叫 message_agent 的工具。每个 Bot Chat 的系统提示里注入了一份队友花名册，名字和职位来自每个 profile 的 title/description，Bot 动笔之前就知道该找谁。发消息就是调 message_agent(target="researcher", message="...")，收件人名字经花名册校验，邮箱和未知 @ 原样放过。这个工具只存在于 Bot Chat 会话里，普通会话、群聊成员会话、CLI 会话都看不到它。

投递层的实现是 Made Yoga 实测拆出来的：消息体写进临时文件（避开 shell 的引号展开和 $(...) 命令替换），然后执行：

hermes -p nuxti chat --in ~ -c "Bot Chat" --create-if-missing -Q --query-file /tmp/msg.txt

也就是说，Bot 互发消息没有内部总线，没有 RPC，底层就是你自己在命令行敲的那条 chat 命令。消息带署名前缀 Message from 🤖 blogi (@blogi):，收件 Bot 下次运行时才看到。发件方不阻塞等回复，拿一个确认就结束回合，回复作为后台完成通知到达。对方在忙就排队。

通信协议本身是在 prompt 构建时注入到 Bot Chat 系统提示里的（agent.bot_mode_protocol: true），SOUL.md 和普通会话不受污染。这个边界划得很干净：协议是信道属性，不是人格属性。

普通聊天里敲 @researcher 看看这个，当前 Bot 会自己组织语言转交，等回复，再向你汇报，且从不逐字转发。也就是说 Bot 间的语义压缩是默认行为，防止长上下文在接力中越传越肿。

为什么说这段值得抄？因为它把 agent 间通信的实现成本压到了地板上：复用已有的 CLI 入口、复用已有的会话存储、复用已有的排队机制，新增的只有临时文件约定、署名前缀和一段注入的系统提示。dsh 的 subagent 工具走的是进程内组合，Hermes 走的是进程间 CLI 交接，两条路线在"复用已有原语"这件事上是同一个思路。

五、对比 Grok Bot：同话术，两条路线

维度	Grok Bot	Hermes Bot Mode
发布	8/11，early beta	8/17，v0.20.3 起默认开启
形态	云端托管的常开 agent 队伍	自托管桌面端的 profile 花名册
Bot 的本体	一台 xAI 供给和运营的云电脑	本机一个目录 ~/.hermes/profiles/name
模型	Grok 全家	任意 provider 任意 model，可混搭
学习方式	演示一遍给你看，观察操作存成 routine	手写 SOUL.md + 勾选技能清单 + cron
计费	SuperGrok Plus/Heavy、Cursor Pro+/Ultra 订阅	MIT 协议，免费
企业能力	Enterprise waitlist	无 admin console、无 SSO、无审计日志
安全边界	画在用户账号上	画在 profile 上

两家卖的东西不一样。Grok Bot 卖成品雇员：给它消息它就干活，登录你的工具，端到端干完，只在需要审批时回来找你。xAI 内部用例包括销售 Bot 更新 CRM、运营 Bot 处理 Gmail 发票、工程 Bot 复现 bug 建工单再转给修复 Bot，宣传语"永不睡觉的雇员"就是这个故事的产品化。

Hermes 卖零件：profile、技能、cron、CLI 这些积木早就有，Bot Mode 只是给积木加了层花名册 UI。towardsai 那篇对比的总结很准：Grok 卖的是成品雇员，Hermes 卖的是造一个的材料，还给你收据。

安全边界的差别更实质。thenewstack 的分析把这条线画得很清楚：Grok Bot 的边界在用户账号，意味着你的工具凭据要交到 xAI 运营的机器上；Hermes 的边界在 profile，所有东西留在自己硬盘，代价是全套运维自己扛。marktechpost 的评价更扎心：Hermes 是工作站工具，不是可管理的基础设施。没有 admin console、没有 SSO、没有审计日志，企业场景短期内别想。

六、三个月实测暴露的糙点

博主 Made Yoga 用一套三个月的配置做了实测：Blogi 管写作、Nuxti 管前端、Aspi 管后端。暴露的问题比功能列表更有参考价值。

交付是逐次调用式的。发件方不等回复，Bot 在忙就排队，没有 live interrupt（官方文档明确列为后续工作）。实际效果就是你成了人肉调度器，得自己记得去开对方的 Bot Chat 收信。

技能清单会漂移。克隆建 Bot 太顺手，多余的能力没人回头清理，他的后端 Bot Aspi 上还挂着 Nuxt 和 Unity 的 MCP。工具越挂越多，模型选错工具的概率随之上行。

群聊硬上限是双刃剑。防了转圈，也限制了协作深度。他的结论是 DM 加 @mention 才是日常主力，群聊基本闲置。

已知 bug #92003：群聊里用户在成员回合没结束就追加消息，会打断该回合的延续。v0.20.5 补了群聊线程、折叠摘要和 blob 头像，这个 bug 在 issue 列表里还开着。

七、对自托管 Agent 设计的启示

这部分脱离 Hermes 本身，说三个可迁移的判断。

数据层越薄，翻新越快。Hermes 六天从社区喊话到默认开启，靠的不是加班堆功能，而是 profile/cron/CLI 这层原语足够稳定和通用，Bot Mode 只需要写渲染逻辑。反过来，如果数据结构里预埋了"Bot"这个概念，这次翻新就要动迁移逻辑，六天变六周。设计 agent 系统时，把领域概念往下压还是往上提，这个选择决定了后续每次迭代的成本。

CLI 可以当 agent 间协议用。Hermes 的 Bot 互聊、dsh 的 subagent 委派，实现方式完全不同，但都做到了一点：agent 间通信复用已有入口，不新造信道。新造信道的方案（消息总线、RPC、共享内存）每一种都要自己解决版本协商、超时、重试，而 CLI 天生自带这些语义。

错误码要类型化，越早越好。Bot Mode 的重试策略、界面角标、agent 分支判断全靠那套 12 个错误码。这在单体应用里是锦上添花，在多 agent 系统里是基础设施，因为协作的每一跳都需要机器可读的失败原因。字符串错误在第一个多 agent 系统出现时就会变成债。

信源

• Hermes Bot Mode 官方文档：hermes-agent.nousresearch.com/docs/user-guide/bot-mode
• Hermes Agent 主仓库：github.com/NousResearch/hermes-agent
• xAI Grok Bot 公告：x.ai/news/introducing-grok-bot
• marktechpost 分析：marktechpost.com/2026/08/17/nous-research-hermes-bot-mode
• towardsai 对比：pub.towardsai.net/grok-bot-vs-hermes-agent-which-always-on-ai-worker-should-you-trust
• thenewstack 安全边界分析：thenewstack.io/ai-agent-security-boundaries
• Made Yoga 三个月实测：madeyoga.github.io/blog/hermes-bot-mode
• 群聊打断 bug：github.com/NousResearch/hermes-agent/issues/92003