多智能体编排不翻车：Manager-Worker角色分工与任务拆解实战

最近在给客户的智能体落地方案做架构时又被问到同一个问题多智能体编排到底怎么才能不翻车问出这句话的人多半看过那种脚本味道很浓的 Agent 协作演示以为把一群 Agent 扔在同一个对话里任务就能自动完成。实际上我在生产环境里跑下来的感觉恰恰相反多智能体编排的核心从来不是数量堆叠而是分工清晰。在所有分工模式里最稳定、最好上手、也最值得先掌握的就是 Manager-Worker 角色分工。这篇文章我会从角色设计的角度完整拆一遍 Manager-Worker 模式包括 Manager 和 Worker 的职责边界、任务拆解与上下文传递、结果校验与失败重试以及工具选型建议。无论你用的是 LangGraph、CrewAI还是自己用 LLM API 搭这套思路都能直接落地。1. 从单智能体到多智能体Manager-Worker 模式为什么会出现1.1 单智能体的天花板先别急着上多智能体。一个 Agent 真能搞定所有事时单智能体是最省心的方案。但任务一旦变复杂单智能体会露出三个天花板。第一个是上下文膨胀。让一个 Agent 做“写行业研究报告”这件事它既要读取大量参考数据又要记住用户最开始给出的格式要求中途还要不断生成中间结论。上下文窗口里塞得越多模型就越容易“忘了前面的重点”尤其是长任务跑到后半段经常出现早期约束被无视的情况。第二个是角色混同。同一个 Agent 既要做数据收集又要做逻辑分析还要负责文字润色这三个动作对 prompt 风格和推理方式的要求差异很大。混在一起很容易产出一种“数据不严谨、分析不深入、措辞又很华丽”的四不像内容。第三个是错误难定位。单智能体链路里一旦结果不对你很难判断是检索错了、推理错了还是生成阶段出了问题排查成本极高。我见过很多团队在最开始把单智能体 prompt 写得很长试图让它在一个上下文里完成所有事结果效果和稳定性都不可控。后来大家慢慢意识到与其让一个 Agent 全能不如把任务拆给多个 Agent各管一段。多智能体编排就是这么被逼出来的。1.2 Manager-Worker 模式的核心逻辑Manager-Worker 也叫 Supervisor-Worker、Orchestrator-Worker是一种非常经典的双层协作结构。它的整体形态很简单一个中心节点叫 Manager负责接收用户目标、拆解任务、分发任务、回收结果、最终汇总多个执行节点叫 Worker每一个只负责完成被分配的子任务然后把结果交回 Manager。用图论的话说这是一种星型拓扑结构。所有信息都流经 Manager 这个中心节点Worker 之间不直接通信。这样设计有几个直接好处第一信息流可控不会出现多个 Agent 你一句我一句、最后聊偏题的情况第二角色边界清晰Manager 管全局Worker 管局部第三问题可追溯哪个环节出问题直接看对应 Worker 的输入输出就能定位。这里要说清楚一个容易产生的误区Manager-Worker 不是“一个聪明的老板指挥一群傻子干活”而更像一个成熟的项目经理带着若干领域专家。Manager 的厉害之处不是自己什么都会而是能准确判断什么任务该交给谁、做完的东西是否达标。Worker 的厉害之处则是在自己的专业范围内做到又快又准而不是越权去管全局。1.3 它能解决什么问题、解决不了什么问题先从能解决的说起。最重要的一个收益是降低单 Agent 的负载。每个 Worker 只需要关注被分配给自己的子任务prompt 可以写得很聚焦上下文窗口也能按需控制这直接缓解了上下文膨胀问题。其次是支持并行执行。只要任务之间没有依赖关系多个 Worker 可以同时开工整体耗时能从“串行加总”变成“最长链路”。再次是职责明确便于调试和优化。比如报告生成项目中如果发现最后的报告风格不符合要求你只需要调整负责写作的 Worker而不需要动数据收集和竞品分析的部分。但 Manager-Worker 不是银弹它解决不了一些问题。如果任务本身强耦合、不可拆分强行编排只会增加通信开销和出错点。比如让多智能体去写一段本来 200 字就能说清楚的通知文案纯属杀鸡用牛刀。另外如果 Manager 自身的拆解和校验能力不行整个系统会比单智能体更容易失败。因为单智能体至少还有一个完整上下文兜底而 Manager-Worker 一旦把任务分错Worker 再努力也只能在错误方向上越跑越远。还有一点这个模式并不擅长开放式头脑风暴。Agent 之间的网状对话能产生一些非预期的“涌现”效果但 Manager-Worker 的结构天然限制了这种自由交互更适合目标明确、步骤相对稳定的任务。所以我的判断很直接如果你的任务有清晰的结构、可拆分的步骤、需要确定性高的产出Manager-Worker 是性价比极高的选择如果你的任务本身连目标都模糊指望 Agent 群自由讨论出奇迹那不如先把任务定义清楚再说。2. 角色分工的核心设计Manager 和 Worker 各自该干什么2.1 Manager 的职责边界很多人设计 Manager 的时候第一反应是让它做“最聪明的那个 Agent”什么都要懂一点甚至亲自下场写一版内容。这是一个非常危险的倾向。Manager 一旦动手做具体任务它就会从“全局调度者”退化成“普通执行者”紧接着就是失去对整体节奏的把控。真正高效的 Manager 应该把自己定位成项目经理而不是万能选手。具体来说Manager 的核心职责有四块。第一块是目标理解与任务拆解。它要把用户那句“帮我做一份新能源汽车市场分析报告”拆成一串可执行的子任务并定义每个子任务的输入、输出和完成标准。第二块是任务调度与分发。根据子任务之间的依赖关系决定哪些并行、哪些串行然后分发给合适的 Worker。第三块是结果回收与质量校验。每个 Worker 返回结果后Manager 要先做基础校验再决定是进入下一个任务还是打回重试。第四块是最终整合。所有子任务完成后Manager 需要把碎片化的结果组织成一份完整交付物。还有一条隐性职责很容易被忽略全局上下文维护。Manager 需要对整个任务进度、已经拿到的中间结果、用户原始偏好保持清晰认识并且能在合适的时机把需要的信息传给 Worker。我通常会在 Manager 的系统 prompt 里明确要求它维护一个“任务进度摘要”每完成一个任务就更新一次摘要避免它自己也越跑越迷糊。2.2 Worker 的职责边界Worker 的设计逻辑刚好和 Manager 相反它不是越全越好而是越专越好。理想的 Worker 应该是一个“单任务专家”它的 prompt 里只需要四样东西身份定位、手头任务、输入数据、输出格式。身份定位解决“你是谁”的问题。比如“你是一名严谨的数据分析师擅长从原始数据中提取趋势”。手头任务说明“你现在要做什么”大多数情况下这条就是 Manager 动态传入的任务指令。输入数据则是当前任务真正需要的最小上下文而不是把整个项目历史都扔给它。输出格式要尽量结构化比如用 JSON 返回结果字段这样 Manager 才能解析和校验。另外非常重要的一点Worker 不要自作主张。它的职责是“执行并返回”而不是“决定下一步做什么”。我经常在 Worker 的 prompt 里写一句约束“你只需要完成当前任务并返回结果不要提出新任务不要尝试修改目标。”别小看这句话很多 Agent 系统失控就是因为 Worker 干着干着开始给自己派活最后把整个编排节奏带偏了。Worker 的返回结果也应该标准化。我在实践中常用的返回结构是这样{ task_id: task_001, status: success, output: 这里是具体结果, confidence: 0.93, notes: 补充说明、数据来源或需要 Manager 注意的点 }状态字段我一般只允许三种值success、failed、retry。confidence 是 Worker 自己对该结果的置信度打分可以帮助 Manager 判断是否要做额外校验。notes 用来传递文本不好表达的信息。这套结构看起来简单但它让 Manager 的后续处理逻辑变得非常干净。2.3 角色明确的边界比能力更重要做多智能体编排这些年我的一个核心体会是系统失败很少是因为模型能力不够更多是因为角色边界含糊。Agent 和 Agent 之间一旦职责重叠就会出现“三个和尚没水喝”的局面。举个例子。在一个内容生成系统里如果 Manager 自己也喜欢写具体段落而写作 Worker 又经常对任务目标提出修改意见两者就会互相拉扯。结果 Manager 觉得自己已经把方向定得很细Worker 却认为 Manager 在越权干预产出既慢又乱。反过来如果 Manager 只做任务拆解和校验Worker 只做执行系统就会像一个运转良好的流水线每个环节的人都明确知道自己的产出应该交给谁。为了让边界更清晰我建议在角色 prompt 里同时写清楚“你不要做什么”。比如 Manager 的 prompt 里写“不要直接生成最终报告内容你负责组织和校验”Worker 的 prompt 里写“不要修改任务目标不要规划下一个任务你只需要完成当前指令”。这些否定约束比正面描述更能防止越界行为。2.4 角色定义中的几个关键参数除了职责描述角色设计还需要落到几个可配置的参数上不然就是空谈。第一个是上下文窗口分配。Manager 的上下文要足够容纳全局状态、任务列表和所有 Worker 的结果摘要所以通常分配较大的窗口Worker 只需要容纳当前任务相关数据窗口可以小一些这也直接影响了 token 成本和并发时的速率限制。第二个是最大重试次数。我一般给每个 Worker 默认 2 次重试机会超过就视为失败改派其他 Worker 或进入降级逻辑。第三个是并发上限。这个要结合你实际使用的模型 API 速率限额来定不能只看任务并行数否则很容易触发限流报错。第四个是输入输出格式约定。任务指令、返回结果都要有明确的 schema最好直接用 JSON Schema 定义让 Manager 在做任务分配时按模板填充Worker 返回时也能被稳定解析。这几个参数看起来琐碎但在真正跑多智能体生产环境时它们决定了系统是“偶尔成功”还是“稳定可用”。3. 实操拆解构建一个高效的 Manager-Worker 编排流程3.1 任务分解策略Manager 拿到一个目标后第一步工作就是把目标拆成一张任务图。我习惯用 DAG有向无环图来表示每个节点是一个子任务每条边表示依赖关系。只有依赖关系清晰的 DAG 才能支撑后面稳定的调度逻辑。任务拆解有一个关键问题粒度怎么定。拆得太粗Worker 实际执行时内部还是要走一个很长的单 Agent 链路等于换汤不换药拆得太细又会出现大量微任务Manager 光调度就忙不过来上下文里也会塞满各种任务状态。我的经验是一个子任务的规模应该控制在“让 Worker 一次调用就能返回可靠结果”的程度。如果预估 Worker 为了完成任务需要内部规划超过三到五个步骤就说明这个子任务还可以继续拆分。举一个我常用来做演示的例子。假设目标是“生成一份新能源汽车市场分析报告”我会让 Manager 先拆成四个任务任务A收集近一年全球新能源汽车销量数据输出结构化数据表。任务B收集头部厂商最新动态与产品节奏输出要点摘要。任务C基于 A 和 B 的结果分析市场规模与竞争格局输出分析结论。任务D基于 A、B、C 的结果撰写最终报告输出 Markdown 格式文档。这里 A 和 B 没有依赖关系可以并行C 依赖 A 和 B必须等它们完成D 依赖 C。Manager 在初期就要识别出这种依赖结构才能决定调度顺序。任务拆解的结果建议以结构化形式保存例如{ tasks: [ {id: A, depends_on: [], worker_type: data_collector, status: pending}, {id: B, depends_on: [], worker_type: data_collector, status: pending}, {id: C, depends_on: [A, B], worker_type: analyst, status: pending} ] }这样 Manager 的循环逻辑就可以根据每个任务的 status 和 depends_on 字段做调度而不是靠模型“临场发挥”。3.2 通信协议与上下文传递Manager 和 Worker 之间的通信不能靠自然语言“随便聊聊”必须有一个相对固定的任务指令模板。我在实践中用这样的模板你是 {worker_role}。 请完成以下任务 任务ID{task_id} 任务目标{goal} 输入数据{input_data} 约束条件{constraints} 输出要求{output_format} 请直接返回结构化结果不要额外提问。这里的 input_data 是 Manager 从全局上下文里提取出的最小必要信息。很多系统跑崩就是因为 Manager 把整个对话历史、所有中间产物一股脑全塞给 Worker时间一长 token 消耗巨大模型注意力也被无关信息稀释。记住一个原则Worker 不需要知道它当前任务之外的信息你要做的是“按需投喂”。Worker 返回给 Manager 的结果也应该遵循固定 schema。我前面已经给过 JSON 结构这里再补充一点如果任务失败Worker 返回的 notes 字段里必须包含失败原因和执行到哪一步的说明。这个信息是 Manager 决定“直接重试、换个 Worker、还是降级处理”的依据。没有结构化返回Manager 就只能靠肉眼读文本做判断系统的确定性就无从谈起。3.3 并行与串行的取舍并行是为效率服务的但它会引入新的复杂度。多个 Worker 同时执行时Manager 同时要接收多份结果不仅需要合理的合并策略还要防止多个结果之间出现冲突。所以我在设计调度逻辑时遵循一个简单原则没有依赖关系的任务才并行有依赖关系的严格按拓扑序执行需要共享全局上下文的关键节点尽量串行。举个反面例子。我早期做多智能体内容生成系统时为了让流程更快把“数据收集”和“报告的读者画像分析”两个任务并发执行。结果数据收集的 Worker 返回的报告受众偏向 C 端消费者而读者画像分析 Worker 默认的是 B 端采购决策者两边对同一个项目的背景假设完全对不上。后续 Manager 为了统一这两个结论花了大量 token 做 conflict resolution效率反而更差。后来我把所有“会影响后续多个任务的关键决策”改为串行执行至少保证全局信息的一致性。并行还有另一个现实约束API 速率限制。如果你设置了 8 个 Worker 并行调用同一个模型接口而该接口限制每分钟 60 次请求8 个任务一次并发就可能占掉很大配额。当任务需要重试时很容易集体触发 429 限流报错。所以并发数不是越大越好要结合你的模型速率限额和任务特点动态调整。我通常用信号量限制全局并发数比如单批最多 4 个 Worker既保证速度又留足重试空间。3.4 结果回收与质量校验Worker 把结果交回 Manager 后最忌讳的就是 Manager 直接拿来拼装。这里必须有一个质量校验环节我一般分三层来做。第一层是格式校验。检查返回结果是不是合法 JSON必填字段是否存在confidence 是否在有效范围内。这一层是程序化检查完全不需要模型参与成本几乎为零。第二层是内容校验。检查 Worker 是否真的回答了任务目标输出里有没有明显的自相矛盾或跑题内容。这一层需要 Manager 用模型能力做判断可以把任务指令、Worker 返回结果、约束条件一起发给 Manager 的校验子流程让它返回“pass / fail / need_revision”三选一并附上修正意见。第三层是一致性校验。当多个并行任务返回后Manager 要快速检查它们之间有没有结论冲突。比如任务 A 说市场规模年增速 8%任务 B 根据另一份数据说增速只有 3%这种冲突必须在汇总前解决。如果校验不通过Manager 会把修正意见作为 feedback 发回 Worker让它重试。这里我要强调一个细节重试 prompt 里必须写清楚“哪里不对、为什么不对、希望你怎么改”而不是简单说“你做得不对请重做”。比如“你引用的销量数据是 2022 年的请改用 2024 年数据后重新输出分析。”这种具体反馈能让 Worker 快速定位问题。同时重试要有次数上限否则遇到一个固执的 Worker系统会陷入无限循环。我见过不少团队在设计时跳过质量校验以为“模型自己能判断好坏”。实际上如果不做校验多智能体系统很容易出现一个现象每一步单看都挺正常但最终拼出来的结果却处处是坑。这个坑往往要到交付时才被发现返工成本高得惊人。4. 常见问题与排查技巧实录4.1 任务分不好Manager 变成“传话筒”有一种项目里非常常见的失败模式Manager 把任务拆完后每个 Worker 的任务描述里还是写着“完成整份报告”只是语气不同。等于 Manager 什么都没拆只做了个传话筒Worker 还是在一个巨大的上下文里单打独斗多智能体就失去了意义。出现这个问题的根因通常是 Manager 的 prompt 里没有强调“拆解到可执行粒度”或者拆分后没有显式定义每个子任务的输出物。我的解决办法是给 Manager 配置一个“任务拆解校验器”在它拆完任务后先自检每个子任务是否满足“一次调用可完成、输出形式明确、依赖关系清晰”这三个条件不满足就重新拆。刚开始会慢一点但能避免后面整个链路跑偏。还有一个判断标准很实用如果某个子任务的描述里出现了“分析并总结并输出建议并撰写报告”这种连词堆积说明拆解粒度太粗必须继续拆。4.2 上下文爆炸token 飙得太快跑多智能体系统的人几乎都会遇到 token 成本超预期的问题。我这边的经验是上下文爆炸通常来自两个地方一个是 Manager 把历史对话完整保留一个是 Worker 的输入里塞入了大段原始文档。针对第一个问题我建议 Manager 不要维护“完整对话历史”而是维护“任务进度摘要”。每完成一个任务Manager 就把对这个任务最关键的结论提取出来写进摘要旧对话可以裁剪或归档。针对第二个问题要给 Worker 的输入长度设置硬性上限例如单个任务输入不超过 3000 字超过需要先做摘要提取再传入。这样能有效防止“一次数据抓取任务把 5 万字资料全塞给模型”的情况。我见过一个比较极端的案例一次市场调研任务单个 Worker 的 prompt 里塞了 4 万多字的原始访谈记录结果 token 成本直接让客户预算超支而且模型处理长上下文时对关键信息的抓取反而更差。后来我改成先让一个文本处理 Worker 提炼出 20 条关键信息再传给分析 Worker成本降了一大半结果质量还提升了。4.3 智能体陷入死循环多智能体系统里最让人头疼的就是死循环。常见场景是Manager 让 Worker 重试Worker 每次都返回“已经修复”但 Manager 校验时发现问题根本没变于是再次重试如此往复直到 token 烧完。这个问题要从两端来解决。一端是限制重试次数。我在每个任务里都带一个 retry_count 参数Manager 在分发任务时会读取超过最大次数就触发备用策略。另一端是要求 Worker 在返回结果时提供“变更说明”也就是说明它这次相对上次到底改了什么。比如“根据反馈我将数据源从 2022 年更新到 2024 年并重新计算了同比增速。”如果 Worker 的变更说明为空Manager 可以直接判定这次重试无效。还有一个更隐蔽的循环来源Manager 自己也会陷入“试图纠正反馈循环”。当多个 Worker 结果冲突时Manager 反复让它们协商结果越讨论越乱。我通常会给冲突消解设定次数限制比如最多两轮仍无法达成一致就直接由 Manager 仲裁或采纳置信度更高的结果。4.4 结果合并时的冲突与矛盾并行 Worker 返回结果后冲突几乎是必然的尤其当不同 Worker 使用的数据源不同、或对同一概念的理解存在偏差时。很多团队忽略了这个环节直接把所有结果拼进报告最后读者看到前后数字都对不上。我建议 Manager 在做最终汇总前增加一个“交叉检查”步骤。做法是把所有并行任务的关键结论提取出来发给一个专门的校验 Worker检查是否存在明显矛盾。如果发现矛盾把相关结论一起发给对应的 Worker 做二次确认并让它们标明置信度和数据来源。最后 Manager 根据置信度和来源可靠性做仲裁。这里有一个经验不要试图让所有 Worker 都达成一致意见那会耗费大量时间。只要在最关键的、用户能直接感知到的数据点上保持一致就够了。一些边缘性的细节矛盾可以通过报告里的措辞来规避比如用“不同口径下增速介于3%到8%之间”这类表达。4.5 故障恢复与可观测性多智能体系统本质上是一个分布式系统你不能只把它当作“模型调用串起来”那么简单。任何一个环节的模型输出格式变化、网络超时、API 限流、上下文超长都可能让整个任务失败。因此可观测性是硬需求。我一般在每次 Manager 和 Worker 调用时都会记录这些信息任务ID、调用时间、模型名称、输入摘要、输出摘要、token 用量、耗时、重试次数、状态。日志格式最好是 JSON 行方便后续接入日志系统。任务失败时要能根据 trace ID 一键回放整个执行链路看是卡在哪个环节。有过一次教训一次客户线上任务的 Manager 因为一个字段解析失败重复触发重试导致当天 token 费用暴涨。如果没有那套日志我根本定位不到问题。后来我给所有外部调用都加了超时和熔断机制单次调用超过 30 秒就主动断开并触发重试而不是傻等。4.6 我踩过的坑和几个避坑心得这里分享几条直接派得上用场的教训。第一条不要把所有 Worker 放进同一个系统 prompt。我早期图省事给所有 Worker 共用一套底稿只在任务指令部分做替换。结果发现 Worker 之间出现了“串角色”现象一个数据分析 Worker 偶尔会开始写营销文案。后来我把每个角色的系统 prompt 完全独立杜绝了上下文污染。第二条先串行打通链路再做并行优化。如果你第一次上多智能体系统千万别一上来就搞复杂的并发拓扑。先把所有任务串行走一遍确认每个环节的输入输出稳定然后才把没有依赖关系的任务改成并行。这个顺序能省下大量排查问题的时间。第三条Manager 的 prompt 要比 Worker 更“啰嗦”。Worker 的 prompt 追求精简但 Manager 需要非常完整地定义它的职责、调度原则、校验标准和输出格式。因为它才是整个系统的大脑一旦它对自己的工作范围理解得不清楚下面所有 Worker 都会跟着乱。第四条每次改动只动一个变量。多智能体系统的参数和 prompt 非常多最容易出现的失误是同时改了 Manager 的调度逻辑、Worker 的 prompt 和任务的拆分方式结果效果变好了却不知道是哪个改动起了作用效果变差了更不知道从哪里排查。坚持一次只改一个变量才能让系统持续累积可复现的优化经验。5. 工具选型不同框架下的 Manager-Worker 实现对比5.1 主流多智能体框架横向对比如果你不想从零手写一套调度逻辑市面上已经有不少支持 Manager-Worker 模式的多智能体框架。我简单梳理几个我用过的。CrewAI 是我做快速原型时最喜欢用的框架之一。它对 Agent 的定义非常贴近 Manager-Worker 思路每个 Agent 都有 role、goal、backstory 三个核心属性而且可以直接把某个 Agent 设置为 Manager让框架自动分配任务、协调其他 Worker。优点是上手快、配置简单适合验证业务流程缺点是对复杂依赖和自定义状态管理的控制力偏弱任务一多容易感觉“框架替你做了决定但你不一定能修改它的决定”。AutoGen 走的是对话式多 Agent 路线更强调 Agent 之间自由对话。它里面有一个 GroupChat 机制可以设置一个 admin 来管理对话这个 admin 就扮演类似 Manager 的角色。优点是灵活Agent 之间的交互可以非常复杂缺点是越灵活越难控制你需要花不少精力去约束对话走向否则很容易跑偏。LangGraph 是我目前在正式项目里用得最多的框架。它的核心是显式图结构任务节点和边的定义非常明确天然适合实现我前面讲的 DAG 式任务拆解。它支持条件分支、状态持久化和细粒度的人类介入因此适合做生产级的 Manager-Worker 编排。缺点是学习曲线相对陡峭需要你对图结构、状态管理有清晰认识否则容易写出比手写还复杂的代码。Claude Agent SDK 这类相对较新的工具则提供了 sub-agents 机制更接近原生的 Manager-Worker 模式。它的优势是代码结构简单几乎不需要额外概念就能定义一个主 Agent 调用若干子 Agent 完成子任务适合团队里 LLM 经验还不太足、想先跑通最小闭环的场景。5.2 我的选型建议选框架没有一个绝对的“最好”要根据你的团队和场景来判断。如果只是想快速验证一个多智能体业务想法我会建议直接用 CrewAI半天就能把 Manager-Worker 原型跑起来。如果系统要进生产而且你需要对任务流程有很强控制力LangGraph 会更合适虽然前期成本高一些但后期的可维护性会好很多。如果你希望 Agent 之间有更强的自由对话和协商能力AutoGen 值得考虑但你要做好约束和控制。如果团队已经有 Claude API 的使用经验直接试一下 sub-agents 模式可能最省事。还有一点经验不要同时引入多个框架。我见过团队一开始用 CrewAI 做原型后来切到 LangGraph后来又觉得 AutoGen 有个功能不错想把它接进来。结果项目有一大半时间花在了框架适配和数据格式转换上真正业务逻辑反而没怎么推进。选定一个主力框架其他的可以作为旁路实验但不要混在同一个生产项目里。无论选哪个框架我前面讲的角色边界、任务拆解、上下文传递、结果校验这些设计原则都是通用的。框架只是帮你把“Manager 分发任务、Worker 返回结果”这个循环变得更简单它不能替你做角色设计。真正决定系统上限的永远是你怎么看清楚任务结构、怎么把合适的任务交给合适的角色、怎么让每一步的结果经得起校验。我在实际项目里最大的体会是Manager-Worker 模式从来不是模型能力的竞赛而是工程化能力的竞赛。先想清楚任务怎么拆、上下文怎么传、结果怎么验再考虑引入多少 Worker、用多复杂的并行拓扑。多智能体编排的复杂度是线性增长的只要每一步都稳得住系统就能撑得住更复杂的业务而一旦中间某一步开始“凭感觉”后面整个链路都会为这个“感觉”买单。