多 Agent 协作与递归任务拆解的工程模式

当一个工程目标超出单个 Agent 的上下文容量与处理能力时，我们需要一种把「一个大问题」降解为「一组可交付小问题」的协作方式。多 Agent 协作与递归任务拆解的工程模式就是这样一套组织方法：上层执行者理解整体目标并完成分解，下层执行者在明确边界内完成局部实现与测试；当某个子任务依然过于复杂时，就继续向下递归拆解，直到每个工作单元都可执行、可验证。

三层结构：理解、递归与局部闭环

• 上层执行者：面向整体目标，回答「要做什么」，输出可委派的子任务、约束条件与验收标准。
• 中层执行者：承接仍然过大的子任务，继续递归拆解，把松散的大目标收敛为稳定的任务层级。
• 下层执行者：在职责边界内完成局部实现与测试，产出可验证结果并向上交付，形成局部闭环。

为什么必须递归拆解

Agent 的上下文窗口、可调用工具与单次可处理的任务规模都是有限的。如果让单个 Agent 长期持有整个项目的全部上下文，不仅成本随规模上升，还容易出现目标漂移、状态污染与关键信息被稀释。递归拆解把这部分压力分散到各层：每个 Agent 只需理解自己那一层的目标与约束，复杂目标被逐层降解为可执行、可交付的工作单元，而整体一致性由任务层级来保证。

关键机制：任务树与交接关系

父任务与子任务构成一棵递归任务树。向下流动的是任务委派——目标、边界约束与验收标准；向上流动的是结果回收——产出物、验证证据与尚未解决的问题。协作能否真正成立，取决于三件事：任务层级是否清晰、职责边界是否互斥、交接产物（接口定义、数据集、测试用例、检查点）是否被明确约定。缺少其中任何一项，多个 Agent 就会退化为重复劳动与相互冲突的结果。

与「方法演化」的呼应

递归拆解的对象不仅是任务本身：拆解的深度、委派的粒度以及结果回收的策略，同样可以被持续评估与调整。当任务反馈（如某个子任务反复返工）反过来影响下一次如何拆解时，这套协作流程本身就进入了自我改进的循环，与把「产生候选的方法」纳入优化对象的思路一脉相承。