1. 为什么单Agent撑不住复杂任务从上下文污染说起如果你最近在折腾大模型应用大概率经历过这样一个阶段一开始用一个Agent跑得好好的能查资料、能写代码、能调工具感觉无所不能。但任务一复杂比如“帮我调研一下竞品A、B、C的定价策略整理成对比表格再基于我们的成本结构给出定价建议”单个Agent就开始露怯了。最典型的表现是它会在中途“忘记”前面查到的数据或者把不同竞品的价格张冠李戴再或者上下文窗口被一堆中间结果塞满之后后面的推理质量断崖式下跌。这不是模型不够聪明而是上下文污染和任务耦合这两个结构性问题在作祟。我最初做Multi-Agent的时候踩的第一个大坑就是“以为把任务写清楚就行了”。实际上单Agent处理多步任务时所有中间状态都堆在同一个上下文里查竞品A的网页内容、竞品B的API返回、竞品C的PDF解析结果全混在一起。模型在生成最终建议时注意力被大量无关信息稀释出错几乎是必然的。Multi-Agent要解决的核心问题说白了就三件事拆任务、隔离上下文、定协作机制。拆任务是把一个模糊的大目标切成可独立执行的子目标隔离上下文是让每个子Agent只看到自己该看的信息不被其他人的中间结果干扰协作机制是定义子Agent之间怎么传递结果、怎么触发下一步、冲突了听谁的。这三个词听起来简单但每一个都有大量的设计决策要做。比如拆任务是按数据源拆还是按处理阶段拆隔离上下文是每个Agent一个独立会话还是共享一个只读的知识库协作机制是中心化调度还是去中心化协商这些选择直接决定了你的Multi-Agent系统是“112”还是“三个和尚没水喝”。这篇文章我会围绕这三个核心问题结合我在实际项目中反复迭代出来的方案把每个环节的坑和技巧都摊开讲。适合已经用过单Agent、准备往多Agent架构迁移的开发者也适合正在设计复杂AI工作流的产品同学。读完之后你至少能判断自己的场景该不该上Multi-Agent以及上了之后怎么避免最常见的翻车方式。2. 任务拆解的粒度控制拆到多细才算够2.1 拆解粒度与Agent数量的平衡点任务拆解是Multi-Agent的第一道坎。拆得太粗等于没拆一个Agent还是扛了太多东西拆得太细Agent数量爆炸通信开销和协调成本反而拖垮系统。我试过一个极端案例把“写一份行业分析报告”拆成了12个子任务每个子任务一个Agent结果光是Agent之间的结果传递和格式对齐就花了大量时间最终报告的质量还不如一个Agent加一个审校Agent的组合。后来复盘发现拆解粒度应该以“上下文能否干净隔离”为标准而不是以“任务步骤”为标准。什么意思如果一个子任务的执行需要依赖另一个子任务的全部中间过程那它们就不该拆开。比如“查竞品定价”和“分析定价合理性”后者需要前者的原始数据但如果前者只输出一个结构化的价格表后者只读这个表那就可以拆。关键在于接口是否清晰——子任务之间的输入输出能不能用明确的数据结构定义。我现在的习惯是先画一张任务依赖图节点是子任务边是数据流。如果两个节点之间的边可以用一个JSON schema描述清楚那就拆如果边是“一堆乱七八糟的上下文”那就合并。2.2 按数据源拆还是按处理阶段拆这是拆解策略的另一个关键选择。按数据源拆就是每个Agent负责一个数据来源比如一个查网页、一个读PDF、一个调API。按处理阶段拆就是按“收集-清洗-分析-生成”这样的流程拆。两种方式我都用过适用场景完全不同。按数据源拆适合信息采集类任务因为不同数据源的访问方式、解析逻辑差异大隔离上下文能避免格式混乱。按处理阶段拆适合加工类任务因为每个阶段的输入输出格式统一流水线式的协作效率更高。实际项目中我经常混用第一层按数据源拆每个采集Agent输出统一格式的中间数据第二层按处理阶段拆清洗Agent、分析Agent、生成Agent依次接力。这样既保证了采集阶段的灵活性又保证了加工阶段的规范性。注意按数据源拆的时候一定要定义一个统一的中间数据格式。我见过太多项目因为网页Agent输出HTML、PDF Agent输出纯文本、API Agent输出JSON导致下游Agent要写三套解析逻辑维护成本极高。2.3 拆解结果的验证用“可独立测试”作为标准拆完之后怎么验证拆得对不对我的标准很简单每个子Agent能不能独立测试。给一个子Agent喂固定的输入它能不能稳定产出预期的输出如果能说明这个子任务的边界是清晰的如果不能说明它依赖了不该依赖的上下文。举个例子我拆过一个“竞品分析”任务其中一个子Agent是“提取竞品官网的功能列表”。测试的时候我发现这个Agent有时候会去参考另一个Agent查到的用户评价来“补充”功能列表导致输出不稳定。这就是边界没划清——功能列表应该只从官网提取用户评价是另一个Agent的事。解决方法是给每个子Agent的prompt里明确写死“你只能使用以下输入”并且在代码层面做输入过滤不把无关的上下文传进去。这听起来很笨但实测下来是最有效的手段。3. 上下文隔离的三种实现路径与选型对比3.1 独立会话隔离最彻底但最贵上下文隔离最直接的做法就是每个Agent一个独立的会话session彼此之间不共享任何历史消息。Agent A的输出通过显式的消息传递交给Agent BB的上下文里只有自己的系统提示和A传来的结果。这种方式的优点是干净每个Agent的上下文窗口完全可控不会被无关信息污染。缺点是贵因为每个Agent都要重新建立自己的上下文系统提示、工具定义、格式说明这些都要重复消耗token。如果Agent数量多光是系统提示的开销就很可观。我一般只在子任务差异极大的场景用这种方式。比如一个Agent专门做代码生成一个Agent专门做文档写作它们的系统提示和工具集完全不同共享上下文反而会互相干扰。这时候独立会话的隔离收益大于成本。3.2 共享知识库私有工作区折中方案更常见的做法是所有Agent共享一个只读的知识库比如向量数据库或结构化存储但每个Agent有自己的私有工作区scratchpad。Agent需要信息时从知识库检索处理过程中的中间结果放在私有工作区只有最终输出才写回知识库。这种方式的好处是平衡。共享知识库避免了信息重复采集私有工作区保证了处理过程的隔离。我做的几个项目里这是用得最多的模式。具体实现上知识库可以用向量数据库存非结构化信息用关系表存结构化信息。私有工作区就是每个Agent的上下文窗口但要注意写回知识库的时机——太早写回其他Agent可能读到半成品太晚写回下游Agent等不到数据。我的经验是子任务完成并自检通过后再写回写回时带上版本号和来源Agent标识方便追溯。3.3 上下文压缩与摘要传递省token但有信息损失还有一种做法是Agent之间传递的不是原始上下文而是压缩后的摘要。比如Agent A处理完一堆网页后不把网页原文传给Agent B而是传一个结构化的摘要。这种方式省token但有信息损失。摘要的质量直接决定了下游Agent的输入质量。我试过用LLM自动生成摘要效果不稳定——有时候摘要漏掉了关键数字有时候又保留了太多无关细节。后来我改用结构化提取代替自由摘要定义好下游Agent需要哪些字段上游Agent只提取这些字段。比如下游需要“价格、功能点、用户评分”上游就只输出这三个字段的JSON不做自由文本摘要。这样信息损失可控格式也稳定。3.4 三种方案的选型对照表方案隔离程度Token成本实现复杂度适用场景独立会话最高最高低子任务差异极大、工具集不同共享知识库私有工作区中等中等中等大多数协作场景上下文压缩传递较低最低高子任务链式依赖、token敏感选型的时候我一般先问三个问题子任务的工具集是否重叠中间结果是否需要被多个下游消费token预算是否紧张根据答案组合基本能定位到合适的方案。4. 协作机制设计从中心化调度到去中心化协商4.1 中心化调度器简单可控但容易成为瓶颈中心化调度是最容易理解的协作机制有一个Orchestrator Agent负责拆任务、分配任务、收集结果、决定下一步。其他Agent都是Worker只负责执行自己的子任务。这种方式的优点是可控。Orchestrator掌握全局状态可以处理异常、重试失败的任务、动态调整任务分配。缺点是Orchestrator容易成为瓶颈——所有决策都要经过它如果任务复杂Orchestrator的上下文会迅速膨胀推理延迟也会增加。我在早期项目里用过这种模式最大的坑是Orchestrator的prompt越写越长最后变成了一个“什么都管”的巨型Agent反而失去了Multi-Agent的意义。后来我把Orchestrator的职责收窄只做任务分发和结果汇总不做具体的内容判断。内容层面的决策交给专门的评审Agent。4.2 去中心化协商灵活但难以调试去中心化协商是另一种极端没有中心调度器Agent之间直接通信通过某种协议比如合同网、拍卖机制来协商任务分配和结果交换。这种方式理论上更灵活适合动态环境。但实际项目中我很少用纯去中心化的方案因为调试太难了。当系统出错时你很难定位是哪个Agent的决策导致了问题因为决策是分布式产生的。我见过一个用Swarm模式的项目Agent之间通过消息队列通信结果出现了一个死循环Agent A等Agent B的结果Agent B等Agent C的结果Agent C又在等Agent A。这种循环依赖在去中心化架构里很难提前发现。4.3 混合模式分层调度局部协商我现在用得最多的是混合模式顶层有一个轻量级的调度器负责粗粒度的任务分配和全局状态管理底层Agent之间可以在局部进行协商比如两个Agent需要交换数据时直接通信不用经过调度器。这种模式的关键是定义清楚哪些决策归调度器哪些归局部协商。我的划分原则是涉及全局状态变更的比如任务完成、失败重试归调度器涉及局部数据交换的比如Agent A需要Agent B的中间结果归局部协商。实现上调度器可以用一个状态机来管理任务生命周期局部协商用消息传递或共享内存。这样既保留了中心化的可控性又避免了调度器成为所有通信的瓶颈。4.4 协作协议的关键字段设计不管用哪种协作机制Agent之间的消息格式都需要仔细设计。我一般会定义这几个关键字段task_id任务标识用于追踪和去重source_agent发送方标识target_agent接收方标识广播时为空payload实际数据用JSON schema约束status任务状态pending/running/done/faileddependencies依赖的其他task_id列表timestamp时间戳用于超时判断这些字段看起来简单但少了任何一个都会在调试时抓瞎。特别是dependencies字段没有它就无法检测循环依赖系统跑着跑着就卡死了。5. 实战中的翻车现场与排查链路5.1 循环依赖Agent A等BB等CC等A这是我遇到的第一个严重bug。系统跑着跑着就不动了日志里没有任何报错就是所有Agent都在“等待中”。排查过程是这样的先看调度器的状态发现有三个任务都是running状态但没有任何Agent在输出。然后查消息队列发现Agent A的最后一条消息是“等待task_003的结果”Agent B在等task_001Agent C在等task_002。三个任务互相等待形成了环。根因是任务拆解的时候没有做依赖检测。我当时的拆解逻辑是让LLM自由发挥LLM有时候会生成循环依赖的任务图。修复方法是在调度器里加一个拓扑排序检查如果检测到环就拒绝执行并报错。提示任务依赖图一定要做环检测这是Multi-Agent系统的基本安全措施。我现在的做法是在任务注册阶段就跑一次拓扑排序有环直接打回重拆。5.2 上下文泄漏Agent B读到了不该读的信息另一个坑是上下文隔离没做好导致Agent B读到了Agent A的中间结果产生了错误的推理。具体场景是Agent A负责查竞品A的价格Agent B负责查竞品B的价格。结果Agent B在生成结果时莫名其妙地提到了竞品A的价格还说“比竞品A便宜”。但Agent B的prompt里根本没有竞品A的信息。排查发现两个Agent共享了同一个向量数据库的命名空间Agent A写入的中间结果被Agent B检索到了。修复方法是给每个Agent分配独立的命名空间或者用元数据过滤确保Agent只能检索到自己写入的数据。这个坑的教训是共享知识库一定要做访问控制。我现在的做法是给每个Agent一个独立的collection需要跨Agent共享的数据才写入公共collection并且写入时打上明确的标签。5.3 结果格式不一致下游Agent解析失败第三个坑是格式问题。上游Agent输出的是自然语言描述下游Agent期望的是JSON结果解析失败整个流水线断掉。这个问题的根因是接口定义不严格。我一开始觉得“让LLM自由输出下游用LLM解析”就行了但实际上LLM的输出格式极不稳定同样的prompt有时候输出JSON有时候输出Markdown表格有时候还夹杂解释性文字。修复方法是强制结构化输出。用function calling或者JSON mode约束上游Agent的输出格式并且在代码层面做schema校验不符合格式的直接重试。重试两次还不行就报错让人工介入。5.4 排查工具日志、追踪与可视化经过这几次翻车我总结了一套排查工具链结构化日志每个Agent的输入输出都记JSON日志包含task_id、agent_id、timestamp、payload调用链追踪用trace_id串联一次完整请求的所有Agent调用方便定位问题出在哪个环节状态可视化把任务依赖图和Agent状态实时画出来一眼就能看出哪里卡住了这些工具在系统稳定运行时看起来多余但一旦出问题能帮你节省大量排查时间。我现在的项目里这套工具是标配。6. 从Swarm到生产级我的架构演进路线6.1 原型阶段能用就行最开始做Multi-Agent原型的时候我用的是最简单的Swarm模式几个Agent通过消息队列通信没有调度器没有状态管理能跑通就行。这个阶段的目标是验证可行性不是追求稳定。我一般会写一个最小的demo两个Agent一个查数据一个分析跑通之后再加Agent。这个阶段最重要的是快速迭代不要过早优化。6.2 过渡阶段加调度器和状态管理原型跑通之后问题开始暴露任务失败没有重试、Agent卡死没有超时、结果丢失没有持久化。这时候就需要加调度器和状态管理。我的做法是引入一个轻量级的状态机管理每个任务的生命周期。状态机用Redis或SQLite持久化支持任务重试、超时中断、断点续跑。调度器负责从状态机读取待执行任务分配给空闲Agent。这个阶段的架构复杂度适中适合大多数中小型项目。我现在的几个生产项目也停留在这个阶段因为再往上加复杂度收益就不明显了。6.3 生产阶段可观测性与容错如果项目要上生产还需要加可观测性和容错机制。可观测性包括指标采集任务成功率、平均耗时、token消耗、日志聚合、告警。容错包括Agent故障转移、任务幂等性保证、数据一致性校验。这个阶段我做得最多的是幂等性设计。因为Agent可能因为超时被重试如果重试时产生了重复的副作用比如重复写入数据库就会出问题。我的做法是给每个任务一个唯一的task_id所有写操作都带上task_id数据库层面做去重。6.4 什么场景不该上Multi-Agent最后说一个反直觉的观点不是所有复杂任务都需要Multi-Agent。我见过一些项目明明一个Agent加几个工具就能解决非要拆成五个Agent结果复杂度上去了效果反而下降。判断标准很简单如果任务可以在一轮对话里完成或者中间结果不需要被多个下游消费那就用单Agent。Multi-Agent的价值在于并行采集和上下文隔离如果这两个需求都不强烈单Agent是更优解。我自己的经验是先尝试用单Agent加工具调用解决问题实在解决不了再考虑Multi-Agent。这样能避免过度设计也能让系统更简单、更可维护。在实际操作中我还有一个习惯每次设计Multi-Agent系统时先画一张图把每个Agent的输入输出、依赖关系、失败处理都标清楚。这张图如果画不出来说明任务拆解还没想明白强行上Multi-Agent只会带来更多问题。画出来了再动手写代码效率会高很多。