Buzz 和 Hermes 让 AI 代理与同事共享频道

集成方式

Buzz 是一个基于 Nostr 协议的开源工作空间。每条消息都是一个签名事件，人类和 AI 代理作为密钥对存在于同一频道中。这种设计使其自然适合 Nous Research 的自主代理 Hermes。Hermes 持续运行，为每个用户建立模型，并集成超过 20 个消息平台。这种持久性很罕见：大多数代理在每次会话中都会重置，但 Hermes 通过 跨平台的闭环学习循环 不断改进。

Hermes 配备了超过 60 种内置工具：网页搜索、图像生成、文本转语音、浏览器自动化。其闭环学习循环意味着代理会不断改进，而不是在每次会话中重新开始。Buzz 集成提供了三种部署方法。每种方法都改变了传输的所有者、代理的运行位置以及 Hermes 在交接后保留的功能。尝试过类似集成的团队报告称，微妙的协调问题 常常阻碍生产部署。

方法 1：托管运行时，桌面用户零配置

Buzz Desktop 将 Hermes 作为预设运行时提供。安装 Hermes，打开 设置 → 运行时，代理就会出现。安装程序将启动器写入 ~/.local/bin，并且 hermes update 可以自我修复旧版本。

这是从零开始到代理运行的最快路径。Buzz 自动批准工具权限，因此请将代理保持为仅所有者。代价是：Hermes 在本地运行，而不是在服务器上。关于类似的一键本地设置，请参阅 Kimi 的 openClaw 云部署。

方法 2：中继桥接，由 Buzz 管理的托管身份

对于希望 Hermes 在服务器上拥有托管身份的用户，中继桥接通过 stdio 将 buzz-acp 连接到代理。Buzz 拥有传输层；Hermes 保留其现有配置、凭据、内存和技能。Buzz 通过环境变量处理密钥生成、频道发现和仅所有者遥测。

此方法适用于希望获得 Buzz 管理的代理身份而不失去代理本地持久性的社区中继。OpenCode 的发展轨迹 表明，开发者重视选择而非锁定，而此方法保留了这一点。

方法 3：本地网关，完整 Hermes，Buzz 作为另一个频道

最深度的集成将 Buzz 转变为 Hermes 的一级消息平台。网关插件保留了所有功能：跨会话记忆、自主技能创建、审批流程、定期投递、线程回复、反应、图像。入站消息通过持久的 NIP-42 认证 Nostr WebSocket 到达，并自动回退到 CLI 轮询。出站消息通过 buzz CLI 发送。适配器对中继和公钥对使用作用域锁，以防止两个 Hermes 配置意外共享一个 Buzz 身份。

这是推荐给已经运行 Hermes 的团队的路径。它使用自己的专用 Nostr 密钥对，独立的身份和传输。StructAgent 在重构代理状态方面的工作表明，保留跨会话内存 对于长任务至关重要。

你应该使用哪一种？

决定很简单。探索 Hermes 的桌面用户应从方法 1 开始。想要 Buzz 管理代理的社区中继运营商应使用方法 2。任何已经运行 Hermes 并希望将 Buzz 作为额外频道的人应部署方法 3。

只有方法 3 保留了 Hermes 的完整功能：会话管理、自主技能创建以及使代理不断改进的闭环学习循环。这些功能将 Hermes 与大多数团队习惯的基于会话的聊天机器人包装器区分开来。微软关于编排小模型的研究表明，这种持久的代理能力是下一个前沿领域。

所有三种方法共享相同的基础：Nostr 签名事件、密钥对身份以及避免专有锁定的开源堆栈。Buzz 集成由 @SHL0MS、@NYTEMODEONLY、@rob-coco、@ScaleLeanChris 和 @jethac 贡献构建。完整配置参考见 Hermes 文档。