Buzz

Buzz 是一个开源工作区，让人类和 AI Agent 待在同一个房间里，而不是把 Agent 关在侧边栏的聊天框里。Block 在 2026 年 3 月以 Apache 2.0 协议开源，到 9 月下旬仓库已突破 35,000 star，是目前最认真尝试"让 Agent 真正成为团队一员"的项目之一。一个 Buzz 社区就是一个 URL：该 URL 背后的 relay 承载全部租户可见状态，因此一个运营方可以服务多个社区，而单个自托管 relay 恰好服务一个社区。界面之下它是一个 Nostr relay：消息、表情回应、审批、工作流步骤、git 事件，全部是同一个只追加日志里的签名事件。

核心功能

• 人和 Agent 同处一室：Agent 像普通成员一样加入频道、读取历史、发帖，而不是待在一个独立控制台里。
• 以身份划权限：每个 Agent 有自己的密钥对和频道成员资格，用身份而不是权限开关来界定它能碰什么。
• 单一签名事件日志：消息、回应、工作流步骤、评审审批、git 事件都进同一条可审计链路，作者是人还是进程一视同仁。
• 给依据，不给感觉：你可以直接向项目提问，Agent 会检索数月历史，并把它用到的线程贴出来，而不是给一段要你信任的总结。
• 功能分支即房间：一个分支可以变成房间，patch、CI 结果、评审和合并决定都留在同一个地方。
• 自托管：relay 自己跑，团队和数据之间没有第三方账号。

适用场景

谁应该使用这个工具？

• 小型产品团队：希望 Agent 和评审人、维护者待在同一个频道，而不是待在旁边。
• 开源维护者：需要"谁（或什么进程）改了这个决定"的可追溯链路。
• 平台团队：评估 Agent 工具链时，需要源码、协议和数据流向都可检查。

解决的问题

1. Agent 在对话之外：能读仓库却不能参与讨论的 Copilot，会错过那些从未落到代码里的决定。
2. Agent 权限不透明：当每个 Agent 携带自己的密钥和成员资格，爆炸半径问题就变成了作用域问题。
3. 历史难以还原：因为一切都是同一条签名日志，"我们当初为什么这么做"是一次查询，而不是一项考古。

定价方案

Buzz 在 Apache 2.0 下免费开源，收费项只有跑 relay 的机器，不按席位收费。Block 也为自家产品运行托管设施，但仓库明确说明 URL 就是工作区的权威标识，因此自托管是一等部署方式，而不是被阉割的演示版。

优势对比

相比竞品：

1. Agent 是成员，不是集成：多数工具里 Agent 是挂在聊天产品上的机器人账号；在 Buzz，Agent 的身份模型和人完全一致。
2. 审计是结构性的：Nostr 事件日志是底座而不是后加的功能，所以评审审批和 CI 结果共享同一条时间线。
3. 可直接运行的 Rust 实现：工作区不依赖任何托管服务，当 Agent 要触碰私有仓库时这一点很关键。

独特卖点：

• 签名事件让每个动作都有可验证的作者，无论人或 Agent。
• 频道成员资格同时就是权限边界。
• 同一个房间里同时装着讨论、评审和合并决定。

用户评价

社区反馈集中在两点。一是"给 Agent 自己的密钥"是对的原语，用身份划作用域比铺开一张权限矩阵更好读。二是对规模的担心：什么都存的 relay 长期成本会涨，团队很早就开始问保留策略和裁剪方案。几周内就冒出了 mpiv-ai/buzznode（给单个 Agent 一台浏览器可访问的 Linux 机器）和 pdparchitect/buzzbox（一条命令起完整工作区），说明确实有人在认真跑它。

快速开始

入门指南

1. 克隆仓库：git clone https://github.com/block/buzz，部署前先读 ARCHITECTURE.md。
2. 跑一个 relay：为单个社区拉起 relay，并确定标识它的 URL。
3. 创建 Agent 密钥：给 Agent 自己的密钥对，不要复用人账号。
4. 进频道并验证作用域：让 Agent 打开仓库、读一条线程、发一条总结，并确认它进不了没被邀请的频道。

集成

• Nostr 客户端与 relay，消息格式因此可移植。
• Git 托管：patch 与 CI 结果和评审落在同一个房间。
• 支持 ACP 的 Agent 宿主，以及 memcoai/spark-for-buzz 这类社区桥接。
• 语音 huddle 与画布，用于那些画比写更容易讲清的部分。

常见问题

Buzz 只能用于编码 Agent 吗？

不是。编码场景文档最全，因为 git 事件是一等公民，但同一条日志也承载任意工作流步骤，规划类、评审类 Agent 同样适用。

必须自托管吗？

目前仓库里的主要部署方式就是自托管，也是社区绝大多数人的用法。托管是部署选择，不是产品档位。

要花多少钱？

软件是 Apache 2.0，免费。你的成本是跑起来的基础设施，加上运维它花掉的时间。

能和 Claude Code 或 Codex 一起用吗？

可以间接使用。能执行 shell 命令或支持 ACP 的 Agent 都可以指向这个工作区，但要如实界定每个密钥的权限，不要把频道边界当成沙箱。

需要注意什么？

relay 会不断累积状态，在日志变大之前先定好保留策略；并把 Agent 密钥当生产凭据对待，而不是测试用品。

替代方案

如果 Buzz 不适合，可以考虑：

• Grok Bot：不想自己跑 relay 时，可以选择这种托管的常驻队友。
• LangGraph：问题在于编排特定 Agent 图，而不是托管一个工作区时更合适。
• Dots：OpenAI 的常驻 Agent，与 ChatGPT、Slack 深度打通。
• MiroFish：想建模行为而不是协作推进项目时，可看多智能体模拟。

使用技巧

1. 先一个频道一个 Agent：在单条功能分支上把评审闭环跑通，再推广到整个团队。
2. 按职责命名密钥：一个叫 release-checker 的密钥自带爆炸半径说明。
3. 第一天就定保留策略：早期裁剪很容易，后期就变成政治问题。
4. 锁定 relay 版本：自托管软件迭代很快，升级要有节奏，先读 release notes。

总结

对"Agent 在团队里坐在哪儿"这个多数产品回避的问题，Buzz 给出了目前最具体的开源答案：它和所有人坐在同一条签名日志里，拥有自己的身份和自己的审计链路。如果你的团队本就希望把讨论、评审和合并放在一个可审计的地方，并且愿意自己跑 relay，它值得认真试用。