# 多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基准。它的八个任务横跨六个领域： | 任务类型 | 具体场景 | 测量的能力 | |----------|---------|-----------| | 协作-研究 | 多Agent共同撰写研究综述 | 信息整合、分工协调 | | 协作-编程 | 多Agent协作完成软件项目 | 代码分工、接口对齐 | | 协作-推理 | 多Agent联合解决逻辑谜题 | 推理链合并、冲突解决 | | 协作-模拟 | 多Agent模拟法庭辩论 | 角色扮演、论据构建 | | 竞争-策略 | 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定义了五种轨迹级幻觉类型： | 幻觉类型 | 定义 | 多Agent中的表现 | |---------|------|---------------| | **Fact Fabrication** | 编造不存在的事实 | Agent A虚构了一个数据源→Agent B引用它→Agent C基于它推理 | | **Context Drift** | 上下文渐进偏移 | 5轮对话后，讨论焦点从"降低成本"滑向"增加收入"，没人注意到 | | **Tool Output Misinterpretation** | 误解工具返回值 | Agent将API返回的"部分成功"解读为"完全成功"并传递给下游 | | **Implicit Assumption** | 隐性假设注入 | Agent在推理中无意识地加入未验证的前提假设，被后续Agent当作事实 | | **Self-Consistency Violation** | 自我矛盾 | 同一Agent在不同轮次给出了互相矛盾的结论，但没人交叉验证 | 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提出了一个三维度涌现评测框架： ```mermaid graph TB subgraph MAEBE三维涌现评测 A[行为维度
Behavioral] --> A1[集体偏见放大
Amplified Bias] A --> A2[策略坍缩
Strategy Collapse] A --> A3[角色固化
Role Rigidity] B[安全维度
Safety] --> B1[对抗联盟形成
Adversarial Alliance] B --> B2[信息囤积
Information Hoarding] B --> B3[责任分散
Responsibility Diffusion] C[效能维度
Efficiency] --> C1[冗余协作
Redundant Collaboration] C --> C2[决策死锁
Decision Deadlock] C --> C3[资源竞争
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 Crash** | 随机杀死某个Agent进程 | 系统降级曲线、恢复时间 | | **Communication Delay** | 注入消息延迟/丢失 | 超时处理、重试策略 | | **Context Corruption** | 篡改共享记忆中的数据 | 错误传播范围、检测延迟 | | **Capability Degradation** | 降低某个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的设计借鉴了人类学术评审机制： ```python # 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评测体系： ```mermaid graph TB subgraph 五层评测体系 L1["第一层：结果度量
Task Completion Rate
Goal Achievement Score"] L2["第二层：轨迹度量
Step Accuracy
Tool Use Correctness
Reasoning Chain Quality"] L3["第三层：交互度量
Communication Efficiency
Role Specialization
Conflict Resolution Rate"] L4["第四层：系统度量
Cascade Failure Rate
Recovery Time
Resource Utilization"] L5["第五层：涌现度量
Emergent Behavior Detection
Collective Bias Score
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推荐的**混合评测**： ```python # 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数量和评测深度）。以下是一个典型的成本估算： | 评测层级 | 单次成本（100个测试用例） | 频率建议 | |---------|----------------------|---------| | 结果度量 | $2-5 | 每次提交 | | 轨迹度量 | $10-20 | 每日 | | 交互度量 | $30-50 | 每周 | | 系统度量 | $50-100 | 每周 | | 涌现度量 | $100-200 | 每月 | **实战建议**：采用"金字塔策略"——底层高频低成本（结果度量每次提交都跑），顶层低频高成本（涌现度量月度执行）。用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冲突看系统如何解决、设计道德困境看系统的决策边界。这种评测方法的哲学是：**如果你的系统在对抗性测试中存活，那它在真实世界中大概率也能表现良好**。 ## 七、推荐方案 | 场景 | 推荐评测方案 | 理由 | |------|-----------|------| | **3个以下Agent，快速验证** | Anthropic三步法 + 结果度量 | 简单高效，避免过度工程 | | **5-10个Agent，生产部署** | MARA三级管道 + MultiAgentBench + MAS-FIRE混沌测试 | 覆盖全面，微软参考架构可直接落地 | | **10+Agent，安全敏感场景** | MAEBE涌现评测 + OWASP ASI08对抗测试 + MAJ-EVAL多裁判 | 安全优先，宁可过度评测 | | **研究/学术场景** | MultiAgentBench + Trajel + 自定义涌现探测 | 学术前沿覆盖，发表友好 | | **成本敏感的创业团队** | 规则评分为主 + 10%人类抽检 + 月度LLM评测 | 用规则评分覆盖80%，人类校准剩余20% | ## 八、终极判断：评测的评测 回到根本问题：**这些评测基准本身可靠吗？**答案是令人不安的。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](https://arxiv.org/abs/2503.01935) — ACL 2025多Agent协作竞争评测基准，MARBLE评分框架原始论文 2. [Beyond Final Answers: Auditing Trajectory-Level Hallucinations in Multi-Agent Industrial Workflows](https://arxiv.org/abs/2605.24219) — IBM与哥伦比亚大学Trajel轨迹幻觉审计框架，五类轨迹幻觉分类法 3. [MAEBE: Multi-Agent Emergent Behavior Evaluation Framework](https://arxiv.org/abs/2506.03053) — ICML 2025涌现行为评测框架，三维度涌现检测方法论 4. [MAS-FIRE: Fault Injection and Reliability Evaluation for LLM-Based Multi-Agent Systems](https://arxiv.org/abs/2602.19843) — 多Agent混沌工程框架，四种故障注入模式与韧性评测 5. [Demystifying Evals for AI Agents — Anthropic Engineering](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — Anthropic 2026年1月发布的Agent评测工程方法论，混合评测策略 6. [Microsoft Multi-Agent Reference Architecture: Evaluation](https://microsoft.github.io/multi-agent-reference-architecture/docs/evaluation/Evaluation.html) — 微软多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 等场景全覆盖。