止观
Hermes实战

Hermes Bot Mode 深度解读：把 AI 助手变成一支"有名字、有头像的同事团队"

止观 2026-09-12 · 11 阅读

摘要（54 字内）：Bot Mode 不是新框架，是给 profile 加了一层“社会界面”——群聊、私聊、例行任务，全部可围观。

以前做“多智能体”，做的是水管：agent A 调 agent B，中间发生了什么，你得翻日志猜。Hermes v0.21.0（Pantheon 万神殿版）把这事反过来——先给每个智能体发工牌，再让它们开会。

这就是 Bot Mode。官方一句话定位：

A society of named agents with their own faces and group chats, where your bots talk to each other — and to you — like a team, not a toolbox.

一群有名字、有头像的智能体，在同一个群里互相说话、也跟你说——像一支团队，不像一个工具箱。

这篇把它的概念模型、桌面架构、群聊规则、bot 间消息协议、跨机路由、失败语义、资源成本一次讲透。所有细节以官方文档和源码为准，文末附来源。

※ ※ ※

一、先记住一句话：Bot 就是 profile，没有新东西

市面上大部分“多 agent 框架”会先塞给你一套新概念：Orchestrator、Swarm、Graph、Node……学完才知道原来底下还是那几个 LLM 调用。

Bot Mode 反着来。Hermes 官方文档里最硬核的一段是这个提示框：

There is no new primitive to learn: a Bot IS a Hermes profile.

一个 Bot = 一个 Hermes profile = ~/.hermes/profiles/<name>/ 目录下的一套完整隔离体：独立的配置、独立的记忆、独立的技能、独立的凭据、独立的聊天历史。Bot Mode 只是套在这个原语上的 UI 层——桌面端给它起名、画头像、排日程、拉群。

这带来一个很少见的性质：GUI 里做的每件事，终端里都有对等命令。

在 Bot Mode 里在 shell 里
和某个 Bot 聊天hermes -p <bot> chat
Bot 的文件/技能/记忆~/.hermes/profiles/<bot>/
Routines（例行任务）hermes cron list（任务名 [bot:<名字>] …）
创建/查看 Bothermes profile create / list

官方文档原话：“No core patches, no background daemons, no extra storage.” 不加核心补丁、不驻后台守护进程、不另开存储。关掉 Bot Mode 开关，roster 和面板实时卸载，你的 profile、会话、cron 一个字节都不动——它自己总结得很精辟：

Bot Mode never owns your data, it only renders it.

（Bot Mode 从不拥有你的数据，它只负责渲染。）

※ ※ ※

二、架构总览：三层，一台“可围观”的社会机器

Bot Mode 架构总览

拆开看图，三层各管一件事：

第一层：Desktop 桌面端（渲染与编排）

左侧边栏的 Bots 页签就是入口。它维护 roster（名单）、头像渲染、群聊房间 UI、Routines 面板、@ 自动补全。桌面端不是必须的——它是“观众兼快递员”（后面讲跨机时会看到这层的双重身份）。

第二层：Gateway 网关（每个机器一个）

真正跑 agent turn 的地方。每个 Bot 的会话调度、群房间的轮次驱动（driver）、消息投递回执，都发生在 owner 机器的网关里。Bot 的“户口”在哪台机器，它的计算就在哪台机器——桌面端只是连过去看。

第三层：Profile 目录（状态本体）

~/.hermes/profiles/<bot>/：SOUL.md（人格与常驻指令）、memory、skills、cron 任务、state.db（会话库）、canonical Bot Chat（每个 Bot 出生瞬间自动创建并置顶的“官方聊天室”）。

这个三层结构解释了 Bot Mode 大多数设计决策：状态归 profile，计算归 gateway，观感归 desktop。

※ ※ ※

三、名单与头像：确定性人格系统

3.1 头像不是装饰，是“身份锚点”

