Buzz：Nostr驱动的Agent协作统一事实源平台

Buzz是一款自托管的工作空间，官方将其描述为“人和Agent可以共同工作的频道驱动空间”。截至2026年7月，该项目在开源托管平台上拥有超过7500个星标、近600次复刻，主开发语言为Rust，采用Apache-2.0开源许可证。

它的目标并非复刻Slack或GitHub，而是将团队当前分散在聊天、代码托管、CI流程、审批环节、搜索工具以及Agent会话中的上下文信息，整合到一条统一的签名事件日志中。在Buzz中，人、Agent、工作流、仓库和决策都以统一的事件形态存在，消息、反应、工作流步骤、代码评审、Git事件都会被签名后写入日志，让项目不再仅仅是代码仓库或群聊，而是“带着代码的协作记录”。

这也是Buzz最独特的设计思路：它没有将Agent视为更智能的聊天入口，而是将其作为团队组织结构的一部分进行规划。

开发团队内部曾构建过集成Slack的Agent工具，能够完成代码提交、资料调研以及协助日常工作流，但当Agent真正进入团队协作后，组织层面的问题很快浮现出来：每个人是否都应该拥有专属Bot？多人共用一个Agent时，该使用谁的凭证？团队更换模型或Agent运行时，项目的身份、权限和历史记录能否保留？当多个Agent同时处理同一个问题时，谁来负责组织并行的上下文？

这正是Buzz的出发点：当AI模型已经能够完成具体任务，团队真正需要的是一个共同协作的统一空间，协作的瓶颈已经从“智能能力”转向“协调管理”。

Buzz的解决方案是将Agent直接纳入频道体系。Agent不再是隐藏在webhook后的自动化脚本，也不是冒用人类凭证的Bot，而是拥有自身身份、权限、成员关系和审计轨迹的协作者。简单来说，Buzz要解决的不是“让Agent回答得更精准”，而是“让Agent在工作时始终处于团队的共同视野中”。

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

这带来了一个关键变化：团队不再需要让Agent“冒用人类身份”。Buzz为每个Agent分配独立的密钥，由Agent的所有者签署窄范围授权。Agent随后以自身身份签署工作内容，授权凭证仅用于证明“谁授权了该Agent、授权边界是什么”。

如果Agent密钥泄露，可以直接撤销该Agent，而无需更换背后的人类身份；在紧急风险场景下，还可以直接终止其活跃会话。这种设计将“授权”和“作者身份”分离，授权操作不会抹除Agent自身的作者身份，这对企业级场景尤为关键——团队不再需要纠结于Agent做错事后无法厘清授权主体、权限范围、执行过程和最终审批者的问题。

Buzz支持Claude Code、Codex、goose以及任何实现Agent Client Protocol的Agent工具。团队可以灵活更换模型或运行框架，而项目的身份、权限和历史记录都会完整保留在Buzz系统中。

官方文档中介绍了一种典型的协作模式：由一个强算力Agent保持全局上下文，多个轻量、高效的Agent并行完成调研、代码实现、测试和评审工作。这些Agent通过普通的Buzz提及功能互相沟通，实时注入彼此的任务上下文，无需人类在多个私有Agent会话之间反复复制粘贴内容。

这种设计实际上将“Agent编排”从私密窗口转移到了团队公共频道。人类可以在协作过程中随时调整工作方向，而非等待一个看似完美却存在错误的最终结果。失败路径、讨论过程和最终决策都会被保留在可搜索的记录中。

如果说传统的Agent harness更像是“单兵增强器”，帮助单个工程师提升效率，那么Buzz更像“团队协同操作台”，其核心目标不是将某个人变成十倍工程师，而是让多个Agent和多个人能够在同一份上下文环境中协同工作。

Buzz有一个非常有趣的产品设想：“Branch as room”——当你创建一个特性分支时，系统会自动生成对应的专属频道。补丁提交、CI运行结果、Agent初审结果、团队反馈以及合并决策，都可以在这个频道中完成。

这解决了当前Agent开发中的一个现实痛点：传统代码托管平台可以保存代码diff，但为什么选择这个实现方案、为何拒绝另一个看似合理的修复、谁在何种上下文下做出了判断，这些信息往往散落在聊天记录、PR评论、CI页面和个人prompt中，难以完整追溯。

Buzz希望将这些分散的信息整合成一条完整的上下文链。半年后搜索一个错误关键词时，用户可以同时找到当时的问题报告、被拒绝的修复方案、代码补丁、评审记录和最终决策。对于工程团队来说，记录这些“为什么”的信息，比单纯保存“代码最终形态”更加困难，也更具价值。

Agent的引入会改变Git的吞吐形态。传统Git有一个天然的限速器：人类。人类需要休息、开会，也会在推送代码前仔细思考。但一组Agent可以在一个下午产生相当于人类数月的提交量和CI运行次数。

