Zed推Delta，Git开始不够用

Zed 最近推出 Delta，并在官网开放 DeltaDB Early Access，把竞争范围从 AI 代码编辑器进一步扩展到版本控制系统。DeltaDB 是一套面向人类与 AI Agent 协作场景的新型版本控制基础设施，它不再只把代码历史理解为一串人工创建的 Git 提交，而是尝试持续记录、组织和查询代码变化。

这不是 Zed 给编辑器增加的又一个侧边栏功能，而是一次明显更重的底层下注。Cursor、Windsurf 等 AI 编辑器主要在模型调用、上下文检索和 Agent 执行体验上竞争，Zed 则开始追问一个更基础的问题：当多个 Agent 可以并行修改成百上千个文件时，继续用面向人类开发节奏设计的 Git 工作流，是否还能有效描述代码是怎样被改出来的？

Delta不是新的代码补全，而是新的变化记录层

Delta 是 Zed 团队对下一代版本控制工作流的产品化尝试，而 DeltaDB 是支撑这一尝试的代码变化数据库。按照 Zed 最新公开信息，DeltaDB 目前仍处于 Early Access 阶段，现阶段更适合被视为方向明确的基础设施预览，而不是可以立刻替换所有 Git 仓库的成熟产品。

传统 Git 是以提交快照为核心的分布式版本控制系统。开发者修改工作区、暂存文件、创建 commit，再通过分支、合并和 rebase 组织历史；这个模型经过二十多年验证，可靠、开放，而且拥有几乎不可替代的工具生态。

DeltaDB 的核心判断是，AI Agent 正在改变版本控制所面对的事件密度。过去一名开发者可能工作几十分钟后提交一次改动，现在同一名开发者可以同时启动多个 Agent，让它们分别阅读仓库、修改文件、执行测试和修复错误，几分钟内产生大量相互关联的变化。最终的 commit 还能保存结果，却很难完整表达每个 Agent 的任务边界、修改来源和中间决策。

这也是 Delta 最值得关注的地方：它瞄准的并不是“如何更快生成代码”，而是“如何管理已经快到失控的代码生成过程”。如果说 AI 补全解决的是输入速度，Agent 解决的是任务执行，那么 Delta 想解决的就是并发执行之后的追踪、审查与协作。

Git记录结果，Delta想记录过程

Git 的优势是稳定地保存项目状态，但 Agent 工作流需要更细粒度的变化来源。一个典型的 Agent 任务可能经历搜索符号、修改接口、更新调用方、运行测试、根据报错二次修复等多个步骤，最后却被压缩成一个文件 diff 或一个 commit。

DeltaDB 试图把代码演进当成可持续记录和查询的数据，而不是只在开发者按下提交按钮时才留下历史。这个思路与 Zed 此前反复提到的“metadata layers”一致：代码之外还需要保留围绕代码发生的人类讨论、Agent 指令和修改关系，让这些信息在文件移动或重构后仍有机会继续存在。

这里需要避免一个误读：Delta 当前不是 Git 已经失效的证明。Git 仍然适合作为跨平台交换、远程托管和发布版本的公共格式，Delta 更像是在工作区与最终提交之间增加一层高频、细粒度的变化数据库。它要补的是 Git 在 Agent 并发、来源追踪和持续协作上的空白，而不是简单重造 git commit。

| 对比维度 | DeltaDB | Git | Jujutsu（jj） | |---|---|---|---| | 核心定位 | 面向人类与 AI Agent 协作的代码变化数据库 | 分布式版本控制系统 | 兼容 Git 生态的新型版本控制前端 | | 主要记录单位 | 持续产生的变化及其关联信息 | commit、tree 和 blob | change 与 commit | | 对 Agent 并行工作的适配 | 产品设计重点 | 依赖分支、worktree 和外部编排 | change 模型更灵活，但并非专为编辑器内 Agent 设计 | | 编辑器结合程度 | 由 Zed 团队直接构建，目标是原生结合 | 通常通过命令行或编辑器插件接入 | 主要通过命令行与 Git 后端工作 | | 生态成熟度 | Early Access，尚待验证 | 极高，代码托管与 CI/CD 的事实标准 | 已可实际使用，生态规模仍小于 Git | | 开放与许可状态 | 截至 2026 年 8 月，完整开放范围仍需进一步披露 | 开源 | 开源 | | 价格 | 尚未公布独立商业价格 | 软件本身免费 | 软件本身免费 | | 适合现阶段替换 Git 吗 | 不建议直接下结论 | 是多数团队的默认选择 | 可在部分团队中作为 Git 兼容工作流使用 |

