多人AI：人机协作的竞争架构

多人AI正逐渐渗透到各个角落。Anthropic正通过Claude Tag将Claude引入共享的Slack频道。Dust正在为人类与智能体构建共享空间。Asana正将智能体融入其工作图谱中。Superconductor和AQ正使智能体会话与框架变得协作化，而Cognee则在构建跨智能体的共享记忆。

如今，市面上已有足够多的不同方法，使得提出一个更有价值的问题成为可能：当我们让AI实现多人协作时，究竟需要共享什么？

答案出人意料地各不相同。根据产品的不同，多人协作层可能是对话、智能体会话、框架、工作图谱、工作空间、记忆，或是工作本身。编码系统有时会反其道而行之，为每个智能体提供隔离环境，仅在事后将其工作成果汇聚起来。

这些不仅仅是不同的产品界面。它们代表了人类与智能体应如何协作的不同架构方法：哪些状态属于执行层面，哪些属于协作层面；共享状态应存放于何处；以及随着工作者来来去去，哪些内容需要持久保留。

目前对于正确的人机架构尚无共识，而毫不意外的是，每家公司的答案往往始于其已拥有的技术栈部分。

纵观当下正在构建的产品，多人AI的七种架构模式脱颖而出。这些模式并非相互排斥，单一产品可以融合其中几种。

共享对话

最直接的方式是将智能体置于一个所有人都能与之交流的平台上。Claude Tag 在 Slack 中实现了这一点。与其让每位员工拥有私密的 Claude 对话，不如让 Claude 参与共享频道。它能感知周围频道的上下文，多人可与之互动，其工作成果对团队可见。

微软在 Teams 中也采用了类似方法，推出了智能体功能。其 Channel Agent 归属于特定频道，并能参与其周围的对话、会议和工作。在这两种情况下，现有的通信系统成为了多人协作的层。

从架构上看，对话本身即是共享状态。底层智能体的执行可以基本保持不变，而围绕它的上下文流则是被共享和持久化的部分。对于许多协作任务而言，这种架构已足够。

共享代理会话

Superconductor 更进一步，通过共享实际的代理会话。多人可以参与同一个正在运行的代理环境，查看实时进展，引导工作方向，进行审查，并从同一状态继续推进。

AQ 将类似理念引入编码工具链。任务获得独立的工作树，而其周围的终端、编辑器、预览及代理环境可与团队共享。HumanLayer 正在探索围绕编码代理会话、计划、差异和任务的相关领域。

在这些架构中，协作以代理及其执行环境为核心，使会话或工具链本身成为多人协作层。换言之，共享状态下移至堆栈底层的实时执行状态。

这与共享对话之间存在显著差异。团队不仅仅是在与同一个代理沟通，而是共享了代理实际执行工作的更多环境。

共享工作图

Asana 和 Linear 的起点不同，因为它们已经拥有多人协作系统。它们的共享对象已经是项目、任务、问题、负责人、依赖关系、评论、状态和审批。它们可以让代理成为现有模型中的参与者，而不是发明新的协作层。

Asana 对此尤为明确。其 AI 队友 与人类一样，在同一个工作图上运作。代理在共享的组织上下文中工作，并在可见性、治理和检查点的保障下参与工作流程。

Linear 一直在将代理引入其问题模型。人类可以保持对问题的责任，同时将工作委托给代理。Patchwork 进一步推动这一理念，将代理视为可见的同事，能够拥有任务、进行对话、按计划工作，并在需要时拉入人类。

在这些架构中，现有的领域模型仍然是记录系统。代理只是与人类一样，在这些持久的对象和关系上运作的新参与者。

这种方法的一个关键特性是：代理不需要持久存在。它可以出现、读取任务和上下文、完成工作，然后消失。当不同的代理或人类连接时，项目、任务和依赖关系仍然存在。

创建共享工作空间

Dust 正通过为团队打造一个新容器来解决这一问题。其 Pods 将人员、代理、对话、文件、任务及围绕共同目标的上下文整合在一起。代理可以针对 Pod 的状态进行操作，创建对话和任务，处理文件，并在参与者之间交接工作。

