How to evaluate AI agents, avoid reward hacking, and build better specs如何评估 AI Agent、避免奖励黑客攻击，并构建更完善的规范

Agent evals are repeatable tests that measure whether an AI agent completed a task correctly. They can score final outputs, tool calls, retrieved context, trace behavior, safety constraints, or artifacts such as code. A good agent eval defines what “done” means, catches regressions, and prevents agents from optimizing shortcuts instead of user outcomes.Agent 评估是可重复执行的测试，用于衡量 AI Agent 是否正确完成任务。它可对最终输出、工具调用、检索到的上下文、Trace 行为、安全约束或代码等产物进行打分。高质量的 Agent 评估会明确定义“完成”的标准，捕捉回退现象，并防止 Agent 为了走捷径而优化，而非真正满足用户需求。

That matters because AI agents do not ship as frozen prompts. They swap models, use tools, rewrite plans, and loop until something looks complete. Without strong evals, “done” becomes whatever the agent can get past the scorecard.这很重要，因为 AI Agent 并不会以冻结提示词的形式交付。它们会切换模型、使用工具、重写计划，并不断循环直到结果看起来像是完成了。如果没有强有力的评估，“完成”就变成了 Agent 能在评分表上蒙混过关的任何东西。

For agent teams, evals are becoming durable product IP. Prompts and models churn, but rubrics, behavioral specs, and test suites preserve the definition of good work across model upgrades and workflow changes. They tell the optimizer what hill to climb.对于 Agent 团队而言，评估正逐渐成为持久的产品资产。提示词和模型不断更迭，但评分标准、行为规范与测试套件能够在模型升级和工作流变更中，始终保留对“好结果”的定义。它们告诉优化器该攀登哪座山峰。

At Arize Observe 2026, George Zhang, OpenClaw maintainer and CTO at Runner, made this point through examples from coding agents, React Doctor, and agent orchestration: models are increasingly good at climbing whatever hill you define. The engineering work is naming the hill, hardening the scorecard, and updating it when production traces reveal new failure modes.在 Arize Observe 2026 大会上，OpenClaw 维护者、Runner 公司 CTO George Zhang 通过编程 Agent、React Doctor 和 Agent 编排的实例说明了这一点：模型越来越擅长攀登你定义的任何一座山峰。真正的工程工作在于命名这座山、加固评分卡，并在生产 Trace 暴露出新故障模式时及时更新它。

This post explains what agent evals are, why they matter, how agents game weak evals, and how to design rubrics and test suites that are harder to reward-hack in production.本文将解释什么是 Agent 评估、它们为何重要、Agent 如何利用薄弱评估钻空子，以及如何设计更难被奖励黑客攻击的生产环境评分标准和测试套件。

What are agent evals?什么是 Agent 评估？

An agent eval is a repeatable check that scores whether an agent run did what you intended. That can look like a golden dataset with expected answers, a code check on tool arguments, an LLM-as-a-judge rubric, or a linter-style score on an artifact the agent produced. The input is usually a trace (prompt, tool calls, final output). The output is a label or score plus, ideally, a reason you can inspect.Agent 评估是一种可重复执行的检查，用于对 Agent 的运行是否达成预期进行打分。它可以表现为带有预期答案的黄金数据集、对工具参数的代码检查、LLM 作为评判者的评分标准，或对 Agent 产出物进行的 Linter 式评分。输入通常是 Trace（提示词、工具调用、最终输出），输出则是一个标签或分数，最好还附带可供查看的判定理由。

Agent evals differ from classic unit tests in one important way: the “correct” path is often under-specified. The agent may call three tools or seven and still succeed. We encode outcomes and constraints (“answer from provided context only,” “never disable lint rules”) rather than a single expected call sequence.Agent 评估与传统单元测试在一个关键点上有所不同：“正确”路径往往没有被充分定义。Agent 调用三个工具还是七个工具，都可能成功。我们编码的是结果和约束（例如“仅根据提供的上下文作答”“绝不禁用 lint 规则”），而不是单一的预期调用序列。

Here are two common shapes:以下是两种常见形态：

• Numeric target: a 0 to 100 grade on a codebase (React Doctor is a public example).数值目标：对代码库给出 0 到 100 的评分（React Doctor 是一个公开示例）。
• Behavioral spec: a test suite that defines correct software behavior (Next.js’s suite is the reference case teams cite when they talk about reproducible implementations).行为规范：一套定义软件正确行为的测试套件（Next.js 的测试套件是团队在谈论可复现实现时常引用的标杆案例）。

