当对话成为代码的真正源头
Zed 团队创始人 Nathan Sobo 坦言："我从来不是 Pull Request 的粉丝。"在没有 AI Agent 之前，人们容易相信在代码快照上交换评论是一种有效的协作方式，但对于 Zed 团队来说这从来行不通。
Zed 团队经常在同一个 worktree 中协同工作，通过边写代码边讨论来建立信任和共同理解。GitHub 不允许你在提交和推送之前讨论代码——但那时他们最重要的对话往往已经结束了。
2021 年，Zed 的创立就是为了突破提交（commit）的限制。他们的计划是打造一款配得上世界顶级开发者的编辑器，然后在其中提供更好的协作方式。如今随着 AI Agent 的兴起，那些他们在人与人协作场景中思考了多年的问题变得更加重要。
生成代码的对话正在成为软件真正的源头。这段对话是持续展开的，必须与代码的变更相互参照。而 Git——围绕离散的 commit 组织——从未被设计来支持这一点。
DeltaDB：不仅仅是提交
Zed 正在构建的就是这样一个系统——DeltaDB，一种全新的版本控制，建立在一个统一的抽象之上：将你与 Agent 的对话以及它们编辑的 worktree 转化为共享制品。
DeltaDB 将你的工作拆解为一系列细粒度的 delta（增量）。Git 在每个 commit 捕捉一个快照，而 DeltaDB 捕捉 commit 之间的每一次操作，并为每个操作赋予一个稳定标识。因为每个 delta 都可以独立寻址，你可以在代码演化的任何时刻指向它——即使它在不断变化。
一条消息和它产生的编辑被并排记录，两者不会漂移分离。由于 DeltaDB 内置了无冲突复制 worktree（CRDT），多人或多 Agent 可以在不同机器上同时编辑同一个文件。
源代码即源对话
因为每个引用都锚定到 delta 而非行号，即使代码在下面移动了，引用仍然有效。从过去对话中的任何一行，你都可以跳转到该代码现在的状态，或当初 Agent 编写它时的状态。从任何一行代码，你都可以找到产生它的对话，以及自那以后触及过它的每一次对话。
Agent 也可以利用这一点。它们可以获取所碰触代码背后的上下文，或者召集之前处理过这些代码的 Agent，询问为什么要这样写。
协作不需要提交
最终目标很简单：与 Agent 的对话成为你唯一需要的对话。队友可以在工作还在进行时加入，与完成工作的 Agent 对话，边走边批注——无需等你先 commit 再 push。
Pull Request、审查线程和内联注释之所以存在，是因为讨论和代码生活在不同的地方。把两者放在同一个地方，这些仪式自然就消失了。Git 和 CI 仍然存在——但只做它们擅长的事：运行检查、连接你和外部世界。
展望未来
软件现在在对话中成形，而非在 commit 中。DeltaDB 就是为此而生的版本控制系统。Zed 将在数周内向早期用户开放 Beta 版本。
