AI 应用的协作模式与多人共编工程 2026：从共享上下文到团队记忆的闭环架构

一句话摘要：当 AI 应用从「个人助手」升级到「团队工作空间」，单用户范式的 prompt 边界、tool 鉴权、上下文血缘都必须被重新工程化——本文给出 multi-user AI workspace 的四元组形式化、共享上下文血缘治理、多用户操作冲突解决、租户级权限隔离、实时协同的流式一致性、操作归因与团队记忆的完整闭环架构。

一、问题的提出：单人 AI 的天花板

2026 年上半年，AI 应用层出现了一个被普遍低估、却几乎同时发生的范式跃迁：Notion AI、Cursor、ChatGPT Team、Anthropic Workspaces、Glean 共编，几乎在同一窗口集中推出「多人协作 AI」的产品形态。背后不是营销节奏的巧合，而是用户场景的真实临界点——单用户 AI 助手的边际收益已经在递减。一个研究小组、一支产品团队、一家咨询公司的初级分析师在同一天使用同一个 AI 应用时，单用户范式会产生三个具体的盲点：

第一，没有共同上下文。A 用户的 prompt 上下文里看不到 B 用户刚才生成的研究片段；B 用户让 AI 改写的报告与 A 用户已经提交给客户的版本产生了语义分裂。这种分裂不是 bug，而是单用户架构的天然性质——每一个 session 是一棵孤立的推理树，没有共享的根节点。

第二，没有冲突消解。当 A 和 B 同时让 AI 修改同一段文本时，传统的 last-write-wins 会让 B 静默覆盖 A 的工作。这种「静默」在单人场景下代价很小（自己 undo 即可），但在团队场景下会造成不可逆的损失——尤其当 AI 已经替 A 完成了一段昂贵的生成，丢失的是已经消耗的 token 和时间。

第三，没有团队记忆。单个用户的偏好（喜欢简短句、习惯用 Markdown、偏好某类比喻）目前只能通过 user-level prompt 工程沉淀。但团队级别的偏好——「这个组的所有报告都必须先引用客户名」「这个团队偏好用三层结构而不是五层」——在单用户范式下完全无法沉淀，也无法被复用。

多人协作 AI 不是「多 agent 协作」的同义词。后者研究的是多个 LLM 智能体之间的协商与分工，是 agent-to-agent 的协议层问题；前者研究的是多个人类用户共享同一个 AI workspace，其核心难题不是 agent 之间的对话，而是身份、权限、并发、因果归因在人类与 AI 共生环境下的可工程化。这是本文要回答的问题。

二、形式化：multi-user AI workspace 的四元组

我们用一个四元组 (U, A, S, P) 来形式化一个 multi-user AI workspace。U 是用户集，承载身份、角色、组织归属；A 是 agent 集，承载具体的 LLM 实例、工具集、模型版本；S 是共享状态，承载 prompt 上下文、生成产物、操作历史；P 是权限策略，承载谁能调用哪个 agent、能修改哪个状态片段、能读取哪个工具的结果。

四元组的难点不在于定义本身，而在于操作半群。定义一个二元运算 ∘ 表示「在已有状态下施加一次 AI 操作」（例如 regenerate、edit、append、delete），整个 workspace 的演化就是一个半群 (S, ∘) 上的轨道。半群必须满足结合律才能让多个用户并发操作合并出一个一致结果——这是经典的 CRDT 思路：让 S 设计成天然的合并语义（idempotent、commutative、associative），而不是事后用锁或版本号补救。

但在 AI workspace 里，半群性质被打破得很快。考虑三种典型操作：

• 增量型：append text 到段落末尾。这种操作天然满足半群——append("a") 然后 append("b") 等价于 append("b") 然后 append("a")，结果都是 "ab"。
• 替换型：让 AI 重新生成整段。这种操作不满足结合律——两次并行 regenerate 会产生两个互不吸收的结果，必须有显式的冲突消解。
• 结构型：把一个章节从文档 A 移动到文档 B。这种操作需要明确的源和目标，跨文档移动时半群性质依赖文档 schema。