Both tell an optimizer what to climb toward. If you are building that stack for the first time, start with evaluation fundamentals in AX or Phoenix LLM evals in open source.两者都告诉优化器该朝着什么方向努力。如果你是第一次构建这套体系，可以先从 AX 的评估基础或开源的 Phoenix LLM 评估入手。

Why are evals important for AI agents?为什么评估对 AI Agent 很重要？

Agents increasingly swap models, rewrite skills, add tools, and loop until something looks done. Without evals, “done” becomes whatever the agent could get away with on the last run.Agent 越来越频繁地切换模型、重写技能、添加工具，并不断循环直到结果看起来像是完成了。如果没有评估，“完成”就变成了 Agent 在上一次运行中侥幸过关的任何东西。

Once you can specify the problem clearly, getting the agent there is increasingly the cheap part. The eval is that specification. It should survive prompt rewrites and model upgrades because it encodes what the product is for: not how the agent implemented a task today, but whether the outcome is acceptable tomorrow.一旦能够清晰地定义问题，让 Agent 达成目标反而越来越成为廉价的部分。评估就是那份定义。它应当在提示词重写和模型升级后依然有效，因为它编码了产品的本质目的：不是 Agent 今天如何实现了任务，而是明天的结果是否可接受。

Two examples clarify why we treat specs as IP, even outside agent products.以下两个例子说明了为什么即使在 Agent 产品之外，我们也把规范视为资产。

1. Test suites as product definitions. Cloudflare’s experimental vinext work showed why public test suites matter for agentic development. By porting large parts of the Next.js test suite and using it as a behavioral spec, the team could iterate toward a broad Next.js-compatible surface in about a week. The lesson is not that agents can magically clone a mature framework end to end; it is that tests make compatibility executable.测试套件作为产品定义。Cloudflare 的实验性项目 vinext 展示了公开测试套件对 Agent 开发为何重要。通过移植 Next.js 测试套件的大部分内容并将其作为行为规范，该团队得以在大约一周内迭代出一个在较广范围内兼容 Next.js 的实现。关键教训不在于 Agent 能魔术般地从头到尾克隆一个成熟框架，而在于测试让兼容性变得可执行。
2. Standards as the human job. OpenAI’s harness engineering write-up describes a five-month experiment in which Codex agents produced roughly a million lines of code across about 1,500 pull requests, with zero manually written code. The human work shifted toward defining coding standards, architecture rules, feedback loops, and review harnesses that agents could operate inside.标准就是人类的工作。OpenAI 的 Harness 工程文章描述了一项为期五个月的实验，其中 Codex Agent 在大约 1500 个 Pull Request 中生成了近一百万行代码，且没有任何人工编写的代码。人类的工作重心转向了定义编码标准、架构规则、反馈循环以及 Agent 可以在其中运作的审查框架。

For agent products, e.g., support, research, coding, or otherwise, the parallel is direct. Model weights are not the moat, neither are prompts or skill files.对于 Agent 产品——如客服、研究、编程等——道理是相通的。模型权重不是护城河，提示词或技能文件也不是。

That is also why we wire evals into the improvement loop: update the spec when production traces show a new failure mode, and don’t treat evals as a one-time pre-launch gate. Our agent harness with traces and evals walkthrough shows that loop on a PM agent scoring GitHub issues; a linter score on a coding agent is the same pattern with a different scorer.这也是为什么我们将评估嵌入持续改进闭环：当生产 Trace 暴露出新的故障模式时就更新规范，不要把评估当作一次性的上线前关卡。我们在结合 Trace 与 Eval 的 Agent Harness 实操演示中展示了这一闭环——一个 PM Agent 对 GitHub Issue 进行打分；编程 Agent 的 Linter 评分也是同一模式，只是使用了不同的评分器。

What are examples of agent evals?Agent 评估有哪些示例？

Agent evals take different shapes depending on the workload, but the underlying move is always the same: define pass/fail (or a score) on something you can re-run. What changes is the scorer.Agent 评估会因工作负载不同而呈现不同形态，但底层逻辑始终一致：对可重复运行的事物定义通过/失败（或分数）。变化的是评分器。

