开源项目第167期：Buzz — Block 开源的人机协作工作空间，Agent 是成员不是 Bot

Cheson_chen

91人浏览 · 2026-07-26 17:28:52

Cheson_chen · 2026-07-26 17:28:52 发布

引言

“A workspace where humans and agents build together, on a relay you own.”

这是「每日一个开源项目」系列的第 167 篇。今天的项目是 Buzz —— Block Inc.（旗下有 Square、Cash App、TBD）开源的自托管团队工作空间，基于 Nostr 中继协议构建，让人类和 AI agent 共享同一个房间。

大多数 AI agent 集成方式是：在 Slack/Teams 里加一个 bot，bot 看到 @mention 就回复，别的时候什么都干不了。Buzz 的出发点是：为什么 agent 的能力边界要比人类成员小？如果 agent 能审查代码、触发工作流、打开频道、叫人来开会 —— 和人类成员做同样的事，用同样的身份系统和审计轨迹 —— 那团队协作会变成什么样？

12,390 颗 Star，2026 年 3 月创建，Apache 2.0。

你会学到什么

Buzz 为什么建在 Nostr 协议上，以及这意味着什么
Agent 作为「正式成员」（而不是 bot）的实现机制
三个典型场景：事故记忆、分支即房间、自动写发布说明
buzz-cli 和 ACP 适配器：如何把 Claude Code 接入 Buzz
架构：Rust crate 地图，Postgres + Redis + MinIO 数据层
现在能用的 vs 还在接线 vs 强烈想法但代码还没写

前提知识

了解团队协作工具的基本概念（频道、消息、工作流）
对 AI agent 工具调用的基本认知
了解 Git 基础操作

项目背景

概述

Buzz 是一个自托管的团队工作空间，技术底层是一个 Nostr 中继：消息、反应、工作流步骤、代码审查批准、Git 事件 —— 全部是同一个签名事件日志里的事件。同样的格式，同样的身份模型，同样的审计轨迹，无论作者是人还是程序。

项目信息

作者/公司: Block, Inc.（Elie Habib 等）
主语言: Rust（后端）+ TypeScript（桌面 UI）
许可证: Apache-2.0
桌面应用: Tauri + React

项目数据

⭐ GitHub Stars: 12,390+
🍴 Forks: 996+
📄 许可证: Apache-2.0
📅 创建时间: 2026-03-06

快速启动

需要 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

just setup 自动运行 just bootstrap：复制 .env.example，下载工具，启动 Docker 服务 + 数据库迁移。

每天开发：

. ./bin/activate-hermit
just dev   # 同时启动中继 + 桌面应用

中继跑在 ws://localhost:3000，桌面应用自动弹出。

如果想分屏工作（中继日志和 Vite 输出分开）：

# 终端 1
just relay

# 终端 2
just desktop-dev

核心设计：一切都是事件

为什么选 Nostr 协议

Buzz 的技术核心是一个 Nostr 中继（NIP-01 / NIP-42）。这个选择有几个深层含义：

统一身份模型：人类用 Schnorr 密钥对签名，AI agent 也用 Schnorr 密钥对签名。身份不是角色或权限标志，而是密码学身份 —— agent 是「另一个密钥对的持有者」，而不是「被授权的 bot」。
统一事件日志：一条消息、一个 emoji 反应、一次工作流触发、一个 PR 审查批准、一个 CI 状态 —— 都是同一个事件日志里的事件，同样可搜索，同样有审计轨迹。
Git 原生集成（NIP-34）：Git 补丁、仓库公告、状态事件都通过 NIP-34 发布到中继，意味着代码变更和关于它的讨论在同一个地方。
可自托管：中继是你自己的，数据不出门。

Agent 是成员，不是 Bot

这是 Buzz 最核心的设计主张。

传统团队工具里的 bot：

有特殊 bot 账号类型
只能响应特定触发器（@mention、webhook）
能做的事是人类能力的一个受限子集
审计轨迹和人类分开记录

Buzz 里的 agent：

有自己的 Nostr 密钥对（就像人类成员一样）
有自己的频道成员资格
能做人类成员能做的所有事：发消息、创建频道、编辑 Canvas、触发工作流、进入语音 huddle、打开代码仓库、发补丁、审查代码、编排其他 agent
审计轨迹和人类的在同一个日志里，用密钥签名区分

用项目自己的话说：「Agents have the same surface area as humans, with their own keys and their own audit trail.」

三个典型场景

README 里有三个场景，值得完整引用，因为它们具体说明了这个设计理念在实践中意味着什么：

场景 1：事故记忆

凌晨 2 点。你输入「我们之前见过这个错误吗？」。一个监视频道的 agent 拉取六个月的历史，发布相关线索、根本原因、修复方案，并提议叫上最后提交这段代码的人。整个交流 —— 问题、答案、证据 —— 留在频道里。

这个场景解决的问题：事故记忆通常散落在不同工具里（Slack 对话、Jira ticket、PagerDuty alert、代码注释），没有人能在凌晨 2 点快速关联。当一切都在同一个事件日志里，agent 的「搜索六个月历史」就不是跨系统 API 调用，而是查同一个索引。

场景 2：分支即房间

你打开一个功能分支。一个频道出现了。补丁以 NIP-34 事件形式落地，CI 发布结果，agent 运行初次代码审查，队友对他们关心的部分 emoji 反应，合并决策落在和证据相同的房间里 —— 所以频道就是代码存在原因的记录。

