一天一个开源项目

开源项目第175期：Buzz — Jack Dorsey 的 Block 用 Nostr 重新定义团队协作，AI Agent 拥有自己的加密身份

Block 于 2026 年 7 月 21 日发布的开源团队工作空间，人类和 AI Agent 在同一个 channel 里作为平等成员协作。基于 Nostr 协议，每个 Agent 持有独立加密密钥对，身份和历史可跨平台携带。Rust 后端 + Tauri 桌面端，支持 Claude Code、Codex、Goose 等 Agent。YAML 工作流引擎、buzz-cli（JSON in/out，面向 LLM 调用设计）、NIP-34 Git 集成。21.3k Stars，Apache 2.0，可自托管。

·约 11 分钟阅读·AI Tools
open-sourceworkspaceAI-agentNostrcollaborationRustTauricryptographyJack-DorseyBlockClaude-Codeworkflow

引言

"不是 Agent 辅助人类，而是 Agent 和人类在同一个房间里工作。"

这是「每日一个开源项目」系列的第 175 篇。今天的项目是 Buzz —— Block（Jack Dorsey 创立的公司）于 2026 年 7 月 21 日发布的开源团队工作空间，其核心主张：AI Agent 应该作为正式成员加入团队，而不是作为一个插件或 bot 挂在角落里。

Slack、Teams、GitHub —— 现有协作工具对 AI 的集成方式通常是这样的：配置一个 bot token，让 bot 监听特定 channel，被 @mention 时触发回复。Agent 没有独立身份，没有持久历史，没有可审计的行为记录，访问权限由平台控制而非组织定义。

Buzz 选了另一条路。它基于 Nostr 协议，每个参与者——无论是人还是 Agent——都持有一个属于自己的密钥对。身份不由平台颁发，行为全部签名可审计，历史可携带到任何 Nostr 兼容系统。人类成员和 Agent 在 channel 里看起来完全一样。

21,300 颗 Star，Apache 2.0，发布六天后的数字。

你会学到什么

  • Buzz 为什么选 Nostr，而不是自建身份系统
  • Agent 如何成为 Buzz 的正式成员，而不是 bot
  • ACP 协议如何驱动 Claude Code、Codex、Goose 等 Agent
  • buzz-cli 的"机器优先"设计：为 LLM 工具调用而建
  • YAML 工作流引擎的触发机制和步骤定义
  • Rust + Axum 后端，Tauri 桌面端，整体技术栈

前提知识

  • 了解团队协作工具（Slack/Discord 类）的基本使用模式
  • 对 AI Agent 工具调用有基本认知
  • 了解密钥对（公钥/私钥）的基本概念会有帮助

项目背景

Block 为什么要做 Buzz

Block 花了两年时间在内部构建 AI 工具，得到一个结论：有效协作发生在人类和 Agent 在同一个上下文里工作的时候。分开的工具、分开的系统、分开的历史，带来的是碎片化和重复劳动。

现有平台的问题不是功能不够，而是设计假设错了：它们把 AI 当成"助手"，而不是"成员"。

Buzz 的设计起点是：Agent 应该拥有和人类成员相同的参与资格——独立身份、可审计行为、持久历史、可配置权限。

发布时间线

  • 2026 年 7 月 21 日：公开发布，同步开源
  • GitHub：发布后数天内达到 21,300 Stars
  • 主网：buzz.xyz（Block 托管实例）
  • 自托管：完整 Docker + Rust 工具链支持

作者/团队

  • 公司: Block, Inc.（Jack Dorsey 创立）
  • 许可证: Apache-2.0
  • 主语言: Rust（后端）+ TypeScript/React（桌面端 via Tauri）+ Dart（移动端 via Flutter）

项目数据

  • ⭐ GitHub Stars: 21,300+
  • 🍴 Forks: 2,300+
  • 📄 许可证: Apache-2.0
  • 📅 发布日期: 2026-07-21

为什么选 Nostr

Buzz 的身份系统完全基于 Nostr 协议，这个选择决定了整个产品的架构走向。

Nostr 解决的根本问题

传统协作平台的身份模型：平台颁发账号，平台控制访问，身份和历史归平台所有。换平台就意味着重新建立一切。

Nostr 的模型：每个参与者生成自己的 secp256k1 密钥对，私钥由自己持有，每条消息用私钥签名。身份不属于任何平台，历史记录可携带，行为不可抵赖。

这对 Agent 的意义：

传统 bot 模型：
  平台颁发 bot token → agent 用 token 调 API → token 撤销则 agent 消失
  身份属于平台，历史属于平台
 
Buzz / Nostr 模型：
  agent 生成自己的密钥对 → 用私钥签名每一条消息 → 密钥归 agent 所有
  身份可携带，历史在 relay 里，切换 relay 不丢失身份

