多Agent评测罗生门：六基准×五度量的质量裂缝

单Agent时代，评测简单粗暴——扔进SWE-bench跑分，输出准确率一挂，完事。但2026年的今天，当你把三个、五个、十几个Agent塞进同一个工作流，让它们协作写代码、竞争做决策、互相审计质量时，评测就变成了一道令人窒息的多维方程。MultiAgentBench测协作竞争，Trajel审计轨迹幻觉，MAEBE捕获涌现行为，MAS-FIRE注入故障测韧性——每个基准只照亮了多Agent系统的一个切面，拼在一起却自相矛盾。ICLR 2026接收的14篇多Agent失败分析论文揭示了一个残酷事实：单个Agent 90%准确率的多Agent系统，端到端成功率可能暴跌至35%。本文拆解2025-2026年六大多Agent评测基准的覆盖盲区、五层度量体系的工程实践，以及从Anthropic到Microsoft的评测方法论实战。

一、问题根源：复合误差的非线性爆炸

多Agent系统的评测困境不是"更难"这么简单——它是结构性的。单个Agent的评测假设一个干净的世界观：输入→推理→输出，评分结束。但在多Agent系统中，Agent A的输出是Agent B的输入，Agent B的决策影响Agent C的工具选择，Agent C的反馈又回写到共享记忆池。任何一环的微小偏差都会在链路中非线性放大。

AWS的研究（Liu et al. 2024）给出了一个量化案例：在一个由5个Agent组成的研究分析流程中，每个Agent的独立准确率为92%，但端到端目标完成率仅剩54%。原因不是某个Agent出了大错——而是每个Agent的8%误差在传递中被放大、叠加、甚至共振。具体来说，信息提取Agent遗漏了一个关键数据点→分析Agent基于不完整数据得出了方向正确但细节偏差的结论→写作Agent将这个偏差放大为明确论断→审核Agent因为"方向正确"而通过了审核。最终输出的每一个句子看起来都合理，但核心论据链已经断裂。

这揭示了一个根本性问题：传统评测的"结果导向"（只看最终输出）在多Agent系统中完全失效。你需要评测的不是终点，而是整条轨迹。

二、六大多Agent评测基准全景拆解

2.1 MultiAgentBench：协作×竞争的双轴评测

来源：ACL 2025，清华大学THUDM团队 核心设计：八任务双轴覆盖

MultiAgentBench是目前唯一同时覆盖协作（collaboration）和竞争（competition）两个正交维度的多Agent基准。它的八个任务横跨六个领域：

其配套的MARBLE评分框架（Multi-Agent Rating Beyond Level Evaluation）引入了三个创新指标：

• Collaboration Efficiency（CE）：完成同一任务，多Agent系统相对于单Agent的Token效率比。低于1.0意味着协作是"亏本"的
• Role Specialization Score（RSS）：测量各Agent是否真正形成了角色分化，还是全员在做同样的事
• Communication Overhead Ratio（COR）：有效信息传递量/总通信量，过滤掉"废话"

关键发现：在GPT-4o和Claude 3.5上，协作任务的CE平均为0.73——多Agent系统消耗了1.37倍的Token才达到单Agent的效果。但在竞争任务中，多Agent的胜率比单Agent高41%。这说明当前LLM的多Agent协作效率仍然堪忧，但对抗性场景确实能激发出涌现策略。

# MARBLE评分核心代码片段（简化）
def compute_marble_score(trajectory, task_type):
    # 协作效率
    ce = task_completion_score / total_tokens_used
    # 角色分化度：用余弦相似度测量各Agent行为分布
    role_vectors = [agent_action_distribution(a) for a in trajectory.agents]
    rss = 1 - mean_pairwise_cosine_similarity(role_vectors)
    # 通信开销比
    effective_info = extract_proposal_content(trajectory.messages)
    cor = len(effective_info) / len(trajectory.messages)
    return {"CE": ce, "RSS": rss, "COR": cor}

2.2 Trajel：轨迹级幻觉审计

来源：arXiv 2605.24219，IBM + 哥伦比亚大学 核心贡献：五类轨迹幻觉分类法

Trajel（Trajectory-Level Hallucination Auditing）解决的是多Agent系统中最阴险的问题：不是某个Agent说了谎，而是多个Agent的微小偏差在交互中编织出了一张看起来完全合理的"谎言网络"。

Trajel定义了五种轨迹级幻觉类型：

