title: “Bot Mode” description: “Turn your Hermes profiles into a roster of named Bots — each with its own chat, role, model, memory, skills, and avatar. Bots run routines, share group chats, and message each other.”

机器人模式

机器人模式可将您的 Hermes 配置文件 转换为一系列具有名称的 机器人。每个机器人都拥有独立的角色、模型、记忆体、技能以及头像；它们能够执行周期性任务，在群组聊天中协同讨论，还能直接互相发送消息。只需创建一次专业机器人，它就会永久存在，随时可通过点击调用。

机器人模式已内置在 桌面应用 中，且默认处于开启状态——无需额外安装。在左侧侧边栏的“会话”选项旁会出现“机器人”标签页；当该标签页处于激活状态时，对话框旁边还会显示“任务”面板。

::提示 机器人即配置文件 无需学习新的基础概念：机器人本身就是Hermes 配置文件——所有的配置、记忆体、技能、凭证以及聊天记录都存储在 ~/.hermes/profiles/<名称>/ 目录下。机器人模式只是为这一基础概念提供的用户界面，因此您在其中的所有操作都可在 CLI 中看到：使用 hermes -p <机器人名> chat 即可打开同一个智能体，而机器人的周期性任务也会显示在 hermes cron list 中。无需进行任何核心代码修改，无需后台守护进程，也不会占用额外存储空间。

::

机器人面板

该列表会为每个智能体配置文件显示一行信息：头像、最新消息预览以及时间戳。

• 点击某个机器人即可进入其聊天界面——每个机器人都拥有一个标准且永久的机器人聊天对话，该对话会在机器人创建的同时立即生成并被固定显示。无论您同时为该机器人打开了多少个标签页，点击任意一行都会打开该机器人聊天界面（即该行预览的正是该对话），而这些其他标签页会继续在旁边保持打开状态。在标签栏中，机器人聊天界面会标注机器人的名称，这样就能一目了然地区分多个正在使用的机器人。
• 当前活跃——列表中的活跃度筛选功能会显示当前正在处理的对话的发起者、90秒内有过消息发送的机器人，以及最近有工作进程响应的机器人。仅有连接到的网关并不代表该机器人正在运行。
• 搜索功能可在您输入内容时实时过滤列表。
• 隐藏机器人——右键点击某一行，然后选择隐藏机器人，即可将不常用的机器人从列表及“当前活跃”栏中移除。隐藏仅影响显示：@提及仍能正常触发响应，群聊成员资格不受影响，常规任务也会继续执行。一旦隐藏了至少一个机器人，面板标题栏会出现一个眼睛图标——点击该图标即可看到以暗色显示的被隐藏机器人，随后右键点击并选择取消隐藏机器人即可将其恢复。被隐藏的机器人不会显示通知，但其未读消息会持续累积，同时眼睛图标上会出现一个小点，让您知晓有相关活动发生。隐藏状态会被保存在机器人的个人资料元数据中，因此无论连接到同一后端的哪个桌面端，都能看到该状态。 :::note 标准的机器人聊天窗口属于永久性聊天模式。在标准聊天窗口中输入 /new（或 /reset）会将对话关系分离到一个临时会话中——而这正是机器人模式所承诺绝不会发生的情况。为此，该工具会自动将指令重定向到 /compact：保留全新的工作上下文，同时延续原有对话。而使用同一账户的普通会话则仍可完全自由地使用 /new 命令。 :::

按类别整理机器人

“类别”是由您自行创建的文件夹——可以是 客户、团队 或其他适合的名称——作为除按网关自动分类之外的第二维度。若未创建任何类别，列表将保持原有的简单形式。

