Zed 在官方博客里宣布，DeltaDB 将在数周内开放测试版。

它最反常的地方，不是又做了一个版本控制系统，而是把记录单位从 commit 往前挪了一步：每一次编辑、每一次 Agent 操作、每一段产生代码的对话，都被记录成连续的 delta。

这件事的关键问题是：AI Agent 开始参与写代码后，团队到底该审查最终 diff，还是也要审查代码生成过程？

我的判断是，DeltaDB 目前还不能被看成 Git 替代品。它更像是在补一个老工具链没认真覆盖的位置：提交之前，代码还在变化时，人和 Agent 怎样共享上下文、接续工作、追溯责任。

Git 管提交后，DeltaDB 瞄准提交前

Git 的强项是快照。

开发者把一段工作整理成 commit，再 push、开 PR、跑 CI、接受 review。这个流程很稳，也很清楚。它把协作压到一个相对固定的边界上：这次改了什么，谁提交的，能不能合进去。

但 AI Agent 参与后，问题变细了。

团队不只想知道“这段代码最后长什么样”。还会想知道：Agent 为什么这么改？它参考了哪段上下文？中间有没有被人纠正？另一个 Agent 接手时，能不能看懂前一个 Agent 的意图？

Git/PR 模式不是不能处理这些问题，而是处理得很绕。对话在聊天窗口，解释在 PR 描述，临时判断在本地工作区。等到 commit 出现，很多过程已经散了。

DeltaDB 押的就是这段空白。

对比项Git / PR 模式DeltaDB 的设想直接影响
记录单位commit 快照每次细粒度操作 delta能回看代码形成过程
协作位置push、PR 之后worktree 仍在变化时讨论和修改可以前移
代码与对话常分散在 PR、Issue、聊天工具绑定保存为同一协作产物可从代码追溯生成它的对话
工具边界Git 仓库和 CI 是中心worktree 可挂载到磁盘现有终端和工具仍能介入

这不是说 PR 没用了。

大团队依赖 PR，不只是因为习惯。权限、审计、合规、安全扫描、责任划分，都需要一个可冻结的边界。没有这个边界，工程组织很难运转。

Zed 对 PR 的批评，更准确地说，是来自它自身产品叙事和协作偏好：PR 太晚，很多判断已经发生在代码写出来之前。这个判断有价值，但不能直接放大成行业共识。

DeltaDB 的新意，是把操作和对话绑在一起

按 Zed 的说法，DeltaDB 会把 worktree 里的每次操作拆成可寻址的 delta。每个 delta 都有稳定身份。

这带来一个变化：某一行代码不只对应一个 commit，也可能对应某段 Agent 对话和一串操作记录。代码不再只是结果，还带着生成它的上下文。

这对 AI 编程工作流很要紧。

过去团队问“谁写了这段代码”，答案通常是某个开发者和某个 commit。Agent 加进来后，真正难的是“为什么这样写”。如果这个答案只存在于临时聊天里，后续审查和维护都会变重。

DeltaDB 试图把这部分也存下来。

Zed 还提到，DeltaDB 支持多人和多个 Agent 在同一个 worktree 中并行编辑，并通过无冲突复制的方式同步。文件也不是只锁在编辑器内部。worktree 可以挂载到磁盘，终端和现有工具仍可操作这些文件。

这点很现实。

开发者工具如果只在一个编辑器里成立，很难进入严肃工程流程。工程团队不会因为一个漂亮的协作模型，就放弃脚本、终端、测试工具、CI、安全扫描和发布系统。

所以，DeltaDB 真正要证明的不是“记录更细”。记录更细只是基础。

它要证明的是：这些细粒度记录不会把团队拖进更重的噪音里。否则，代码审查会从看 diff，变成翻流水账。

对开发者工具和工程团队，动作不一样

对开发者工具从业者，DeltaDB 提醒的是一个产品方向：AI 编程工具的竞争，不会只停在“谁生成代码更快”。下一层竞争会转向上下文管理、协作记录、可追溯性和多人 Agent 编排。

如果你在做 IDE、代码托管、代码审查或 Agent 平台，短期动作不是立刻跟进一个 DeltaDB，而是检查自己的产品有没有回答三个问题：Agent 的操作能不能被追溯？对话能不能进入工程记录？多人和多 Agent 改同一批文件时，冲突和责任怎么处理？

对正在引入 AI Agent 的工程团队，动作更保守。

DeltaDB 现在只是即将开放的 beta，不适合被当成主干版本控制方案来迁移。更合理的做法，是把它放进小范围试验：挑低风险仓库、内部工具或 Agent-heavy 的原型项目，看它是否真的降低接手和审查成本。

采购或平台选型也不该急。

如果团队已经在评估 AI 编程工具，可以把“对话与代码变更是否可追溯”加入打分项。但不要因为 DeltaDB 的叙事，就提前改掉 Git、CI、代码托管和权限体系。那是本末倒置。

现实约束还很多。

DeltaDB 的稳定性、冲突处理体验、权限模型、存储开销、在大型 monorepo 里的表现，目前都还没有足够公开答案。Zed 也没有宣称要取代 Git。它的说法更接近：Git 和 CI 继续承担检查、发布前边界和外部连接，DeltaDB 管提交之前的协作流。

接下来最该看三件事。

  • 高频编辑下，delta 记录会不会变成负担。
  • 从代码追溯对话，是否真的能减少 review 和接手成本。
  • 它能否不绑死 Zed 编辑器，进入现有工具链。

如果这三点答不好，DeltaDB 就是一个很聪明的编辑器实验。答得好，它才有资格成为 AI Agent 协作里的底层记录层。

回到开头那个问题：AI Agent 写代码后，团队到底该审查什么？

只审查最终 diff，可能不够了。但把全过程都搬进工程系统，也不天然正确。好的版本控制，不是记录越多越好，而是把该留下的现场留下，把该冻结的边界冻结。