Block 开源 Buzz：基于 Nostr 的工作空间，让 AI Agent 和人类在同一个 DevOps 频道里协作

如果你在做 DevOps，你每天的工作大概是这样的：

• 半夜告警了，你打开 Slack 看消息，打开 Grafana 看监控，打开 Jira 看工单，打开 GitHub 看 PR，打开 Jenkins 看构建日志
• 五个 Tab 来回切，信息散落在五个系统里，互相不知道对方的存在
• 你想问"这个错误我们以前见过吗？"，没人记得，你得自己去翻半年前的聊天记录
• 你想让 AI 帮你分析一下，但是 AI 不在你的工作流里，它只是一个外部的聊天机器人

问题出在哪里？ 出在你用的所有工具，都是为人类设计的。 AI Agent 在这些工具里，永远只是一个"外挂"，一个"集成"，一个"Bot"。 它不是团队成员，它没有自己的身份，它没有自己的审计日志，它看不到完整的上下文。

Block（原 Square）昨天开源了一个项目，要彻底改变这件事。

Buzz，一个基于 Nostr 协议的自托管工作空间，让人和 AI Agent 在同一个频道里协作。

GitHub 地址：https://github.com/block/buzz

这不是又一个 Slack 替代品，不是又一个 AI Bot 框架。 这是一个从底层协议开始，就为"人和 Agent 平等协作"而设计的工作空间。

---

核心设计：Agent 是团队成员，不是 Bot

这是 Buzz 和所有其他协作工具最根本的区别。

在 Slack 里，Bot 就是 Bot。它通过 Webhook 接进来，用一个 Bot 账号发消息，它的权限是管理员配的，它的行为是不透明的，它的操作是没有审计日志的。

在 Buzz 里，Agent 是团队成员。

• Agent 有自己的密钥对（Nostr Schnorr 签名）
• Agent 有自己的频道成员资格
• Agent 有自己的审计日志
• Agent 的每一个操作——发消息、做反应、提交 patch、审批工作流——都是一个签名事件
• Agent 的权限是通过身份来界定的，和人类成员完全一样

这意味着什么？ 意味着你可以像信任一个人类同事一样信任一个 Agent。 因为它的每一个操作都是可追溯的、可审计的、可验证的。 出了问题，你能查到是哪个 Agent 在什么时候做了什么，和查一个人类同事的操作记录完全一样。

---

Buzz 在 DevOps 中的五个核心场景

Buzz 的 README 里讲了三个故事，我把它扩展成五个 DevOps 场景，逐一拆解。

场景 1：事件管理——半夜告警，Agent 先到

传统流程：

1. PagerDuty 告警，你被叫醒
2. 打开 Slack 看有没有人已经在处理
3. 打开 Grafana 看监控指标
4. 打开 Kibana 搜日志
5. 翻半年前的聊天记录看有没有类似的故障
6. 找到根因，写修复方案
7. 全程大概 30-60 分钟

Buzz 流程：

1. 告警通过 webhook 触发 Buzz 工作流
2. Agent 自动被拉进事件频道
3. Agent 搜索六个月的历史事件，找到相似的故障、根因和修复方案
4. Agent 在频道里发一条消息，附带所有证据链（之前的讨论帖、相关的 PR、当时的修复 commit）
5. Agent 提议："这个问题我们 3 月 15 日见过，根因是 Redis 连接池耗尽，当时的修复是 #PR-1234，要不要我先 apply 一个类似的修复？"
6. 你看到消息，点个 👍，Agent 开始干活
7. 全程 5 分钟，你甚至没完全醒

关键区别： Agent 不是在"帮你搜"，它是在事件频道里留下了一条完整的、签名的、可搜索的记录。 下次再出类似问题，这条记录就是历史证据。 事件的记忆，从"在谁脑子里"变成了"在频道里"。

场景 2：CI/CD——Feature Branch 就是一个 Room

传统流程：

1. 你开了一个 feature branch
2. 推代码到 GitHub
3. CI 在 GitHub Actions 里跑
4. 代码审查在 PR 里做
5. 讨论在 Slack 里
6. 构建日志在 Jenkins 里
7. 所有信息散落在四个地方

Buzz 流程：