• 可通过面板中的 + 菜单选择 新建类别，或右键点击某个机器人后选择 移至类别 → 新建类别…（这样在创建新类别的同时即可将该机器人归入其中）。
• 也可通过将机器人对应的行拖拽到目标类别上来将其归类——悬停时目标类别会高亮显示，按 Esc 键可取消拖拽操作；或者右键点击后选择 移至类别 并挑选目标。选择 从类别中移除 则会将机器人重新放回 未分配 状态。
• 可通过类别标题的右键菜单（或悬停时出现的 ⋯ 图标）来 重命名、重新排序或删除 类别；双击标题即可进行重命名。类别标题同样支持像网关标题那样的折叠功能。
• 删除类别不会删除其中的机器人——它们只会回到 未分配 状态，且系统会弹出 撤销 选项，无需额外确认。 会员信息存储在每个机器人的配置文件元数据（ui_meta）中，因此该机器人的相关内容会跟随其出现在连接到同一后端的所有终端上。当列表显示多个网关时，各部分内容会嵌套在各个网关对应的分类中。

创建机器人

在列表中点击新建机器人。快速创建只需填写三个字段——名称、标题和描述，几秒钟后机器人即可生成，并会在其新的聊天窗口中通过首条消息自我介绍。

选择高级选项则可查看全部功能设置：

• 从现有配置文件克隆——基于其他机器人的配置、技能、SOUL数据及内存进行创建，或选择全新配置文件以获得干净的空起点。
• 创建空配置——完全不使用预置的技能，打造极简配置的机器人。
• 模型与提供方指定——为机器人指定专属模型。任何Hermes支持的提供方/模型组合均可使用，不同的机器人可以并行运行不同的模型。若不进行设置，则会继承初始配置文件中的设置。
• 自定义SOUL.md文件——用于设定机器人的角色定位及行为准则。
• 按技能、工具集及MCP服务器启用特定功能——仅勾选该机器人所需的功能项。
• 共享密钥——默认情况下，新创建的机器人会与主配置文件共享同一个OAuth/令牌池，因此凭证刷新不会相互影响。（旧版网关则会复制凭证——虽然仍能正常使用，但属于分离式管理。）

选择机器人运行的设备（“在以下设备上创建”）

在设置 → 连接中注册了多个连接后，“新建智能体”对话框会出现一个创建位置选择器。选定某台设备后，智能体即会在该设备的后端创建——此时您的窗口无需切换网关。新创建的智能体将会以“连接型智能体”的形式显示在列表中（如果其名称在多台设备上均存在，则会带有@name-device标识），与它进行聊天时消息会直接发送到它所在的设备。

若仅有一个连接（即常见情况），则该选择器会被隐藏，智能体仍会在当前连接的设备上创建——这与旧版本的行为完全一致。

关于远程创建的注意事项：

• 克隆源指的是目标设备的配置文件（即其default配置）——远程设备无法获取您的本地配置文件用于克隆。
• 实时显示的“能力”标签页会绑定到目标设备的后端，因此您在创建过程中配置的技能、工具及MCP服务器都会存储在智能体实际运行的设备上。（旧版本的桌面应用在处理远程目标时会回退到分阶段的技能/工具/MCP清单；这两种方式都会读取目标设备的配置目录。）
• 若取消该对话框，当前正在编辑的配置草稿将会丢失，无论它是在哪台设备上创建的。

通过编辑配置文件（右键点击智能体）即可随时打开该智能体的实时配置界面，可修改头像、标题、描述、模型标识、技能、工具集、MCP服务器以及完整的SOUL.md文件。

右键点击复制功能可创建机器人的完整副本——包括配置、技能、SOUL.md文件、内存数据以及外观样式。删除档案则会永久移除该机器人，其操作流程与桌面端档案菜单的确认机制相同；默认档案则无法被删除。

头像

每个机器人都会拥有一个头像：

