当协调者把任务分解得太窄时，整个领域会被遗漏。子代理只能在被分配的范围内工作——如果协调者把”创意产业”只定义为视觉艺术，音乐、写作和电影就永远不会被研究。覆盖缺口源于分解环节，不是执行环节。
分解瓶颈
子代理是执行引擎。它们在被分配的范围内搜索、分析和综合。它们不会质疑范围本身。如果协调者分配的是”分析数字艺术、平面设计和摄影”，子代理就精确地做这些——最终报告只覆盖了视觉艺术。
这使得协调者的分解成为覆盖率的单点故障。一个范围不当的分解会产出一份对错误子集的深入分析。
窄分解的症状
- 最终输出只覆盖了一个多面主题的某个方面
- 用户反馈”广但浅”——系统在覆盖到的内容上很深入，但遗漏了整个领域
- 子代理成功完成了（它们的工作是正确的），但整体结果不完整
关键诊断：如果子代理在分配的任务上都成功了，但最终输出缺少主题，问题就在分解，不在执行。
上下文溢出怎么导致信息丢失
即使分解正确，规模上也可能失败。协调者正确识别了 15 篇研究论文，全部 15 篇都被分析了，但当协调者把 15 份分析传给综合子代理时，只有 8 份能装进子代理的上下文窗口。七份分析被悄悄丢弃了。
协调者有责任管理 agent 之间的信息流，包括确保数据适合每个 agent 的约束。结果太大时，协调者应该先摘要、分块或提取关键发现再传递。
迭代检查
协调者应该在第一轮后评估分解的完整性：
- 子任务是否覆盖了原始请求的所有方面？
- 是否有被遗漏的领域、视角或角度？
- 如果有缺口，委派针对性的后续任务——不要从头重来。
这个评估-迭代循环在结果到达用户之前捕获窄分解。协调者评估覆盖率，识别缺口，逐步填补。
一句话总结： 子代理只做被分配的事——协调者层面的窄分解才是覆盖缺失的根因，不是子代理执行失败。评估分解完整性并迭代。