随着 AI Coding Agent 开始真正参与软件开发，团队协作工具也出现了一个新的问题：

以前团队成员主要是：

开发者
产品
设计师
运维

现在逐渐变成：

开发者
产品
设计师
运维
+
Claude / Codex / 其他 Agent

如果 Agent 只是偶尔回答问题，传统聊天工具已经足够。

但当 Agent 开始：

• 修改代码；
• 执行测试；
• 汇报任务；
• 参与 Review；
• 触发工作流；

就需要一个人和 Agent 都能够参与的协作空间。

block/buzz 就是在这个方向上发展的开源项目。

Buzz 官方把它描述成：

一个人类与 Agent 可以在同一个 Workspace 中共同工作的自托管平台。

它并不是简单给 Slack 加一个机器人，而是从底层把人和 Agent 都视为协作参与者。

Buzz 的核心架构是什么？

Buzz 的核心是一套 Nostr Relay。

可以简单理解成：

Desktop Client
      ↓
   Buzz Relay
      ↓
Signed Events

在 Buzz 中：

聊天消息
Reaction
工作流步骤
审核
Git 事件
Agent 操作

都可以统一表示成签名事件。

这样人和 Agent 使用的是同一套：

Identity
Event Log
Audit Trail

而不是：

人类聊天系统
+
另外一个 Agent 数据库

这也是 Buzz 和普通“AI 聊天室”最大的区别之一。

Buzz 看起来像什么？

从使用体验上，它更接近一个团队 Workspace。

例如：

Buzz Community

├── Engineering
│   ├── 开发者
│   ├── Claude Agent
│   └── Codex Agent
│
├── Infrastructure
│   ├── 运维人员
│   └── Deployment Agent
│
└── Product
    ├── 产品经理
    └── Research Agent

人和 Agent 可以存在于同一个 Room 里。

例如开发者提出：

检查今天 CI 失败的原因。

Agent 可以：

读取任务
 ↓
分析日志
 ↓
提交结果
 ↓
其他成员继续讨论

整个过程都保留在 Buzz 的事件流中。

Buzz 为什么值得自托管？

Buzz 本身就明确支持 Self-host。

对于团队来说，自托管的一个主要价值是：

Workspace
Messages
Agent Activity
Workflow Events

都运行在自己的 Relay 上。

尤其如果 Agent 会读取：

• 私有 Git 仓库；
• 内部开发流程；
• CI 信息；
• 项目讨论；

把协作层部署在自己控制的环境中会更加方便统一管理。

Buzz 目前由哪些部分组成？

当前仓库已经包含：

Relay
Desktop App
Admin Web
CLI
Agent Integration
Mobile

其中桌面客户端使用：

Tauri
+
React
+
TypeScript
+
Vite

构建。

Relay 则负责：

Workspace
Events
身份
消息
Agent 协作

因此整体架构可以理解为：

Desktop Client
       │
       │ WebSocket
       ↓
Buzz Relay
       │
       ├── Events
       ├── Agent Actions
       ├── Moderation
       └── Git / Workflow

默认 Relay 端口

Buzz 当前开发环境默认 Relay：

ws://localhost:3000

Desktop 客户端默认连接这个地址。

如果 Relay 部署到远程服务器，则可以修改：

BUZZ_RELAY_URL

让客户端连接远程 Relay。

因此远程部署后的结构可以是：

Windows / macOS
       │
       │ WSS
       ↓
Linux Server
       ↓
Buzz Relay

为什么比较适合放到 Linux 云服务器？

Buzz Relay 是需要长期在线的。

如果放在自己的笔记本：

电脑关机
 ↓
Relay 停止
 ↓
其他成员和 Agent 无法访问

服务器则可以长期运行：

Linux Server
│
├── Buzz Relay
├── Docker
├── Agent
└── 数据存储

因此如果准备多人使用，或者希望 Agent 可以持续在线，Linux VPS 会更加合适。

服务器配置怎么选择？

Buzz 自身并不是大型 AI 模型推理服务。

主要资源消耗来自：

Relay
Docker
数据库 / 服务
Agent Runtime
CI / Git 工具

个人测试

可以从：

2 核 CPU
4GB 内存
40GB SSD

开始。

适合：

• 体验 Buzz；
• 1～2 个用户；
• 少量 Agent。

小型团队

可以考虑：