每个 Bot 一出生就有一张脸。默认是 blob face：从名字确定性推导的软体头像——同一个名字，永远是同一张脸，全宇宙任何一台 Hermes 上都不会变。打字时脸跟着名字实时变，可以 Randomize 重掷、Lock 锁定、还可以钉一个轮廓（round/organic/boxy/nub/cloud/sun 六种）。

另有几何脸（7 形状 × 10 颜色），带微动画：某个 Bot 正在为你干活时，它会抬头、冒三个省略点，turn 结束回到待机姿态——动画的所有权精确到连接，不同网关上的同名 Bot 不会蹭这个表情。

也支持上传图、AI 生成肖像、pixel pet（跑 hermes pets 看电子宠物画廊）。

3.2 “Active now” 的语义很严格

roster 的活跃过滤条件是：90 秒内写过消息，或最近有 worker 心跳，或当前正持有聚焦 turn 的 Bot。注意官方特意强调的一句：

A connected gateway alone does not mean a Bot is working.

网关连着 ≠ Bot 在干活。这个口径很值得学——很多 dashboard 的“在线”就是骗自己的。

3.3 Bot Chat 是“永不断代”的

每个 Bot 的 canonical Bot Chat 是终身制：你在里面按 /new 或 /reset，输入框会把它偷偷改写成 /compact——保留关系、压缩工作上下文，但绝不分叉。官方称之为 forever-chat：“Bot Mode 承诺唯一不会发生的事，就是这段关系被断开。”

设计意图很直白：Bot 的记忆和上下文全在这一条会话里累积，断代等于把雇了半年的员工记忆清空。普通会话不受此限制。

※ ※ ※

四、群聊：会议室是有议事规则的

2–6 个 Bot 可以开一个 Discord 式的房间，你也在里面。但群聊不是“所有人对所有人广播”——它有一整套防止失控的议事规则：

轮次制。 你发一条消息，最多触发 3 轮串行成员发言。被 @ 的 Bot 必须回应；没人被 @ 时全员可响应。

沉默是合法发言。 每个 Bot 自己判断要不要说话——“有新东西可补充就说，否则 pass”，一轮全员沉默，房间自动安静。官方文档特意为这个行为背书：

Speaking is each member's own choice.

硬上限。 单次触发最多 10 条消息、3 轮，防止 bot 之间互相@到地老天荒。

人类是最终裁判。 Bot 可以把真正需要判断力的问题用 @user 升级给你，房间会出现 needs you 徽章；待处理的命令审批也点亮同一个徽章。

每成员独立会话。 每个 Bot 在群里保持自己的持久 Group: <房间名> 会话，房间上下文像普通对话一样延续。

关窗不停会。 这是最“产品化”的一条：如果房间成员全在同一个网关上，轮次调度由该网关上的 durable driver 接管——你关掉桌面端、断网，讨论照常推进，重开窗口后从房间日志回放追赶。只有成员跨机器的房间才需要各跑各的。

房间状态（名册、最近记录、头像、名字）镜像进每个已连接网关的共享 profile metadata，带版本合并——换一台电脑登录同一个后端，房间和历史都在。重命名房间只是改名，解散房间则在所有客户端（包括当时离线的）永久移除。

※ ※ ※

五、Bot 之间怎么“私聊”：一个工具、两条路由、一套失败语义

5.1 message_agent：带署名的点对点投递

Bot 间消息流程

每个 Bot 的 canonical Bot Chat 里有一个专属工具 message_agent，用法朴素：

message_agent(
    target="researcher",
    message="把上周竞品价格变动的结论整理给我，重点标出促销价"
)

几个关键设计：

  • ▪ 目标校验：target 对着 live roster 验证，发错人直接报错，不会扔进虚空；
  • ▪ 自动署名：投递时自动加前缀 Message from 🤖 <sender> (@<sender>):，谁说的永远可查；
  • ▪ fire-and-forget：发送方拿到“已入队”回执就先结束自己的 turn，对方的回复稍后作为后台完成通知落进你的会话——不阻塞、不陪等；
  • ▪ 对方先认识人再选收件人：teammate 名单（每个 profile 的名字+职位+简介）直接编进每个 Bot Chat 的系统提示词，Bot 在决定“找谁”之前就知道谁管什么；
  • ▪ 只在正式场合存在：这个工具只注入 canonical Bot Chat——你的普通会话、群聊成员会话、CLI 会话都看不到它，防误用边界很干净。