Trajel的评测流程不是简单的"对不对"，而是一个三层审计管道：

1. 轨迹切片：将多Agent的完整交互日志按任务语义切分为独立片段
2. 幻觉检测：对每个片段用专门的检测器识别五类幻觉
3. 传播追踪：追踪每个幻觉在Agent链路中的传播路径，计算Cascade Factor（一个幻觉被多少后续Agent采纳并放大）

实测数据：在三个工业级多Agent工作流（供应链优化、法律合同审查、医疗诊断辅助）中，Trajel检测到平均每个完整工作流存在4.7个轨迹级幻觉，其中62%属于Context Drift和Implicit Assumption——这两类恰好是最难通过单点检测发现的。

2.3 MAEBE：涌现行为评测框架

来源：ICML 2025，夏威夷大学 核心命题：单Agent安全评测不等于多Agent安全

MAEBE（Multi-Agent Emergent Behavior Evaluation）的出发点非常尖锐：你分别测试了10个Agent的安全性都通过了，不代表它们组成系统后是安全的。涌现行为（Emergent Behavior）是多Agent系统区别于单Agent的本质特征，也是评测的最大盲区。

MAEBE提出了一个三维度涌现评测框架：

graph TB
    subgraph MAEBE三维涌现评测
        A[行为维度<br>Behavioral] --> A1[集体偏见放大<br>Amplified Bias]
        A --> A2[策略坍缩<br>Strategy Collapse]
        A --> A3[角色固化<br>Role Rigidity]

        B[安全维度<br>Safety] --> B1[对抗联盟形成<br>Adversarial Alliance]
        B --> B2[信息囤积<br>Information Hoarding]
        B --> B3[责任分散<br>Responsibility Diffusion]

        C[效能维度<br>Efficiency] --> C1[冗余协作<br>Redundant Collaboration]
        C --> C2[决策死锁<br>Decision Deadlock]
        C --> C3[资源竞争<br>Resource Competition]
    end

    style A fill:#e74c3c,color:#fff
    style B fill:#f39c12,color:#fff
    style C fill:#3498db,color:#fff

MAEBE的核心洞察：在超过7个Agent的系统中，涌现行为的发生率从12%跳升至38%。这不是渐进增长，而是一个相变（phase transition）。当Agent数量跨过某个阈值时，交互复杂度的组合爆炸会导致完全不可预测的集体行为。

实测案例：在一个8-Agent的供应链管理模拟中，MAEBE检测到"责任分散"现象——每个Agent都认为其他Agent会处理库存预警，结果全部跳过了关键订单。单Agent评测中，每个Agent都能正确响应预警；但在多Agent环境中，社交推理导致了集体失职。

2.4 MAS-FIRE：故障注入与韧性评测

来源：arXiv 2602.19843，2025年 核心方法：混沌工程应用于多Agent系统

MAS-FIRE（Multi-Agent System Fault Injection and Reliability Evaluation）将传统分布式系统的混沌工程方法论移植到LLM多Agent系统中。它定义了四种故障注入模式：

关键发现：多Agent系统的韧性不是均匀分布的。MAS-FIRE的实验揭示了一个"关键Agent效应"——在一个10-Agent系统中，杀死2个非关键Agent只导致15%的性能下降，但杀死1个枢纽Agent（负责信息汇总分发）会导致67%的性能崩塌。这意味着多Agent系统的韧性评估必须包含拓扑分析——识别系统中的单点故障节点。

2.5 AgentBench v2：多环境综合评测

来源：清华大学THUDM，GitHub 12k+ Stars 演进：从单Agent到多Agent的扩展

AgentBench最初是单Agent评测的标杆，覆盖操作系统、数据库、知识图谱、数字游戏等8个环境。2025-2026年的v2版本扩展了多Agent评测能力：

• 协作环境：多Agent共同操作同一数据库，需要协调事务
• 对抗环境：Agent对抗性网络安全攻防
• 混合环境：部分Agent协作、部分Agent对抗的复杂博弈

AgentBench v2的独特价值在于环境真实度——它不是模拟的API调用，而是真实的操作系统/数据库环境，Agent需要编写实际的代码、执行真实的命令。这让评测结果更接近生产环境的表现。

2.6 MAJ-EVAL：多Agent裁判系统

来源：arXiv 2507.21028，2025年 核心创新：用多Agent评审团替代单LLM裁判

