Block 开源 Buzz：Nostr 上的 AI 协作工作空间

7/23/2026开源AI开发者工具

Buzz 工作区截图：人类与 AI Agent 在同一频道协作

2026 年 7 月 23 日，Block（前 Square）开源了一个名为 Buzz 的项目。两天内 GitHub star 从两千多飙升至近 6000，日均增长 3252 颗，成为本周 GitHub Trending 增速最快的仓库。Buzz 的定位一句话概括：一个自托管的工作空间，让人类和 AI Agent 在同一个频道里干活。

不是又一个 Slack 替代品

Buzz 不是一个聊天工具，或者更准确地说，它不只是聊天。在它的架构里，每一条消息、每一次反应、每一个工作流步骤、每一次代码审查和每一个 git 事件，都是一个密码学签名的 Nostr 事件。人类和 AI Agent 使用同一套身份模型，拥有相同的密钥对，产生相同的审计轨迹。

这意味着 Agent 在 Buzz 中拥有和人类一样的频道成员身份——自己的密钥、自己的成员资格、自己的操作日志，而非挂在某个 API 后面的隐形服务。你可以像添加一个人一样把 Agent 加进频道——它有自己的密钥、自己的频道成员资格、自己的操作日志。当它做错了什么，你可以从审计链上追溯到具体是哪个 Agent、在什么时间、做了什么操作。

Block 在 README 中用了三个场景描述这个模型：

  • 事件记忆：凌晨两点遇到线上故障，在频道里问「上次遇到这个错误是什么情况」，Agent 会搜索六个月的历史记录，返回相关讨论、根因分析和修复方案，整个过程保留在频道里。
  • 分支即频道：创建一个 feature 分支，Buzz 自动创建一个频道。补丁、CI 结果、代码审查、合并决策全部发生在这个频道里。合并后频道归档，成为这段代码为什么存在的永久记录。
  • 自动发布：打 tag 触发工作流，Agent 读取已合并的 PR，起草发布说明，提交人类审查，获得 👍 反应后发布。每一步都有签名，每一步都可搜索。

底层协议：Nostr NIP-01

Buzz 的技术选型有些反直觉。大多数团队协作工具（Slack、Discord、Teams）使用自定义的 WebSocket 协议或 REST API，而 Buzz 选择了一个起源于去中心化社交领域的协议——Nostr。

Nostr 的核心是签名事件。每个事件包含六个字段：

id        sha256 of canonical bytes
pubkey    secp256k1 public key
kind      integer (the only switch)
tags      structured metadata
content   JSON payload
sig       Schnorr signature

Buzz 扩展了标准 Nostr 事件格式，使用自定义 kind 编号覆盖企业级功能。标准 Nostr kind（0-9999）用于通用消息和反应，Buzz 自定义范围（40000-49999）用于流消息 V2、论坛帖子、工作流执行等。添加一个新功能只需要定义一个新的 kind 编号，现有客户端不会受影响。

这个设计有几个实际好处：

  1. 统一审计：人类消息和 Agent 操作走同一条事件管线，经过相同的签名验证、存储、搜索索引和审计日志
  2. 协议级互操作：任何支持 NIP-29（中继群组）的 Nostr 客户端都可以直连 Buzz relay
  3. 身份可移植：密钥对不绑定平台，Agent 可以用同一个 npub 加入不同社区

架构：26 个 Rust crate

Buzz 的后端是一个 Rust workspace，包含 26 个功能聚焦的 crate：

类别crate职责
核心协议buzz-core零 I/O 类型定义、NIP-01 过滤器、Schnorr 验证
中继服务buzz-relayAxum WebSocket + REST 服务器
数据层buzz-dbPostgres 事件存储、频道、工作流
认证buzz-authNIP-42/NIP-98 Schnorr 认证、速率限制
消息总线buzz-pubsubRedis pub/sub、在线状态、输入指示
搜索buzz-searchPostgres 全文搜索
审计buzz-audit哈希链防篡改日志
Agent 接口buzz-cli、buzz-acp、buzz-agentAgent CLI、ACP 线束、ACP Agent
工作流buzz-workflowYAML 自动化引擎
Agent 开发buzz-dev-mcpShell + 文件编辑 MCP 工具
Git 集成git-sign-nostr、git-credential-nostrNostr 签名的 git 操作
媒体buzz-mediaBlossom/S3 存储

架构图很清晰：relay 是唯一的真实数据源（single source of truth）。所有读写都流经它，子系统之间不直接调用。buzz-workflow 不会调用 buzz-pubsub，buzz-search 不会调用 buzz-db——跨子系统协调只通过 relay 进行。

事件管线处理一条 [EVENT] 消息时经过 12 个步骤：认证检查 → 公钥匹配 → kind 拒绝 → 临时路由 → Schnorr 签名验证 → 频道成员资格检查 → 数据库插入 → Redis 发布 → 扇出 → 搜索索引 → 审计日志 → 工作流触发。其中搜索索引、审计日志和工作流触发是异步 fire-and-forget，不会阻塞事件提交。

Agent 系统：ACP + MCP

Buzz 的 Agent 层由两个独立的二进制文件组成，通过两个标准协议通信：

任何 ACP 客户端 (Zed, JetBrains, buzz-acp)
        │
        │ stdio ACP (JSON-RPC 2.0)
        v
  buzz-agent (最多 8 个并发会话)
        │
        │ stdio MCP (JSON-RPC 2.0) — 每个会话一个
        v
  buzz-dev-mcp (或任何 MCP 服务器)
        │
        v
  shell, str_replace, todo; rg + tree

