大多数代理编码模式在第一个模块上都跑得挺顺。挑一个工作流——技能框架、多工作树设置、一套编排运行器——一个下午就能把东西推出来。难的不是这个。真正的问题要过几个月才会浮出来：代码库膨胀了，任务也不再规整，那时候这套模式还能不能撑住？对绝大多数模式来说，答案是否定的。

这倒不是在低看工具本身，而是问题属性使然。孤零零地实现一个功能，跟跨几十个并行会话维护一整套系统，根本是两种活动。在第一步赢得很漂亮的模式，不会自动在第二步同样奏效。

这里的“扩展”，具体指的是项目成熟后通常一并出现的四件事。

首当其冲的是代码库的增长。代码库有历史、有日积月累的约定，还有其他代理要调用的活跃接口。在上面工作的代理不能只知道今天要写什么，还得清楚已经存在什么、以前做过哪些决定。

其次是任务复杂度的跃升。一个牵涉三个组件、需要做架构决策的任务，跟改一个文件的任务完全不是一回事。对简单场景有效的模式，遇到复杂情况经常就开始吃力了。

再者是代理数量。从两个并行代理涨到八个，不光是产出变了，协调面也变了。一个会话里拍板的决定，得让其他会话感知到；冲突必须在合并入主线之前就暴露出来。

最后是持续时间。六小时的冲刺跟跑上几周的项目截然不同。过往决策的记忆、之前踩过的Bug的形态、那些不那么显而易见的选择背后的判断依据，都得在单个会话结束之后继续存在。

最常见的模式之一是单代理监督。开一个 Cl​​aude Code 会话，你盯着一行一行，每一步都批准或纠正。这是多数人的起点，对边界明确的任务——加一条新路由、重构一个函数、写一个独立脚本——这完全是正确的选择。你始终在环路中，一致性很容易维持。它的天花板就是你的注意力。吞吐量只有一个代理，而代理的上下文窗口就是唯一的共享记忆。在AI编码采纳阶梯的第一步，这个模式运转良好。一旦你想拥有一条以上的工作流，它就不够用了。

另一种常见做法是人工简报驱动的并行代理。你拉起多个工作树，开始前给每个代理做一份简报。这是迈向并行最自然的第一步，任务分解得够清楚的话，几个代理往往也能配合得不错。但管理开销是线性的。每多一个代理就多一份简报，而每一份简报都要携带其他方式就会丢失的共享上下文——代码约定、当天早些时候敲定的决策、其他代理已经认可的接口。两个代理时还凑合。五个时，你自己就成了集成层：每一个决定都要经过你的工作记忆来流转，而人的工作记忆是没法这样扩展的。这种动态，此前有过更详细的讨论。