47个任务，30小时监督，120小时工作量被压缩到4分之1。这组数字来自一个真实的Rust项目——不是Demo，是5.1万行代码、有真实用户的生产环境。
作者用5个AI编程代理并行工作了一周。结果既验证了多代理协作的可能性，也暴露了当前技术边界里那些容易被忽视的暗礁。
架构师是唯一的"人"，其他全是"手"
每天早上前30分钟，架构师代理只做一件事：读需求 backlog，把模糊的目标拆解成独立、可测试的任务单元。
这个环节决定了全天是顺畅推进还是陷入冲突地狱。作者对比了两种拆解方式——"重构消息路由系统"这种表述，三个代理同时开工必然撞车；而"提取投递重试逻辑到独立模块""给消息投递加超时配置""给Maildir原子重命名写测试"，三个任务互不干扰。
架构师的质量输出，是整套系统的隐形天花板。
这有点像工厂里的IE工程师。产线工人可以有很多，但能把复杂工序拆成不打架的工位，才是稀缺能力。目前这个环节还离不开人的判断，或者说，离不开一个"懂业务且会写提示词"的人。
测试门：12次拦截与3次"差点出大事"
每个代理提交代码后，必须先过测试门。作者记录了12次"代理宣称完成但测试失败"的情况——没有这扇门，12个带病的分支会直接进入主干，引发级联故障。
典型故障模式：代码能编译、看起来对、主流程跑得通，但漏了边界条件、搞坏了既有测试、或者引入隐蔽回归。测试门把失败日志扔回去，代理通常能在第一次重试时修复。
三次严重拦截包括：合并锁的竞争条件、配置解析的空值检查缺失、以及一个因硬编码路径导致"本地通过CI挂"的测试。作者估算，任何一次漏进主干，调试成本都是小时级。
测试门在这里不是质量锦上添花，是系统能运转的前提条件。
这也解释了为什么很多AI编程工具演示看起来很炫，落地就翻车——Demo往往跳过"验证"环节，直接展示生成代码的快感。
零文件冲突的秘密：工作树隔离+串行合并
5个代理同时编辑同一代码库，作者用了两个机制避免混乱。
每个代理在独立的git工作树（worktree）和分支上工作。活跃开发阶段，文件层面的冲突是零——代理们可以无意识地在同一文件上并行修改。
冲突只出现在合并时刻。47个任务总共产生4次合并冲突，全部容易解决，因为合并被文件锁串行化了，同一时间只有一个分支在进主干。
这个设计牺牲了部分并行度，换取了可预测性。作者没有尝试真正的并行合并，那需要更复杂的冲突预测或自动解决机制，目前还不是这5个代理的能力范围。
上下文窗口：3次撞墙与拆解艺术
三次代理中途撞上上下文限制，模式高度一致：任务看起来简单，实际需要读大量文件才能理解全貌。
最惨的一次是"全量改用类型化错误"。代理开始读错误类型定义，顺着用到这些类型的模块继续读，再读调用这些模块的代码……等终于摸清范围，上下文窗口快满了，实际改动只能草草收场。
解法是把"全量"拆成"按模块"。给投递模块加类型化错误，一个窗口能装下；给全仓库加，装不下。
这个教训对用人的人来说更直接：别让AI做"理解整个系统再动手"的事，把大目标切成窗口能吞下的粒度。
换句话说，当前AI代理的"阅读理解能力"受限于窗口大小，而不是模型本身的推理深度。这是工程约束，不是智能问题。
4倍效率从哪来，又去哪了
120小时→30小时的压缩比，前提是作者作为监督者每天投入6小时。这6小时花在：审阅架构师的拆解、处理合并冲突、诊断测试失败、以及最重要的——识别代理的"完成幻觉"。
代理会说"完成了"，但完成的是编译通过，不是需求满足。作者需要像产品经理验收需求一样，逐个核对任务定义和实际输出。
这个模式目前适合什么？作者给出的画像很清晰：积压的需求清单、相对独立的模块改造、有完善测试覆盖的代码库。不适合的是：架构级重构、需要跨系统联调的功能、以及测试缺失的老代码。
一个细节值得玩味：作者提到代理在修复测试失败时"通常第一次重试就能解决"。这说明错误信息作为反馈信号足够明确时，AI的自我修正能力相当可靠。但反馈模糊时——比如"这个实现不够优雅"——代理就会陷入无效迭代。
如果监督成本能从每天6小时降到2小时，这套流程的边际收益会再上一个台阶。但那个临界点在哪，作者没有答案——这也是留给下一个实验者的问题。
热门跟贴