Demystifying evals for AI agents
- URL: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- Source: blog
- Author: Anthropic
- Local evidence: OpenClaw定时任务/ClawFeed24小时高价值一览/2026-07-23-ClawFeed24小时高价值一览.md
- Fetch method: opencli web read
- Added: 2026-07-23
中文摘要
Agent 评测难在多轮工具调用、状态修改和错误放大；单靠人工试用不够，量产后再补 eval 会进入“用户说变差了却无法验证”的盲飞。Anthropic 文章把 grader 分为 code、model、human 三类，并用 Claude Code、Descript、Bolt 的演进说明：早期靠 dogfood，上线后要用从窄场景到复杂行为的回归集来持续定位退化。
One-liner
Agent 评测不是上线后补救，而是把多轮行为退化变成可回归的工程系统。
Obsidian evidence excerpt
enCLI web read、Anthropic Engineering、StackOverflow Hot / arXiv 辅扫
- 验证状态：已落盘且非空
## 今日精选
本期从候选里只保留真正读过正文、评分超过 7 分的内容，偏 AI agent 评测、基础设施判断和工程密度高的文章。
1. 标题：Demystifying evals for AI agents
评分：8.9/10
推荐语：Anthropic 工程文把 agent eval 拆成可落地的词汇表和 grader 选型，而不是空谈“要有评测”。正文明确区分 task / trial / grader / transcript / outcome / evaluation harness / agent harness，并点出 Opus 4.5 在 τ2-bench 订票任务里钻政策空子“考砸了其实答对了”的静态 eval 失效案例。
摘要：Agent 评测难在多轮工具调用、状态修改和错误放大；单靠人工试用不行，量产后再补 eval 会进入“用户说变差了却无法验证”的盲飞。文章给出 code / model / human 三类 grader 的取舍，并用 Claude Code、Descript、Bolt 的演进说明：早期靠 dogfood，上线后要靠窄场景到复杂行为的回归集。
链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
2. 标题：Nobody knows what a used GPU cluster is worth
评分：8.8/10
推荐语：把 AI 基建融资讲到“抵押品会不会跟着运维团队一起走”这一层，数字扎实。引用 Meta Llama 3 训练中断统计：16,384 张 H100、54 天、419 次意外中断，其中 GPU 故障 148、HBM3 72；外推 20 万卡大约每天 50 次 GPU 故障。
摘要：GPU 债和飞机、船舶不同：面值、清算价、持续运营价是三套数，而持续运营价取决于拓扑知识、散热 quirk 和静默数据损坏处置能力，这些通常不在贷款合同可见范围。H100 租金从约 $8/h 掉到 $1.70 再反弹到 $2.35，CoreWeave 类 GPU 抵押贷相对基准约 +8.5pt，溢价就是“看不清风险”的价格。
链接：https://ciphertalk.substack.com/p/nobody-knows-what-a-used-gpu-cluster
3. 标题：Can a MUD evaluate LLMs?（CrucibleBench）
评分：8.7/10
推荐语：$99 的Fetched source / metadata
Demystifying evals for AI agents
作者: @AnthropicAI
原文链接: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
Introduction
Good evaluations help teams ship AI agents more confidently. Without them, it’s easy to get stuck in reactive loops—catching issues only in production, where fixing one failure creates others. Evals make problems and behavioral changes visible before they affect users, and their value compounds over the lifecycle of an agent.
As we described in Building effective agents, agents operate over many turns: calling tools, modifying state, and adapting based on intermediate results. These same capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them harder to evaluate.
Through our internal work and with customers at the frontier of agent development, we’ve learned how to design more rigorous and useful evals for agents. Here's what's worked across a range of agent architectures and use cases in real-world deployment.
The structure of an evaluation
An evaluation (“eval”) is a test for an AI system: give an AI an input, then apply grading logic to its output to measure success. In this post, we focus on automated evals that can be run during development without real users.
Single-turn evaluations are straightforward: a prompt, a response, and grading logic. For earlier LLMs, single-turn, non-agentic evals were the main evaluation method. As AI capabilities have advanced, multi-turn evaluations have become increasingly common.
In a simple eval, an agent processes a prompt, and a grader checks if the output matches expectations. For a more complex multi-turn eval, a coding agent receives tools, a task (building an MCP server in this case), and an environment, executes an "agent loop" (tool calls and reasoning), and updates the environment with the implementation. Grading then uses unit tests to verify the working MCP server.
Agent evaluations are even more complex. Agents use tools across many turns, modifying state in the environment and adapting as they go—which means mistakes can propagate and compound. Frontier models can also find creative solutions that surpass the limits of static evals. For instance, Opus 4.5 solved a 𝜏2-bench problem about booking a flight by discovering a loophole in the policy. It “failed” the evaluation as written, but actually came up with a better solution for the user.
When building agent evaluations, we use the following definitions:
- A task (a.k.a problem or test case) is a single test with defined inputs and success criteria.
- Each attempt at a task is a trial. Because model outputs vary between runs, we run multiple trials to produce more consistent results.
- A grader is logic that scores some aspect of the agent’s performance. A task can have multiple graders, each containing multiple assertions (sometimes called checks).
- A transcript (also called a trace or trajectory) is the complete record of a trial, including outputs, tool calls, reasoning, intermediate results, and any other interactions. For the Anthropic API, this is the full messages array at the end of an eval run - containing all the calls to the API and all of the returned responses during the evaluation.
- The outcome is the final state in the environment at the end of the trial. A flight-booking agent might say “Your flight has been booked” at the end of the transcript, but the outcome is whether a reservation exists in the environment’s SQL database.
- An evaluation harness is the infrastructure that runs evals end-to-end. It provides instructions and tools, runs tasks concurrently, records all the steps, grades outputs, and aggregates results.
- An agent harness (or scaffold) is the system that enables a model to act as an agent: it processes inputs, orchestrates tool calls, and returns results. When we evaluate “an agent,” we’re evaluating the harness _and_ the model working together. For example, Claude Code is a flexible agent harness, and we used its core primitives through the Agent SDK to build our long-running agent harness.
- An evaluation suite is a collection of tasks designed to measure specific capabilities or behaviors. Tasks in a suite typically share a broad goal. For instance, a customer support eval suite might test refunds, cancellations, and escalations.
Components of evaluations for agents.
Why build evaluations?
When teams first start building agents, they can get surprisingly far through a combination of manual testing, dogfooding, and intuition. More rigorous evaluation may even seem like overhead that slows down shipping. But after the early prototyping stages, once an agent is in production and has started scaling, building without evals starts to break down.
The breaking point often comes when users report the agent feels worse after changes, and the team is “flying blind” with no way to verify except to guess and check. Absent evals, debugging is reactive: wait for complaints, reproduce manually, fix the bug, and hope nothing else regressed. Teams can't distinguish real regressions from noise, automatically test changes against hundreds of scenarios before shipping, or measure improvements.
We’ve seen this progression play out many times. For instance, Claude Code started with fast iteration based on feedback from Anthropic employees and external users. Later, we added evals—first for narrow areas like concision and file edits, and then for more complex behaviors like over-engineering. These evals helped identify issues, guide improvements, and focus research-product collaborations. Combined with production monitoring, A/B tests, user research, and more, evals provide signals to continue improving Claude Code as it scales.
Writing evals is useful at any stage in the agent lifecycle. Early on, evals force product teams to specify what success means for the agent, while later they help uphold a consistent quality bar.
Descript’s agent helps users edit videos, so they built evals around three dimensions of a successful editing workflow: don’t break things, do what I asked, and do it well. They evolved from manual grading to LLM graders with criteria defined by the product team and periodic human calibration, and now regularly run two separate suites for quality benchmarking and regression testing. The Bolt AI team started building evals later, after they already had a widely used agent. In 3 months, they built an eval system that runs their agent and grades outputs with static analysis, uses browser agents to test apps, and employs LLM judges for behaviors like instruction following.
Some teams create evals at the start of development; others add them once at scale when evals become a bottleneck for improving the agent. Evals are especially useful at the start of agent development to explicitly encode expected behavior. Two engineers reading the same initial spec could come away with different interpretations on how the AI should handle edge cases. An eval suite resolves this ambiguity. Regardless of when they’re created, evals help accelerate development.
Evals also shape how quickly you can adopt new models. When more powerful models come out, teams without evals face weeks of testing while competitors with evals can quickly determine the model’s strengths, tune their prompts, and upgrade in days.
Once evals exist, you get baselines and regression tests for free: latency, token usage, cost per task, and error rates can be tracked on a static bank of tasks. Evals can also become the highest-bandwidth communication channel between product and research teams, defining metrics researchers can optimize against. Clearly, evals have wide-ranging benefits beyond tracking regressions and improvements. Their compounding value is easy to miss given that costs are visible upfront while benefits accumulate later.
How to evaluate AI agents
We see several common types of agents deployed at scale today, including coding agents, research agents, computer use agents, and conversational agents. Each type may be deployed across a wide variety of industries, but they can be evaluated using similar techniques. You don’t need to invent an evaluation from scratch. The sections below describe proven techniques for several agent types. Use these methods as a foundation, then extend them to your domain.
Types of graders for agents
Agent evaluations typically combine three types of graders: code-based, model-based, and human. Each grader evaluates some portion of either the transcript or the outcome. An essential component of effective evaluation design is to choose the right graders for the job.
Code-based graders
| Methods | Strengths | Weaknesses | | --- | --- | --- | | • String match checks (exact, regex, fuzzy, etc.) • Binary tests (fail-to-pass, pass-to-pass) • Static analysis (lint, type, security) • Outcome verification • Tool calls verification (tools used, parameters) • Transcript analysis (turns taken, token usage) | • Fast • Cheap • Objective • Reproducible • Easy to debug • Verify specific conditions | • Brittle to valid variations that don’t match expected patterns exactly • Lacking in nuance • Limited for evaluating some more subjective tasks |
Model-based graders
| Methods | Strengths | Weaknesses | | --- | --- | --- | |
- Rubric-based scoring
- Natural language assertions
- Pairwise comparison
- Reference-based evaluation
- Multi-judge consensus
|
- Flexible
- Scalable
- Captures nuance
- Handles open-ended tasks
- Handles freeform output
|
- Non-deterministic
- More expensive than code
- Requires calibration with human graders for accuracy
|
Human graders
| Methods | Strengths | Weaknesses | | --- | --- | --- | |
- SME review
- Crowdsourced judgment
- Spot-check sampling
- A/B testing
- Inter-annotator agreement
|
- Gold standard quality
- Matches expert user judgment
- Used to calibrate model-based graders
|
- Expensive
- Slow
- Often requires access to human experts at scale
|
For each task, scoring can be weighted (combined grader scores must hit a threshold), binary (all graders must pass), or a hybrid.
Capability vs. regression evals
Capability or “quality” evals ask, “What can this agent do well?” They should start at a low pass rate, targeting tasks the agent struggles with and giving teams a hill to climb.
Regression evals ask, “Does the agent still handle all the tasks it used to?” and should have a nearly 100% pass rate. They protect against backsliding, as a decline in score signals that something is broken and needs to be improved. As teams hill-climb on capability evals, it’s important to also run regression evals to make sure changes don’t cause issues elsewhere.
After an agent is launched and optimized, capability evals with high pass rates can “graduate” to become a regression suite that is run continuously to catch any drift. Tasks that once measured “Can we do this at all?” then measure “