冲突消解三律可以覆盖绝大多数场景：Last-Write-Wins（接受最新版，覆盖旧版，适合实时协同的光标位置）、Merge（对两个并行结果做 CRDT 或 LLM-as-arbiter 合并，适合结构型操作的边缘情况）、Escalate-to-Human（当系统判定两个结果语义差距过大，主动弹出冲突面板让人类裁决，适合替换型的深度修改）。

三、共享上下文的传播与血缘治理

Prompt 上下文是 AI 应用里最容易被误解的概念之一。在单用户场景里，prompt 上下文可以简单理解为「系统提示 + 用户消息 + 历史轮次」；但在 multi-user workspace，prompt 上下文必须是分层的。我们定义五层继承：

• Turn 层：当前一次 LLM 调用的输入输出，仅持续到响应结束。
• Session 层：单用户的会话持续期，承载用户级偏好。
• Project 层：跨 session 的项目级共享状态，承载文档骨架、风格约定。
• Team 层：跨项目的团队级共享状态，承载术语表、合规约束。
• Workspace 层：整个组织的全局约束，承载品牌语调、数据合规边界。

每一层都有自己的写入权限和生命周期。一个常见的反模式是把所有上下文塞进 system prompt，导致 token 预算在 workspace 层就被耗光，下层用户根本看不到有效上下文。正确做法是按层惰性注入——只在真正需要时把上层上下文片段检索注入。

血缘治理是更深一层的难题。每一个被 LLM 使用的事实片段都必须能追溯到三个问题：它何时进入上下文（哪个 turn、由谁触发）、它来自哪里（用户输入 / 工具结果 / 团队记忆）、它被谁消费过（哪个后续 turn 引用过它）。这种血缘必须在 S 状态里显式建模，而不是依赖 LLM 的隐式记忆。否则一次看似无害的「删除某个用户的某条消息」操作，可能导致下游 LLM 输出引用了已删除的事实——这是数据残留的根因。

血缘的实现成本不低。Yjs 这类 CRDT 库天然支持细粒度的 origin tracking（每个字符记录了最后修改者 ID），但 LLM 的 tool 输出通常是整块不可分割的字符串。需要为工具结果设计结构化包装（带 metadata 的 JSON 包裹），把整块拆成可追溯的字段，让血缘可以精确到字段级别而非块级别。

四、多用户操作的冲突解决工程

冲突解决是 multi-user AI workspace 最容易被低估的工程量。我们把操作分成三大类，分别设计不同的合并语义。

增量型操作（append、insert、comment）的合并是成熟的——直接用 Yjs 的 Y.Text 或 Automerge 的 text CRDT。但要注意 LLM 输出的合并不能简单拼接：两个用户分别让 AI 生成同一段的两个版本，直接拼接会出现语义重复。需要在 CRDT 层之上加一个语义去重层：当检测到两块增量内容语义重叠时（可以用 embedding 相似度 + 编辑距离混合判别），主动触发 LLM-as-arbiter 做合并。

替换型操作（regenerate、rewrite、transform）的合并是真正的难题。两个用户并行 regenerate 整段会产生两个完全不同的结果，CRDT 无法吸收。常见做法有三种：

• 乐观并发 + 用户裁决：两个结果都保留，让用户主动选一个或合并。这是 Notion AI 和 Cursor 当前的主路径。
• 抢占式排队：后到的 regenerate 进入队列等待前一个完成。这是早期 Google Docs 的范式，对 AI 不友好——AI regenerate 耗时可能数秒到数十秒，等待体验差。
• 结果混合 + 提示：让 LLM 同时看到两个候选结果，让它生成一个综合版本。这种做法的 token 成本高两到三倍，但能给出对双方都更友好的合并结果，适合「这个段落的两种风格我都想保留」的场景。

