上周刷 GitHub Trending，一个 Rust 项目连续三天霸榜，Star 周增量破万。点进去一看——Block（原 Square，Jack Dorsey 的公司）开源的，名字叫 Buzz。
一句话介绍：一个让人类和 AI Agent 在同一个工作空间里协作的通信平台，基于 Nostr 协议，用 Rust 写的。
我花了两天时间把它的架构文档、源码结构翻了一遍，越看越觉得这东西的设计思路和市面上那些"给 AI 套个壳"的协作工具完全不是一个路子。今天聊聊我的发现。
一、先搞清楚：Buzz 到底是什么？
很多人第一反应：这不就是个 Slack 平替？
不是。Slack 的核心是聊天应用，API 是后加的，Bot 是二等公民。Buzz 反过来——协议优先，先有一套统一的签名事件协议，聊天、代码审查、工作流触发全都是这条协议上的事件。
简单说：
- 人类发消息 → 一条签名事件
- Agent 提交代码补丁 → 一条签名事件
- CI 跑完发布结果 → 一条签名事件
- 工作流审批 → 一条签名事件
所有东西汇入同一个事件日志，同一个搜索索引。没有"消息表""Bot 操作表""审计表"这种割裂的存储——一张事件表搞定一切。
┌─────────────────────────────────────────────────┐
│ Buzz 工作空间 │
│ │
│ 人类用户 AI Agent CI/CD │
│ │ │ │ │
│ │ 各自持有独立密钥对（secp256k1） │
│ └────────────────┼────────────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 统一签名事件日志 │ │
│ │ （Nostr Protocol） │ │
│ └─────────────────────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ ▼ ▼ ▼ │
│ PostgreSQL Redis S3/MinIO │
│ (事件存储+全文搜索) (Pub/Sub) (媒体/Blossom) │
└─────────────────────────────────────────────────┘
二、最让我眼前一亮的设计：Agent 拥有自己的密钥对
这是 Buzz 和传统 Bot 最大的区别，也是我反复读了三遍文档才确认的设计。
传统做法
Bot 拿到人的 API Token，以人的身份发消息。结果审计日志里分不清哪条是人发的、哪条是 Bot 代发的。Token 泄露 = 人整个身份被冒用。
Buzz 的做法
每个 Agent 生成自己独立的 secp256k1 密钥对，有自己的身份。人作为"所有者"签署一个授权凭证，限定 Agent 能干什么。
验证链路是这样的：
Agent 发布事件
│
▼
① 用 Agent 公钥验证事件签名 → 确认是它发的
│
▼
② 事件中携带 authorization 标签 → 追溯授权凭证
│
▼
③ 用人类所有者公钥验证授权凭证签名 → 确认授权真实
│
▼
④ 检查授权范围 / 过期时间 / 速率限制 → 确认在权限内
我实际看了一个授权凭证的结构，长这样：
{
"pubkey": "人类所有者的公钥",
"kind": "Agent Authorization",
"tags": [
["delegatee", "agent的公钥"],
["scope", "workspace:channel:dev:read,write"],
["scope", "git:repo:myproject:read,review"],
["expiration", "1787280000"],
["max_events_per_hour", "100"]
],
"sig": "所有者的Schnorr签名"
}
关键点：Agent 用自己的身份签名工作内容，授权凭证只证明"谁授权了它"。Agent 密钥泄露？撤销那个授权就行，人的主身份不受影响。员工离职？移除他的授权，他名下所有 Agent 自动失效。
这套设计本质上是把可验证凭证（VC）的思想搬进了协作平台。
三、实战场景：分支即房间（Branch as Room）
文档里有个场景我觉得特别能体现 Buzz 的设计哲学，我按自己的理解画了个完整流程：
开发者创建功能分支 feature/login
│
▼
Buzz 自动创建频道 #feature-login
│
▼
开发者推送代码补丁
│
▼
补丁作为 NIP-34 事件落地（签名事件）
│
├──────────────────────┐
▼ ▼
CI 跑完发布结果 Code Review Agent
（签名事件到频道） 自动做首轮审查
│ │
▼ ▼
队友对审查意见 Agent 提交审查意见
添加 reaction （用自己的密钥签名）
│ │
└──────────┬───────────┘
▼
合并决策 + 所有证据
共存于同一频道
注意几个细节：
- Agent 的审查意见是它自己签名的——不是冒充人发的，审计追踪里清清楚楚
- CI 结果是事件——不是外部系统通过 Webhook 推进来的独立记录，而是同一个事件日志的一部分
- 半年后搜"登录功能"——能一次性搜到代码、讨论、审查、CI 结果，因为它们都是同一个频道里的事件
这就是"协议优先"的好处：不需要做复杂的关联和聚合，天然就在一个流里。
四、技术栈拆解：为什么是 Rust + Nostr？
Rust 侧
Buzz 是一个 Rust workspace，拆成二十多个 crate：
| 分类 | 核心 Crate | 干什么 |
|---|---|---|
| 协议层 | buzz-core |
零 I/O 的类型定义、NIP-01 过滤器、Schnorr 验证 |
| 服务层 | buzz-relay |
Axum WebSocket + REST，核心服务 |
buzz-db |
PostgreSQL 数据层 | |
buzz-auth |
NIP-42/98 认证、限流 | |
buzz-pubsub |
Redis 发布订阅、在线状态 | |
buzz-audit |
哈希链审计日志 | |
| Agent 层 | buzz-cli |
Agent 优先的 CLI，JSON in / JSON out |
buzz-acp |
ACP 测试框架，接 Goose/Claude Code/Codex | |
buzz-workflow |
YAML 自动化工作流 | |
| Git 层 | git-sign-nostr |
Nostr 签名 Git |
我特别关注了 buzz-cli 的设计——JSON in / JSON out，完全为 LLM 工具调用设计。Agent 调用它就像调一个标准 CLI 工具，不用搞复杂的 SDK 集成。
Nostr 侧
Buzz 选 Nostr 不是赶时髦，是因为 Nostr 的三个特性正好匹配需求：
- 加密身份原生：secp256k1 密钥对是协议层的东西，不是后加的
- 统一事件模型：一套 JSON 结构覆盖所有操作
- 中继可替换：数据属于你，中继只是管道
需要澄清的"去中心化"
网上不少文章说 Buzz 是"P2P 去中心化通信平台"，我翻了架构文档，这个说法不准确。Buzz 明确写了：
- 没有 P2P 事件交换
- 没有 Gossip 层
- 没有中继间复制
它的"去中心化"体现在部署和所有权层面——你可以跑自己的中继，保留自己的域名和数据。实际使用中，一个工作空间对应一个中继，是单中心的。
五、Git 存储的巧思：对象存储 + Manifest 指针
这部分我觉得是整个架构里最精巧的设计，值得单独说。
Buzz 的 Git 仓库不放在传统 Git server 上，而是用对象存储 + Manifest 指针的方案：
┌─────────────────────────────────┐
│ 对象存储层（S3/MinIO） │
│ ┌──────────┐ ┌──────────┐ │
│ │ abc.pack │ │ def.pack │ │
│ │ (不可变) │ │ (不可变) │ │
│ └──────────┘ └──────────┘ │
│ content-addressed，写操作幂等 │
└──────────────┬──────────────────┘
│ 引用
┌──────────────▼──────────────────┐
│ Manifest 层（manifest.json） │
│ 可变，CAS 原子更新 │
└──────────────┬──────────────────┘
│ 通知变更
┌──────────────▼──────────────────┐
│ 事件层（Git Push 事件） │
│ 通知变更，不定义变更 │
└─────────────────────────────────┘
推送流程三步走：
- 先写对象：Git 对象打包成 packfile 上传到对象存储，content-addressed 所以幂等
- 原子更新指针：CAS（compare-and-swap）操作更新 manifest 指针
- 发事件通知：发布 Git Push 事件宣布变更
文档里提到他们对这套流程做了 TLA+ 形式化验证，证明了三个属性：持久性（并发推送不丢数据）、可重建性（从 manifest 和 packfile 可完整重建仓库）、并发安全性。
这个设计直接面向 Agent 大规模并发操作的场景——传统 Git server 在几百个 Agent 同时推送时会成为瓶颈，而对象存储天然支持高并发写入。
六、我的判断：值得关注的三个理由
第一，"Agent 即成员"范式可能是未来协作软件的方向。 现在的 Bot 模式是过渡态——随着 Agent 能力增强，它必然需要独立身份、独立审计、独立权限管理。Buzz 把这件事从协议层就做对了。
第二，Rust + Nostr 的组合很务实。 Rust 保证性能和安全性，Nostr 提供现成的签名事件协议，不用从零造轮子。二十多个 crate 的拆分也说明工程成熟度不低。
第三，Git 存储层的设计有借鉴价值。 对象存储 + CAS 指针的方案，对于任何需要处理高并发写入的系统都有参考意义。
但也要泼盆冷水
- 项目标注
maturity: prototype，还在快速迭代 - 自托管需要维护 Postgres + Redis + S3 + Relay，运维成本不低
- Nostr 协议相对小众，团队有学习成本
- 密钥管理的 UX 是硬伤——私钥丢失 = 身份永久丢失
结语
Buzz 不是终点，但它提出了一个值得认真对待的问题：当 AI Agent 成为团队的常驻成员时，协作平台该怎么设计？
它的回答是——从协议层开始，让人和 Agent 同构。不是给 Agent 开个 API，而是给它一把钥匙，让它自己进房间。
这个思路，我觉得是对的。
