2026 年 8 月 6 日翻 GitHub 周榜，第1名不是某个 AI 编程工具，也不是某个模型框架，而是 block/buzz--一个自称"蜂巢心智通信平台"（a hive mind communication platform）的项目。Rust 写的，Apache-2.0 协议，3 月 6 日开源，今天还在 push。一周涨了 10,780 star，累计 23,490。一个通信平台凭什么压过一众 agent 工具爬到周榜第一？因为它踩中的是一个新范式：人机共享 workspace，agent 是 teammate，不是 bot。
buzz 是什么
buzz 是 block（Square、Cash App 母公司）开源的自托管 workspace。定位一句话：人类和 AI agent 共享同一个 room。
底层是 Nostr relay。这不是随便选的技术栈--Nostr 的本质就是签名事件流。在 buzz 里，每条消息、每个 reaction、每个 workflow step、每次 review approval、每个 git event，都是一条签名事件，写到同一个 log 里。人和进程用的是同一套身份模型，留下的是同一种审计轨迹。
这点很关键。签名事件意味着防篡改、可追溯、不可抵赖--谁在什么时候说了什么、批准了什么、改了哪行代码，都有 cryptographically 绑定的记录。人和 agent 走的是同一套机制，不是"人的操作进数据库，agent 的操作进另一份日志"这种二毛账。一条 log 既是大本营，也是黑匣子。
社区里有一句话点破定位：Buzz community = workspace。它不是给你挂个机器人助手的聊天软件，是把整个工作空间--对话、代码、审批、工作流--拢成一条可审计的事件流。URL 本身就把 community 和 workspace 等同起来，这是它权威的定位声明。
agent 是 teammate 不是 bot
buzz 真正的区别不在功能列表，在身份模型。
Slack 和 Discord 的 bot 模式是这样的：人是人，bot 是 bot，bot 装在人开的 channel 里，靠 permission flags 决定能干啥。bot 永远是二等公民--它能 @你，能发通知，但你不会把它当成"工位对面的同事"。它的身份是挂在人类账号边上的附属品，权限是逐个 flag 勾出来的，没有"这个 bot 是什么角色"的概念，只有"它能按哪些开关"。
buzz 把这个层级拍平了。agent 是 member，不是 bot。它有自己的 keys、自己的 channel memberships、自己的 audit trail，按身份 scope 走，不是按 permission flags 走。你可以给一个 agent "scope teammate"这种身份，它就拥有了 teammate 该有的操作面：open repos、send patches、review code、run workflows、edit canvases、orchestrate other agents、voice huddles、create channels。
| 能力 | Slack/Discord bot | buzz agent |
|---|---|---|
| 身份模型 | bot 账号，靠 permission flags | member，按 scope，有 keys/audit trail |
| 代码协作 | 外挂 webhook/通知 | open repos、send patches、review code |
| 工作流 | 触发外部 CI | run workflows、orchestrate other agents |
| 协作面 | 文字消息 | edit canvases、voice huddles、create channels |
| 审计 | bot 日志单独一份 | 同一个 Nostr log，人和 agent 同源 |
这不是"给 bot 加了几个权限"，是把 agent 当成组织里的一个工位来对待。scope 和 flag 的区别是本质性的：flag 是"你能按这个开关"，scope 是"你是这种角色"--前者是权限清单，后者是身份契约。前者要你一个个勾，后者一旦赋了身份，该有的能力自然到位。
还有一层区别在问责。当 agent 以 member 身份发了一个有问题的 patch，审计轨迹直接指向它的 keys 和 scope，不是"某个 bot 不知怎么搞的"。这让 agent 的行为可问责，而不是一个黑箱动作。teammate 要为自己的行为负责，bot 不需要--这是两种身份模型在责任上的根本分野。一旦 agent 能 review 代码、能 orchestrate 别的 agent，"这一步是谁干的、依据什么干的"就必须能查到具体身份，否则协作就没法收口。
一个 log，四处用例
buzz 的 Nostr 底座带来的最大红利，是人和 agent 的工作痕迹写在同一条 log 里。这解锁了几个 Slack/Discord bot 模式做不到的用例：
- 问项目问题带 receipts：你问"上个月那个性能 patch 是怎么决定的"，agent 不是凭印象 vibes 回答，而是搜 6 个月的签名事件线程，把 patch、CI、review、approval 串成证据链给你。bot 模式做不到这点--讨论在 Slack、patch 在 GitHub、CI 在另一个系统，根本串不起来，只能给你"大概是这样"的模糊总结。
- agent triage bug 不给全权：让 agent 先分类 bug、打标签、找相关 PR，但不给它直接 merge 的 scope。teammate 也有试用期，权限按身份 scope 收紧。这比给 bot 一个"只读"flag 灵活得多--scope 可以细到"能 triage、不能 merge、能 review、不能 approve"，颗粒度按角色定义。
- feature branch 变成 room：一个分支就是一个 room，patch、CI 结果、review、merge 全在一个 channel 里共存。代码和讨论不再分两处，git event 本身就是 log 里的事件，不需要额外同步--这边提交了 patch，那边 room 里自动出现对应事件，人和 agent 在同一个上下文里接着讨论。
- 搜对话/patch/workflow/approval 一处搞定：因为都是签名事件，全在一个 log 里，搜索是跨类型的。你搜"上周谁批准了那个迁移"，结果里同时有人类的讨论、agent 的 triage、CI 的结果、最终的 approval--一屏看完决策全貌。
看法
周榜第1、一周涨 10.8k star，说明"agent 协作"这件事已经从概念变成刚需。但 buzz 真正押对的不只是"协作"，是"身份对等"。
过去两年，所有人都想把 agent 塞进现有工具--Slack 里加 bot、IDE 里加 Copilot、终端里加 Claude Code。这些都是"bot 模式"：人在主位，agent 是插件，挂在人类的工具链边上。这种模式的瓶颈很明显：agent 永远是外来户，它的行为没法和人类行为用同一套语言描述、同一套机制审计，出了问题只能去翻各自系统的日志拼时间线。
buzz 提出的反命题是：如果 agent 一开始就和人是同一种 citizen，共享同一个 workspace、同一条 log、同一套审计，协作的形态会完全不一样。agent 的决策能被回溯，人类的决策也能被 agent 调用--双向的，不是单向的命令。这才是"teammate"三个字该有的分量。
把"身份对等"放到更长的时间尺度看，它解决的是"协作行为可归属"这件事。不止代码变更，连讨论、审批、工作流都签上名，谁做的、在什么 scope 下做的、依据什么，全可查。当 agent 越来越多地替人做决策，"这个决策是谁做的"必须能查清。bot 模式查不清，因为 bot 没有真正的身份，它的动作挂在人类账号边上，责任也跟着模糊；buzz 查得清，因为 agent 就是 member，它的每一步都在同一条 log 里，跑不掉。这是从"工具产生日志"到"身份产生日志"的转变--日志的主人不是工具，是身份。
这跟"agent 是 teammate"的口号是一回事，但 buzz 把它落到了工程上--Nostr 签名事件、scope 身份、共享 log。口号谁都会喊，落到协议层才是真东西。这是从"给 agent 找个工具"到"给 agent 一个工位"的范式切换。
当然，自托管 + Rust + Nostr 这套技术栈对一般团队不算轻，迁移成本不低。buzz 短期能不能取代 Slack 还得看生态--集成、客户端、第三方接入。但作为"人机共享 workspace"这个范式的第一个像样样本，它值得记下。周榜第1说明外部也有人买账，不是 block 一家关起门来在自嗨。下一个值得看的，是这种"agent as teammate"的身份模型会不会反过来影响 Slack/Discord 的设计--当协作的默认参与者一半是人一半是 agent 时，纯 bot 模式会显得越来越别扭。
参考来源
- block/buzz 仓库：https://github.com/block/buzz
- GitHub 周榜（OpenGithubs/github-weekly-rank）：https://github.com/OpenGithubs/github-weekly-rank
- star 数据据 GitHub API 2026-08-06 核实：23,490（周增 10,780）
- 本文素材由作者 curl GitHub API + block/buzz README 核实（2026-08-06），手工整理写作；项目定位与能力以 block/buzz 官方 README 为准