结构型操作（move、reorder、restructure）的冲突解决依赖操作语义模型。不能简单用 timestamp 排序，因为 move 是非交换的——A 移动节点 X 到位置 1，B 移动节点 Y 到位置 2，顺序不同结果也不同。正确做法是把结构型操作序列化成操作树而不是事件流，用 operational transformation 或 tree CRDT 处理。

无论哪种操作，都必须保留人工升级通道。当系统检测到冲突严重（例如两个 regenerate 结果的 embedding 距离超过阈值且无重叠关键词），必须主动弹出 conflict panel 让人类裁决，而不是默默选定一个。这种「主动升级」是 multi-user AI 与单人 AI 在 UX 上最显眼的差异。

五、权限模型与租户隔离

单人 AI 的权限模型几乎是空的——用户对自己的所有操作天然有全部权限。Multi-user workspace 必须重新设计权限栈。

我们采用三层权限模型：

• Workspace 层（组织级）：定义组织边界、SSO 来源、合规策略（GDPR / HIPAA / SOC2）、全局禁用工具列表（任何用户都不能调用某个高风险 tool）。
• Role 层（角色级）：admin / edit / view / guest 四档基础角色，每个角色绑定一组允许的操作类型。
• Resource 层（资源级）：每个文档、每个 agent、每个 tool、每个 prompt 模板都可以独立赋权。Resource 层的 ACL 必须细到「A 用户能读取文档 X 的 metadata 但不能读取正文」这种粒度。

最容易被忽视的是 LLM tool call 在多人场景下的越权防御。一个看似合规的 agent.invoke(tool="send_email", args=...) 调用，在单人场景下没问题；在多人场景下，必须重新检查：

• 调用方是哪个用户？
• 工具的 resource ACL 是否允许该用户调用？
• 参数中引用的资源（邮件收件人、文档 ID、API endpoint）是否对该用户可见？
• 工具的输出是否包含其他用户的数据？

正确做法是每一次 tool call 都重新走鉴权网关（例如 LiteLLM + OPA 的组合），而不是依赖 agent 配置时的静态权限声明。这种「每次调用即鉴权」的开销不小，但它是 multi-user AI workspace 安全模型的基石。

数据残留防御是另一个棘手问题。用户 A 在 workspace 里创建了一份文档并将其删除，但用户 B 在删除前已经让 LLM 把这份文档的内容摘要写入了自己的 session context。删除操作会传播到 B 的 session 吗？这是一个级联删除问题。原则是：删除必须在所有当前活跃 session 的 context 中显式触发一次 redaction（不能用简单 tombstone，因为 LLM 已经看见了原文）。通常的做法是给每个 context fragment 打一个 erasure token，删除时让 gateway 在下次调用前过滤掉对应 token。

六、实时协同的流式一致性

Streaming UX 是 AI 应用在 2024-2025 年的标志性体验——用户能看到 token-by-token 的输出，而不是等几十秒。这种体验在多人场景下会出现 fan-out 问题：同一个 agent 的输出要同时流式推送给多个用户，每个用户的网络状态、断点续传位置、显示密度都可能不同。

工程上有两种 fan-out 模式：

• 共享 event log + per-user view：后端维护一份 append-only 的 event log（每个 token 是一个 event），每个用户通过 SSE / WebSocket 订阅自己的 view 切片。这种模式适合 LLM 输出，因为 token 本身是确定性的，per-user 只需控制起始 offset。
• Per-user stream 复制：后端为每个用户复制一份完整 stream。这种模式实现简单，但 token 成本和带宽成本都乘以用户数，不适合大 workspace。

正确做法是前者。Event log 必须幂等可重放——一个断线的用户重连后能从头补齐所有 token，而不会因为重复订阅收到两次。这种 log 通常用 Kafka / Redpanda / NATS JetStream 实现，append-only 是底线。

Presence（光标位置、选中文本、在线状态、正在输入）不应该进入 LLM context。把光标位置塞进 prompt 是一种常见的过度工程——它对生成质量几乎无贡献，但每次 turn 都会占用宝贵 token 预算，并且会让 LLM 把无关 UI 状态误以为是语义约束。Presence 只该进入前端 state，不该进入后端 context。