• 数据块面部（默认选项）——根据机器人名称自动生成的确定性软体面部：名称不变，面部形象始终如一。在“新建机器人”时输入名称，面部形象会实时更新；点击随机化可重新生成，锁定面部则可在名称更改后仍保留当前喜欢的形象；也可从六种轮廓（圆形、有机形、方块形、小突起形、云形、太阳形）中选定一种作为固定样式，其余部分仍由名称决定。
• 几何图形面部——经典的7种形状搭配10种颜色。在机器人进行实时对话时，它会微微前倾并抬头，伴随三个动态点显示，对话结束后则恢复到闲置状态。由于头像所有权与连接关系绑定，因此不同网关上的同名机器人不会共享同一姿势。后台进程会保持其原有的动画效果；照片、数据块面部和符号则各自独立渲染。
• 上传的图片——您喜欢的任何图片均可使用。
• AI生成的肖像——当配置了图像后端时，可就地生成肖像（该功能基于标准的image.generate RPC接口，可在本地及远程网关上使用）。
• 像素宠物——来自petdex图库的陪伴角色，会在机器人忙碌时在头像旁跳动。可在终端中运行hermes pets命令来浏览该图库。 机器人的外观、标题及描述均存储在后端配置文件的元数据中，因此连接到同一后端的所有桌面端上，该机器人的显示效果都保持一致。

定时任务

定时任务面板会将重复性任务关联到执行这些任务的机器人——例如“每天早上总结我的收件箱内容”这类任务，就会显示在负责处理的机器人旁边。该面板仅在“机器人”标签页处于激活状态时显示在聊天界面旁，而当您切换回“会话”视图时则会隐藏（旧版本的桌面端则始终显示该面板）。系统提供一个结构化的日程选择器，让您先设定执行频率，再补充必要细节；同时还有一个“高级”字段，可查看原始的Hermes日程字符串。

定时任务实际上就是带有命名空间的普通Hermes定时作业，格式为[bot:<名称>] <任务名>——它们也会显示在hermes cron list列表以及Cron功能的主页面上。执行结果会记录在机器人自身的聊天历史中，因此您可以直接在该处查看执行结果。

群组与群聊

右键点击本地机器人 → 选择管理群组，即可将其添加到或从任意数量的群聊中移除。您可以单独选择现有群组，也可以直接创建新群组。机器人的本地成员身份信息存储在其后端同步的配置文件元数据中，因此会随该配置文件在不同桌面端之间同步；那些仅包含一个旧版群组的旧配置文件依然可以正常使用。通过“新建群聊”选择器加入的连接型机器人，其来源信息也会保留在群聊的共享状态中。

房间是跟随网关而非单个桌面端的。 每个房间的最新对话记录、成员列表、图片以及名称都会同步到该桌面端所连接的所有网关的共享配置元数据中，并且每个网关都有独立的版本控制机制，因此当多个桌面端同时写入数据时，它们会合并而非互相覆盖。在另一台设备上使用同一网关（无论是局域网、Tailscale还是其他连接方式）打开Hermes Desktop，该房间及其历史记录都会显示出来；仅支持网关连接的客户端同样可以查看这些内容。房间拥有稳定的内部标识，因此只需重命名即可更改其在各处的显示名称；解散房间则会在所有客户端上永久移除该房间——即便那些客户端当时处于离线状态也不例外；而重新创建同名群组则会生成一个全新的房间。即便某个网关出现故障或被移除，数据也不会丢失：所有已连接的桌面端都会本地保留完整的房间数据，并在重新连接到相应网关时自动同步最新内容。（完整的操作日志保存在每个桌面端的本地存储中；而共享的镜像仅包含有限时期的近期记录。）

群组在按活动顺序排列的列表中与机器人私信处于同一行。即使一个机器人属于多个群组，它仍只保留一条私信记录；而每个群组都会拥有属于自己的独立行，其中显示成员数量、最新消息预览、时间戳以及是否需要用户响应的状态。