改名的 Bot 标签自动同步：给 profile 起名 Research Buddy 后，@research-buddy、@researchbuddy 都能命中，旧名字继续兼容。

5.2 两条跨机路由：Desktop 快递 vs hermes peer 专线

跨机器的 Bot 互相投递有两条路，定位不同：

路线 A：Desktop Relay（桌面端当快递员）

你在 Settings → Connections 里注册的每个网关（本地、远程 URL、SSH、Hermes Cloud、docker），桌面端都保持一条长连接，顺便当通信枢纽：名单定期互相广播（每个 Bot 知道“其他机器上还有哪些同事”），message_agent 跨连接投递走桌面端的 socket。优点是零配置；约束是投递期间得有个“认识两台机器”的桌面端活着。

路线 B：hermes peer（网关直连，无桌面端参与）

# 在对端注册为 peer（需要对端开 api_server + API_SERVER_KEY）
hermes peer add spark --url http://spark.lan:8377 --key <API_SERVER_KEY>
hermes peer list

# 短消息：dm 阻塞等对方 turn 结束
hermes peer dm spark/researcher < /tmp/dm.txt

# 长任务：run 立即返回 run_id，幂等键防重复劳动
hermes peer run spark --idempotency-key ticket-123 < /tmp/long-task.txt
hermes peer status spark run_abc123
hermes peer stop   spark run_abc123

peer 注册后，每个 Bot 的系统提示词自动带上 peer 名单，message_agent(target=“spark/researcher”, ...) 直接可达——你的 bot 会自己发现“原来别的机器上还有同事”。凭据规范也很克制：key 走 ~/.hermes/.env 的 HERMES_PEER_<NAME>_KEY，名字和 URL 进 config.yaml 的 bot_peers。

一个诚实的网络提醒写进了官方文档：跨网关是直连，桌面端不做 NAT 穿透。家里 NAT 后面的机器可以主动打给公网 VPS，反方向不通。群房间如果跨 NAT 边界，把房间权威放在人人都够得着的公网主机上，或者上 Tailscale。

5.3 失败语义：类型化错误码 + 只重试“重试有用”的

投递失败返回机器可读的 reason 码，发送方的完成通知直接打标 [reason: provider_rate_limit]——bot 可以程序化分流（“这是限流，稍后重试” vs “这是没登录，得找人”），不用让模型去猜报错文案：

provider_auth_or_access · provider_quota_limit · provider_rate_limit
provider_server_error · context_overflow · missing_config
model_unavailable · runtime_offline · queued_expired
delivery_timeout · target_busy · unknown

重试策略克制：瞬时故障（对端离线、超时、限流）原会话重跑一次；上下文溢出重跑前先走标准压缩再试；鉴权/配额/配置错误永不自动重试——第二次也修不好，只会烧额度，立刻上报。文档里连“崩溃的 turn 不会被自动重放、死信工作保持可检视而不是悄悄重跑”这种细节都写明了。

※ ※ ※

六、Routines：任务挂在人名下

Routines 面板把定时任务归属到人——“每天早上总结收件箱”这件事，挂在负责它的 Bot 旁边，而不是躺在一个全局 cron 列表里。

技术上没有任何新调度器：Routines 就是普通的 Hermes cron job，只是名字空间化为 [bot:<名字>] <routine>，hermes cron list 里照样能看到。运行结果直接落进该 Bot 的 Bot Chat——结果就在你平时找这个 Bot 说话的地方，想追问当场追问。

结合 0.21.0 的 cron 记忆能力（定时 agent 现在会加载和更新持久记忆，monitor 任务没变化直接跳过 LLM 调用），“任务挂人名下”就有了真实含义：例行任务的产出会被那个 Bot 记住。

※ ※ ※