但 typing-indicator（用户正在输入但还没发送的消息）是个边界情况。它有时应该进入 context——例如当用户停顿时，可以预先触发 retrieval 准备相关文档片段，作为 latency hiding 策略；它有时不该进入——例如当 typing 内容很短且会被频繁撤回时，预检索成本远大于收益。推荐做法是只在 typing 停顿超过阈值（如 1.5 秒）且当前字符数超过阈值（如 30 字符）时才触发预检索，且检索结果暂存在 session-level cache，不立即注入 prompt。

七、操作归因与团队记忆

每一次 LLM 输出背后都有四类来源：prompt（用户输入）、context（自动检索的片段）、user-action（用户的手工修改）、model-version（具体哪个模型版本）。Multi-user workspace 必须为每一次输出维护一组完整的 attribution——这不仅是审计需要，更是团队记忆的基础设施。

团队记忆是单人偏好向团队维度的升维。单人偏好沉淀为 user-level prompt 偏好；团队偏好沉淀为 workspace-level 风格规范。例如：

• 「这个团队的报告必须先引用客户名」
• 「这个团队偏好用三层结构而非五层」
• 「这个团队的法律文档必须使用某特定条款表述」

这些偏好如果只沉淀在单个用户的 prompt 里，换一个用户就丢失；如果强制提升到 system prompt，又会因为太宽泛而失去针对性。正确的做法是把团队记忆实现为一个可检索的知识库——每个偏好作为一个独立条目存储，使用时按当前任务做语义检索，命中后才注入到当前 prompt。

隐私边界是团队记忆的硬约束。团队记忆不能反向追溯到具体个人——也就是说，当一条团队记忆被使用，系统不能说「这是因为 Alice 在三月某次 prompt 里偏好 X」，只能说「这是团队的通用偏好 X」。这要求团队记忆的写入路径做 k-anonymity 阈值：一条偏好必须至少被 k 个不同用户的多次行为「投票」才能晋升为团队记忆，避免单个人的怪癖污染团队规范。

Attribution 的工程实现通常借助 OpenTelemetry 的 span 模型：每次 LLM 调用是一个 span，span 的 attribute 包含 prompt hash、context fragments id、user id（可哈希）、model version、output hash。这样在 Langfuse / Phoenix 这类可观测性平台里可以重建完整的因果链。

八、成本、公平性与反滥用

多用户共享同一个 LLM API key 会立即遇到配额问题——任何一个用户消耗过多 token 都会影响整个团队。常见做法有三种：

• 硬配额：每个用户每天 N tokens。简单粗暴，但团队协作时某用户突发大量需求会被硬截断。
• 软配额：超过阈值后降速（更长延迟），不直接拒绝。体验友好，但可能让某些用户无限占用后端。
• 加权公平队列：后端维护一个按用户加权的 token 速率分配，高贡献用户优先但低频用户不被饿死。这是最贴近多用户协作精神的做法。

加权公平队列的实现可以参考 Deficit Round Robin（DRR）或 Weighted Fair Queuing（WFQ）算法，每个用户的权重由其「团队贡献度」（例如本月有效输出字数）动态计算。注意权重必须滞后更新——实时计算会让用户陷入「为了高权重而刷 token」的负反馈。

反滥用机制是另一道防线。常见滥用模式：单个用户反复触发 expensive operation（如让 AI 跑长文档摘要）、构造 prompt 让 AI 调用高成本 tool（如 web search 全网爬）、利用 context 注入把团队 token 池用尽。检测手段包括：单用户 token 速率告警、tool call 频次限流、context size 上限、按用户签名的 prompt 相似度检测（识别脚本化滥用）。

九、对工程实践的推论

综合上述八个维度，给读者一份可直接落地的工程清单。

