超越提示框：构建企业级多人在线AI协作架构

企业级多人在线AI协作架构

生成式AI的主流交互范式是「提示框」——同步、无状态、高度个人化。用户输入一段文字，模型返回结果，会话结束。这种架构对于个人编码辅助或客服分流而言足够优秀，但当需求从个体增强转向多方实时协作智能时，它便从根本上失效了。

「多人在线AI」不只是在一个聊天室里放一个机器人。它是一个分布式系统，多个自主智能体（或人与AI的混合参与者）必须在共享的可变状态空间中运行。它们需要感知彼此意图、管理上下文窗口的资源竞争，并保持动作的因果一致性。对企业软件架构师而言，这意味着AI从一种「工具」（如数据库或搜索引擎）转变为事件网格中的主响应节点。

聊天UI模型的三大结构性缺陷

要理解为什么多人在线AI需要全新架构，先要拆解当前聊天UI为何无法支撑这一场景。标准LLM接口的实现遵循一个N+1问题：

无状态性：主流LLM提供商（OpenAI、Anthropic、本地Llama）都是无状态的。除非客户端每次显式发送完整历史，否则它们不记得「Alice」和「Bob」。
同步阻塞：HTTP请求会阻塞线程或异步任务，直到token生成完毕。这对人类阅读文本没问题，但对需要在毫秒级响应工具调用或其他智能体动作的Agent来说，是灾难性的。
丢失更新问题：如果Agent A和Agent B同时读取同一上下文、各自生成变更、再同时写回，其中一个变更会丢失，或系统进入不一致状态。

在多人在线场景中，状态不只是对话历史，状态就是世界本身——是被重构的共享代码库、被调整的财务模型、被优化的供应链计划。架构必须将共享状态视为一等公民，分布在工作节点集群上，而非单个用户浏览器标签页中的局部变量。

丢失更新问题是多用户并发系统中的经典故障模式，最早在数据库事务理论中被系统化描述。当两个执行体（在本文语境下即两个Agent）同时读取同一份状态、各自基于该快照做出修改、再先后写回时，后写入者的结果会覆盖先写入者，被覆盖的那次变更即「丢失」。传统关系型数据库用乐观锁（版本号比对）或悲观锁（行级锁定）来防止这一问题，但在LLM驱动的场景中，Agent的「思考—生成—写回」周期可能长达数秒，长时间持锁会彻底破坏协作流畅度。这正是后文引入CRDT的根本动机：用可交换、可合并的操作语义替代锁机制，让并发写入在前端就地收敛。

多人在线AI的四大架构支柱

据tamiz.pro的技术分析，一个健壮的多人在线AI系统建立在四个与标准Web应用截然不同的支柱之上：

共享可变上下文（世界状态）

所有Agent在统一的数据模型上操作，而非孤立的线程。这可以是一个共享JSON文档、向量数据库命名空间或图数据库。架构必须确保所有Agent在任意逻辑时间点对该状态拥有一致视图。

解耦事件总线

Agent之间不直接调用，而是向中央事件总线发布意图（如「我要运行测试」「我已修改文件X」）。这种解耦允许在不重新设计通信结构的前提下添加新Agent类型。

异步协调层

「编排器」不是忙等待循环，而是一个状态机：监听事件、判断工作流当前阶段、触发相应Agent或人工介入。在大规模实现中，这意味着从请求-响应范式转向事件驱动架构（EDA）。

事件驱动架构（EDA） 的核心思想是组件之间通过发布/订阅事件而非直接RPC调用进行通信，生产者只管发布事实，消费者自行决定如何处理。与请求-响应相比，EDA天然支持扇出、削峰和异步重试，但也引入了新的复杂度：事件顺序不保证、重复投递需要幂等消费、跨服务调试需要事件溯源和追踪。Temporal.io 在此之上提供了「持久化执行」能力——工作流状态被持久化到后端，进程崩溃后可从断点恢复，这使得长时间运行、包含人工审批环节的Agent编排具备了生产级可靠性。用事件流替代同步调用，正是本文主张AI从「工具」升级为「事件网格中主响应节点」的落地路径。

全局状态树与增量广播

编排器管理一棵全局状态树。当用户或Agent修改数据时，编排器基于当前状态验证转换，并通过发布/订阅机制（如Redis Streams或NATS）向所有连接客户端广播增量更新。

CRDT：解决AI协作中的「光标战争」

多人环境中必然遇到「光标战争」：人类正在编辑某段落时，AI Agent同时在重写它。朴素的「最后写入胜出」策略会导致数据丢失和用户挫败。

解决方案：无冲突复制数据类型（CRDT）

将CRDT（如Yjs或Automerge）集成到AI输出流中，AI不再发送整块文本，而是发送一系列操作（Ops）：

Insert(index, character, authorId)
Delete(index, length)
Format(index, length, attribute)

将AI视为CRDT文档中的另一个并发用户，系统可确保：

强最终一致性：所有用户和Agent最终看到相同的文档状态。
非阻塞编辑：AI可以建议重写第二段，同时用户在第一段修正错别字，无需任何锁机制。

CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）是一类数学上保证并发操作可交换、可结合、幂等的数据结构，使得多个副本在任意网络分区和消息乱序下，只要最终收到全部操作，就必然收敛到相同状态。它分为基于状态的CvRDT（通过合并函数归并）和基于操作的CmRDT（通过交换操作序列）两大类。文本编辑领域最常用的是基于操作的序列CRDT，代表实现包括Yjs和Automerge。Yjs采用了一种名为YATA的算法，能在O(n)复杂度下处理并发插入的位置消歧，因而成为ProseMirror、TipTap等富文本编辑器的默认协作后端。将LLM输出建模为CRDT操作流而非整段文本，是让AI安全参与实时协作的关键工程手段。

人在回路：从「写作者」到「主编」

多人在线AI不是取代人类，而是将人类角色从写作者转变为主编。

干预模式

系统设置「干预点」，AI在此暂停执行并呈现决策分叉：

隐式批准：若X秒内无人干预，AI继续执行（低风险任务）。
显式批准：AI暂停等待人类点击「批准」或「修改」（高风险任务如API部署）。

上下文感知

为防止AI幻觉或忽略用户当前编辑，提示词必须是动态的。系统使用滑动上下文窗口，包含：原始目标、CRDT文档当前状态、近期人工编辑历史（实时学习用户偏好）。

高层架构与技术栈

整个系统的数据流如下：用户通过WebSocket网关连接，网关对接CRDT同步引擎，引擎与编排器/状态机通信，编排器调度Agent池（路由器、编码器、审查器），Agent池调用LLM集群，编排器同时对接Redis状态存储/发布订阅。

组件	推荐技术	理由
实时传输	WebSockets / gRPC-Web	低延迟、双向流
状态同步	Yjs / Automerge	确保多参与者一致性
协调层	Temporal.io / Redis Streams	持久化执行与事件溯源
Agent框架	LangGraph / CrewAI	支持循环图与有状态Agent
前端	React + TipTap/ProseMirror	富文本编辑与CRDT集成

从聊天机器人到智能体工作空间

构建多人在线AI要求我们从根本上重新审视LLM集成方式。我们正在从「聊天机器人」（线性、孤立的对话）转向「智能体工作空间」（共享的、有状态的环境，人与AI在活的产物上协作）。

管理CRDT、事件驱动编排和状态机的复杂度确实显著。但这是将AI从新奇的生产力工具转变为核心企业引擎的唯一路径——一个能实时处理复杂多步骤工作流的引擎。通过将通信结构从Agent逻辑中解耦，我们构建的系统不仅可扩展，还能适应下一代基础模型。