AI Agent与Subagent协作：从任务拆解到稳定编排的实战指南

做 AI Agent 和 Subagent 协作这件事我是踩过不少坑才摸到一点门道的。一开始我也是“单 Agent 万能论”的信徒把规划、调用工具、写代码、检查结果全塞给一个 Agent结果任务稍微复杂一点就开始失控上下文越滚越长模型越答越偏最后输出一坨看似完整、实则完全不相关的东西。后来我把任务拆出去引入 Subagent以为万事大吉结果又踩出一片新坑子任务返回格式不稳定、父 Agent 反复重派同一个活、并行任务互相污染……这篇内容就是把我在这过程中踩过的坑和最终梳理出来的正确协作姿势做个总结特别适合正在搭 Agent 系统的开发者以及想理清 Agent 架构逻辑的产品同学。这篇文章不会给你一套银弹框架因为 Agent 本身的智力上限取决于底层模型编排层能做的只是把问题切成小块让模型在每小块上保持专注。我会从三个层面展开为什么必须拆、拆完怎么协作、协作过程中最常见的问题怎么排查。里面会穿插一些真实的踩坑例子和一份可以直接复用的 Prompt 模板希望能帮你少走一些弯路。1. 为什么必须把任务拆给 Subagent很多刚接触 Agent 的人都有一个直觉既然模型这么强为什么不能让它一口气把所有事干完我一开始也是这么想的直到在一次实际任务里翻车才明白单 Agent 不是“能不能干”的问题而是“干着干着就偏了”的问题。1.1 单 Agent 的三重天花板第一重天花板是上下文窗口的物理限制。主流的模型虽然都宣称支持很长的上下文但长上下文不等于高质量理解。当一段对话历史超过某个量级之后模型会对夹在中间的信息“视而不见”尤其容易忽略早期设定的约束条件。你可以把它类比成一个人的短期记忆让你一边读需求文档、一边查资料、一边写代码你会忘掉需求文档里的关键约束。模型也一样而且它“忘掉”的方式更隐蔽——它不会告诉你它忘了它会直接在后续输出里无视那个约束产出一份漂亮但不符合要求的交付物。第二重天花板是工具权限混杂带来的失控风险。如果你只用一个 Agent 又让它有搜索、数据库查询、写文件、发消息等权限一旦它在某个环节出现误判副作用会被放大。我见过一个典型例子某次我让 Agent 自动整理数据它觉得数据有点脏居然自己写了一段清理脚本去改了源文件完全绕过了我原本让它“只读分析”的要求。这不是模型故意使坏而是职责边界没设清楚。Subagent 的核心价值之一就是把工具权限按任务边界切开每个子任务只拿到自己需要的最小权限出问题也只在局部爆发。第三重天花板是流程状态的混乱。单 Agent 自己既要做项目经理又要做工程师还要做测试所有状态都堆在同一段对话历史里。过程中一旦出错你很难判断它到底处于哪个阶段、哪一步决策出了问题。调试的时候尤其痛苦你只能看到一段漫长的对话流无法定位是哪一小步把整体带偏了。拆成 Subagent 之后每个子任务有了独立的生命周期你可以单独检查每个子任务的输入、输出和工具调用记录问题定位思路一下子清晰很多。1.2 Subagent 能解决什么不能解决什么Subagent 能解决的是四件事上下文聚焦、工具权限隔离、并行能力、错误边界。上下文聚焦让它不用背着一整段历史去做一件小事工具隔离让每个子 Agent 只操作自己该操作的东西并行能力让多个独立子任务可以同时推进省时间错误边界让单个子任务的失败不会立刻毁掉整个任务。但 Subagent 不能解决的是两件事第一它不能提高模型本身的智力上限。如果底层模型能力不够拆得再细也不会质变只会把一个大幻觉拆成几个小幻觉。第二它不能弥补编排层设计的混乱。主 Agent 如果不懂得如何拆任务、不定义清楚输出格式Subagent 越多协作成本越高甚至互相干扰。所以 Subagent 的正确使用姿势不是“把任务扔出去就完事”而是围绕它建立一套输入输出协议和验收机制。这个认知说起来简单却是我在踩了多次坑之后才真正理解的。2. 两种协作拓扑与场景选择说完了为什么拆再来说怎么协作。基于我在实际项目里的尝试目前比较成熟可靠的协作拓扑大致分两类链式传递和管理器-执行者模式。两者的适用场景完全不同放在一起对比会更清晰。2.1 链式传递适合流水线型任务链式传递几乎是最好理解的模式。任务被拆成若干工序Subagent A 干完把中间产物交给 Subagent BB 再交给 C像工厂流水线一样依次推进。我在一个数据处理需求里用过这种结构先让一个子任务从原始文档里提取信息再将提取结果交给下一个子任务做格式化最后再做一次校验。因为每道工序只需要处理上一道工序的输出子任务的上下文非常干净出问题时也容易定位是哪个环节。但是链式传递有一个致命弱点中间产物的格式必须非常稳定。我早期在这个项目里吃过一个大亏。第一个子任务把提取结果写成了自然语言段落第二个子任务要从这些段落里抽取关键字段。结果模型每次理解的侧重点都不一样有的抽漏了字段有的把描述性语句当成数据录了进去最终输出完全不可用。后来我强制第一个子任务必须返回指定字段的 JSON第二个子任务只做“读 JSON → 转化 JSON”的动作问题才彻底解决。链式传递适合那些工序边界清晰、前后依赖强、一旦定好协议就基本不会变化的任务选择它之前先问自己一句中间产物格式能不能定义得很严格能就用链式不能就要谨慎。2.2 管理器-执行者模式适合复杂研究型任务另一种是管理器-执行者模式也就是主 Agent 做“项目经理”负责拆任务、派活、验收而不直接做具体工作每个具体子任务交给专门的 Subagent 去执行。这种模式非常适合那种需要多角度探索、多信息源验证的研究型场景。举个例子假设要生成一份某行业的调研报告主 Agent 可以先拆出“市场概况”“竞品分析”“技术趋势”“风险因素”四个子任务分别派给四个不同的 Subagent每个 Subagent 只专注自己的方向最后主 Agent 再汇总成文。这种模式的优点很明显每个子任务都足够聚焦结果质量更容易保证子任务之间如果互不依赖还可以并行执行节省时间。缺点也明显主 Agent 的调度能力会成为瓶颈。如果它不懂得合理拆任务可能把一个本该拆成三块的活拆成十几块导致大量时间花在派活和等待上反过来如果它拆得太粗糙子任务内部又会变得复杂难控。我个人的经验是子任务的粒度应该控制在“让 Subagent 独立思考之后能产出一个明确交付物”的程度。比如“分析该公司的三条主要产品线并对比优劣”就比“分析这家公司”更好用。前者的产出物是明确的对比结果后者则会收到一堆宽泛的资料。2.3 两种模式的取舍判断链式和管理器式并不是对立关系实际系统里常常是混合的。主流程用管理器式拆解某个依赖链明显的环节内部再用链式传递。我在选择协作拓扑的时候会先看两个问题任务顺序依赖强不强子任务之间有没有互相独立、需要并行的地方两者对照如下判断维度链式传递管理器-执行者适用场景流水线式数据处理、明确工序依赖研究、分析、内容生成等探索型任务流程特征串行执行上一环节输出是下一环节输入主 Agent 负责拆分、调度、验收子任务可并行失败影响前一个环节出错会导致整条链路重跑单个子任务失败可单独重试该子任务复杂度结构简单调试容易调度逻辑复杂需要注意任务边界与验收规则上手成本较低较高需要精心设计 Agent 的拆解能力如果你刚起步我建议先跑通链式传递因为它的结构最简单、最容易排查问题。等对 Agent 的输出稳定性有信心之后再加管理器的拆解层演进成一个完整的协作系统。3. 上下文管理与状态传递最容易翻车的地方如果让我用一个词总结 Agent 协作中最容易出问题的环节我会选“状态传递”。任务拆得再好协议写得再规范上下文传丢了、传偏了整个协作还是会崩。这一章讲讲我在上下文管理和状态同步方面踩过的坑和最终采用的方案。3.1 只给需要的上下文不要把全部历史塞进去我见过不少人刚上手 Subagent 的时候习惯把父 Agent 的整段对话历史直接转发给子 Agent美其名曰“让子 Agent 了解完整的背景信息”。这种做法的结果是 token 消耗巨大而且引入大量与子任务无关的噪声模型反而抓不住重点。我给它的建议是采用“任务卡片”模式父 Agent 在派发任务时只传四类信息——任务目标、所需输入材料、输出协议、约束条件。其他背景能省则省实在需要背景知识就用压缩摘要而不是原文。我实际用下来的一套任务卡片字段大概是这样的任务 ID、任务目标、输入数据、可用工具、输出协议、验收标准、失败处理策略。其中“失败处理策略”很多人会漏掉但很关键。子任务在执行过程中如果发现自己干不了应该直接返回 failed 状态而不是硬着头皮编造结果。这个策略要在派单时就写清楚否则子 Agent 很容易为了“完成任务”而给出虚假交付物。3.2 先定输出协议再做任何编排我在讲链式传递时已经提到过一次输出格式的重要性这里我要再强调一遍因为这是整个协作体系中最值得优先做的事。Subagent 的输出不能靠“自然语言 让下一个模型去理解”必须要求它输出结构化数据最常见的就是 JSON。这里有个关键点父 Agent 本身也是模型它做验收和汇总的时候同样依赖确定性结构去判断。如果子 Agent 返回的是一段自然语言父 Agent 每次都可能有不同的解读结果就是同一个子任务跑三次三次结论都不一样。我自己的经验是在做任何框架选型、任何复杂编排之前先把子任务的 JSON Schema 定好。例如{ task_id: task_001, status: completed, summary: 本子任务完成情况的一句话总结, result: { key_field: value, items: [] }, confidence: 0.92, errors: [] }这样一来主 Agent 拿到返回值后只需要做非常轻量的解析和字段检查就能判断任务是否完成而不需要“重新理解”子任务的输出。还有个附加技巧如果子任务的产出需要给人看我一般要求它同时输出“给机器读的 JSON”和“给人读的 Markdown 报告”两者分开避免模型为了输出好看的报告而牺牲数据完整度。双通道输出听起来麻烦实际用起来很省心。3.3 共享记忆还是传消息上下文之外还有一个绕不开的问题是状态同步。两个常见思路一个是消息传递也就是我上面说的任务卡片模式父 Agent 发给子 Agent、子 Agent 返回结果所有信息都在消息中流动另一种是共享记忆区类似一块黑板多个 Subagent 可以读写同一块存储。消息传递的优势是隔离性好、逻辑清晰适合绝大多数场景也是我默认采用的方式。共享记忆区适合那些确实需要多个子 Agent 协作修改同一份资料的场景但它的坑比较隐蔽并发写入冲突和旧数据污染。我在某个研究任务里踩过一次坑。子 Agent A 在共享区写了一个关键结论子 Agent B 没有及时同步或者没注意到这条结论产出物与它冲突父 Agent 也没察觉最后汇总报告自相矛盾。排查了很久才发现是共享区数据版本混乱导致的。如果你想用共享记忆区我的建议是给每次写入操作带上子 Agent 标识和版本号父 Agent 在汇总前检查版本链是否完整。如果能不用共享记忆就尽量不用消息传递在这个阶段足够满足大部分需求。4. 实操踩坑实录四个高频问题与排查方法这一章我从实际运行日志里捞出来四类反复出现的问题每类都按“现象、根因、解法”来讲。这些都是很具体的坑如果你也在搭 Agent 协作系统大概率会碰到。4.1 子任务返回结果格式不稳定现象同一个任务、同一个 Prompt连续跑三次三次返回的 JSON 结构都不一样有时候字段名变了有时候多了一层嵌套有时候直接输出 Markdown 而不是 JSON。这个问题在接入不同模型时尤其严重不同的模型对结构化输出的遵守能力差异明显。根因通常有三个输出模板不够具体、temperature 参数设得过高、模型本身对长文本里的格式约束“注意力漂移”。解决步骤我建议这样第一步在子 Agent 的系统 Prompt 里明确给出输出 JSON 的完整示例不要只写字段名要给一个完整的填充示例第二步在代码里加一个 JSON 校验层解析失败时把错误信息回传给模型让它基于报错信息修复一次而不是立刻重跑整个任务第三步把 temperature 调低一些对于精确提取类任务我一般设置在 0 到 0.2 之间第四步校验加修复最多重试两次超过次数就标记失败不要无限制重试。4.2 死循环与重复派活现象主 Agent 对某个子任务的执行结果不满意之后又派了一次同样的任务得到类似但不完全一致的结果还是不满意于是再派一次……一直到触发调用次数上限才停下来。这个问题的迷惑性在于单看每次派活似乎都“有点道理”但它已经严重影响效率和成本。根因是主 Agent 缺少“任务已完成的硬性判定标准”。它觉得结果不够好但又说不清哪里不够好于是只能反复尝试。解决办法是在编排层加约束同时让父 Agent 的验收动作变得可判断。比如任务卡里写明“仅当 JSON 的 status 为 completed 且 result 字段满足全部验收条件时任务才算完成”满足即停不满足直接判定失败并记录原因而不是再随机派一次。另外编排层也要做好防火墙设置最大调用次数、令牌预算、单任务卡重试上限。这些都是硬性约束模型再聪明也不能突破。4.3 并行 Subagent 的限流与结果一致性现象管理器式协作里主 Agent 一次性派出 8 个并行子任务结果有 3 个超时还有 2 个因为 API 限流直接报错。更隐蔽的问题是并行子任务如果共享了某些全局信息结果之间可能出现互相矛盾。解决方案分两块。并行调度方面并发数不要一上来就拉满我建议从小值起步比如 3 个跑稳定了再逐渐增加。重试要用指数退避策略第一次失败等 1 秒、第二次等 2 秒、第三次等 4 秒避免所有子任务同时重试造成二次限流。结果一致性方面如果子任务之间有依赖关系必须先做拓扑排序把有依赖的任务分成批次每批次内并行批次之间串行。盲目并行只适用于真正互相独立的子任务。4.4 “虚假完成”与验收缺失现象子 Agent 返回 status 为 completed但你打开 result 一看内容非常空泛或者干脆是模型编造的信息。这可以说是 Agent 协作里最危险的坑因为失败至少会暴露问题而虚假完成会把错误悄悄埋进后续流程。根因是模型有强烈的“给出一个答复”的倾向。你让它完成任务它就算没有真正完成也会倾向于先交一份看起来合理的答案。解法是硬性验收规则。不要让子 Agent 自己判断“做完了没”而是给它一套具体、可检查的验收条件。比如要求“提取结果必须包括至少 5 条事实性条目每条必须带来源编号”达不到这个条件子 Agent 必须把 status 设为 failed并在 errors 字段里说明缺了什么。宁可让它主动承认失败也不能让它编造成功。我见过很多团队在这一步偷懒结果整个 Agent 系统看起来跑得风风火火实际上产出的东西大量需要返工。5. 一套可落地的协作范式与工具链选型道理讲了这么多最后给一套可以直接上手的参考范式和选型判断维度。这部分没有太玄的东西就是我在多次重写编排系统之后沉淀下来的套路。5.1 协作范式任务-执行-验收-汇总我的参考范式很简单四个阶段任务拆解、子任务执行、结果验收、成果汇总。任务拆解由主 Agent 完成输出若干张任务卡执行阶段每个 Subagent 只处理自己那张任务卡并按照协议返回结构化结果验收环节由主 Agent 按照任务卡里的验收标准做字段级检查全部通过之后主 Agent 把多个子任务的结果汇总成最终产出。这里最容易被忽略的是“验收”这一环。很多团队把主 Agent 当成中转站只做拆任务和拼结果中间验收几乎没有结果就是子任务各自完成得挺好合到一起却发现到处打架。我的做法是让主 Agent 在验收阶段不仅看单个子任务的返回字段还要对比多个子任务之间的结论是否有冲突有冲突就进入一轮“澄清机制”比如派一个专门的子任务去核对矛盾结论。5.2 工具链选型的判断维度选 Agent 编排框架的时候我一般不会盲目追求功能最全的那个而是按下面几个维度打勾是否支持递归和子 Agent 派生内置记忆与状态管理好不好用有没有并发调度、重试、限流这些基础机制能不能方便地接入外部工具以及可观测性是否足够强。可观测性我特别想强调一下很多框架跑起来像黑盒你根本看不到每个子任务的 token 开销和调用轨迹出了问题只能全链路猜排查效率极低。不同项目适合的框架也不一样。如果你主要的场景是固定流程的数据处理轻量一点的编排层可能就够了如果你要做的是长时间的探索型研究任务那就需要更强的主 Agent 调度能力和记忆管理能力。我的建议是先拿一个最小场景跑通框架的核心链路再决定要不要深入使用而不是一上来就堆一堆插件和高级特性。5.3 一套具体的 Prompt 示例最后给一份我实际在用的 Prompt 模板算是一个可以直接抄作业的起点。主 Agent 派单时用的模板大致长这样你正在向专家子代理分配一个任务。请严格按照以下模板输出任务卡 { task_id: 子任务唯一标识, objective: 子任务明确目标一句话说清楚要产出什么, inputs: [输入材料1, 输入材料2], allowed_tools: [允许使用的工具列表], output_schema: { status: completed 或 failed, summary: 总结, result: 具体结果, errors: 失败原因列表 }, success_criteria: [可检查的硬性验收条件如必须包含来源编号], failure_policy: 无法满足成功条件时必须返回 failed并说明原因 }子 Agent 执行端的模板大概长这样你是一个聚焦单一目标的专家代理。你收到的任务卡如下 {task_card} 请严格按 output_schema 返回 JSON不要输出任务卡以外的内容。如果无法满足 success_criteria 中的任意一条必须将 status 设为 failed并用 errors 说明缺少了什么。这套模板的核心思路是“把约束写在任务卡里让子 Agent 变成执行特定协议的工人”。模型不可能 100% 遵循模板所以程序里要加校验和修复层双保险才能保证稳定性。踩完这些坑之后我最大的体会是Subagent 协作这件事本质上是把一个不可控的大模型问题拆成若干个相对可控的小模型问题。让子 Agent 专注一个小目标定义清楚的输入输出协议加上严格的验收规则系统自然而然会稳定下来。如果你正在搭自己的 Agent 系统我建议你不要一上来就追求复杂的架构和花哨的编排先挑一个最简单、最核心的子任务把任务卡、JSON 协议、验收和失败处理这一条链路完整跑通再逐步增加复杂度。链条搭稳了后面再加什么都顺手。