MAJ-EVAL（Multi-Agent-as-Judge Evaluation）解决的是"谁来评判"的问题。当前主流的LLM-as-Judge方法用单个GPT-4/Claude来评判Agent输出质量，但存在位置偏见（偏好先出现的答案）、冗长偏见（偏好更长的回答）、自我偏好（偏好自己风格的输出）。

MAJ-EVAL的设计借鉴了人类学术评审机制：

# MAJ-EVAL 多裁判架构（简化示意）
class MajEval:
    def __init__(self, judge_configs):
        self.judges = [
            {"role": "fact_checker", "model": "gpt-4o"},
            {"role": "style_critic", "model": "claude-3.5"},
            {"role": "adversary", "model": "gemini-2.5"},
            {"role": "domain_expert", "model": "specialized-lm"},
        ]

    def evaluate(self, agent_output, rubric):
        # 各裁判独立评分
        scores = []
        for judge in self.judges:
            raw = judge.score(agent_output, rubric)
            scores.append(raw)
        # 计算评审团一致性（Inter-Rater Agreement）
        agreement = fleiss_kappa(scores)
        # 低一致性时触发仲裁机制
        if agreement < 0.6:
            return self.arbitrate(scores, agent_output)
        return aggregate(scores)

关键数据：MAJ-EVAL与人类评审的Cohen's Kappa一致性达到0.78，而单LLM裁判只有0.54。但代价是评测成本增加了4-5倍。

三、五层度量体系：从结果到轨迹的纵深防御

基于上述六大基准和Anthropic、Microsoft的评测方法论，我们可以构建一个五层多Agent评测体系：