可以使用房间旁边的“上移”和“下移”箭头来调整房间的排列顺序。在首次移动之前，系统会保持原有的“固定优先”与“最近活动”排序规则不变。一旦完成移动，房间的顺序就会保存在该桌面端，并且在重新加载后依然有效；新添加的房间会按照既定顺序出现在其对应的固定或非固定区域中。房间移动无法跨越固定区域的边界，而筛选功能也不会从已保存的顺序中移除被隐藏的房间。这些控件用于调整实际的群聊房间顺序，而不影响用户创建的机器人文件夹，同时也不会改变成员构成或网关归属权。

在任何包含2至6个机器人的群组行上点击“打开聊天”，即可进入一个供整个群组协作的共享房间：

• 仅显示一条对话内容。公开消息及每位成员的回复会按发送顺序显示，同时标注发言者姓名和时间戳。开启新话题不会合并之前的回复。“在当前话题下回复”功能可在不改变房间顺序的情况下继续讨论该主题；“活动状态”仅作为辅助视图，并不能替代普通消息。私人机器人聊天则依然保持独立。

• 您发送的消息会触发最多三轮连续的成员回复轮次。被@提及的机器人也会作出回应（若未提及任何人，则所有机器人都会回复）；每个机器人会简短回复或选择不回复，当一轮对话结束后仍未有新回复时，该轮对话即告结束。

• 机器人可通过 @name 互相发起对话，而遇到需要人工判断的情况则可通过 @user 将问题转交给你——此时群组行会显示“需要你处理”标识。待处理的疑问及命令审批也会触发该标识；仅解决当前提示语即可解除对该提示的关注，但不会移除相关的提及。提示语会跟随房间名称的变化而同步，而当房间解散时，即便有成员的正在进行的投票随后到达，这些提示语也会被清除。

• 通过设置上限（每次发送最多10条消息、共3轮对话），可防止房间陷入无休止的讨论。

• 每位成员都会保留自己独立的 Group: <name> 会话，因此房间上下文能像其他普通对话一样得以保留。

• 并非每个机器人都会回复每条消息。 发言与否由每位成员自行决定——只有当机器人有新内容要补充时才会回复，否则保持沉默；通过 @提及特定成员，则可将对话范围限定在该成员身上。通常只有被提及的成员（或有话要说的人）会发言，其余成员则保持安静。

• 关闭桌面端后，房间仍可继续运行。 只要房间内的所有成员都连接在同一个网关上，该网关就会通过稳定的驱动程序来管理对话轮次：关闭 Hermes 桌面端（或失去网络连接）不会中断正在进行的讨论，桌面端在重新连接后会从房间的日志中继续接续对话。符合此情况的网关在 groups.capabilities 中会显示 driver: true。而那些成员分布在多台设备上的房间则有所不同：每位成员的对话都在各自的网关上运行，此时仍适用“机器人间消息传递”部分所描述的跨连接机制。

• **聊天室可跨越多台机器。**新的群聊选择器允许从任何已注册的连接中选取机器人；每位成员的对话都在其专属的机器上、独立的Group: <name>会话中进行。跨机器参与的成员会在聊天室及其他成员的对话记录中显示对应的设备标识（如dixie · Mac Mini），同时经过识别的@name-device引用格式也可在聊天室提及中使用——这样一来，两台不同机器上同名机器人就不会混淆。

机器人之间的消息交互

机器人之间可以互相发送带归属信息的消息，且您可以从任何聊天窗口发起任务分配：

