大模型多智能体能力对比：统一任务与协作口径再看差异
多智能体能力对比的第一步不是看谁的角色多，而是把比较条件固定下来。
同样一个任务，用两个 Agent 串行完成和用五个 Agent 互相讨论，结果可能完全不同。
如果不先统一任务集、协作方式和评估指标，所谓对比很容易变成看演示视频。
下面按“先定口径、再看指标、最后做取舍”的顺序展开，适合正在评估多智能体方案、准备选型或搭内部评测的读者。
先统一比较口径，避免各说各话
多智能体通常指多个大模型实例或角色（如规划者、执行者、审核者）按照某种协作拓扑共同完成一个任务。
对比时最容易被忽略的是协作拓扑：谁先执行、谁可以调用谁、失败后谁负责重试。
建议在对比前固定以下条件：
- 任务集相同：选同一批可验证的任务，例如“从给定日志定位故障并输出修复命令”“根据需求文档生成可运行脚本”。任务要有明确的对错或可人工判定的结果。
- 协作拓扑一致或明确标注：串行、并行、辩论式、主管-工人式，不同拓扑不能混在一起比较。如果方案本身只支持固定拓扑，就在该拓扑下比较。
- 工具权限一致：能否调用 shell、浏览器、数据库、代码执行器，会直接影响完成率。对比时应记录每个方案可用的工具列表。
- 人工介入规则一致：什么情况下暂停等人工确认，什么情况下自动重试。没有统一规则，人工介入成本就无法比较。
一个常见误解是“Agent 数量越多能力越强”。
角色增加会带来通信开销和状态同步问题，在简单任务上反而可能降低稳定性。
对比时要看的是在给定拓扑下，任务完成率和成本是否可接受，而不是角色数量。
对比时该看哪些指标
指标不需要多，但每个都要能重复测量。
以下四类指标比较实用：
任务完成率：在固定任务集上，最终输出被判定为正确的比例。
判定标准要提前写死，比如“命令能直接执行且输出符合预期”才算通过。
通信与调用开销：多智能体之间传递消息的次数、每次消息的长度、工具调用总次数。
这些直接影响延迟和费用。
可以用日志统计：每个任务平均消息轮次、平均 token 消耗、平均工具调用次数。
故障恢复能力：当某个 Agent 输出错误、工具调用超时或返回异常时，系统能否发现并纠正。
一个可操作的检查方式是人为注入一次工具超时，观察系统是重试、切换角色还是直接失败。
人工介入成本：每个任务平均需要人工确认或修正的次数。
这个指标在演示里很少出现，但落地时往往决定能不能长期用。
如果要做成可复查的对比记录，可以按任务逐条记录：任务编号、是否完成、消息轮次、工具调用次数、是否人工介入、失败原因分类。
这样后续换模型或调整拓扑时，能看出变化来自哪里。
用具体例子看差异
假设任务是从一段 Nginx 错误日志中定位原因并给出修复命令。
方案 A 是单 Agent 直接回答。
方案 B 是两个 Agent：一个负责读日志并提取关键行，另一个负责给出修复建议。
方案 C 是三个 Agent 辩论式讨论。
在同一个任务集上，可能出现这样的情况：方案 B 因为职责拆分，提取日志更稳定，完成率略高；
方案 C 在简单日志上讨论轮次多、延迟高，完成率没有明显提升；
方案 A 在日志格式干净时表现接近方案 B，但遇到多段日志混杂时容易漏看关键行。
这个例子的结论不是“两个 Agent 最好”，而是：在需要信息提取加判断的任务上，职责拆分可能带来收益；
在简单任务上，增加讨论轮次不一定划算。
对比时要结合自己的任务类型看，不能把某个场景的结论直接套到所有场景。
另一个判断条件是任务的可验证性。
如果任务结果无法自动判定，比如“写一份市场分析”，多智能体之间的讨论可能看起来更充分，但完成率很难客观比较，这时应更多关注人工介入成本和输出一致性，而不是追求一个虚假的准确率数字。
常见坑与取舍建议
坑一：用演示任务代替评测集。
演示任务通常是精心挑选的，对比时要换成自己业务里真实出现过的任务，哪怕只有二三十条，也比看演示可靠。
坑二：忽略失败分支。
多智能体系统的能力差距往往在失败时暴露：一个 Agent 卡住后，系统是等待、重试还是降级。
对比时至少记录一次失败场景的处理方式。
坑三：把拓扑差异当成模型差异。
如果方案 A 是串行、方案 B 是并行，完成率不同可能来自拓扑而不是模型本身。
报告结论时要写清楚比较条件。
取舍上可以这样判断：任务步骤固定、结果可自动验证，优先选拓扑简单、开销低的方案；
任务需要多角度检查且人工审核成本高，再考虑增加审核角色；
对延迟敏感的场景，先测消息轮次和工具调用次数，再决定是否采用多智能体。
多智能体能力对比的最终目的不是选出角色最多的方案，而是找到在你自己任务集上完成率、开销和人工成本都能接受的组合。
先把口径固定，再谈差异，结论才站得住。
