Hermes Bot Mode 实战：把一个 Agent 变成可复用的专业 Bot 团队
适合谁： 想让 Hermes 长期承担研究、写作、编码、复核等重复工作的个人开发者和小团队。本文把 X 上 Hermes 社区近期讨论度较高的 Bot Mode，整理成一套可以落地的工作方法。
先说结论：Bot Mode 解决的不是“多开几个聊天窗口”
从官方和维护者在 X 上的介绍看，Bot Mode 的核心变化是：一个 Agent Profile 可以成为一个有名字的 Bot，并拥有相对独立的角色、模型、记忆、Skills、Tools 和外部连接。Bot 之间还可以互相通信。
这意味着工作方式可以从：
每次临时告诉同一个 Agent：你现在扮演研究员，然后再扮演审稿人
升级为：
Research Bot 负责找资料
Builder Bot 负责产出初稿
Reviewer Bot 负责检查事实、链接和格式
重点不是 Bot 越多越好，而是职责稳定、输入输出明确、结果可验收。
X 上哪些信号值得关注？
本文不是把单条帖子当成产品文档，而是把多条公开讨论交叉整理成可操作结论：
- 官方介绍 Bot Mode：每个 Profile 可以变成命名 Bot，拥有独立角色、模型、记忆和 Skills，并可与其他 Bot 通信。来源：@NousResearch。
- 维护者补充边界：Bot Mode 是 sessions 模式之外的工作方式；Bot 可以有自己的工作、描述、头像、记忆、技能、工具和外部连接。来源：@Teknium。
- 社区展示群聊协作：有用户展示了 6 个 Bot 在同一组对话中协作。它说明“多 Bot 协作”是社区正在尝试的用法，但不等于所有版本都已经稳定支持。来源：@BkashJosi。
- 社区给出具体案例：先创建 HR Bot，再让它根据赛车游戏项目生成其他部门 Bot；这个案例更适合作为“Bot 工厂”理念的启发，而不是开箱即用的标准流程。来源：@witcheer。
- 远程 Gateway 讨论：Desktop 可以连接多个 Gateway，并选择 Bot 的归属机器；远程连接要区分
hermes serveDashboard 后端和 OpenAI 兼容的api_server。来源：@Teknium、@Teknium。
重要说明： X 帖子是产品动态和社区经验，不是本站对你当前版本的实测证明。界面名称、连接方式和可用功能应以你安装的 Hermes 版本和官方文档为准。
推荐的最小团队：3 个 Bot 就够了
1. Research Bot：只负责证据
职责： 搜索官方文档、仓库、Issue、公告和原始帖子，输出来源表，不直接写最终文章。
输入： 主题、时间范围、必须覆盖的官方来源。
输出格式：
结论：一句话
证据：原始链接 + 发布者 + 日期
可信度：官方 / 维护者 / 社区 / 待核验
限制：哪些信息不能从该来源推出
2. Builder Bot：负责组织交付物
职责： 根据已确认的证据写文章、代码或运营素材，不自行补齐缺失事实。
输入： Research Bot 的证据表、文章结构、读者画像、字数和格式要求。
输出： 初稿、引用链接、待核验清单。
3. Reviewer Bot：负责挑错
职责： 检查断言是否有来源、链接是否可访问、代码是否把占位符误当成真实凭据、标题是否与正文一致。
验收规则：
- 每个版本号、数字和产品能力都有来源；
- X 帖子中的“据称”“社区展示”没有被改写成“官方保证”；
- 没有 API Key、Cookie、Token 或登录状态文件；
- 文章至少有一个读者可以执行的步骤；
- 所有外链都指向原始来源或官方文档。
如何设计一个真正好用的 Bot
不要只写“你是一个很厉害的研究员”。一个可复用 Bot 至少要固定四件事：
角色：你负责什么，不负责什么
输入：用户必须提供哪些信息
输出：固定字段、格式和长度
验收：什么条件满足后才算完成
可以从下面的模板开始：
# Bot 角色
你是 Research Bot，只负责资料检索和证据整理。
## 你负责
- 优先查找官方公告、官方文档、项目仓库和维护者原帖
- 给每条结论附原始 URL
- 区分已确认、社区说法和待核验信息
## 你不负责
- 不编造缺失的发布时间、性能数字或用户数量
- 不把社区体验写成官方承诺
- 不读取、输出或转发凭据、Cookie、Token 和登录状态
## 输出格式
1. 结论
2. 原始来源
3. 证据摘录
4. 可信度
5. 未解决问题
## 完成标准
没有来源的关键断言必须进入“未解决问题”，不能直接进入最终稿。
三条适合日常运营的工作流
工作流 A：从热门主题变成原创文章
热门 X 主题
↓
Research Bot：收集 5–10 条原始来源
↓
人工确认：删掉重复、夸张和无法核验的说法
↓
Builder Bot：写成教程 / 对比 / 排障文章
↓
Reviewer Bot：检查来源、链接、敏感信息和可执行性
↓
人工发布：加入配图、摘要、内链和更新日期
工作流 B：把一次复杂任务沉淀成 Skill
一次任务完成后，不要只保存最终结果。让 Bot 记录：输入条件、关键命令、失败点、判断依据和验收标准。之后再把稳定步骤整理成 Skill。
这里可以结合 Hermes 的 /learn 思路，但应检查生成的 Skill 是否包含过时命令、过宽权限和未经验证的结论。Skill 能复用，不代表 Skill 自动正确。
工作流 C：跨机器分工
适合把本地桌面端、低成本 VPS 和专门的 Gateway 分开：
- 本地机器：需要浏览器、GUI 或个人文件的 Bot；
- VPS：持续运行的定时任务、轻量研究和内容处理 Bot；
- 独立 Gateway：需要隔离权限或独立模型配置的 Bot。
先确认连接的是 hermes serve 相关 Dashboard 后端，再检查认证方式和 Gateway 归属。不要因为某个 API_SERVER_KEY 存在，就假设 Desktop 会使用它完成连接。
安全边界：多 Bot 会放大权限问题
每个 Bot 都可能拥有自己的 Tools、Skills、记忆和外部连接。建议按“最小权限”设计：
| Bot | 推荐权限 | 不建议默认开放 |
|---|---|---|
| Research | 浏览、读取公开资料、写研究草稿 | 发帖、发邮件、修改生产文件 |
| Builder | 读取证据表、写工作区草稿 | 直接部署、删除文件、发送外部消息 |
| Reviewer | 读取初稿、链接检查、静态扫描 | 修改原始数据、代替人工批准发布 |
尤其要注意三类风险：
- 记忆串线：个人信息、客户资料和公开研究不应混在同一个 Bot 的长期记忆里。
- 外部连接串用：连接了 X、邮箱、支付或代码仓库的 Bot，不应默认拥有所有其他 Bot 的操作能力。
- 自动发布失控：把“生成草稿”和“发送到外部平台”分成两个步骤，最后一步保留人工确认。
一个最小验收清单
首次搭建 Bot 团队时，可以逐项打勾：
- [ ] 每个 Bot 有明确的单一职责；
- [ ] 每个 Bot 有独立的输入、输出和完成标准；
- [ ] Research Bot 能保留原始来源 URL；
- [ ] Builder Bot 不会把待核验内容写成确定事实；
- [ ] Reviewer Bot 能发现无来源数字和失效链接；
- [ ] 不同 Bot 的记忆、工作目录和外部连接已明确隔离；
- [ ] 远程 Gateway 的认证方式已单独验证；
- [ ] 外部发帖、发邮件、部署和删除操作保留人工确认；
- [ ] 用一条无敏感信息的测试任务跑通完整链路；
- [ ] 记录 Hermes 版本、Desktop 版本和测试日期，方便回归。
最后：运营上不要追逐“Bot 数量”，要追逐“可复用交付”
Bot Mode 最有价值的地方，不是把一个 Agent 包装成很多头像，而是把高频工作拆成稳定角色：研究有证据、写作有结构、复核有标准、发布有闸门。
对内容运营来说，一条热门 X 帖子只是选题信号，不是文章本身。真正能沉淀长期流量的页面，应该进一步回答：
- 这个功能到底解决什么问题？
- 谁适合使用？
- 如何开始？
- 哪些说法仍未核验？
- 如何验证配置成功？
- 出问题时如何回滚？
这也是把“热点搬运”变成“可搜索、可执行、可复用内容”的关键一步。
来源与更新时间
- 资料来源：Hermes Agent 官方、维护者和社区公开 X 帖文，链接已在正文对应段落列出。
- 本文定位：基于公开动态整理的实践方法，不代表对所有 Hermes 版本功能的独立实测。
- 更新日期：2026-08-27