• @提及——在任意聊天窗口中输入@researcher have a look at this，系统会通过自动补全功能帮您选择合适的机器人；消息发送后，系统会根据实时列表确定被提及的对象，并明确告知该机器人您指的是谁（包括个人资料、友好名称以及跨连接机器上的机器人对应设备信息）。随后该机器人会自行撰写消息并通过message_agent函数发送出去——您的原文不会被原封不动地转发，回复也会标注对应的机器人身份。电子邮件地址或未知的@引用则会被原样传递。其他连接机器上的机器人也可以通过相同方式被联系：桌面端会通过该连接专用的套接字来传输消息（详见下文的“跨机器机器人”部分）。
• 重命名后的机器人仍保留原有标签 — 为机器人起一个友好的名称（即聊天界面顶部的铅笔图标，或通过 hermes profile rename 命令设置），该名称即可用于给机器人添加标签：例如将机器人命名为 Research Buddy，则无论是在普通聊天还是群组聊天中，使用 @research-buddy（或 @researchbuddy）均能触发该机器人的响应。消息编辑器中的 @ 自动补全功能会显示重命名后的标签，同时也会匹配旧名称，从而确保能够正常发送消息。
• 私信功能 — 每个机器人聊天窗口都内置了 message_agent 工具：开发者可通过调用 message_agent(target="researcher", message="…") 的方式向团队成员发送消息。该工具会依据实时名单验证目标用户身份，自动在消息开头添加“消息来自 🤖 <发送者> (@<发送者>)”的标识，并将消息投递至目标用户的官方机器人聊天窗口。这种发送方式为“即发即忘”：发送者收到确认后即可继续操作，回复则会在稍后以后台完成通知的形式送达。消息会以原始参数形式传输（不会经过Shell解析——引号、$(...) 和反引号等内容都会原样保留），且机器人会自行撰写消息内容，而非直接转发用户的原文。每个机器人聊天窗口的系统提示中都包含了团队成员名单以及每个用户资料标题/描述中的姓名和角色信息，因此机器人在选择接收对象之前就能知晓各自的职责。该工具仅存在于通过机器人模式管理的安装环境中的官方机器人聊天会话中；普通聊天、群组成员会话以及CLI会话中则不存在此功能。 本地消息也会发送到在桌面端或 TUI 中保持开启状态的机器人聊天窗口。接收方后端会负责消息处理：它会通过现有的通知轮询机制读取持久性消息，在空闲时立即处理，或等待当前轮次中已排队的人类输入处理完毕。queued 状态仅表示消息已被持久性接收，并不代表回复已完成。目标配置文件会将消息的传递 ID 和接收记录保存在 runtime/bot_live_delivery/ 目录下；只有 settled 状态才能表明处理已完成。若某个轮次因故障或被取消而中断，系统不会自动重新执行该轮次；同时，那些被分配给已离线负责人的待处理任务仍可查看，而不会被默默地重新运行。对于处理结果未知的消息，请勿再次发送。那些不具备实时消息传递功能的旧版后端会继续维持原有的拒绝处理机制，升级后需重新启动该后端。

在构建提示语时，后端会自动为每个机器人的标准机器人聊天会话配置消息协议——即便是有同事通过 CLI 以无界面模式打开该聊天窗口也是如此。只有标准机器人聊天会话会包含该协议配置；普通的对话会话以及 SOUL.md 文件则不会受到影响。此功能可通过 config.yaml 文件中的 agent.bot_mode_protocol 参数进行控制（默认值为开启状态）：

agent:
  bot_mode_protocol: true   # inject the bot-to-bot messaging protocol into canonical Bot Chats

:::note
机器人之间的消息传递为每次调用独立处理：接收方机器人在下次运行时会获取该消息。在对话进行中中断机器人当前操作的功能属于未来计划。

::

失败轮次会安全重试

本地一次性传递机制会将当前会话的拒绝代码与易于理解的消息分开保存。当出现 SESSION_NOT_OWNED 错误时，系统会返回 target_busy 状态；若协调注册表无法读取，也不会被错误地标记为其他所有者。那些不支持该代码标识的旧版本地 CLI 仍会使用传统的拒绝信息表述。

