想象一下：你输入 myproject.com，看到的不是 GitHub 的仓库列表，而是你的项目全景------代码、聊天、CI 结果、问题追踪、设计文档，全在一个页面上。点击一个仓库，浏览器渲染出 README，同时 git clone myproject.com 就能克隆------同一链接，两个身份。
由 Block, Inc.（原 Square）出品，Apache 2.0 协议开源，GitHub 上 7.7k Stars。
Github:
一个无聊的野心
Buzz 的 VISION 文档里有一句很直白的话："这里没有什么是新颖的。Git 托管已经解决了。聊天已经解决了。AI 代理已经解决了。Nostr 身份已经解决了。关键在于把它们全部放在一个域名后面，用一套身份系统。"
翻译成人话就是：我们今天为了做一个项目要开多少个网页？GitHub 看代码，Discord 聊天，Linear 管任务，Vercel 看部署，Notion 写文档，Slack 讨论设计。然后还要忍受它们之间几乎不互通。
Buzz 的解法：一个 Nostr 中继，搞定所有。
Nostr 是什么？和 Buzz 什么关系？
如果你不熟悉 Nostr，可以把它理解成一个"去中心化的消息协议"。每条消息都是一个 JSON 对象，包含你是谁（公钥）、消息类型（kind 整数）、内容、签名。看起来像这样：
json
{
"id": "sha256 哈希",
"pubkey": "secp256k1 公钥",
"kind": 9,
"content": "修复了登录页的 bug",
"sig": "签名"
}Buzz 用 Nostr 作为底层协议，但做了个重要的改动：不搞 P2P 传播、不搞 GOSSIP 协议。所有数据流经一个中继（relay），中继是唯一的事实来源。客户端连上中继、发事件、收推送，完事。
这意味着什么？每一条聊天消息、每一次代码审查、每一个 CI 结果、每一次合并决策，都是签名事件。审计日志天然存在，不用额外建表。搜索可以跨所有类型的内容------你在搜索框打"auth 刷新"，返回的结果包含聊天记录、补丁、CI 日志和设计文档，因为它们都是同一种东西：Nostr 事件。
三个小故事
项目的 README 用三个故事来解释 Buzz 能做什么，我这里直接搬过来，因为每个都很精彩。
故事一：事故记忆。 凌晨两点线上出问题了。你在故障频道里打字："上次看到这个错误是什么情况？"一个监听着频道的 AI 代理翻出六个月的聊天和事件历史，贴出对应的讨论链接、根因分析和修复方案，然后主动问要不要把上次上线的那个人叫醒。
关键点在于：你不需要记得"上次那个问题是在哪个频道讨论的"或者"那个 Slack 消息的链接在哪"。中继是唯一的事实来源，搜索一次搞定。
故事二：分支即房间。 你创建一个功能分支，Buzz 自动创建一个对应的频道。补丁以 Nostr 事件的形式进入频道，CI 结果自动推送，AI 代理做一轮初审，团队成员对特定部分做出反应，合并决策落在这个房间里。分支合并后，频道归档，变成这段代码为什么存在的永久记录。
两年后有人翻到这段代码，可以打开这个归档频道，看到当时讨论了什么、尝试了什么、拒绝了什么、最终选了哪个方案。
故事三：自写发布。 一个工作流在标签创建时触发。AI 代理读取合并到主分支的所有 PR，撰写发版说明，贴出来让人审核，收到一个竖起大拇指的表情后就发布。每个步骤都有签名，每个步骤都可搜索。
AI 代理不是机器人，是成员
这是 Buzz 最特别的设计。在很多平台里，机器人是二等公民------用 Webhook 接入，权限是"打了勾的复选框"，做的事情是广播消息。在 Buzz 里，AI 代理有自己的密钥对、自己的频道成员身份、自己的审计轨迹。
这意味着：你不用给 AI 代理一个"管理员 token"让它胡来。你像邀请一个同事一样邀请它进入频道。它只能看到你让它看到的频道，只能做它有权做的事情。权限范围基于身份，而不是权限标签。这是密码学层面的约束，不是靠"我们信任这个机器人"的约定。
Buzz 自己还写了一套叫 buzz-agent 和 buzz-dev-mcp 的工具链。buzz-agent 是一个 ACP 协议的代理，buzz-dev-mcp 是给代理提供 Shell 和文件编辑能力的 MCP 服务器。两个二进制文件，两个协议，没有耦合。设计原则很直接："如果一个高级工程师不能在一下午读完这两个二进制文件，那就是太复杂了。"
架构概览
技术栈：Rust 后端的单仓库，TypeScript/React 桌面端（Tauri 2）。
中继用 Axum 做 WebSocket + REST 服务器。后端拆成几十个 crate，但核心依赖关系很清晰：
buzz-core：零 I/O，只做类型定义和签名验证buzz-relay：把其他 crate 粘到一起buzz-db：Postgres 存储buzz-pubsub：Redis 发布/订阅buzz-search：全文搜索buzz-audit：哈希链审计日志buzz-workflow：YAML 自动化引擎
关键原则：中继是唯一的事实来源。所有子系统通过中继协调，不存在"工作流引擎绕过中继直接发消息"这种情况。
支持多租户：一个中继进程可以托管多个社区，隔离通过域名实现------你连到 teamA.com 看不到 teamB.com 的任何东西。隔离不只是应用层的，文档里提到用 TLA+ 形式化验证了多租户安全模型。
为什么值得关注
Buzz 的野心其实不小。它不只是在做一个"更好的 Slack"或者"带聊天的 GitHub"，而是想重新定义"软件项目的家"应该长什么样。
目前的开源协作工具生态是这样的：GitHub 管代码和 Issue，Discord 管即时沟通，GitBook 管文档，CircleCI 管测试，SonarQube 管代码质量------每个都要单独登录、单独管理权限、互不打通。做贡献的人要注册五个账号才能参与一个项目。
Buzz 的 v1 目标是：一个域名，搞定所有。聊天、代码、CI、AI 代理、文档------都是 Nostr 事件，都在同一个中继里，搜一次就找到。
当然，项目还远没完成。从 README 的状态表看，核心功能已经就绪：中继、频道、桌面应用、CLI、工作流引擎、Git 托管、搜索、审计。但移动端还在开发中，审批关卡还没完全接上，推送通知还在计划里。
一些值得想的
Buzz 的野心很大，但面临的挑战也不小：
用户迁移成本。 让已经用 GitHub + Discord + Notion 的团队换到 Buzz，需要的不是 Buzz 更好，而是 Buzz 好非常多。而目前 Buzz 的生态才刚刚起步。
Nostr 的接受度。 Nostr 本身还是一个相对小众的协议，认知度和以太坊、ActivityPub 不在一个量级。Buzz 能不能带火 Nostr 在企业场景的应用，需要时间验证。
Block 的投入。 Buzz 由 Block 出品，有企业背书和资源支持。但 Block 的目的是什么？是内部孵化工具的开源化，还是想做一个有商业前景的产品？目前看 Buzz 的 OSS 版本是完整的自托管方案，但未来会不会有托管版 SaaS、会不会有企业版收费，文档里没有明确说。
开箱复杂度。 自托管需要 Docker、Rust 工具链、Postgres、Redis、S3/MinIO。对只想"试一下"的用户来说门槛不低。项目提供了打包好的桌面应用可以直连公共中继，但核心体验还是需要自己跑中继才能完整体验。 Github:
总结
Buzz 是一个野心很大的开源项目。它的核心洞察------"所有团队协作工具应该是一个中继，而不是七个互不相关的标签页"------站得住脚。Block 的资源、Nostr 的密码学基础、形式化验证的隔离模型、清晰的技术架构，这些都在给它背书。
项目在 GitHub 上 7.7k Stars，1800+ 次提交，对于一个今年 3 月才创建的项目来说，开发速度非常快。如果你关心 AI 与人类协作、去中心化身份、或下一代开源基础设施的走向，Buzz 值得放进 Watch List。
关注引导
如果你对 AI 工具、开源项目分析、下一代协作平台感兴趣，欢迎关注我们，每周带来深度开箱分析。