用 Delta 取代 Pull Request
今天，我们正式上线 Delta 的公测版——一个与 agent 协作编程、审查其产出的多人协作环境。之所以做 Delta，是因为 agent 已经从根本上改变了我们写软件的方式，但现有的协作工具却没跟上。
上周我们跨过一个关键节点：关闭了 Delta 自身仓库上的 pull request 功能。现在我们完全在 Delta 内部开发和协作。
Delta 与传统工作流的区别在于：协作不再依赖 commit 和 push 代码。你可以直接把队友拉进你和 agent 的对话中。对方加入后，能看到和你相同的工作区（worktree），并在自己的机器上操作。队友可以直接问同一个 agent，你当初为什么用 Mutex 而不是 RwLock。即使你下线了，他们也能接着你和 agent 的进度继续工作。
从今天起，任何人都可以在 macOS、Linux 或 Windows 上下载 Delta，也可以无需下载直接在网页端使用，出门在外还能用手机浏览器跟进讨论。
没有 pull request 的代码审查
自 GitHub 十五年前推出 pull request 以来，它一直是请队友审查代码变更的标准方式。但随着 agent 生成的代码越来越多，需要互相审查的 diff 也跟着爆炸式增长。
把大 diff 拆成一串分支确实更便于浏览，但代码背后的决策仍然需要审查，而小 diff 提供不了这些上下文。审查者也许会把你的 diff 丢给另一个 agent 来帮助理解，但那个 agent 得重新拼凑出你早已理清的决策过程。
为什么队友的 agent 还要去猜测你是怎么一步步做出这些决定的？
在 Delta 中，你可以邀请任何人接着你留下的线索继续，也可以创建一个专门的审查子线程。审查功能会引导你了解分支上的改动，并让你访问原始智能体的上下文。每次审查都会获得父线程工作树的一个隔离副本，这样你和你的团队就可以使用智能体探索代码并尝试修改，而不会干扰原始工作。如果审查者发现问题，他们可以申请修订，或者与智能体合作自行修复。在让智能体合并变更之前，审查期间做出的修改可以先整合到父线程中。
基于 DeltaDB 构建，兼容 Git
Delta 构建在 DeltaDB 之上，它将 Git 的基于内容的版本控制扩展为基于增量的版本。它不仅记录提交之间的编辑，还保留来自人类和智能体的消息，从而保存了代码在整个线程中的演化过程。提交仍然是你推送、拉取和构建的检查点。DeltaDB 则保留了这些检查点之间的工作状态。
你不需要让整个团队都迁移到 Delta 才能使用它。
例如，zed-industries/zed 暂时仍会保留在 GitHub 上，因为那是社区发现问题和提交变更的地方。我们鼓励 Zed 贡献者在提交 Pull Request 的同时分享 Delta 线程。贡献者可以在 Delta 中协作，同时继续通过 GitHub 提交变更；即使从未打开过 Delta 的队友，看到的依然是正常的 Git 仓库。
关注我们替换 GitHub.com 的征程
看起来大家都在竞相替换 GitHub。大多数竞争者承诺提供更好的可用性，但仍沿袭传统的分支、提交和 Diff 等基本原语。
我们相信，线程将成为软件开发的新基本单位，而用增量来建模其状态是最优解。
我们首先要告别的是 GitHub 工作流中的 Pull request。取而代之的是 Delta 线程，以及一种我们称为持续工程的协作方式。过去行业实现了集成持续化，随后是交付持续化，但软件工程的其他部分仍沿袭批量处理模式。在 Delta 线程中，从构思、实现、评审到变更落地，所有环节都能在同一处完成。
我们正在为开发者使用 GitHub.com 的其他工作流打造更优的替代方案，首当其冲的是 DeltaDB 中的 Git 存储。从长远看，基于内容的构建能力可以将 CI 风格验证直接引入线程之中。现阶段，用户可触发运行现有 CI 服务商，在将变更落地前先查验结果。
试用公开测试版
感谢数千位申请早期访问并协助我们发现 Delta 缺陷的用户。Delta 仍在成型，我们最关心的部分功能还在路上（关于< a href="https://delta.dev/roadmap">下一步计划可点击这里）。但它已是我们日常的标配工具：关闭 Pull request 以来，我们的 33 名成员已将 570 项变更落地到 main 分支。
公开测试期间，Delta 免费使用。我们将很快为个人和团队推出付费套餐，但 Delta 将始终提供免费的版本。
下载 Delta，启动智能体，邀请队友进入线程，体验其中的妙处。我们很乐意听听你的使用感受。