对于失败的传递轮次，最多只会重试一次，且仅在重试确实能解决问题时才会进行。对于临时性故障（如目标端运行时离线、传递超时、提供商速率限制或服务器错误），系统会直接重新启动相同的机器人对话会话。若因上下文溢出导致失败，系统同样会重新启动该会话——在调用模型之前，重试的轮次会先通过标准的上下文压缩机制对过长的对话记录进行压缩，从而让重试内容能够纳入原有上下文范围。而身份验证、配额及配置错误则绝不会自动重试：再次尝试无法解决这些问题，还只会消耗配额，因此错误会立即显示出来。此外，重试的轮次绝不会启动新的会话——您的机器人对话历史和上下文都将保持不变。

传递失败时：显示的文字说明

无论是机器人对话环节失败还是消息中转传输失败，系统都会在错误提示文本之外附带一条机器可读的 reason 代码。目标网关会首先对故障类型进行分类（如 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 等），随后由桌面端将相关信息转发，而发送方的完成通知也会在错误文本前标注 [reason: <code>]。这样，调用方无需解析供应商提供的冗长说明，只需根据代码来判断应采取“重新登录”还是“稍后重试”的操作。桌面端的需要关注标识也会使用相同的代码。

连接设备间的消息传递（桌面端中转功能）

在 设置 → 连接 中注册的每一个网关——无论是本地连接、远程 URL、SSH、Hermes Cloud 还是 Docker——都会被桌面端保持为持续开放的连接通道，机器人模式会自动利用这些通道进行消息传递。无需任何额外配置即可实现。

• 代理列表会自动同步。 只要桌面端处于运行状态，它就会定期向每个已连接的网关通报其他连接上存在的代理信息。随后，每个机器人聊天的队友列表中就会显示这些代理（标记为“其他连接上的队友”），并列出其名称、角色以及所在机器——当代理出现、消失或重命名时，列表也会随之更新（即能力周期更新）。
• message_agent 可直接发送消息。 你笔记本上的机器人可以通过 message_agent(target="moxie", …) 向云端代理发送消息，操作方式与发送给本地队友完全相同。如果多个机器上存在相同的标识符，则需使用 target="moxie@<connection>" 来区分（工具会给出正确的格式提示）。消息的传输依赖于桌面端：发送方网关负责将消息排队，桌面端再将其转发至目标连接对应的网关，目标机器人则在其标准的聊天界面中处理消息，最终回复会以与本地私信相同的后台完成通知形式返回给发送方。
• 桌面端充当消息传递者。 只要有同时知晓两种连接的桌面端在运行，跨连接的消息传输就能正常进行（桌面端负责管理套接字和认证信息——各网关之间无法看到彼此的认证信息）。如果在消息传输过程中桌面端被关闭，发送方的机器人会收到回复未送达的通知，而不会处于等待状态。对于无需桌面端参与、需要持续运行的机器间通信，可注册对等节点（见下文“hermes peer”）——两种传输路径可以共存。

机器人发起的跨机器私信（hermes peer）

同一台机器上的机器人无需通过任何桌面端即可与另一台机器网关上的机器人进行消息交互。只需将另一台网关注册为对等节点（即其API服务器地址加上API_SERVER_KEY）即可：

hermes peer add spark --url http://spark.lan:8377 --key <API_SERVER_KEY>
hermes peer list
hermes peer dm spark < /tmp/dm.txt        # message body from a file (nothing shell-interpreted)
hermes peer dm spark/researcher < /tmp/dm.txt   # named profile on a multiplexed peer
hermes peer run spark --idempotency-key ticket-123 < /tmp/long-task.txt
hermes peer status spark run_abc123
hermes peer stop spark run_abc123

hermes peer dm 命令会通过对端现有的 API 服务器将消息发送至远程智能体的标准 Bot Chat 环境，在那里执行一次智能体响应流程，随后将回复输出到标准输出流——其功能与本地的 hermes -p <bot> chat 命令完全对应，实现了跨机器的同步操作。

