# Agent 评估方法论与可观测性：从直觉到工程化的质量保障体系

## 概述

Agent 系统的评估（evaluation）正在经历从"事后补充"到"核心基础设施"的认知升级。与传统软件测试不同，agent 的非确定性行为、对运行环境的深度依赖、以及 benchmark 与生产环境之间的巨大鸿沟，使得评估成为一个独特且复杂的工程挑战。

本文综合七篇来自 OpenAI、Anthropic、LangChain 和 OpenHands 的技术文章，覆盖以下核心问题：如何系统化地评估 agent 技能？如何处理评估的非确定性？基础设施噪声如何扭曲 benchmark 分数？深度 agent 评估有哪些特殊挑战？harness 工程如何通过评估驱动实现巨大性能提升？以及如何构建面向生产环境的 AI 代码验证体系？

## Agent 技能评估：从定义到验证的系统化框架

Agent 技能（skill）评估的核心挑战在于：**添加 skill 并不总是提升表现**。OpenHands 的实证研究揭示了一个被广泛忽视的事实——某些 skill 实际上会降低 agent 的表现 [^28]。在三个案例研究中，Dependency Audit 任务的 skill 是变革性的（0% → 100%），Financial Report Extraction 的 skill 是安全网（90% → 100%），而 Sales Pivot Analysis 则展示了最复杂的情况：效果因模型而异，某些模型在没有 skill 时表现反而更好。

这一发现意味着每个 skill 都需要严格的 A/B 评估，包含无 skill 的基线对照（No-Skill Baseline）。OpenHands 提出的评估三要素——Bounded Task（有界任务）、Deterministic Verifier（确定性验证器）和 No-Skill Baseline——为 skill 评估提供了最小可行框架 [^28]。

OpenAI 则从实践角度提供了更细粒度的 8 步框架 [^27]。其核心理念是"先定义再构建"——在实现 skill 之前，先确定四个维度的成功标准：outcome goals（任务完成）、process goals（正确的工具调用序列）、style goals（输出规范）和 efficiency goals（最小化不必要操作）。评估方法分为两个层次：**确定性检查**通过解析 JSONL event stream 验证具体行为（如"agent 是否执行了 `npm install`"），**定性评估**则利用 model-assisted evaluation 对代码风格、架构模式等主观要素打分。

两篇文章的方法论互补性很强：OpenAI 侧重"如何构建和评估单个 skill"，OpenHands 侧重"如何验证 skill 是否真的有价值" [^27][^28]。

## 从小处开始：10-20 个测试用例的务实策略

多篇文章不约而同地强调了**从小规模开始**的实践原则。OpenAI 建议从 10-20 条 prompt 的测试集起步，包含显式触发、隐式触发、上下文变体和负样本四类场景 [^27]。Anthropic 建议用 20-50 个基于真实失败案例的简单任务启动 [^29]。Anthropic 的多 agent 研究团队更是直接表示"从约 20 个代表性查询开始，早期变更往往产生巨大效果" [^35]。

这种共识的背后有深刻的工程逻辑：agent eval 的成本远高于传统单元测试（每次运行涉及多次 LLM 调用、工具执行和环境搭建），大规模测试套件的维护成本也远超一般软件项目。更重要的是，小规模但精心设计的测试集往往能捕获大部分关键回归——前提是测试用例来源于**真实的生产失败案例**，而非凭空想象。

Anthropic 提出的 eval 生命周期管理进一步完善了这一策略：capability eval 衡量 agent 能完成什么新任务（pass rate 从低开始上升），当达到 100% 时应转化为 regression suite，确保已掌握任务的持续一致性 [^29]。

## 非确定性指标：pass@k 与 pass^k

Agent 评估面临传统软件测试不存在的独特挑战——**非确定性**。同一个 agent 在同一任务上的多次运行可能产生不同结果。Anthropic 引入了两个关键指标来量化这种非确定性 [^29]：

- **pass@k**：k 次尝试中至少一次成功的概率，随 k 增加而上升。它回答的问题是"这个 agent 有没有能力完成这个任务？"
- **pass^k**：k 次尝试全部成功的概率，随 k 增加而下降。它回答的问题是"这个 agent 能否可靠地完成这个任务？"

两个指标揭示系统的不同属性。一个 pass@5 = 95% 但 pass^5 = 20% 的 agent 意味着它几乎总能找到正确答案，但需要多次尝试才行——这种特征对于交互式使用可能是可接受的，但对于自动化流水线则是危险的。

OpenHands 的代码验证研究 [^33] 将这一理念推向了实际应用：通过 trajectory-level critic model 引导的 Best-of-N 选择策略，在 Best@8 时达到 73.8% 成功率（随机基线仅 57.9%），而 critic 引导的 early stopping 平均仅需 1.35 次尝试（随机需 8 次）。这实质上是在工程层面利用 pass@k 特性来弥补 pass^k 的不足。

