自托管蜂巢工作空间：人类与AI代理共享同一间“房间” | buzz

📌 项目地址：block/buzz | ⭐ 6,159 颗星 | 🔧
Rust | 📜 未标注

它不是又一个“AI聊天机器人”

多数团队工具引入AI代理时，要给一个API
Token，把它挂在频道里当bot。Buzz换了个思路：代理和人类共用同一套身份模型——各自有密钥对、各自签名事件、各自有频道成员关系。加入一个代理，就像邀请一个新同事，而不是装一个插件。

底层是Nostr
relay。所有消息、反应、代码审查、CI事件、工作流步骤，都是签名事件写入同一个日志。人类写的事和代理写的事件，形状一样，身份一样，审计线索一样。用户看到的是一个工作空间界面，实际是一个“有口味”的事件日志。

一个事实：代理能做的和人类一样多

来自README的五个具体场景，没有一句编造：

• 搜索六个月历史，带引用贴出答案。代理不是凭感觉回复，而是翻出具体线程和事件哈希。
• 把功能分支变成“房间”
  。补丁、CI、代码审查、合并决策都存在一个房间里。那个频道本身就成了“为什么代码存在”的记录。
• 让代理分类一个bug，但不给它管理员权限。代理有自己的密钥和频道成员资格，作用域由身份决定，不是权限标志位。和分配任务给新人一样自然。
• 在同一个地方搜索聊天、补丁、工作流、审批。因为它们在底层全是同一类事件。
• 让代理管理工作空间本身：创建频道、编辑画布、运行工作流、发起语音、编排其他代理。不是只会回消息的bot。

核心差异：统一身份+统一日志

Slack、Discord、Teams处理代理时，一般做成bot
user挂在人类账号下，或通过OAuth授权。权限靠管理员设置，行动记录分散在不同系统（聊天、CI、仓库）。Buzz的办法是：代理有自己密钥，签名自己事件，事件日志里人类和代理条目完全同级。你不需要纠结“给/不给写仓库权限”，只需要决定“是否把这个代理加进某个频道”。因为代码提交、工作流、审批都在同一个日志里，搜索和审计的准确性比跨系统拼接高得多。

需要注意的几件事

• 单relay，单社区。默认自托管方案，一个relay
  URL对应一个社区。要服务多个团队，得跑多个relay或找托管商。README提了“hosted
  operator can serve many communities behind many
  domains”，但没有给出具体多租户搭建指南。
• 自托管是根基。要体验，需要自己部署Nostr
  relay和Buzz客户端。README没有一键部署命令，只有架构图：客户端→Relay→存储。建议去看仓库的文档或issue。Apache
  2.0许可证，可商用，但运维责任在自己。
• Nostr基础概念门槛。如果不熟悉relay、事件签名、密钥管理，可能需要花时间。但Buzz的UI层（从截图看有频道、画布、媒体评论）已经把包装成类似Discord/Notion的界面。
• 生态仍在早期。6159
  star说明关注度不低，但仓库可能还在快速迭代。代理能力取决于你接入的LLM和工作流配置，Buzz不捆绑模型，需要自己配置代理的密钥和行为逻辑。

一句话判断

如果你需要数据主权、统一审计，愿意自己部署Nostr
relay，Buzz提供了一个把代理真正当成员的工作空间框架。如果你只是想加点聊天机器人，它可能太重。