由于该命令会保持一个 HTTP 连接直至整个响应流程结束，因此仅适用于发送简短查询或接收回复的场景。对于耗时较长的响应流程，peer run 会立即返回一个 run_id，可通过 peer status 命令持续查询其状态。此类运行过程会继承标准的 Bot Chat 对话记录，同时通过稳定的 --idempotency-key 确保重试时能够恢复到之前的处理结果，而不会重复执行任务。若需中断某个运行流程，可直接使用该 run_id 调用 peer stop 命令，而无需针对特定的响应轮次操作。

一旦某个对端被注册，所有 Bot Chat 实例都会自动继承所教授的消息协议（即 agent.bot_mode_protocol），该协议会包含对端列表，因此 message_agent 函数可直接指定对端目标——例如使用 message_agent(target="spark/researcher", …) 指定特定智能体，或使用 target="spark" 指定对端的主智能体——这样一来，智能体便能自行了解其他机器上存在哪些同事以及如何与他们通信。注册或移除对端后，每个 Bot Chat 实例在处理下一条消息时都会自动刷新相关协议配置。

前提条件：对端机器需运行带有强加密密钥 API_SERVER_KEY 的 api_server 网关平台；网络连通性由您的网络环境负责保障（如局域网、Tailscale 或 VPN 等）。该密钥属于敏感凭证，存储在 ~/.hermes/.env 文件中的 HERMES_PEER_<NAME>_KEY 键值中；而对端名称/URL 则存储在 config.yaml 文件的 bot_peers 配置项下。

::注意 单向可达性（NAT） 跨网关连接为直接的网关对网关连接——桌面端仅作为查看器，而非中继节点。位于家庭NAT后的网关可以拨出连接到公共对等设备（例如笔记本电脑连接到VPS是可行的），但除非网络环境提供了相应路径，否则反向连接将无法建立（例如VPS无法连接到家庭网络）。如果您的群组聊天跨越了NAT边界，请将房间权限设置在所有参与者都能访问的节点上（通常是公共VPS），或者通过Tailscale/VPN来搭建网络桥梁。

::

转移房间权限

权限接管属于运营方恢复流程，而非原子级的权限移交操作。需在相应的网关上使用现有的JSON-RPC方法groups.promote和groups.demote来实现。系统中不存在groups.peer.promote或groups.peer.demote这类方法；groups.capabilities可列出当前网关所支持的方法。

::警告 在提升权限前锁定旧权限持有者 在发送confirm: true之前，必须确认之前的权限持有者已无法执行任何操作，并且要持续保持该锁定状态，直至其权限被降级。需停止该节点的房间编辑进程，防止其自动重启，或使用类似的基础设施锁定机制。网络超时、断开桌面端连接或调用groups.stop方法均不能作为有效证明：旧网关仍可能处于运行状态，而且暂停某次操作并不会立即撤销其房间权限。如果无法实现有效锁定，请勿尝试提升权限。

1. **检查副本覆盖情况。**在替代网关上，查看groups.replica_state中包含{"room_id":"ROOM_ID"}的字段，并对比last_seq与latest_seq的值。在计划接管之前，必须确保已有完整的副本；而升级操作本身并不检测这种覆盖情况。groups.replicate在处理完groups.log返回的页面后会报告caught_up状态；但仅凭节点注册并不能证明替代节点已拥有该房间的历史记录。Caught_up状态仅表示最后已复制的页面，并不能证明旧写入节点已停止工作或不存在更新的事件。对于计划内的迁移，需先让写入节点进入静止状态，通过最终游标完成数据复制，然后再维持数据隔离机制。而在灾难恢复场景中，则需要考虑那些从未传递到副本端的日志历史。

2. **仅在旧写入节点被隔离时才进行升级。**在替代节点上：

   {"jsonrpc":"2.0","id":1,"method":"groups.promote","params":{"room_id":"ROOM_ID","confirm":true,"reason":"planned-handover"}}
   