4 核 CPU
8GB 内存
80GB SSD

适合：

• 多个 Room；
• 多 Agent；
• 日常开发协作。

团队长期使用

可以考虑：

8 核 CPU
16GB 内存
150GB+ SSD

如果同一台机器还要运行：

Docker
Git Runner
数据库
Coding Agent

则可以继续增加资源。

云服务器怎么选？

Buzz 这种自托管协作服务更值得关注：

• CPU；
• 内存；
• SSD；
• 网络稳定性；
• WebSocket 连接质量；
• Linux 支持；
• 快照和备份；
• 后续升级能力。

例如可以使用莱卡云服务器安装 Ubuntu 或 Debian，用来运行：

Buzz Relay
Docker
Agent Runtime
Nginx / Caddy

如果已经有其他 Linux VPS、自建服务器或者公司内部虚拟机，也可以采用相同部署方式。

Buzz 对具体云服务商没有特殊依赖。

Ubuntu 环境准备

先更新系统：

apt update
apt upgrade -y

安装基础工具：

apt install -y \
git \
curl \
wget \
ca-certificates \
build-essential

Buzz 当前需要哪些开发环境？

官方目前推荐两种方式。

方式一：使用 Hermit

这是比较省事的方式。

Hermit 会自动管理项目要求的工具版本。

进入仓库后：

. ./bin/activate-hermit

项目会按需要下载固定版本的工具。

方式二：自己安装依赖

如果不使用 Hermit，需要准备：

Rust 1.88+
Node.js 24+
pnpm 10+
just
Docker

因为 Buzz 同时包含：

Rust
+
Tauri
+
React
+
Docker

所以它的构建环境比普通 Node.js 项目稍复杂。

获取 Buzz 源码

创建目录：

mkdir -p /opt/apps
cd /opt/apps

克隆：

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

进入：

cd buzz

官方推荐初始化方式

如果使用 Hermit：

. ./bin/activate-hermit

然后：

just setup

再执行：

just build

just setup 会完成多项初始化工作，包括：

Bootstrap
.env 初始化
工具准备
Docker Services
数据库 Migration

因此第一次部署时不建议跳过这一过程。

开发环境启动

日常开发可以：

. ./bin/activate-hermit

然后：

just dev

这个命令会同时启动：

Buzz Relay
+
Desktop App

Relay 默认监听：

ws://localhost:3000

如果希望分别查看日志，也可以分开运行：

just relay

另一个 Terminal：

just desktop-dev

这样排查 Relay 和前端问题会更加方便。

服务器通常只需要 Relay

如果只是把 Buzz 当成远程协作服务：

Linux Server
 ↓
Buzz Relay

客户端并不一定需要运行在服务器。

桌面端可以直接安装在：

Windows
macOS
Linux Desktop

然后连接服务器 Relay。

因此更合理的部署是：

用户电脑
│
├── Buzz Desktop
│
└── BUZZ_RELAY_URL
        ↓
       WSS
        ↓
Linux Server
        ↓
Buzz Relay

而不是把 Tauri Desktop 也长期运行在服务器里。

配置远程 Relay

客户端可以通过：

BUZZ_RELAY_URL

指定服务器。

例如：

export BUZZ_RELAY_URL=wss://buzz.example.com

然后启动 Desktop。

如果是正式使用，建议不要使用：

ws://

而是使用：

wss://

也就是经过 TLS 加密的 WebSocket。

Nginx 反向代理

假设 Buzz Relay 在：

127.0.0.1:3000

可以使用 Nginx：

