在实际的大模型工程落地中，多智能体系统的核心挑战不是让一个Agent变得更聪明，而是让多个Agent高效协作且保持系统可控。当任务规模从单次对话扩展到需要并行处理数十个子任务的场景时，放任自由调度的系统几乎必然陷入上下文溢出、任务冲突或Token消耗失控的困境。这篇文章拆解一套经过工程验证的多智能体架构设计方案，覆盖从任务分解、Subagent派生、状态管理到并发控制的关键环节。
动态大纲与任务调度
主Agent接到一个复杂任务后的第一步，不是立即动手执行，而是生成一个动态大纲（Dynamic Outline）。这个大纲是系统级的任务追踪表，实时记录每个子任务的当前状态。假设任务是调研75家科技公司的技术路线演进，大纲会将任务拆解为75个子项，并实时标记每项的进度：哪些已完成、哪些正在执行、哪些尚未分配。主Agent在分发新任务前，先读取大纲的当前状态，确认哪些任务还未被领取，再决定派发给谁。大纲是系统的全局唯一真相源，谁领了什么任务、完成进度如何，一目了然。
当大纲中存在待分发的子任务时，主Agent通过 delegate_task 工具派生出多个独立的Subagent。每个Subagent领取各自的子任务后并行执行，互不干扰。以调研任务为例，主Agent一次可以调用四次 delegate_task，分别派生出负责苹果、谷歌、微软、亚马逊的四个Subagent，它们同时开始爬取资料和分析工作。主Agent的角色类似交响乐指挥，不亲自演奏任何乐器，只负责监督各声部的进度和纠正偏差。角色定义清晰、边界划分严格，是这套调度机制能够有效运转的前提。
信息收敛机制
Subagent完成工作后返回结果时，有一个关键约束必须遵守：不能把收集到的原始内容直接传回主Agent。原因在于，如果每个Subagent把爬取的数万字网页原文全量传回，主Agent的上下文窗口会被迅速占满，推理质量急剧下降。Token消耗也会雪崩式上涨，直接推高系统运行成本。
解决方案是在Subagent的执行流程中加入强制压缩环节。Subagent的工作流程分为四步：爬取原始数据、分析提取关键信息、自我压缩提炼结论、返回精炼简报。最后一步是核心，Subagent必须在返回前将原始内容压缩为高密度的结论摘要，过滤掉冗余信息和噪音。这样主Agent接收到的始终是经过提炼的简报，上下文空间得以保留，推理能力不会被海量原始数据稀释。信息流的方向是从发散到收敛，每个子节点承担压缩责任，是防止系统陷入混乱的基础设计。
扁平化架构与并发限流
另一个需要防范的风险是Subagent的无限繁殖。当一个Subagent遇到难以处理的子任务时，如果允许它自己派生新的Subagent，就会形成递归派生链。子又生孙、孙又生子，Token消耗呈指数级增长，系统很快陷入死循环。
架构中设置了两个硬性约束来防止这种情况。第一个是辈分隔离：只有主Agent拥有 delegate_task 的调用权限，普通Subagent被禁止再派生新的Subagent，整个架构保持严格的扁平结构，从代码层面杜绝递归派生的可能。第二个是物理限流：在代码中设置并发上限，比如最多允许20个Subagent同时运行，超出则排队等待。这两个约束本质上是同一个思路，用工程的确定性来限制模型行为的不确定性。模型会随机犯错，但工程约束不会因为模型的随机性而失效。
状态冲突与中心化调度
当Subagent数量达到一定规模，任务冲突和状态覆盖的问题就难以避免。两个Subagent可能被分配到重叠的任务范围造成重复劳动，或者一个Subagent的输出覆盖了另一个的中间结果。动态大纲在这里充当了冲突仲裁中心的角色。
主Agent在分发任务时，基于大纲的当前状态做严格的边界划分。代码逻辑上，每个待分配任务在分发前都会检查是否已被其他Subagent领取，或是否已经完成，确保不会重复分发。主Agent在分发前就消除了任务重叠的可能性。大纲因此成为系统的全局唯一真相源，每个Subagent只知道自己的任务边界，主Agent通过大纲维护全局的状态一致性，所有Subagent各走各的路、互不干扰。
非确定性系统的评估
这类动态系统每次执行的调用序列都可能不同，传统的单元测试方法基本失效。无法精确断言系统在第几步调用了哪个工具，因为下一次运行路径可能完全不同。目前业界比较成熟的评估方案是 LLM-as-a-Judge，即让更强大的模型充当裁判，对主Agent产出的最终报告进行结构化打分。裁判模型从信息完整性、逻辑连贯性、事实准确性等维度给出评判。通过规模化的自动评测，每次系统调整后，团队可以量化地判断输出质量是否真正提升，而不是在不同的随机路径之间盲目切换。