Delta 真正要证明的不是概念是否新颖，而是它能否无摩擦地嵌入现有 Git 生态。开发团队不会为了追踪 Agent 多装一套无法与 GitHub、CI/CD、代码评审和发布流程互通的孤岛系统，因此导入已有仓库、导出标准提交、处理历史重写以及与远程托管平台协作，都会决定 DeltaDB 能否走出 Zed 编辑器。

为什么由Zed来做，这件事有一定合理性

Zed 的优势是它控制了从编辑器渲染、文本模型到多人协作和 Agent 面板的完整技术栈。Zed 使用 Rust 从头构建，并通过自研 GPUI 利用多核 CPU 与 GPU；其编辑器核心采用 GPL，服务端组件采用 AGPL，GPUI 则采用 Apache 2.0 许可证。此前公开采访曾提到，Zed 代码库当时已接近 60 万行 Rust 代码，这使它具备直接改造编辑器底层数据流的能力。

完整掌控编辑器栈对 Delta 尤其重要。普通插件通常只能看到文件保存前后发生了什么，而编辑器本身可以观察缓冲区中的实时变化、光标位置、符号跳转、多缓冲区编辑以及协作者操作。版本控制如果想从“保存后的文件快照”向“持续变化流”演进，就需要尽可能靠近文本编辑的源头。

Zed 已经拥有可复用的多人协作基础设施。官方 AI 页面显示，Zed 可以让开发者实时跟随 Agent 在代码库中的导航和修改过程，并把 Agent 的改动汇总到可编辑的 unified diff 中，由开发者统一接受或拒绝。DeltaDB 如果能接住这条实时事件流，就有机会把一次性的审查界面升级为长期存在的变化记录。

Zed 还在通过 ACP 接入不同的编程 Agent。ACP 是用于连接代码编辑器与 AI 编程 Agent 的开放协议，Zed 当前支持把 Claude Agent、Codex、OpenCode 等工具带入同一个编辑环境；MCP 则用于为 Agent 扩展外部工具和上下文。模型和 Agent 越多，统一记录“谁改了什么、为什么改、基于什么上下文”的需求就越强。

Delta解决的是Agent并发后的混乱

并行 Agent 是 Delta 最现实的使用场景。假设开发者同时分配三个任务：一个 Agent 升级数据库依赖，一个 Agent 重构鉴权模块，另一个 Agent 修复相关测试；三个任务都可能修改配置文件、锁文件和公共类型定义。使用传统工作流时，团队往往要为每个 Agent 创建分支或 worktree，再手动判断冲突和提交顺序。

Delta 的潜在价值是把每个任务的变化身份与最终文件状态分开管理。这样一来，即使多个 Agent 触碰同一文件，编辑器也有机会按任务、参与者或意图展示变化，而不是只给开发者一份混杂在一起的行级 diff。对于代码审查者而言，“这十行来自依赖升级任务”通常比“这十行在第 214 行到第 223 行发生变化”更有用。

来源追踪还可能成为 AI 代码治理的必要能力。企业团队不仅需要知道代码最终是否通过测试，还需要知道改动由哪个 Agent 发起、使用了什么指令、经过哪些人工修订，以及哪些结果最终进入发布分支。Git 可以承载部分元数据，但如果所有信息都依靠开发者手动整理进 commit message，执行质量很难稳定。

不过，Zed 目前公开的信息还不足以证明 DeltaDB 已经解决所有并发冲突。尤其是语义冲突并不会因为存储模型改变而自动消失：两个 Agent 即使修改不同文件，也可能对同一接口做出不兼容假设。Delta 可以改善变化的可见性与组织方式，却不能代替测试、类型检查和人工架构判断。

对Cursor和Windsurf而言，压力不在编辑速度

Delta 让 Zed 与 Cursor、Windsurf 的竞争从功能数量转向架构差异。Cursor 和 Windsurf 已经建立了成熟的 Agent 产品认知，在模型选择、代码库检索、终端工具调用和任务自动执行方面拥有先发优势；Zed 较晚强化 Agentic Editing，但它试图用原生编辑器、多人协作和版本控制层形成更深的组合。

