导语：2026 年，构建一个 AI Agent 已不再是技术壁垒——甚至可以让 AI 自己生成一个。但当我们试图打造通用型、能力复杂的 Agent 时，评测成了真正的"最后一公里"。企业级 AI 应用落地最大的卡点，不再是怎么搭 Agent，而是评测怎么做
传统的实践主要有机评+人评给出权重分数，以及各种典型的 benchmark。随着 harness 工程、meta-harness 概念的提出，让 Agent 感知环境、自迭代，减少人在过程中的干预，变成一种新的思路。
本文基于对 arXiv 论文、Anthropic/OpenAI 工程博客、Twitter/X 社区讨论及业界实践的深度调研，系统梳理 Agent 评测领域的核心挑战、方法论演进和最佳实践，并以通用 Agent（OpenClaw）评测落地为例，给出可执行的路线图。最后深入剖析 Anthropic 在 Claude Code 复杂能力评测上的一手实践。
第一章 Agent 评测方法论与未来展望
一、为什么 Agent 评测是"真正的难题"
1.1 从"能不能做"到"做得好不好"
Agent 的发展已经走过了概念验证阶段。LangChain、CrewAI、OpenAI Agents SDK 等框架让"搭一个 Agent"的门槛降到了最低。但一个残酷的现实是：90% 的 Agent 开发时间花在评测和调优上，而不是初始搭建上。
Anthropic 在其广泛引用的工程博客 Building Effective Agents 中一针见血地指出：构建 Agent 的核心不是选择最花哨的框架，而是建立严格的评测体系和有效的防护机制。他们强调，成功的 Agent 开发者往往从最简单的架构开始，然后用评测数据驱动每一步复杂度的增加（Building effective agents）。
OpenAI 在发布 Agents SDK 时同样将评测放在了核心位置，提供了内置的 tracing 和 eval 框架，并明确表示：没有可靠的评测，就不可能构建可靠的 Agent（New tools for building agents）。
1.2 Agent 评测的独特挑战
与传统 ML 模型评测相比，Agent 评测面临一系列独特难题：
| 挑战维度 | 传统 ML 模型 | AI Agent |
|---|---|---|
| 输出确定性 | 给定输入，输出确定 | 同一输入可能产生不同的行动序列和结果 |
| 评测维度 | 准确率、F1 等单一指标 | 结果正确性、过程合理性、效率、成本、安全性多维交织 |
| 环境依赖 | 静态数据集 | 与外部工具/API/网页交互，环境持续变化 |
| 归因困难 | 模型输出即最终结果 | 失败可能源自推理、工具调用、环境变化等任何环节 |
| 可复现性 | 固定种子可复现 | 网页内容变化、API 响应不同、LLM 温度随机性 |
Harrison Chase（LangChain CEO）在多个场合反复强调：Agent 评测是整个 AI 应用领域最大的未解决问题之一。LangChain 的 2024 年 State of AI Agents 报告显示，"评测质量"和"可观测性"是从业者反馈最多的两大痛点。
1.3 过程评测 vs 结果评测：一个核心分歧
Agent 评测领域最根本的分歧在于：我们应该评什么？
结果导向（Outcome-based） ：只看最终结果是否正确。简单、直观，但无法解释为什么成功或失败，也无法区分"走了正确的路"和"碰巧对了"。
过程导向（Trace-based） ：分析 Agent 的每一步决策。能发现中间步骤的问题，但成本高、标注难，而且"正确的过程"本身很难定义——完成同一个任务可能有多条合理路径。
业界的实践共识正在形成：两者缺一不可，但侧重点取决于场景。
- 高风险场景（医疗、金融）：过程评测权重更高，需要解释每一步决策
- 高吞吐场景（客服、数据处理）：结果评测为主，辅以过程抽检
- 开发迭代中：过程评测用于 debug，结果评测用于 regression
Hamel Husain（前 GitHub ML 工程师）在其广受关注的 LLM 评测系列博客中提出了一个务实观点：先从最简单的、基于断言的评测开始，只有当简单方法不够用时才引入 LLM-as-Judge（Your AI product needs evals）。
二、主流 Agent 评测 Benchmark 全景
2.1 第一梯队：标杆级 Benchmark
SWE-bench（Princeton, 2023）是当前 Agent 评测领域影响力最大的 benchmark 之一。它从 12 个 Python 开源仓库中收集了 2294 个真实的 GitHub issue-PR 对，要求 Agent 理解问题、定位代码、编写补丁并通过测试（SWE-bench: Can Language Models Resolve Real-World GitHub Issues?）。
SWE-bench 的精妙之处在于：它以真实世界的代码变更为任务，评测标准是已有 单元测试 的通过率——这提供了一个几乎完美的、无需人工标注的评测闭环。其"Verified"子集经人工筛选确保每个测试都准确反映 issue 意图。
WebArena（CMU, 2023）则面向 Web 环境中的 Agent 评测，在 4 个真实网站（电商、论坛、GitLab、内容管理系统）上设置了 812 个任务，评测 Agent 在复杂网页环境中完成端到端任务的能力（WebArena: A Realistic Web Environment for Building Autonomous Agents）。
GAIA（Meta, 2023）聚焦通用 AI 助手能力，设计了需要网络搜索、多模态理解、复杂推理等综合能力的问题，且答案唯一可验证。它最大的贡献是揭示了一个有趣的反差：人类在这些任务上轻松达到 92% 准确率，而当时最强的 GPT-4 + 插件仅达 15%（GAIA: a benchmark for General AI Assistants）。
2.2 第二梯队：特定领域 Benchmark
TAU-bench（Sierra, 2024）：专注于现实客服场景（航空、零售），评测 Agent 在数据库操作和策略遵循方面的表现。它的独特之处在于评测了 Agent 在真实业务约束下的决策质量。
MLE-bench（OpenAI, 2024）：以 Kaggle 竞赛为基础，评测 Agent 的机器学习实验能力——包括数据分析、特征工程、模型训练和提交（MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering）。
AgentBench（Tsinghua, 2023）：覆盖 8 个不同环境（操作系统、数据库、知识图谱、横向思维谜题等），是最早尝试系统性评测 LLM-as-Agent 的工作之一（AgentBench: Evaluating LLMs as Agents）。
2.3 Benchmark 的局限性
尽管这些 benchmark 推动了领域发展，但它们存在系统性问题：
- 环境漂移（Environment Drift） ：WebArena 中的网页内容会变化，API 返回值会更新，导致同一 Agent 在不同时间的得分可能大幅波动
- 过拟合 风险：当 benchmark 成为"考试"，Agent 开发者开始针对特定 benchmark 优化，而非提升通用能力
- 成本天花板：SWE-bench 的完整评测需要大量 API 调用，单次运行成本可达数百美元
- 覆盖率不足：真实世界的 Agent 应用场景远比 benchmark 覆盖的范围广
MASEval（2026）的一项关键发现更是对当前评测范式提出了挑战：在同一能力层级内，Agent 框架选择对性能的影响与模型选择同样重要。这意味着仅报告"GPT-4 在 X benchmark 上达到 85%"是不够的——还需要指明用了什么框架、什么编排策略（MASEval: Extending Multi-Agent Evaluation from Models to Systems）。
三、LLM-as-Judge：让 AI 评审 AI
3.1 核心理念与方法
当 Agent 的输出是自由文本或复杂的多步骤行动序列时，传统的精确匹配和规则评测往往力不从心。LLM-as-Judge 应运而生：用一个（通常更强的）LLM 来评估另一个 LLM/Agent 的输出质量。
Anthropic 在 Building Effective Agents 中明确推荐了这种方法，并强调关键在于评测 prompt 的设计。他们的实践经验是：好的 LLM Judge 需要明确的评分标准（rubric）、清晰的评分维度定义、以及足够的示例。
OpenAI 的 Evals 框架同样内置了 LLM-as-Judge 能力，支持多种评测模板（事实正确性、风格一致性、安全性等）。
3.2 可靠性问题与缓解策略
LLM-as-Judge 并非银弹。已知的问题包括：
- 位置偏差（Position Bias ） ：当比较两个答案时，LLM 倾向于选择先出现的
- 自我偏好（Self-Preference） ：GPT-4 倾向于给 GPT-4 生成的答案更高分
- 长度偏差（Verbosity Bias ） ：更长的回答倾向于获得更高评分
- 校准困难：LLM 评分的绝对值不稳定，不同 prompt 下评分分布差异很大
业界的缓解策略包括：
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 多轮投票 | 对同一样本多次评判，取多数票 | 高风险决策 |
| 成对比较 | 不打绝对分，只做 A vs B 比较 | 迭代优化对比 |
| 校准锚点 | 提供已知分数的参考示例 | 需要绝对分数时 |
| 分层评测 | 先用确定性规则过滤，再用 LLM 评价剩余 | 大规模评测 |
| 人机一致性验证 | 定期用人评校验 LLM Judge 的准确性 | 长期运行的评测流水线 |
Jason Wei（前 Google Brain）在其关于 LLM 评测的系列文章中提出了一个重要观点：LLM-as-Judge 的一致性（agreement）比准确性（accuracy）更重要——如果 LLM Judge 的评分在不同运行之间高度一致，即使与人类评分有系统性偏差，也可以通过校准来修正。
3.3 实践中的混合评测范式
成熟的 Agent 评测体系通常采用分层混合架构：
-
第一层：确定性检查（规则/ 断言 ）
- 格式正确性（JSON schema 验证）
- 工具调用参数合法性
- 安全护栏触发检测
- 延迟/成本阈值
-
第二层：半自动检查（启发式 + 简单 LLM）
- 关键信息提取准确率
- 步骤合理性打分
- 意图理解一致性
-
第三层：深度评测（强 LLM Judge）
- 开放性回答质量
- 多轮对话连贯性
- 复杂推理正确性
-
第四层：人工抽检（定期/触发式）
- LLM Judge 校准验证
- 边界 case 审查
- 用户满意度调研
Hamel Husain 在其博客中将这个理念提炼为一句话： "Start with assertions, graduate to LLM-as-Judge only when you must." （Your AI product needs evals）
四、从 Harness 到 Meta-Harness：评测工程的范式跃迁
4.1 什么是 Harness Engineering
在 Agent 评测领域，Harness 指的是将 Agent 放入其中运行和评测的测试环境 + 评测逻辑 + 反馈回路的整体框架。一个好的 harness 不仅仅是一个测试脚本，而是一个完整的工程系统，包括：
- 环境搭建：为 Agent 提供可控、可复现的执行环境
- 任务分发：向 Agent 发送标准化的任务指令
- 轨迹采集：记录 Agent 的每一步决策和工具调用
- 评分计算：根据预定义标准计算各维度得分
- 报告生成：输出结构化的评测报告
SWE-bench 的 harness 是一个典型案例：它为每个任务创建独立的 Docker 环境，安装对应版本的仓库依赖，运行 Agent 生成的补丁，然后执行测试套件来判定成败。
UK AI Safety Institute 开源的 Inspect AI 是目前最成熟的通用 Agent 评测 harness 框架之一，提供了标准化的任务定义、沙箱执行、评分和日志功能。
4.2 Meta-Harness：让评测系统自己进化
Meta-Harness 是 harness engineering 的下一个前沿。核心思想是：如果 Agent 可以自我改进，那评测系统本身也应该能够自我进化。
Meta-Harness 的概念包含几个层次：
第一层：评测驱动的 Agent 自动调优
DSPy 框架是这个方向的先驱。开发者声明 Agent 的输入输出签名和评测指标，DSPy 的编译器自动搜索最优的 prompt 和 few-shot 示例——本质上就是一个 meta-harness，用评测分数作为信号自动优化 Agent（DSPy: Compiling Declarative Language Model Calls into State-of-the-Art Pipelines）。
TextGrad 将这个思想推向更深处：它将 PyTorch 反向传播的范式迁移到文本领域，LLM 的文本反馈充当"梯度"，通过计算图反向传播来优化 Agent 的各个组件。实验表明，这种方法能让 GPT-4o 在 Google-Proof QA 上的零样本准确率从 51% 提升到 55%（TextGrad: Automatic "Differentiation" via Text）。
Microsoft 和 Stanford 联合开发的 Trace (OPTO) 框架更进一步，将 AI 系统的计算工作流视为一个类似神经网络的图，通过执行迹进行端到端优化，能同时优化 prompt、超参数、代码等异构参数（Trace is the Next AutoDiff）。
第二层：Agent 架构的自动设计
ADAS（Automated Design of Agentic Systems）代表了更激进的探索：让元 Agent 在代码空间中搜索最优的 Agent 架构。Meta Agent Search 算法从简单设计开始，根据评测结果迭代改进，最终自动发现了在多个领域超越人工设计的 Agent 架构（Automated Design of Agentic Systems）。
这预示着一个深刻的范式转变：Agent 的设计者不再是人类工程师，而是另一个 Agent，由评测指标驱动自动进化。
第三层：评测标准本身的自我进化
最前沿的探索是让评测标准和测试用例也能自动演化。HyperAgent 概念提出了一种闭环架构：Agent 的行为数据反馈到评测系统，评测系统自动识别能力短板、生成新的测试用例、调整评分权重，形成一个完全自治的改进循环。
4.3 Meta-Harness 的工程实现路径
将 meta-harness 落地需要几个关键的工程组件：
Meta-Harness 反馈循环：Agent 执行 → 轨迹采集 → 评测打分 → 优化器分析 → Agent 更新 → 再评测
核心模块包括：
- Eval Engine：评测引擎，对 Agent 输出进行多维度评分
- Optimizer（DSPy/TextGrad） ：优化器，根据评测分数自动调优 Agent 参数
- Test Case Evolver：测试用例演化器，自动生成新的测试用例
- Trace Store：轨迹存储，记录所有执行历史
- Env Sandbox：环境沙箱，提供隔离的执行环境
五、Agent 自迭代：从反思到经验积累
5.1 Reflexion：语言化的强化学习
Reflexion 提出了一个优雅的思路：用自然语言反思替代传统 RL 的权重更新。Agent 在任务上失败后，不是调整模型参数，而是生成一段文本反思（"我在第三步错误地调用了搜索 API，应该先确认用户意图"），将其存入情节记忆，下次遇到类似任务时读取这些反思来改进决策（Reflexion: Language Agents with Verbal Reinforcement Learning）。
实验结果令人印象深刻：GPT-4 + Reflexion 在 HumanEval 编程任务上达到 88% pass@1（提升 11%），在 AlfWorld 决策任务上超越基线 22%。
5.2 Voyager：技能库驱动的终身学习
NVIDIA 的 Voyager 是 Agent 自迭代领域的里程碑工作。它在 Minecraft 中实现了一个能够终身学习的 Agent，核心架构包含三个模块（Voyager: An Open-Ended Embodied Agent with Large Language Models）：
- 自动课程生成器：持续提出越来越复杂的目标
- 技能库（Skill Library） ：将成功的行为存储为可执行 JavaScript 代码，后续可检索复用
- 迭代式提示机制：整合环境反馈、执行错误、自我验证来持续改进代码生成
技能库是 Voyager 最有启发性的设计：代码比自然语言描述更精确可复用，而且技能库会随探索不断增长，实现了真正的"经验积累"。
5.3 ExpeL：从成功和失败中提取知识
ExpeL 提出了一种更结构化的经验学习方法：Agent 自主从训练任务中收集经验，用自然语言提取通用规则和教训，然后在新任务中检索相关经验来增强决策（ExpeL: LLM Agents Are Experiential Learners）。
与 Reflexion 的差异在于：ExpeL 不只是从失败中学习，而是同时从成功和失败中提取洞察，且支持跨任务的迁移学习。
5.4 从个体自迭代到系统级自进化
根据 A Survey of Self-Evolving Agents（TMLR 2026）的系统梳理，Agent 自进化已形成完整的分类体系：
| 进化维度 | 代表工作 | 核心机制 |
|---|---|---|
| 经验记忆 | Reflexion, ExpeL, SAGE | 从历史中提取和复用经验 |
| Prompt 优化 | DSPy, TextGrad, Trace | 自动搜索/生成最优 prompt |
| 工具创建 | Voyager, CREATOR, SkillWeaver | Agent 自己创建新工具/技能 |
| 工具选择 | AgentSquare, Darwin Godel Machine | 动态选择最优工具组合 |
| 架构进化 | ADAS, AFlow, AlphaEvolve | 自动设计 Agent 架构 |
一个值得注意的趋势是：这些进化维度正在从割裂走向融合。最新的框架（如 Trace/OPTO）试图在一个统一的优化框架中同时处理 prompt、代码、超参数和架构的优化。
六、Eval-Driven Development：评测驱动的 Agent 开发范式
6.1 EDDOps：评测作为持续的治理功能
University of Adelaide 和 CSIRO Data61 在 2024 年提出了 EDDOps（Evaluation-Driven Development and Operations） 方法论，将评测定位为贯穿 Agent 整个生命周期的持续治理功能，而非开发末期的检查站（EDDOps: Evaluation-Driven Development and Operations of LLM Agents）。
EDDOps 的核心架构包含两个循环：
- 离线循环（开发阶段） ：固定回归基线 → 自动执行评测 → 步级日志分析 → 切片标记（按任务类型/难度等维度分析） → 指导优化
- 在线循环（生产阶段） ：生产数据采样 → 在线评测 → 异常检测 → 触发重新开发
这种设计确保了评测不是一次性的，而是持续运行的反馈系统。
6.2 实践框架：Agent 的 TDD
借鉴软件工程中测试驱动开发（TDD）的理念，Agent 评测驱动开发的工作流如下：
Step 1: Eval-First — 在编写任何 Agent 逻辑之前，先定义评测套件。这包括：任务数据集（覆盖正常/边界/对抗性 case）、成功标准（各维度的通过阈值）、评测方法（确定性规则 + LLM Judge 的组合）。
Step 2: 最小化实现 — 用最简单的架构实现 Agent（通常是单 LLM + 基本工具），运行评测，建立基线 分数。
Step 3: 红灯驱动改进 — 分析评测失败的 case，定位问题根因（prompt 不清晰？工具缺失？推理不够？），逐一修复。每次只改一个变量，隔离效果。
Step 4: CI/CD ****门控 — 将评测集成到 CI/CD 流水线中，每次代码变更自动触发评测。分数低于阈值则阻止合并/部署。
Step 5: 持续扩展 — 将生产中发现的新失败 case 加入评测数据集，形成"飞轮效应"——Agent 越用越好，评测越来越全面。
6.3 工具链选型
当前 Agent 评测的工具链已趋于成熟：
| 工具 | 定位 | 核心能力 | 适用阶段 |
|---|---|---|---|
| Braintrust | 评测 + 可观测性平台 | 评分、对比、Canary 部署、prompt 管理 | 全生命周期 |
| LangSmith | LangChain 生态评测 | Trace 分析、评测集管理、A/B 测试 | 开发+生产 |
| Promptfoo | 开源评测框架 | YAML 配置、红队测试、CI/CD 集成 | 开发阶段 |
| Inspect AI | 通用 Agent 评测 | 沙箱执行、标准化评分、多 benchmark 支持 | 基准评测 |
| Arize Phoenix | 开源可观测性 | Trace 分析、评测、RAG 分析 | 生产监控 |
| DeepEval | 类 pytest 测试框架 | 单元测试、回归测试、Confident AI 集成 | 开发阶段 |
Braintrust 和 LangSmith 的差异化竞争值得关注：前者更强调评测与生产系统的无缝集成（Notion、Stripe、Vercel 等公司在用），后者则深度绑定 LangChain 生态，提供更丰富的 trace 分析能力。
七、Multi-Agent 系统的评测挑战
7.1 从模型评测到系统评测
多 Agent 系统的评测面临一个根本性问题：性能是整个系统的涌现属性，无法简单地分解为各个 Agent 的能力之和。
MASEval 的研究为此提供了清晰的框架：
三层评测架构：
- LLM 层：单个模型的基础能力（推理、工具使用、指令遵循）
- Agent 层：单个 Agent 的工具选择准确率、步级决策质量、成本效率
- 系统层：路由准确率、错误级联率、端到端任务完成率、协调效率
7.2 评测 Orchestrator
在多 Agent 系统中，Orchestrator 的质量直接决定了系统的上限。评测 Orchestrator 需要关注：
- 路由 准确率：是否将任务派遣到正确的专家 Agent
- 容错和恢复：子 Agent 失败时的处理能力
- 效率：是否在满足质量要求的前提下最小化 Agent 间通信开销
- 决策质量（DQ） ：多维度指标，捕捉有效性、具体性和正确性
Red Hat 的实践值得借鉴：他们维护了一个 known_bad_conversation_results 目录，包含各种已知失败模式的对话，用于持续验证 Orchestrator 是否能正确处理这些 edge case。
7.3 端到端 vs 模块化
最佳实践是两者结合：
- CI/CD 阶段：使用模块化评测快速迭代，每个 Agent 独立评测
- 预发布阶段：运行端到端评测确保系统级行为正确
- 生产阶段：在线端到端指标监控 + 定期模块化深度分析
八、社区争鸣与前沿观点
8.1 "Evals Are All You Need" vs "Evals Are a Scam"
Agent 评测领域正在经历一场有趣的"文化战争"。
一方面，"Evals are all you need" 的观点认为：在 Agent 开发中，评测体系的质量是唯一决定成败的因素。Anthropic 和 OpenAI 都明确站在这个阵营，将评测能力视为核心竞争力。
另一方面，AgentOps CEO 在其引发热议的文章 "Evals Are a Scam" 中指出：当前很多评测实践沦为了"表演性安全"——团队花大量时间搭建评测系统，但评测结果并不能真正反映 Agent 在生产环境中的表现。
Shreya Shankar 在 "In Defense of AI Evals" 中给出了一个更平衡的视角：评测本身不是目的，关键是评测能否驱动改进决策。如果评测结果不能指导你做出具体的改进行动，那这个评测就是无效的。
8.2 Vibes-Based vs Systematic
社区中还有一个持续的争论：在早期开发阶段，是应该依赖"直觉感受（vibes）"快速迭代，还是从一开始就建立系统化的评测？
务实的共识是：两者不矛盾，关键是时机。
- 探索阶段（0→1）：vibes-based 评测足够了，快速试错比精确测量更重要
- 优化阶段（1→N）：必须建立系统化评测，否则改进将失去方向
- 生产阶段：需要全自动化评测流水线 + 在线监控
Andrej Karpathy 在推文中分享过一个观点：他在评测 LLM 时会先大量手动查看输出（vibes），建立直觉后再设计系统化评测。这种"先定性再定量"的方法论对 Agent 评测同样适用。
8.3 面试中的评测问题
Agent 评测已成为 AI 工程师面试的核心考察点。典型的面试问题包括：
- 如何设计一个 Agent 的评测体系？从哪些维度出发？
- 给定一个 RAG Agent，如何定义和测量"答案质量"？
- 如何处理 Agent 评测中的非确定性问题？
- 如何在 CI/CD 中集成 Agent 评测？
- LLM-as-Judge 的局限性是什么？如何缓解？
- 如何评测一个多 Agent 系统中 Orchestrator 的质量？
这些问题考察的不是特定工具的使用，而是评测思维——对评测维度的理解、对权衡取舍的判断、对工程实践的认知。
九、方法论总结：Agent 评测最佳实践清单
基于以上调研，提炼出以下最佳实践：
9.1 评测设计原则
- Eval-First：在写 Agent 逻辑之前先定义评测。如果你无法定义什么是"好"，你就无法构建"好"的 Agent
- 分层评测：从确定性断言开始，逐步引入 LLM-as-Judge，人工抽检作为兜底
- 多维度：至少覆盖正确性、效率（延迟/成本）、安全性、用户满意度
- 过程+结果：结果评测定方向，过程评测找问题
- 可复现性：固定环境版本、固定随机种子（尽管 Agent 场景难以完全控制）
9.2 工程实践要点
- 固定回归 基线：维护一个"黄金数据集"，每次变更必跑
- 单变量迭代：每次只改一个参数，隔离效果
- 关注分布而非均值：看百分位数（P50/P95/P99），不要只看平均分
- CI/CD ****门控：评测不通过则阻止部署
- 生产反馈闭环：将生产中的失败 case 持续加入评测集
9.3 进阶策略
- 评测驱动优化：用 DSPy/TextGrad/Trace 让评测分数直接驱动 prompt/架构优化
- 元评测：定期评测你的评测——LLM Judge 是否还准确？测试数据集是否过时？
- 系统级思维：不要只评测模型，评测整个系统（包括框架、编排、工具链）
- 经验积累：建立 Skill Library / Experience Store，让 Agent 从历史中学习
- 渐进复杂度：从简单 Agent 开始，每一步复杂度增加都由评测数据支持
9.4 组织层面
- 评测文化：让评测成为团队的日常习惯，而不是发布前的突击检查
- 评测即文档：好的评测集本身就是 Agent 行为规范的最佳文档
- 投资评测基础设施：评测工具的 ROI 远超你的想象
十、展望：Agent 评测的未来
Agent 评测正在经历三个深刻的范式转变：
从静态 Benchmark 到动态评测环境：未来的评测不再是"做一张固定试卷"，而是在持续变化的环境中评估 Agent 的适应能力。
从人工设计到自动进化：Meta-Harness 的理念将逐步落地——评测标准、测试用例、评分函数都将由 AI 自动生成和迭代。人类的角色从"评测设计者"转变为"评测系统的监督者"。
从事后评测到在线优化：评测不再是开发流程的一个"阶段"，而是与 Agent 运行实时集成的持续优化信号。Trace/OPTO 这类框架预示了未来：Agent 在生产中运行时，评测系统同步收集反馈，优化器实时调整参数。
最终，最好的评测系统是你几乎不需要手动维护的那个——它自己生成测试用例，自己校准评分标准，自己发现 Agent 的能力短板，自己驱动改进。这不是科幻，DSPy + TextGrad + ADAS 的组合已经展示了这个方向的可行性。
第二章 怎么落地、快速见效——以 OpenClaw 为例
结合第一章的方法论以及 Anthropic Demystifying Evals for AI Agents 的实战建议，以下是一个四周路线图，适用于 OpenClaw 这类通用 Agent 的评测体系从零到一的落地。
一、Phase 0：第一周——快速建立评测基线（20-50 case 即可起步）
Anthropic 在 Demystifying Evals 中明确说了一个关键判断：不要等到有几百个 case 才开始，20-50 个从真实失败中提取的 case 就是一个很好的起点。早期 Agent 每次变更的效果都很大，小样本就够用（Demystifying evals for AI agents）。
具体动作：
| 步骤 | 做什么 | 产出 |
|---|---|---|
| 1. 收集失败 Case | 从已有的用户反馈/bug tracker/线上日志中，挑出 20-50 个典型失败场景 | eval_dataset_v1.jsonl |
| 2. 定义成功标准 | 每个 case 写清楚：输入是什么、期望结果是什么、用什么方式判定通过 | 明确的 grader 定义 |
| 3. 跑 基线 | 用当前的 OpenClaw 跑一遍，记录 pass rate 作为 baseline | 比如 baseline = 42% |
| 4. 分类打标 | 按失败原因分桶：推理错误 / 工具调用错误 / 环境问题 / prompt 不清晰 | 失败分布热力图 |
这一步的关键原则（来自 Anthropic 实战经验）：
"两个领域专家独立看同一个 case，应该能得出相同的 pass/fail 结论。" 如果不能，说明 case 定义有歧义，需要修改。0% pass@100 的 case 大概率是 case 本身有问题，而不是 Agent 不行。
二、Phase 1：第二周——搭建分层 Grader 体系
不要一上来就搞 LLM-as-Judge，按 Anthropic 的分层策略：
Layer 1: 确定性 Grader（优先建设，覆盖 60-70% 的评测需求）
- 结果状态校验：数据库/文件系统是否变更正确（state_check）
- 工具调用校验：是否调用了必要的工具、参数是否合法（tool_calls）
- 格式校验：输出是否符合 schema
- 安全护栏：是否触发了不该触发的操作
Layer 2: LLM-as-Judge（处理开放性输出）
- 按维度独立评分：每个维度用独立的 LLM Judge，不要一个 Judge 评所有维度
- 给 LLM 退路：允许返回 "Unknown"，避免幻觉
- 定期用人评校准
Layer 3: Transcript 分析（诊断用，不做门控）
- 步数 / token 用量 / 耗时
- 工具调用序列合理性
- 是否出现反复重试
一个重要的 Anthropic 教训：
不要检查 Agent 是否走了"正确的步骤序列"，只检查最终产出。 Agent 经常会找到评测设计者没想到的合理路径。过于严格的过程校验会惩罚创造性解法。"Grade what the agent produced, not the path it took."
三、Phase 2：第三周——接入 CI/CD + 建立调优飞轮
评测流水线：
PR 提交 → 触发评测 → 跑 eval_suite_v1（20-50 case）→ pass rate < baseline？→ 阻止合并 → pass rate ≥ baseline？→ 允许合并，记录分数趋势
调优策略（快速见效排序）：
| 优先级 | 调优手段 | 预期收益 | 成本 |
|---|---|---|---|
| P0 | 修 system prompt：把评测中发现的高频失败模式写成规则 | 5-15% 提升 | 半天 |
| P1 | 补充 few-shot examples：从成功 case 中挑典型的作为示例 | 3-10% 提升 | 1 天 |
| P2 | 工具描述优化：让工具的 description/schema 更清晰 | 2-8% 提升 | 1 天 |
| P3 | 用 DSPy 做自动 prompt 优化：声明评测指标，自动搜索最优 prompt | 5-20% 提升 | 3 天 |
| P4 | 错误恢复机制：Agent 调用工具失败后的 retry/fallback 策略 | 3-5% 提升 | 2 天 |
关键：单变量迭代。 每次只改一个东西，跑评测，看分数变化。不要同时改 prompt 又换模型又改工具。
四、Phase 3：第四周——区分 Capability Eval 和 Regression Eval
这是 Anthropic 文章中一个非常重要的概念区分：
| Capability Eval | Regression Eval | |
|---|---|---|
| 目的 | 发现 Agent 的能力边界 | 防止已有能力退化 |
| 初始 pass rate | 低（30-50%），给优化留空间 | 接近 100% |
| 何时用 | 开发阶段，hill-climbing | CI/CD 门控，每次变更必跑 |
| 毕业机制 | pass rate 稳定在高位后，"毕业"进入 regression suite | 持续运行 |
对 OpenClaw 的建议：第一周建的 50 个 case 中，先跑出 baseline。其中 pass rate 已经 >95% 的 case 直接归入 regression suite；剩下的作为 capability eval 来驱动改进。
五、快速见效的额外策略
5.1 非确定性处理
通用 Agent 输出天然不确定。Anthropic 推荐两个指标：
- pass@k：k 次尝试中至少成功 1 次的概率（衡量"能不能做到"）
- pass^k：k 次尝试全部成功的概率（衡量"能不能稳定做到"）
对 OpenClaw 这种通用 Agent，用户体验强相关的场景用 pass^3（连续 3 次都成功），工具调用类场景用 pass@1。
5.2 从生产日志挖掘评测数据
最高效的数据集构建方式。设一个 pipeline：用户反馈差评 → 自动提取 trace → 人工审核 → 加入 eval suite。这样评测集会自然反映真实分布。
5.3 对标打分而非绝对打分
LLM Judge 打绝对分不稳定，用 Pairwise Comparison（A/B 对比）替代。每次改完 prompt 后，跑新旧两个版本，让 Judge 选哪个更好。
第三章 Anthropic 落地实践与方法论
本章深入剖析 Anthropic 在 Claude Code 复杂能力（subagent、task system、team mode 等）评测上的一手实践。核心资料来源于 Anthropic 2026 年 1 月发布的 Demystifying Evals for AI Agents 和 Quantifying Infrastructure Noise in Agentic Coding Evals 两篇工程博客。
一、Claude Code 评测的整体架构
Anthropic 对 Claude Code 的评测是一个多层、渐进式的体系：
一、开发期评测（自动化 Eval）
- 窄域 eval：简洁性、文件编辑正确性
- 复杂行为 eval：过度工程化、工具选择合理性
- Coding benchmark：SWE-bench Verified, Terminal-Bench 2.0
- Capability vs Regression 分离
二、发布前验证
- A/B Testing（真实用户流量）
- 内部 dogfooding（Anthropic 员工日常使用）
- 系统化人工评估（校准 LLM Judge）
三、生产监控
- Production monitoring（实时指标）
- User feedback（thumbs up/down）
- Transcript sampling（定期人工抽检）
关键引述：
"Claude Code 最初靠 Anthropic 员工和外部用户的快速反馈迭代。后来才加入 eval——先是窄域（简洁性、文件编辑），再到复杂行为（过度工程化）。这些 eval 帮助定位问题、指导改进、聚焦研究和产品团队的协作。"（Demystifying evals for AI agents）
二、评测 Subagent / Task System 等抽象能力的方法
Claude Code 的 subagent、task system、team mode 等功能的评测，Anthropic 采用了按 Agent 类型分治的策略。从他们的公开资料可以提炼出以下方法论：
策略一：端到端任务评测 + Transcript 分析
对于 subagent（子代理在独立 context 中运行，回报摘要），核心评测逻辑是：
Grader 1: 结果正确性 — 最终代码是否工作（deterministic_tests）
Grader 2: subagent 行为检查 — 是否正确委派了子任务（tool_calls 检查）
Grader 3: context 效率 — 主 context 是否保持精简（transcript 断言，如 main_context_tokens < 50000）
Grader 4: 质量 rubric — 是否正确委派调研给 subagent，同时保持主对话干净（llm_rubric）
关键点：不检查 subagent 内部的执行路径，只检查：
- 最终结果是否正确
- 是否触发了 subagent 机制
- 主 context 是否因此保持了更好的"卫生状态"
策略二：双向平衡评测（Balanced Problem Sets）
这是 Anthropic 反复强调的核心教训，直接来自 Claude.ai web search 的评测经验：
"单向评测 → 单向优化。" 如果你只测 Agent 应该用 subagent 的场景，你会得到一个动不动就派 subagent 的 Agent。必须同时测"应该用 subagent"和"不应该用 subagent"的场景。
对 OpenClaw 的启示：
| 评测维度 | 正例（应触发） | 反例（不应触发） |
|---|---|---|
| Subagent 委派 | 需要读大量文件做调研 | 简单的单文件修改 |
| 多 Agent 协作 | Writer/Reviewer 需要分离的场景 | 单次问答，无需协作 |
| 工具调用 | 明确需要搜索/计算/文件操作 | 可以直接从已有知识回答 |
策略三：基础设施噪声控制
这是 Anthropic 最新的、非常独到的贡献。他们在 Infrastructure Noise 一文中证明了：基础设施配置（CPU/RAM/时间限制）本身可以导致 benchmark 分数波动 6 个百分点——有时比模型间的排行榜差距还大（Quantifying infrastructure noise in agentic coding evals）。
核心发现：
- 在 Terminal-Bench 2.0 上，严格资源限制（1x）vs 不限制（uncapped）的分数差距达 6 个百分点（p < 0.01）
- 3x 以内的资源放宽主要减少了基础设施错误（5.8% → 2.1%），不改变评测难度
- 3x 以上的资源放宽开始实质性降低评测难度（Agent 可以用暴力策略）
- 甚至时间段都有影响——API 延迟随流量波动，pass rate 随之变化
对 OpenClaw 的直接启示：
- 评测环境必须标准化：为每个 task 定义资源的 floor 和 ceiling
- 每次评测的 trial 要隔离：清理上下文、重置环境，避免 Agent 利用之前 trial 的残留信息
- 3 个百分点以内的分数差异要持怀疑态度——可能是噪声而非真实能力差异
策略四：Capability → Regression 毕业机制
Anthropic 内部对 Claude Code 的 eval 实行毕业制度：
Capability eval（pass rate 从低爬高）
↓ pass rate 稳定在高位
Regression eval（pass rate 应始终接近 100%）
↓ 分数下降
触发调查：是 Agent 退化了还是 eval 环境变了？
他们在 SWE-bench Verified 上的经验：从一年前的 ~40% 到现在 >80%，已接近"毕业"——eval 饱和后需要创建更难的新 eval 才能继续驱动改进。
策略五：研究-产品团队的评测协作模式
Anthropic 最终采用的组织架构是：
专门的 Evals Team 拥有核心基础设施，领域专家和产品团队贡献具体的 eval task 并自己运行评测。
他们甚至鼓励 PM、CSM、销售人员用 Claude Code 来提交 eval task 的 PR。让离用户最近的人定义"好"的标准。
三、可直接借鉴的 8 步 Eval Roadmap
Anthropic 在文章中给出了一个完整的 roadmap，以下按 OpenClaw 的场景做了适配：
| 步骤 | Anthropic 原始建议 | 适配 OpenClaw |
|---|---|---|
| Step 0: Start early | 20-50 case 即可，不要等 | 第一周就从线上 bad case 里凑够 30 个 |
| Step 1: Start with manual checks | 把你手动验证的东西自动化 | 把开发时每次手动检查的行为写成 grader |
| Step 2: Unambiguous tasks | 两个专家应独立得出相同判定 | 让两个同事分别标注同一组 case，不一致的要修改 |
| Step 3: Balanced sets | 正例+反例都要有 | 每个能力维度都写"应触发"和"不应触发"的 case |
| Step 4: Stable environment | 每次 trial 从干净环境开始 | Docker 隔离 + 环境重置 + 资源标准化 |
| Step 5: Thoughtful graders | 确定性优先，LLM 辅助，partial credit | 先建 state_check + tool_calls grader，再补 LLM rubric |
| Step 6: Read transcripts | "Read the transcripts!" | 每周花 2 小时人工阅读失败 case 的完整 trace |
| Step 7: Monitor saturation | 接近 100% 的 eval 不再提供改进信号 | 定期检查哪些 case 已"毕业"，补充更难的新 case |
| Step 8: Open contribution | 让全团队都能贡献 eval task | 建立一个简单的 case 提交流程，降低门槛 |
四、评测方法的 Swiss Cheese Model
Anthropic 用安全工程的"瑞士奶酪模型"来描述评测方法的互补关系——没有单一方法能 catch 所有问题：
| 方法 | 优势 | 劣势 | 适用阶段 |
|---|---|---|---|
| 自动化 Eval | 快、可复现、可 CI/CD | 需要前期投入、可能与真实用法脱节 | 每次 PR |
| Production Monitoring | 反映真实用户行为 | 被动、问题已到用户 | 上线后持续 |
| A/B Testing | 控制变量、测量真实影响 | 慢、需要足够流量 | 重大版本变更 |
| User Feedback | 发现意料之外的问题 | 稀疏、有偏 | 持续收集 |
| Manual Transcript Review | 建立直觉、发现微妙质量问题 | 不可扩展 | 每周定期 |
| Systematic Human Study | 金标准 | 贵、慢 | 校准 LLM Judge |
参考资料
- Anthropic, "Building effective agents": www.anthropic.com/research/bu…
- Anthropic, "Demystifying evals for AI agents": www.anthropic.com/engineering…
- Anthropic, "Quantifying infrastructure noise in agentic coding evals": www.anthropic.com/engineering…
- OpenAI, "New tools for building agents": openai.com/index/new-t…
- SWE-bench: arxiv.org/abs/2310.06…
- WebArena: arxiv.org/abs/2307.13…
- GAIA: arxiv.org/abs/2311.12…
- MLE-bench: arxiv.org/abs/2410.07…
- AgentBench: arxiv.org/abs/2308.03…
- MASEval: arxiv.org/abs/2603.08…
- Hamel Husain, "Your AI product needs evals": hamel.dev/blog/posts/…
- DSPy: arxiv.org/abs/2310.03…
- TextGrad: arxiv.org/abs/2406.07…
- Trace/OPTO: proceedings.neurips.cc/paper_files…
- ADAS: arxiv.org/abs/2408.08…
- Reflexion: arxiv.org/abs/2303.11…
- Voyager: voyager.minedojo.org/
- ExpeL: arxiv.org/abs/2308.10…
- EDDOps: arxiv.org/abs/2411.13…
