这几年做大模型应用，我最大的体会是：真正能在生产环境稳定跑通的方案，几乎没有一个是靠单体 Agent 单打独斗完成的。大家最后都会走到同一个方向上——把任务拆成多节点、多角色协作的复杂 Agent 工作流，再围绕并行、协调、评估优化这三个关键词把系统持续打磨。并行让任务能在更短时间内获得更多角度的结果，协调让这些结果不至于彼此打架，评估优化则保证每一次改动都能被验证、被沉淀成可复用的经验。这篇文章会把这套机制的拆解思路、落地步骤和实际容易踩的坑都过一遍，适合已经写过提示词、正在把多个模型调用串成工作流的开发者参考。
1. 先把问题定义清楚：复杂 Agent 工作流到底复杂在哪
1.1 单 Agent 系统的几个崩溃点
单 Agent 系统的典型姿态，是把所有事情都丢给同一个模型：检索也用它，分析也用它，写稿也用它。乍一看很简洁，上下文也连续，但一旦任务步骤超过五六个，问题就出来了。
最常见的崩溃点是长任务漂移。任务执行到中后段，Agent 很容易忘记最开始那条硬性约束，比如“只基于给定材料回答”、“不要重复已经说过的结论”，然后自己自由发挥。我见过不少案例，单 Agent 跑一个八步的研究任务，前面四步输出都正常，到第六步开始编造数据。原因不复杂：上下文越长，模型对早期指令的注意力权重就越低，这不是靠提示词写几遍“牢牢记住”就能解决的。
第二是自我校验失效。让同一个系统既当运动员又当裁判，它通常会对自己的输出很客气。你让它“仔细检查一遍再输出”，它可能只是把原文换了个句式，逻辑漏洞照样留着。这是结构性缺陷，不是提示词问题。做质量把关的角色，应该在模型、提示词、上下文上都和生产者隔离，才能让校验真正有意义。
第三是定位困难。单 Agent 一旦输出不对，你很难判断是意图理解错了、检索没召回、拆解步子不对，还是生成阶段写歪了。所有环节的状态都混在一个上下文里，日志只能看到输入输出，中间为什么是这个结果，根本无从追溯。
所以复杂任务往多 Agent 工作流走，本质上不是赶时髦，而是为了解决三个确定性需求：让每个子任务职责单一、可独立验证；让互不依赖的子任务并行执行、缩短总耗时；让整个链路留下清晰的中间状态和评估数据，方便持续调优。
1.2 复杂度的三个来源
拆工作流之前，得先知道自己面临的是哪种复杂度。我习惯把复杂度分成三类，分别对应不同的设计手段。
第一类是数据规模带来的复杂度。输入太多，或者单份输入太大，单个 Agent 的上下文窗口装不下，强行塞进去要么截断、要么丢失细节。对应的手段是数据分片、摘要、分段处理，把大问题切成小问题。
第二类是依赖结构带来的复杂度。任务之间存在明确的先后顺序、条件分支、汇聚关系，比如“先收集素材，再写初稿，再审核，审核不通过要退回修改”。这类任务适合用有向图或状态机来描述，靠编排层控制流动。
第三类是质量标准带来的复杂度。输出需要多角度验证、多个候选方案比选、甚至要满足特定格式和引用要求。这时候单次生成很难达标，需要评审、对比、修订这类循环机制。
把这三类列成一张表，设计思路会清楚很多：
| 复杂度来源 | 典型表现 | 对应设计手段 |
|---|---|---|
| 数据规模 | 上下文放不下多份文档 / 长文本 | 数据分片、分段落并行处理、逐层摘要 |
| 依赖结构 | 节点之间有先后、条件、汇聚关系 | DAG 编排、消息路由、状态机控制 |
| 质量标准 | 需要多重校验、方案比选、格式约束 | 评审节点、共识机制、生成-修订循环 |
大多数复杂工作流是三类复杂度的叠加。比如一个行业研究报告生成任务，既要把几十份资料分片处理，又要按“摘要-分析-结论”的依赖顺序组织，最后还得有质量审查环节。只处理其中一类，往往等于没处理。
1.3 并行、协调、评估优化三者之间的关系
这三个词不是并列的三个模块，而是一条闭环：协调机制决定任务怎么有序流动，并行机制负责让没有依赖关系的部分同时推进，评估优化机制则负责验证这套流动方式是否真的好用。
很多人上手就先把并行度拉满，结果发现上下文乱飞、结果冲突、成本暴涨。我的建议是永远按照“评估优先于协调，协调优先于并行”的顺序来建设。先建一个最朴素的串行工作流，加上指标埋点和日志；再用评估发现瓶颈在哪一步；然后针对瓶颈做并行；并行引入的问题交给协调机制去收敛；最后用评估验证收益。这样每一步都有数据支撑，不会拍脑袋。
2. 并行机制：让任务真正同时跑起来
2.1 并行度从依赖分析开始，不是从主观愿望开始
并行听起来很简单：把任务多复制几份，同时跑不就行了。但实际上一旦任务之间有数据依赖，盲目并行只是在制造混乱，最后合并阶段反而要花更大代价去纠正。
我每次做并行设计，第一步永远是画依赖关系，标的不是“谁说话更流畅”，而是“谁需要谁的输出”。规则只有一条：没有数据依赖和状态依赖的任务，才考虑并行；有依赖的，老老实实排先后。
常用的拆分方式有两种。
一种是数据分片。输入是多份独立文档时，把文档按主题或来源切成多个切片，每个子 Agent 只处理自己那一份，最后汇总。这种并行最安全，因为切片之间天然隔离，互相不需要通信。比如要总结三十份会议纪要，就可以按部门拆成三个组并行处理，每组负责十份。
另一种是职能分片。一个复杂的产出任务，拆成“收集资料”、“提炼要点”、“起草初稿”、“质量审查”四个子任务。其中“收集资料”和“提炼要点”如果输入源不同，可以并行；“起草初稿”必须等前面两个完成；“质量审查”则要等初稿出来。这种拆分能明显缩短链路，但必须依赖分析做扎实。
一个典型的错误是：把需要共享结论的任务强行并行。比如两个子 Agent 都在分析同一份材料，各自得出矛盾结论，合并时谁也说服不了谁。这种场景并行不是优化，是制造问题。
2.2 扇出与扇入：并行执行的工程形态
并行执行在工程上通常表现为扇出（fan-out）和扇入（fan-in）两个阶段。扇出是把一个父任务拆解成多个子任务，分发给多个执行体；扇入是把子任务的结果回收、清洗、合并，再交给下游。
用伪代码表达大概是这样的形态：
async def execute_branch(task_meta): sub_tasks = split_by_dependency(task_meta) # 只有无依赖的节点才进入并行 async with concurrency_limit(MAX_WORKERS): # 控制并发上限 partials = await gather(*[run_one(t) for t in sub_tasks]) return merge_partials(partials, strategy=task_meta["merge"])这里有几个关键细节。
第一，子任务的结果必须结构化。扇入阶段最忌讳把每个子 Agent 的完整输出原文拼进同一个上下文，再让汇总模型去读。这样既贵，又容易因为文本太长导致汇总模型忽略关键内容。正确做法是：每个子 Agent 输出一个固定结构，包含结论、证据、置信度、失败原因，汇总模型只读这个结构，需要的细节再按需回溯。
第二，合并要分层，不要一次合并所有结果。如果有二十个子任务，不要尝试让一个模型一次性读二十份输出。先按业务逻辑聚成两三组，组内合并，再组间合并。每层合并的负担都小，细节丢失也少。
第三，并行度要受控，不是越高越好。我见过一个项目，并行度从 4 调到 12，总耗时反而上升了。原因是模型接口出现限流，大量请求在排队重试，同时合并阶段的上下文膨胀，处理时间翻倍。合理做法是给并发设置上限，并预留一部分余量给重试场景，不要让系统长期贴着资源上限运行。
2.3 并行带来的三个副作用与防控方法
并行能省时间，但一定会引入新问题。我在实际项目里反复踩到的有三个。
第一个是外部接口限流。多个子任务同时调用模型接口，上游根据账号等级给出每秒调用上限，超过就返回限流错误。防控方法是在代码里实现带指数退避的重试机制，把并发上限控制在接口限制的六到七成，避免“重试风暴”——大量请求同时失败、同时重试、又同时失败，把上游彻底打挂。
第二个是结果乱序。并行任务的完成顺序是不确定的，不能用“第几个返回的就是第几个任务”这种假设。每个子任务的结果必须携带 task_id，合并前先按 task_id 对齐。很多诡异的数据错乱问题，排查到最后都发现是扇入阶段没有做对齐，把 A 任务的结果算到了 B 任务头上。
第三个是共享状态竞争。多个子 Agent 同时写同一个缓存键、同一个临时目录，或者同一份知识库记录，会产生互相覆盖。防控办法很简单：能不加共享状态就不加；必须共享时，要么在父任务维度做隔离，要么用带锁的存储，让每个子任务的写入都带上任务标识，避免直接覆盖全局键。
并行机制设计得好，工作流能获得实实在在的吞吐提升；设计得不好，它会让错误变得更隐蔽、更难排查。
3. 协调机制：从“一堆 Agent”变成“一个工作流”
3.1 编排式与自治式：两种路线的取舍
并行负责让任务同时跑，协调负责让它们跑得有序。协调机制的设计，业内大体分成两条路线。
编排式路线是中心控制。一个调度器持有全局面板，负责拆解任务、分派子任务、接收结果、决定下一步。这样的优点是流程可控、状态清晰、权限集中，适合固定流程和强约束场景。缺点也很明显：调度器本身可能成为性能或复杂度瓶颈，一旦中心节点出错，整个工作流都可能卡住。
自治式路线是分散协作。多个 Agent 共享一个“协作空间”，各自观察状态、认领任务、发布结果，像一群人围着一块白板干活，没有绝对的中心指挥。它的优点是灵活、适应开放场景，缺点是状态不可控、结果难预测、调试成本高。
生产中我很推荐“编排为主、自治为辅”的混合方案。固定流程，比如数据采集、清洗、质检，用编排式，保证确定性；开放探索，比如“根据用户需求设计三版方案”，用自治式让多个 Agent 各自出招，再由评审环节收敛。
| 维度 | 编排式 | 自治式 |
|---|---|---|
| 适合场景 | 固定流程、强约束、需要审计 | 开放探索、方案生成、创意任务 |
| 状态管理 | 集中，清晰 | 分散，模糊 |
| 调试难度 | 较低，可按节点定位 | 较高，需要更多追踪手段 |
| 灵活度 | 依赖调度器设计 | 高，但不可预测 |
| 失败风险 | 中心节点崩溃影响全局 | 单个 Agent 失败影响小，但整体收敛难 |
3.2 五种实用的协调模式
具体到多 Agent 协同，我常用的协调模式有五种，每种都有适用场景和代价。
流水线模式。上游节点的输出直接成为下游节点的输入，严格按顺序执行。适合步骤稳定、前后依赖极强的任务，比如“取数 → 清洗 → 生成报告 → 发送”。优点是简单可靠，缺点是整体耗时取决于最慢环节，上游没做完下游只能等着。
监督者模式。一个主 Agent 或调度模块负责拆解任务、分配资源、验收结果。适合任务类型复杂、每个子任务差异大的场景。这个模式对监督者的要求很高，它不一定要会做具体活，但要能判断子任务结果合不合格。实际工程里，我更倾向于用代码实现“验收”这一步，而不是让监督 Agent 用自然语言判断，规则化验收更稳定，Agent 只负责生成内容。
黑板模式。多个 Agent 共享一个可随时读写的工作空间，各自把它擅长的部分写进去，其他 Agent 根据状态取用或继续加工。适合没有明确流程、需要互相激发的场景。这个模式效率高但容易失控，必须要设置写入规范，比如每条记录带作者、标签、状态，避免大家都在同一块黑板上涂鸦。
评审团模式。让多个独立的 Agent 分别对同一个问题给出答案或评分，再用投票或加权方式合并出最终结果。适合质量要求高、担心单点偏见的场景。多个独立判断确实能降低幻觉风险，但成本成倍增加，只适合关键路径，不适合所有节点。
生成-评审-修订循环。先让生成 Agent 产出结果，再交给独立的评审 Agent 检查，发现问题就退回修改，往复迭代直到通过。这个模式能显著提升质量，但要注意设置最大迭代次数，否则一个“永远不满意”的评审 Agent 能把任务卡死。我在实践中通常把次数限制在两到三次，超过就直接转人工或降级输出。
实际项目很少只用一种模式。一个复杂的任务往往先按流水线分段，段内用并行加评审团，关键输出再用生成-评审-修订循环兜底。模式是积木，不是教条。
3.3 消息与状态机设计：让通信可追溯
多 Agent 协作的本质是消息传递。消息设计得好，问题排查事半功倍；设计得差，工作流跑起来像一个黑箱，出问题完全无从下手。
我习惯让每条消息至少包含这些字段：
{ "task_id": "a3f2e8", "sender": "planner", "receiver": "reviewer", "type": "result_review", "payload": { "doc_id": "doc_107", "summary": "本季度销售额同比增长12%...", "confidence": 0.82, "error": null }, "schema_version": "1.2", "ts": 1710000000 }task_id 用于关联整个工作流里的所有环节；sender 和 receiver 记录消息来源去向；type 表明消息性质，是请求、结果、错误还是心跳；payload 承载实际内容；schema_version 保证消息格式演进时能兼容处理。不要小看 schema_version，工作流升级后旧的日志数据如果格式变了，没有版本标识根本没法做回归对比。
错误消息也要结构化。我习惯在错误载荷里明确区分“可重试错误”和“不可重试错误”。比如模型接口超时属于可重试，提示词内容非法属于不可重试。调度器看到错误类型后，可重试的进重试队列，不可重试的直接丢进人工处理通道。如果只用自然语言描述错误，调度器还得再让模型判断一次，浪费成本还不稳定。
状态机也建议在编排层集中维护：created → running → succeeded，running → retry_wait → running，异常状态下转移到 failed。状态不要放在 Agent 自己的上下文里，要让 Agent 通过消息上报状态，由编排层统一记录。这样任何时候出问题，查一下状态流转就能知道任务卡在哪个环节，而不是去翻某个 Agent 的生成文本。
4. 评估优化机制：把工作流变成可度量的系统
4.1 指标要分层，不能只看一个准确率
很多团队评估工作流只看一个“输出对不对”，这是不够的。复杂工作流的评估必须分层次，否则要么看不出问题，要么出了问题不知道是哪一层引起的。
我习惯把指标分成三层。
任务级指标，关注单个子任务的正确率、完成率、重试次数、平均耗时。这一层能快速定位到具体节点的问题，比如“材料摘要节点失败率高”或“审查节点总是把好结果打回重改”。
工作流级指标，关注端到端的成功率、总耗时、在途任务数、资源峰值。这一层反映整体效率。尤其要记录“端到端耗时的 P95 值”，因为平均值很容易被少数极快任务拉低，掩盖长尾问题。
系统级指标，关注调用成本、额外重试代价、缓存命中率、人工介入率。这一层决定系统能不能长期运行。有人力介入的工作流，人工介入率就是核心成本指标，太高就说明自动链路不达标。
| 指标层次 | 例子 | 主要解决的问题 |
|---|---|---|
| 任务级 | 子任务成功率、重试次数、单步 P95 耗时 | 定位具体失败节点 |
| 工作流级 | 端到端成功率、总耗时、在途任务数 | 评估整体效率和瓶颈 |
| 系统级 | 调用成本、缓存命中率、人工介入率 | 评估成本和质量稳定性 |
不建议只用单一准确率指标。准确率只告诉你结果对不对，不告诉你慢在哪里、贵在哪里、为什么不稳定。复杂工作流的评估目标是找出“影响质量的关键变量”，不是给别人一个好看的分数。
4.2 构建一个可复现的评估闭环
评估优化不能靠感觉，也不能靠零散的几次人工抽查。我建议搭一个最小但完整的评估闭环，跑起来之后所有优化决策都有数据可依。
第一步，准备固定评估集。收集一百到两百个代表性输入，覆盖正常情况、极端情况、历史失败情况。这些样本一旦确定，就不要轻易变动，它是你所有对比实验的共同基准。
第二步，固定运行条件。评估时保持并行度、模型版本、温度参数一致，只改你想验证的变量。否则两个版本的结果差异说不清是变量引起的，还是随机波动引起的。
第三步，定义评分规则。最可靠的做法是“规则检查 + 独立模型评分 + 人工抽查”三层结合。规则检查负责硬性约束，比如格式是否合法、必填字段是否缺失、是否包含禁用词；独立模型评分负责质量维度，比如相关性、完整性、是否忠于给定材料；人工抽查负责那些模型也不容易判断的软性质量问题。
第四步，做回归对比。每次改动工作流，都在原版本和新版本上跑同一套评估集，对比指标。提升幅度大于阈值才保留改动；出现任何指标明显回退，无论新指标多诱人，都要先暂停，查清原因再决定。
评估闭环建立后，优化就不再是碰运气。你可以有底气地说：哪个节点值得调提示词，哪种并行方式值得保留，哪些失败需要重试，全部基于数据。
4.3 高频优化抓手，按性价比排序
当评估数据在手，优化就有了优先级。我通常按下面的顺序动手。
先调结构化输出和提示词。这是成本最低的一步。给每个子 Agent 定义明确的输出格式，要求必须包含哪些字段和判断依据，往往能解决一半以上的输出不规范问题。提示词层面优先做强约束，而不是写一堆“请好好表现”的废话。
再调工作流的合并策略和并行度。如果评估数据显示合并节点经常丢失信息，就改成分层合并；如果显示并行带来的耗时收益已不明显，就适当降低并行度换取稳定性。这一步涉及结构变动，风险略高，改完必须跑回归。
然后调模型选型和参数。在关键质量节点上换更强的模型，在非关键节点换更便宜的模型，是成本和质量平衡的核心手段。温度参数默认宁低勿高，尤其在结构化和审查类任务上，低温能明显减少随机错误。
最后做缓存和去重。相同输入在真实场景中会出现多次，对确定性环节做结果缓存能显著降本。缓存要注意键的设计，必须覆盖影响输出的所有变量，否则会返回陈旧结果。
每轮优化只改一个变量，不要同时调提示词、并行度和模型。变量混在一起，回头根本说不清提升是哪个改动带来的。优化是个反复的活，一次只前进一步，但每一步都踩实。
5. 实际落地：从单 Agent 平滑升级的步骤与排障
5.1 先做一条串行链路，别一上来就并行
很多人看到复杂工作流的架构图就忍不住直接照着搭，结果节点一多，根本不知道问题出在哪。我的建议是分步走，先建一条完整但串行的链路，跑通之后再加并行和协调。
具体步骤可以这么做：
- 把业务场景拆成三到五个主要环节，先不追求精细，保证链路完整。
- 每个环节输出结构化结果，并把关键参数和结论写入日志。
- 用固定的二十到五十个输入跑五遍，观察成功率和耗时的方差。方差大说明链路不稳定，先找原因再继续。
- 加一个评审节点，人工看评审意见是否合理，不做自动决策。
- 确定日志和指标埋点已经能回答“哪一步失败、为什么失败”，再引入并行。
- 引入并行时，先只并行最安全的只读环节，比如数据分片处理。
- 全链路稳定后再加失败重试、动态路由、人工降级通道。
这条路径看着慢，实际上比一上来就搭七层 DAG 快得多。每层都稳住了再往上垒，排障范围始终是新增的那一小块。
5.2 分阶段演进：每一阶段都有验收标准
我把落地划分成四个阶段，每阶段结束都要有明确的验收结果，才能进入下一阶段。
阶段一：单 Agent 基线。所有任务由一个 Agent 串行完成，但保留完整步骤日志和指标。验收标准是能回答“平均耗时多少、成功率多少、最常见的失败模式是什么”。
阶段二：串行多节点。拆成生成、审查、修订三个节点，每个节点职责单一，输出结构化。验收标准是相对阶段一的成功率提升或成本下降，且失败能定位到具体节点。
阶段三：并行只读子任务。把数据分片类任务并行化，加入并发控制和扇入合并。验收标准是端到端耗时明显缩短，且并行任务本身的成功率不下降。
阶段四：动态调度。引入基于评估数据的路由逻辑，比如简单任务走快路径、复杂任务走多节点协作、失败任务自动降级或转人工。验收标准是系统在保证质量的前提下，成本和耗时都进入可控区间。
| 阶段 | 主要改动 | 验收标准 |
|---|---|---|
| 一 | 单 Agent + 步骤日志 | 能回答基本耗时、成功率、主要失败模式 |
| 二 | 串行多节点 | 失败可定位到节点，质量或成本有改善 |
| 三 | 并行只读子任务 | 端到端耗时下降，子任务成功率不降 |
| 四 | 动态路由与降级 | 质量和成本在可控范围内动态平衡 |
每一步都补上日志和评估，后一阶段的改动才有的放矢。不要跳到第四阶段才想起指标埋点，那时候前面所有节点都已经变成黑盒了。
5.3 常见问题排查速查表
把几年做 Agent 工作流的常见问题和排查思路整理成一张表，每次遇到类似症状，先按表里的方向检查，能省很多时间。
| 症状 | 常见原因 | 排查方向 |
|---|---|---|
| 任务越跑越偏题 | 上下文过长导致早期指令权重下降 | 缩短单节点上下文，把关键约束放到生成节点的系统提示最前部 |
| 流程卡在某一步不前进 | 子任务结果格式不符合合并层预期 | 检查消息 payload 是否符合 schema，错误消息是否被正确识别 |
| 合并层输出信息丢失 | 一次性让模型读太多原始结果 | 改分层合并，子任务先输出结构化摘要再逐层汇总 |
| 多个 Agent 结果互相矛盾 | 共享上下文被并发写入，或依赖分析漏了 | 检查共享状态写入规范，重新画依赖关系 |
| 成本突然暴涨 | 重试风暴或缓存键设计不当 | 检查重试策略，检查缓存命中率和缓存键覆盖范围 |
| 并行度提高后总耗时反而增加 | 接口限流或合并阶段成为新瓶颈 | 降低并发上限，观察合并节点 P95 耗时 |
还有一个容易忽略的细节：当工作流里多个 Agent 需要“互相参考”时，要防止循环依赖导致死循环。比如 A 生成方案，B 评审，A 看到评审意见修改，B 再评审，如果 B 永远不通过，A 就会无限修订。这种情况一定要设置最大迭代次数，或者让评审 Agent 在“通过”之外增加“降级通过”的选项，保证任务能收敛。
写在后面的一点经验
最后分享一个个人很深的体会：复杂 Agent 工作流的建设，自古华山一条路，就是“确定性优先，复杂度滞后”。我每次想一口气引入并行、协调、评估全套机制，最后都会变成一场排障马拉松。反而是先做一条串行链路，把消息格式、日志埋点、评估基线固定下来，再逐步引入并行和协调，系统会稳定得多。并行是把双刃剑，它在降低延迟的同时也会放大错误，协调机制就是为此存在的；评估优化不是项目收尾才做的事，而是日常每个改动都要过的关卡。希望这篇拆解能帮你在设计复杂 Agent 工作流时少走几步弯路。