必须提供room_id和confirm: true参数；reason为可选参数，其默认值为authority-unreachable。进行确认即表示您认为之前的授权节点无法执行操作，并非自动封锁该节点的请求。若未进行确认，调用将返回4118错误码。成功时，系统会返回authority_gateway_id和authority_epoch（复制后的时间戳加一）。 3. 在将旧授权节点重新投入服务之前，先将其降级。 通过旧网关上的受控恢复连接来执行此RPC操作时，需保持该节点的正常房间写入功能处于封锁状态。请用升级成功后返回的实际值替换示例中的网关ID和时间戳。

{"jsonrpc":"2.0","id":2,"method":"groups.demote","params":{"room_id":"ROOM_ID","observed_gateway_id":"NEW_GATEWAY_ID","observed_epoch":2}}

这三个参数都是必需的。切勿随意猜测未来的时间戳：降级操作需要的是更新权威节点的证据，而非凭空编造的值。系统会记录authority.lost状态，并采用实际观测到的数据链路；重复执行相同操作也不会产生任何影响。如果旧主机暂时无法使用，请将其隔离，先完成此步骤，然后再恢复其正常的写入功能。

4. 验证并重新连接。 读取两个网关上的groups.state信息，将room.authority_gateway_id和room.authority_epoch与升级后的结果进行比对。必须拒绝来自旧权威节点的请求，将客户端引导至新的权威节点。降级操作仅会隔离写入操作，不会合并历史数据，也不会自动将旧的权威存储转换为同步副本。

如果在旧网关仍可写入的情况下进行升级，两个独立的state.db存储就会继续接收消息，从而导致数据历史出现分歧。即使新节点的时间戳更高，也无法远程禁用旧节点的写入功能；出现“脑裂”现象并不一定要求两个节点的时间戳必须相同。如果数据历史已经出现分歧，应先隔离写入操作，并保留两份历史记录以便后续恢复，而非指望通过升级、降级或重放操作来合并这些数据。

跨机器的机器人

在设置 → 连接中注册多个后端——包括本地运行时、远程网关、SSH主机以及Hermes Cloud实例——系统会持续显示来自所有已连接源的机器人信息。对于SSH源，系统会在不向远程设备发送任何指令的情况下完成清单记录；而暂时无法访问的机器也会保留其最后记录的条目，而不会消失。如果多个源使用相同的配置文件名，系统会通过@name-device的形式来区分它们（例如@research-homelab）。机器人的聊天记录、会话信息、内存数据以及程序均存储在拥有该配置文件的机器上。

点击某个连接型机器人并不会将您的窗口切换到该机器上——您仍可留在当前聊天界面中，通过@mention方式与其交互、将其加入群组聊天，或直接使用创建于选项在其上新建机器人。通过这种方式，云端机器人与本地机器人可共享同一份清单：只需注册您的Hermes Cloud实例和桌面设备（可通过Tailscale或SSH实现连接），它们的机器人便能互相发送消息并处于同一聊天室中，同时每个机器人的工作都在其自身的设备上独立运行。这些机器之间的机器人私信会自动通过桌面设备中转（详见上文跨连接设备发送消息部分）。

如需完整的多连接使用指南，请参阅将桌面设备连接到多个Hermes实例。

关闭此功能

Bot模式是一种内置的桌面插件。您可以在设置 → 插件 → 机器人中将其关闭——这样一来，机器人列表、常规任务面板以及内容生成中间件会立即解除注册，且无需重启。无论是否启用该模式，您的个人资料、会话及定时任务都不会受到影响；Bot模式从不拥有您的数据，仅负责对其进行呈现。

此外，还提供一项偏好设置，可将标准的机器人聊天记录隐藏在常规侧边栏的会话列表之外，使其仅显示在“机器人”面板中。（此功能利用了核心的隐藏会话标志；在较旧的网关上，这些聊天记录仍将保持可见状态。）

CLI一致性

由于机器人属于个人资料的一种，因此所有操作在终端中都有对应的命令：

有关底层实现细节，请参阅个人资料；完整的CLI参考信息则可在个人资料命令中找到。