为此，Buzz设计了适配Agent规模的Git存储系统：将仓库保存为不可变、内容寻址的packfile，再配合一个可变的manifest pointer。一次推送操作会先写入对象，再通过条件compare-and-swap机制推进指针；只有指针更新才视为提交完成。工作空间事件仅用于宣布变化，而非定义变化本身。

开发团队还提到，他们使用TLA+为存储协议建模，检查了耐久性、数据重建和并发推送等场景。这说明Buzz并非仅在UI层面实现Agent协作，而是在存储一致性和对象存储边界层面都做了专业的工程设计。

根据项目公开信息，Buzz目前已经具备以下能力：

• Relay服务、频道、线程、私信、canvas、媒体、搜索和审计日志
• 基于Tauri + React的桌面应用
• 面向Agent的buzz-cli，输入输出以JSON格式为主，方便大语言模型工具调用
• ACP harness，可接入Goose、Codex、Claude Code等工具
• YAML工作流，支持message、reaction、schedule、webhook等触发器
• NIP-34 Git事件，包括patch、仓库公告、状态更新等
• Git托管后端

当前正在开发的功能包括iOS和Android移动端应用、工作流审批闸门、huddle生命周期事件。更远期的规划包括跨relay的信任网络声誉系统、推送通知以及社区文化功能。

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

第一层是客户端层：包括Buzz桌面应用、人类用户客户端、AI Agent、CLI工具和脚本程序。Agent侧通过buzz-acp接入ACP与MCP协议，buzz-cli则面向自动化流程和大语言模型工具调用。

第二层是buzz-relay，作为系统的单一事实源，负责处理NIP-01、NIP-42认证、频道管理、私信、媒体存储、工作流、Git REST接口和审计日志。在默认自托管部署模式下，一个relay对应一个社区；在托管多租户部署中，社区边界由宿主派生并隔离。

第三层是基础设施层：使用Postgres存储事件和提供全文搜索能力，Redis负责pub/sub、在线状态和输入提示，S3或MinIO负责Blossom媒体与对象存储。

项目仓库内部是一个Rust工作区：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与配对功能则由git-sign-nostr、git-credential-nostr、buzz-pair-relay、buzz-pairing-cli等模块支撑。

如果仅需试用应用，可以从开源托管平台的最新Release版本下载macOS、Linux或Windows构建包。默认应用会连接ws://localhost:3000，也可以通过BUZZ_RELAY_URL环境变量指向自定义的relay服务。

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

日常开发启动可以使用：

just dev命令会同时启动relay服务和桌面应用。如果需要拆分日志，可以在一个终端运行just relay，在另一个终端运行just desktop-dev。如果需要使用Agent功能，需要设置BUZZ_PRIVATE_KEY环境变量并使用buzz-cli工具。

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

传统的协作工具组合通常是：Slack负责讨论，GitHub负责代码diff，CI工具负责运行结果，Agent harness负责执行流程，文档或搜索系统负责知识沉淀。每个系统都只掌握部分信息，但没有任何一个工具能够完整回答“为什么这段代码会存在”。

Buzz将这些分散的协作对象整合到同一条签名事件日志中。人、Agent、工作流和代码仓库使用统一的协议、身份模型，并纳入同一个搜索索引。它的核心理念是：一个统一的社区空间，可以替代七个互相割裂、需要手动同步信息的标签页。

Buzz目前仍处于早期开发阶段。官方明确提醒，不要将规划中的愿景列表视为可用于合规规划的成熟功能。移动端应用、工作流审批闸门和huddle功能仍在开发中；跨relay信任网络、推送通知等功能仍属于远期规划。

此外，尽管Buzz的理念极具吸引力，但工程 adoption成本并不低。团队需要接受将Nostr身份、签名事件、Agent授权、Git存储、搜索和审计日志都纳入同一套基础设施的设计模式。它更适合对Agent协作、可审计历史和自托管控制权有强需求的工程团队，并不适合仅需要轻量聊天机器人的场景。

因此，Buzz更像是为“Agent已经进入工程生产环节”的团队准备的基础设施，而非适合所有团队立即迁移的通用协作软件。

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

它给出的解决方案是：将Agent转变为拥有身份、边界、签名记录和历史的协作者；将代码、讨论、审批和工作流重新整合到同一个空间；将上下文从私人prompt中解放出来，成为团队可搜索、可审计、可迁移的共同资产。

如果Agent真的会成为未来工程团队的常规组成部分，那么像Buzz这样的“Agent-native workspace”可能比单点编程工具更加重要。它关注的不是让某个大语言模型多写几行代码，而是让人和Agent协同工作的组织结构变得可落地、可执行。

真正的行业分水岭可能即将到来：当Agent不再仅仅是窗口中的回答者，而是带着身份、权限、审计记录和历史信息进入团队协作，工程组织需要的就不再只是更强的AI模型，而是一套全新的工作空间协议。