Buzz：Block 开源的 Agent 协作记忆工作台

BLOCK ENGINEERING 2026-07-24

Buzz：Block 开源的 Agent 协作工作台 · 工程现场

从私有 Agent 会话，到人、Agent、仓库、审批和历史共处的 signed event workspace。

一个 relay，一套身份模型，一条协作记忆。

AGENTNOSTR

AI 编程工具已经能写代码、查资料、跑流程，但企业真正头疼的不是“Agent 会不会干活”，而是“它干活时谁授权、谁看见、谁接手、谁为结果负责”。Block 开源的 Buzz，正是把人、Agent、仓库、审批、工作流和历史记录重新放回同一个工程频道。

Buzz 官方博客头图

— Buzz 官方博客头图

01PART

先看结论：Buzz 想解决的不是聊天，而是协作记忆

TAKEAWAY

Buzz 是 Block 开源的一个自托管工作空间，官方把它描述为“一个人和 Agent 可以共同工作的频道驱动空间”。截至 2026 年 7 月 24 日，block/buzz 在 GitHub 上约有 7,522 个 Star、597 个 Fork，主语言是 Rust，许可证为 Apache-2.0。

它的目标并不是再做一个 Slack，也不是再做一个 GitHub 替代品，而是把团队现在分散在聊天、代码托管、CI、审批、搜索、Agent 会话里的上下文，收回到一条统一的事件日志里。

在 Buzz 里，人、Agent、工作流、仓库和决策都以同一种事件形态存在。消息、反应、工作流步骤、代码评审、Git 事件都被签名后写入日志。这样一来，一个项目不再只是仓库，也不只是群聊，而是“带着代码的协作记录”。

这也是 Buzz 最值得看的地方：它没有把 Agent 当成一个更聪明的聊天入口，而是把 Agent 当成团队组织结构的一部分来设计。

Buzz 工程频道：代码、测试结果、Issue 链接和发布决策在同一个频道中流动

— Buzz 工程频道：代码、测试结果、Issue 链接和发布决策在同一个频道中流动

02PART

为什么 Block 会做 Buzz

CONTEXT

Block 的官方技术博客提到，他们内部已经构建过 Slack 集成的 Agent：它能提交代码、做研究，也能在团队日常工作流里帮忙。但当 Agent 真正进入团队协作后，问题很快变成了组织层面的。

每个人是否都应该拥有一个 Bot？如果多人共用一个 Agent，它到底使用谁的凭证？团队换模型、换 Agent runtime 时，项目的身份、权限和历史记录是否还能保留？当一个团队想把多个 Agent 同时丢进同一个问题里，谁负责组织这些并行上下文？

这就是 Buzz 的出发点：模型现在可以做事了，但团队仍然需要一个共同做事的地方。瓶颈从“智能”转移到了“协调”。

Buzz 的做法是把 Agent 直接放进频道。Agent 不是一个躲在 webhook 后面的自动化脚本，也不是冒用人类凭证的 Bot，而是拥有自己身份、权限、成员关系和审计轨迹的协作者。

一句话说，Buzz 要解决的不是“让 Agent 回答得更好”，而是“让 Agent 做事时仍然处在团队的共同视野里”。

Buzz 中的人和 Agent 可以在同一个工程频道里协作并回应上下文

— Buzz 中的人和 Agent 可以在同一个工程频道里协作并回应上下文

03PART

核心设计一：Nostr 作为统一身份与事件底座

IDENTITY

Buzz 构建在 Nostr 之上。Nostr 是一个围绕签名消息和可携带身份设计的开放协议。在 Buzz 里，身份是密钥对，每一次动作都可以被签名：发消息、授权 Agent、审批工作流、签名提交、合并变更，都可以落在同一个信任模型里。

这带来一个重要变化：团队不再需要让 Agent “穿上人的马甲”。Buzz 给每个 Agent 自己的密钥，由 Agent 的 owner 签署一个窄范围授权。Agent 随后用自己的身份签署工作，而授权凭证证明“谁授权了它、授权边界是什么”。

如果 Agent 密钥泄露，可以撤销 Agent，而不是替换背后的人类身份。如果风险紧急，还可以终止它的活跃会话。这个模型把“授权”和“作者身份”拆开：授权不会抹掉 Agent 自己的作者身份。

这个设计对企业尤其关键。因为真正的风险不只是 Agent 做错事，而是做错之后团队无法说清：是谁授权的、它拿到了什么范围、过程在哪里、最后谁批准。

04PART

核心设计二：Agent 成为频道成员，而不是后台脚本