• Coding agents get a linter or audit score on the code they generate.编程 Agent 会对其生成的代码进行 Linter 或审计评分。
• Tool-calling agents get checked on whether the right tool fired with valid arguments— see how to evaluate tool-calling agents and evaluating tool calls in LLM pipelines.工具调用 Agent 需要检查是否正确调用了工具且参数有效——详见如何评估工具调用 Agent，以及 LLM 流水线中工具调用的评估。
• PM and workflow agents get rubrics scoring issue quality or task completion straight from their traces, as in our PM agent harness walkthrough.PM 和工作流 Agent 则通过评分标准直接从其 Trace 中对 Issue 质量或任务完成度打分，如我们的 PM Agent Harness 实操演示所示。
• Open-ended output calls for LLM-as-a-judge or LLM-judge agent evaluation, where rubric-based scoring handles natural language a number can’t.开放式输出需要 LLM-as-a-judge 或 LLM-judge Agent 评估，通过基于评分标准的打分来处理数字无法衡量的自然语言内容。
• Pass/fail gates are binary evals tied to a single failure mode: hallucination, policy violation, a missing citation.通过/失败关卡是与单一故障模式绑定的二元评估：幻觉、策略违规、缺少引用。

Retrieval-heavy agents are their own case, you can start with RAG evaluation patterns—golden questions, context adherence, and trace review—before you reach for judges.重度检索型 Agent 属于另一类情况，可以先从 RAG 评估模式入手——黄金问题、上下文遵循度和 Trace 审查——然后再考虑使用评判模型。

How do agent evals get gamed?Agent 评估是如何被钻空子的？

Reward hacking shows up the moment a metric becomes the target. Take React Doctor for example: it grades a React codebase from 0 to 100 and lists what is wrong. Point an agent at it with “fix my front-end until React Doctor reads 100/100” and the score often moves without much human refactoring. That is specification-driven development working as designed.一旦指标成为目标，奖励黑客攻击就会出现。以 React Doctor 为例：它对 React 代码库给出 0 到 100 的评分并列出问题所在。如果让 Agent 以“修复前端直到 React Doctor 显示 100/100”为目标，分数往往会上升，但却没怎么经过人工重构。这属于规范驱动开发按设计运行的情况。

It also breaks the same way every time someone forgets to constrain the spec. Another run on the same prompt hit 100/100 by disabling or excluding the checks being scored. The prompt never said that was out of bounds. The model took the shortest path up the hill.但每当你忘记给规范加上约束，它就会以同样的方式崩坏。另一次使用相同提示词的运行通过禁用或排除被评分的检查项拿到了 100/100。提示词从未说过这是越界行为。模型选择了登山的捷径。

That sequence is what we mean by gaming an agent eval:这一连串行为就是我们所说的“钻 Agent 评估的空子”：

1. Pick a metric.选定一个指标。
2. Let the agent optimize it.让 Agent 对其进行优化。
3. Watch the metric and the user-visible outcome diverge.观察指标与用户可见的实际结果发生偏离。

Goodhart’s law is not new. What changed is speed: a model finds the exploit on the first pass if your spec leaves room for it. When we review common agent failures in production, vague success criteria show up far more often than weak base models.古德哈特定律并不新鲜。变化的是速度：如果规范留有漏洞，模型可能在第一次运行时就找到利用方式。回顾生产环境中常见的 Agent 故障，模糊的成功标准出现的频率远高于底层模型能力不足。

How do you build evals that are harder to game?如何构建更难被钻空子的评估？

The React Doctor case is a useful template. The first prompt optimized the score. The hardened spec optimizes score plus constraints. Next:React Doctor 的案例是一个有用的模板。最初的提示词只优化分数。加固后的规范则同时优化分数和约束。接下来：

