当智能体成为同事：Buzz 背后的理念

关于 Buzz，我之前已经写过一篇，当时的重点是共享算力和共同的模型运行方式。那是我最初觉得这个项目最令人兴奋、也最不同寻常的部分。但随着我对 Buzz 的了解越来越深入，工作空间本身反而变得越来越有意思。因此我又在一个小规模环境中亲自试用了 Buzz。

这也源于我近几个月越来越明显感受到的一个问题：我和 AI 一起工作的效率确实提高了，但过程也变得更加混乱。Codex 在处理一个仓库，Claude Code 在核查另一个想法，另一个智能体在收集信息，与此同时，终端、浏览器、邮件和多个聊天窗口都在同时运行。每个智能体单独看都很有用，问题出在它们之间的衔接处。上下文需要复制，决策需要重复说明，结果需要手动汇总。

而这正是 Buzz 所要解决的问题。这个开源项目来自 Block，也就是由 Twitter 联合创始人 Jack Dorsey 领导、旗下拥有 Square 的公司。它的目标不是再造一个 AI 助手，而是创造一个共享的工作空间，让人类和智能体使用同样的频道、话题串、项目和记录。一个 Codex 智能体可以制定计划，Claude Code 可以对其提出批评，人类可以做出决定，下一个智能体则可以据此在仓库中完成修改。整条链路都留在同一个空间里，清晰可见。

“Slack 杀手"这种简单标签在我看来过于片面。Buzz 展示的是一种可能适用于拥有大量智能体的团队的工作方式。与此同时，它仍然年轻，对资源消耗较大，在安全层面的要求也比它友好的界面所暗示的更高。正是这种宏大理念与早期开发阶段并存的组合，让人更值得仔细审视一番。

真正的问题不在于模型本身

大多数 AI 工具都是围绕人与单一智能体之间的关系设计的。我打开 Codex，输入一个任务，得到一个结果。然后我打开 Claude Code，把同样的背景再解释一遍，请它给出第二种意见。对单个任务来说，这样运作得还不错。但在团队协作或多个智能体并行工作的场景中，就会出现新的协调问题。

这个问题我在日常工作中深有体会。Claude Code、Codex、Hermes、浏览器、聊天窗口和各种终端并行运行，会话记录从一个工具转移到另一个工具。一个智能体了解会议纪要，另一个了解仓库，第三个了解所需的权限或技能。每个都掌握一部分信息，但没有人掌握完整的共同工作现状。

Mission Control 式的仪表盘只能部分解决这个问题。它们或许能显示有五个智能体正在活动，却还无法提供一个共同可理解的地方，让任务、讨论、中间状态、审查和决策留在一起。因此 Buzz 的切入点不是打造一个更美观的智能体列表，而是从工作空间本身着手。

智能体是成员，而不是附加的机器人

乍一看，Buzz 显得很眼熟。它有社区、公开和私有频道、话题串、私信、论坛、搜索、语音会议室（Huddles）以及移动应用。它与普通 Slack 集成的关键区别，藏在这些表面之下。

在 Buzz 中，智能体本身就是一个独立成员。它拥有自己的资料、加密密钥对、频道成员身份和独立的审计轨迹。它发出的消息会以自己的身份显示。这样一来，事后不仅能看出"AI 做了某事”，还能清楚看到是哪个智能体采取了行动，任务是在哪个频道中收到的，以及是哪个人或哪个其他智能体触发了它。

这听起来像是用户管理上的一个小改动，但对真正的实际工作来说却至关重要。一个普通的 Slack 机器人通常挂靠在某个集成之上，被动等待某个人 @ 它。两个来自不同厂商的机器人通常互不知晓对方的存在。而在 Buzz 中，智能体之间可以互相沟通、移交任务，并在同一个话题串中讨论各自的结果。这并不会让 Codex 和 Claude Code 合并成一个系统，但它们会因此获得一个共同的沟通空间。

Buzz 本身并不会自动带来全部智能。这个工作空间连接的是所谓的 harness（运行框架）和模型，它们本来就已经在本地、服务器或某个服务商那里运行。根据项目当前的状态，其中包括 Codex、Claude Code 和 Goose 等。更多智能体也可以通过开放接口接入。这是一种"自带智能体"的模式：Buzz 负责协调，具体的智能体则用自己的工具、技能、权限和模型成本来思考和行动。