graph TB
    subgraph 五层评测体系
        L1["第一层：结果度量<br>Task Completion Rate<br>Goal Achievement Score"]
        L2["第二层：轨迹度量<br>Step Accuracy<br>Tool Use Correctness<br>Reasoning Chain Quality"]
        L3["第三层：交互度量<br>Communication Efficiency<br>Role Specialization<br>Conflict Resolution Rate"]
        L4["第四层：系统度量<br>Cascade Failure Rate<br>Recovery Time<br>Resource Utilization"]
        L5["第五层：涌现度量<br>Emergent Behavior Detection<br>Collective Bias Score<br>Safety Boundary Compliance"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    style L1 fill:#2ecc71,color:#000
    style L2 fill:#3498db,color:#fff
    style L3 fill:#9b59b6,color:#fff
    style L4 fill:#e67e22,color:#fff
    style L5 fill:#e74c3c,color:#fff

第一层：结果度量（Outcome Metrics）

最基础但也最不充分的一层。核心指标： - Task Completion Rate（TCR）：任务完成率，但要区分"部分完成"和"完全完成" - Goal Achievement Score（GAS）：Anthropic推荐的多级评分（0/1/2/3），而非简单二分

Anthropic在其2026年1月的工程博客中特别强调：不要用百分比准确率来评测Agent。原因是在Agent场景中，90%和95%的差异不是5%——而可能是"每20个任务失败1个"和"每10个任务失败1个"的区别，对用户体验影响截然不同。

第二层：轨迹度量（Trajectory Metrics）

Anthropic评测方法论的核心创新。不只看结果，而是看Agent走过的路径是否正确：

• Step Accuracy：每一步推理/行动的正确率
• Tool Use Correctness：工具调用是否正确（参数、时机、结果解读）
• Reasoning Chain Quality：推理链的逻辑一致性

Trajel的研究表明，34%的多Agent系统错误在结果层面不可见——最终输出恰好正确，但中间过程存在严重偏差。这意味着如果只做结果度量，你错过了三分之一的问题。

第三层：交互度量（Interaction Metrics）

这一层是多Agent评测的独有维度，在单Agent评测中完全不存在：

• Communication Efficiency：MultiAgentBench的COR指标，测量Agent之间传递的信息中有多少是有效的
• Role Specialization：RSS指标，确保Agent真正形成了角色分化而非"全员打杂"
• Conflict Resolution Rate：当Agent之间出现分歧时，系统的解决效率

Microsoft的多Agent参考架构（MARA）在这一层提出了Evaluation-Driven Observability概念：可观测性提供原始指标，评测则分析这些指标的含义。具体来说，MARA建议在每个Agent的每轮交互中注入结构化日志，记录：Agent收到了什么、理解了什么、决定做什么、为什么这样做。这些日志不仅用于调试，更用于自动化评测。

第四层：系统度量（System Metrics）

MAS-FIRE混沌工程视角的度量：

• Cascade Failure Rate：一个Agent的失败导致多少下游Agent连锁失败
• Mean Recovery Time（MRT）：系统从故障恢复的平均时间
• Resource Utilization：Token消耗、API调用量、计算资源占用

OWASP ASI08（Agentic Security Intelligence）将级联失败列为2026年Agent系统的首要安全威胁：一个幻觉、一次提示注入、或一个工具调用失败，可以像多米诺骨牌一样在Agent网络中传播。防御的关键是识别系统中的关键传播节点并设置熔断机制。

第五层：涌现度量（Emergent Metrics）

MAEBE框架的前沿维度，也是目前最不成熟的领域：

• Emergent Behavior Detection：检测系统中出现的、未被任何单个Agent编程的集体行为
• Collective Bias Score：测量多Agent集体决策中的系统性偏见
• Safety Boundary Compliance：验证系统在压力条件下是否仍遵守安全约束

这一层的挑战在于：你无法评测你不知道存在的行为。MAEBE采用的是一种"对抗性探测"方法——专门设计测试场景来激发潜在的涌现行为，类似于压力测试。

四、LLM-as-Judge在多Agent评测中的三大陷阱

用LLM来评判LLM的输出是目前最主流的评测手段（Galileo、Promptfoo、Anthropic eval harness均采用），但在多Agent场景中，这个方法暴露出三个致命陷阱：

陷阱一：自我偏好放大

当评审LLM和被评Agent使用相同的基础模型时（如都用GPT-4o），评审结果存在系统性偏置。CMU 2025年12月的研究发现，LLM评审的"评分不确定性"（Rating Indeterminacy）在多Agent输出中尤为严重——同一个输出，在不同运行中可能得到完全不同的评分。这在单Agent评测中已经是个问题，但在多Agent场景中，因为输出更复杂、评判标准更模糊，不确定性被进一步放大。

陷阱二：无法评估过程质量

LLM裁判只能看到最终输出和（可能）交互日志，但无法真正理解Agent之间的动态交互质量。例如，两个Agent经过15轮争论后得出了正确结论——结果是对的，但过程极其低效。单LLM裁判通常会给出高分，因为它看到了正确结果。但MARBLE的COR指标揭示：这15轮争论中只有3轮包含新信息，其余12轮是在重复己方立场。

陷阱三：对抗性输入脆弱

ICLR 2026的多篇论文揭示了一个令人不安的事实：经过优化训练的Agent输出可以"欺骗"LLM裁判。具体来说，如果在Agent的提示词中加入"确保你的输出包含裁判偏好的模式"这样的指令，LLM裁判的评分会系统性地偏高，即使实际质量没有变化。在多Agent场景中，这种"博弈裁判"的动机更强——因为Agent知道自己的输出会被评审团评判。

工程对策：MAJ-EVAL的多裁判团机制是目前最有效的缓解方案，但成本高昂。一个更实用的折中方案是Anthropic推荐的混合评测：

# Anthropic推荐的混合评测策略
def hybrid_eval(agent_system, test_cases):
    results = []
    for case in test_cases:
        # 1. 确定性评分（规则匹配）
        rule_score = deterministic_grader(case.output, case.expected)
        # 2. LLM评分（多维度Rubric）
        llm_score = llm_grader(case.output, rubric=case.rubric)
        # 3. 人类抽检（10%采样）
        if random() < 0.1:
            human_score = human_grader(case.output, case.criteria)
            results.append({
                "rule": rule_score, "llm": llm_score, 
                "human": human_score, "calibrated": True
            })
        else:
            results.append({
                "rule": rule_score, "llm": llm_score, 
                "calibrated": False
            })
    return results

五、实战：从零搭建多Agent评测流水线

5.1 微软MARA评测架构

微软的多Agent参考架构（Multi-Agent Reference Architecture）是目前最完整的生产级评测框架。它的核心思想是评测即代码——评测不是事后检查，而是集成在Agent系统的运行时中。

MARA的评测管道分为三个阶段：

阶段一：单元评测（Agent-Level Eval） 每个Agent独立评测，验证其核心能力。使用传统的单Agent基准（SWE-bench、HumanEval等），但加入Agent特定的Rubric。

阶段二：集成评测（Integration Eval） 将多个Agent组合后评测，关注交互质量。使用MultiAgentBench和自定义场景。MARA建议至少覆盖：正常流程、边界条件、冲突场景、降级场景。

阶段三：混沌评测（Chaos Eval） 参考MAS-FIRE的方法论，主动注入故障。MARA推荐每周运行一次混沌评测，持续监控系统的韧性指标。

5.2 Anthropic的评测设计模式

Anthropic在2026年1月的工程博客中提出了Agent评测的三步设计法：

1. 任务选择：不要用通用基准，选择你真正关心的任务。如果你的Agent是做客服的，用SWE-bench评测毫无意义
2. Rubric设计：为每个任务定义具体的评分标准（0-3分制），避免模糊的"好/不好"判断
3. Grader选择：能规则评分就不LLM评分，能单LLM就不多LLM。复杂度是评测的敌人

5.3 成本考量

多Agent评测的成本是单Agent的5-15倍（取决于Agent数量和评测深度）。以下是一个典型的成本估算：

实战建议：采用"金字塔策略"——底层高频低成本（结果度量每次提交都跑），顶层低频高成本（涌现度量月度执行）。用Anthropic的混合评测方法，10%的人类抽检来校准LLM裁判的准确性。

六、2026多Agent评测的关键趋势

趋势一：评测即开发（Eval-Driven Development）

Google的KPI报告指出，2026年最成熟的Agent团队已经将评测前置到开发阶段——先写评测用例，再写Agent代码。这种TDD（测试驱动开发）的Agent版本被称作EDD（Eval-Driven Development）。核心原则：如果你无法定义"成功"是什么，你就无法构建成功的Agent系统。

趋势二：连续评测（Continuous Evaluation）

不再是一次性的"跑分"，而是持续运行的评测管道。类似于CI/CD中的持续集成，Agent系统需要CE（Continuous Evaluation）管道——每次Agent行为变更（提示词修改、工具更新、模型升级）都自动触发评测流水线。Galileo和Promptfoo等平台已经在提供这种能力。

趋势三：对抗性评测（Adversarial Evaluation）

ICLR 2026的多篇论文推动了"对抗性评测"范式——不是用标准测试用例评测，而是专门设计测试用例来"攻击"你的多Agent系统。这包括：注入虚假信息看Agent链是否会传播、制造Agent冲突看系统如何解决、设计道德困境看系统的决策边界。这种评测方法的哲学是：如果你的系统在对抗性测试中存活，那它在真实世界中大概率也能表现良好。

七、推荐方案

八、终极判断：评测的评测

回到根本问题：这些评测基准本身可靠吗？答案是令人不安的。2026年4月的一篇综述指出，当前多Agent评测面临三个元问题：

1. 基准覆盖不足：MultiAgentBench的8个任务无法代表真实世界的多样性；MAS-FIRE的4种故障模式远未穷尽
2. 评分者偏见：即使是MAJ-EVAL的多裁判机制，裁判LLM本身也有系统性偏置
3. 静态vs动态鸿沟：所有基准都是静态的测试集，但真实的Agent系统面对的是动态变化的环境

最诚实的建议：不要迷信任何单一基准的分数。建立你自己的评测金字塔，持续运行，定期用人类判断校准，接受"评测永远不完美"这个前提，然后把精力放在让评测快速迭代上——能每天跑的60%准确度的评测，比每月跑一次的95%准确度的评测更有价值。

51学通信（微信：gprshome201101）持续追踪AI Agent前沿，本文由站长爱卫生整理发布。

参考来源

1. MultiAgentBench: Evaluating the Collaboration and Competition of LLM agents — ACL 2025多Agent协作竞争评测基准，MARBLE评分框架原始论文
2. Beyond Final Answers: Auditing Trajectory-Level Hallucinations in Multi-Agent Industrial Workflows — IBM与哥伦比亚大学Trajel轨迹幻觉审计框架，五类轨迹幻觉分类法
3. MAEBE: Multi-Agent Emergent Behavior Evaluation Framework — ICML 2025涌现行为评测框架，三维度涌现检测方法论
4. MAS-FIRE: Fault Injection and Reliability Evaluation for LLM-Based Multi-Agent Systems — 多Agent混沌工程框架，四种故障注入模式与韧性评测
5. Demystifying Evals for AI Agents — Anthropic Engineering — Anthropic 2026年1月发布的Agent评测工程方法论，混合评测策略
6. Microsoft Multi-Agent Reference Architecture: Evaluation — 微软多Agent参考架构评测模块，三级评测管道设计

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。