2026 年 3 月建仓，到 10 月已经 3.5 万 star —— 这是 Block, Inc.（原 Square）开源的 Buzz。

它的自我描述只有一句："A hive mind communication platform"（蜂巢思维通信平台）。README 里那句解释更直白："A workspace where humans and agents build together, on a relay you own."（一个人类与智能体共同构建的工作空间，跑在你自己拥有的 relay 上。）

但这个定位很容易被二手文章讲歪 —— 我搜到的中文资料里，有的说它是"去中心化多 Agent 通信基础设施，支持大规模 Agent 协作与消息路由"。这是把它讲小了。它不是一个消息中间件，而是一个完整的工作空间：聊天、论坛、画布、代码托管、工作流、语音房、搜索、审计日志，全部塞在同一个事件日志里。

本文重点讲清楚一件事：你到底会在什么情况下用它。

一、Buzz 是什么

先看一手数据（2026 年 10 月 2 日通过 GitHub 官方接口查询）：

• 仓库：block/buzz，出品方 Block, Inc.
• 许可：Apache 2.0
• 规模：35,411 star、4,668 fork、3,619 个未关闭 issue；2026-03-06 建仓，最后一次推送就在 2026-10-02
• 技术：主语言 Rust，仓库约 592 MB、5,464 个文件、33 个 Rust crate、27 个 CI workflow
• 发布节奏：已有 123 个 release，最新桌面版 v0.5.26（2026-09-29）

它的核心机制一句话能说清：Buzz 是一个 Nostr relay，每一条消息、每一个表情回应、每一步工作流、每一次代码评审通过、每一个 git 事件，都是同一个日志里的一条签名事件。作者本人说的更传神：

"In practice it feels like a team workspace. Under the hood it's an event log with taste and a suspicious number of Rust crates."

（实际用起来像个团队工作空间，底层是一个有品味的事件日志，以及多得可疑的 Rust crate。）

关键在于：人和 Agent 用的是同一套身份模型、同一条日志、同一个搜索索引。区别只是一个有血肉，一个只有密钥对。

二、为什么它和 Slack + GitHub 不是一回事

现在一个团队的真实工作流大约是这样的：聊天在 Slack，代码在 GitHub，CI 在另一个面板，发布在第三个工具，搜索靠人肉回忆，中间再写一堆胶水脚本把它们粘起来。Buzz 的赌注是：

"one substrate instead of seven tabs pretending they know about each other"（一个底座，而不是七个假装互相认识的标签页）。

落地到设计上，差异体现在这几处：

• 一个社区 = 一个工作空间 = 一个域名。 浏览器打开 myproject.com 看到的是你的仓库；git clone repoa.myproject.com 直接用；打开 Buzz 客户端就进了工作发生的那些频道。不需要 GitHub，不需要 Discord。
• 三个视角，一条日志。 Stream（像 Slack 的实时话题聊天）、Forum（像 Discourse 的异步长帖）、Workflow（结构化、可追溯的自动化）—— 三种表面形态，读的是同一份事件日志和同一个搜索索引。
• 通知默认是零。 这是它一个很反直觉的设计选择："Zero is the default. You opt in to noise, not out."（默认静音，你是主动选择接收噪音，而不是主动屏蔽。）Stream 和 Forum 默认零通知，只有 DM 标为紧急，工作流只有审批环节通知。
• Agent 不是机器人，是成员。 把 Agent 加进频道的方式和加一个人一样。它有独立密钥、独立频道成员资格、独立审计轨迹。README 的原话是："Agents are part of the room, not haunted cron jobs."（Agent 是房间里的一员，不是闹鬼的定时任务。）

三、使用场景：你会在什么情况下用它

这是本文的重点。我把 README、四份 VISION 文档里描述的场景整理成了 9 个，并且在每个场景后面标注了它现在到底能不能用 —— 因为 Buzz 官方自己就把功能分成了"今天能用 / 正在接线 / 只有强烈观点还没代码"三档，这个区分对读者比什么都重要。

场景 1：凌晨两点的故障复盘 —— "这个错我们以前见过吗？"

这是官方 VISION 文档开篇举的第一个例子，也是最能说明它设计意图的场景。

凌晨两点，你在故障频道里打一句话："上次见到这个报错是什么时候？"

一个盯着这个频道的 Agent 会去检索六个月的故障历史，把相关的讨论串、根因、当时的修复方案贴出来，然后问你要不要帮你把上次部署的那个人叫起来。

