1. 单Agent扛不住的时候就是拆分的信号1.1 我第一次真实的翻车现场做AI应用开发这几年我踩过最狠的一次坑是让一个全知全能的Agent去自动生成一份行业研究报告。当时我想得很简单大模型上下文窗口够大让它自己搜资料、自己分析、自己写权限都给足问题不大吧结果跑了不到三个小时输出就开始精神分裂。前半部分还在认真分析市场规模后半部分突然开始引用完全不相关的网页内容给它指定的标题规范写到第五章就彻底丢了最离谱的是它把我在系统提示词里写的一条引导语当成正文内容直接搬进了报告里。那次之后我彻底明白一件事单Agent的瓶颈往往不是模型能力本身而是上下文里的信息浑浊。任务越长、涉及的工具越多、中间环节越杂这个浑浊就越严重。要解决这个问题不能靠堆提示词只能靠架构层面的调整也就是把Multi-Agent真正用起来。1.2 单Agent到底卡在哪三个地方我把当时的问题归纳成三类你可以对照自己的项目看记忆污染。对话历史越积越长Agent开始分不清早期自己说过的话和用户真实需求谁的优先级更高。早期结论和后期结论互相打架指令被淹没在历史数据里模型逐渐丢失主线。成本失控。每次调用都要把全部历史都塞给模型。假设一个任务迭代30步每步新增约1500 token的中间产物那么第20步时单次调用可能要带上3万token的旧上下文。跑完整个任务大量token都花在反复重复旧内容上。职责漂移。一个Agent同时扮演研究员、写作员、审核员角色切换多了以后系统提示词里那句你现在是数据分析师的影响力会被越来越长的历史稀释。我就亲眼看着它从分析师慢慢变成了复读机。所以Multi-Agent的真正价值不是多几个模型一起跑而是把一个大而模糊的任务拆成多个小而清晰的任务分配给职责明确、上下文干净、能够互相协作的执行单元。要做成这件事核心是解决三个问题怎么拆任务、怎么隔离上下文、怎么设计协作机制。这篇文章围绕这三件事展开最后附一个完整的实战复盘希望能给正在做Agent应用的同学一点可复用的思路。2. 拆任务任务树、依赖关系与角色岗位说明书2.1 任务树怎么画才不容易散架拆任务的第一步是画任务树。我推荐的方法是目标倒推法从最终交付物出发反复问要产出这个东西必须先得到什么逐层往下拆到叶子节点。拿我刚才说的行业研究报告为例任务树大概是这样的生成行业研究报告 ├── 确定报告大纲 │ └── 规划子章节与每个章节的要点 ├── 数据采集 │ ├── 市场规模数据 │ ├── 竞争格局信息 │ ├── 技术趋势资料 │ └── 典型玩家动态 ├── 数据核验与清洗 │ ├── 冲突信息交叉验证 │ └── 来源可信度评估 ├── 分析结论生成 │ ├── 市场趋势判断 │ └── 竞争格局分析 └── 报告撰写与质检 ├── 章节成稿 └── 事实一致性审校画到叶子节点时我用三个问题来做收敛判断可完成性这个子任务能不能由单一Agent在少数几次LLM调用内完成如果需要先查再想再写好几个来回说明还要继续拆。输入输出清晰度它的输入来源是谁、输出交给谁中间有没有明确的数据格式如果说不清任务边界就是模糊的。可验收性任务完成后怎么验证做得对不对比如采集Agent的验收条件是返回N条带来源链接的事实卡而不是抽象的搞一些资料回来。2.2 依赖关系与三种拆法任务树的节点不是孤立的常见的依赖关系有三种串行依赖A完成才能开始B比如先采集再核验、并行依赖互不依赖可以同时跑比如竞品分析和市场规模测算、条件依赖B走哪条路径取决于A的结果比如数据如果显示行业处于衰退期就得追加原因分析。对应这三种依赖常用的拆分策略有三种流水线拆法按阶段切成A→B→C的链式结构适合阶段边界清晰、顺序固定的任务。扇出拆法一个任务裂成多个并行子任务完成后统一汇总。适合管理、研究、采集这类可以同时铺开的环节。分支拆法根据中间结果动态决定后续任务通常需要编排层介入由Manager Agent做路由判断。我实际使用时的组合拳是整体走流水线局部用扇出遇到条件依赖就让Manager做路由。这样既有确定性又不失灵活。2.3 角色定义比提示词重要拆完任务就要给每个Agent定义岗位说明书。这一步很多人会偷懒只写一句你是一个数据分析师。但实际跑起来你会发现Agent之间的协作质量靠的不是提示词里那点性格描述而是清晰的输入输出契约。我给每个Agent的岗位说明书固定包含五要素要素含义示例职责范围只做什么、明确不做什么只负责采集不进行分析输入契约接收什么格式的数据JSON数组每个元素含keyword、max_results输出契约返回什么格式的交付物含source、claim、confidence的事实卡数组可用工具能调用哪些工具搜索API、网页抓取工具成功标准什么算完成、什么算失败facts数组为空视为失败并上报举个例子数据采集Agent的输出契约我会写成这样{ task_id: string, facts: [ { source: string, claim: string, confidence: 0.0 } ], status: done | partial | failed }有了这个契约下游Agent完全不需要关心上游是怎么搜索、怎么抽信息的拿到JSON就能干活。这比任何精心堆砌的提示词都更能决定系统上限。任务拆得细、契约定得清后面做上下文隔离和协作编排才会顺。3. 隔离上下文每个Agent的记忆边界到底划在哪3.1 不隔离的代价有多大上下文隔离是Multi-Agent和多角色一体化提示词最本质的区别。一体化提示词里所有角色共享一份完整对话历史而Multi-Agent必须让每个Agent拥有自己的记忆空间。为什么必须这么做除了前面说的记忆污染还有两个硬理由。第一个是token经济学。假设整个任务链路的原始上下文是100个单元分成5个Agent后每个Agent实际只关心其中20个单元。隔离之后每次调用只需要带20个单元不隔离的话每次调用都要带100个单元。任务规模越大、迭代轮数越多两者的成本差距就是指数级的。我在一个中等规模的项目里实测过做上下文隔离后整体token消耗降低了约60%延迟也明显下降。第二个是事实一致性。采集Agent读到的100篇原始网页里必然存在噪音、过时信息和互相矛盾的表述。如果这些原始内容全部进入写作Agent的上下文写作Agent很容易写出前后打架的句子。隔离的真正意义是让每个Agent只看到被加工过、可信且与当前任务相关的那一小部分信息。链条越往下游信息浓度应该越高噪音越少。3.2 隔离的三种落地方式具体怎么实现隔离我整理过三种从轻到重的落地方式会话级隔离每个Agent维护独立的session/对话历史Agent之间只通过方法调用的返回值传递信息。这是最简单的一种适合流水线模式实现成本极低。存储级隔离每个Agent访问独立的向量数据库集合或命名空间只能检索到自己的领域数据。适合需要长期记忆、跨多轮任务的场景。我之前用Qdrant做过按Agent名拆collection的方案排查问题时非常清爽。白板级隔离系统有一个共享存储区Agent只被授权读写某些分区或键值域。公共分区放最终结果私有分区放过程数据。我目前的主力方案是**会话级隔离共享白板的组合**每个Agent的对话历史严格私有任务完成后的交付物写入白板供有权限的下游Agent读取。这个组合简单、可控、出问题时边界清楚。3.3 共享白板的正确打开方式共享白板是上下文隔离里的例外区域设计不好就容易又变成一锅粥。我给自己定了三条使用规则只写结果不写过程中间思考、失败尝试、冗余草稿一律留在私有上下文里白板上只允许出现对外可用的交付成果。按命名空间分区比如research/raw_facts、analysis/conclusions、report/final_draft。每个Agent只能写自己所属的分区对其他分区只有只读权限。带版本和状态每次写入都附上version、updated_at、status字段。下游Agent通过status判断数据是否可用避免读到写到一半的脏数据。提示最容易翻车的地方是让Agent手写一个超长总结传给下游。这种自然语言接力本质上还是在传递原始上下文只是换了个位置。正确的做法是让Agent把关键信息结构化把原文引用或工件ID传给下游下游需要细节时再按ID去读源数据。隔离的目的不是不传信息而是只传该传的那部分。4. 协作机制编排四种模式与消息协议设计4.1 四种主流协作模式怎么选拆完任务、划好上下文就到了Agent之间怎么协作的环节。我整理过四种主流模式各有各的适用场景。串行流水线PipelineA完成把输出交给BB交给C。适合阶段边界清晰、顺序固定的任务比如采集→清洗→分析→写稿。优点是链路简单、好排查缺点是慢且任何一个环节卡住整条链就卡住。管理者和执行者Hierarchical一个Manager Agent负责拆任务、派发、收集结果、汇总下面挂多个Worker Agent。适合任务结构会动态变化的场景。Manager不亲自干活它更像一个有调度权的路由器。我习惯让Manager只做三件事分解、派发、汇总具体执行一律下放给Worker。黑板模式Blackboard所有Agent围绕一个共享区域工作谁发现新信息就写入其他Agent被触发后读取并继续推进。适合探索型任务比如让多个Agent集体研究一个开放性问题。难点是触发机制不好设计容易空转或重复劳动。对抗/评审模式Debate/Review多个Agent对同一结果评审、挑错、修改循环迭代直到收敛。适合代码审查、内容质检这类准确性要求极高的场景。缺点是成本高而且如果Agent能力不够会出现低质量的互相抬杠。实际项目里这些模式经常混用。比如我的研究报告项目就是整体流水线、采集环节扇出并行、末尾挂一个质检Agent做评审。别拘泥于选一种模式按任务树上的结构去组合才是正道。4.2 消息协议让Agent之间说结构化的话不管选什么协作模式Agent之间的消息格式都建议走结构化协议而不是用一段话把所有信息说完。我一般至少约定这几个字段字段说明task_id全局唯一任务标识贯穿全链路from / to发送方、接收方payload业务数据按约定的JSON Schema校验statuspending / done / failed / needs_inputtrace_id链路追踪ID用于排查问题有了这套字段做日志分析、链路追踪、失败重放都很方便。我见过不少项目让Agent直接把结果用一段话说给下一个Agent听结果出问题时日志里全是自然语言根本定位不了是哪一步把数据搞坏的。消息协议是你给Agent系统上的第一个保险丝。4.3 异常处理与降级路径Multi-Agent系统真正跑到生产环境后最常见的三个异常是Agent输出格式不符合契约说好返回JSON结果给了段散文、Agent在失败后进入死循环式重试、下游Agent拿到上游数据却解析失败。我的应对思路分三层契约校验层在每个Agent输出的入口做JSON Schema校验不合格就自动附加格式错误反馈让它再试一次仍失败就标记失败并上报绝不放行脏数据。超时与熔断给每个Agent调用设置超时时间和最大重试次数。超过阈值不再盲目重试而是把控制权交还给编排层由Manager决定是重派还是标记失败。降级路径关键链路连续失败时主动降级成单Agent直出模式。牺牲一点质量保证整个流程不卡死。很多Agent框架解决的问题是怎么让Agent跑起来但没有回答跑坏了怎么兜底。恰恰是这个兜底设计决定了你的系统是demo还是能稳定跑的生产系统。5. 实战复盘行业研究报告自动生成的Multi-Agent设计5.1 需求拆解与Agent拓扑我拿一个实际做过的项目完整过一遍设计流程自动生成某新兴行业的深度研究报告。这个系统从用户给一个行业关键词开始到交付一份带数据来源、分析结论、格式规范的完整报告。我把任务拆成了六个Agent岗位拓扑如下Agent职责上游输入下游输出规划Agent拆报告结构、定每章要点用户需求大纲JSON采集Agent搜索并抽取原始事实大纲关键词事实卡列表验证Agent核验冲突数据与来源可信度事实卡验证通过的事实集分析Agent产出市场趋势、竞争格局结论事实集分析结论JSON写作Agent按大纲组织成文大纲分析结论章节草稿质检Agent审校事实一致性、格式规范章节草稿终稿修改意见协作模式是规划Agent → [采集Agent扇出并行→ 验证Agent] → 分析Agent → 写作Agent → 质检Agent。整体是流水线中间采集环节做扇出末尾挂评审。编排层用一段简化的Python逻辑可以写成这样def run_pipeline(requirement): outline planner.run({requirement: requirement}) fact_tasks fan_out(collector, outline[keywords]) facts validate.run(fact_tasks) conclusions analyst.run({facts: facts}) draft writer.run({outline: outline, conclusions: conclusions}) final, review qa.run({draft: draft, outline: outline}) return final每一步的输出都走契约校验校验不过就返回给原Agent重试一次。5.2 上下文划分表谁该看到什么这是整个设计里我最看重的部分。每个Agent的上下文边界必须提前写清楚不能含糊采集Agent只看搜索关键词和检索结果摘要看不到报告大纲全貌。这样做是为了避免它带着结论去找论据——一旦它知道报告结论是行业高速增长它搜索时就会只挑支持增长的资料。验证Agent只看事实卡和来源URL不做行业分析只做来源可信度交叉验证。分析Agent只看验证通过的事实集不看原始网页。保证分析基于可信数据而不是被原始噪音干扰。写作Agent只看大纲和分析结论不看事实明细。避免写作时被原始数据带偏也避免它擅自修改数据。质检Agent只看成稿和大纲对照检查事实一致性和格式规范。这样划分之后整条链路的信息浓度是逐级上升的从几十条原始URL到若干条事实卡再到几条分析结论最后变成报告。每个Agent只接触自己该接触的那层上下文干净token开销可控职责边界也清晰。5.3 踩过的坑和修复手段系统上线后我踩了三个很典型的坑每个都值得拿出来说。第一个坑采集Agent返回空结果却报成功。排查发现它的输出契约里status字段默认值是done——即使没抓到任何事实它也按成功返回。结果下游单个分析Agent拿着空事实集硬写出了两页看似合理的空泛分析。修复办法是让契约校验强制要求facts数组非空才允许返回done同时在编排层加了空结果拦截。第二个坑写作Agent悄悄脑补数据。写作Agent拿到的分析结论里有市场规模约为X亿元它写进正文时擅自改成了更精确的X亿元较上年增长Y%没有任何依据。修复办法是在结论字段里增加confidence和source_id并明确告诉写作Agent数据一律照抄不要润色、不要推断保持原样。第三个坑上下文隔离做得太死报告前后风格不一致。并行扇出的多个写作子任务分别完成后拼起来读着像拼凑文章。后来我在共享白板里加了一个全局风格规范分区由规划Agent在启动时写入风格要求写作Agent运行时都读取这份规范风格才统一下来。这三个坑说明一个道理隔离不是目的可控才是。什么该隔离、什么该共享要以信息正确、风格统一、成本可控三个目标来做权衡。6. 最后几点经验6.1 别为了多Agent而多Agent我见过不少项目任务其实很简单强行拆成四五个Agent结果光协调消息就占了大部分token效果反而不如单Agent加一套好提示词。如果你的任务在单Agent下能稳定完成那就先别拆。等你真的遇到记忆污染、上下文超限、职责漂移这三个问题之一再认真考虑拆。6.2 从单体结构化开始迁移先做单体Agent把输入输出协议定义清楚整体跑通后再按协议拆分成多个Agent和编排层迁移成本极低。我几乎所有Multi-Agent项目都是从单体提示词迭代过来的这条路最稳。别一上来就画一个庞大的Agent拓扑那是给自己挖坑。6.3 可观测性是排查故障的命根子每个Agent的输入输出、token消耗、重试次数、链路耗时都要打日志。排查哪个Agent把数据搞坏了时一条完整trace比任何脑补推理都管用。我在生产系统里给消息协议加了trace_id之后定位问题的平均时间从小时级降到了分钟级。6.4 给Agent认错的权利在系统提示词里明确允许Agent输出我需要额外的信息让它在拿不准的时候主动上报而不是硬编一个表面合理的答案。这一点在验证类、质检类Agent上尤其好用——它们经常需要判断这里的证据不足以得出结论。给Agent一条认错的出口比让它硬着头皮生成一个看似完整实则错误的答案要划算得多。如果你正在设计自己的多Agent系统建议从一个你正在头疼的单Agent任务开始先画出任务树再定义每个节点的岗位说明书然后划上下文边界最后选协作模式。把这四步走完你的系统已经比大多数demo型项目扎实了。后面每加一个Agent都先问一次它真的有必要独立存在吗它的上下文边界和消息契约定清楚了吗回答好这两个问题你的Multi-Agent系统就能长期稳定地运转。