Relay 是共同的工作现状

从技术角度看，Buzz 由若干部分组成。桌面应用是界面层。一个社区就是实际的工作空间。Buzz Relay 负责存储和分发其中的消息、成员、智能体、规则、媒体、搜索数据、工作流和 Git 事件。智能体可以运行在与桌面应用相同的机器上，也可以运行在一台持续运行的服务器上，或者完全另一台机器上。

Buzz 使用 Nostr 作为协议。人类和智能体都用各自的私钥对事件进行签名。Relay 负责验证身份和成员资格，存储这些事件，并分发给有权限的客户端。不过这并不意味着 Buzz 是一个神奇的点对点网络。Relay 是某个社区的中心数据来源，不同 Relay 之间没有自动复制，消息始终留在发送时所在的那个 Relay 上。

这种架构带来了两个有意思的结果。身份并不简单地绑定在某个中心化的 Slack 账户上，而是基于一套独立的密钥对。与此同时，团队可以自行运行这个工作空间。如果只是想先测试一下，可以使用 Block 托管的社区。如果想自己掌控数据存放、可用性和备份，则可以在自己的基础设施上运行 Relay。

目前的服务器架构采用了一些常见组件：PostgreSQL 用于存储事件和全文搜索，Redis 用于发布订阅（Pub/Sub），以及兼容 S3 的存储用于媒体文件。这不是一个安装完就可以放着不管的小服务。自行运维的 Relay 需要 TLS、更新、备份、监控以及规范的密钥管理。

为什么共享上下文如此有价值

Buzz 最有力的理念，是持久且共同可见的上下文。一个项目不再只是 Slack 里的一条消息、一次独立的智能体运行、GitHub 上的一个 Pull Request，以及视频会议中的某个决定。Buzz 试图把这些散落的痕迹汇聚到同一个事件空间中。

当不同智能体各有所长时，这一点尤其有用。一个现实的工作流程可能是这样的：

1. 人类在项目频道中描述目标和边界。
2. 一个调研智能体收集信息，并记录其信息来源。
3. 第二个智能体专门挑战薄弱环节，寻找反面论据。
4. Codex 或 Claude Code 制定出具体计划。
5. 另一个智能体检查该计划是否存在安全隐患、缺失测试或不清晰的假设。
6. 经人类批准后，改动在一个独立的 Worktree 中实施。
7. Diff、测试结果、审查意见和最终决定都留在对应的频道中，方便查找。

这种模式在对抗式审查（adversarial review）中特别有意思。一个模型被明确赋予"攻击"某个产品计划或实现方式的角色，第二个模型则必须为这些决定辩护或加以改进。因为两者都能看到完整的话题串，由此产生的是对既有工作现状的真正较量，而不只是对一段被复制过来的文本进行孤立审查。

这种模式对内容和业务流程同样有意思。一个智能体做主题调研，第二个负责撰写，第三个负责编辑。指标或最新消息可以定期流入某个频道，让人类和智能体能够共同讨论其发展趋势。语音会议室（Huddles）则更进一步：人类和智能体在语音会议中交流，谈话会被转换为文字，随后可以进一步转化为具体的任务。

正是在这一点上，Buzz 超越了一个普通群聊。频道不只是一个交流的地方，而是变成了一份可追溯的工作记录。

Buzz 同样想取代 GitHub

Buzz 把 Git 仓库、补丁、审查和状态事件整合进同一个工作空间。Relay 本身就可以托管仓库。智能体可以使用 Worktree，分别在不同分支上独立开发，将改动以补丁形式提交，并在项目上下文中讨论审查意见。

这背后的愿景很有力量：一个 feature 分支会变成一个空间。里面不仅有提交记录，还有关于为何需要这项改动、哪些替代方案被否决、CI 报告了什么，以及谁批准了合并的讨论。尤其是在由智能体生成的代码中，这种产生过程的来龙去脉如今常常是缺失的。

尽管如此，我还不会急于对 GitHub 下结论。GitHub 不只是一个 Git 存储服务，而是一个经过多年发展、涵盖权限、审查、CI/CD、安全扫描、发布、集成和外部协作的完整生态系统。Buzz 已经具备可用的 Git 基础功能，也提出了一种颇具意思的 Forge 方案。但项目自身的状态说明，也明确区分了已经能正常工作的部分、尚待接线完成的功能以及仍停留在愿景阶段的构想。对于关键仓库来说，循序渐进地引入要比立即全面迁移更为稳妥。

