长久以来，运营模式都由当时流行的工具塑造而成。Asana、Jira、Linear 将冲刺、周计划、看板等实践编码成一种仪式，公司可以系统化地执行以推动流程。工具塑造了运营模式，运营模式也塑造了工具。这并非最佳运营模式，只是当时工具能支持的最佳模式。当工具变得像 Buzz 这样可配置时，这些约束便消失了。现在，运营模式需要跟上工具所支持的能力。
当 Buzz 中的一个线程成为问题的诊断、任务、修复和讨论时，它将原本需要多个工具才能完成的工作浓缩到一个线程中，任何人都可以跟读。用户能从中获取完整的上下文，理解决策背后的原因。此外，Buzz 中的所有操作都有 CLI 命令，允许 Agent 创建自己的频道、更新自己的记忆，以及执行其他用户级操作。用户可以在设置 Agent 的行为、工具、模型和能力时，为 Agent 设定频道级或线程级的规则。如果这还不够，该应用还是开源的，用户可以修改、改进或贡献代码，让 Buzz 成为工作的标准界面。
Buzz 的可配置性如此之高，以至于问题不再是“它能不能做这个或那个”，而是“你如何设置它来精确实现你想要的”。我一直在尝试让 Agent 为每个线程生成一个白板，并在该线程中工作的所有 Agent 之间共享。这样能实现更优质的上下文交接，而无需我额外付出劳动，因为交互规则已经在频道中定义好了。还有更多值得尝试的方式。
有了如此大的灵活性，瓶颈就变成了运营模式。你如何调整自己的节奏和流程，以利用现有工具最大化产出？当用户可以直接在 Buzz 中把任务作为线程来跟踪时，项目跟踪工具的价值何在？当所有信息都由人类和 Agent 记录在线程中时，还有什么需要跟踪？
限制因素不再是用户从一个工具复制粘贴到另一个工具的速度。我们已经用 Buzz 实验了几个月，但尚未找到能最大化 Buzz 对组织价值的运营模式。用 Buzz 来开发 Buzz 本身，带来了一系列我们以前不会问的问题：Agent 之间正确的协作模式是什么？对于非工程类工作，这会发生怎样的变化？Agent 有效协作的最佳抽象层级是什么？你如何定义一组 Agent 在无需你介入的情况下良好协作的方式？如果 Agent 可以自己创建频道并只邀请其他 Agent，那么团队能在自动化上走多远？
就个人而言，探索新的协作方式的过程非常棒。最明显的一点是，我们还有太多需要尝试。
我们的工作很大一部分是协作性的，这一点在 AI 时代也不应改变。以 Buzz 作为界面和协调层，将所有要素整合在一起，提出新的工作方式吧——buzz.xyz / github.com/block/buzz
