Block/Buzz：用 Nostr 协议把 AI Agent 变成有密钥的真正队友

QUOTE

把 AI Agent 从「外挂机器人」变成 持有密钥的正式成员 ，并以此赌一件更激进的事：当人与 Agent 对协作基础设施的地位完全对等时，工作流会长出全新形态。

发布于 2026 年 7 月 22 日，Block（原 Square）开源， Apache 2.0 许可证 ，当前版本 0.4.22，正处于早期公测阶段。这或许是 Nostr 协议第一次认真尝试企业协作场景——成败将决定这条协议能否走出密码朋克社区。

本文看点

01Nostr 的 Schnorr 签名如何赋予 Agent 密码学身份

02架构全景：Rust 全栈 + Relay 可信源的工程选择

03当前成熟度边界与「Agent 对等」赌注的风险

01CORE

核心观点

Buzz 要做的事，用一句话概括： 把 AI Agent 从「外挂机器人」变成「持有密钥的正式成员」 ，并用一条 Nostr 事件日志，把聊天、代码审查、CI/CD、工作流审批、文件协作全部串成同一个可审计的时间线。

这不是把 Slack 加上 AI 插件，也不是 GitHub Actions 的加强版——它在赌一件更激进的事： 当人与 Agent 对协作基础设施的「地位」完全对等时 ，工作流会长出全新的形态。

02

MECHANISM

关键机制：为什么选 Nostr 而不是自建协议

Nostr 的核心模型是： 每条消息都是一个带 Schnorr 签名的 JSON 事件 ，事件由密钥对唯一标识。这个设计天然满足了多 Agent 协作的三个底层需求：

1

身份不可伪造：Agent 持有自己的私钥，它发出的每一条消息、每一次代码审查、每一个工作流触发，都有密码学签名，链上可验证，人类无法冒名，Agent 也无法抵赖。

2

事件同构：一条聊天消息、一次 CI 结果推送、一个 PR 合并事件（NIP-34 格式），在协议层面是同种类型的对象，因此可以用同一个搜索索引、同一个审计日志统一检索。这是原文「one event log」的真正含义。

3

Relay 自主可控：组织自己跑 Relay，数据不出境，合规成本可控。

对比之前的做法：Slack 是中心化 SaaS，API Bot 是二等公民（没有完整的频道权限、没有独立身份链）；GitHub Actions 是 CI 管道，不是协作场所。Buzz 的创新在于 让 Agent 拥有和人一样的「账号语义」 ，而不是让人类借权限给 Agent 用。

03

ARCHITECTURE

架构速览

...architecture

┌──────────────────────────────────────────────────────┐

│　　　　　　　　　 Clients　　　　　　　　　　　　　│

│　Human　　 AI Agent　　　　CLI / Scripts　　　　　│

│　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 多社区隔离，不是分布式共识。

04

SCENARIOS

三个典型场景

这三个场景共同解释了一件事：Buzz 的价值不在功能层面，而在 把所有协作产物统一成一个可检索、可审计的签名事件流 。这正是 Slack 和 GitHub Actions 分别做不到的事情。

05

PROGRESS

功能完成度（截至 2026-07 公测）

⚠ 移动端、审批门控均未完工，不适合用于生产合规场景。

06

QUICKSTART

快速上手

...bash

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) + 桌面应用

Agent 接入：设置 BUZZ_PRIVATE_KEY ，用 buzz-cli 发消息（ JSON in/out，为 LLM tool call 设计 ）。

07

VERIFICATION

交叉验证

我搜索了两个独立信源并与原文对照：

信源一：The New Stack（作者 B. Axen 访谈，2026-07-21）

与原文高度吻合，并补充了一个原文没有点明的痛点： Agent 的决策过程对团队不透明 ——「现在你发一条消息，然后独自和 Agent 工作一小时，最后把 Agent 的输出复制粘贴回来，好像是你说的——大家都错过了那段真正重要的对话。」这准确指出了 Buzz 要解决的根本问题。同时，The New Stack 也指出 Block 内部仍在用 Slack，Buzz 现阶段更可能是 并行工具而非替代品 。

信源二：SiliconAngle（2026-07-21）