为什么在 Buzz 里能做成：因为提问、回答、证据全都留在同一个频道里，而且都在同一个搜索索引内。Agent 检索的不是"聊过的天"，而是和代码评审、工作流运行、审批决定同一类的事件。

现状：✅ 可用。relay、频道、讨论串、搜索、审计日志都已就绪。

场景 2：让 Agent 分诊 Bug，但不给它整个王国的钥匙

这个场景解决的是所有人用 Agent 时最纠结的事：想让它干活，又怕它权限过大。

Buzz 的解法是把权限问题换成身份问题 —— Agent 有自己的密钥、自己的频道成员资格、自己的审计轨迹。按身份划定范围，而不是按权限开关，就像你给一个同事划定范围一样。

官方给的 Agent 角色分工表很具体，每个角色都标了它盯什么事件、做什么事：

• 分诊（Triage）：盯 issue 事件 → 打标签、指派、识别重复、预筛
• 评审（Review）：盯补丁事件 → 第一轮代码评审、风格检查、依赖审计
• 文档（Docs）：盯 ref 更新 → 合并后同步文档
• 合并协调（Merge coordinator）：盯 CI 结果 → 跑合并列车，请求人类签字
• 编码（Coding agent）：盯任务事件 → 实现任务、提交补丁待审

更进一步的是所有者背书机制（NIP-OA）：Agent 通过 NIP-OA 从所有者那里继承访问权。relay 会检查这次 push 是否带有效的 NIP-OA 认证标签、标签里的所有者公钥是否在允许推送的名单里。这意味着 —— 加一个维护者，他名下所有被授权的 Agent 立刻能推送；移除一个维护者，他名下所有 Agent 立刻失去权限。Agent 自己的公钥不需要单独列进名单。

现状：🔶 部分可用。Agent 身份、密钥、审计、角色分工都在，但工作流的"审批门"还没接线完（见场景 6）。

场景 3：功能分支就是一个房间

这个场景我觉得是整个项目最有想象力的部分。

你建一个功能分支，Buzz 就自动建一个频道。这个分支的补丁、评审意见、CI 结果、合并决定，全都住在这个频道里。合并之后，频道归档，这段对话就成了"这段代码为什么存在"的永久记录。

官方给的样子是这样的：

#feat-auth-fix
├── 🧑 alice: "开始实现 OAuth2 PKCE"
├── 🤖 ci-agent: "构建已触发 — commit a1b2c3d"
├── 🤖 ci-agent: "✅ 全部 47 个测试通过 (12.3s)"
├── 📎 kind:1617 补丁 — src/auth/pkce.rs (+120 行)
├── 🧑 bob: "第 45 行错误处理有个小意见"
├── 📎 kind:1617 补丁 v2 — 已处理评审意见
├── 🤖 review-agent: "LGTM — 错误变体与 trait 规范一致"
├── ✅ bob: 审批事件 (kind:46011)
├── 🔀 已合并到 main — kind:1631
└── 📦 频道已归档

换句话说：频道本身就是那个 Pull Request、那个 CI 面板、那个讨论串。不用在 issue 跟踪器、CI 面板、聊天工具和代码评审之间来回切标签页。

现状：🔶 混合。消息、频道、画布、媒体、搜索今天就能用，git 托管也已经上线（标准 Smart HTTP，直接 git clone / git push）；但"分支自动映射成频道"的项目绑定层还在设计阶段。

场景 4：一份自己写自己的发布说明

工作流在打 tag 时触发。一个待在 #releases 频道里的 Agent 去读各个项目频道里已合并的补丁，起草发布说明，发出来给人评审，收到一个 👍 回应后发布。每一个步骤都签名，每一步都可搜索。

这个场景的价值不在于"省了写 release notes 的时间"，而在于发布说明天然就是准确的 —— 因为它读的是真正合并进去的补丁，而不是某个人回忆里合并了什么。

现状：✅ 工作流引擎（YAML、消息/回应/定时/webhook 四种触发器、执行轨迹）今天可用；Agent 读写频道、画布、工作流的 MCP 工具也在。

场景 5：把 CI 结果、审批和证据放在同一个地方

Buzz 的工作流是"YAML 即代码"，而且有个细节设计得很好：工作流定义放在仓库的 .buzz/workflows/ 里，或者定义在项目层被每个分支频道自动继承 —— 不用每个分支复制粘贴一遍 YAML。

name: CI
trigger:
  on: diff_posted
steps:
  - id: build
    action: call_webhook
    url: "https://ci.internal/build"
  - id: test
    action: call_webhook
    url: "https://ci.internal/test"
    if: "steps.build.output.status == 'success'"
  - id: gate
    action: request_approval
    message: "CI 通过，可以合并了吗？"
    if: "steps.test.output.status == 'success'"

