五度妙笔
API商城
数据库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.mjsimport { 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 方案把 Best@8 从 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，而不是模型权重本身。
他们的结果也很有说服力。用同一个模型，只改 harness，deepagents-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 更开放，如果任务定义本身含糊，那后面的分数基本没有太大解释力。
第二点是他们对 pass@k 和 pass^k 的区分。Anthropic 提醒，pass@k 衡量的是多次尝试里至少成功一次的概率，适合“只要有一次撞对就值钱”的场景；而 pass^k 看的是多次尝试是否都能成功，更适合需要稳定一致性的产品。这个区分看似简单，其实特别关键，因为它直接决定了你在优化什么。如果一个团队嘴上说要做企业级稳定产品，最后却只盯着 pass@k，那指标和目标根本不是一回事。
更进一步，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 - OpenAI's concrete guide to turning agent traces into repeatable evals with JSONL logs and deterministic checks.
https://developers.openai.com/blog/eval-skills
2.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-skills
3.Agent evals - OpenAI's product guide for measuring agent quality with reproducible task-level and workflow-level evaluations.
https://developers.openai.com/api/docs/guides/agent-evals
4.Evaluation best practices - OpenAI's general guide to building eval suites that match real-world distributions and catch regressions early.
https://developers.openai.com/api/docs/guides/evaluation-best-practices
5.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-grading
6.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-code
7.Demystifying Evals for AI Agents - Anthropic's guidance on what to measure when agents have many possible trajectories to success or failure.
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
8.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 - LangChain's 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 - LangChain's evidence that harness changes alone can significantly improve benchmark performance.
https://blog.langchain.com/improving-deep-agents-with-harness-engineering/
