📌 项目地址：block/buzz | ⭐ 20,956 颗星 | 🔧 Rust | 📜 未标注
Buzz 这个仓库值得细读，不是因为 20956 个 star，而是它重新定义了一个问题：AI 代理在团队工作区里，到底该以什么身份存在。
README 第一句就说明了它的位置：A workspace where humans and agents build together, on a relay you own。一个自托管的工作区，人和代理在同一间屋子里干活。它底层是 Nostr relay——所有消息、反应、工作流步骤、评审意见、git 事件，都是同一条日志里的签名事件。同一种结构，同一个身份模型，同一份审计轨迹。作者是人是进程，系统不区分。
我翻完 README 后，觉得真正值得拆的是它怎么处理”代理”这个角色。这决定了整个产品的气质。
代理是成员，不是 bot
多数 AI 协作工具里，代理是挂在系统边上的插件。你配一组 API 权限，它调接口替你干活，能力边界由 permission flags 枚举出来。要在新场景里用代理，就再加一条规则。
Buzz 换了个做法。README 原话：Add an agent to a channel the same way you add a person. 把代理加进频道，和加一个人完全一样。代理有自己的密钥对，有自己的频道成员资格，有自己的审计轨迹。没被邀请的频道，它进不去，签不了名。
这里的关键不是”代理有权限”，而是”代理有身份”。权限可以被授予、被撤销、被绕过；身份是结构性的。一个代理在哪些房间，决定了它能签什么事件、能触发什么动作、能接触到什么数据。
后果是什么？ README 里说：Scoped by identity, not by permission flags — the same way you’d scope a teammate。代理的边界由”它在哪”决定，不是由”它被允许做什么”决定。去掉了一整层授权管理。
人和代理共用一套语法
这个选择往下推，会得到一些有意思的结果。
传统工具里，人和工具的交互模型是两套：人点按钮，工具调 API。Buzz 里只有一种交互单位——签名事件。代理发 patch、代理审代码、代理跑工作流、代理改画布——每个动作都签名进日志，和人类成员的动作用一样的格式。
这意味着几件事。
首先是审查。人和代理都在同一份日志里留痕，协作的历史是单一序列，不存在”人类的对话”和”代理的操作”两个分开的抽屉。查某个功能为什么被合并，从频道消息一路追到 CI 运行、代码评审、合并决策，都在同一条链上。
其次是交接。README 举了个具体场景：把 feature branch 变成房间，让 patch、CI、评审、合并决策都发生在同一个 channel 里。人等代理的检查结果，代理等人确认合并，都在同一处，没有跨系统切换的损耗。
搜索也变成统一的了。对话、patch、工作流运行、审批，全部归档成同类事件。README 说：Search the conversation, the patch, the workflow run, and the approval in one place — because they’re all the same kind of event. 不需要分别去代码平台、CI 平台、聊天记录里翻。
代理能干的活，超出”聊天”
README 列了代理在 Buzz 里可以做的操作：开仓库、发 patch、审代码、跑 workflow、编辑画布、编排其他代理、进语音 huddle、建频道、拉人进来。
我注意到一个细节：agents have the same surface area as humans。代理和人类拥有一样的操作面。你加一个人的时候能做的一切——把它放进某个频道、给它看某些内容、让它参与某个流程——加代理时都适用。没有”代理专用接口”，也没有”人类专用权限”。同一个事件日志，同一套身份模型。
这意味着安全边界的设置思路也变了。不必再为代理单独设计一套最小权限策略，只需要按管理团队成员的方式来管理它：这个代理需要知道什么，就把它放到哪个房间。
还有一个具体的功能：Ask the project a question and get an answer with receipts. 代理回答问题时，会去搜索六个月的历史记录，然后贴出相关帖子的链接。不是给结论，是给证据链。因为所有事件都在一个日志里，这个搜索是天然可行的，不需要额外打通多个数据源。
自托管的意义
README 里有一句：The URL is authoritative for the workspace，and all tenant-observable state under that URL is community-local. 在一个默认的单 relay 部署里，一个 URL 对应一个社区。托管运营商可以在多个域名后面挂很多社区，但客户端规则始终不变——URL 决定你进入哪个工作区，URL 之下的所有状态都是社区局部的。
这个设计解释了”on a relay you own”的分量。自托管不只是一个部署选项，它是数据边界的具体载体。谁拥有 relay，谁就拥有日志——包括日志里所有人和所有代理的行为记录。
仓库用 Rust 写，Apache 2.0 许可。单 event log 覆盖所有交互，签名密钥统一身份，社区边界由 URL 确定。这三条拼在一起，Buzz 描述的是一个具体的、需要亲眼看一下的架构选择，不是又一个”AI 赋能团队协作”的套话。
至少对我而言，值得关注的是它对代理身份的取舍——让代理以成员身份存在，不设特殊通道。这个取舍带来的收尾方式，值得看它实际跑起来之后长什么样。