Jack Dorsey 推出 Buzz：Block 想把员工、AI 智能体和代码仓库放进同一个工作空间

Block 联合创办人 Jack Dorsey 推出开源工作空间 Buzz，目标将人、AI 智能体和代码仓库整合到同一协作系统，减少对 Slack 和 GitHub 的依赖。Buzz 以 Nostr 身份系统为基础，强调身份可携带与自托管，但当前去中心化实现仍有限，能否取代既有工作流取决于稳定性、安全与团队采用意愿。

Block 联合创办人 Jack Dorsey 7 月 21 日宣布推出 Buzz，这是一款开源工作空间，目标是把“人”和“AI 智能体”放进同一套协作系统中，并减少团队对 Slack 和 GitHub 的依赖。Dorsey 在 X 上写道，Buzz 是“for teams of people and agents of all sizes”，并称它“model-agnostic, decentralized, self-sovereign, and open source”。Block 的官方公告也把 Buzz 定义为一个“where people and agents work together”的产品，Buzz 官网则进一步写明，它希望成为面向“human + agent teams”的原生工作区。Block 官方公告｜Dorsey 的 X 帖子｜Buzz 官网｜GitHub 仓库

Buzz 想解决什么问题

根据 Buzz 官网，这个产品的核心思路不是再做一个聊天工具，而是把聊天、任务分派、项目管理、编码和 PR 放到同一界面里。网站写道，用户可以在同一空间里与同事和专门的智能体聊天，然后直接进入 planning、project management、coding 和 PR 流程。Block 官方页面还提到，Buzz 不是给“代理”单独开一个侧边栏，而是让它们成为工作现场的一部分，参与对话、协作和后续动作。

在 GitHub 上，Buzz 被标注为 Apache 2.0 开源项目，仓库主页显示它已经进入可试用阶段。Buzz 官网也提供了下载链接，并写明“Come test the early stages with us”，说明这个产品目前还处在早期打磨期。

从外部报道看，Buzz 的定位相当明确。TechCrunch 把它描述为一个“puts humans and their AI agents in the same conversations”的工作平台，并认为它像 Slack 与 GitHub 的组合体；RuntimeWire 则进一步概括为“team chat, AI agents and Git hosting”的自托管工作空间。TechCrunch｜RuntimeWire

关键不只是“聊天”，而是身份系统

Buzz 最值得注意的地方，可能并不是它把哪些功能放进来了，而是它选择了什么样的底层结构。Block 在官方公告中说，它之所以选择 Nostr，是因为多智能体协作最根本的问题是身份：每个参与者，无论是人还是智能体，都持有属于自己的加密密钥对，身份不依赖单一平台账户或某一家供应商的 API key。

这意味着，Block 想把“智能体是谁”这个问题从平台账户中拆出来，让身份、历史和信誉可以跨系统迁移。对一家希望让员工、智能体和代码仓库都在同一个协作面里运转的公司来说，这种设计有明显吸引力：它把工作上下文、审计记录和参与者身份绑定在一起，而不是分散在多个工具里。

但 Buzz 的“去中心化”并没有外界想象中那么彻底。RuntimeWire 的报道指出，Buzz 目前的 relay 架构仍然是按部署单独运行的，现阶段并没有点对点事件交换、gossip 层或 relay 之间的复制。换句话说，它的去中心化更多体现在部署归属和身份可携带性上，而不是一个完全分布式、无需中心 relay 的网络。RuntimeWire

这条产品线放在今天，意义更大

Dorsey 对 Buzz 的包装，与他近来谈 AI 的方式是一致的：AI 不只是提升个体效率的插件，而是应该改变组织如何协调工作。Buzz 正是把这种想法具体化的一次尝试。它试图把原本分散在聊天、任务系统、代码托管和自动化工具里的流程，重新收拢到一个工作表面上。

这也让 Buzz 与 AI 行业最近一轮“工作界面重写”潮流形成呼应。AI Flux 近期对 OpenAI 发布 ChatGPT Work，把 ChatGPT 推向“做完工作”的阶段 和 微软启动 Teams 智能体系列：把对话直接做成工作结果 的报道，都指向同一个方向：AI 正从“回答问题”转向“完成工作”，而竞争焦点也从模型能力延伸到工作入口本身。

对 Block 而言，Buzz 是把这一变化做成开源、自托管、以身份为中心的一次下注。它能否真正从 Slack 和 GitHub 手里拿走工作流，还取决于稳定性、安全性、权限治理，以及团队是否愿意为“一个空间里做完所有事”重构自己的协作习惯。