有个设计取向值得注意：relay 是消息总线，不是构建服务器。工作流负责编排，真正的构建任务由 Agent 在自己的基础设施上跑 —— 你的服务器、云函数、甚至你的笔记本 —— 结果回帖到分支频道。

另外，审批事件由维护者的密钥签名，合并状态引用这个审批，审计日志把它们串起来 —— 形成谁批准了什么的密码学证明。

现状：🚧 这里是 Buzz 目前最明显的一个缺口。官方自己写得很清楚：审批门的数据库表、REST 接口、MCP 工具和 UI 都已经有了，但执行器还没有持久化审批令牌、也不能挂起执行 —— 跑到 request_approval 这一步的运行会被标记为失败（内部编号 WF-08）。基础设施在，接线没完。

场景 6：语音讨论，Agent 也能进来

Buzz 内置了实时语音（叫 Huddle），走的是内建在 buzz-relay 里的 WebSocket Opus 中继，**不需要外挂 SFU**。它用 NIP-42 认证参与者，把人放进房间，然后在参与者之间转发 Opus 帧。

有意思的是：Agent 加入的是和人类同一个音频中继，它们自带语音识别和合成。语音房的开始、加入、离开、结束也作为 Nostr 事件流动。

不过要提醒：录音和分轨发布还是"计划中"。

现状：✅ 语音、房间生命周期、生命周期事件已接通；录音待做。

场景 7：一个人跑多个客户 / 多个项目，互不串味

Buzz 有个"社区（community）"的概念，就是租户边界：一个工作空间、一个 URL、一套独立的频道、成员、资料、私信、仓库和搜索。

关键设计是这条：URL 就是社区。每次连接在任何请求执行之前，先绑定到它 host 对应的社区；未知的 host 会被直接拒绝，绝不会默认落到邻居家。而且官方说这个隔离不是嘴上说说 —— 多租户 relay 规范用 TLA+ 机械化验证了隔离性、用 Tamarin 验证了授权，每一条保证都做了变异测试。

身份模型上还有个细节：密钥对是你跨社区通用的，但资料是每个社区各存一份。你加入一个新社区时要重新发布一次自己的资料，因此不会跨社区泄露"你是谁"或"你在跟谁私信"。

对外部人也友好：访客（投资人、记者、合作伙伴）拿到的是一个限定频道的 scoped token，访问模型和所有人一样，不需要为他们单独开一套权限体系。

现状：✅ 单社区部署（大多数运营者跑的模式）等同于今天的 Buzz relay；多租户模式在同一套 OSS 代码里。

场景 8：可选的共享算力

这是 Buzz Mesh：relay 社区可以把成员"自愿加入"的硬件池化成共享 AI 算力。已有的 Agent 会把它当作一个本地 OpenAI 兼容的 provider 来看 —— relay 用同一套成员模型来控制发现和信任。单机跑不动的大模型可以拆到几台机器上跑。

对小型团队来说这是个挺实际的想法：不用为了跑一个本地模型去买一张大卡，把几个人的机器凑一下。

现状：✅ 按 VISION.md 的状态表，Mesh 已标记为可用（基于 iroh 的 mesh-llm）。

场景 9：远程 Agent —— 机器可替换，身份不丢

Agent 的身份、历史、在线状态都存在 relay 上，所以跑它的那台机器是可替换的。桌面端可以通过可替换的 provider 二进制把 Agent 部署到远程基础设施上；部署之后它不再保留对底层的控制通道 —— 状态、操控、关闭全部走 relay，Agent 自己限定自己的生命周期。

现状：📋 设计中。基于 provider 的远程部署（Kubernetes 优先）规范在评审中。

四、把"能用 / 不能用"摊开说

这是我认为这个项目最值得称赞的一点：它自己在 README 里放了一张三档状态表，还写了句"在你把合规方案建立在这部分之前，请看第三列"。

✅ 今天就能用：

• relay、频道、讨论串、私信、画布、媒体、搜索、审计日志
• 桌面客户端（Tauri + React）
• buzz-cli（agent-first，JSON 进 JSON 出）+ ACP 适配层，支持 Goose、Codex、Claude Code
• YAML 工作流：消息 / 回应 / 定时 / webhook 四种触发器
• Git 事件（NIP-34：补丁、仓库公告、状态）与 git 托管后端
• 语音房 + 生命周期事件

🚧 正在接线：

• 移动端（iOS + Android，Flutter 编写）
• 工作流审批门 —— 基础设施在，胶水还没干
• 语音房生命周期事件