| 产品 | AI 工作流重点 | 变化审查方式 | 底层编辑器路线 | Delta式版本控制布局 | |---|---|---|---|---| | Zed | 原生 Agent、多 Agent 并行、实时跟随与协作 | Multibuffer、可编辑 unified diff | Rust 与 GPUI 从头构建 | 已推出 DeltaDB Early Access | | Cursor | Agent、代码库上下文与 VS Code 生态兼容 | 编辑器 diff 与 Agent 任务界面 | 基于 VS Code 体系演进 | 目前仍主要围绕 Git 工作流 | | Windsurf | Agent 任务流与代码上下文联动 | 以 Agent 生成改动和 diff 为主 | 基于成熟编辑器生态构建 | 目前仍主要围绕 Git 工作流 |

Zed 的路线更难复制，但也更难完成。自研编辑器意味着团队能深入改造数据结构和交互方式，同时也要独自补齐调试器、扩展生态、远程开发和企业管理等大量基础能力。值得注意的是，Zed 官网截至 2026 年 8 月已经列出 macOS、Linux 和 Windows，早期报道中“尚不支持 Windows”的描述已经过时。

Delta 因此不是 Zed 已经胜过 Cursor 或 Windsurf 的证据。现阶段更准确的判断是，Zed 找到了一个足以形成差异化、又确实会被 Agent 普及放大的问题；但竞争优势只有在 DeltaDB 可用、可靠、可迁移，并且不会给开发者增加额外心智负担后才成立。

现在仍有四个关键问题没有答案

DeltaDB 的技术野心已经清楚，但产品成熟度仍然缺少硬指标。Zed 尚未公开足够完整的性能基准，例如大型单体仓库的初次索引时间、持续记录带来的磁盘开销、百万级变化下的查询延迟，以及多 Agent 同时写入时的吞吐量，因此目前不能仅凭“数据库化”就判断它比 Git 更快。

接下来最值得观察的是四件事：

1. 与 Git 的互操作性。 DeltaDB 能否稳定导入已有历史，并把任务级变化导出为结构清晰的标准 commit，将直接决定团队采用成本。
2. 数据所有权与开放程度。 Zed 编辑器本身高度开源，但 DeltaDB 的客户端、服务端、存储格式和同步协议是否开放，仍需要明确答案。
3. 离线与本地优先能力。 版本历史属于高敏感资产，企业用户会关心记录是否必须上传云端，以及能否在内网或自托管环境运行。
4. 可量化的规模表现。 DeltaDB 需要公开仓库规模、并发 Agent 数量、写入吞吐、查询延迟和存储增量，否则很难与成熟 Git 工具链进行工程比较。

安全边界同样不能被“更完整的历史”掩盖。持续记录编辑过程可能包含尚未提交的密钥、内部路径、失败代码和 Agent 对话，DeltaDB 必须提供清晰的忽略规则、保留周期、访问权限和删除机制。对于企业客户而言，能够记录一切不一定是优点，能够精确决定什么不被记录才是刚需。

Zed正在把编辑器变成开发活动数据库

Delta 最重要的信号是，AI 代码编辑器的下一阶段可能不再围绕补全准确率展开。随着 Claude Agent、Codex、OpenCode 等 Agent 可以独立浏览项目、执行工具和修改文件，编辑器正在从文本输入工具变成任务调度器、协作空间和变化审查中心。

Zed 想再向前走一步，把编辑器变成代码开发活动的数据库。代码只是最终产物，围绕代码发生的任务、讨论、Agent 操作、人工修订和审查决定，也被视为值得长期保存和查询的一等数据。这与 Zed 最初强调的实时多人协作并不冲突，反而把“人与人协作”延伸成了“人与多个 Agent 协作”。

我们的判断是，Delta 方向正确，但现在下“Git 终结者”的结论明显过早。Git 的真正壁垒不是提交命令，而是全球代码托管、CI/CD、发布和审计系统共同形成的生态；DeltaDB 更现实的机会，是先成为 Git 之上的高频工作层，再逐步证明一种面向 Agent 的变化模型能否成为新标准。

对开发者而言，现阶段没有必要迁移仓库，但值得关注 DeltaDB 的 Early Access 进展。它能否让并行 Agent 的修改更容易理解、拆分、回退和审查，比任何“生成速度提高多少”的宣传都更重要——因为 AI 编程真正稀缺的已经不是代码产量，而是对代码变化的控制力。

参考来源

• Zed Industries / Zed GitHub 仓库：Zed 编辑器的官方开源代码库，可用于核对其 Rust 技术栈、许可证、Agent、Git 与协作功能的实际实现。