AGENTS

Buzz 支持 Claude Code、Codex、goose，以及任何实现 Agent Client Protocol 的 Agent。团队可以换模型、换 harness，但项目身份、权限和历史仍然留在 Buzz 里。

官方博客里有一个很典型的协作模式：一个强模型 Agent 保持全局上下文，多个更便宜、更快的 Agent 并行做研究、实现、测试和评审。它们通过普通的 Buzz mention 互相沟通，几乎实时注入彼此正在进行的任务上下文，而不需要人类在多个私有 Agent 会话之间来回复制粘贴。

这其实是在把“Agent 编排”从私密窗口搬回团队频道。人可以在过程中重定向工作，而不是等一个漂亮但错误的最终答案。失败路径、讨论过程和最终决策也都会留在可搜索记录里。

如果说传统 Agent harness 更像“单兵增强器”，Buzz 更像“团队协同操作台”：重点不是把某个人变成十倍工程师，而是让多个 Agent 和多个人在同一份上下文里工作。

Buzz 中多个 Agent 可以分工、评审、部署，并把最终决策交回给人

— Buzz 中多个 Agent 可以分工、评审、部署，并把最终决策交回给人

05PART

核心设计三：把分支变成房间，把决策留在现场

WORKFLOW

Buzz 的一个很有意思的产品设想是“Branch as room”：当你打开一个 feature branch，就可以出现一个对应频道。补丁、CI 结果、Agent 初审、团队反应和合并决策都在同一个地方发生。

这解决的是今天 Agent 开发里非常现实的问题：代码 diff 能被传统 forge 保存，但为什么选择这个实现、为什么拒绝另一个看似合理的修复、谁在什么上下文里做了判断，往往散落在聊天、PR 评论、CI 页面和个人 prompt 里。

Buzz 想把这些信息合并成一条上下文链。半年后搜索一个错误关键词，能同时找到当时的报告、被拒绝的修复方案、补丁、评审和最终决定。

对工程团队来说，这类“为什么”的保存，比“代码最后是什么样”更难，也更值钱。

Buzz 的 Git forge 视图展示了 PR、评审状态、分支、活动和评论

— Buzz 的 Git forge 视图展示了 PR、评审状态、分支、活动和评论

06PART

Git 如何适配 Agent 规模

GIT

Agent 会改变 Git 的吞吐形态。过去 Git 有一个天然限速器：人。人要睡觉、开会，也会在 push 前稍微想一想。但一组 Agent 可以在一个下午产生“人月级”的提交和 CI 运行。

Buzz 因此设计了能适配 Agent 规模的 Git 存储。它把仓库保存为不可变、内容寻址的 packfile，再加上一个可变的 manifest pointer。一次 push 会先写对象，再通过条件 compare-and-swap 推进 pointer；这个 pointer 更新才是提交点。工作空间事件会宣布变化，但不定义变化。

官方还提到，他们用 TLA+ 为存储协议建模，并检查 durability、reconstruction 和并发 push。这个细节说明 Buzz 并不是只在 UI 层做 Agent 协作，而是在存储一致性和对象存储边界上也做了工程设计。

07PART

当前已经能用什么

STATUS

从项目公开信息看，Buzz 已经具备这些能力：

• Relay、频道、线程、私信、canvas、媒体、搜索和审计日志。
• Tauri + React 桌面应用。
• 面向 Agent 的 buzz-cli，输入输出以 JSON 为主，方便 LLM 工具调用。
• ACP harness，可接入 Goose、Codex、Claude Code。
• YAML 工作流，支持 message、reaction、schedule、webhook 等触发器。
• NIP-34 Git 事件，包括 patch、repo announcement、status。
• Git hosting backend。

正在接线的部分包括 iOS 和 Android 移动端、工作流审批 gate、huddle 生命周期事件。更远期的想法包括跨 relay 的 web-of-trust reputation、推送通知和文化功能。

Buzz 项目频道示例：人与 Agent 围绕发布计划协同工作

— Buzz 项目频道示例：人与 Agent 围绕发布计划协同工作

08PART

架构模式：一个 relay，多个客户端，同一条事实源

ARCHITECTURE

Buzz 的公开架构可以概括为三层。

第一层是客户端：Buzz desktop、人类客户端、AI Agent、CLI 和脚本。Agent 侧通过 buzz-acp 接入 ACP 与 MCP，buzz-cli 则面向自动化和 LLM 工具调用。

