Block 开源 Buzz：把人类和 AI agent 放进同一个 Nostr 中继里协作

2026 年，Block, Inc.（前 Square）在 GitHub 以 Apache-2.0 协议开源了 Buzz——一个「人类和 AI agent 一起构建」的自托管工作空间。它的开场定位很直白：「A workspace where humans and agents build together, on a relay you own.」官方甚至自嘲「是的，这又是一个 AI 周边开发者工具，我们很抱歉」。区别在于 agent 进了房间之后真正能做事：开仓库、发补丁、review 代码、跑 workflow、编辑画布、编排其他 agent、开语音临时讨论、建频道。本文基于仓库 README 与官方截图做一手拆解。

一、它到底是什么：一个 Nostr relay，套了协作软件的皮

Buzz 表面上像 Slack/Discord 这类团队工作空间，但底层是一个 Nostr relay：每一条消息、表情回应、workflow 步骤、review 批准、git 事件，都是同一条日志里的一个签名事件。无论作者是人还是程序，事件形状、身份模型、审计轨迹都一样——只是密钥对不同。

一个 Buzz community 就是用户通过 URL 访问到的工作空间。当前单中继部署里，relay URL 唯一定位一个 community；托管方也可以在多个域名/子域后服务多个 community，但客户端规则不变：URL 决定工作空间，该 URL 下所有租户可见状态都是 community 本地的。

二、核心 bet：agent 是「成员」，不是 bot

Buzz 最想传递的设计观是：agent 有自己的密钥、自己的频道成员资格、自己的审计轨迹，按身份（而不是权限开关）授权，就像你给一个同事授权一样。agent 不是挂在 cron 上的「闹鬼任务」，而是房间里的一员——能被 @、能被拉进频道、能被要求交接。

官方给了三个场景故事：

• 事件记忆：凌晨两点你问「这个错误我们以前见过吗？」，监控频道的 agent 拉出六个月历史，贴出相关线程、根因、修复，并主动提出通知上次发版的人；
• 分支即房间：开一个 feature 分支，频道自动出现，补丁作为 NIP-34 事件落地，CI 贴结果，agent 做初筛 review，合并决策和证据在同一个房间；
• 自动写发版：workflow 打 tag 触发，agent 读已合并 PR、起草 release notes、贴出来等人点 👍 反应后发版，每一步都签名、都可搜索。

三、技术架构：Rust workspace + 一个中继作为唯一事实源

官方给出的架构是分层的：客户端（Buzz 桌面端 / Goose、Codex 等 agent / buzz-cli）通过 WebSocket 打到 buzz-relay（Axum，WS + REST，实现 NIP-01、NIP-42 鉴权、channel/DM/media/workflow/git REST、审计日志），再往下是 Postgres（事件 + 全文搜索）、Redis（pub/sub、在线状态、正在输入）、S3/MinIO（Blossom 媒体）。

整个后端是一个 Rust crate 工作区，按职责拆分：buzz-core（零 I/O 类型、NIP-01 过滤器、Schnorr 验签）、buzz-relay、buzz-db、buzz-auth（NIP-42/98 Schnorr 鉴权、限流）、buzz-pubsub、buzz-search（Postgres FTS）、buzz-audit（哈希链日志）；agent 面有 buzz-cli（JSON in/JSON out，为 LLM 工具调用设计）、buzz-acp（对接 Goose/Codex/Claude Code 的 ACP harness）、buzz-agent、buzz-dev-mcp（shell + 文件编辑工具）、buzz-workflow（YAML 自动化）、buzz-persona（agent 人设包）；git 面有 git-sign-nostr / git-credential-nostr（Nostr 签名的 git）。给 agent 接入时只需设置 BUZZ_PRIVATE_KEY 再用 buzz-cli，它对 LLM 工具调用友好，输出结构化 JSON 而非自然语言段落，方便 agent 程序化解读。审计层 buzz-audit 用哈希链记录事件，意味着任何一条消息、审批或补丁的历史都可被链式校验，这也是它敢让 agent 持有真实写权限的技术前提。

自托管路径很常规：装 Docker 与 Hermit（或 Rust 1.88+、Node 24+、pnpm 10+、just），just setup && just build，日常 just dev 起中继（ws://localhost:3000）和桌面端；生产用 deploy/compose/ 的 docker compose（Postgres、Redis、MinIO、可选 Caddy/TLS），也支持 Railway 一键部署。

四、关键事实：它现在能干什么、不能干什么

官方用三栏明确标注了成熟度，这是读这个 repo 最该看的部分：

官方特别提醒：「请不要按 💭 那一栏来规划你的合规方案。」仓库本身数据（截至本文撰写时）为约 2,756 次提交、1.6k issues——说明它迭代很快，但也意味着仍在高速变动期。

五、客观分析：优势与局限

优势：

• 用「同一种签名事件」统一了聊天、workflow、git、审批，省去了「聊天 + forge + bot + CI 面板 + 发版工具 + 搜索 + 胶水」七张标签页互相假装认识的局面；
• agent 与人类同身份模型、同审计轨迹，按身份授权，比「给 bot 一个长期 token」更可控；
• Nostr/开源/自托管，数据在自己手里，Relay 你自己拥有。

局限与官方口径偏差：

• 它还没做完：移动端、workflow 审批门禁、推送通知都在「正在接」或「只有想法」一栏；把它当成熟协作平台会踩空；
• Windows 安装包未做代码签名，首次运行 SmartScreen 会报「Windows 已保护你的电脑」；agent 的 shell 工具在 Windows 上还要自己装 Git for Windows；
• 自托管有真实运维成本：Postgres + Redis + MinIO + Rust 工具链，不是「双击即用」；
• 官方明说「这不是区块链」——签名事件有审计价值，但不要期待代币或公链叙事；也「不是 AI 替代计划」，人在回路仍是前提；
• 多 community 模式下共享 Postgres/Redis/对象存储，但官方强调租户边界是语义层的，对自托管单中继用户这个复杂度暂时用不上。

六、谁该关注

• 想要「agent 是团队一员」而非「agent 是外挂脚本」的工程团队，尤其已经在用 Goose/Codex/Claude Code、又想给它们一个带审计的工作空间的人；
• 喜欢 Nostr 协议、想在其上看一个「事件日志 + 协作 UI」能做到什么程度的开发者；
• 愿意跑 docker compose 自托管、能接受 alpha 软件的团队。

对想要开箱即用、有移动客户端、不操心运维的普通团队，现阶段更现实的选择仍是成熟 SaaS；Buzz 更适合那些愿意和它一起把「正在接」的部分补齐的人。

参考来源

• block/buzz — GitHub
• Koala 项目库条目 #1715 Buzz