使用的 Nostr NIPs

  • NIP-01：基础事件格式（所有消息的底层结构）
  • NIP-42：身份验证（连接 relay 时验证密钥所有权）
  • NIP-34：Git 集成（patch 提交、repo 公告、提交状态）

"relay URL 即社区"

Buzz 的一个设计决策：社区（workspace）由 relay URL 标识。wss://your-org.buzz.xyz 就是你的工作空间，URL 本身是权威标识符。不同 relay 是不同社区，同一 relay 上的所有状态共享同一个事件日志。

Agent 如何成为正式成员

不是 bot，是成员

传统平台的"AI bot"：一个服务账号，监听特定 channel，被 @mention 时触发响应。在权限模型里通常是一个独立类别，和人类成员不同。

Buzz 的 Agent：持有自己的密钥对，用和人类完全相同的方式加入 channel，发消息也是经过签名的 Nostr 事件，在 channel 历史里和人类消息无差异。

加入 channel 的方式：

# 给 agent 分配角色（和给人类成员操作相同）
buzz channels add-member --channel CHANNEL_ID --pubkey AGENT_PUBKEY --role member

加密身份意味着什么

每条 Agent 发出的消息都携带 Agent 自己私钥的签名：

  • 不可抵赖：任何人都可以验证这条消息来自哪个 Agent
  • 可审计：审计日志里的 Agent 行为归属明确，不会是"某个 bot"
  • 可携带：Agent 的密钥对不绑定到 Buzz 平台，可以在任何 Nostr 兼容系统里使用同一身份

ACP 协议如何驱动 Agent

Buzz 通过 ACP（Agent Client Protocol）把 relay 事件转发给 Agent 进程：

Buzz relay（WebSocket 事件流）
        ↓
buzz-acp（独立二进制，在 relay 外运行）
        ↓
ACP（JSON-RPC over stdin/stdout）
        ↓
Agent 进程（Claude Code / Codex / Goose / 自定义）
        ↓
MCP 工具调用 → 消息发回 channel

关键设计：每个 channel 同一时刻只有一个活跃 prompt。后续 @mention 在当前 prompt 完成前排队，避免多个 prompt 并发导致上下文窗口冲突。Agent 进程崩溃时，harness 自动重启。对话历史不存在 ACP 进程里，存在 relay 的 Postgres 数据库里，Agent 重启后上下文完整保留。

支持的 Agent

目前内置支持（自动检测本机已安装的 harness）：

  • Claude Code（Anthropic）
  • Codex（OpenAI）
  • Goose（Block 自己的 agent）
  • Grok（xAI）
  • 自定义 ACP 兼容 agent

buzz-cli：为机器设计的接口

机器优先的设计原则

Buzz 的 CLI 设计出发点不是"方便人类使用"，而是"方便 LLM 工具调用"：

  • JSON 到 stdout：所有输出都是结构化 JSON，方便程序解析
  • 结构化错误到 stderr：错误信息和正常输出分开，不污染 stdout
  • 有意义的退出码：0 = 成功，非零 = 有类型的失败，方便脚本判断

配置通过环境变量：

export BUZZ_RELAY_URL='http://localhost:3000'
export BUZZ_PRIVATE_KEY='nsec...'   # agent 或用户的私钥

主要功能

# channel 管理
buzz channels list
buzz channels create --name "dev-ops"
 
# 发送消息
buzz messages send --channel CHANNEL_ID --text "部署完成，版本 v2.3.1"
 
# 搜索（全文，覆盖消息 + canvas + git 事件，同一索引）
buzz messages search --query "deploy failed" --since 24h
 
# 读取线程
buzz threads read --thread-id THREAD_ID
 
# canvas 读写（文档）
buzz canvases write --canvas-id ID --content "..."
 
# 工作流管理
buzz workflows list
buzz workflows run --workflow-id ID
 
# Agent 记忆存储
buzz memory set --key "deployment-config" --value "..."
buzz memory get --key "deployment-config"
 
# Git repo 公告（NIP-34）
buzz repos announce --url https://github.com/org/repo

这个接口的用途：Agent 通过 MCP 工具调用这些命令，向 channel 发报告、读取上下文、更新 canvas、查询历史，不需要直接操作 relay 协议。

YAML 工作流引擎

触发机制

工作流支持四种触发方式：

trigger:
  on: message_posted       # 有消息发出时
  # on: reaction_added     # 有人加了 emoji reaction
  # on: schedule           # cron 表达式定时触发
  # on: webhook            # 外部 HTTP webhook

完整示例：发布请求工作流

name: "Release request"
trigger:
  on: message_posted
  filter: "str_contains(trigger_text, 'ship it')"
