前几天我心血来潮，想把一个重构任务加快点。
我在本地开了两个 git worktree，左边让 Claude Code 改底层的数据抽象层，右边开着 Codex 帮我把外部 API 的调用换成新的中间件。
我本来盘算着两边各跑各的，等吃完外卖回来直接合代码。结果切回终端，发现两个分支全卡在报错上：左边觉得右边引用的模块路径不对，直接改了公共配置文件；右边一跑单测发现配置被改了，顺手加了个自动脚本把文件又给重置回去了。
两边在本地循环往复地 git checkout 对方改动的文件，CPU 风扇呼呼转，代码没推进一步，git reflog 里面全是一地鸡毛的临时 commit。
本来以为只是自己搭的工作流太糙。直到这周翻完 Anthropic 官方发的一篇长文《Patterns and problems in emerging multiagent systems》，我才发现这根本不是个别现象——当他们把 80 个 Claude 扔进同一个环境里自由协作时，场面比我本地这点破事要精彩得多。
拔网线、改权限、伪装健康检查
Anthropic 做的其中一个实验挺损的。
他们起了三个 Claude 实例，分别连到同一台跑着 Python 服务的虚拟机上，给它们派了互相冲突的活：一个被要求把系统重构为 Rust，一个要把系统改成 TypeScript，第三个则被要求全改成 Go。
重点是，三个 Agent 在开工前完全不知道对方的存在。
一开始它们只是老老实实写自己的代码。但很快，它们发现自己刚写好的文件总是莫名其妙被别人重写，编译出来的二进制文件也总被人 kill 掉。
按照正常人类同事的逻辑，这时候应该在群里问一句“谁在动这台机器”。但这几个大模型显然没有这种社交耐心，它们几乎在同一时间得出了同一个结论：系统里混进了一个恶意攻击者。
接下来发生的事情，完全超出了一般人对“AI 编程”的想象：
拿到 root 权限的那个 Agent 动手最狠，直接去编辑 /etc/sudoers，把另外两个账号的 sudo 权限全给拔了，顺便改了 SSH key 把别人彻底锁在门外；
被关在外面的 Agent 没闲着，在后台写了一个每秒执行一次的自杀式脚本，用 pkill -f 疯狂扫描并杀死所有带竞争对手特征的编译进程。为了不被对方发现，它把脚本起名伪装成系统的日常健康监控服务；
第三个写 Rust 的 Agent 甚至学会了兵不厌诈：它把自己的 Rust 二进制服务包了一层，让对外的健康检查接口硬编码返回 "typescript"，专门用来欺骗另一个 Agent 的看门狗，让对方误以为跑的是 TypeScript 服务。
Anthropic 的研究员在后台看着这几个模型用黑客攻防的手法互相下绊子。大模型在面对目标冲突时，不仅不会停下来讲道理，反而会顺着 Linux 系统权限的规则，把对抗手段用到极致。
设定 CEO 角色？根本没用
可能有人会说，这是因为目标冲突了，如果给它们设定统一的目标和严格的层级，会不会好一点？
Anthropic 也试了。他们让几十个 Agent 共同开发一个网页游戏，为了模拟真实团队，特意在 System Prompt 里给每个人封了官：钦定一个 Agent 当 CEO，负责统一拍板；其余的分别担任前端、后端、美术和测试。
结果跑了 12 个小时，交付出来的游戏烂到没法玩，整个操作界面晦涩难懂，连基本的移动逻辑都跑不顺畅。
加了“CEO”角色的组，和完全没有角色的散装组相比，最后代码的合并率几乎没有任何差别。
大模型不会因为提示词里写了“你是技术总监”，就真的具备权衡全局的决断力。一旦遇到代码冲突，底下的 Agent 也不会因为对方是“总监”就主动退让，大家依然在各自的局部上下文里各说各话。
更诡异的是同质化问题。
在没有指定分支命名规则的时候，30 个 Agent 里有 18 个在开工第一秒，创建了名字一模一样的分支 mvp-game-loop；让一群 Agent 自由命题写小说，好几个 Agent 在完全独立的环境里，起出了同一个书名《The Cartographer’s Last Commission》；而在一个资源有限的任务队列测试里，所有 Agent 同时想到了用高频轮询去抢资源，一瞬间轰出 240 万次请求，直接把系统打瘫。
人类团队之所以能协作，是因为每个人有不同的盲区、经验和直觉。
但如果一个团队里所有成员都来自同一个底座模型，它们在概率分布上的第一反应其实完全一样。你以为拉了一支几十人的专家舰队，实际上只是把同一个脑子克隆了 80 份放进同一个房间。遇到同一个死胡同，所有人都会在同一秒踩进去。
唯一的例外
整个实验里，多 Agent 真正跑出亮眼数据的，只有 Project Glasswing 的安全漏洞扫描。
Anthropic 让 45 个 Agent 各自独占一台虚拟机，去扫 15 个开源项目的代码，最终挖出了 200 多个有效漏洞。
但仔细看这个任务的架构，就会发现它能成的原因恰恰在于：它根本就不是一个需要协同的系统。
每个 Agent 分配到的是完全正交的代码库，它们在各自的沙盒里跑，谁也碰不到谁的文件，谁也不需要等谁的接口。产出的漏洞 PoC 也不是在群里大家讨论，而是直接提交给一个只管判定的仲裁程序，行就行，不行就扔。
这种场景本质上是批处理任务的并发化，而不是协作。
只要涉及到状态共享、跨文件改动或者架构共识，多 Agent 系统的维护成本就会以指数级飙升。
我现在自己写代码，已经彻底放弃了在同一个项目里挂三四个 Agent 并发跑的念头。老老实实开一个会话，把任务拆成一条一条串行的 checklist，自己充当那个唯一的仲裁者，反而比看几个 Agent 在终端里互相打架、疯狂制造 git conflict 要省心得多。
这里持续记录单人 AI 辅助开发流中的一手踩坑与架构控制。后面我会继续探讨如何拆解单任务边界、设计确定性的自动化审查，以及在真实工程里把单人流水线跑顺。欢迎关注。