自动化智能体评估的实证研究 An Empirical Study of Automating Agent Evaluation
用评估技能+六阶段流水线让 Claude 自动为任意 agent 生成可执行的评估代码
前置知识
LLM-as-a-Judge（LLM 评判）
用一个大语言模型作为裁判，对另一个模型（或 agent）的输出打分或分类。常见做法是构造一个 prompt，把待评估的输入/输出塞进去，让 judge 模型返回一个分数或 A/B 选择，例如 G-Eval 用 chain-of-thought 提升与人类评分的相关性。优势是可扩展、便宜；缺点是容易受 prompt 措辞、长度偏好影响，且单点决策不可解释。
EvalAgent 生成的评估代码里大量使用 LLM-as-Judge（GEval）。理解其能力边界和常见陷阱（关键词启发式 vs 语义评估）才能看懂本文的定性分析。
OpenTelemetry / OTEL Trace（执行轨迹）
OpenTelemetry 是一个跨语言的可观测性标准，它把一次 agent 运行记录成一棵 span 树，每个 span 包含 operation 名、起止时间、属性（key-value）、嵌套事件等。本文的 agent 跑完后会被 Traceloop 这种库自动埋点，导出 JSON 格式的 span 列表，存到 ./data/trace/ 供后续评估。
EvalAgent 的核心创新是「trace-based evaluation」——它从真实运行时数据里抽取出工具调用、错误恢复、决策序列等行为信号，而不是只看 agent 的最终输出文本。这跟只看代码或只看答案的传统评估有本质区别。
DeepEval 评估框架
一个开源的 LLM/Agent 评估库，提供 G-Eval、AnswerRelevancy 等内置指标和 BaseMetric 基类，让用户继承后实现 measure() / a_measure() 即可自定义指标。它内部用 LiteLLM 适配多种模型 provider（包括 AWS Bedrock），但需要正确的 "bedrock/" 前缀才能调通。
EvalAgent 默认用 DeepEval 实现 LLM-as-Judge 指标。本文 14/40 失败里有 9 个是 Sonnet 生成代码时没正确处理 DeepEval 的 async_mode，导致 measure 缺失对应的 a_measure 协程——理解这个细节能看懂失败分析章节。
Pairwise Comparison（成对比较）与 Thurstone 法则
不直接给评估对象打绝对分，而是每次拿 A、B 两个方案比较哪个更好。心理学里的 Thurstone 法则证明：在缺乏标定尺度的领域，相对判断比绝对打分更稳定、更易达成一致。LMArena 等就是这套思路。本文的 meta-evaluator 走 agentic 路线，可以读多个文件、跑 shell 工具做多步审查，而不只是单 prompt 给答案。
本文的 5 维度权重打分（URF 15%、MR 30%、CQC 25%、PQ 15%、PCA 15%）就是建立在 pairwise 基础上；理解为何「相对判断更可靠」能解释为什么需要 agentic meta-evaluator。
研究动机
随着 AI agent 进入代码生成、科学发现、金融分析等高风险场景，如何可靠地评估它们成为新的瓶颈。和 LLM 评估（看单轮输出质量）不同，agent 评估必须审视执行轨迹里的「推理步骤→工具调用→错误恢复→状态转移」整条行为链——只看最终答案不够，因为正确答案可能掩盖了错误的推理过程（Lightman 等人 2023 已论证），而失败输出也可能源自健壮的错误处理。当前业界普遍把评估逻辑硬编码到 agent 代码里（DeepEval、Langfuse 的常见做法），导致评估行为在开发环境和生产环境之间漂移。手工设计评估标准、为每个 agent 写埋点、逐条 trace 检查失败原因，代价高昂且需要领域专家。当用户拿着一个新 agent 问「帮我评估一下」时，方法论层面的能力几乎为零。
本文的目标是本文要解决的是「评估生成」（evaluation generation）问题：给定一个 agent 的源代码和执行轨迹，自动产出完整的评估制品——评估准则、可执行评估代码、可读的诊断报告。具体可量化目标有两个：第一，把端到端的评估成功率（Eval@1）从基线的 15–35% 提升到 60% 以上；第二，在 5 维度成对比较上拿到 80% 以上的胜-平率，并让人工专家 80% 以上的对比中偏好生成结果。
与已有工作不同的是，现有 LLM-as-a-Judge（Zheng 2023）和 agentic judge（Zhuge 2024、He 2025、Kim 2025）都把评估当作「已经知道评什么、给个分数」的下游任务，假设评估准则已经存在。本文识别的 gap 是更上游的——设计「该评什么、怎么评」。作者实证发现，仅靠强代码能力（Claude Code + Sonnet 4.5）直接生成评估代码，会出现三种系统性失败：指标膨胀（每个 agent 平均塞 12+ 个零散指标，偏好延迟分位数和 token 计数等运维指标）、代码过度工程化（生成的评估代码比必要的 2–3 倍长、分散在 5–7 个文件、引入过早抽象）、plan-code drift（计划里写得很漂亮的语义评分标准，实现时退化为关键词计数）。EvalAgent 的独特切入角度是：通用代码 agent 缺乏的不是写代码能力，而是评估领域的「领域知识」，因此通过 evaluation skills（程序化指令+可复用代码模板+动态 API 文档）把这种知识显式注入，而不是寄希望于模型自己悟出来。
核心方法
EvalAgent 的整体思路可以类比为「给一个资深评估工程师配一本操作手册」：通用 agent 已经会读代码、跑命令、写测试，但不知道「评估 agent」这个特定任务该用什么方法论、该踩哪些坑、该用哪些工具的当前 API。EvalAgent 把这些知识编码成一组「评估技能」（evaluation skills），并在一条 6 阶段流水线上按需加载——每个阶段只调入相关的技能片段，避免上下文膨胀。具体而言，流水线依次做评估规划（生成结构化 plan）、测试用例生成（JSONL）、agent 埋点（OTEL/Traceloop）、轨迹收集与处理、评估代码生成（DeepEval 集成）、报告输出。核心直觉是：与其让模型一次性 end-to-end 输出所有制品，不如用 skills 把每一步「该看什么、该写什么、该避免什么」先验化，同时用 Context7 在代码生成阶段实时拉取最新 API 文档，解决训练数据陈旧导致的 API 漂移。
EvalAgent 的核心创新是「把评估领域知识显式编码为可加载的 evaluation skills」，而不是依赖模型隐式学会。这与已有工作有本质区别：(1) 相比纯 LLM-as-Judge（Zheng 2023、Kim 2023），EvalAgent 不是「给定一个评分标准判分」，而是先生成评分标准——这是更上游、更难的任务；(2) 相比已有 agentic judge（Zhuge 2024、Chen 2025），EvalAgent 不是直接给 agent 行为打 verdict，而是动态生成「针对该 agent 的整套评估流水线」，包括指标定义、可执行代码、报告；(3) 相比已有 agent 评估框架（DeepEval、RAGAS、Langfuse）需要用户手工配置指标，EvalAgent 把「指标选择+代码实现+报告输出」全自动化。具体来说，skills 包含三类内容：程序化指令（如「先做最小可用版本、验证库 API 再写代码、严格按 plan 不超范围」）、可复用代码与模板（plan 模板、report 模板、OTEL 解析和 DeepEval 集成的代码模式）、动态资源（通过 Context7 拉取 DeepEval/LiteLLM/Bedrock 的最新签名）。消融实验（Table 9、Table 10）直接证明：去掉 skills，Eval@1 从 65% 跌到 30%；去掉 Context7，Sonnet 4.5 的 Eval@1 从 65% 跌到 20%，下降 45 个百分点。
方法步骤详情
EvalAgent 的 6 阶段流水线完整步骤如下，每一步只加载相关 skills，遵循 progressive disclosure 原则。**阶段 1 评估规划**：输入是 agent 源码、OTEL 轨迹、用户需求；操作是调用 planning skill 和 plan 模板，输出结构化 Markdown plan（包含 agent specification、2–4 个聚焦指标及评分 rubric、测试场景、技术栈）。**阶段 2 测试用例生成**：输入是阶段 1 的 plan；操作是按 plan 列出的场景合成 JSONL 测试集，每条含 test_id、scenario、query、description、expected_behavior；输出 test_cases.jsonl（该阶段可替换）。**阶段 3 agent 埋点**：输入是 agent 源码；操作是用 Traceloop.init 加几行 OTEL 埋点（Code 2 示例），disable_batch=True，导出到本地 4318 端口。**阶段 4 轨迹收集与处理**：输入是运行 agent 产生的 OTEL JSONL；操作是 trace processor 过滤出 traceloop.*/gen_ai.*/http.* 等 agent 相关 span，抽取 operation 名、输入/输出、提示/补全、工具元数据、耗时；输出紧凑的 per-trace JSON 制品。**阶段 5 评估代码生成**：输入是 plan + 抽取后的 trace；操作是调用 code generation skill（要求「先做最小可用版本、严格按 plan、避免过度工程」），结合 trace 解析和 DeepEval 集成的 code patterns，通过 Context7 拉取最新 API；输出三类制品——指标实现类（确定性检查 + LLM-as-Judge）、评估 orchestrator、依赖清单。Code Quality 约束：200–400 LOC、2–4 文件、无未用导入。**阶段 6 报告输出**：输入是评估运行结果；操作是按 report 模板填四段——执行摘要（测试规模/成功率/关键强弱项）、分指标分析、失败根因分析（含具体文件:行号引用）、优先级建议。EvalAgent 基于 Claude Code v2.1.92，骨干为 Sonnet 4.5，集成 DeepEval，实时查询 Context7。
技术新颖性
技术新颖性体现在三个层面。第一，**抽象层面**：把 evaluation generation（评估生成）和 evaluation judgment（评估判断）显式分开——前者更上游、要求设计能力，后者只要求判定能力。已有工作几乎都只做后者，本文首次把前者作为系统性问题处理。第二，**方法论层面**：evaluation skills 是一种「可重用的领域知识包」，把程序化指令+模板+代码 pattern+动态文档统一在同一抽象里，并通过 progressive disclosure 控制上下文。这比 prompt 工程（脆弱、不可复用）和微调（成本高、难更新）都更灵活。第三，**评测层面**：本文第一次为「评估自动化系统」建立 benchmark（AgentEvalBench：20 个真实 agent × 5 测试场景 × 2 类需求），并提出 Eval@1 指标——它比 Pass@1 更严格，要求代码不仅能跑，还要产出非平凡、有意义的评估结果（明确排除常量/全零指标、跑在 mock 数据上、把预测当 ground truth 这三种伪成功）。这给整个子领域提供了可复现的评估基座。
实验结果
核心实验围绕 2×2 因子设计（Haiku 4.5 / Sonnet 4.5 × 通用 / 具体需求）、4 个基线（B1 LLM-Singleturn、B2 Agent-Sourcecode、B3 Agent-Onestage、B4 Agent-Twostage）展开，全部跑在 AgentEvalBench 的 20 个 agent × 2 类需求 = 40 个评测对上。**主结果（Table 5）**：EvalAgent 在 5 维度成对比较上对所有基线、两种骨干都拿到 84–100% 的胜-平率；Eval@1 上 Sonnet 4.5 达到 65.0%（vs B4 30.0%、B3 35.0%、B2 60.0%、B1 17.5%），Haiku 4.5 达到 62.5%（vs B4 32.5%、B3 17.5%、B2 45.0%、B1 15.0%）。其中 B2（只看源码不看 trace）的 Eval@1 数字偏高（最高 60%）的原因被作者指出——它经常跑在 unit test stub 上而非真实 agent 行为，属于伪成功，**trace 才是真实质量的试金石**。**消融发现 1（Trace 价值，Table 7）**：B3 vs B2 的胜-平率 73–77%，Metric Relevance 维度最高 80%，说明 trace 让指标能评估「agent 实际干了什么」，但代价是 Eval@1 从 60% 降到 35%（解析复杂度）。**消融发现 2（Plan 的两面性，Table 8）**：无结构化的 plan-then-implement (B4) 反而输给 one-stage (B3)——B3 vs B4 胜-平率 73.8%，Sonnet 4.5 下 B4 产生 4.4× 更长的 plan、6.6× 更长的代码、却换来类似的 Eval@1。B4 靠更多异常处理避免了崩溃，但经常产出全零指标（trace 格式不匹配）。**消融发现 3（Skill 价值，Table 9）**：固定 prompt 要实现 k∈{1,3,5} 个指标，EvalAgent 在 5 指标时 Eval@1 升到 65%，B3 跌到 30%、B4 到 40%——多指标时共享 trace 解析被 factors out，失败概率不叠加。**消融发现 4（Context7 价值，Table 10）**：Sonnet 4.5 启用 Context7 后 Eval@1 从 20% 涨到 65%，绝对提升 45pp；Haiku 4.5 提升 15pp（62.5%→47.5%）。原因是缺少 Context7 时模型写出 `us.anthropic.claude-sonnet-4-...` 而非正确的 `bedrock/us.anthropic.claude-sonnet-4-...`，DeepEval 报缺 a_measure() 协程错。**定性发现（Table 11）**：EvalAgent 平均 289 LOC、2 文件、0 死代码；B1 694、B2 1068、B3 844、B4 1902（EvalAgent 的 2.4–6.6×）。基线 35–75% 的 agent 退化为关键词启发式（regex 数动词、硬编码词典），EvalAgent 仅 20%——它使用 GEval 做语义评估。B4 在 11/20 agent 上生成未被引用的 report_generator.py 等死代码文件，EvalAgent 在 19/20 agent 上严格维持 2 文件模式。**人类对齐（Table 3）**：3 位专家对 40 对评估对比做 blinded pairwise 评判，Fleiss' κ=0.923（几乎完美一致），79.5% 偏好 EvalAgent（10.5% 平，10.0% 偏 B4）；meta-evaluator (Opus 4.5) 与人类多数决的整体胜者一致率 97.5%（39/40），200 个维度级判断的一致率 75.0%（Gwet's AC1=0.687，Spearman ρ=0.617）。**元评估者一致性**：跨模型（Opus 4.5 vs Sonnet 4.5）一致率 86.6%；同一模型三次独立运行的三方一致率 76.3%、配对一致率 84.2%（远高于 33.3% 随机基线）。**失败分析（Table 12）**：Sonnet 4.5 失败 14 例里 9 例是 DeepEval async_mode 陷阱（生成的 measure 缺 a_measure 协程），代码结构本身都正确，手动设 async_mode=False 即可；Haiku 4.5 失败 15 例里 6 例是 Python API 误用（Path.ctime()、dict(os.stat()) 等）、5 例是时间戳字符串算术——表明小模型存在能力门槛。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| AgentEvalBench 整体成对比较（Sonnet 4.5 骨干） | Overall Win-Tie Rate | EvalAgent 自身（vs B4）：Overall 90.0%，MR 87.5%，CQC 92.5% | B4 Agent-Twostage：5 维胜-平 60.0/87.5/92.5/83.8/61.3% | 绝对提升 0–27.5pp，5 维平均提升约 13pp |
| AgentEvalBench 评估代码可执行性 | Eval@1 | Sonnet 4.5：65.0%（26/40）；Haiku 4.5：62.5%（25/40） | B4：30.0–32.5%；B3：17.5–35.0%；B2：45.0–60.0%；B1：15.0–17.5% | 相对最强基线 B2 的 60% 提升 5pp，但 B2 数字含伪成功；相对同架构 B4 提升 32.5–35pp |
| 人类专家偏好（盲评，n=40 对） | Prefer EvalAgent | 79.5%（ties 10.5%，baseline 10.0%） | Agent-Twostage (B4)：10.0% | 胜出近 8 倍，Fleiss' κ=0.923 证明专家间几乎完全一致 |
| 技能消融（Sonnet 4.5，5 指标复杂度） | Eval@1 | 65.0%（5 指标时反而上升） | B3 Onestage 30%；B4 Twostage 40% | 在 5 指标复杂度上比 B3 高 35pp、比 B4 高 25pp，且随指标数增加不退化 |
| Context7 动态文档消融 | Eval@1 | Sonnet 4.5 启用 Context7：65.0%；Haiku 4.5：62.5% | Sonnet 4.5 关闭 Context7：20.0%；Haiku 4.5：47.5% | Sonnet 绝对提升 +45pp，Haiku +15pp，是单一最强干预 |
| 代码体量（20 agent 平均） | LOC + 文件数 | 289 ± 67 LOC，2.0 ± 0.2 文件 | B1 694/3.4；B2 1068/5.1；B3 844/5.4；B4 1902/8.6 | 比 B4 少 6.6× 代码、4.3× 文件，且 0 死代码 vs B4 的 29 个死代码实例 |
| 评估策略质量 | LLM-as-Judge 占比（vs 关键词启发式） | 65% agent 仅用 LLM-as-Judge（13/20），20% 同时使用 | B1–B4 的关键词启发式占比 25–35% | 把语义评估的占比从 25–45% 拉到 65%，验证 skill 引导远离浅层启发式 |
| Meta-evaluator 跨模型一致性 | Case-level Agreement | Opus 4.5 vs Sonnet 4.5：86.6%；同模型三次运行三方一致：76.3%、配对：84.2% | 随机三选一基线 33.3% | 远高于随机基线 43pp+，证明 meta-evaluation 鲁棒不依赖具体模型 |
局限与改进
**作者承认的局限**：(1) 20 个 agent 仍可能没覆盖所有 agent 类型，特别是具身 agent、多模态 agent；(2) 所有实验都用 Claude 模型家族（Sonnet/Haiku/Opus），缺乏跨家族验证；(3) Eval@1 62.5–65.0% 意味着约 1/3 的生成评估仍需人工调试；(4) Meta-evaluation 本身主观性强，即使人类专家对 Plan Quality 的一致性也只到 Fleiss' κ=0.885、Plan-Code Alignment 0.700，比其他维度显著低。**我的额外观察**：(1) 失败分析（Table 12）显示 Sonnet 9/14 失败都是同一个 DeepEval async_mode 坑，作者估算「单修这一行 Eval@1 能到 87.5%」——这反过来暴露 EvalAgent 的 skills 还不完整，应当把「DeepEval 异步处理」做成强制 skill 而非留给模型自行处理；(2) AgentEvalBench 的 20 个 agent 平均 957 LOC、3.2 工具、145 事件（Table 2），但 adala_agent 高达 3900 LOC、9 工具、156 事件，最小的 ai_tic_tac_toe 只有 369 LOC——复杂度分布偏中等，可能不足以代表真实工业 agent；(3) B2 数字偏高是因为跑在 stub 数据上被 Eval@1 算为「成功」，这暴露 Eval@1 定义还需要把「使用真实 trace 数据」显式作为判据，否则会激励模型走捷径；(4) EvalAgent 自身基于 Claude Code 闭源系统，skills 模板细节也未完全公开（仓库只给了 D 节的 prompt 节选），可复现性受限。
独立分析的弱点
**弱点 1：Sonnet 9/14 失败集中在 DeepEval async_mode 这一个坑**——这是 skills 设计不够防御性的体现。改进方向：把 DeepEval 同步/异步处理封装成强制 skill（自动注入 `async_mode=False` 或自动补 a_measure 协程），作者估算单这一项修复就能把 Eval@1 从 65% 拉到 87.5%。**弱点 2：B2 跑在 unit test stub 上被 Eval@1 误判为「成功」**——当前 Eval@1 检查「能跑+非平凡输出」，但无法区分输出是来自 stub 数据还是真实 trace。改进方向：Eval@1 应额外要求 `actual_output` 字段非空且能溯源到 OTEL span 里的具体 gen_ai.* 事件，否则一律判失败。**弱点 3：人类对 Plan Quality 的一致性仅 0.885，Plan-Code Alignment 仅 0.700**——这两个维度的 rubric 描述偏抽象（Table 16、17），不同专家对「complete」「aligned」的理解差异大。改进方向：把 Plan Quality 拆成「结构完整度」（自动检查 section 是否齐全）+「指标可操作性」（每个 metric 是否给出具体 method 字段）；把 Plan-Code Alignment 改成结构化检查——为每个 plan 里声明的 metric 提取其名，然后在代码里做 AST 匹配，统计对齐率。**弱点 4：20 个 agent 的多样性仍有限**——没有具身 agent、纯语音 agent、agentic 搜索类 agent。改进方向：下一版加入 SWE-Bench 风格 coding agent、Mind2Web 风格 web agent、τ-bench 风格客户服务 agent，把跨领域泛化作为硬指标。**弱点 5：所有实验在 Claude 模型族上做**——当用户换用 GPT-5、Gemini、Qwen3-Coder 时，evaluation skills 是否同样有效未知。改进方向：在附录里加跨家族 1-shot 复现实验，并提供抽象 skill 接口让用户替换 DeepEval 集成代码。**弱点 6：6 阶段流水线是串行而非闭环**——生成的评估报告只交付给人类，不回流给 agent 做改进。改进方向：增加第 7 阶段「agent 改进建议闭环」，把报告里的优先级 P1 建议自动转成对 agent 源码的 patch。
未来方向
**作者提出的方向**：(1) 闭环迭代——让评估反馈直接驱动 agent 改进，而不只是产出报告；(2) 领域化 skill 库——为对话系统、具身 agent、coding assistant 各建一套 evaluation skills；(3) 更复杂的测试数据生成——从简单合成走向对抗性、组合式场景构造；(4) 通用 trace 格式标准——目前 OTEL 属性名各家 agent 不统一，需要 schema 收敛；(5) 扩充 AgentEvalBench 到 50–100 个 agent；(6) 更细致的 meta-evaluation 方法——Plan-Code Alignment 维度的人间一致性还有 0.700 的提升空间。**基于成果可延伸的方向**：(1) 把 EvalAgent 做成 IDE 插件，agent 作者写完代码后一键产出 CI 集成的 eval 套件；(2) 把 evaluation skills 与 Model Context Protocol 结合，让 skill 可以被任何 agent 框架（不只是 Claude Code）按需加载——这能避免对单一编程助手的依赖；(3) 用 EvalAgent 反向评估 EvalAgent 自己（即 self-meta-evaluation），看「自动评估一个评估系统」是否可行；(4) 结合 trajectory attribution（Code 15 已展示的 agent 归属）做多 agent 系统的归因评分，把贡献分配到具体子 agent；(5) 探索 evaluator-evaluator 网络——用 N 个不同的 meta-evaluator 取众数，进一步降低主观性。
复现评估
**开源情况**：代码与 AgentEvalBench 已开源在 https://github.com/awslabs/Agent-EvalKit（论文反复提到），包含 baseline 实现、skills 模板节选、prompt 示例。**数据资源**：AgentEvalBench 包含 20 个真实 agent（涵盖 LangChain、LangGraph、LlamaIndex、CrewAI、Strands、Agno、Adala、MCP/Bedrock、Custom 9 个框架、14 个应用域、3 个复杂度档），平均 957 LOC，每个 agent 配 5 个测试场景和 2 类评估需求。**算力需求**：EvalAgent 自身基于 Claude Sonnet 4.5，每次生成评估代码约 4 分钟、2,095K tokens（Table 5c），按 AWS Bedrock Sonnet 4.5 定价约 $1.94/case；20 agent × 2 需求 × 5 条件 ≈ 200 次生成 = ~$400/单次完整实验。Meta-evaluation 用 Opus 4.5 作为 judge 又是一笔费用。**复现难度**：中等偏难——主体框架已开源，但 (a) skills 完整 prompt 模板在 D 节只给了节选、完整版可能在仓库 README；(b) OTEL 轨迹的具体采集方式需要读者根据每个 agent 单独跑一遍 Traceloop；(c) baseline B1–B4 的 prompt 模板公开在 D.1，但 temperature、tool-call 限制（50 步）等超参需要仔细核对；(d) Context7 的接入和 license 状态需自确认。**实践建议**：先跑 `app/cli crawl` 类似流程抓一个 agent 的 trace，按 D 节提示配置 Claude Code + Context7，按 README 启动 EvalAgent；如果有 DeepEval 经验，10× 比对一次完整 pipeline 应该 1–2 天可走通。
论文图表
