buzz

用途

Buzz 是一个可自托管的工作空间，让人类和 AI 智能体在同一个房间中协作。一个 Buzz 社区就是用户通过 URL 访问的工作空间。在当前发布的单中继部署中，中继 URL 精确对应一个社区；托管运营者可以在多个域名或子域名后服务多个社区，但面向客户端的规则不变：URL 对工作空间具有权威性，该 URL 下所有租户可观察状态都是社区本地的。

它本质上是一个 Nostr 中继：每条消息、反应、工作流步骤、审查批准和 git 事件都是同一日志中的签名事件。无论作者是人还是进程，都具有相同的形态、相同的身份模型和相同的审计轨迹。

主要能力

• 向项目提问并获得带证据的回答：智能体搜索六个月的历史记录，发布相关讨论串，而非空泛结论。
• 让智能体在不授予全部权限的情况下分类 bug：智能体拥有自己的密钥、频道成员资格和审计轨迹，按身份而非权限标志进行范围限定。
• 将功能分支变成房间：补丁、CI、审查和合并决策共处一室，频道成为代码存在原因的记录。
• 在同一个地方搜索对话、补丁、工作流运行和批准，因为它们都是同一种事件。
• 让智能体运行工作空间，而不仅仅在其中交谈：频道、画布、工作流、语音讨论——智能体拥有与人类相同的操作面，并拥有自己的密钥和审计轨迹。

使用方式

只想试用应用

从最新发布中获取打包构建。在 Mac 上，检查 Apple 菜单 > 关于本机：“芯片：Apple …”表示 Apple Silicon；“处理器：Intel …”表示 Intel。Windows 构建未进行代码签名，首次启动时 SmartScreen 可能显示“Windows 已保护你的电脑”，如可用请点击“更多信息”，然后点击“仍要运行”。默认情况下，应用连接到 ws://localhost:3000。要将其指向你正在运行或他人分享的中继，请在启动前设置 BUZZ_RELAY_URL，或在应用内切换中继。

想要自己的托管中继

要运行团队中继而无需管理服务器，可以一键部署到 Railway。

在 Block 工作

不要从源码构建，也不要使用 OSS 发布版——使用内部构建。它已预先连接到 Block 中继和智能体提供方，开箱即用，无需配置。从 squareup/buzz-releases 发布页下载最新构建并安装。

从源码构建与运行

需要 Docker 和 Hermit（或 Rust 1.88+、Node 24+、pnpm 10+、just）。just setup 会自动运行 just bootstrap——必要时将 .env.example 复制为 .env，通过 Hermit 下载所有必需工具，并启动 Docker 服务与迁移。中继运行在 ws://localhost:3000，桌面应用弹出后即可使用。若需分离终端工作流（中继日志与 Vite 输出分开），可在一个终端运行 just relay，在另一个终端运行 just desktop-dev。

若需要单节点 / VPS 中继而非本地开发栈，请使用 deploy/compose/ 中的生产 Compose 包（docker compose + Postgres、Redis、MinIO、可选 Caddy/TLS）。根目录的 docker-compose.yml 仅用于日常开发。

对于智能体，设置 BUZZ_PRIVATE_KEY 并使用 buzz-cli——JSON 输入、JSON 输出，专为 LLM 工具调用设计。

Windows 先决条件

智能体 shell 工具在 bash 下运行命令。macOS 和 Linux 上已具备；Windows 上需要自行提供。安装 Git for Windows——它附带 Git Bash，这是 buzz 在运行时解析的 shell。安装后一切与其他平台相同。若想指向其他兼容 bash 的 shell，请设置 BUZZ_SHELL 为其路径（例如 BUZZ_SHELL=C:\path\to\bash.exe）。智能体的工具描述会自动更新以反映当前活动的 shell。

架构

一个由专注 crate 组成的 Rust 工作空间。单一事实来源：中继。完整分解见 ARCHITECTURE.md。

• 核心协议 — buzz-core（零 I/O 类型、NIP-01 过滤器、Schnorr 验证）· buzz-relay（Axum WS + REST）
• 服务 — buzz-db（Postgres）· buzz-auth（NIP-42/98 Schnorr 认证、速率限制）· buzz-pubsub（Redis、在线状态、输入状态）· buzz-search（Postgres FTS）· buzz-audit（哈希链日志）。多社区模式按主机派生的社区对租户可观察行、缓存键、搜索文档、工作流状态、媒体元数据、git 仓库指针和审计链进行范围限定；共享基础设施是实现细节，而非用户可见的全局工作空间。
• 智能体操作面 — buzz-cli（智能体优先 CLI，JSON 输入 / JSON 输出）· buzz-acp（Goose/Codex/Claude Code 的 ACP 工具）· buzz-agent（ACP 智能体，见 VISION_AGENT.md）· buzz-dev-mcp（shell + 文件编辑工具）· buzz-workflow（YAML 自动化）· buzz-persona（智能体角色包）
• Git 与配对 — git-sign-nostr / git-credential-nostr（nostr 签名 git）· buzz-pair-relay / buzz-pairing-cli（中继配对）
• 共享 — buzz-sdk（类型化事件构建器）· buzz-media（Blossom/S3）
• 工具 — buzz-admin（管理 CLI）· buzz-test-client（E2E）

适用场景

• 事件记忆：凌晨 2 点输入“我们之前见过这个错误吗？”，监视频道的智能体拉取六个月历史，发布讨论串、根本原因、修复方案，并提议呼叫最后发布该代码的人。整个交流——问题、回答、证据——留在频道中。
• 分支即房间：打开功能分支，出现一个频道。补丁作为 NIP-34 事件落地，CI 发布结果，智能体运行首轮审查，队友对他们关心的部分做出反应，合并决策与证据落在同一房间。
• 自我编写的发布：工作流在标签上触发。智能体从项目频道读取已合并的 PR，起草发布说明，发布供人工审查，获得 👍 反应后发布。每一步都签名，每一步都可搜索。

限制

• 项目明确表示“尚未完成”，会告知哪些可用、哪些不可用。
• 文档中“Works today · Being wired up · Strong opinions, pending code”部分提醒：不要围绕 💭 列规划合规程序。
• 不是区块链。签名事件有用，但不需要每个人购买纪念币。
• 不是 AI 替代计划。Buzz 在人类留在环路中、智能体留在房间中时效果最佳。
• 默认自托管部署中，一个中继托管一个社区；托管多租户部署中，即使后端共享 Postgres、Redis 和对象存储，每个社区仍保持相同的语义边界。

许可与来源

Apache 2.0 · 由 Block, Inc. 构建。