老读者都知道我这人一向对“堆技术概念”这件事比较警惕。尤其是去年到今年“多 Agent 系统”基本成了 AI 应用层的流量密码好像不带几个 Agent 协作就没脸跟人打招呼。说实话我自己也在这上面栽过跟头最早做复杂任务拆分时脑子一热上了 8 个 Agent 并行跑结果上下文互相污染、Token 烧得飞快、输出结果乱七八糟最后花了两天擦屁股。所以今天这篇我就把自己折腾多 Agent 系统的真实经验拿出来聊聊核心话题只有一个协作拓扑怎么选以及选完以后有哪些坑等着你。这篇文章不会给你堆砌概念也不会画一堆看起来很高级的架构图而是直接讲四种我实测用过的协作拓扑每一种都对应什么场景选型依据是什么并发配置怎么调以及最常见的几个翻车现场。不管是正准备做 Agent 编排的工程师还是已经被多 Agent 折腾得睡不着觉的算法同学这篇文章都值得你花十分钟看完。不敢说让你少走全部弯路但至少能帮你避开我踩过的那些大坑。1. 四种协作拓扑详解从排队干饭到三体人多 Agent 系统说到底就干一件事把一团大任务拆开分给多个具有不同能力的 Agent 去执行。但“拆开之后怎么组织”这件事直接决定了系统的高效还是崩溃。我在实践中接触到的协作拓扑归纳下来就四种链式、扇出/并行、路由/编排者、图式/网状。这四种各有各的脾气用对了是利器用错了是灾难。1.1 链式拓扑最直觉的流水线链式拓扑的思路非常简单就是把 Agent 一个接一个排成队前一个 Agent 的输出作为后一个 Agent 的输入形成一条单向流水线。你可以在很多开源框架里看到它的影子比如有些人把 LangChain 的 LangGraph 里的 Sequential 节点或者一些工作流引擎的 pipeline 模式本质都是链式。这种拓扑最适合的任务是那些本身就存在严格先后顺序、中间结果有明显层级关系的场景。举个我实际做过的例子写技术周报。我先用 Agent A 去抓取这周的研发提交记录和会议纪要然后把 A 整理出的素材交给 Agent B 去提炼成要点最后再由 Agent C 把要点排版成正式周报格式。整个过程就是 A 到 B 到 C每一步都依赖上一步的输出完全没有回旋余地。链式的好处很突出。第一逻辑简单可追踪性强任何一个环节出错你直接看是哪个 Agent 的输入输出出了问题就行不需要全局排查。第二上下文开销小每个 Agent 只需要接收直接上游传来的信息不需要了解全局所以 Token 消耗是最低的。第三开发速度快你不需要设计复杂的调度逻辑写几行代码串起来就完事。但链式的短板同样致命。一是单点故障任何一个 Agent 挂了整个链路就断了后面全部白干。二是延迟叠加如果每个 Agent 要花 5 秒三个串起来就是 15 秒用户等得失去耐心。三是错误传导前面 Agent 一旦输出错误信息后面的 Agent 会把这个错误当事实继续加工最后输出一个看起来很合理但完全跑偏的结果。应对办法后面我会专门讲这里先记住一个结论链式拓扑适合“短链路、强依赖、可接受延迟”的任务一旦你的节点超过四五个就要开始警惕了。1.2 扇出/并行拓扑把任务拆给一群人扇出拓扑也叫 Fan-out/Fan-in核心是一个协调者把任务拆成 N 个子任务分发给多个 Worker Agent 并行执行再把所有结果聚合回来。这种模式非常适合“大批量、相互独立、结果可合并”的任务。我做过的典型案例是批量竞品分析。比如要分析 10 家竞品的定价策略如果用一个 Agent 挨个看时间和 Token 都扛不住。我就用一个拆解 Agent 先生成 10 个独立的分析指令然后同时启动 10 个 Worker Agent 分别去处理一个竞品最后再用一个聚合 Agent 把 10 份报告汇总成一份横向对比。整个耗时从原来的串行 5 分钟降到了 1 分钟以内效果非常明显。扇出拓扑最大的优点就是并行度高、吞吐量大。而且因为各个子任务之间天然隔离错误爆炸半径小一个 Worker 出了问题重跑那一个就行其他 Worker 不受影响。但这个拓扑有个容易被忽略的难点拆解的质量。如果协调者没有一个清晰、不重叠、可执行的任务拆解能力分给 Worker 的任务互相有交集或者边界模糊最后聚合的时候就会乱成一锅粥甚至出现同一个事实两个 Agent 给出不同结论的情况。聚合这一步也是难点多个结果合并时如果各结果之间格式不一致或存在事实冲突你很难让聚合 Agent 自动判断谁对谁错。所以我的经验是用扇出拓扑之前先想明白三件事任务能不能拆成互不依赖的子任务子任务的输出格式能不能强制统一聚合阶段有没有人工兜底的机制这三个问题只要有一个答不上来扇出很可能就是灾难。1.3 路由/编排者拓扑一个聪明的调度大脑路由拓扑也叫编排者模式是当前工业界最实用、最常见的一种多 Agent 组织方式。它的核心思路是有一个中央调度 Agent也常被称为 Router、Orchestrator、Planner它自己并不直接完成业务任务而是负责“看菜下饭”接收用户的输入理解意图后决定由哪个子 Agent 或哪条执行链路来处理。这个模式特别适合那种“入口统一、场景多样”的业务系统。最典型的例子就是智能客服。用户进来可能问退款、查物流、开发票你说让一个 Agent 全权负责很容易因为知识库太杂而答非所问。更好的办法是入口 Agent 先判断这是一个物流问题、支付问题还是售后问题然后把它路由到对应的专项 Agent。每一个专项 Agent 的知识库和工具都是高度定制的回答质量和效率都会高得多。路由拓扑的好处是扩展性好。你每接入一个新的业务领域只需要新增一个子 Agent并在路由规则里加一个分支即可不需要改动其他 Agent 的逻辑。同时边界清晰子 Agent 之间不需要互相感知责任划分非常明确出了问题可以直接定位到对应的 Agent。但路由拓扑也并非没有代价。首先中央编排者本身成了系统的单点和瓶颈。如果路由 Agent 死了整个系统就瘫了。其次路由判断一旦出错任务就会被送到错误的 Agent 手里轻则答非所问重则引发连锁错误。我见过很多系统子 Agent 本身做得不错但路由准确率只有七成整体体验立刻崩盘。所以路由拓扑对编排者的意图识别能力要求极高而且必须设计兜底分支当置信度低时要能退回人工或通用 Agent而不是硬着头皮给个错误答案。1.4 图式/网状拓扑全连接的高成本自由图式拓扑也叫网状拓扑是所有拓扑里最复杂也最“性感”的一种。在这种模式下Agent 之间可以任意通信可以自由协商任务的分工和协作关系不是预先写死的而是由 Agent 们在执行过程中动态规划出来的。你可以把它想象成彼得·帕克体内的那种能力整个系统像是有三体人的感觉彼此实时互通共同演进。一开始我对这种拓扑寄托了很大的幻想让多个 Agent 像一群人开会一样自己去拆解问题、互相检查、迭代优化岂不是能把复杂任务解决得很漂亮后来实际试了一次我才明白这种自由是要付出惨痛代价的。图式拓扑首要的代价就是上下文爆炸。N 个 Agent 两两通信意味着信息量呈指数级增长。你需要维护一个巨大的共享记忆池每个 Agent 读取和写入时都会消耗大量 Token。我做过一个实验用三个 Agent 做图式协作每轮每个 Agent 都要同步全部对话历史才跑了三个回合Token 消耗已经让我肉疼了。其次是调试地狱。链路是动态生成的意味着你无法预测 Agent 们下一刻会走哪条路。系统出了问题你想复现都难因为你甚至说不清出错时 Agent 之间经历了什么对话。我后来翻 trace 日志翻了两个小时才勉强定位到问题是 Agent B 误解了 Agent C 的消息。但这种定位能力并不总是靠得住。图式拓扑真正适合的是那种没有固定方法论、需要探索和反复试探的问题比如开放式的科学研究辅助、复杂的多目标优化。如果你做的是一个流程相对固定的业务系统用图式拓扑纯粹是给自己找罪受。我的观点很明确图式拓扑是存在适当时机的但不是现在不是大多数业务场景。大多数情况下它是研究项目或炫技 Demo离稳定可用的工程系统还差得很远。2. 选型决策框架什么项目该选什么拓扑说完了四种拓扑的脾气接下来就是最关键的问题我怎么知道自己的项目该用哪一种我见过不少团队一上来就照抄网上的“SuperAgent”架构弄一堆 Agent 满天飞最后发现根本维护不住。其实选型没那么玄乎你只需要问自己三个问题答案基本就出来了。2.1 三个关键问题依赖、容错、成本第一个问题也是最核心的任务之间的依赖是串行还是并行如果业务本身的流程就是前后相继的比如“先收集再分析再输出”那链式拓扑就是天选。如果业务可以被拆成多个互不依赖的独立任务比如“同时分析 10 份文档”那扇出拓扑明显更合适。如果业务既有依赖分支又有并行节点那你就考虑用一个编排者去动态组合也就是路由/编排者拓扑。第二个问题出错时你能否接受部分失败换句话说你对“精确性”的要求有多高。链式和扇出都比较好做失败隔离因为每一步的输入输出是可预期的你可以在关键节点做校验。图式拓扑最难做容错因为流程不是固定的你没法定点校验每一步。如果你做的是医疗咨询、法务分析这类容错率极低的任务我强烈劝你远离图式老老实实用链式加人工审核。第三个问题你的资源和预算有多大这里说的资源不仅仅是钱还包括时间。图式拓扑需要大量的调试时间和 Token 预算链式和路由拓扑则相对省。你如果是一个小团队预算有限就不要在初始阶段追求“全自动智能体集群”起步用最简单的模型把成本压到最低再说。2.2 复杂度由简到繁的原则项目推进过程中很多人容易犯一个毛病想一步到位一开始就设计一个“完美”的多 Agent 架构。我以前也这样后来发现这是绝对的反模式。正确的做法是先用最简结构把业务逻辑跑通再根据瓶颈和痛点逐级升级拓扑。具体来说我提倡“由简到繁、按需升级”的路线。第一版如果你判断业务的步骤是固定的就用链式拓扑甚至直接用单 Agent 加提示词模板不要急着上多 Agent。跑一段时间发现某个独立环节耗时太长而且可以并行就把这个环节拆出去做成扇出。再跑一段时间发现用户的问题领域太分散单一流程无法覆盖那就加一个路由 Agent按意图分流。你要是对 Agent 之间的动态配合有强烈需求再考虑图式而且要控制在一个很小的子任务范围内。我给你打个比方。做多 Agent 系统就像创业开公司你一开始肯定是一个人干所有事等业务量大了你才招第一个员工再忙不过来就招第二个而不是一上来就搞一个几十人的大公司。贪大求全的结果往往是系统复杂度失控最后谁都不知道这个系统为什么会出问题。2.3 架构演进的信号什么时候该换拓扑什么时候需要考虑从一种拓扑切换到另一种拓扑我总结了几个实际运维中会遇到的信号你对照自己的系统看看有没有中招。第一个信号是延迟超标。你发现某个环节的处理时间明显拖了整体后腿而且这个环节的任务是相互独立的这就是扇出/并行介入的信号。我优化竞品分析那一次就是靠这个信号把整体耗时缩减了 80%。第二个信号是某个环节经常被重复执行。比如链式拓扑里Agent B 频繁因为输出不符合规范被要求重写。这说明 B 不是一个稳定的单节点它的判断逻辑其实很复杂需要再细分。这时候你可以考虑把 B 内部拆成一个小的路由拓扑让 B 自己成为一个微型的多 Agent 系统。第三个信号是上下文窗口频繁不够用。如果你发现每次调用的 prompt 都长到快要触及模型的上下文窗口上限这说明你的链路太长或者信息太杂。解决办法不是单纯换更大的上下文窗口而是要考虑拓扑级的信息过滤。比如增加一个专门的“上下文压缩”Agent或者把长链路拆成多个短阶段让每个 Agent 只负责处理聚焦的信息从而缩短上下文长度。3. 实操agent 并发配置与工程化调参拓扑选型定了接下来的重头戏就是落地时的工程参数配置。这块网上说得比较零散我结合自己的项目经验把并发配置、超时重试、上下文管理、可观测性这四个维度一次性讲透。3.1 并发配置的关键参数多 Agent 系统的并发配置本质上是一道资源规划题。你去调用模型服务的时候上游通常有并发限制比如每秒请求数或每分钟 Token 数你的 Worker 并发数不是想开多大就开多大而是要基于上游限制和任务特性来推算。我常用的一个经验公式是合理并发数 上游服务允许的最大并发请求数 × 0.8。留出 20% 的余量是为了应对突发流量和重试导致的瞬时并发高峰。比如上游 QPS 限制是 20那我一般把 Worker 并发设成 16。在实际编码中我会给并发池设定四个关键参数max_concurrency最大并发数、queue_size等待队列长度、timeout单次任务超时、retry_times失败重试次数。下面这个 Python 伪代码片段是我近期的项目里的一个配置示例你可以参考着改import asyncio from asyncio import Semaphore MAX_CONCURRENCY 8 # 同时最多执行的子任务数 QUEUE_SIZE 100 # 等待队列上限超过则拒绝新任务 TASK_TIMEOUT 30 # 单个子任务超时秒 RETRY_TIMES 3 # 单任务失败重试次数 semaphore Semaphore(MAX_CONCURRENCY) async def run_worker(task): async with semaphore: for attempt in range(RETRY_TIMES): try: return await asyncio.wait_for(execute_agent(task), timeoutTASK_TIMEOUT) except asyncio.TimeoutError: logger.warning(ftask {task.id} timeout, retry {attempt 1}) raise RuntimeError(ftask {task.id} failed after {RETRY_TIMES} retries)注意我这里用的是协程asyncio因为多 Agent 场景下主要瓶颈是等待模型 API 的 IO 响应而不是 CPU 计算。你用多线程甚至多进程也能实现但协程的资源开销最小。除了并发数还要严格控制队列长度。实际项目中我见过有人把队列设为无限大结果上游一抖动积压了海量任务全部在超时边缘反复重试直接把整个系统拖垮。3.2 超时与重试的工程化聊到超时和重试很多人的第一反应是“超时报错就重试呗”。但是重试有很多讲究这里最容易踩坑的地方在于不是所有的失败都适合重试。如果是上游模型因为过载返回 429 错误那过一会儿重试通常是有效的这叫瞬时故障。但如果是你的 prompt 根本设计有问题导致模型每次返回相同的不合规结果那你重试一百次也没用纯属烧钱。我的方法是分层超时与重试。第一层单次 API 调用超时设置成 30 秒超过 30 秒就当失败触发指数退避重试。指数退避的策略是第 1 次重试等待 2 秒第 2 次等待2^24秒第 3 次等待2^38秒最多重试 3~5 次。这样做的好处是上游短暂过载时我们不会用高频重试把下游彻底打挂。第二层整个任务级别超时比如一个大任务总体不能超过 120 秒。这一层是兜底防止某个子任务里的重试逻辑无限循环最终把整个任务拖死。第三层业务校验重试当模型返回结果无法通过 JSON 格式校验或逻辑校验时我们重新生成但这个重试最多只做 1 次因为大概率是 prompt 问题而不是随机错误。另外做重试机制时一定要注意幂等性设计。如果 Agent 在执行业务动作时不只是读数据还会写数据比如发邮件、建工单那重试就可能导致重复执行多次产生严重副作用。解决办法是给任务生成一个唯一次请求 ID上游在处理请求时先检查这个 ID 是否已经处理过处理过就直接返回旧结果坚决不重复执行。这种幂等设计在真正的生产环境里是刚需很多人一开始不做等到线上出现重复工单就晚了。3.3 上下文管理与 token 控制我见过不少多 Agent 项目功能和效果都跑通了一看账单傻眼了Token 消耗高到吓人。这里面的核心原因就是上下文管理没做好。多 Agent 系统最常见的 Token 浪费点有三个。第一链式拓扑里把上一轮 Agent 的完整对话历史直接传给下一个 Agent历史越长消耗越离谱。第二扇出拓扑里每个 Worker 都把完整的任务背景和资料库内容拷贝一份带进上下文导致同样的背景被重复读取 N 遍。第三路由拓扑里编排者为了做判断把用户的所有历史记录全部塞给模型但真正有用的可能只有最后一条消息。我的应对策略是“二级压缩”。第一级在把上游 Agent 的输出传给下游之前用一个轻量级的总结 Agent 把信息压成结构化摘要。这个摘要只包含下游任务的必要信息比如结论、置信度、关键数据其余冗长的推理过程通通丢弃。第二级设置全局 Token 预算。我给每个子任务分配一个 Token 上限比如 8000 Token用来放置 prompt 和输出。如果任务进行中 Token 快要用完Agent 就要主动做“遗忘”操作把最久远、最不重要的记忆从上下文里替换出去。这里还有一个小技巧模型调用时尽量把temperature调低比如 0.1尤其在链式传递的环节需要尽量减少随机性。你想想如果每个 Agent 都有自己的一点“小个性”那经过三层传递错误就会像滚雪球一样被放大。3.4 可观测性多 Agent 系统调试的命脉很多团队把多 Agent 系统做出来以后最头痛的问题就是调试。传统单体程序出错有堆栈、有日志多 Agent 系统呢错误可能发生在任何一个 Agent而且每个 Agent 的输入输出都是动态的传统的日志系统根本不够用。我强烈建议每一个 Agent 环节都记录标准化的结构化日志至少包含以下字段agent_id、task_id、span_id、parent_span_id、input_summary、output_summary、token_usage、latency_ms、status。有了这些字段你才能像查链路追踪一样把一个大的任务请求串起来看到它经过了哪些 Agent每个 Agent 花了多少时间和 Token卡点在哪。另外定期抽样人工审查 Agent 的 prompt 和输出也非常重要。机器是不知道自己跑偏了的你必须在早期就建立一套抽查机制尤其在上线初期最好每一个请求都留存 prompt 和 response用人工判断模型输出是否符合预期。你说不定会发现很多模型自己根本意识不到的诡异逻辑而这些发现往往是系统迭代方向的重要依据。4. 踩坑清单与排查实录最后这部分是这篇文章最实战的部分。我把做多 Agent 系统以来踩过的最典型的坑整理了出来每一个都附上排查思路希望能给你省出大量时间。4.1 典型踩坑场景附排查思路坑一上下文污染/错误传导。这是链式和图式拓扑最常出的问题。早期做一个信息提取项目Agent A 在提取时漏了一个字段Agent B 拿到缺字段的数据后没有报警而是脑补了一个看似合理的值填了进去最后 Agent C 拿着这个编造的值做分析得出了一个完全错误的结论。排查过程用了很久因为单看每一步的日志都好像没问题直到把三个 Agent 的输入输出放一起对比才发现数据是 A 开始就丢了。解决办法在 A 和 B 之间加一道结构化校验对必填字段进行强校验缺了就抛错绝不把不完整数据传给下游。坑二死循环。这是在图式拓扑里最容易遇到的。两个 Agent 因为对一个问题的理解不一致互相发送澄清消息你发给我一条“请解释”我回你一条“请参考上文”一来一回日志刷了几百条Token 烧了不知道多少系统就是不往下走。后来我加了最大轮次限制和循环检测机制任何一个 Agent 如果发现自己收到的上一条消息内容和若干轮之前完全一样就自动停止。这个机制救了命现在我的系统里任何图式子流程最多只允许跑 6 轮超过就强制结束并交由人工处理。坑三把 Agent 数量当成性能指标。这是我见过最多的认知偏差。早期的项目为了显得功能强大硬塞了 12 个 Agent结果系统响应慢、Token 费用高、错误率也居高不下。后来在一次重构里砍掉了 6 个冗余 Agent把剩下 6 个的职责重新划清效果反而全面提升。这里我想强调一个铁律多 Agent 的复杂度是呈指数级上升的每增加一个 Agent你的系统复杂度和调试成本都会翻倍。能用 3 个解决的事坚决不用 4 个。坑四并行任务进度丢失。扇出拓扑最怕的不是某一个任务失败而是失败后你不知道其他任务进行到哪一步了。有一次跑一个含 100 个子任务的批量分析跑到一半个别任务因为上游限流失败重试逻辑因为超时设置太短也失效了最后 100 个任务里丢了 8 个整个结果集少了一块。后来我给任务列表加了持久化队列任务从分发到完成的状态都记录在数据库里失败的任务可以重新入队不再依赖内存状态彻底解决丢任务的问题。坑五路由误判。路由 Agent 的准确率不可能是 100%总会有一些用户输入模棱两可它判断错了方向导致任务被送到错误的 Agent 里。这个问题在客服机器人类系统里尤其致命。我吃过亏后为路由加了一个“置信度阈值”机制当路由 Agent 对意图的判断置信度低于 0.7 时不直接路由而是先抛给用户做二次确认或者转交给一个兜底通用 Agent。这个机制虽然增加了一次交互但整体体验明显提升。4.2 多 Agent 并发配置常见问题速查表鉴于并发配置是工程落地中最容易出现故障的环节我把实操中最常见的故障和排查方案整理成一个速查表。症状可能原因解决方式并发数调大了但整体吞吐量没怎么提升上游 API 有并发限制实际请求被限流排队调低并发数重试策略改为指数退避避免触发上游限流惩罚偶尔超时报错重试后成功模型服务响应缓慢属于正常抖动单次请求超时适当调大如 40s开启指数退避重试但设置最多 3 次防止雪崩总耗时反而比串行还高拓扑选错比如让不相关的环节串行等待分析任务依赖图把可并行的环节改成扇出结构不同 Agent 之间的输出经常出现事实矛盾上下文被污染或者各 Agent 使用了不同的信息源统一数据源在传递前做强校验关键数据以结构化格式传递单个任务 Token 消耗爆炸式增长没有做上下文压缩整段历史被重复携带增加摘要压缩节点只传结构化结论设置全局 Token 预算任务卡住不动日志大量重复消息Agent 之间进入了死循环设置最大轮次限制和循环检测超限时强制终止并人工介入4.3 项目复盘一次从“人海战术”到“精准编排”的经历讲一个真实项目也是我印象最深的一次多 Agent 架构重构。最早做一个综合信息分析系统时我的初始方案是让 8 个 Agent 同时干活有的负责抓新闻有的负责提取产品信息有的负责分析竞品有的负责生成报告……听起来很震撼实际跑起来简直是一场灾难。首先是上下文互相污染每个 Agent 都从一个巨大的共享池里读数据经常读到过期的、被其他 Agent 改错的内容其次是 Token 消耗高得惊人一个分析任务跑下来光 Token 成本就要好几美元更烦的是输出质量很不稳定有的 Agent 给出的报告和另一个 Agent 的数据对不上我整天忙着协调它们之间的矛盾。后来我痛定思痛把整个架构彻底推倒重来按照本文说的方法重新设计。我先梳理了真实业务场景的依赖关系发现实际上只有“采集、清洗、分析、成稿”四个核心环节于是我把 8 个 Agent 砍成 4 个专项 Agent让它们之间呈清晰的链式关系然后在采集环节内部做了一个扇出并行再在成稿之前加了一个路由判断根据报告类型选择不同的输出模板。重构之后的结果让我很震撼。Token 消耗比原来下降了 60%任务完成率从 82% 升到 96%平均处理时延从 45 秒降到 18 秒。最让我欣慰的是系统不再是“薛定谔的稳定”而是变成了一套随时可以预测、可以调试的工程系统。这次经历让我彻底明白了一个道理多 Agent 系统的重点不是“多”而是“准”是把合适的任务、合适的上下文、合适的模型放到合适的拓扑里。还有一个可以省的坑如果你用的是各种开源框架一定要先确认它对并发控制、超时设置、上下文压缩的支持程度。有的框架为了演示效果默认配置很激进盲目照搬就是送钱。最后再分享一个我个人的小习惯。每做一个多 Agent 项目我都会先画一张业务流程图哪怕是在纸上随便画都行。图上的节点不是 Agent而是任务步骤。画完之后我再把这些节点自然组合该串的串、该并的并、该加路由判断的加判断。先用业务角度思考再用 Agent 角度实现这条顺序一旦搞反你的系统基本就埋下隐患了。就我个人经验来说多 Agent 系统真正考验人的不是你会不会调用模型而是你有没有足够强的工程能力去约束和控制这些智能体。拓扑选型、并发配置、超时重试、上下文管理、可观测性每一块都是细节活。希望这篇文章能帮你把那些我趟过的坑提前避掉把你的多 Agent 系统从“玩具”推向“工具”。