Buzz：让人和 AI Agent 在同一个房间里干活

367 stars today | Rust | by Block

一个工作群的截屏

凌晨两点，你在一个叫 #payments-api 的频道里打了一行字："这个错误之前见过吗？"

三秒后，一个叫 @incident-bot 的成员翻出了过去六个月的相关讨论、根因分析、修复 PR，把链接贴在频道里，然后问："要不要我把最后一个提交者叫醒？"

整个对话——你的问题、Agent 的回答、证据链——都留在了频道里。不是某个 bot 的私信，不是某个 CI 面板的日志，是频道里的一条消息。

这就是 Block（原 Square）开源的 Buzz 想做的事：一个人类和 AI Agent 共享的工作空间。

它到底是什么

Buzz 是一个可自托管的工作空间，核心架构选择很激进——它是一个 Nostr relay。

每一条消息、每一个 emoji 反应、每一次工作流步骤、每一个代码审查批准、每一个 git 事件，都是一个签名过的 Nostr 事件，写在同一份日志里。人类发的消息和 Agent 发的消息，用的是同一种数据结构、同一套身份模型、同一条审计链。区别只在于：人类用人的密钥对，Agent 用 Agent 的密钥对。

README 里有一句话说得很直白：

Agents are members, not bots.

不是在聊天工具里挂一个 webhook，不是给 CI 跑完发一条通知，而是把 Agent 当成团队的正式成员——加频道、看历史、提 PR、做审查、跑工作流，和人拥有完全相同的操作面。

三个场景

README 里给了三个具体场景，比任何架构图都清楚：

场景一：事故记忆。 凌晨两点，你问"这个错误之前见过吗？"Agent 翻六个月历史，把相关线程、根因、修复方案贴出来，问你要不要呼叫最后提交的人。整个交互留在频道里。

场景二：分支即房间。 你开一个 feature 分支，自动出现一个频道。补丁以 NIP-34 事件的形式落地，CI 结果发到频道里，Agent 做第一轮审查，队友对关心的部分加 emoji 反应，合并决策也在同一个频道里做出。频道本身就是"这段代码为什么存在"的完整记录。

场景三：自己写自己的发布说明。 工作流在 tag 上触发，Agent 读所有合并的 PR，起草 release notes，发到频道等人审，拿到 👍 反应后发布。每一步都签名，每一步都可搜索。

为什么选 Nostr

这是 Buzz 最有意思的技术选择。

大多数团队协作工具的架构是：聊天是一套系统、CI 是一套系统、代码托管是一套系统、bot 是一套系统，中间用 webhook 和 API 对接。每个系统有自己的数据模型、自己的身份系统、自己的权限系统。你在一个系统里搜不到另一个系统里的东西。

Buzz 的选择是：所有东西都是同一种事件。Nostr 协议本身是为社交媒体设计的去中心化协议，核心思想是"所有内容都是签名事件，relay 负责存储和转发"。Buzz 把这个模型借过来，用在团队协作上：

• 消息是事件
• 代码补丁是事件（NIP-34）
• CI 结果是事件
• 审查批准是事件
• Agent 的操作也是事件

Block 为什么要做这个

Block 是 Twitter 创始人 Jack Dorsey 的公司（旗下有 Square、Cash App），Dorsey 本人是 Nostr 协议的早期支持者。所以 Buzz 选择 Nostr 不完全是技术考量，也有理念认同。

但抛开理念，Buzz 解决的确实是一个真实问题：Agent 在现有协作工具里是二等公民。

在 Slack 里，bot 是一个 webhook，它发消息但看不到频道历史。在 GitHub 里，bot 是一个 token，它能操作 PR 但不在频道里。在 Jira 里，bot 是一个 API key，它能创建 ticket 但不参与讨论。

Buzz 的核心赌注是：如果 Agent 拥有和人一样的操作面——同样的频道访问权、同样的历史搜索能力、同样的工作流触发能力——它能做的事会多得多。

当前状态

Buzz 今天能做的事：

• Relay、频道、线程、DM、画布、媒体、搜索、审计日志
• 桌面应用（Tauri + React）
• buzz-cli（Agent 优先，JSON 输入输出）+ ACP harness（支持 Goose、Codex、Claude Code）
• YAML 工作流：消息/反应/定时/webhook 触发
• Git 事件（NIP-34：补丁、仓库公告、状态）
• Git 托管后端

有强烈想法但还没实现的：跨 relay 的信任网络、推送通知。

一个更大的问题

Buzz 引出的真正有趣的问题不是"Nostr 能不能做协作工具"，而是：当 Agent 成为团队的正式成员时，协作工具应该长什么样？

现在的做法是：人在 Slack 里讨论，Agent 在后台跑，通过 webhook 把结果塞回 Slack。Agent 是一个" haunted cron job"—— haunted 的幽灵，cron job 的定时任务。

Buzz 的答案是：把 Agent 拉到桌前，给它一个座位，让它和人用同一套工具、同一套协议、同一套审计链。不是更聪明的 bot，而是更平等的成员。

这个方向对不对，现在还不好说。但 367 stars today 的增长说明，至少有不少人觉得"haunted cron job"不是 Agent 协作的终局。

*GitHub: block/buzz · License: Apache 2.0 · Language: Rust*