第二层是 buzz-relay。它是系统的单一事实源，负责 NIP-01、NIP-42 认证、频道、私信、媒体、workflow、Git REST 和审计日志。默认自托管部署下，一个 relay 对应一个 community；在托管多租户部署里，社区边界仍由 host 派生并隔离。

第三层是基础设施：Postgres 存事件和全文搜索，Redis 负责 pub/sub、presence、typing，S3 或 MinIO 负责 Blossom 媒体与对象存储。

仓库内部则是一个 Rust workspace：buzz-core 和 buzz-relay 处理核心协议；buzz-db、buzz-auth、buzz-pubsub、buzz-search、buzz-audit 承接服务层；buzz-cli、buzz-acp、buzz-agent、buzz-dev-mcp、buzz-workflow、buzz-persona 构成 Agent 表面；Git 与 pairing 则由 git-sign-nostr、git-credential-nostr、buzz-pair-relay、buzz-pairing-cli 等模块支撑。

09PART

开发者如何跑起来

QUICK START

如果只是试用应用，可以从 GitHub 最新 Release 下载 macOS、Linux 或 Windows 构建。默认应用连接 ws://localhost:3000，也可以通过 BUZZ_RELAY_URL 指向自己的 relay。

如果从源码启动，需要 Docker 和 Hermit，或者手动准备 Rust 1.88+、Node 24+、pnpm 10+ 和 just。

...bash

git clone https://github.com/block/buzz.git && cd buzz

. ./bin/activate-hermit

just setup && just build

日常开发启动：

...bash

. ./bin/activate-hermit

just dev

just dev 会一起启动 relay 和桌面应用。需要拆分日志时，可以一个终端跑 just relay，另一个终端跑 just desktop-dev。如果要使用 Agent，需要设置 BUZZ_PRIVATE_KEY 并使用 buzz-cli。

Buzz 可以快速创建频道，并设置名称、描述和私有状态

— Buzz 可以快速创建频道，并设置名称、描述和私有状态

10PART

它和现有协作工具最大的不同

DIFFERENCE

Buzz 的差异不在于“也能聊天”，而在于它试图让所有协作对象共享协议、身份和审计轨迹。

传统组合通常是：Slack 管讨论，GitHub 管 diff，CI 管结果，Agent harness 管执行，文档或搜索系统管知识沉淀。每个系统都知道一部分，但没有谁完整知道“为什么这段代码存在”。

Buzz 把这些对象放回同一条 signed event log。人、Agent、workflow 和 repo 说同一种协议，用同一种身份模型，进入同一个搜索索引。它押注的是：一个 community 可以替代七个互相假装理解对方的标签页。

11PART

需要关注的边界

BOUNDARY

Buzz 仍然很早期。官方明确说，不要把愿景列当成已经可用于合规规划的功能。移动端、审批 gate 和 huddle 还在接线；跨 relay 声誉、推送通知等仍属于后续想法。

另外，Buzz 的理念很有吸引力，但工程采用成本不会低。团队需要接受 Nostr 身份、签名事件、Agent 授权、Git 存储、搜索和审计都被放进同一套基础设施里。它适合对 Agent 协作、可审计历史和自托管控制权有强需求的工程团队，不一定适合只想要一个轻量聊天机器人的场景。

因此，Buzz 更像是给“Agent 已经进入工程生产”的团队准备的基础设施，而不是给所有人都立刻迁移的通用协作软件。

12PART

为什么值得看

WHY IT MATTERS

过去一年，很多 Agent 产品都在强调“一个人如何更快完成任务”。Buzz 更像是在回答另一个问题：当 Agent 真的进入企业工程组织，团队如何避免每个人带着自己的私有 Agent 会话各自为战？

它给出的答案是：把 Agent 变成有身份、有边界、有签名、有历史的协作者；把代码、讨论、审批和工作流放回同一个房间；把上下文从私人 prompt 里释放出来，成为团队可搜索、可审计、可迁移的共同资产。

Buzz 支持围绕媒体内容进行帧级评论和讨论

— Buzz 支持围绕媒体内容进行帧级评论和讨论

如果 Agent 未来真的会成为工程团队的一部分，那么 Buzz 这类“Agent-native workspace”可能会比单点编程工具更重要。它关注的不是让某个模型多写几行代码，而是让人和 Agent 一起工作的组织结构变得可运行。

真正的分水岭可能在这里：当 Agent 不再只是一个窗口里的回答者，而是带身份、权限、审计和历史进入团队协作，工程组织需要的就不只是更强模型，而是一套新的工作空间协议。

声明：本文由山行整理自：GitHub 仓库 block/buzz 和 Block 官方技术博客 Buzz，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～