## 基础设施噪声：6 个百分点背后的系统性偏差

Anthropic 的一项重要研究揭示了 agent benchmark 中一个被严重低估的问题：**基础设施配置对评估分数有显著且系统性的影响** [^30]。在 Terminal-Bench 2.0 上，保持模型、harness 和 task set 完全一致，仅改变资源配置（CPU、内存、带宽），分数差异最高达 6 个百分点。

研究发现了一个关键的 **3x 阈值效应**：在资源配置低于 3 倍规格时，额外资源主要修复可靠性问题（如瞬态内存尖峰导致的基础设施错误率从 5.8% 降至 0.5%）；超过 3 倍后，资源开始**主动赋能新的问题求解策略**——agent 可以安装重量级依赖、启动昂贵进程、运行内存密集型测试套件。

这意味着"模型能力"和"基础设施行为"之间的边界远比单一 benchmark 分数暗示的更加模糊。对于技术管理者而言，这一发现有两个直接推论：（1）排行榜上低于 3 个百分点的差异可能反映的是硬件差异而非模型能力差异；（2）资源配置必须作为一等实验变量，与 prompt 格式和采样温度同等严格地记录 [^30]。

这一发现也为 OpenHands 观察到的 skill 效果不一致现象 [^28] 提供了另一个解释维度——基础设施差异可能是 skill 在不同环境下效果波动的隐性原因之一。

## 深度 Agent 评估的特殊挑战

LangChain 基于四个实际 agent 应用的开发经验，总结了深度 agent 评估的独特难点 [^31]。最核心的洞见是：**深度 agent 的评估不能套用传统 LLM 评估的统一逻辑**。传统 eval 对整个数据集使用相同的评估逻辑，但深度 agent 的成功标准因测试用例而异——一个日历调度 agent 的评估需要同时验证特定的 tool call、用户通信和文件内容准确性，这些检查逻辑无法泛化为统一模板。

LangChain 为此提出了 **"bespoke test logic per datapoint"**（按数据点定制测试逻辑）的理念，并在三个粒度层次上实施 [^31]：

1. **Single-step evaluation**：验证 agent 在特定场景下的单次决策（工具选择和参数生成），效率最高。约一半测试用例使用此粒度即可。
2. **Full turn evaluation**：揭示端到端行为，覆盖 trajectory（工具调用序列）、final response（最终输出质量）和 state（生成的 artifact）三个维度。
3. **Multi-turn evaluation**：模拟用户对话，需要条件逻辑在每步之后动态调整，避免 agent 偏离预期路径后后续输入变得无意义。

环境隔离是可重复性的关键保障——编码 agent 使用临时目录，Docker 容器化沙盒，以及通过 VCR 或 Hono proxy 模拟外部 API 请求 [^31]。这一实践与基础设施噪声研究 [^30] 形成了呼应：隔离的测试环境正是控制噪声的关键手段。

## Harness 工程对评估分数的实际影响

LangChain 的 harness engineering 实践提供了迄今最有说服力的证据：**在底层模型不变的情况下，仅通过优化 harness 就能实现巨大的性能提升**——从 Terminal Bench 2.0 的 52.8% 到 66.5%，排名从第 30 名跃升至第 5 名 [^32]。

五个关键改进展示了 harness engineering 的具体杠杆：

- **Build-and-Self-Verify Loop**：agent 最常见的失败模式是"写完代码、目视确认、然后停止"。通过 PreCompletionChecklistMiddleware 在退出前强制执行验证，大幅提升完成率。
- **Environmental Context Injection**：主动注入目录结构、可用工具、测试标准和时间预算等上下文，减少盲目探索。
- **Doom Loop Detection**：追踪每个文件的编辑次数，在过度编辑时建议 agent 重新考虑方法。
- **Reasoning Sandwich**：在规划和验证阶段使用高强度推理，在实现阶段降低推理强度，避免超时。
- **Model-Specific Tuning**：同一 harness 对不同模型效果不同，需按模型迭代优化。

这些改进本质上都是 **context engineering** 的具体应用——通过精心设计 agent 的上下文（系统 prompt、工具描述、middleware 注入的信息）来引导其行为。13.7 个百分点的提升全部来自 harness 而非模型更换，这对"模型决定一切"的观点构成了有力反驳 [^32]。

## AI 生成代码的验证技术栈

OpenHands 的研究揭示了 AI 代码验证领域最令人警醒的发现：**仅在学术 benchmark 上训练的 critic model 在生产环境中的表现甚至不如随机猜测**（AUC ~0.45-0.48） [^33]。这一 benchmark-production gap 的根本原因是生产环境的成功信号更稀疏、更模糊。