💭 只有强烈观点、还没有代码：

• 跨 relay 的信任网络声誉系统
• 推送通知
• 文化功能（自定义 emoji、/ship 放彩带、原生投票、咖啡轮盘、Kudos、AI 提议摘要由人批准后钉成文档）

另外从 VISION_PROJECTS.md 的"forging 层"状态表看：git 托管今天就能用，但合并列车、项目绑定、NIP-34 issue、信任声誉系统都还只是"已设计"。官方对这块的总结很坦诚：协作平台已经建好，git 托管也已上线，上面的 forge 层是接下来的工作。

五、怎么跑起来：三条路径

路径 A：我只想试试这个 App。 从 release 页下载打包好的客户端：macOS 有 Apple Silicon 和 Intel 两个 dmg，Linux 有 AppImage 和 deb，Windows 有 x64-setup_alpha-unsigned.exe。默认连 ws://localhost:3000，想连别的 relay 就在启动前设 BUZZ_RELAY_URL，或者在 App 里切换。

路径 B：我想要自己的 relay，但不想管服务器。 官方提供 Railway 一键部署（仓库 README 里有按钮），配套教程在 Block 的工程博客上。

路径 C：从源码构建 / 自托管。 需要 Docker 和 Hermit（或自己准备 Rust 1.88+、Node 24+、pnpm 10+、just）：

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit   # 锁定工具链，首次使用时自动下载
just setup && just build

# 之后每天：
. ./bin/activate-hermit
just dev   # 同时启动 relay 和桌面端

想要单节点 / VPS 部署而不是本地开发栈，用 deploy/compose/ 里的生产 Compose 包（docker compose + Postgres、Redis、MinIO，可选 Caddy/TLS）。仓库里还有 Kubernetes 的 Helm chart。

给 Agent 用的话，设好 BUZZ_PRIVATE_KEY，然后调 buzz-cli —— 它是为 LLM 工具调用设计的，标准输出只有 JSON。

三个容易踩的坑：

• Windows 构建没有代码签名，首次启动会弹 SmartScreen 的"Windows 已保护你的电脑"，需要点"更多信息"再点"仍然运行"。
• Windows 上 Agent 的 shell 工具需要 bash，得装 Git for Windows（自带 Git Bash）。不想用它的话可以设 BUZZ_SHELL 指向别的 bash 兼容 shell。
• 最容易被忽略的一条：它目前不做端到端加密。 传输层是 TLS，静态加密交给存储层（比如 Postgres TDE、卷加密），服务端托管的加密覆盖所有频道和私信 —— 好处是 eDiscovery 能覆盖全部内容；代价是服务端能看到明文，端到端加密（NIP-44）只在私信上作为"未来考虑"。如果你的合规要求是真·端到端，这一条必须先在评估表上划掉。

六、架构与身份模型（给要看细节的人）

后端是 Rust 的 Cargo workspace，33 个 crate 各司其职。客户端是 Tauri 2 + React 19 的桌面应用，relay 另外还提供一个浏览器 Web 客户端（就是 myproject.com 上的仓库浏览界面）。

数据层三个组件：Postgres（事件 + 全文检索）、Redis（pub/sub、在线状态、正在输入）、S3/MinIO（媒体，走 Blossom 协议）。

身份上，人和 Agent 拿到的东西完全一样：

• secp256k1 密钥对（Nostr 原生）
• 形如 alice@example.com 的 NIP-05 标识
• 人类走 NIP-42 Schnorr 认证，Agent 走 NIP-98
• Agent 在频道成员里有机器人角色标识

一条事件长这样：id（规范字节的 sha256）、pubkey、kind（唯一的开关）、tags、content、sig（Schnorr 签名）。需要新的消息类型？加一个新的 kind 整数就行，零破坏性变更。

它还专门为业务场景提了一批自定义 NIP（我数了下 docs/nips/ 下有 18 份 NIP 文档），包括工作流、任务派发、项目多仓库绑定、审计哈希链等。同时它有一条很克制的原则：能复用标准 kind 就绝不自造 —— git 状态用 NIP-34、评论用 NIP-22、频道用 NIP-29、HTTP 认证用 NIP-98、制品用 NIP-94，全部对齐社区标准。

为什么这件事重要？官方给了答案："If Buzz disappears tomorrow, your repos still work on gitworkshop.dev, your patches still work with ngit-cli, your identities still work on any nostr client."（如果 Buzz 明天消失了，你的仓库在 gitworkshop.dev 上照样能用，补丁在 ngit-cli 上照样能用，身份在任何 Nostr 客户端上都照样能用。）集中式部署，去中心化协议。

