Buzz 是 Block 开源的 Rust 项目，以自托管 Nostr 中继为核心，让人类与 AI 代理在同一事件日志和身份模型中协作，共享频道、搜索与审计链。
项目做什么
项目试图把团队目前用聊天、代码托管、机器人、CI 面板、发布工具和搜索索引拼凑起来的工作流，收敛到一个以中继为唯一事实来源的载体上。按 README 描述，消息、回应、工作流步骤、审查批准和 git 事件都写为同一日志中的签名事件，人类与自动化进程共用同一身份模型和审计轨迹。自托管默认一个中继对应一个社区，托管方可在共享 Postgres、Redis 与对象存储的后端上服务多个社区，但 URL 决定工作区边界，租户可见状态按社区隔离。
与同类方案相比
README 主张的优势来自统一底座：人类、代理、工作流与仓库使用同一协议、同类密钥和同一搜索索引，因此对话、补丁、工作流运行与审批可以在同一处检索，而不必在多个工具之间搬运上下文。默认自托管部署中一个中继承载一个社区；多租户部署中每个社区仍保留语义边界，共享基础设施被描述为实现细节而非用户可见的全局工作区。这些属于设计主张，README 未提供与现有工具的基准测试或对照数据，因此相对优势尚无法独立验证。
设计与创新
较具体的设计点包括：代理以成员身份加入频道，拥有自己的密钥、频道成员资格和审计轨迹，用身份而非权限开关限定能力范围；git 操作以 NIP-34 事件表示，覆盖补丁、仓库公告与状态；分支可对应一个频道，使补丁、CI、审查与合并决定集中在同一房间；媒体评论锚定到具体帧；buzz-acp 充当 ACP 与 MCP 之间的适配层；审计采用哈希链日志。这些大多是既有协议与组件的组合，其新颖程度在给定材料中无法独立评估。
适用场景
README 给出的典型场景包括：让代理检索约半年历史，回答“是否见过该错误”并附上讨论、根因与修复证据；为特性分支建立房间，让补丁、CI 结果、代理初评、团队回应与合并决定同处一地；由 tag 触发的发布流程让代理汇总已合并 PR、起草发布说明、等待人类回应后发布；让代理在不获得全权的前提下分诊缺陷；在视频等媒体上按帧留言。其中工作流审批门、huddle 生命周期事件与移动端在 README 中被标注为仍在接入，尚未完成。
谁会受益
对于希望自行托管、并让 AI 代理参与工程协作的小型团队，Buzz 提供了已打包的桌面端（macOS 的 Apple Silicon 与 Intel、Linux 的 AppImage 与 deb、Windows x64）、一键部署到 Railway 的中继方案，以及面向 LLM 工具调用的 buzz-cli（JSON 输入输出）和针对 Goose、Codex、Claude Code 的 ACP 适配。仓库内还有 deploy/compose 的单节点 VPS 部署包与基于 just 的开发命令集。是否适合具体团队，取决于其能否接受 Nostr 事件模型与当前的功能完成度；README 未提供规模化运行或负载数据。
使用前需要注意
README 明确列出尚未完成的部分：移动客户端（iOS 与 Android，Flutter）、工作流审批门、huddle 生命周期事件属于仍在接入；跨中继的信任网络声誉、推送通知和文化功能仅有设想，代码未落地。Windows 构建未做代码签名，首次运行可能触发 SmartScreen 提示；从源码运行需要 Docker，以及 Hermit 或指定版本的 Rust、Node、pnpm 与 just，Windows 上还需 Git Bash 或通过 BUZZ_SHELL 指定兼容 shell。客户端默认连接 ws://localhost:3000。文档未给出性能基准、与竞品的实测对比，多租户共享 Postgres、Redis 与对象存储时的隔离强度也未经独立验证。
本文基于抓取时的项目 README 和仓库简介整理；功能、限制与文档可能随项目更新而变化。