OpenAI、OpenHands、Anthropic、LangChain的智能体测评技术综述

我把 OpenAI、OpenHands、Anthropic、LangChain 关于 Agent Evals 的十篇文章系统看了一遍。看完以后一个非常明确的感受是Agent 的评测逻辑发生了转变。以前我们评模型核心问题是“答案对不对”现在评 Agent核心问题变成了“这个系统能不能稳定地做对事”。这里的“系统”不只是模型本身还包括skill、工具、路由、验证、运行环境以及整个执行闭环。OpenAI 在最新文档里已经把 traces、graders、datasets、eval runs 作为 Agent 评测的核心对象Anthropic 也明确把 Agent eval 拆成 task、trial、grader 三个层次来讨论。换句话说今天真正需要被评测的不是单次输出而是一个完整工作流。我自己的判断是这十篇文章虽然来自不同团队但最后收敛到了同一件事Agent 的竞争力越来越不是“模型会不会答”而是“系统能不能持续、稳定、可解释地完成任务”。OpenAI讲的是如何把评测平台化OpenHands讲的是如何把验证做成运行时能力Anthropic讲的是如何把评测这件事做得更科学LangChain讲的则是怎样通过 harness engineering 把模型能力真正压榨出来。它们看起来视角不同但其实是在回答同一个问题一个 Agent 到底怎样才能从 demo 走向可交付。为什么 Agent 评测已经从“辅助工作”变成“基础设施”OpenAI 在《Evaluation best practices》里讲得很直接生成式天然具有非确定性所以不能再靠几条单元测试或者人工体验来判断系统质量。真正有效的做法是尽早建立贴近真实任务分布的评测集合持续记录日志并且尽量让评测自动化、结构化、可重复。它强调的不是“最后验收时测一下”而是 eval-driven development也就是把评测前移到开发过程本身。这背后反映的是一个很现实的问题如果没有评测闭环Agent 的失败几乎都是模糊的。你只能感觉它“有时候不太行”但很难知道到底是 prompt 不稳、tool selection 出错、handoff 逻辑有问题还是验证环节根本没做好。OpenAI 在《Evaluate agent workflows》里因此给了一个很清晰的次序调试早期优先看 trace等知道什么叫“好”以后再把这些标准固化为 datasets 和 eval runs。这条顺序我觉得非常关键因为 trace 的作用是定位问题dataset 的作用才是重复比较。两者不能颠倒。Anthropic 的文章让我印象很深的一点是它把 eval 重新定义成了一种“测量设计”。他们并不把评测看成给模型打分而是认为要先界定清楚任务成功标准再跑多个 trial最后由 grader 做判断。对 Agent 来说这种思路尤其重要因为 Agent 不是一次性给答案它会多步执行、会分叉、会试错甚至有时候最终结果看起来正确过程却完全不可复用。也正因为如此仅看结果往往支撑不了后续优化。第一条主线从“黑盒结果评分”走向“轨迹级评测”我看完 OpenAI 的几篇文档以后最大的一个认识变化是Agent 评测的对象必须从结果扩展到轨迹。OpenAI 在《Trace grading》和《Evaluate agent workflows》里都在讲这件事。所谓 trace grading不再只是检查最终答案而是对一整条 agent trace 里的关键步骤打标签、打分判断它的决策、工具调用和执行路径是不是符合预期。这样做的意义不在于多拿一个分数而在于你终于知道“错在哪里”。这一点在《Testing Agent Skills Systematically with Evals》里有一个非常典型的原文代码示例。它不是上来就给模型输出打分而是先运行 agent把结构化事件流写成 JSONL再从 trace 里做确定性检查。原文代码如下// evals/run-setup-demo-app-evals.mjs import { spawnSync } from node:child_process; import { readFileSync, writeFileSync, existsSync, mkdirSync } from node:fs; import path from node:path; function runCodex(prompt, outJsonlPath){ const res spawnSync( codex, [ exec, --json, --full-auto, prompt, ], { encoding: utf8 } ); mkdirSync(path.dirname(outJsonlPath), { recursive: true }); writeFileSync(outJsonlPath, res.stdout, utf8); return { exitCode: res.status ?? 1, stderr: res.stderr }; } function parseJsonl(jsonlText){ return jsonlText .split(\n) .filter(Boolean) .map((line) JSON.parse(line)); } function checkRanNpmInstall(events){ return events.some( (e) (e.type item.started || e.type item.completed) e.item?.type command_execution typeof e.item?.command string e.item.command.includes(npm install) ); } function checkPackageJsonExists(projectDir){ return existsSync(path.join(projectDir, package.json)); }这段代码表面上是在做 skill eval实际上体现的正是 trace-first 的思路先把 agent 的执行过程结构化记录下来再去问它有没有执行关键命令、有没有生成关键产物。和传统“看最终输出像不像”相比这种方式最大的进步在于评测对象从文本变成了行为。换句话说Agent 的过程第一次真正变成了可以被程序验证的东西。我觉得这件事的工程意义很大。因为一旦你开始评轨迹而不是只评结果优化方向就会完全变掉。以前出错了只能继续改 prompt现在出错了可以明确判断是 planner 没想清楚、tool 选错了、命令没执行到位还是系统没有逼它做验证。也就是说trace grading 的价值不是让评测更复杂而是让优化终于有抓手。第二条主线Skill 不是天然增益必须和 baseline 对照评估看 OpenAI 和 OpenHands 这两组文章时我有一个很强的共同感受“给 Agent 加一个 skill”这件事并不天然等于“Agent 更强了”。OpenAI 在《Testing Agent Skills Systematically with Evals》里把 skill eval 抽象成一条很清楚的链路prompt → captured run → checks → score。也就是说skill 的价值不是靠直觉判断而是要回到可观察的执行过程和可验证的结果上。OpenHands 在《How to Evaluate Agent Skills》里把这个问题说得更直接。他们强调一个有意义的 skill eval 至少要有三样东西边界清晰的任务、确定性的 verifier以及 no-skill baseline。其中最容易被忽略的是 baseline。因为如果你只跑“加了 skill”的版本你永远不知道这个 skill 是真有帮助还是模型本来也能完成。更现实一点说很多看起来很聪明的 skill实际上会引入新的歧义和失败模式。OpenAI 那篇文章里给了一个很适合说明这个思路的结构化 rubric 示例。原文不是让模型自由发挥地“评价一下这个 repo”而是要求它严格按 JSON Schema 输出从而把原本模糊的风格和结构判断转换成可重复的结构化评分{ type: object, properties: { overall_pass: { type: boolean }, score: { type: integer, minimum: 0, maximum: 100 }, checks: { type: array, items: { type: object, properties: { id: { type: string }, pass: { type: boolean }, notes: { type: string } }, required: [id, pass, notes], additionalProperties: false } } }, required: [overall_pass, score, checks], additionalProperties: false }紧接着它再通过一条命令把 repo 按这个 schema 做只读式评估codex exec \ Evaluate the demo-app repository against these requirements: - Vite React TypeScript project exists - Tailwind is configured via tailwindcss/vite and CSS imports tailwindcss - src/components contains Header.tsx and Card.tsx - Components are functional and styled with Tailwind utility classes (no CSS modules) Return a rubric result as JSON with check ids: vite, tailwind, structure, style. \ --output-schema ./evals/style-rubric.schema.json \ -o ./evals/artifacts/test-01.style.json这两段内容让我觉得特别有代表性因为它们展示的不是“怎么多写一点测试”而是另一种评测思路先把要求拆成一组明确检查项再要求模型按结构化格式返回评分结果。这样一来评测就不再停留在“感觉不错”而是可以直接进入比较、回归和迭代。OpenHands 的实证结果也支持这一点。他们在安全扫描任务里观察到改进后的 skill 可以把 pass rate 从 0/10 提高到 10/10同时把平均运行时长从 266 秒缩短到 109 秒。这个结果很说明问题真正高价值的 skill不是让模型“多知道一点”而是让它更稳定地走进一条正确的工作流。第三条主线评测正在前移成“验证栈”critic 开始成为系统部件如果说前面两条主线讲的还是“运行完以后怎么评”那 OpenHands 在《Learning to Verify AI-Generated Code》里讲的已经是下一步了验证不该只是收尾动作而应该成为运行时能力。他们提出 verification stack 的核心不是多加几个测试而是引入一个小而快的 trajectory-level critic对整条 agent 轨迹做判断然后把这个判断直接用于 reranking、early stopping 和 iterative refinement。我觉得这篇文章最有价值的地方不只是提出 critic而是把训练 critic 的思路讲明白了。OpenHands 发现只在 benchmark 数据上训练 verifier迁移到真实生产轨迹时几乎没什么用真正有效的是用真实用户—agent 交互轨迹做训练再结合 PR merge、code survival 这类稀疏但真实的生产信号去对齐结果。这个结论其实很重要因为它说明 verifier 不是一个“实验室里看起来不错”的部件而是必须贴着真实工作流长出来。这篇文章没有放很长的 demo 脚本但它直接写到critic 已经被集成进 OpenHands Software Agent SDK可以在程序里调用分数把它接入自己的控制循环例如 reranking、early stopping、iterative refinement。这种写法本身就很说明问题验证已经不是线下打分器而是一个线上控制器。我自己的理解是这里发生了一个非常关键的范式转变以前我们默认“生成是主要能力验证只是附属能力”现在恰恰相反生成越来越便宜验证越来越值钱。因为当你可以很便宜地产生多个候选方案时系统真正需要的是快速判断哪一个更值得保留、什么时候该停、什么时候该继续修。OpenHands 在 SWE-bench Verified 的 mixed-outcome 子集上用 critic-guided 方案把 Best8 从 57.9% 提升到 73.8%同时把 early stopping 的平均尝试次数从 8.0 降到 1.35这基本已经把这个逻辑说明白了。第四条主线Harness Engineering 已经成为主要增益来源LangChain 那两篇文章给我的最大启发是很多时候Agent 的主要增益不来自换模型而来自改 harness。《Improving Deep Agents with harness engineering》开头就把 harness 讲得很透它的作用是把模型本身那种“有时候特别聪明、有时候特别飘”的能力塑造成对具体任务稳定有效的系统能力。这里优化的对象包括 system prompt、tool choice、execution flow、middleware而不是模型权重本身。他们的结果也很有说服力。用同一个模型只改 harnessdeepagents-cli 在 Terminal Bench 2.0 上就从 52.8 提升到了 66.5。这个结果对做产品的人其实很重要因为它几乎是在提醒我们如果系统层没搭好模型再强也会浪费掉。《Evaluating Deep Agents: Our Learnings》则从评测角度把这个问题讲清楚了。它认为Deep Agents 的评测不能再用“一个数据集 一个统一 evaluator”这种很薄的范式来做因为每个 datapoint 可能都需要更具体的测试逻辑。它更接近一种小型的端到端系统测试而不是传统单轮 LLM 打分。在具体工程做法上LangChain 文章里有两点很值得借鉴。第一是 Trace Analyzer Skill先从 LangSmith 拉 traces再让并行的错误分析 agents 去看这些 traces最后由主 agent 汇总出改 harness 的建议。第二是 Build Self-Verify他们发现模型其实会修 bug但它并不会自然进入 build-verify loop最常见的失败模式是“写完了自己看一眼觉得差不多就结束了”。所以他们在 harness 里显式加入规划、构建、验证、修复这样的过程约束。这一点我很认同。因为很多团队一说 Agent 优化第一反应就是调 prompt 或者换模型但 LangChain 的经验表明真正能把系统从“能跑”推到“能用”的往往是 harness engineering。也就是说模型决定了智能上限而 harness 决定了这部分智能究竟能释放出来多少。Anthropic 提醒的两个问题任务设计和基础设施噪声Anthropic 的两篇文章看完以后我觉得它们最重要的价值在于“降噪”。它不是教你多做一个技巧而是提醒你很多评测结论之所以不可靠不是因为模型太复杂而是因为评测本身没设计好。第一点是任务设计。Anthropic 认为一个好的任务不只是题目写清楚而是成功标准必须清楚到让两个领域专家独立来看也会得出大致一致的 pass/fail 判断。否则你最后测到的不是系统能力而是题目本身的歧义。这个判断我觉得特别重要因为 Agent 的任务往往比传统 benchmark 更开放如果任务定义本身含糊那后面的分数基本没有太大解释力。第二点是他们对 passk 和 pass^k 的区分。Anthropic 提醒passk 衡量的是多次尝试里至少成功一次的概率适合“只要有一次撞对就值钱”的场景而 pass^k 看的是多次尝试是否都能成功更适合需要稳定一致性的产品。这个区分看似简单其实特别关键因为它直接决定了你在优化什么。如果一个团队嘴上说要做企业级稳定产品最后却只盯着 passk那指标和目标根本不是一回事。更进一步Anthropic 在《Quantifying infrastructure noise in agentic coding evals》里指出基础设施配置本身就能让 agentic coding benchmark 波动数个百分点甚至可能超过头部模型之间的分差。这个结论我觉得应该成为做 Agent eval 的基本常识如果环境没有对齐很多“优化有效”的结论都不可信。在 Agent 场景里runtime environment 已经不是一个被动容器而是求解能力的一部分。我对这十篇文章的最终归纳把这十篇文章放在一起看我最后形成的理解其实很简单Agent 评测正在从“结果打分”走向“系统测量”。第一层当然还是结果层也就是最终答案、最终代码、最终状态是否正确。但这一层只能告诉我们系统有没有成功不能告诉我们为什么成功、为什么失败。第二层是轨迹层也就是 trace grading。到了这一层Agent 的工具调用、决策步骤、handoff 和验证动作都变成了可观察对象。系统第一次有能力把“过程”本身纳入评测。第三层是验证层也就是 OpenHands 的 critic 和 LangChain 的 self-verify loop。评测开始从离线分析转向运行时反馈verifier 不再只是裁判而开始参与控制系统行为。第四层是环境层也就是 Anthropic 一直提醒的基础设施一致性。如果这一层不稳上面三层的比较都可能失真。所以我的结论是今天真正值得投入建设的不再只是 prompt、benchmark 或者单次 demo而是一整套评测—验证—优化的工程飞轮。OpenAI 给了平台化路径OpenHands 给了 verifier 方向Anthropic 给了测量纪律LangChain 给了 harness engineering 的实践。把它们合起来看已经能形成一套相对完整的方法论先用 traces 找问题再用 datasets 和 graders 固化标准再把 verifier 接进运行时最后通过 harness engineering 把系统不断推向更稳定的状态。参考文献1.Testing Agent Skills Systematically with Evals - OpenAIs concrete guide to turning agent traces into repeatable evals with JSONL logs and deterministic checks.https://developers.openai.com/blog/eval-skills2.How to Evaluate Agent Skills (And Why You Should) - OpenHands hands-on playbook for measuring whether a skill actually helps using bounded tasks, deterministic verifiers, no-skill baselines, and trace review.https://openhands.dev/blog/evaluating-agent-skills3.Agent evals - OpenAIs product guide for measuring agent quality with reproducible task-level and workflow-level evaluations.https://developers.openai.com/api/docs/guides/agent-evals4.Evaluation best practices - OpenAIs general guide to building eval suites that match real-world distributions and catch regressions early.https://developers.openai.com/api/docs/guides/evaluation-best-practices5.Trace grading - OpenAI documentation on grading agent traces directly, which is especially helpful for long multi-step tasks.https://developers.openai.com/api/docs/guides/trace-grading6.Learning to Verify AI-Generated Code - OpenHands overview of a layered verification stack using trajectory critics trained on production traces for reranking, early stopping, and review-time quality control.https://openhands.dev/blog/20260305-learning-to-verify-ai-generated-code7.Demystifying Evals for AI Agents - Anthropics guidance on what to measure when agents have many possible trajectories to success or failure.https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents8.Quantifying infrastructure noise in agentic coding evals - Anthropic on how runtime configuration can move coding benchmark scores by more than many leaderboard gaps.https://blog.langchain.com/evaluating-deep-agents-our-learnings/9.Evaluating Deep Agents: Our Learnings - LangChains practical breakdown of single-step, full-run, and multi-turn eval design for stateful agents.https://blog.langchain.com/evaluating-deep-agents-our-learnings/10.Improving Deep Agents with harness engineering - LangChains evidence that harness changes alone can significantly improve benchmark performance.https://blog.langchain.com/improving-deep-agents-with-harness-engineering/