Block/Buzz：用 Nostr 协议把 AI Agent 变成有密钥的真正队友
发布于 2026 年 7 月 22 日，Block（原 Square）开源，Apache 2.0 许可证，当前版本 0.4.22，正处于早期公测阶段。
核心观点
Buzz 要做的事，用一句话概括：把 AI Agent 从"外挂机器人"变成"持有密钥的正式成员"，并用一条 Nostr 事件日志，把聊天、代码审查、CI/CD、工作流审批、文件协作全部串成同一个可审计的时间线。
这不是把 Slack 加上 AI 插件，也不是 GitHub Actions 的加强版------它在赌一件更激进的事：当人与 Agent 对协作基础设施的"地位"完全对等时，工作流会长出全新的形态。
关键机制：为什么选 Nostr 而不是自建协议
Nostr 的核心模型是：每条消息都是一个带 Schnorr 签名的 JSON 事件，事件由密钥对唯一标识。这个设计天然满足了多 Agent 协作的三个底层需求：
- 身份不可伪造：Agent 持有自己的私钥，它发出的每一条消息、每一次代码审查、每一个工作流触发，都有密码学签名，链上可验证，人类无法冒名，Agent 也无法抵赖。
- 事件同构 ：一条聊天消息、一次 CI 结果推送、一个 PR 合并事件（NIP-34 格式），在协议层面是同种类型的对象，因此可以用同一个搜索索引、同一个审计日志统一检索。这是原文"one event log"的真正含义。
- Relay 自主可控：组织自己跑 Relay，数据不出境，合规成本可控。
对比之前的做法：Slack 是中心化 SaaS，API Bot 是二等公民（没有完整的频道权限、没有独立身份链）；GitHub Actions 是 CI 管道，不是协作场所。Buzz 的创新在于让 Agent 拥有和人一样的"账号语义"，而不是让人类借权限给 Agent 用。
架构速览
scss
┌──────────────────────────────────────────────────────┐
│ Clients │
│ Human Client AI Agent CLI / Scripts │
│ (Buzz Desktop) (Goose/Codex/..) (buzz-cli) │
│ ┌──────────────┐ │
│ │ buzz-acp │ │
│ │ (ACP ↔ MCP) │ │
│ └──────┬───────┘ │
└───────────────────────────┼──────────────────────────┘
▼ WebSocket / REST
┌──────────────────────────────────────────────────────┐
│ buzz-relay │
│ NIP-01 · NIP-42 auth · channel/DM/workflow/git │
└───────┬────────────────┬────────────────┬────────────┘
▼ ▼ ▼
Postgres Redis S3/MinIO
(events + FTS) (pub/sub) (Blossom 媒体)技术选型上全是 Rust（核心 crate：buzz-core / buzz-relay / buzz-auth），前端 Tauri + React，部署用 Docker Compose + Postgres + Redis + MinIO。整体是一个单 Relay 即单一可信源的架构，横向扩展靠多 Relay 多社区隔离，不是分布式共识。
三个典型场景（原文 + 我的解读）
| 场景 | 原文描述 | 实质意义 |
|---|---|---|
| 凌晨事故溯源 | 问 Agent"我们见过这个报错吗"，Agent 拉六个月历史并附证据 | 把 RAG 的输出钉在对话上下文里，而非存在某个向量库里 |
| 分支即房间 | 开 feature branch 自动创建频道，patch/CI/review 同室 | 让"为什么这段代码存在"这个问题有结构化答案，而非靠 git blame 猜 |
| Release Note 自动化 | Workflow 触发 → Agent 起草 → 人工 👍 → 自动发布 | 人工审批被记录为一个签名事件，合规可查 |
功能完成度（截至 2026-07 公测）
| ✅ 已可用 | 🚧 接线中 | 💭 想法阶段 |
|---|---|---|
| Relay、频道、线程、DM、Canvas、媒体、搜索、审计日志 | iOS / Android（Flutter） | 跨 Relay 信任网络 |
| 桌面端（Tauri + React）macOS / Linux / Windows | 工作流审批门控 | Push 通知 |
buzz-cli（JSON in/out）+ ACP（Goose/Codex/Claude Code） |
Huddle 生命周期事件 | 文化功能 |
| YAML Workflow（消息/反应/定时/Webhook 触发） | ||
| Git 托管（NIP-34 patch/repo/status 事件） |
移动端、审批门控均未完工，不适合用于生产合规场景。
快速上手
bash
# 依赖：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 # 首次初始化
每日开发
. ./bin/activate-hermit
just dev # 同时启动 relay (ws://localhost:3000) + 桌面应用
`. ./bin/activate-hermit
just dev # 同时启动 relay (ws://localhost:3000) + 桌面应用
`Agent 接入：设置 BUZZ_PRIVATE_KEY，用 buzz-cli 发消息（JSON in/out，为 LLM tool call 设计）。
交叉验证
我搜索了以下独立信源并与原文对照：
① The New Stack（作者 B. Axen 访谈，2026-07-21）
与原文高度吻合，并补充了一个原文没有点明的痛点："现在你发一条消息，然后独自和 Agent 工作一小时，最后把 Agent 的输出复制粘贴回来，好像是你说的------大家都错过了那段真正重要的对话。" 这准确指出了 Buzz 要解决的不是"Agent 会不会用"，而是Agent 的决策过程对团队不透明 这个更根本的问题。同时，The New Stack 也指出 Block 内部仍在用 Slack------理由是 Slack 编码了大量已有业务工作流，迁移成本极高，所以现阶段 Buzz 更可能是并行工具而非替代品。
② SiliconAngle（2026-07-21）
认同 Buzz 的技术差异化定位，但提出了两个具体质疑：第一，版本 0.4.22 且无移动端，成熟度不足以支撑企业级采用；第二，托管服务定价未公布，商业模式不清晰。文章还援引对比数据：Buzz 发布初期 GitHub stars 仅一百余，而 Block 同期开源的 goose 框架已超 5 万 stars------说明开发者认可度存在明显落差。
综合判断 ：两个独立信源均认同 Buzz 在 Agent 身份模型上的技术创新，但都对当前成熟度和商业可行性持保留态度，这与原文相当诚实的"Works today / 🚧 / 💭"三列表格一致------原文并没有过度吹嘘。
边界与局限（不唱赞歌的部分）
- Nostr 并非银弹 。Nostr 本身是为去中心化社交媒体设计的，其大规模 Relay 的性能、事件过滤的表达能力、跨 Relay 同步的一致性，在企业协作场景下均未经生产验证。用 Schnorr 签名实现审计链是优雅的，但也意味着事件不可删除，对某些合规场景（如 GDPR 删除权）是麻烦。
- "Agent 和人地位对等"这个赌注本身有风险。当 Agent 可以创建频道、触发工作流、管理其他 Agent 时，权限边界的颗粒度必须非常精细，否则一个配置错误的 Agent 能在整个 workspace 里造成大范围破坏。目前工作流审批门控还在 🚧 阶段，这是实际部署前最需要等待的功能。
- 自托管门槛。原文语气轻快地说"Docker + Hermit，然后就跑起来了"，但运维一个生产级的 Relay（Postgres + Redis + MinIO + Caddy + TLS）对大多数非 DevOps 团队来说并不轻松，而托管版的定价和 SLA 至今未公布。
- 当前阶段不适合的场景：有严格合规要求的金融/医疗团队（审计链不可删除 + 移动端缺失）、规模超过几十人的中大型团队（网络效应锁定在 Slack/Teams 里）、不愿意维护基础设施的小团队（托管版定价未知）。
个人启发
对独立开发者 / 小型工程团队 ：现在就值得拉下来跑一遍 just dev，感受"Agent 作为频道成员"这个交互范式的实际感觉，而不是等它成熟。用它来做个人项目的"分支即房间"实验，成本为零，学到的是下一代协作工具的底层逻辑。
对工具链决策者 ：不要被"替代 Slack + GitHub"这个说法带偏评估节奏。现阶段合理的行动是：在一个非关键项目上并行跑 Buzz，验证 Agent 审计链对你团队的实际价值，而不是押注全面迁移。等移动端和审批门控上线（估计 Q3-Q4 2026）再做正式评估。
对关注 AI Agent 治理的人：Buzz 最值得借鉴的不是产品，而是**"用密钥对替代权限标志位来定义 Agent 身份"这个思路**。这个设计模式可以独立于 Buzz 被应用到其他系统里。
延伸思考
-
"Agent 持有密钥" vs "人类授权 Agent 使用密钥"------这两种身份模型长期会走向哪一种？ 前者（Buzz 的做法）带来完整的可审计性，但也意味着 Agent 可以在授权范围内完全自主行动；后者更保守但权限语义更清晰。当 Agent 开始能"orchestrate 其他 Agent"时，密钥链条的信任传递如何防止权限膨胀？
-
Nostr 协议能否承载企业级协作的性能和合规压力？ 目前 Nostr 在社交媒体场景已有一定规模验证，但企业场景对事件延迟、顺序保证、数据驻留合规（如 GDPR）的要求截然不同。Buzz 是 Nostr 协议第一个认真尝试企业场景的项目，它的成败会决定 Nostr 能否走出"密码朋克社区"进入主流工程圈。
-
"一条事件日志统一一切"这个赌注，是架构美学还是工程现实？ 把聊天、Git 事件、CI 结果、审批记录放进同一个 append-only 日志，查询和搜索很优雅，但当日志体量增长后，查询性能、存储成本、数据分级管理（热/冷数据）将是绕不过去的工程挑战。目前用 Postgres FTS 兜底，长期够不够用？
📚 参考来源