七、成本清单：养一支 bot 团队要花多少

  • ▪ 进程模型：每个本地 Bot 一个独立 backend 进程，桌面端最多同时保温 Warm Bot Backends = 3（默认），每个约 60 MB；闲置 10 分钟回收。日志里 Hermes backend for profile “x” exited (1) 紧跟 idle-reap 信息的话，是正常回收不是崩溃。
  • ▪ 全读占满槽位的场景：大群房间多成员、看板跨 profile 调度——把 Warm 数往“同时活跃的 Bot 数”上调，并配够内存。
  • ▪ 不算成本的开销：读别的 Bot 的历史、后台刷新 transcript 不占槽位，只有交互打开或真正跑 turn 才算。
  • ▪ 创建成本：New Agent 快速通道只要三个字段——名字、职位、简介——几秒出生，自我介绍作为 Bot Chat 的第一条消息。Advanced 里可以克隆既有 profile、钉独立模型（不同 Bot 跑不同模型完全合法）、自定义 SOUL.md、逐技能/工具集/MCP 授权，默认与主 profile 共享 OAuth 凭据池（避免刷新互相踢下线）。

※ ※ ※

八、设计评析：为什么这层“皮”值得认真做

回看整份文档，Bot Mode 的工程品味藏在四个反直觉决定里：

1. 拒绝新原语。 不发明 “Bot” 这个存储层概念，UI 名词直接映射回 profile。代价是功能清单看起来“平淡”，收益是：学习成本塌缩为零、CLI 全部对等、卸载干净、数据主权在用户。

2. 把“谁在说话”做成一等公民。 确定性头像、自动署名、@ 标签同步、needs-you 徽章、设备角标（dixie · Mac Mini）——协作系统里最贵的不是算力，是归因。能一眼说出“这句是谁、在哪台机器、什么时候说的”，多 agent 才从玄学变成可运维的资产。

3. 防失控写进协议而不是靠自觉。 3 轮 10 条硬上限、沉默合法、@user 升级通道——官方显然被“两个 bot 互相@到烧光 API 额度”这类事故教育过，规则先行。

4. 失败是产品的一部分。 类型化 reason 码、可重试/不可重试的清晰边界、死信可检视不悄悄重跑——这些没一个会出现在 demo 里，但生产环境里每一个都是保命的。

AI 助手的竞争正在从“谁更聪明”转向“谁更像一支能交付的团队”。模型能力抹平之后，剩下的活儿就是编排的可见性、记忆的持久性、失败的可解释性。Bot Mode 是这三件事目前最完整的一份开源答卷。

※ ※ ※

九、快速上手

有桌面端（最顺路径）：升级 Hermes → 打开 Bots 页签 → New Agent 三字段建 bot → 右键拉群 → Routines 挂任务。全程无需配置。

纯 CLI 用户：

hermes profile create researcher   # 建一个"bot"
hermes -p researcher chat          # 进它的正式会话（Bot Chat 等价物）
hermes peer add vps --url http://your-vps:8377 --key <KEY>
hermes peer dm vps/researcher < task.txt   # 跨机协作

升级命令：

# 已有安装
hermes update

# 全新安装
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

建议版本 v0.21.2（state.db 专项修复版），Bot Mode 及其全部周边功能均已包含。

※ ※ ※

你觉得“给 agent 发工牌”是花架子，还是多智能体落地的必经一步？评论区聊聊。

点个在看，转发给那个还在用日志拼多 agent 调用链的同事。

下一篇预告：hermes peer 跨机协作实战——我准备让家里的 Mac 和云上的 VPS 各跑一个 bot，让它们自己组个群。

※ ※ ※

资料来源

  • ▪ Hermes Agent 官方文档 user-guide/bot-mode.md（本机仓库 main 分支，v0.21.2 时期）
  • ▪ GitHub Release Notes：Hermes Agent v0.21.0 (v2026.8.31) “The Pantheon Release”
  • ▪ NousResearch/hermes-agent · https://github.com/NousResearch/hermes-agent
  • ▪ 生成日期：2026-09-12

评论 (0)