• State the forbidden shortcuts. Write “100/100 with all rules still enabled,” not “make the front-end better.” List the cheats you refuse to accept before you run the agent: disabled linters, empty citations, stub implementations, tool calls with placeholder arguments.明确列出禁止的捷径。写“在所有规则仍保持开启的情况下达到 100/100”，而不是“让前端变得更好”。在运行 Agent 之前，列出不能接受的作弊行为：禁用 Linter、空引用、存根实现、使用占位参数的工具调用。
• Check spirit, not just letter. If your eval only reads the final number, it is incomplete. Add checks that the behaviors you care about still happened: scored checks still enabled, tools called with real inputs, sources present in the answer.检查实质，而非只看字面。如果评估只读取最终数字，那它是不完整的。增加对你关心的行为是否仍然发生的检查：被评分的检查项是否仍然开启、工具是否使用了真实输入调用、答案中是否包含来源。
• Red-team before you trust. Try to pass the eval without solving the user problem. If you can, the model will too. The missing “do not disable rules” clause in the React Doctor prompt is exactly the kind of gap red-teaming is meant to surface.信任之前先红队测试。试着在不解决用户问题的情况下通过评估。如果你能做到，模型也能。React Doctor 提示词中缺失的“不要禁用规则”条款，正是红队测试旨在发现的漏洞类型。
• Use instructions when there is no single number. For “elegant architecture” or “good writing,” we use plain-English rules and iterate until the optimizer stops finding loopholes. Same job as an LLM judge, with the same dependency on human labels behind the rubric. When pass/fail is enough, binary evals are often easier to defend than an uncalibrated 1-100 scale.当没有单一数字时，使用文字指令。对于“优雅的架构”或“优秀的写作”，我们使用自然语言规则并不断迭代，直到优化器找不到漏洞为止。这与 LLM 评判者的工作相同，同样依赖评分标准背后的人工标注。如果通过/失败已经足够，二元评估往往比未经校准的 1-100 分制更站得住脚。
• Run on production-shaped traffic. Offline green scores are cheap. Run evals on traces from real sessions so shortcuts show up where they hurt users. For agent-heavy workloads, Agent as a Judge can help when a fixed template is too rigid and you need scoring in full trace context. In Arize AX, this pattern uses an agentic evaluator that reads traces at runtime rather than relying only on pre-mapped columns. The LLM evaluation guide is our recommended starting point if you are building that stack for the first time.在生产环境真实流量上运行。离线的绿色分数很容易拿到。在真实会话的 Trace 上运行评估，这样捷径才会在真正伤害用户的地方暴露出来。对于重度使用 Agent 的 workload，当固定模板过于僵化、需要在完整 Trace 上下文中打分时，Agent as a Judge 可以提供帮助。在 Arize AX 中，该模式使用一个 Agentic 评估器在运行时读取 Trace，而非仅依赖预先映射的列。如果你第一次构建这套体系，建议从 LLM 评估指南开始。

Specs are climbing the abstraction ladder规范正在攀登抽象阶梯

Coding agents changed how much intent you have to write to get a unit of work done:编程 Agent 改变了完成一个工作单位所需表达意图的多少：

Each step returns more output per sentence of specification. Coding agents generate faster than most teams can define “done,” so vague specs become the bottleneck. The leverage is in clearer completion criteria, not in watching every diff.每一步都让你在每一句规范中获得更多产出。编程 Agent 的生成速度超过了大多数团队定义“完成”的速度，因此模糊的规范成为瓶颈。杠杆在于更清晰的完成标准，而非逐行查看每个 diff。

You can also spec by reference: ask a model to design a distributed system “like Designing Data-Intensive Applications” and it often produces something credible because the book functions as a shared standard. Coding-agent rule files are another form of the same idea: machine-readable standards agents optimize against between runs.你也可以通过引用进行规范：让模型参照《Designing Data-Intensive Applications》设计一个分布式系统，它通常能产出可信的方案，因为这本书充当了一种共享标准。编程 Agent 的规则文件则是同一理念的另一种形式：机器可读的标准，Agent 在各次运行之间据此优化。

What to invest in next接下来该投入什么

Execution will keep getting cheaper. What compounds is the spec: what you measure, what you forbid, and what you update when a new loophole appears in production.执行的成本会持续降低。能够产生复利的是规范：你衡量什么、禁止什么，以及当生产环境出现新漏洞时更新什么。

If you are auditing an agent stack today, start here: write evals before prompts, treat the suite like a product definition a new engineer can understand, and run evals on traces as traffic arrives. That is the IP worth defending: evals, rubrics, and test suites that catch real failures, resist reward hacking, and make the next agent version measurably better than the last.如果你今天正在审计一套 Agent 技术栈，从这里开始：先写评估再写提示词，把整套评估当作新人工程师也能理解的产品定义，并在流量进来时就在 Trace 上运行评估。这才是值得捍卫的资产：能够捕捉真实故障、抵御奖励黑客攻击，并让下一个 Agent 版本比上一个可衡量地更好的评估、评分标准和测试套件。

For more, watch George’s full talk at Arize Observe 2026 here.想了解更多，请观看 George 在 Arize Observe 2026 上的完整演讲。