在现代代码编辑器的协作场景中，多个 AI 代理同时参与代码修改已成为常态。Zed 作为一款强调实时协作的编辑器，其底层采用冲突无关复制数据类型（CRDT）作为协同编辑的核心算法框架。与传统的操作转换（OT）不同，CRDT 将冲突解决内嵌到数据结构本身，使并发操作能够在无需中心协调的情况下自然收敛。本文将从算法原理到工程实现，详细剖析 Zed 在多代理并行编辑场景下的冲突解决机制与状态同步策略。
CRDT 核心设计：从绝对偏移到内容寻址
传统的协同编辑系统在描述插入位置时通常依赖绝对字符偏移量。然而，当两个代理并发编辑同一文档时，这种基于偏移的寻址方式会导致严重的状态分歧。假设副本 A 在位置 8 插入了文本「December」，副本 B 同时在位置 8 插入了「 Engelbart」，当双方同步时，如果不做转换处理，文本将出现在错误的位置。OT 算法通过变换操作来适应并发修改，但这要求定义复杂且难以证明正确性的转换函数。
Zed 选择了另一条路径：使用基于内容的逻辑寻址。核心思想是将每次插入操作视为一个不可变的文本片段，并为每个片段分配全局唯一的标识符。这个标识符由两部分组成：副本编号（Replica ID）和序列号（Sequence Number）。副本编号在会话初始化时由中心节点分配，确保不同副本生成的标识符永不冲突。当用户在某个插入片段的特定偏移量处添加新文本时，新插入的位置描述为「在 ID 为 X 的插入片段的偏移量 Y 处」。这种寻址方式的关键在于，即使并发编辑改变了文档的物理结构，只要原始插入片段存在，新插入就能被准确定位。
具体实现中，Zed 使用「锚点」（Anchor）作为逻辑位置表示。锚点是（插入标识符，偏移量）的二元组。当需要应用远端操作时，编辑器扫描本地文档，找到目标插入片段中包含指定偏移量的片段，然后在对应位置插入新文本。这种机制确保了无论操作到达的顺序如何，最终收敛的文档状态都是一致的。值得注意的是，Zed 的插入操作形成树形结构，后续插入可以建立在先前插入之上，这为复杂的嵌套编辑提供了稳定的基础。
并发插入的因果排序：Lamport 时钟的应用
当两个代理在同一位置并发插入文本时，顺序本身并不影响最终收敛性，但所有副本必须采用相同的排序规则。简单的 ID 排序虽然能保证一致性，却无法保留用户的原始意图。例如，如果用户在看到某个插入后才进行操作，基于 ID 的排序可能将该操作置于插入之前，导致语义错位。
为解决这一问题，Zed 引入 Lamport 逻辑时钟来捕获操作之间的因果关系。每个副本维护一个标量值的 Lamport 时钟，当生成操作时将时钟加一，当接收来自其他副本的操作时，将本地时钟设置为本地值与接收到的时钟戳中的较大值。这种机制确保了：如果操作 A 在操作 B 被观察到之前已经生成，则 A 的时间戳必定小于 B。
基于这一属性，Zed 对同一位置的并发插入按时间戳降序排序，时间戳相同时则按副本 ID 升序排序。降序排列的意义在于保留「后看到先插入」的语义 —— 当用户在某个位置看到已有文本后立即输入，新输入应该出现在该文本之前。实践表明，这种排序策略在大多数场景下能够正确反映用户的编辑意图，同时保证所有副本的一致性。从工程角度监控这一机制时，可以关注时间戳分布的异常情况，例如同一副本的时间戳出现逆序，这可能指示时钟同步存在 bug。
删除操作的墓碑机制与版本向量
对插入操作的良好处理只是协同编辑的一半，删除操作的语义同样需要仔细设计。在 Zed 中，删除并不真正移除文本，而是标记「墓碑」（Tombstone）。被标记为墓碑的片段在向用户展示时被隐藏，但仍然保留在数据结构中，以维持锚点解析的有效性。这一设计类似于其他 CRDT 实现中的「删除标记」模式，但 Zed 进一步引入了版本向量来解决更复杂的并发场景。
考虑以下场景：副本 A 删除了一段文本，副本 B 同时在该文本范围内插入了新字符。如果删除操作仅记录一个范围，副本 A 可能看不到 B 的插入（因为文本已被删除），而副本 B 却能看到自己的插入，导致状态分歧。Zed 通过为删除操作附加版本向量（Version Vector）来解决这个问题。版本向量记录了删除操作发起时各个副本观察到的最新序列号。当应用删除操作时，只有序列号小于版本向量中对应值的插入才会被标记为墓碑，并发插入则被排除在外。
这种机制确保了删除者的「观察视角」被准确保留。从监控角度，可以追踪墓碑数量与活跃文本的比例。当墓碑占比过高时，可能表明存在大量被删除但未真正清理的历史数据，影响内存使用和查询性能。Zed 在内部使用写时复制 B 树来索引这些片段，避免对每次远端操作都进行线性扫描，但这仍然是运维中需要关注的指标。
协同编辑环境下的撤销与重做
单机编辑器的撤销栈通常是全局的，操作必须严格按照时间逆序撤销。但在协同环境中，每个用户应该能够撤销自己执行的操作，而非其他人的操作。Zed 实现了「撤销映射」（Undo Map）来支持这一需求。撤销映射将操作标识符映射到一个计数：计数为零表示操作未被撤销；奇数表示已撤销；偶数表示已重做。撤销和重做操作仅更新特定操作标识符的计数，不影响其他用户的操作。
当渲染文档时，系统首先检查目标插入是否已被撤销（计数为奇数），然后检查是否存在墓碑标记，以及这些墓碑本身的撤销计数。这一设计允许用户按照任意顺序撤销自己的操作，而不破坏与其他用户操作的相对关系。Zed 当前仅允许用户撤销自己的操作，但文档指出未来可能支持撤销协作方的操作。从工程实现角度看，撤销映射的存储开销与操作数量线性相关，对于长期协作的大型项目，可能需要实现映射的压缩或裁剪策略。
并行代理场景下的状态同步与回退
Zed 近期引入的并行代理（Parallel Agents）功能将 CRDT 的应用扩展到了多 AI 代理协同编辑的场景。每个代理可以视为一个独立的编辑副本，拥有自己的副本标识符和操作序列。多个代理并发执行代码修改时，CRDT 保证了所有代理看到的最终文档状态一致。
在实际工作流中，并行代理可能共享同一工作副本，也可能运行在隔离的分支工作树（Worktree）中。共享工作副本时，所有代理的修改通过 CRDT 实时合并；隔离模式下，各代理在独立分支上操作，最终通过版本控制系统合并。无论哪种模式，DeltaDB 作为底层存储使用 CRDT 记录变更，支持字符级别的永久链接和实时协作。这意味着用户可以在任何时刻看到代理的光标位置和实时 diff，即使代理正在并发修改同一文件的相邻区域。
对于回退策略，当某个代理的操作导致问题时，可以利用 CRDT 的可逆特性进行精确回滚。由于每个操作都有唯一标识符，回退操作实际上是生成一个新的「撤销」操作，而非修改历史。这种设计天然支持审计和追溯，配合版本控制系统的分支机制，可以实现「尝试 — 回退 — 重试」的敏捷开发流程。从监控角度，建议追踪冲突解决的频率 —— 正常情况下 CRDT 应能自动收敛，频繁的手动干预可能表明代理间的操作存在潜在的语义冲突。
工程落地的关键参数与监控建议
基于上述机制，在生产环境中部署 Zed 的协同编辑功能时，以下参数和监控点值得特别关注。首先是 Lamport 时钟的同步状态，建议设置时钟偏差告警阈值，例如单副本时钟与全局最大值差异超过 1000 时触发告警，这可能指示网络分区或时钟同步异常。其次是墓碑比例，墓碑字符数与总字符数的比例不应超过 0.5，超过则建议触发数据清理流程。第三是操作队列长度，当远端操作队列积压超过阈值时，可能需要优化网络或增加同步频率。最后是副本健康度，每个副本的操作序列应该单调递增，若出现回绕则需要检查副本标识符分配逻辑。
对于多代理场景，还应关注代理操作之间的语义兼容性。虽然 CRDT 保证最终一致性，但不同代理可能对同一代码区域产生竞争性修改，导致编辑效率下降。建议在代理任务分配层面实现空间隔离，让不同代理操作不同的模块或文件，以减少不必要的冲突。
资料来源
本文核心技术与架构细节来自 Zed 官方博客对 CRDT 的深度解析（https://zed.dev/blog/crdts），该文章详细阐述了内容寻址、墓碑机制、因果排序等核心设计。平行代理与实时同步的实现参考了 Zed 官方文档与产品发布信息。