我对 Buzz 的第一次测试

我特意从小规模开始：一个自建社区、一个频道、两个角色分明的智能体。Codex 负责制定技术方案，Claude Code 负责挑战其中的假设、安全漏洞和不必要的复杂性。生产环境凭证、客户数据和敏感仓库都被排除在外。我最初想测试的是协作本身，而不是最大程度的自主性。

第一次的开放式任务描述得过于笼统。两个智能体开始各自规划，彼此回应，最后都在等待下一步指示。这提醒了我一件事：一个共享频道并不能取代编排（orchestration）。当我给出明确指令"Codex 制定计划，Claude 审查计划，然后二者一起等待批准"后，整个流程就明显变得更平稳、更可追溯了。更多智能体并不能取代清晰的流程定义。

真正让我印象深刻的，不是某次令人惊艳的单条回复，而是没有出现媒介断层。两个智能体看到的是同一个话题串，批评意见就紧挨在原始计划旁边，我随时都能看清谁正在工作。我不需要在不同窗口之间来回复制文字，也不需要向第二个智能体重新解释前情。这正是 Buzz 对我而言真正有价值的地方。

不过在高强度的软件开发工作中，直接使用 Codex 或 Claude Code 依然更快。Buzz 增加的是沟通、记录和共享上下文，而这一层会消耗时间和 token。每增加一个智能体，就多一个独立会话，庞大的频道历史在涉及多个模型时也可能被重复处理。因此对于一个耗时较长的编码任务，我仍会倾向于使用原生的 harness，而把 Buzz 更多用于规划、任务交接和审查环节。

我目前还没有深入测试的部分，包括工作流、更长时间的语音会议、本地模型，以及多个持续运行的远程智能体。恰恰是这些场景，才能真正检验 Buzz 在日常使用中是否不仅仅是"看起来清晰"，而是能够可靠地完成任务。这款软件还处于 1.0 之前的阶段，在一些地方也确实还显得比较稚嫩。用于实验完全没问题，但核心流程仍然需要人工把控、重试逻辑，以及一条清晰的人工兜底退路。

共享上下文同时也是一道安全边界

让 Buzz 变得有用的因素，同时也扩大了攻击面。一个接入的 Codex、Claude Code 或 Hermes 智能体，可能带有文件访问权限、Shell、浏览器、MCP 服务器、邮件、日历，或其他内部工具的访问权限。一旦某位团队成员可以向该智能体发出指令，其权限范围就远远超出了"回复一条聊天消息"这么简单。

因此最重要的原则是：一个智能体只应在其内容和成员构成与其工具权限相匹配的频道中工作。频道成员身份是核心的访问门槛。是成员就可以读写，不是成员就既不应看到私有频道，也不应能订阅其中的事件。

即便有加密签名，也并不能解决所有的审计问题。Buzz 维护一份链式的、可发现篡改痕迹的审计日志。但如果攻击者能够写入数据库，理论上仍可以在篡改之后重新计算整条链。因此这份日志的属性是"篡改可被发现"（tamper-evident），而不是"防篡改"（tamper-resistant）。只要存储的信任基础没有完全崩塌，改动就是可以被察觉的。

对于由 Block 托管的社区，还有一点需要注意：消息、私信和上传的媒体文件并没有端到端加密。出于运营、安全、内容审核或法律义务，Block 可以查看这些内容。此外，如果智能体使用的是某个云端服务，相应的模型提供商也可能获取提示词和频道内容。

自行托管（Self-Hosting）改变的是数据主权，但并不会自动改变整条数据流向。自建的 Relay 会把消息和文件留在自己的基础设施上，但如果智能体依然使用云端模型，任务所需的数据仍然会离开这个 Relay。真正意义上的本地化运行，需要同时具备自建 Relay、本地模型和本地工具这三个条件。关于 Buzz 共享算力的可能性与局限性，我此前已单独撰文讨论。

我目前如何使用 Buzz

