当 Superset 这类多代理代码编辑器同时编排 10+ 个 CLI 编码代理（Claude Code、Codex、Cursor Agent 等）时，每个代理在独立的 git worktree 中并行作业，最终需要将各自的修改合并到主干。这种多代理并发编辑场景对冲突解决算法提出了严苛要求：既要保证实时协作的低延迟，又要处理离线恢复时的状态一致性。本文从分布式一致性算法层面，剖析 OT（Operational Transformation）与 CRDT（Conflict-free Replicated Data Types）的选型权衡、操作转换的边界条件处理，以及版本向量的压缩策略。
OT 与 CRDT 的核心差异
OT 和 CRDT 代表了两种截然不同的冲突解决哲学。OT 采用 "操作转换" 思路：当本地操作与并发远程操作冲突时，通过转换函数调整操作的参数，使其在逻辑上等效于按某种全局顺序执行。这种方法依赖中央协调点（或逻辑上的集中式转换服务）来排序和转换操作，因此天然适合低延迟的实时协作场景。然而，OT 的瓶颈在于中央服务可能成为单点故障，且离线恢复时需要与转换引擎重新对齐状态。
CRDT 则采用 "数据结构内置一致性" 思路：通过设计满足交换律、结合律和幂等性的数据类型，使各副本在独立应用操作后最终收敛到相同状态，无需中央协调。这种强最终一致性（Strong Eventual Consistency）使 CRDT 在离线优先和去中心化架构中表现出色，各代理可以独立工作并在网络恢复时自动合并。
选型权衡：何时选择 OT，何时选择 CRDT
在多代理代码编辑场景中，选型需考虑以下维度：
网络拓扑与协调模式：如果系统采用中心化架构（如 Superset 的中央监控面板），OT 的中央转换服务可以高效处理操作排序。但如果代理分布在不同网络环境，或需要支持完全离线的本地开发模式，CRDT 的去中心化特性更具优势。
延迟敏感度：OT 能提供亚秒级的实时协作体验，因为操作可以立即本地应用并异步转换。CRDT 虽然也能支持实时同步，但其收敛保证不依赖全局协调，在高延迟或间歇性连接环境下反而更稳定。
数据类型复杂度：代码编辑不仅涉及纯文本，还包括语法结构、缩进、格式化等。OT 在文本编辑领域有成熟的转换函数库（如 Google Docs 使用的 Jupiter 系统），但对于结构化数据（如 AST 级别的编辑），需要自定义复杂的转换规则。CRDT 的序列类型（如 RGA、YATA）可以处理字符级并发编辑，但代码语义的保持需要额外的应用层逻辑。
可扩展性边界：当并发代理数量超过 50 个时，OT 的中央转换服务可能面临吞吐量瓶颈。CRDT 的横向扩展能力更强，每个代理的内存和计算开销相对独立。
操作转换的边界条件处理
选择 OT 方案时，必须妥善处理以下边界条件：
操作依赖追踪：每个操作需携带其依赖的前置操作 ID，形成操作因果图。当转换服务接收到乱序操作时，必须缓存等待依赖满足后再执行转换。建议设置依赖等待超时（如 5 秒），超时后标记为冲突并触发人工介入。
转换函数的完备性：对于代码编辑，需定义插入、删除、替换、缩进调整等操作的转换规则。关键边界包括：两个代理同时在同一位置插入内容时的顺序确定（可采用代理 ID 字典序或时间戳）；删除已被其他操作修改过的范围时的语义保持。
撤销 / 重做栈的同步：多代理场景下的撤销操作需明确作用域 —— 是撤销本地代理的操作，还是全局撤销？建议采用 "代理隔离的撤销栈" 设计，每个代理只能撤销自己的操作，避免跨代理撤销导致的意外状态回退。
冲突降级策略：当转换函数无法确定唯一结果时（如两个代理同时修改同一行代码的不同部分，但语义上存在潜在冲突），系统应触发 "冲突标记" 而非自动合并，将决策权交还给开发者。
版本向量压缩策略
CRDT 的核心挑战之一是版本向量的元数据开销。每个操作携带的向量时钟随代理数量线性增长，在 Superset 这类 10+ 代理的场景下，需要有效的压缩策略：
增量向量时钟：仅记录自上次同步以来发生变化的代理版本号。对于长时间未参与编辑的代理，其版本号可以从向量中剔除，在需要时通过状态传输重新同步。
向量时钟摘要：采用 Merkle 树或布隆过滤器对版本向量进行摘要，减少传输开销。当两个代理的版本向量差异较小时，只需交换差异部分而非完整向量。
剪枝与垃圾回收：对于已经全局确认的操作（即所有代理都已应用），可以从版本向量中移除对应的条目。设置剪枝阈值（如操作确认后 30 秒），定期清理已稳定的版本信息。
分片向量时钟：将代理划分为逻辑分片（如按功能模块或代码目录），每个分片维护独立的版本向量。跨分片操作携带多个分片的向量，但单个分片内的编辑只需携带该分片的向量，显著降低常规操作的元数据大小。
混合架构的实践建议
现代多代理系统趋向于 OT-CRDT 混合架构，以结合两者优势：
分层设计：采用 CRDT 作为底层状态同步层，保证最终一致性；在应用层使用 OT 处理实时协作的即时反馈和冲突标记。当网络分区发生时，系统降级为 CRDT 模式继续工作；网络恢复后，通过 OT 转换服务对齐状态。
代理角色区分：将代理分为 "主写代理" 和 "只读代理"。主写代理（如负责核心逻辑修改的 Claude Code 实例）使用 OT 协议与中央服务通信，保证编辑的精确控制；只读代理（如代码审查、文档生成类代理）使用 CRDT 订阅状态，降低中央服务负载。
冲突解决管道：建立三级冲突处理机制 ——L1 自动合并（CRDT 收敛）、L2 启发式合并（OT 转换规则）、L3 人工介入（冲突标记）。设置阈值参数：当自动合并的置信度低于 0.85 时，升级到 L2；当转换规则无法确定唯一结果时，升级到 L3。
可落地的参数配置清单
针对 Superset 类多代理编辑器，建议配置以下参数：
- 操作转换超时：5-10 秒，超过后触发冲突标记
- 版本向量剪枝间隔：30 秒，清理已确认的操作版本
- CRDT 同步窗口：100ms 批处理，平衡实时性与网络开销
- 最大并发代理数：OT 模式建议 ≤20，CRDT 模式可支持 50+
- 冲突标记阈值：语义相似度 <0.85 时触发人工审查
- 离线模式切换：网络延迟 >500ms 或丢包率 >5% 时自动启用 CRDT 离线模式
结语
多代理并发编辑的冲突解决没有银弹。OT 提供精确的实时协作控制，适合中心化、低延迟场景；CRDT 提供弹性离线能力和水平扩展性，适合分布式、间歇连接场景。在 Superset 这类支持 10+ 代理并行作业的工具中，理解两种算法的边界条件、设计合理的版本向量压缩策略、建立分层的冲突解决管道，是构建可靠多代理开发环境的关键。
参考来源
- Superset GitHub 仓库: https://github.com/superset-sh/superset
- OT vs CRDT 技术对比分析: https://thom.ee/blog/crdt-vs-operational-transformation/
- 多人协作算法指南: https://www.taskade.com/blog/ot-vs-crdt
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。