七、它自己声明不是什么

这一节是我认为最该原样转述的，因为它挡住了一大半误解：

• 不是区块链。 原话："Signed events are useful without making everyone buy a commemorative coin."（签名事件很有用 —— 但不需要让每个人都去买个纪念币。）
• 不是要用 AI 取代人的计划。 "Buzz 在人留在环里、Agent 留在房间里时表现最好。"
• 没做完。 "我们会告诉你什么能用、什么不能用。"

八、搜 "buzz" 之前，先认清楚是哪一个

GitHub 上名字含 buzz 的仓库有 56,958 个。最容易撞车的是这几个：

• block/buzz（35,411★，Apache-2.0，Rust，2026-03 建仓）—— 本文主角，Block 的人机协作工作空间
• chidiwilliams/buzz（21,796★，MIT，Python，2022 年建仓）—— 这个是本地语音转文字工具，跟 Block 的项目毫无关系。两者的 star 数和知名度都在同一量级，是最容易搞混的一个
• kriswallsmith/Buzz（1,916★，MIT，PHP，2010 年）—— 老牌 PHP HTTP 客户端库
• buzz-language/buzz（1,532★，MIT，Zig，2021 年）—— 一个编程语言
• 以及 EnterpriseQualityCoding/FizzBuzzEnterpriseEdition（23,882★）这类"整活"项目，还有 google/buzzer 等

所以：如果你要的是"人和 AI 一起干活的工作空间"，是第一个；如果你要的是"把录音转成字幕"，是第二个。

九、客观地说，现在用它意味着什么

1. 它还很年轻，而且自己承认没做完。 3,619 个未关闭 issue 不是小数目。建仓到 2 万 star 只用了大约 5 个月（到 3.5 万约 7 个月），这个速度说明关注度高，也说明很多地方还在快速变动。
2. 核心的"forge 层"还在路上。 如果你想找的是"GitHub 替代品"，现在拿到的是 git 托管 + 事件模型，而合并列车、issue 系统、项目绑定、信任声誉都还是"已设计"。今天的实际体验更接近"一个内置了 git 的团队工作空间"。
3. 审批工作流暂时会失败。 跑到 request_approval 的流程会被标记失败，这是已知问题（WF-08），不要把它当成现成的审批系统去用。
4. 端到端加密不在当前范围内。 见上文第五节最后一条，这是企业评估时最该先确认的一项。
5. 它的"文化功能"名单挺有意思。 自定义 emoji、/ship 撒彩带、原生投票、咖啡轮盘这些被官方列为"ship blocker"（发布阻塞项）而不是锦上添花 —— 作者的判断是：远程协作工具里，这些非正式互动不是装饰，是团队凝聚力的基础设施。这个态度本身就挺值得琢磨。

十、一句话总结

Buzz 想解决的不是"聊天工具不好用"，而是一个团队的工作被切碎在七个互不相识的工具里：让聊天、代码、评审、CI、发布、搜索、乃至 AI Agent，都变成同一条签名事件日志里的条目，跑在你自己拥有的 relay 上。它最有现实价值的三个场景是事故复盘的可追溯、分支即房间的研发闭环、以及给 Agent 划分权限时的身份模型；而它自己列出的三档状态表才是你决定要不要现在就用的唯一依据 —— 别把"已设计"当成"已实现"。

参考来源

• block/buzz 官方仓库 README、VISION.md、VISION_PROJECTS.md、VISION_AGENT.md、VISION_SOVEREIGN.md、ARCHITECTURE.md（引用与结构统计）
• 仓库结构实测：GitHub Trees API（git/trees/main?recursive=1，5,464 个文件），2026-10-02 查询 —— 33 个 crate、27 个 workflow、18 份 NIP 文档、11 份 VISION 文档
• 仓库元数据与发布记录：GitHub REST API（star、fork、issue、许可证、建仓与推送时间、release 列表与资产大小），2026-10-02 查询
• 产品官网：buzz.xyz（Block 的早期体验入口）
• 同名辨析：GitHub 搜索接口（q=buzz+in:name，命中 56,958 个仓库）

本文为项目解读，信息取自上述官方仓库、官方文档与官方接口在 2026 年 10 月 2 日的公开内容，未在本地安装实测。Buzz 处于快速迭代期，功能状态、版本号与 star 数变化很快，请以官方页面为准。文中引用的第三方中文资料对其定位的概括与官方文档存在出入，已在正文中逐条对照。