block/buzz

如果你的团队已经在用编程代理，却把它们的产出散落在聊天线程、PR 和私人会话里，Buzz 值得看一眼。它是一个可自托管的频道式工作空间，核心赌注是让代理以成员身份加入频道，而不是作为外挂机器人存在。

解决什么问题

假设你想知道某个错误以前是否出现过，或者想把一个功能分支的补丁、CI 结果和评审讨论放在一处。现在这些上下文是割裂的：代理在自己的会话里干活，发现被粘贴进团队聊天，合并决定背后的理由留在 PR 线程里。Buzz 改变的是产出落地的地方：频道本身成为记录。你在房间里提问，代理检索该社区的历史，把相关线索和证据贴回来，问题、回答和链接留在一起。最终得到一条可以回头查的记录。

有什么不同

在当前交付的单 relay 模式下，一个 relay URL 对应一个社区，人、代理、工作流和仓库共享同一套身份模型和同一份事件日志（项目说明）。这个设计比功能清单更重要：代理有自己的密钥、自己的频道成员关系和自己的审计记录，访问范围按团队成员的方式划定，而不是靠权限开关。README 举的例子包括代理分诊 bug、一个把 NIP-34 补丁事件、CI 结果和代理初审放在一起的分支频道，以及由消息、表情回应、定时或 webhook 触发的 YAML 工作流。桌面端是 Tauri 加 React，另有一个面向 LLM 工具调用的 CLI：JSON 输入、JSON 输出（CLI 目录）。

代价是铺得太广。这是一个年轻平台，同时想做聊天、代理运行时、工作流引擎和仓库集成。README 自己的状态表把"今天可用"（relay、频道、线程、私信、画布、媒体、搜索、审计日志、桌面应用、CLI、YAML 工作流）和仍在接通中的部分分开，后者包括移动客户端、工作流审批闸门、huddle 生命周期事件和推送通知。使用时要习惯这条分界线。

谁值得试

适合的是这样一支小工程团队：已经把调研、实现和初审交给代理，并且希望这些对话积累在有自主控制权的 relay 上的共享房间里。"分支即房间"这个说法足够具体，可以直接拿去和现有的 issue 跟踪与 PR 流程对照。不适合的是只需要普通群聊的团队，或者想要成熟移动优先客户端的个人：移动端被列为进行中，桌面应用才是眼下现实的入口。

使用条件与边界

最轻的尝试方式是打包好的桌面版，发布页提供 macOS、Linux 和 Windows 安装包（最新发布），其中 Windows 版标注为 alpha 且未签名。自建 relay 是另一件事：可以一键部署到 Railway（Railway 部署），也可以用生产用 Compose 包，包含 Postgres、Redis、MinIO 和可选的 Caddy/TLS（Compose 包）。根目录的 docker-compose 文件明确只用于开发。

从源码构建需要 Docker 加 Hermit，或者 Rust 1.88+、Node 24+、pnpm 10+ 和 just，然后执行 just setup 和 just build，日常运行用 just dev（Docker、Hermit）。这是实打实的工具链投入，relay 这边还意味着要长期维护 Postgres、Redis 和对象存储。自托管也意味着升级和你积累的审计数据都由你自己负责。

HotRepo 点评

HotRepo 在 2026-10-25 首次观测到 Buzz：36,439 星，当日 +85，只在每日榜出现一次；单次快照不足以判断关注度是持续还是消退。项目本身创建于 2026 年 3 月，年龄和趋势历史都很短。2026-06-22 的 Show HN 帖子获得 21 分、7 条评论（Show HN）；一位评论者说"事故记忆"的故事打动了他，因为组织里太多知识存在 Slack 里（评论），但这只是个人反应，不是社区结论。决定投入前值得确认一件事：状态表里"正在接通"的部分是否包含你工作流所依赖的能力。