QM 是这一方法的另一个有趣版本。它为人们和共享房间提供持久环境，其中包含记忆、文件、凭据、权限、计划任务、应用和沙盒，同时允许不同的代理框架在这些环境中运行。

这里的架构更侧重于围绕协作本身创建一个新的共享状态容器。共享工作空间可以将多人协作的多个必要部分汇聚于一处，并使其全部可供代理使用。

构建工作空间架构有其充分理由，因为人机代理团队的需求是我们现有协作产品未曾设计来满足的。

共享记忆

Cognee 给出了不同的答案。一位开发者可以配合 Claude Code 工作，而另一位则使用 Codex。他们的代理保持独立，但来自文档、聊天、工单、代码及代理运行的有用上下文，汇聚成了公司的共享大脑，使得一个人的代理能受益于另一个人代理早前学到的知识。

多家代理记忆公司正从不同角度解决类似问题，包括 Mem0、Zep 和 Letta。它们在记忆的表示与检索方式上各有千秋，但共同的架构思路是将记忆与个体工作者分离，使代理既能保持独立，又无需每次从零开始。

共享记忆为原本独立的代理提供了一个共同的知识积累层。代理可以使用不同的模型、工具和界面，同时仍能受益于团队其他成员已掌握的知识。

这里的核心记录并非执行过程，甚至也不一定是工作本身，而是关于工作的累积上下文，独立于产生它的工作者而持久保存。

保持执行隔离

编程智能体还展现出一种与多人协作几乎相反的方式：完全不共享执行状态。

Codex、Cursor、Warp 及其他编程系统日益支持多个智能体并行操作，但它们通常不会让每个智能体都去修改一个共享环境。工作者各自拥有独立的工作树、分支、沙箱或云机器，其贡献稍后再进行整合。

软件开发之所以如此演进，是有其原因的。共享的可变状态难以管理，两个智能工作者同时编辑同一内容，可能带来的协调问题比解决的问题还要多。Git 为每个工作者提供了私有的工作状态，并提供了一种明确的方法来将各自的贡献合并回来。

这一理念或许能延伸至编程之外的领域。每个智能体都可以获得完成其任务所需的上下文，独立工作，留下明确的输出，并依赖一个共享系统来协调这些输出。在这种架构中，多人协作源于协调独立工作者，而非将他们置于同一执行环境中。

将工作与执行分离

Honeycomb Canvas 采用了另一种方法。在调查过程中，人类与智能体在同一画布上协作，产生发现、查询、可视化、假设及其他中间成果，这些成果对所有人可见且可用。

这里有趣的是，可以将构成工作的工件、关系及状态转换视为独立的持久状态，而不依赖于产生它们的执行过程。

我认为这里存在一个更大的架构机遇，也是我们在 ThruWire 正在探索的方向：将工作本身与执行它的过程分离。智能体会话、框架、模型及运行时可以构成一个执行平面，而另一个独立的工作平面则承载着定义工作的持久对象、关系、状态、历史记录及检查点。

一旦工作与执行分离，人类和智能体便可自由来去，无需随身携带工作内容。他们不必共享大脑、框架，甚至不必使用相同的模型。工作本身提供了持久状态，成为他们协作的基础。

那么多人协作应该放在哪里？

没有人对架构达成一致是有原因的。每家公司对多人协作的定义往往倾向于它已经拥有的技术栈层。

这些模式解决了问题的不同部分，而真正的人机团队可能会同时结合其中几种。一个项目可能涉及十个人和五十个智能体，在几个月内共同推进。他们不会共享同一个对话，不会在同一个环境中运行，不会使用同一个模型，甚至不会同时在场。

因此，架构问题不仅仅是人类和智能体应该共享什么。而是哪些状态必须是持久的，这些状态应该存储在哪里，以及系统的哪些部分可以保持临时性和隔离性。

无论我们最终采用何种架构，都必须能够应对所有这些情况。至少，共享状态需要能够经受住任何一个人或智能体执行工作的过程。