为弥合这一鸿沟，OpenHands 构建了基于 trajectory-level critic 的验证栈，训练方法包含三个关键步骤：

1. **Segmentation**：将交互标准化为请求→动作→完成的片段
2. **Dense Supervision Through Rubrics**：24 个可从 trace 观察的特征（误解意图、不遵循指令、范围蔓延等），提供几乎 100% 的覆盖率
3. **Semi-Supervised Training**：结合稀疏的生产 outcome 信号和密集的 rubric 标注

一个关键发现是 **code survival**（代码存活率）是比 PR merge 更好的生产 outcome 代理指标——code survival 信号训练的 critic AUC 达 0.69，而 PR merge 信号仅达 0.58 [^33]。这暗示"代码被合并"和"代码真正有用"之间存在重要差异。

## 跨文章洞见

**共识模式：验证比生成更重要。** 从 LangChain 的 Build-and-Self-Verify Loop [^32]，到 OpenHands 的 verification stack [^33]，再到 Anthropic Agent SDK 将 Verify Work 嵌入核心循环 [^36]，所有文章都指向同一个结论：LLM 已经让代码生成变得廉价，真正的瓶颈在于验证。

**共识模式：从小规模起步。** OpenAI 建议 10-20 条 [^27]，Anthropic 建议 20-50 条 [^29]，多 agent 团队建议约 20 条 [^35]——行业正在收敛到一个共识：起步时几十个精心设计的测试用例远胜于数百个粗糙的用例。

**张力点：标准化 vs. 定制化。** Anthropic 致力于为行业提供统一的术语和分类框架 [^29]，而 LangChain 明确主张"bespoke test logic per datapoint" [^31]。这种张力揭示了 agent 评估的本质矛盾——既需要跨项目可比的标准化指标，又需要尊重每个任务独特性的定制化逻辑。

**隐性风险：benchmark 信仰的崩塌。** 基础设施噪声可造成 6 个百分点的分数差异 [^30]，benchmark 训练的 critic 在生产中不如随机 [^33]，skill 效果因模型和环境而异 [^28]——这三个发现共同动摇了对 benchmark 排行榜的盲目信任。

## 对技术管理者的建议

1. **将 eval 视为一等基础设施**，而非事后补充。在 agent 项目启动时就分配评估基础设施的预算和工程资源，参照 Anthropic 的"eval-driven development"模式 [^29]。

2. **从 20 个测试用例开始**，基于真实失败案例而非理论场景。随生产环境中的新失败模式有机增长，遵循 capability → regression 的生命周期管理 [^27][^29]。

3. **建立双层评估体系**：确定性检查验证基本行为正确性，model-assisted 评估覆盖主观质量维度。先实现前者，按需叠加后者 [^27][^29]。

4. **对 benchmark 排行榜保持审慎**。低于 3 个百分点的差异可能反映基础设施而非模型能力 [^30]。要求供应商提供完整的评估配置信息。

5. **优先投资 harness 工程**。13.7 个百分点的提升证明 harness 优化的 ROI 通常高于模型更换 [^32]。Self-verification、context injection 和 loop detection 是三个高优先级方向。

6. **为 AI 生成代码建立独立的验证层**。不要仅依赖 agent 的自我报告，考虑引入 trajectory-level critic 和 code survival 指标 [^33]。

7. **每个 skill 都需要 A/B 验证**。不要假设添加 skill 总能提升表现，在多个模型上测试，并定期重新评估已有 skill 的有效性 [^28]。

8. **记录并控制评估环境变量**。将资源配置（CPU、内存、网络）、模型版本、harness 配置和随机种子作为 eval 结果的必要附加信息 [^30]。

## 引用来源

- [^27]: [Testing Agent Skills Systematically with Evals (OpenAI)](../notes/27-openai-eval-skills.md)
- [^28]: [How to Evaluate Agent Skills (OpenHands)](../notes/28-openhands-evaluating-skills.md)
- [^29]: [Demystifying Evals for AI Agents (Anthropic)](../notes/29-anthropic-demystifying-evals.md)
- [^30]: [Quantifying Infrastructure Noise in Agentic Coding Evals (Anthropic)](../notes/30-anthropic-infrastructure-noise.md)
- [^31]: [Evaluating Deep Agents: Our Learnings (LangChain)](../notes/31-langchain-evaluating-deep-agents.md)
- [^32]: [Improving Deep Agents with Harness Engineering (LangChain)](../notes/32-langchain-improving-with-harness.md)
- [^33]: [Learning to Verify AI-Generated Code (OpenHands)](../notes/33-openhands-verify-ai-code.md)
- [^35]: [How We Built Our Multi-Agent Research System (Anthropic)](../notes/35-anthropic-multi-agent-research.md)
- [^36]: [Building Agents with the Claude Agent SDK (Anthropic)](../notes/36-anthropic-claude-agent-sdk.md)