Zed在6月11日发布了一篇题为《Software Is Made Between Commits》的博文,宣布旗下版本控制系统DeltaDB开放早期访问申请。它想解决一个具体问题:Git以commit为最小单位,而AI coding agent在两次commit之间跑出来的大量中间尝试——被推翻的方案、被采纳的建议、反复的调试——在现有版本控制体系里几乎不可见。
DeltaDB给出的方案是:每个操作都有稳定标识,可以回溯到任意一次编辑;每处代码变更和产生它的agent对话双向关联;worktree被虚拟化,分支近乎零成本,哪怕在agent运行中途也能分叉;队友不必等你commit,可以在工作进行中直接加入对话、做批注。
四个卖点听起来都指向同一件事:把版本控制的颗粒度从"提交"降到"操作"。但产品页面写得再漂亮,也回避不了一个更朴素的问题——它现在到底能不能用。
承诺"几周"却拖了两个月
答案不算好看。6月11日的发布博文里,Zed明确说beta版会在"几周内"向早期用户开放。可截至8月5日,DeltaDB官网仍标注为Early Access,只留了一张申请表单,没有任何公开的正式发布(GA)公告。
一个产品从"发布"到"能用"之间隔了近两个月,这在AI原生工具的发布节奏里并不常见——大多数团队宁可晚一点公布,也不愿意让承诺的时间窗口被公开打脸。这中间到底是技术难度超出预期,还是团队主动放慢了节奏,Zed没有公开解释。但至少说明一件事:回溯任意编辑、零成本分支这些描述,目前还只是产品愿景,不是可验证的交付状态。
CRDT加持,但定位是补充层不是替代品
从技术路线看,DeltaDB底层用的是CRDT(无冲突复制数据类型)架构——这套技术Figma、Google Docs等实时协作产品已经用了多年,Zed把它挪到了版本历史层面。它把worktree做成可复制的结构,允许多个人和agent在不同机器上同时改同一份文件;每个操作(delta)有独立的稳定标识,引用锚定在delta而不是可变的行号坐标上,代码挪了位置,历史引用照样有效。
但Zed自己把DeltaDB定位为Git的补充,不是替代。Git和CI仍然负责外部集成、代码检查和发布这些工作,DeltaDB只负责实时协作和操作级别的历史记录。即便worktree被虚拟化,agent依然可以通过终端访问文件,用户也能把worktree挂载到磁盘,用平常的开发工具照常操作。
- 结论.DeltaDB更像是在Git仓库之上叠加一层更细的编辑日志,而不是重新发明版本控制本身。
这个定位其实削弱了"颠覆式"的营销语气。业内做细粒度、非快照式版本控制的尝试并不新鲜,Jujutsu(jj)、Sapling都在做类似的事——只是它们没有把"agent对话"作为一等公民接进版本历史。DeltaDB真正的差异化,可能不在版本控制模型本身,而在于它把AI agent的交互记录也纳入了可寻址、可回溯的历史里。这算不算核心突破,现在还很难下结论。
没被回答的几个问题
Zed计划未来把DeltaDB开源,并提供可选付费服务,类比的是Zed编辑器本身"开源+商业化"的路径。但具体开源时间表、定价模式,官方都没有公布。
更悬而未决的是几个技术细节:对话和代码被CRDT跨机器同步之后,数据存在本地还是云端?团队的私有代码和agent对话记录,是否可能被用于分析或训练?"操作"的粒度到底细到什么程度——是每次按键,还是每轮agent对话?这直接决定了历史记录会不会膨胀到难以使用。大规模代码库、多agent并发编辑场景下,CRDT复制worktree的性能开销有多大,也完全没有公开数据。
- 风险.隐私、存储位置、并发性能这三项关键信息目前均未披露,企业用户在评估前很难做尽调。
目前也没有找到任何独立的社区实测反馈——没有Hacker News讨论,没有第三方团队公开的使用体验。这意味着现在能看到的关于DeltaDB的一切,都还只是Zed自己讲的故事。
说要重新定义版本控制,自己先要能按时开门。
对正在用Claude Code、Cursor这类agent工具写代码的团队来说,DeltaDB描述的痛点是真实的——commit粒度太粗,agent中间过程留不下痕迹,这确实是现有工作流的空白。但"愿景清晰"和"能不能规模化落地"是两回事。接下来真正值得盯的,不是它又画了什么新功能,而是早期访问什么时候真正扩大、开源时间表什么时候公布、有没有第一批团队愿意公开讲自己的使用体验。