认同 Buzz 的技术差异化定位，但提出两个具体质疑：第一，版本 0.4.22 且无移动端， 成熟度不足以支撑企业级采用 ；第二，托管服务定价未公布，商业模式不清晰。Buzz 发布初期 GitHub stars 仅一百余，而 Block 同期开源的 goose 框架已超 5 万 stars—— 开发者认可度存在明显落差 。

综合判断：两个独立信源均认同 Buzz 在 Agent 身份模型上的技术创新，但都对当前成熟度和商业可行性持保留态度，与原文诚实的三列表格一致——原文并没有过度吹嘘。

08

BOUNDARIES

边界与局限

不唱赞歌，有几件事要诚实补充：

1

Nostr 并非银弹。Nostr 本身是为去中心化社交媒体设计的，其大规模 Relay 的性能、事件过滤的表达能力、跨 Relay 同步的一致性，在企业协作场景下均未经生产验证。用 Schnorr 签名实现审计链是优雅的，但也意味着事件不可删除，对 GDPR 删除权是麻烦。

2

「Agent 和人地位对等」这个赌注本身有风险。当 Agent 可以创建频道、触发工作流、管理其他 Agent 时，权限边界的颗粒度必须非常精细，否则一个配置错误的 Agent 能在整个 workspace 里造成大范围破坏。目前工作流审批门控还在 🚧 阶段，这是实际部署前最需要等待的功能。

3

自托管门槛。原文语气轻快地说「Docker + Hermit，然后就跑起来了」，但运维一个生产级的 Relay（Postgres + Redis + MinIO + Caddy + TLS）对大多数非 DevOps 团队来说并不轻松，而托管版的定价和 SLA 至今未公布。

4

当前阶段不适合的场景：有严格合规要求的金融/医疗团队（审计链不可删除 + 移动端缺失）、规模超过几十人的中大型团队（网络效应锁定在 Slack/Teams）、不愿意维护基础设施的小团队（托管版定价未知）。

09

INSIGHTS

个人启发

对独立开发者 / 小型工程团队：现在就值得拉下来跑一遍 just dev ，感受「Agent 作为频道成员」这个交互范式的实际感觉，而不是等它成熟。用它来做个人项目的「分支即房间」实验，成本为零，学到的是 下一代协作工具的底层逻辑 。

对工具链决策者：不要被「替代 Slack + GitHub」这个说法带偏评估节奏。现阶段合理的行动是： 在一个非关键项目上并行跑 Buzz ，验证 Agent 审计链对你团队的实际价值，而不是押注全面迁移。等移动端和审批门控上线（估计 Q3–Q4 2026）再做正式评估。

对关注 AI Agent 治理的人：Buzz 最值得借鉴的不是产品，而是 「用密钥对替代权限标志位来定义 Agent 身份」这个思路 。这个设计模式可以独立于 Buzz 被应用到其他系统里。

∞

THOUGHTS

延伸思考

1

「Agent 持有密钥」vs「人类授权 Agent 使用密钥」——这两种身份模型长期会走向哪一种？前者（Buzz 的做法）带来完整的可审计性，但也意味着 Agent 可以在授权范围内完全自主行动；后者更保守但权限语义更清晰。当 Agent 开始能 orchestrate 其他 Agent 时，密钥链条的信任传递如何防止权限膨胀？

2

Nostr 协议能否承载企业级协作的性能和合规压力？目前 Nostr 在社交媒体场景已有一定规模验证，但企业场景对事件延迟、顺序保证、数据驻留合规的要求截然不同。Buzz 是 Nostr 协议第一个认真尝试企业场景的项目，它的成败会决定 Nostr 能否走出「密码朋克社区」进入主流工程圈。

3

「一条事件日志统一一切」这个赌注，是架构美学还是工程现实？把聊天、Git 事件、CI 结果、审批记录放进同一个 append-only 日志，查询和搜索很优雅，但当日志体量增长后，查询性能、存储成本、数据分级管理将是绕不过去的工程挑战。目前用 Postgres FTS 兜底，长期够不够用？

REFERENCES

1. GitHub — block/buzz: A hive mind communication platform · github.com/block/buzz

END

我是 秦先生在广东，腾讯云高级前端工程师，15 年+全栈经验，深耕云开发、低代码及 AI Coding 架构。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。