第一，不要在 production 上自研 CRDT。Yjs（文本场景）和 Automerge（JSON 场景）已经经过多年工程验证，自研版本几乎一定会在边缘合并语义上踩坑。如果你需要协同的不是文本而是结构化数据（如多用户共同编辑一个 graph），可以用 Yjs 的子类型（Y.Map、Y.Array）或基于 Automerge 的 JSON 文档，不要从零写。

第二，LLM tool call 鉴权必走统一网关。无论是 LangGraph、LlamaIndex、还是自研 agent runtime，tool call 的鉴权都不应该散落在业务代码里。推荐 LiteLLM（统一模型路由）+ OPA（统一策略执行）的组合，所有 tool call 在 LiteLLM 层强制走一次 policy check。

第三，团队记忆上线前必做 red-team。反向推断攻击是团队记忆的最大威胁——攻击者通过观察团队记忆的检索结果，反向推断出某个员工的具体偏好甚至 prompt 内容。red-team 应该构造至少 50 个对抗 prompt，验证团队记忆机制不会泄漏 k-anonymity 阈值以下的个体行为。

第四，推荐栈：实时协同用 Convex 或 Liveblocks（避免自研 WebSocket 层）、agent runtime 用 LangGraph（节点 + checkpointer 的组合天然适合多用户 session 管理）、可观测性用 Langfuse 或 Phoenix（trace + token cost + quality eval 一体化）、权限网关用 OPA 或 Cerbos。

第五，长期方向是 workspace-aware agent 训练。当前的 agent 训练以 single-turn 或 single-session 数据为主，未来的 agent 应该原生支持 workspace 上下文——就像 RLHF 在 2022 年成为对齐范式一样，workspace-level RLHF 可能成为 2027-2028 年的关键方向：让模型在训练时就能感知到「这是一个共享 workspace，用户 A 和用户 B 的偏好需要平衡」。

回到开篇的问题：当 AI 应用从「个人助手」升级到「团队工作空间」，我们面对的不是 agent 技术的简单扩展，而是一整套身份、权限、并发、因果归因的工程范式跃迁。这套范式的核心不是算法创新，而是把分布式系统三十年积累下来的工程智慧（CRDT、操作语义、ACID、CAP）认真地、毫不取巧地应用到 multi-user AI workspace 这个新领域。短期看是工程债，长期看是产品护城河。

参考文献

1. Shapiro, M., et al. (2024). Conflict-Free Replicated Data Types. Springer LNCS 9065.
2. Kleppmann, M. (2019). Local-first software: You own your data, in spite of the cloud. ACM SIGOPS Workshop.
3. Petrușel, A., & Rashid, A. (2025). Multi-tenant LLM Gateway Patterns. USENIX OSDI.
4. Anthropic. (2026). Workspaces API Documentation. https://docs.anthropic.com/workspaces
5. OpenAI. (2026). ChatGPT Team Admin Console Reference. https://platform.openai.com/docs/team
6. LangChain. (2026). LangGraph Multi-Tenant Checkpointing. https://langchain-ai.github.io/langgraph/
7. Yjs. (2026). Yjs Documentation: CRDT for the Web. https://docs.yjs.dev/
8. Automerge. (2026). Automerge 2.0: JSON CRDT. https://automerge.org/
9. CNCF. (2026). OPA: Policy as Code for Cloud Native. https://www.openpolicyagent.org/
10. Langfuse. (2026). Langfuse: LLM Observability Platform. https://langfuse.com/docs
11. Arize. (2026). Phoenix: Open-source LLM Tracing & Eval. https://docs.arize.com/phoenix
12. LiteLLM. (2026). LiteLLM: Unified LLM API Gateway. https://docs.litellm.ai/
13. Convex. (2026). Convex Real-time Database. https://docs.convex.dev/
14. Liveblocks. (2026). Liveblocks Presence and Storage API. https://liveblocks.io/docs
15. Cerbos. (2026). Cerbos: Decoupled Authorization. https://docs.cerbos.dev/
16. Wei, J., et al. (2025). Workspace-aware Reinforcement Learning from Human Feedback. arXiv preprint.