buzz-agent 是一个 ACP（Agent Client Protocol）Agent，通过 stdio 与客户端通信，调用 LLM，使用 MCP 工具。支持最多 8 个并发会话，每个会话有独立的 MCP 服务器实例和历史记录。当上下文填满时，会话会自动总结自己的历史并继续。

buzz-dev-mcp 是一个 MCP 服务器，为任何 Agent 提供 shell 和文件编辑器能力。进程生命周期有界，输出有界，文件编辑相对于工作目录解析。

Block 选择自建而非使用现有 Agent 框架的理由是审计性：一个资深工程师可以在一个下午读完两个二进制文件的源码。当 Agent 做了意外的事情时，从症状到根因的路径很短。

分支即频道：Nostr 原生的代码托管

Buzz relay 可以托管 git 仓库。浏览器访问 myproject.com 看到项目主页，git clone 同一个域名即可克隆代码——标准 Smart HTTP 传输，git clone 和 git push 不需要特殊配置。你的 npub 签名推送，使用和频道消息相同的域名、认证和身份。

这个设计的核心概念是「分支即频道」。创建一个 feature 分支时，Buzz 自动创建一个频道：

#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
└── 📦 频道归档

分支保护规则存在仓库公告事件（NIP-34，kind:30617）中，relay 在 git 传输层强制执行。只有 push-allowed 列表中的 npub 可以推送到受保护分支。合并需要指定数量的签名审批事件才能接受推送。

Agent 通过 NIP-OA（所有者证明机制）继承访问权限。relay 检查：推送是否携带有效的 NIP-OA 认证标签，标签中的所有者公钥是否在 push-allowed 列表中。添加一个维护者，他所有授权的 Agent 都可以推送；移除维护者，所有 Agent 立即失去访问权限。

工作流引擎

Buzz 内置了一个 YAML 自动化引擎，支持四种触发方式：消息触发、反应触发、定时触发和 webhook 触发。工作流定义可以放在仓库的 .buzz/workflows/ 目录中，也可以在项目级别定义后被所有分支频道继承。

yaml
name: CI
trigger:
  on: diff_posted
steps:
  - id: build
    action: call_webhook
    url: "https://ci.internal/build"
    body: '{"commit": "{{trigger.commit}}"}'
  - id: test
    action: call_webhook
    url: "https://ci.internal/test"
    if: "steps.build.output.status == 'success'"
  - id: gate
    action: request_approval
    message: "CI passed. Approve merge?"
    if: "steps.test.output.status == 'success'"

工作流编排步骤，Agent 执行计算，relay 是消息总线而非构建服务器。推送触发 CI 工作流后，工作流引擎协调构建、测试、lint 步骤，Agent 在自己的基础设施上运行实际任务，结果发回到分支频道。每一步都被追踪，每条追踪记录都是签名事件。

多社区与隔离

Buzz 支持「多社区」部署模式。一个运营者可以在共享基础设施上托管多个社区，每个社区有自己的域名或子域名。URL 是社区的选择器：myproject.com 是权威的——所有连接在运行任何请求之前绑定到该域名对应的社区，未知域名被拒绝而非默认路由。

隔离是边界而非过滤器。共享基础设施的社区之间不可见——彼此的事件、个人资料、私信、搜索结果、审计链和错误字符串都隔离。Buzz 使用 TLA+ 和 Tamarin 形式化方法验证了多租户隔离规范，每个保证都有变异测试。

身份可移植但个人资料按社区隔离。你的密钥对在每个社区中都是你的，但你的个人资料、私信和频道无关内容存在于各个社区内。你将自己的人设转发到你加入的每个社区，不存在跨社区的泄露。

规模与现状

Buzz 的设计目标规模是 10,000 人类用户加 50,000 Agent，吞吐量约 60 万事件/天（平均 7/秒）。事件存储使用 Postgres 17 按月分区，全文搜索基于 Postgres FTS（权限感知），审计使用哈希链防篡改日志，Redis pub/sub 实现 <50ms p99 扇出。

目前可用的功能包括 relay、频道、线程、私信、画布、媒体上传、搜索和审计日志。桌面客户端（Tauri + React）支持七大界面：Home、Stream、Forum、DMs、Agents、Workflows、Search。移动客户端（Flutter，iOS + Android）正在开发中。

部分功能仍在接线中：工作流审批门的基础设施已就位（schema、REST 端点、MCP 工具、UI 全部存在），但执行器尚未持久化审批令牌或暂停执行——碰到 request_approval 步骤的运行会被标记为 Failed。Huddle（语音）的生命周期事件已连线，录音和按轨发布仍在计划中。

Block 的战略意图

Block 是 Jack Dorsey 旗下公司，旗下有 Cash App、Square、Tidal 等产品。Buzz 的开源和 Block 内部使用是同步的——Block 员工有独立的内部构建版本，预配置连接 Block relay 和 Agent 提供商。

这与 Block 此前在 Nostr 生态的投入一脉相承。Jack Dorsey 是 Nostr 协议的早期支持者，曾资助 Nostr 相关开发。Buzz 将 Nostr 从社交领域延伸到企业协作领域，用同一个签名事件协议统一了人类和 Agent 的交互模型。

Apache 2.0 许可证，Rust 后端，TypeScript/React 前端。完整的自托管路径需要 Docker + Rust 1.88+ + Node 24+ + pnpm 10+，just setup && just build 即可启动。

推荐阅读