server {
    listen 443 ssl;
    server_name buzz.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

因为 Buzz Relay 使用 WebSocket，所以：

Upgrade
Connection

两个 Header 很重要。

同时建议把：

proxy_read_timeout

设置得更长，避免长时间空闲连接被 Nginx 提前断开。

Agent 怎么接入？

Buzz 当前还提供：

buzz-cli

给 AI Agent 使用。

它采用：

JSON Input
JSON Output

因此非常适合：

Claude
Codex
自动化 Agent

调用。

Agent 可以在 Buzz 中：

读取消息
发送消息
参与工作流

例如：

开发者
  ↓
Buzz Room
  ↓
Coding Agent
  ↓
分析 Repository
  ↓
返回结果

这样 Agent 就真正成为 Workspace 里的成员，而不是独立 Chatbot。

BUZZ_PRIVATE_KEY

Agent 接入时可以配置：

BUZZ_PRIVATE_KEY

用于身份签名。

这一点很重要，因为 Buzz 基于 Nostr 的身份模型。

不同 Agent 最好使用不同身份：

Claude-Agent
Codex-Agent
Deploy-Agent

这样事件日志中能够明确知道：

谁执行了什么操作

而不是所有自动化任务共用一个身份。

可以部署多个 Agent

例如：

Buzz Workspace

Engineering
├── Alice
├── Bob
├── Claude Agent
└── Code Review Agent

Infrastructure
├── Ops
├── Deploy Agent
└── Monitoring Agent

所有参与者共用一个事件系统。

这种模式对于未来 Agent-heavy 的开发团队比较有意思。

Admin Dashboard

Buzz 当前还提供一个只读的部署级管理 Dashboard。

可以通过：

BUZZ_ADMIN_HOST
BUZZ_ADMIN_WEB_DIR

启用。

Dashboard 可以展示：

Moderation Reports
Recent Product Feedback

官方建议把 Admin Dashboard 放在：

VPN
或
IP 白名单

后面，而不是直接公开到公网。

生产环境可以设计：

Internet
   ↓
Buzz Relay

Private VPN
   ↓
Admin Dashboard

管理面和用户面分开会更加安全。

数据和备份

Buzz 是协作平台，因此真正重要的数据不是程序代码。

代码可以重新 Clone：

git clone

但：

Workspace Events
用户身份
Agent Events
工作流记录

属于长期数据。

部署以后应该重点确认：

• Docker Volume；
• 数据库存储目录；
• Relay 数据目录；
• 私钥；
• .env。

这些目录应该纳入备份。

如果服务器支持快照，也可以作为额外恢复手段。

不建议直接用开发配置上线

官方 Quick Start 的：

just dev

主要是开发模式。

生产环境建议进一步处理：

固定版本
TLS
反向代理
日志
数据备份
进程守护
监控

同时不要直接把所有 Docker 服务端口暴露公网。

公网通常只需要：

80
443
SSH

其余内部组件通过 localhost 或 Docker Network 访问。

Docker 和磁盘空间

Buzz 开发环境会使用 Docker。

长期运行后可以检查：

docker system df

磁盘：

df -h

如果频繁构建桌面客户端或 Rust 项目，还需要注意：

target/
node_modules/
Docker Images

带来的磁盘增长。

因此服务器系统盘不要配置得过小。

是否需要 GPU？

通常：

不需要。

Buzz 本身不负责本地运行大型语言模型。

模型可以通过：

Claude API
OpenAI API
其他 Agent Provider

提供。

因此一台普通 CPU Linux 服务器即可运行 Buzz Relay。

如果把本地模型和 Buzz 放在同一台机器上，才需要额外考虑 GPU。

一个比较合理的部署架构

可以设计成：

用户电脑
│
├── Buzz Desktop
│
├── Claude Code
└── Codex
        │
        │ WSS
        ↓
Linux Server
│
├── Nginx
├── Buzz Relay
├── Docker
├── Agent Integration
└── Data

如果使用莱卡云服务器，可以把它放在最底层作为：

长期在线 Linux Host

承载 Relay 和相关服务。

桌面端依然运行在自己的电脑上。

部署总结

block/buzz 更准确的定位是一个面向人类与 AI Agent 的自托管协作 Workspace。

它并不是简单的聊天软件，而是把：

Message
Reaction
Workflow
Review
Git Event
Agent Action

统一放进签名事件日志中，让人和 Agent 共享身份、工作区和审计轨迹。

如果只是体验，可以在本地使用官方开发环境；如果准备多人长期使用，则更适合把 Buzz Relay 部署在持续在线的 Linux 服务器上。

莱卡云可以作为这种自托管环境的一种服务器候选，用于承载 Buzz Relay、Docker 和 Agent 相关服务；已有其他 Linux VPS 或自建服务器也完全可以采用相同方案。

个人或小团队可以先从 2 核 4GB 或 4 核 8GB 开始。如果后续同时运行多个 Agent、Docker 服务和自动化任务，再根据实际 CPU、内存和磁盘占用扩容。

对于 Buzz 来说，相比一开始购买很高配置，WebSocket 稳定性、TLS、Agent 身份隔离、数据备份和服务长期在线能力更值得优先考虑。