Hermes Agent Bot 模式发布

去掉头像和名单视图后，Bot 模式中的“机器人”其实只是一个 Hermes 配置文件：独立的配置、记忆、技能、凭证和聊天历史，存储在磁盘上的 ~/.hermes/profiles/<name>/ 目录下。Nous Research 自己的代码仓库明确指出实际开发的工作量极小——没有核心补丁、没有后台守护进程、没有额外的存储层，所有内容都是标准的 Hermes 表面功能 ^[1]。Bot 模式真正增加的是命名、身份（角色、图片、描述）以及一个视觉切换器，取代了旧的单代理会话列表。

这一点很重要，因为 Hermes Agent 早在 v0.6.0 版本就已发布了底层基础功能——“配置文件”，用于运行隔离的代理实例——这比 Bot 模式作为一个概念出现早了大约四个半月。基于已有且经过实战检验的基础功能进行构建，而不是发明一个新的多代理子系统，是一种低风险快速交付重磅功能的方式，事实也正是如此：从一天的公开测试版到捆绑并默认启用仅用了两天时间。这也解释了该功能在其用户中最常见的批评声音：从结构上看，它本质上只是一个皮肤。

Bot 模式的首次公开亮相紧随 xAI 推出其“Grok Bot”功能几天之内，关于 Nous Research 发布的报道也明确以此为框架 ^[2]。当一名用户直接向构建 Bot 模式的 Nous Research 联合创始人 Teknium 提出这一对比时，他的回复只有两个字：“正是如此。” 这几乎等同于在发布时公开承认了竞争意图。

这种比较的实质在于许可证，而非原始能力——大多数观点认为 Grok Bot 在每个机器人的云端和浏览器计算方面仍具有优势。而 Nous Research 所强调的是开放性：Bot 模式及其运行的 Hermes Agent 均采用 MIT 许可证，意味着任何人都可以查看、分叉或重新分发多机器人工具链，而 Grok Bot 则封闭在 xAI 的产品中。这种定位针对的是特定受众——希望掌控自己代理栈的个人开发者和小型团队，而不是封闭竞争对手可能追逐的企业级基础设施买家。

目前大家纷纷分享截图的功能是机器人之间的消息传递，但从机制上看比看起来更简单：机器人通过一个持久化的代理收件箱进行通信，@提及某个机器人会触发一次真正的 CLI 交接，而不是通过某种新的消息层进行路由 ^[1]。发起交接的机器人将等待回复，并将结果折叠回自己的对话中，因此从用户角度看，就像把一位专业同事拉进讨论，而不是调用另一个独立程序。

这种交接模型可扩展至包含两到六个机器人的群聊，每次用户消息最多允许三轮连续响应，之后控制权才会交还给人类 ^[2]。Nous Research 自己文档中指出的权衡是，机器人之间的传递按调用发生，而非通过即时或中断驱动的通道——这对于研究后再审查的顺序工作流来说足够好，但对于试图在此基础上构建紧密耦合、低延迟多代理流水线的人来说则构成了真实瓶颈。

发布的节奏本身就很引人注目：8月14日进行为期一天的公开测试，两天后（v0.20.3，约125个拉取请求）即被整合进默认启用的版本，再过两天又发布了补丁版本（v0.20.4，约74个拉取请求），修复了群聊 bug 并添加了标签页形式的会话/机器人侧边栏 ^[3]。这表明公司正在根据早期用户实际使用中发现的问题近乎实时地迭代其重磅功能。

早期用户对该功能的反应确实存在分歧。一派——可见于 Reddit 上的一篇构建日志，其中一名测试者组建了一个由研究员、风险分析师和论点编辑组成的三人股票研究机器人团队——将可重复使用、职责明确的专业机器人视为真正的生产力提升，减少了将工具加载到单一全能配置文件中的每轮代币成本。另一派则称之为 Hermes Desktop 前端的新奇功能：多代理能力‘本来就存在’，此前可通过 Telegram 或 Discord 的机器人间设置或原生的 Agent-to-Agent 协议实现，Bot 模式只是为其赋予了面孔。两种观点之下都存在一个实际难题——分散在多个机器人中的共享知识容易逐渐不同步，因此测试者建议将其保留在单一工作目录级别的文件中，而不是复制到每个机器人的记忆里；Nous Research 团队表示，未来版本将计划推出跨配置文件的正式共享内存系统。