1. 你开了一个 feature branch
2. Buzz 自动创建一个频道（基于 NIP-34 Git 事件）
3. Patch 提交 → 自动发到频道
4. CI 跑完 → 结果自动发到频道
5. Agent 做第一轮代码审查 → 审查结果发到频道
6. 团队成员在频道里对具体的代码行做反应和讨论
7. Merge 决策也在这个频道里做
8. 频道就是这个 branch 的完整记录——为什么写这些代码、谁说了什么、CI 结果、审查意见，全部在一个地方

关键区别： 频道就是 branch 的活档案。 你不需要在四个 Tab 之间切换来拼凑一个 PR 的完整故事。 所有东西——代码、CI、审查、讨论、决策——都是同一个事件日志里的签名事件。

场景 3：发布管理——Release Notes 自己写自己

传统流程：

1. 你打了一个 tag
2. 手动去看这个版本合并了哪些 PR
3. 手动写 release notes
4. 手动发到 Slack/邮件/博客
5. 手动更新文档
6. 全程 30-60 分钟，而且容易漏

Buzz 流程：

1. 你打了一个 tag
2. Tag 事件触发 Buzz YAML 工作流
3. Agent 自动读取这个版本所有合并的 PR（都是频道里的历史事件）
4. Agent 自动生成 release notes 草稿
5. Agent 在发布频道里发出草稿，请求人类审核
6. 你看了一眼，点个 👍
7. Agent 自动发布

关键区别： 发布不是一个人的加班活，它是一个工作流。 Agent 做的是最耗时的信息收集和初稿撰写，人类做的是判断和决策。 而且整个过程——从 tag 到发布——每一步都是签名事件，都有审计记录。

场景 4：代码审查——Agent 作为第一审查者

传统流程：

1. PR 提交，等着人类 review
2. 人类 reviewer 可能要一天才有空
3. Review 质量取决于 reviewer 的状态和心情
4. 简单的格式问题、明显的 bug、安全风险，浪费了人类 reviewer 大量时间

Buzz 流程：

1. PR 提交，频道自动创建
2. Agent 作为频道成员，自动收到通知
3. Agent 做第一轮审查：
   • 检查代码风格和规范
   • 检查明显的逻辑错误
   • 检查安全风险
   • 检查测试覆盖率
4. Agent 在频道里发出审查报告，标出需要人类重点关注的地方
5. 人类 reviewer 只需要看 Agent 标出的重点
6. 如果 Agent 发现问题，可以直接提交修复 patch（NIP-34 事件）
7. 人类 reviewer 审核修复，点 👍 通过

关键区别： Agent 不是在"代替"人类审查，它是在"预筛"。 把人类从格式检查、明显 bug 这些低价值的审查中解放出来，让人类专注于架构判断、业务逻辑、边界条件这些真正需要人脑的事情。

场景 5：审计和合规——一切皆签名事件

传统流程：

1. 审计员来了，问"谁在什么时候做了什么操作"
2. 你去翻 Slack 聊天记录（可能已经过期）
3. 你去翻 GitHub 操作日志
4. 你去翻 Jenkins 构建日志
5. 你去翻 Jira 工单
6. 拼凑出来的东西不完整，时间线对不上
7. 审计员不满意

Buzz 流程：

1. 审计员来了，问"谁在什么时候做了什么操作"
2. 你打开 Buzz 的审计日志
3. 每一条消息、每一个反应、每一次 patch 提交、每一次 CI 运行、每一次审批——全部是签名事件，全部有时间戳，全部有作者身份
4. 人类和 Agent 的操作，同样的格式，同样的审计粒度
5. 全文搜索，一搜就出来
6. 审计员满意地走了

关键区别： 审计不是一个专门的"合规工程"，它是工作流的自然副产品。 因为在 Buzz 里，所有操作本身就是签名事件，审计日志不是额外维护的，它就是事件日志本身。

---

技术架构：为什么 Nostr 是正确的选择

Buzz 选择 Nostr 作为底层协议，不是赶时髦，是因为 Nostr 的设计天然适合"人和 Agent 平等协作"的场景。

Nostr 特性	在 Buzz 里的意义
签名事件	每个 Agent 的操作都有密码学签名，不可伪造
去中心化身份	Agent 有自己的密钥对，不依赖中心化的用户系统
统一事件模型	消息、反应、Git 事件、工作流步骤，全是同一种数据结构
Relay 架构	自托管，数据在你自己的服务器上
NIP 扩展	NIP-34（Git 事件）等标准扩展，让 Git 操作成为一等公民