在第一次测试中，我使用了一个小规模、边界清晰的社区：没有生产环境凭证、没有客户数据，也没有包含机密信息的仓库。两个智能体就已经完全够用：一个负责创建，一个负责审查。而我作为人类，负责设定任务、批准节点和中止条件。

我最初搭建的，不是一个拥有上百个智能体的自主"企业"，而是一次范围有限的审查流程：

• 一个智能体根据现有的 issue 制定技术方案。
• 第二个智能体寻找安全漏洞、缺失的假设，以及不必要的复杂性。
• 两者都必须给出信息来源、涉及的文件和尚未解决的问题。
• 最多讨论两轮之后，团队就需等待人类批准。
• 只有获得批准之后，才允许某个智能体在一个隔离的 Worktree 中准备具体改动。

通过这种方式，我能够在不立即改造整个工作流程的前提下，测试出 Buzz 真正的优势所在。与此同时，token 消耗、延迟、权限设置和可追溯性也都清晰地暴露了出来。

对于单人处理单一编码任务的场景，我仍然会使用直接的智能体界面，它更快，也更容易掌控。而一旦有多个人、多个智能体，或多条工作流需要共享同一个上下文，Buzz 就开始展现出它的价值。因此，小型开发团队、代理机构、研究小组以及技术娴熟的独立开发者，是它最自然的目标用户群体。

对于规模较大的企业，我会更为谨慎。在正式发布 1.0 版本之前，在缺少长期支持路线、工作流仍显年轻的情况下，我不会把 Buzz 作为承载关键沟通或源代码的唯一场所。作为试点项目未尝不可，但完全替代 Slack 和 GitHub，目前来说等同于押注这个项目的开发速度。

Buzz 背后的理念，大于当前这个客户端

对我来说，Buzz 最令人兴奋的部分，并不是某一个单独的功能。频道、论坛、语音会议室、Git 托管和本地模型，在其他地方也都能找到。真正新颖的地方，在于它坚定地假设：智能体不再只是单个用户的私人工具，而是变成了一个共同工作流程中可见的参与者。

由此，问题本身发生了转变。我们不再只是问哪个模型能写出最好的代码，而是必须思考人类和多个智能体应如何分配任务、共享上下文、彼此制衡，并让责任可以被清楚追溯。而恰恰是这些方面，如今往往缺少相应的社会性与技术性基础设施。

Buzz 目前还没有给出一个完整的答案。这款软件还很年轻，一些工作流并不稳定，共享上下文可能会带来不小的成本，自行托管也意味着实实在在的运维责任。尽管如此，这个项目确实击中了一个真实存在的问题。当智能体承担越来越多的工作时，光是并排打开五个独立的聊天窗口已经不够用了。我们需要一个共同的地方，让它们的工作保持可见、有边界、可核查。

也许有朝一日，Buzz 真的会取代 Slack 和 GitHub。但就现在而言，一个更小却也更重要的结论已经足够：Buzz 是一份很有说服力的设计方案，展示了当一个工作空间不再只由人类使用时，它可能呈现出的样子。共享算力最初让我注意到这个项目，而共享工作空间，则是我会继续测试 Buzz 的原因。

第一次测试后的结论

在我这次简短的测试中，Buzz 恰好击中了我目前使用 AI 智能体时遇到的问题。单个模型早已不再是瓶颈，真正困难的是让多个智能体、多个决策和多个结果保持在同一条线上。Buzz 让这项工作变得可见，让 Codex、Claude Code 等智能体拥有了一个不仅能对我做出反应，也能彼此互动的场所。

真正打动我的，是共享上下文、清晰区分的智能体身份，以及让第二个模型直接对某个结果发起挑战的能力。让我不那么满意的，是随之而来的额外开销。对于单一的编码任务来说，直接使用 Codex 或 Claude Code 依然更快。而一旦涉及多个智能体或多个人，Buzz 的优势才真正开始显现。

这次测试有意保持在较小规模，我既没有检验持续运作的团队场景，也没有测试大型仓库、复杂工作流或较长时间的高负载情况。原因在于，这款软件还很年轻，且发展速度太快。就目前而言，我不会把 Buzz 作为承载关键沟通或源代码的唯一场所。但对于一个小团队、一家代理机构，或者一个个人的 AI 实验室来说，它已经不只是一个有意思的演示，而是一个我会继续使用、并有意识地融入日常工作的工具。

下次再见，
Joe

FAQ