1. 多 Agent 并行之后为什么“判断对错”成了最棘手的问题1.1 从单兵作战到团队协作的范式转变过去两年Agent 开发的主流叙事一直是“让一个 Agent 把一件事从头做到尾”。你给它一个目标它自己规划、自己调工具、自己反思、自己收尾。这个模式在简单任务上跑得挺漂亮但一旦任务链条变长、涉及领域变多单 Agent 的短板就暴露得非常明显上下文窗口不够用、工具调用容易串味、一个环节出错后面全盘崩、推理成本随步数指数级上升。于是“多 Agent 并行”几乎成了必然选择。把一个大任务拆成若干子任务每个子任务交给一个专职 Agent各自带着自己的系统提示词、工具集和记忆去干活最后再把结果汇总起来。这套思路在工程上非常自然就像一家公司不会让一个人同时干产品、开发、测试、运营而是分团队协作。但问题也随之而来。单 Agent 时代对错判断相对简单——它自己输出自己反思或者人来兜底看一眼。多 Agent 并行之后你会突然发现A Agent 说这个方案可行B Agent 说这个方案有风险C Agent 给出的数据跟 A 对不上D Agent 干脆超时没返回。这时候谁来拍板凭什么拍板拍错了谁负责这就是标题里说的核心矛盾多 Agent 并行之后谁来判断对错这不是一个哲学问题而是一个必须在架构层面解决的工程问题。我见过太多团队把多 Agent 系统搭得热热闹闹结果卡在“结果汇总”这一步最后又退化成人工逐个审核并行带来的效率提升全被吃掉了。1.2 任务 DAG、质量审校、证据仲裁三件套的分工要解决这个问题得先把三件事分清楚它们经常被混为一谈任务 DAG解决“谁先干、谁后干、谁依赖谁”的问题。它是整个多 Agent 系统的骨架决定了任务怎么拆、怎么并行、怎么汇聚。质量审校解决“单个 Agent 的输出本身合不合格”的问题。它关注的是局部质量比如格式对不对、逻辑自洽不自洽、有没有明显幻觉。证据仲裁解决“多个 Agent 结论冲突时听谁的”的问题。它关注的是全局一致性是在冲突中做出可解释裁决的机制。这三者层层递进。DAG 没设计好审校和仲裁根本无从谈起审校没做好仲裁就是在垃圾里挑垃圾仲裁没做好前面所有并行都是白干。下面我会按这个顺序把每一层的设计思路、实操要点和踩坑经验掰开讲。提示很多团队一上来就写仲裁逻辑结果发现冲突根源其实是 DAG 拆分不合理或者审校标准太模糊。先把前两层做扎实仲裁会简单很多。2. 任务 DAG 设计并行不是目的可控汇聚才是2.1 为什么必须是 DAG 而不是简单列表最朴素的多 Agent 实现是一个任务列表挨个跑或者并发跑最后把所有结果拼起来。这个做法在任务之间完全独立时没问题但现实中大部分任务是有依赖的。比如“写一份行业分析报告”你得先搜集资料再提炼观点再写初稿再配数据图表最后统稿。资料没搜完就写初稿写出来的东西就是空中楼阁。DAG有向无环图的价值就在于把这种依赖关系显式表达出来。每个节点是一个子任务每条边是依赖关系。没有依赖的节点可以并行有依赖的节点必须等前驱完成。这样既拿到了并行的效率又保证了顺序的正确性。我自己的经验是DAG 的粒度控制比拓扑结构本身更重要。节点太粗并行度上不去节点太细调度开销和汇总成本爆炸。一般建议单个节点的预期执行时间在 30 秒到 5 分钟之间超过 5 分钟就考虑再拆低于 30 秒就考虑合并。2.2 节点拆分的三条实用原则拆分任务节点时我总结了三条例单一职责一个节点只做一件事输出一种明确类型的结果。比如“检索资料”和“总结资料”要拆开不要合成一个“检索并总结”。可独立验证每个节点的输出必须能被独立审校不依赖其他节点的中间状态。这样审校才能并行做。失败可隔离一个节点失败不应该导致整个 DAG 崩溃而应该能被重试或降级。这就要求节点之间的数据传递是显式的、可序列化的。举个具体例子。做一个“竞品分析”任务我通常会拆成这样的 DAG节点职责依赖可并行N1确定竞品清单无否N2抓取竞品A公开信息N1是N3抓取竞品B公开信息N1是N4抓取竞品C公开信息N1是N5提炼各竞品核心卖点N2,N3,N4否N6对比分析并生成结论N5否N7质量审校N6否N2、N3、N4 三个节点并行跑这是并行收益最大的地方。N5 必须等三个都完成N6 再基于 N5 汇总。整个结构清晰每个节点的输入输出都能明确定义。2.3 汇聚节点的设计陷阱DAG 里最容易出问题的不是并行节点而是汇聚节点——也就是依赖多个前驱的那个节点。它要处理的是“多个来源的结果怎么合并”这里有几个坑结果格式不一致三个抓取 Agent 返回的字段名、结构可能各不相同。汇聚节点如果没做归一化后面全乱。部分失败N2 成功了N3 超时了N4 返回了空。汇聚节点是直接失败还是用两个成功的结果继续这必须提前定义策略。结果冲突N2 说竞品A主打性价比N3 说竞品A主打高端。汇聚节点不能简单拼接得标记冲突交给后面的仲裁层。我的做法是汇聚节点必须有一个明确的“合并契约”规定好输入 schema、缺失值处理方式、冲突标记格式。这个契约最好用代码里的数据结构固化下来而不是靠提示词描述。提示词描述的东西Agent 十次有两次不遵守你就得排查半天。注意不要指望汇聚节点自己“智能地”处理所有异常。它应该只做机械的合并和标记真正的判断交给审校和仲裁层。职责越单一系统越稳。3. 质量审校让每个 Agent 的输出先过一遍筛子3.1 审校到底审什么质量审校不是“再让一个 Agent 看一遍”这么简单。如果审校 Agent 没有明确的检查清单它大概率会给出“看起来不错”这种废话。审校必须针对每个节点的输出类型定义具体的检查维度。我通常把审校维度分成四类格式合规字段是否齐全、类型是否正确、必填项是否为空。这类检查最好用代码做不要用 LLM又快又准。事实一致性输出中的事实性陈述是否与输入一致有没有引入输入里没有的信息幻觉。逻辑自洽结论和论据是否匹配有没有自相矛盾的地方。完整性是否覆盖了任务要求的所有要点有没有遗漏。前两类可以高度自动化后两类需要 LLM 参与。我的经验是能用规则做的绝不用 LLM能用小模型做的绝不用大模型。审校层如果全用大模型成本和延迟都会失控。3.2 审校 Agent 的提示词怎么写才有效审校 Agent 的提示词和普通任务 Agent 完全不同。普通 Agent 是“去做一件事”审校 Agent 是“去挑毛病”。挑毛病的提示词如果写得太宽松它就只会说好话写得太严苛它会把没问题的东西也判成问题。我常用的审校提示词结构是这样的你是一个严格的质量审校员。你的任务是检查下面这份输出是否满足给定的验收标准。 验收标准 1. [具体标准1] 2. [具体标准2] 3. [具体标准3] 待审校输出 [输出内容] 请逐条检查每个标准对每条给出 - 判定通过 / 不通过 / 部分通过 - 理由具体说明哪里满足、哪里不满足 - 证据引用输出中的原文作为依据 最后给出总体判定和需要修改的具体建议。 不要因为整体看起来还行就放过细节问题。关键点是逐条检查 引用证据。要求它引用原文能大幅降低它瞎判的概率。我实测下来加了“引用证据”这一条之后审校的准确率能提升不少因为它没法凭空说“这里有问题”而不指出具体位置。3.3 审校结果的处理策略审校完之后结果怎么用这里有三条路通过直接进入下一环节。不通过但可修复打回给原 Agent 重做附上审校意见。这里要限制重试次数一般最多 2 次超过就升级处理。不通过且不可修复标记为失败走降级或人工介入流程。我踩过的一个坑是重试时把审校意见原封不动丢回去Agent 经常改不对。后来我改成把审校意见拆成具体的修改指令比如“把第三段的日期从 2023 改成 2024”而不是“第三段有问题”。指令越具体重试成功率越高。另外重试次数一定要设上限。我见过一个系统因为审校和重试形成死循环一个节点跑了四十多分钟还没结束最后把整个 DAG 拖垮。重试上限 超时熔断是必须的。4. 证据仲裁多个 Agent 打架时谁来拍板4.1 冲突的三种典型形态多 Agent 系统里的冲突归根结底是三种事实冲突A 说这个数据是 100B 说是 120。这是最硬的冲突必须靠外部证据裁决。判断冲突A 认为这个方案可行B 认为有风险。这是主观判断的冲突需要引入评判标准。优先级冲突A 认为应该先做功能XB 认为应该先做功能Y。这是目标层面的冲突往往需要回到任务定义去解决。不同类型的冲突仲裁方式完全不同。事实冲突可以查证据判断冲突要靠标准优先级冲突要靠目标对齐。把冲突类型分清楚是仲裁设计的第一步。4.2 仲裁的三种机制及适用场景我实践下来仲裁机制主要有三种各有适用场景机制原理适用场景缺点证据投票每个结论附证据证据强的胜出事实冲突证据质量难量化规则裁决预设规则按规则判定判断冲突规则覆盖不全仲裁 Agent专门的 Agent 做裁决复杂综合冲突成本高、可能引入新偏见我的建议是分层使用先用规则和证据投票处理大部分冲突只有规则覆盖不了的复杂冲突才交给仲裁 Agent。这样既控制了成本又保证了覆盖率。证据投票的关键是证据的可比性。如果 A 的证据是“某报告说”B 的证据是“某数据库查询结果”这两者没法直接比。所以我在设计时要求每个 Agent 输出结论时必须附带证据类型和证据强度比如{ conclusion: 竞品A主打性价比, evidence: [ {type: official_pricing, strength: 0.9, content: 官网定价低于同类30%}, {type: user_review, strength: 0.5, content: 部分用户提到价格实惠} ] }有了结构化的证据仲裁就能按证据强度加权而不是靠感觉。4.3 仲裁 Agent 的提示词设计要点当冲突复杂到需要仲裁 Agent 时提示词的设计就至关重要。仲裁 Agent 最怕的是“和稀泥”——两边都说有道理最后给个模棱两可的结论。我的仲裁提示词核心是强制表态 说明理由 标注置信度你是仲裁员。下面有两个 Agent 对同一问题给出了冲突的结论。 Agent A 的结论[...] Agent A 的证据[...] Agent B 的结论[...] Agent B 的证据[...] 请做出裁决 1. 你支持哪一方如果都不支持给出你的独立结论。 2. 你的裁决依据是什么逐条说明。 3. 你对这个裁决的置信度是多少0-1 4. 如果置信度低于 0.7说明还需要什么额外信息才能提高置信度。 不允许给出“两者都有道理”这类模糊结论。“不允许模糊结论”这一条非常关键。不加这句仲裁 Agent 大概率会给你一个“综合来看A 和 B 的观点都有可取之处”的废话。加了之后它被迫做出选择哪怕选择是“都不对我的结论是 C”。4.4 仲裁结果的可追溯性仲裁做完了事情还没完。每一次仲裁都必须留下可追溯的记录谁和谁冲突、冲突点是什么、仲裁依据是什么、最终结论是什么、置信度多少。这份记录的价值在于事后复盘时能知道系统在哪里容易出错出现严重错误时能定位是哪个环节的问题积累足够多的仲裁记录后可以反过来优化审校规则和 DAG 设计我一般会把仲裁记录存成结构化日志字段包括conflict_id、agents_involved、conflict_type、arbitration_method、decision、confidence、timestamp。这些数据攒上几百条你就能看出系统的薄弱环节在哪里。5. 把三层串起来一个完整的实操流程5.1 从任务输入到最终输出的全链路把前面三层串起来一个完整的多 Agent 并行系统大概是这样的流程任务解析接收原始任务拆解成 DAG定义每个节点的职责、输入输出 schema、验收标准。并行执行按 DAG 拓扑顺序调度无依赖的节点并行跑每个节点由一个专职 Agent 执行。节点审校每个节点完成后立即审校通过则标记完成不通过则按策略重试或降级。汇聚合并所有前驱完成后汇聚节点按合并契约合并结果标记冲突。冲突仲裁对标记的冲突按类型选择仲裁机制产出裁决结果。全局审校对最终汇总结果做一次全局审校检查整体一致性和完整性。输出交付通过全局审校后输出同时记录全链路日志。这个流程里审校是分布式的仲裁是集中式的。审校在每个节点后做保证局部质量仲裁在汇聚后做保证全局一致。两者配合才能既快又准。5.2 关键参数与阈值设置实操中有几个参数必须调好否则系统要么太慢要么太松单节点超时建议 3-5 分钟超过就判定失败。具体看任务复杂度但一定要设。审校重试上限2 次。超过就升级不要无限重试。仲裁置信度阈值0.7。低于这个值就标记为“需人工复核”不要硬着头皮输出。并行度上限根据你的 API 配额和成本预算定一般 5-10 个并发比较稳。太高容易触发限流反而更慢。这些参数没有绝对标准得根据你的实际任务和资源调。我的建议是先保守再逐步放宽。一开始超时设短一点、重试设少一点、并行度设低一点跑顺了再慢慢加。5.3 一个容易忽略的环节DAG 执行的可观测性多 Agent 系统最怕的是“黑盒”——跑完了你不知道中间发生了什么。所以可观测性必须从第一天就做不能等出问题了再补。我通常会在每个节点记录开始时间、结束时间、耗时、输入摘要、输出摘要、审校结果、重试次数。汇聚节点额外记录冲突数量和仲裁结果。这些数据汇总到一个看板上你一眼就能看出哪个节点最慢、哪个节点最容易失败、哪类冲突最多。没有可观测性你调优就是盲人摸象。有了它你能精准定位瓶颈。我自己的系统里就是靠这个看板发现某个抓取节点经常超时后来把它的超时从 3 分钟调到 5 分钟整体成功率立刻上去了。6. 常见问题与排查技巧实录6.1 审校 Agent 总是“放水”怎么办这是最常见的问题。审校 Agent 倾向于说“整体不错”导致有问题的输出被放过。排查思路检查提示词里有没有“逐条检查 引用证据”的要求。没有就加上。检查验收标准是不是太模糊。把“内容质量好”改成“必须包含至少 3 个数据支撑点每个数据点必须有来源”。考虑用两个审校 Agent 交叉审一个宽松一个严格取交集。成本翻倍但准确率提升明显。我实测下来验收标准越具体审校越靠谱。模糊的标准只能得到模糊的审校。6.2 仲裁 Agent 给出模棱两可的结论如果仲裁 Agent 说“两者都有道理”说明提示词约束不够。解决办法明确要求“不允许模糊结论”。要求给出置信度低于阈值就标记人工复核。如果它实在无法裁决让它输出“需要什么额外信息”而不是硬给一个结论。有时候模棱两可恰恰说明信息不足这时候正确的做法是补充信息而不是逼它表态。6.3 DAG 执行到一半卡住不动这通常是某个节点在重试循环里出不来或者某个节点超时后没有正确触发下游。排查步骤看可观测性日志定位是哪个节点卡住。检查该节点的重试次数是否已达上限。检查超时熔断是否生效。检查下游节点的依赖条件是否被正确触发。我遇到过一次是因为汇聚节点的依赖条件写成了“所有前驱成功”但有一个前驱失败了导致汇聚节点永远等不到。后来改成“所有前驱完成无论成功失败”问题解决。依赖条件要区分“完成”和“成功”这是个容易忽略的细节。6.4 并行度上去了但总耗时没降并行度增加但耗时没降通常是汇聚节点成了瓶颈或者并行节点之间有隐藏依赖。排查看汇聚节点的等待时间如果它大部分时间在等说明并行节点的完成时间差异太大快的要等慢的。检查并行节点是否共享了某个资源比如同一个 API 配额导致实际串行。考虑把慢节点进一步拆分或者给慢节点分配更多资源。并行不是银弹木桶效应在多 Agent 系统里同样成立。整体耗时取决于最慢的那条路径。6.5 常见问题速查表问题可能原因排查方向审校放水提示词太宽松、标准模糊加逐条检查、具体化标准仲裁模糊提示词约束不足禁止模糊结论、要求置信度DAG 卡住重试死循环、依赖条件错误查重试上限、查依赖定义并行不提速汇聚瓶颈、隐藏依赖查等待时间、查资源共享成本失控审校和仲裁全用大模型规则优先、小模型优先7. 我个人的一些实操体会多 Agent 并行这套东西搭起来不难难的是让它稳定地产出可信结果。我最大的体会是不要试图用更复杂的 Agent 去解决 Agent 带来的问题。冲突多了就加仲裁 Agent审校不准就加更多审校 Agent这样只会让系统越来越臃肿成本和延迟越来越高问题却不一定解决。正确的思路是往简单里做能用规则的地方用规则能用代码的地方用代码把 LLM 的使用范围压缩到真正需要它的地方。审校的格式检查用代码事实核查用检索只有逻辑自洽和完整性判断才交给 LLM。仲裁也一样证据投票能解决的绝不劳烦仲裁 Agent。另一个体会是日志比什么都重要。多 Agent 系统的调试难度远高于单 Agent因为问题可能出在任何一个节点、任何一次审校、任何一次仲裁。没有详尽的日志你根本不知道问题出在哪。我现在的习惯是宁可多记日志也不要事后抓瞎。最后分享一个小技巧定期用历史任务回放整个 DAG。把过去跑过的任务重新跑一遍对比输出差异。如果同一个任务两次输出差异很大说明系统稳定性不够某个环节的随机性太强。这个方法帮我发现了好几个隐藏的稳定性问题比单看日志有效得多。这套东西还在演进任务 DAG 的自动生成、审校标准的自动学习、仲裁策略的动态调整都是可以继续深挖的方向。但不管怎么演进核心逻辑不变并行负责效率审校负责局部质量仲裁负责全局一致。三者各司其职系统才能既快又稳。