传统 PR 流程的问题：为什么这个 PR 存在的决策讨论在 Slack，PR 本身在 GitHub，CI 在另一个工具，部署审批在再另一个工具？Buzz 的答案是：它们都是事件，都属于同一个频道。

场景 3：自动写发布说明

一个工作流在 tag 上触发。agent 读取项目频道里合并的 PR，起草发布说明，发布供人工审查，得到一个 👍 反应，然后发布。每个步骤都签名，每个步骤都可搜索。

注意「👍 反应就是审批门」这个设计 —— 不是特殊的审批 UI，不是独立的审批工具，就是频道里的一个 emoji 反应，因为它也是一个签名事件，可以被工作流监听。

Agent 接入：buzz-cli 和 ACP 适配器

buzz-cli

buzz-cli 是专门为 AI agent 设计的命令行工具：JSON 输入，JSON 输出，为 LLM 工具调用优化。

# 设置 agent 的 Nostr 私钥
export BUZZ_PRIVATE_KEY=nsec...

# 之后 buzz-cli 就是这个 agent 的身份

设计原则：所有命令的 I/O 格式对 LLM 工具调用友好，不输出人类可读但难以解析的格式。

ACP 适配器（buzz-acp）

Buzz 提供了一个 ACP（Agent Communication Protocol）适配器，让以下 AI coding agent 可以直接接入 Buzz：

Claude Code
Goose（Block 自己的 AI agent）
Codex

ACP 是 ACP ↔ MCP 的桥接层：buzz-acp 把 Buzz 的能力翻译成 MCP 工具，让支持 MCP 的 agent 可以直接调用。

buzz-dev-mcp

buzz-dev-mcp 是一个 MCP 服务器，提供：

Shell 工具（在 buzz 上下文里执行命令）
文件编辑工具

这让 Claude Code 等工具在 Buzz 频道里工作时，可以用熟悉的 MCP 工具调用模式操作文件和运行命令。

架构深度解析

系统架构

┌────────────────────────────────────────────────────────────┐
│                         客户端                             │
│  人类客户端            AI agent          CLI / 脚本        │
│  (Buzz 桌面)     (Goose/Codex/Claude)   (buzz-cli)         │
│      │            ┌─────────────┐             │            │
│      │            │  buzz-acp   │             │            │
│      │            │ (ACP ↔ MCP) │             │            │
│      │            └──────┬──────┘             │            │
└──────┼───────────────────┼────────────────────┼────────────┘
       │ WebSocket          │ WS + REST          │ WS + REST
       ▼                    ▼                    ▼
┌────────────────────────────────────────────────────────────┐
│                       buzz-relay                           │
│  NIP-01 · NIP-42 认证 · 频道/DM/媒体/工作流/Git REST      │
│  审计日志                                                  │
└────┬───────────────────┬─────────────────┬────────────────┘
     │                   │                 │
  ┌──▼────────┐    ┌──────▼──────┐    ┌────▼──────┐
  │ Postgres  │    │    Redis    │    │  S3/MinIO │
  │(事件+FTS) │    │ (pub/sub)   │    │ (Blossom) │
  └───────────┘    └─────────────┘    └───────────┘

单一真相来源：中继。所有状态都通过中继流转，没有客户端本地状态和服务端不同步的问题。

Rust Crate 地图

核心协议层

buzz-core — 零 I/O 类型、NIP-01 过滤器、Schnorr 验签
buzz-relay — Axum WebSocket + REST 服务器

服务层

buzz-db — Postgres 数据访问
buzz-auth — NIP-42/98 Schnorr 认证 + 速率限制
buzz-pubsub — Redis pub/sub + presence + typing 状态
buzz-search — Postgres 全文搜索
buzz-audit — 哈希链审计日志

Agent 层

buzz-cli — agent 专用 CLI（JSON in/out）
buzz-acp — Goose/Codex/Claude Code 的 ACP 适配器
buzz-agent — ACP agent 实现
buzz-dev-mcp — shell + 文件编辑 MCP 工具
buzz-workflow — YAML 自动化工作流
buzz-persona — agent 人格包

Git + 配对

git-sign-nostr / git-credential-nostr — Nostr 签名的 Git
buzz-pair-relay / buzz-pairing-cli — 中继配对

多社区模式

一个中继默认托管一个 community（工作空间）。托管运营商可以用多域名/子域名为多个社区提供服务，但面向客户端的规则不变：URL 就是工作空间的权威标识，所有租户可见状态都以 community 为作用域隔离 —— 哪怕后端共享同一个 Postgres 和 Redis。

现在能用 / 正在接线 / 强烈想法但代码还没写

README 里这张表的诚实程度值得单独提：

✅ 现在能用	🚧 正在接线	💭 强烈想法，代码还没写
中继、频道、线程、DM、Canvas、媒体、搜索、审计日志	iOS + Android 移动端（Flutter）	跨中继信任网络
桌面应用（Tauri + React）	工作流审批门（基础设施在，胶水代码还在干）	推送通知
`buzz-cli` + ACP 适配器（Goose/Codex/Claude Code）		文化功能
YAML 工作流（消息/反应/计划/webhook 触发）
Git 事件（NIP-34：补丁、仓库公告、状态）
Git 托管后端