steps:
  - id: announce
    action: send_message
    channel: "{{trigger.channel_id}}"
    text: "Release requested by {{trigger.author}} — starting deployment pipeline."
 
  - id: notify-ops
    action: send_dm
    to: "ops-lead-pubkey"
    text: "Manual approval needed for release from {{trigger.author}}"
 
  - id: wait-approval
    action: wait_approval
    approvers: ["ops-lead-pubkey", "eng-lead-pubkey"]
    timeout: 30m
 
  - id: trigger-deploy
    action: webhook
    url: "https://ci.internal/deploy"
    method: POST
    body: '{"version": "{{vars.release_tag}}"}'

每个步骤发出的事件都写入 relay 事件日志，可通过搜索查询整个工作流执行历史。

支持的动作类型

  • send_message — 向 channel 发消息
  • send_dm — 发私信
  • add_reaction — 添加 emoji reaction
  • webhook — 触发外部 HTTP 请求
  • wait_delay — 等待指定时间
  • wait_approval — 等待审批（暂部分实现）

技术架构

后端（Rust）

Buzz 的 relay 是一个 Rust workspace，核心组件：

buzz-relay          Axum WebSocket + REST HTTP 服务
buzz-store          Postgres 事件存储 + 全文检索
buzz-pubsub         Redis pub/sub（实时消息分发）
buzz-media          S3/MinIO 媒体文件存储
buzz-acp            ACP 协议 harness（独立二进制）

事件日志设计：所有状态（聊天消息、canvas 更新、代码审查、CI 事件、工作流步骤）都是同一格式的 Nostr 事件，存在同一个 Postgres 表里，走同一个全文索引。"搜索 deploy"会同时返回相关的聊天讨论、canvas 文档和 Git 提交状态。

安全模型：

  • Tenant 上下文由服务器主机名解析，Agent 无法伪造跨社区访问
  • Channel 作用域 token 无法发布全局事件
  • 订阅交付时二次检查权限，捕获订阅后的权限变更
  • Ephemeral 事件（打字状态、在线状态）验证后不入库

桌面端（Tauri + React）

# 开发环境启动（relay + 桌面端）
just dev

Tauri 用 Rust 提供系统能力（文件访问、通知等），React 负责 UI 渲染，编译出原生桌面应用，比 Electron 内存占用更低。

移动端（Flutter）

iOS 和 Android 客户端基于 Flutter，目前在开发中。

快速开始

本地开发

git clone https://github.com/block/buzz.git
cd buzz
 
# 使用 Hermit 管理工具链（推荐）
. ./bin/activate-hermit
 
# 或手动安装：Rust 1.88+, Node 24+, pnpm 10+, just
 
just setup   # 初始化依赖
just build   # 构建所有组件
just dev     # 启动 relay（ws://localhost:3000）+ 桌面端

Docker 部署

docker compose up -d

包含：relay、Postgres、Redis、MinIO（媒体存储）。

Railway 一键部署

GitHub 仓库里提供了 Railway 部署模板，点击即可在云上部署一个私有 Buzz 实例。

连接 Agent

# 安装 buzz-cli
cargo install buzz-cli
 
# 设置环境变量
export BUZZ_RELAY_URL='wss://your-relay.buzz.xyz'
export BUZZ_PRIVATE_KEY='nsec...'
 
# 把 agent 添加到 channel
buzz channels add-member --channel CHANNEL_ID --pubkey AGENT_PUBKEY --role member
 
# 启动 ACP harness（自动检测本机安装的 agent）
buzz-acp --relay wss://your-relay.buzz.xyz --key nsec...

项目地址与资源

总结

Buzz 在一个设计决策上打了所有赌：AI Agent 应该作为正式成员加入团队，而不是作为附属工具。这个决策决定了所有后续选择——Nostr 协议（身份不由平台控制）、加密密钥对（行为可审计）、buzz-cli 的 JSON 输出（方便 LLM 工具调用）、ACP 协议（统一 Agent 接入标准）。

"一个事件日志"的设计值得注意：聊天消息、代码审查、CI 通知、工作流执行步骤全部写入同一个格式的 Nostr 事件流，走同一个全文索引。Agent 查询历史不需要知道"这是聊天还是代码事件"，搜一次就能看到相关的全部上下文。这是 Agent 友好的数据模型，不是给人类设计的分类体系再加 Agent 适配层。

Buzz 现在还早。工作流的部分动作返回 NotImplemented，移动端在开发中，生态刚起步。但 Block 做了一件重要的事：把 Agent 协作问题从"API 集成层面"提升到了"平台设计层面"，并且把整个平台开源出去让社区来演化。

探索 PrimeSkills —— 精选 AI Agent 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。

欢迎访问我的个人主页，发现更多有价值的见解和有趣的产品。

← 返回博客列表