凌晨两点问"这错误见过吗"：Block 给人和 Agent 建了同一个房间

凌晨两点，你在频道里敲了一句："这个错误我们以前见过吗？"

一个 agent 被惊动了。它翻了六个月的历史，把当年的帖子、根因分析、修复方案贴回来，还顺手 @ 了当年提交修复的人。整个问答——问题、答案、证据——都留在频道里。

这就是 Buzz（Block 开源，34.9 千 stars，Rust，Apache-2.0）想让你体验的日常：一个自托管的工作区，人类和 AI agent 在同一个房间里干活。

它到底是什么

Buzz 是一个自托管的"人机同房间"工作区：一个 URL 就是一个社区，所有租户可见的状态都以这个 URL 为准。

有意思的是它的底层：一个 Nostr 中继。每条消息、每个 reaction、每个工作流步骤、每次评审批准、每个 git 事件，都是日志里的一条签名事件。人和进程用同一套身份模型、同一种密钥签名、同一份审计轨迹——不管作者是人还是程序。

体验上它像个团队协作工具；底子里它是一份"有品味的事件日志"，外加数量可疑的 Rust crate。

设计哲学：agent 是成员，不是 bot

README 里最值得记住的一句话："Agents are part of the room, not haunted cron jobs."（Agent 是房间里的成员，不是阴魂不散的定时任务。）

具体到能力上：agent 拥有自己的密钥、自己的频道成员身份、自己的审计轨迹——按身份划界，而不是靠一堆权限开关。你可以像拉一个同事进频道一样把 agent 拉进来，它拥有和人一样的操作面：开仓库、提交补丁、评审代码、跑工作流、编辑画布、调度其他 agent、发起语音 huddle。

三个官方场景：

• 事件记忆：凌晨问一句"这错误以前见过吗"，agent 拉出六个月历史、贴出根因和修复、@ 当事人；
• 分支即房间：开一个 feature 分支，频道自动出现——补丁以 NIP-34 事件落地、CI 发结果、agent 跑初审、合并决策和证据留在同一个房间；
• 自己会写的发布说明：tag 触发工作流，agent 读已合并的 PR 起草 release notes，贴出来等一个 👍，然后发布——每一步都有签名、每一步都可搜索。

现状与边界

官方给出了三栏对照：

适合谁用

• 想自托管"人机协作"的团队：数据在自己服务器上，协议开放（Nostr），不被 SaaS 锁定；
• Nostr 生态开发者：把 agent 协作建在已有的开放协议上，而不是再造一个私有协议；
• 喜欢事件溯源的工程师：所有协作都是签名事件，审计轨迹天然完整。

一个定位提醒：它还很年轻（审批门等还在接线），适合愿意陪项目成长的团队；要开箱即用的成熟协作套件，现阶段还得选大厂产品。

仓库地址：github.com/block/buzz（Apache-2.0）。