多Agent翻车现场：并行带来的冲突、漂移与合并地狱
多Agent并行开发听起来很美好：把一个大项目拆成几块，让多个AI Agent同时干活，速度翻倍。实际上手才发现，"并行"这个词背后藏着一堆你没想到的麻烦。我最近研究了几个多Agent协作的案例，发现踩坑的方式出奇地一致。
01 三类典型翻车
第一类是文件冲突。两个Agent同时改同一个文件，各自觉得自己的改动是对的。合并的时候Git直接报冲突，而且这种冲突往往不是简单的几行重叠，而是两段逻辑互斥。你得理解两个Agent各自在想什么，才能决定保留哪个版本。
第二类是状态漂移。Agent A改了一个接口的返回格式，Agent B不知道这件事，还在按老格式调用。两个人各自的代码都能跑通单元测试，合到一起就炸了。这个问题在人类协作中也存在，但Agent比人的速度快得多，漂移积累的速度也快得多。你可能十分钟没看，两个Agent已经各自往不同方向跑了五步。
第三类是合并地狱。前两类问题如果没有及时处理，冲突会像滚雪球一样堆积。到了某个点，手动解决合并冲突的时间比让Agent重新写一遍还长。我见过一个案例，十几个分支同时开发了两天，最后合并的时候花了比开发更长的时间清理冲突。
02 Nicholas Carlini的16个Claude实例
今年2月，Nicholas Carlini公开了一个实验：他用16个Claude实例并行开发一个C编译器。这个案例提供了一个真实的多Agent协作样本。
他的协作机制是这样的：每个Claude实例运行在独立的Docker容器中，通过一个共享的Git仓库来协调。Agent自行认领任务，方式很朴素，用lock文件。一个Agent想做某个任务，先创建一个lock文件声明"这个任务我来做了"。其他Agent看到lock文件存在，就跳过这个任务去找下一个。
合并冲突怎么处理？Agent自己解决。如果解决不了，就放弃当前分支，从最新的main重新开始。这种"做不好就重来"的策略听起来粗暴，但在token成本可控的情况下，比花时间调试一个复杂冲突要高效。
最终的结果是产出了大约10万行代码。过程中有没有翻车？当然有。有些Agent因为解决冲突失败反复重试，浪费了token。有些任务因为拆分不够细，两个Agent在边界处打架。但整体而言，这套机制跑通了，说明多Agent并行是可行的，前提是你得接受一定程度的浪费。
03 实际能用的解法
研究了几个案例之后，我总结出四个减少翻车的做法。
任务切片边界要清晰。这是最重要的一条。每个Agent负责独立的文件或模块，交叉越少越好。理想情况是Agent之间完全不碰同一个文件。做不到完全隔离的话，至少要做到改同一文件的Agent不超过两个，并且明确各自负责文件的哪个部分。
锁文件和claim机制要有。Agent认领任务前先锁，避免两个Agent抢同一个任务。Carlini用的就是这个方案，简单但有效。锁的粒度可以是任务级别，也可以是文件级别。文件级别的锁粒度更细，能允许更多并行，但实现复杂度也更高。
分支策略要明确。每个Agent一个分支，定期合并到主分支。"定期"这个频率很关键。合并太频繁，Agent还没做完就要处理冲突，打断工作流。合并太稀疏，漂移积累太多，后面的冲突更难解决。根据我看到的案例，每完成一个完整的子任务就合并一次是比较合理的节奏。
合并门禁不能省。自动化测试通过才允许合并到主分支。这条在人类协作中是常识，在多Agent场景下更加重要。因为Agent产出代码的速度快，如果没有门禁，问题代码进入主分支后会被其他Agent拉取，污染所有人的工作基线。
04 并行还是串行，看项目规模
不是所有项目都适合多Agent并行。
适合并行的情况：项目足够大，能拆出五个以上互相独立的模块。每个模块有清晰的接口定义，内部实现互不影响。团队对时间敏感，愿意用更多token换更快的交付。
适合串行的情况：项目的模块之间耦合度高，改一个地方会牵动好几个文件。代码量不大，一个Agent花几个小时就能做完。你在探索阶段，还不确定架构怎么设计，这时候多个Agent同时开工只会制造更多返工。
一个粗略的判断标准：如果你画不出一张图，让每个Agent的工作范围互不重叠，那就别硬上并行。串行跑两遍，可能比并行跑一遍然后花两天解决冲突要快。
05 我对多Agent协作的现阶段判断
多Agent并行开发是可行的，Carlini的案例证明了这一点。但"可行"和"好用"之间还有距离。
现在的工具链还比较原始。锁文件是最低级的协调机制，相当于你给一群实习生每人发一张纸条写"我在做这个任务"。没有实时的状态共享，没有智能的冲突预防，也没有自动的任务重新分配。当某个Agent卡住的时候，其他Agent不知道，也帮不上忙。
我觉得未来的方向是更智能的orchestrator。不是让Agent自己协调（它们其实不擅长这个），而是有一个中央调度器来分配任务、监控进度、处理冲突。Claude Code的Tasks功能已经在往这个方向走了，但离成熟还有一段路。
现在如果你要用多Agent，我的建议是保守一些。先从两到三个Agent开始试，把协调机制跑通了再逐步加Agent数量。一上来就开16个实例，除非你像Carlini那样对项目架构有绝对的把控力，否则大概率是在给自己制造问题。
参考链接： https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-working-together-created-a-new-c-compiler https://code.claude.com/docs/en/agent-teams https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them