Claude Code Projects：在同一个代码仓库上同时运行多个代理

今天早上，和每天早上一样，我把三个 Claude Code 窗口并排打开。一个在修某个角落里的 bug，一个在另一个地方写测试，第三个在做文档，而我在中间，因为这三个窗口都在操作同一个仓库，只能把文件从一个文件夹抄到另一个文件夹。能用，但我大部分时间都在站岗。

这周，Anthropic 介绍了可以让我不用再站岗的东西。消息是媒体报道出来的，不是那家公司自己的博客，所以我就按它现在的样子来看，一项正在部署中的公告。但它描述的，正是我每天都在面对的问题。

Projects 会变成什么

到目前为止，Projects 是你存放一个项目及其上下文文件的地方。以后，暂且这么说，因为它还没真正到我手里：它会变成你提出一个目标，然后由一台机器自动把目标拆成几块，交给多个代理去做的地方。

你写下自己想要得到什么，比如重做登录页面和它的测试。一个协调代理查看工作，把它拆开，然后把每一块发送到一个单独的线程里。每个线程都是 Claude Code 的完整会话，运行在云端某个地方，拥有自己的仓库副本和自己的分支。这些线程不会互相踩到，因为它们操作的不是同一批文件，而当它们互相踩到时，机器会发现。

三个窗口，一个仓库，还有一个来回奔波的人。这就是我这一年来每天早上做的事

真正重要的细节：冲突

这就是大多数文章一带而过的地方，但这恰恰是整个东西最有意思的地方。当两个人同时修改同一个文件里的同一行时，Git 拒绝替你选择，要求你手动裁决。这就叫合并冲突，所有项目都会遇到，而这正是大多数人不敢在同一个仓库上启动三个代理的原因。风险不在于它会崩掉，而在于最后得把一团乱麻理清。

在 Projects 里，这件事不用你来做了。两个线程碰到同一个地方时，会产生一个冲突，机器会把它展示出来，并像处理一个普通的修改提案那样解决它，也就是那种我们会在接受前先审阅的提案。这个机制很普通，所有开发工具里十五年前就有了。新鲜的是，它现在被用在那些会自己写代码的代理身上。

道岔只做一件事：把每节车厢送上正确的轨道。协调器对任务做的也是一样的事

第二件我没想到的事：这些线程共享记忆和中间文件。一个线程如果已经弄明白身份验证是怎么工作的，就不用向旁边的线程解释。每个线程还可以反过来启动自己的子代理、循环和任务链。三层嵌套，差不多可以说，别从走廊尽头看这东西。

为什么这比又一个新功能更让我有共鸣

因为我现在手动做的事，做得很差。我把工作分成三份，因为会话之间互不交流，所以把上下文解释三遍，把代码片段从一个文件夹抄到另一个文件夹，最后还得多审查一倍，确保没人把别人的工作覆盖掉。

真正的收益不是写得更快，而是不必再记录谁在碰什么。一个负责拆分工作并监视碰撞的协调器，正是我这一年来扮演的角色，只是我做得没那么好。如果你已经试过让两个 Claude Code 账号并行运行，你就知道这些管线很快就要付出代价。

它还做不到什么

得冷静下来。上线时，一切都在云端进行：你的代码仓库会发往 Anthropic，你的代理在他们的机器上运行，而本地支持要等到以后，时间未定。如果你在处理一个不允许离开公司内部的企业代码仓库，这个版本暂时还和你无关。

接下来，这是一个测试版，只面向一部分 Pro 和 Max 订阅者。不是今晚装上就能用的成品。开放给团队套餐和这家公司的其他应用已经列入计划，“计划”是软件厂商词汇里最有弹性的词。

即将开放，但有条件，只面向部分客户。所有软件厂商都会挂在橱窗上的那块牌子

还有一个问题目前没人回答，也是我最担心的问题：配额。一个 Claude Code 会工作一小时的会话是要花钱的，而你同时启动五个，它花钱的速度就是五倍。我上周正好提到过配额在不明不白地减少。在一个用量封顶的订阅上增加代理，主要就是加快你盯着计数器看的速度。

问题的核心

两年来，我们学会了和一个代理交谈，然后给它工具，再然后编写不用我们提示就能自行运行的循环。下一步，就是把它们几个放到同一个项目上，这迫使我们解决一些开发过程中早就知道的问题，任务分配、冲突、复查。没什么神奇的：和团队里一样的那些麻烦，只不过换成了永远不会睡觉的同事。

这并不让我害怕，甚至让我稍微安心了一点。一个告诉你它无法同时处理两项修改的工具，就无法处理真正的项目。这个工具承诺自己能做到，而这正是我们要看它是否认真的地方：看它第一次自行裁决冲突时的表现，也看我重读它的决定时会是什么表情。