整个架构非常干净：

客户端（桌面 App / AI Agent / CLI）
    ↓ WebSocket
Buzz Relay（Rust + Axum）
    ↓
Postgres（事件存储 + 全文搜索）
Redis（pub/sub + 在线状态）
S3/MinIO（媒体文件）

一个 Rust 工作空间，一组聚焦的 crate，单一数据源。 没有微服务地狱，没有消息队列迷宫，没有七个 Tab 假装互相知道对方。

---

Agent 接入：支持你已有的编码工具

Buzz 不造 Agent，它复用你已有的。

通过 buzz-acp（Agent Communication Protocol）层，Buzz 可以对接：

• Goose：Block 自家的 AI Agent
• OpenAI Codex：通过 ACP 适配
• Claude Code：通过 ACP 适配

Agent 通过 buzz-cli 接入，这个 CLI 专门为 LLM 工具调用设计：

• JSON in / JSON out
• 不需要复杂的 SDK
• Agent 可以创建频道、发消息、做反应、提交 patch、触发工作流

你不需要换 Agent，你只需要让 Agent 多一个工作空间。

---

YAML 工作流：DevOps 自动化的粘合剂

Buzz 内置了 YAML 工作流引擎，支持四种触发方式：

# 示例：Tag 推送时自动生成 Release Notes
trigger: webhook
event: git_tag
steps:
  - action: agent.message
    channel: "#releases"
    prompt: "读取本版本所有合并的 PR，生成 release notes 草稿"
  - action: wait_for_reaction
    emoji: "👍"
    timeout: 3600
  - action: agent.message
    channel: "#releases"
    prompt: "发布 release notes"

触发方式	适用场景
message	有人 @ Agent 或在频道里说了关键词
reaction	有人对某条消息做了特定反应（如 👍 审批）
schedule	定时触发（如每天早上发一份昨日 CI 报告）
webhook	外部系统触发（如 GitHub webhook、Prometheus Alertmanager）

这四种触发方式，覆盖了 DevOps 自动化 90% 的场景。

---

怎么部署？

最简单：Railway 一键部署

[Deploy on Railway] → 点击 → 完成

自托管：Docker Compose

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build
just dev   # relay + desktop app

生产环境用 deploy/compose/ 下的 Compose bundle：Postgres + Redis + MinIO + 可选 Caddy/TLS。

Agent 接入

设置 BUZZ_PRIVATE_KEY，用 buzz-cli：

buzz-cli --relay ws://your-relay:3000 \
  --action send_message \
  --channel "#incidents" \
  --text "故障已恢复，根因分析见附件"

---

和现有 DevOps 工具的对比

能力	Slack + GitHub + Jenkins	Buzz
聊天和代码审查分离	✅ 分离（不同 Tab）	❌ 不分离（同一频道）
Agent 身份	Bot 账号，权限靠管理员配	独立密钥对，身份和人类平等
审计日志	每个系统各有一套，格式不统一	统一的签名事件日志
事件历史搜索	只能搜聊天记录	聊天 + 代码 + CI + 审查 + 决策，一个搜索框
工作流自动化	需要 Zapier/n8n 等胶水	内置 YAML 工作流引擎
自托管	Slack 不能自托管	完全自托管，数据在你手里
Git 事件	通过 Webhook 间接同步	NIP-34 原生支持，Git 事件是一等公民

---

写在最后

DevOps 工具链最大的问题，不是工具不够多，而是工具太多了。

七个 Tab，五个系统，三套权限，两个搜索框，一个你。 每天的工作有 30% 的时间花在"在系统之间切换和传递信息"上。

Buzz 做的事情很简单：把所有东西放到一个事件日志里。 聊天是事件，代码是事件，CI 是事件，审查是事件，决策是事件。 人类和 Agent 用同一套身份模型，同一个审计日志，同一个搜索索引。

这不是又一个"AI 赋能 DevOps"的故事。 这是一个从底层协议开始重新思考"人和 Agent 怎么一起工作"的尝试。

如果你在做 DevOps，如果你在管一个需要 AI Agent 参与的团队，Buzz 值得你认真看一看。

---

作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。