Buzz：2 万 Star 的 Nostr 协作平台，人和 Agent 共用一个房间
看完你会发现，你之前的理解可能要更新了。
团队协作工具的现状是：聊天用 Slack，代码用 GitHub，CI 用 Jenkins，机器人用自定义脚本，搜索靠全局搜索，发布用专用工具--七个 tab 各管各的，中间靠一堆胶水代码假装它们认识彼此。
Block（就是 Square 改名那个）开源的 Buzz 想把这些全统一掉。不是再做一个 Slack，而是用 Nostr 协议把所有交互--人的消息、Agent 的操作、代码提交、CI 运行、审批--都变成同一种加密签名事件，存在同一个不可篡改的日志里。上线 5 个月，21000+ Star，Apache 2.0。
本文提纲
- Buzz 是什么
- 核心赌注：一个 substrate 替代七个 tab
- 七个 Surface：你日常需要的一切
- 人机同等身份模型
- Nostr 协议：一切皆签名事件
- Rust 后端：20+ crate 的模块化设计
- Agent 能力：不只是聊天，是干活
- 自部署与上手
Buzz 是什么
Buzz 是一个可自部署的协作平台，人和 AI Agent 在同一个房间里工作。
项目关键数据：
| 项目 | 值 |
|---|---|
| 仓库 | block/buzz |
| Stars | 21,572 |
| Forks | 2,325 |
| License | Apache 2.0 |
| 后端语言 | Rust (20+ crates) |
| 桌面端 | Tauri 2 + React 19 + TypeScript |
| 移动端 | Flutter (iOS + Android，开发中) |
| 协议 | Nostr (NIP-01 + 自定义 kind 40000-49999) |
| 创建时间 | 2026-03-06 |
一句话定位：一个社区用一条事件日志，人、Agent、工作流、代码仓库全说同一种协议。
核心赌注：一个 substrate 替代七个 tab
Buzz 的设计理念写在 README 里很直白：
One community can do what teams currently fake with chat, forges, bots, CI dashboards, release tools, search indexes, and a pile of glue code. Not all at once, not magically, but with one substrate instead of seven tabs pretending they know about each other.
不是再造一个 Slack，而是把 chat、代码托管、CI、bot、搜索、发布工具统一成一个事件日志。所有交互--无论来自人还是进程--都是同一种加密签名事件，存在同一个不可篡改的记录里。
这个设计的直接好处是搜索：对话、代码补丁、工作流运行、审批记录共享同一个搜索索引，因为它们都是同一种事件。你搜一个关键词，相关的讨论、代码变更、CI 结果、审批记录一起出来，不需要在七个工具之间跳来跳去。
七个 Surface：你日常需要的一切
Buzz 把协作场景拆成七个 Surface（界面）：
| Surface | 功能 | 类比 | 默认通知级别 |
|---|---|---|---|
| Home | 个性化信息流 | - | - |
| Stream | 主题实时聊天 | Slack | 零 |
| Forum | 异步长帖讨论 | Discourse | 零 |
| ✉️ DMs | 一对一和群聊（最多 9 人） | - | 仅紧急 |
| Agents | Agent 目录和任务看板 | - | - |
| ⚡ Workflows | YAML 代码化自动化 + 执行追踪 | GitHub Actions | 仅审批 |
| Search | 全文搜索所有事件 | - | - |
通知设计有个有意思的细节：默认通知级别是零。你要主动选择接收噪音，而不是被动关闭它。DMs 默认只在"紧急"时通知，Workflows 只在需要审批时通知。这和 Slack 那种"所有消息默认通知你直到你被逼疯"的设计完全相反。
人机同等身份模型
这是 Buzz 最核心的设计决策。
人和 Agent 拿到的是完全相同的身份基础设施：
- 一个 secp256k1 密钥对（Nostr 原生）
- 一个 NIP-05 handle
- NIP-42 Schnorr 认证（人用 WebSocket）或 NIP-98（Agent 用 HTTP）
- Agent 在频道成员关系里标记为 bot 角色
认证逻辑很简单：认证了或没认证。频道成员关系控制内容可见性。Agent 不是被"授予权限"的外部工具，而是社区的成员--和人有同样的操作面，有自己的密钥和审计轨迹。
这意味着你给 Agent 的不是"权限标志"（permission flag），而是和给人类同事一样的身份范围控制（scoping by identity）。Agent 能开仓库、发补丁、审查代码、跑工作流、编辑画布、编排其他 Agent、加入语音--和人能做的一模一样，只是用不同的密钥对。
Nostr 协议：一切皆签名事件
Buzz 的底层是 Nostr 协议。每一条交互都是一个加密签名的 JSON 事件：
{
"id": "<sha256 of canonical serialization>",
"pubkey": "<secp256k1 public key, hex>",
"kind": <unsigned integer>,
"tags": [["e", "<event-id>"], ["p", "<pubkey>"]],
"content": "<JSON payload or plain text>",
"sig": "<Schnorr signature over id>"
}
关键设计是 kind 字段：它唯一的分发开关。加新功能就是加新的 kind 数字。Buzz 在 Nostr 原有的 kind 范围基础上，用了 40000-49999 范围的自定义 kind 来实现企业功能。
Relay（中继服务器）是唯一的真相来源。没有 P2P 事件交换，没有 gossip 协议，没有副本复制。所有客户端通过 WebSocket 连接到 relay，relay 负责验证签名、持久化事件、扇出到订阅者、建立搜索索引。
Buzz 还扩展了 Nostr 的 Git 事件（NIP-34）：补丁、仓库公告、状态更新都是签名事件。这意味着代码审查和合并决策可以和讨论记录在同一个频道里--频道就是代码存在的理由的记录。
Rust 后端：20+ crate 的模块化设计
Buzz 的后端是一个 Cargo workspace，拆成了 20+ 个 crate，按职责分类：
| 类别 | Crate | 职责 |
|---|---|---|
| 核心协议 | buzz-core | 零 I/O 基础：类型、NIP-01 过滤器、Schnorr 验证 |
| 核心协议 | buzz-relay | Axum 服务器，把所有东西绑在一起 |
| 数据存储 | buzz-db | Postgres 事件存储 |
| 数据存储 | buzz-search | Postgres 全文搜索（GIN 索引 tsvector） |
| 数据存储 | buzz-media | Blossom/S3 媒体存储 |
| 认证安全 | buzz-auth | NIP-42 和 NIP-98 Schnorr 认证 |
| 认证安全 | buzz-audit | 哈希链防篡改审计日志 |
| 实时通信 | buzz-pubsub | Redis pub/sub、在线状态、输入指示 |
| 实时通信 | buzz-voice | 语音通话 Opus relay |
| 自动化 | buzz-workflow | YAML 代码化自动化引擎 |
| Agent | buzz-acp | Agent 通信协议 harness |
| Agent | buzz-agent | ACP agent 二进制（最多 8 个并发会话） |
| Agent | buzz-dev-mcp | MCP 服务器，带 shell 和文件编辑工具 |
| Agent | buzz-cli | Agent 优先的 CLI（JSON 输入输出，为 LLM 工具调用设计） |
| Git | git-sign-nostr | Nostr 签名的 git 提交 |
| Git | git-credential-nostr | Nostr git 凭证助手 |
最关键的架构约束是 buzz-core 明确禁止 I/O：不能依赖 tokio、sqlx、redis、axum。这是整个依赖图的架构支点，保证核心协议逻辑和基础设施完全解耦。
Relay 直接 import 所有子系统来编排它们，但子系统之间互相隔离--buzz-db 不知道 buzz-pubsub 的存在。这种设计让每个 crate 可以独立测试和替换。
Agent 能力：不只是聊天，是干活
Buzz 里 Agent 能做的事远超普通 bot：
问项目一个问题，拿到带证据的答案。Agent 搜索六个月的历史记录，把相关讨论、根因分析、修复方案整理成帖发出来--有据可查，不是凭感觉。
Agent 驱动的 bug 分拣。Agent 有自己的密钥、频道成员关系和审计轨迹，按身份范围控制而不是权限标志。
特性分支变成一个房间。补丁、CI、代码审查、合并决策都在一个频道里共存，频道本身就是代码存在的完整记录。
Agent 管理工作区。Agent 可以创建频道、编辑画布、跑工作流、加入语音--和人一样的操作面。
Agent 通信通过 ACP（Agent Communication Protocol）harness 桥接，支持 Goose、Codex、Claude Code。buzz-cli 是专门为 LLM 工具调用设计的 CLI，JSON 输入输出，Agent 可以直接调用。
工作流用 YAML 定义，支持四种触发器：消息、反应、定时、webhook。工作流执行有完整的 trace 追踪。
自部署与上手
方式一：下载桌面应用
GitHub Releases 提供打包构建：macOS (.dmg)、Linux (.AppImage/.deb)、Windows (.exe)。
方式二：一键部署到 Railway
https://railway.com/deploy/buzz-relay-block
方式三：Docker Compose 自部署
生产环境的 Compose bundle 在 deploy/compose/，包含 Postgres、Redis、MinIO 和可选的 Caddy/TLS。
方式四：从源码构建
需要 Docker、Hermit（或 Rust 1.88+、Node 24+、pnpm 10+、just）：
git clone https://github.com/block/buzz
just setup && just build
just dev
方式五：Agent 开发
需要 Rust 工具链和 buzz-cli。设置 BUZZ_PRIVATE_KEY 环境变量，用 buzz-cli 发 JSON 输入输出，专为 LLM 工具调用设计。
仓库里还有示例 bot 可以参考：countdown-bot 和 meadow-core。
当前实现状态
| 功能 | 状态 |
|---|---|
| Relay、频道、帖子、DMs、画布、媒体、搜索、审计日志 | ✅ 可用 |
| 桌面应用 (Tauri + React) | ✅ 可用 |
| buzz-cli + ACP harness (Goose/Codex/Claude Code) | ✅ 可用 |
| YAML 工作流（消息/反应/定时/webhook 触发） | ✅ 可用 |
| Git 事件 (NIP-34: 补丁、仓库公告、状态) | ✅ 可用 |
| 移动端 (Flutter iOS + Android) | 开发中 |
| 工作流审批门控 | 接线中 |
| 语音通话生命周期事件 | 接线中 |
| Git 托管后端 | 接线中 |
| Web-of-trust 跨 relay 信誉 | 规划中 |
核心功能已经可用，移动端和部分高级功能还在开发中。如果你想找一个能自部署、Agent 能真正干活（而不只是发消息）的协作平台，Buzz 值得试试。尤其是"人机同等身份"这个设计--Agent 不是被管理的工具，而是有自己密钥和审计轨迹的团队成员。
参考文档与链接
- GitHub: block/buzz - 21000+ Star，Apache 2.0，基于 Nostr 的人机协作平台
- Buzz Vision 文档 - 项目愿景和设计哲学
- 架构文档 - 系统架构和 crate 关系
- Agent 愿景 - Agent 能力设计理念
- Nostr 协议 (NIP-01) - Nostr 基础协议规范
- Railway 一键部署 - 一键部署 Buzz relay
- zread.ai: block/buzz - 架构概览和 crate 详细说明
- buzz-cli 文档 - Agent 优先 CLI 参考
你怎么看这个趋势？评论区聊聊你的判断。觉得有用点个赞让更多人看到。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。