技术 · 深入
一个模型从头做到尾，越做越漏
拆解归主线，执行归并行
这是把一个大任务交给一个主智能体拆解、多个子代理并行执行、再由主线汇总判断的编排方法，解决「一个模型从头做到尾，越到后面越糊涂、越查不出问题」的漏检。做法分三步：主线只负责拆任务和收结论，子代理各自领一份能独立完成的子任务并行做，最后主线按验收标准逐条比对，对不上的回退到证据，最终判断不下放。
方法 · 一图看懂
1
拆 — 主智能体只做规划：把目标拆成能独立完成的子任务，每个子任务写清输入材料和验收标准。
2
派 — 一个子任务对应一个子代理，上下文只给该任务需要的文件与约束；单次执行最多并行协调 1,000 个子代理。
3
并 — 同一份文件只能有一个子代理在写，其余全部只读；写操作之间不重叠。
4
收 — 主线按验收标准逐条比对子任务产出，对不上的回退到原文与证据，不看子代理说得有多肯定。
5
判 — 结论由主线写：子代理的产出是材料不是定论，取舍与最终口径归主线。
档位差异：单代理从头做到尾 vs 动态工作流
初档的做法是让一个模型从读代码到写结论全包下来，任务一长就会出现「前面看得细、后面全靠猜」。深档换的是编排方式：主线不写正文，只做拆与收；子代理之间不共享工作区，也不看彼此的中间结果。Anthropic 的对照数据把差距摆在明面上——11.6 万行代码库里埋了 70 个 Bug，单智能体每次只检出 14 至 27 个，动态工作流稳定检出 66 个。差别不在模型更强，而在每个子代理只盯一小块，漏检的覆盖面被切开了。
边界：并行不是越多越好
并行数一上去，成本和冲突也一起上去。三条硬边界：①拆不动就别拆——目标本身没写清，拆出来的子任务会互相矛盾；②写操作必须串行——同一文件被多个子代理同时改，汇总时必然打架；③判断不下放——让子代理直接给结论，等于把取舍分散到几十个视角里，主线最后只能拼接不能收敛。1,000 是能力上限，不是推荐值；一次任务如果一份上下文就装得下，拆开只是徒增协调开销。
原理 · 为什么有效
为什么有效：一个模型从头做到尾时，处理是单线程的——越往后读，前面看过的细节越模糊，写结论时靠的是印象而不是证据。拆成并行子任务后，每块材料都在一个子代理的上下文里完整出现一次，漏检被摊到多个独立视角上；主线不复述细节，只按验收标准核对这些视角的产出，等于把「读得全」和「判得准」拆成两件事分别做。这也解释了单智能体检出 14 至 27 个、动态工作流能稳定检出 66 个的差距——不是更聪明，是没有人需要同时记住所有东西。
适用场景
适用：任务能切成几块互不依赖的部分，且每块有明确验收标准——大仓库查 Bug、多文档交叉核对、多路资料同时调研、批量文件各自改写。不适用：任务本身是一条链（后一步依赖前一步结果），或者目标还没定清就要动手；也不适合写操作密集的任务，同一份文件被多方并发修改时，汇总成本会超过并行省下的时间。
自测 · 5 问
我的子任务之间，是不是真的可以互不依赖地做完？
每个子任务有没有写清验收标准，还是只有一句「帮我看看」？
同一份文件，会不会同时有两个子代理在写？
子代理交回来的是材料还是结论，最终结论是不是主线自己写的？
汇总时我是按验收标准核对，还是按哪个子代理说得更有把握？
怎么上手 · 验证步骤
第一步，先把目标写成一句可验收的话，再往下拆成 3 至 5 个子任务，每个子任务单独写输入材料与验收标准。第二步，标出哪些子任务要写文件，把写同一份文件的合并成一个，其余设为只读。第三步，并行跑完，主线按验收标准逐条比对，对不上的一律回退原文，不采信子代理的自评。第四步，把这次拆法记下来，下次同类任务直接复用。
跑完回看两件事：如果主线汇总时还要重新读一遍全部原始材料，说明这次拆分没起作用；如果某个子任务的产出被主线整段丢弃，说明这个子任务的验收标准当初就没写清。