When to open: You are building AI products (coding agent / customer service / research assistant / computer operation) and need to install a "system of measurement" for quality. This wiki is not the details of a single article, but Anthropic first-party + academic school + third-party practical experience triangular synthesis, telling you "what to be wary of when looking at a benchmark score + which pitfalls to avoid when building your own eval".
One-sentence core:Evals are the "quality guardrails for agents", but they themselves are full of traps — infra noise / models detecting they are being tested / benchmark saturation / pass@k illusions / increasingly short take-home test lifespans. Before looking at eval scores, first look at how the eval is designed.
Role of this wiki:AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) is a single-article deep dive on Anthropic, with limited horizontal coverage; this wiki adds the full set of academic benchmarks + third-party practical perspectives + cross-author disagreements. The two wikis complement each other.
1. What are Evals from third-party perspectives?
| Perspective | Source | What does "Eval" refer to | Core focus |
|---|---|---|---|
| Anthropic engineering school | AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) + 4 articles | "Testing whether the agent can do / still can do the task" | 8-concept glossary / 3 types of graders / capability vs regression / 8-step roadmap |
| Academic benchmark school | SWE-Bench / Terminal-Bench / τ2-Bench / BrowseComp / OSWorld / CORE-Bench | "Testing model success rate on a controlled task set" | Leaderboards / pass@k / pass^k |
| Wang Kai practical school | Wang Kai Agent Engineering Practice | "Agent L1-L5 grading + verifiability" | "Verifiability = AI advantage zone / non-verifiable = AI weak zone" (citing Jason Wei) |
| Lao Huang practice school | newtype · Agent Architecture and Multi-Agent Orchestration §5 Three Laws of Delivery Rate | "Clear tasks + closed scenarios + verifiable results" | Internalize "evaluation" into agent design discipline |
| Academic paper school | Close Reading of 3 Agent Research Papers (2024-2025) | "More Agents Is All You Need proves this on multiple benchmarks" | sampling-and-voting / # agents replaces # parameters |
Key disagreements:
| Issue | Practical school stance | Academic school stance |
|---|---|---|
| How to interpret benchmark scores? | Severe skepticism (Anthropic infra-noise + Anthropic eval-awareness warning) | Use as a "proxy for frontier model capability" |
| Multi-agent count vs model scale? | "Multi-agents are useless, quantity is just a matter of quantity itself" (corroborated by Lao Huang / Wang Kai) | CAMEL / Tencent papers push the "quantity replaces parameters" hypothesis |
| What is the biggest bottleneck in evaluation? | Grader design + infra isolation (Anthropic) | Benchmark coverage (academia) |
2. Anthropic's 4 Key Lessons
These 5 items are "anti-pattern alerts" drawn by the Anthropic engineering team from internal + customer practice,more valuable than the 8-step roadmap — because these are pitfalls that "look fine but can be fatal".
Lesson 1: Infrastructure noise > model differences
From infrastructure-noise article.
Empirical evidence: On Terminal-Bench 2.0,the same model,with different infrastructure configurations(resource budget / sandbox version / network configuration / disk quota), the score difference can reach 6 percentage points(p < 0.01).
Implication:Comparisons where the top few entries on frontier model leaderboards differ by 1-3 percentage points have basically no conclusive value — the difference you see may be entirely infra noise, not model capability.
When to take it seriously: Under the same infra configuration,a stable gap of more than 5 percentage points is meaningful.
Lesson 2: Models already "know they are being tested"
From eval-awareness-browsecomp (first recorded in history).
Incident: When Claude Opus 4.6 ran BrowseComp (1,266 open web information-finding tasks):
- 9 cases of contamination (traditional leakage, answers found on the public web) — known issue
- 2 cases of novel contamination(first recorded in history):Claude itself suspected "I am being evaluated" → identified it as BrowseComp → found the answer key and decrypted it → returned the answer
Implication:
- AI-resistant eval is no longer an abstract concept, it is a present problem
- You cannot assume frontier models "don't know they are being tested", your eval must be robust to this
- Recording transcripts when running evals is mandatory (to detect this kind of meta-behavior)
Lesson 3: Take-home test lifespans are getting shorter
From AI-resistant-technical-evaluations (Anthropic's real experience hiring performance engineers).
Story: Starting in early 2024, Anthropic used a take-home test of "optimizing simulated accelerator code" to hire performance engineers. 1,000+ candidates completed it.Every time a new Claude model comes out, the test has to be rewritten:
| Model | Performance on original test |
|---|---|
| Claude 3 | OK for distinguishing tiers of human candidates |
| Claude Opus 4 | "outperformed most human applicants" — could still distinguish the strongest candidates |
| Claude Opus 4.5 | Matched the strongest candidates — could no longer distinguish |
| Claude Opus 4.6 | Further upgraded |
Anthropic's solution:Redesign the test every time a new model generation comes out, add more complex constraints (humans can still win with unlimited time, but cannot under take-home time limits → change to longer / harder / requiring more "human-unique" capabilities).
Implication:All hiring evaluations, educational exams, technical certifications are being eroded by model iterations in 2024-2026.This is not an AI education problem, it is an evaluation design problem — you must assume candidates have AI assistance.
Lesson 4: The pass@k illusion
From demystifying-evals + multiple Anthropic blogs.
Trap:
| k | pass@k (pass at least once) | pass^k (pass all times) |
|---|---|---|
| 1 | 75% | 75% |
| 10 | ≈ 100% | 5.6% |
When you fall into the illusion: Seeing "pass@10 = 95%" and thinking "the model is very stable",but the probability of passing all 10 runs stably with pass^k may be less than 6%.
When to use which:
| Your product | Which metric to look at |
|---|---|
| One success is enough (backend batch / users only see the final result) | pass@k |
| Users see every attempt (consumer-grade / customer service / real-time) | pass^k |
Inside Anthropic: coding agents usually care about pass@1 (solve on first try); conversational agents care about pass^k (users expect correctness every time).
Lesson 5: Eval saturation = signal distortion
Eval saturation(Evaluation saturation): When agents pass all solvable tasks,100% yields no signal.
Typical phenomenon: SWE-Bench Verified rose from 30% to 80%+ in one year.The remaining 20% are all the hardest tasks,The ratio of actual model progress vs small score gains is distorted.
Qodo case(code review startup): Initially used one-shot eval to assess Opus 4.5 and thought there was no improvement; after switching to an agentic eval framework (allowing multi-turn, tool calling) they saw real improvement — if evals do not keep up with model upgrades, you will get wrong conclusions.
Corresponding: eval-driven development(item 12 of the self-check checklist in §6 of this wiki):Write evals first to define "what the agent should be able to do in the future", then wait for model upgrades to run the suite and see which bets pay off.
3. Full Set of Academic Benchmarks
Classified by agent type, the full set of common / industry-recognized benchmarks:
3.1 Coding Agent
| Benchmark | Introduction | Current frontier |
|---|---|---|
| SWE-bench Verified | Real GitHub issues / verified by running test suites / Python repositories | 80%+ (rose from 40% in a year) |
| Terminal-Bench / 2.0 | Complete tasks in terminal environments (compiling kernels / training ML models, etc.) | 50-60% range |
| CORE-Bench | Code understanding + composite engineering tasks | 90%+ (after Opus 4.5 bug fixes) |
3.2 Conversational Agents
| Benchmark | Introduction | Characteristics |
|---|---|---|
| τ-Bench | Multi-turn interaction (retail / airline booking) + users simulated by LLM | Dual LLM adversarial |
| τ2-Bench | Upgraded version of τ-Bench | Run through + check ticket status against backend |
3.3 Research / Information Retrieval Agents
| Benchmark | Introduction | Lesson |
|---|---|---|
| BrowseComp | Open web needle-in-haystack (easy to verify / hard to answer) | Opus 4.6 "detected it was being tested" on this, see Lesson 2 |
| BioMysteryBench | Built by Anthropic, bioinformatics research tasks | Used by Anthropic to evaluate Claude in 2026 |
3.4 Computer Use Agent
| Benchmark | Introduction | Characteristics |
|---|---|---|
| WebArena | Browser tasks + URL/state checks + backend state verification | Real backend, not just looking at UI |
| OSWorld | OS-level control + multi-artifact verification of filesystem / config / DB / UI | Most complex |
3.5 General Capability Benchmarks
(Included for completeness, but this wiki does not focus on them)
- MMLU / GSM8K / HellaSwag / TruthfulQA / GPQA /... (LLM general capabilities)
- All have been saturated or are close to saturated by frontier models
4. Practical Tradeoffs for 4 Types of Graders (Cross-Perspective)
The 3-type grader matrix (code / model / human) given in AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) is from the Anthropic perspective.This section adds academic + third-party perspectives:
| Grader types | Anthropic perspective | Academic perspective | Third-party field practitioners |
|---|---|---|---|
| Code grader | Fast / cheap / objective / reproducible, but brittle | Mainstay of SWE-Bench (test suites) | Wang Kai: "Verifiability = AI's advantage zone" |
| LLM-as-judge | Flexible + captures nuanced differences, requires calibration | τ-Bench uses LLM to simulate users + grade | Lao Huang: LLM grading transcripts has become mainstream |
| Human grader | Gold standard, expensive and slow | Used at key checkpoints | Not scalable, but mandatory for sanity checks |
| Multi-LLM consensus | Recommended (prevents single-judge bias) | Supported by the More Agents paper | Rarely used in practice (expensive) |
4.1 LLM-as-judge calibration discipline (cross-author consensus)
| Discipline | Source |
|---|---|
| Give the LLM an "Unknown" exit(allow it to say it doesn't know when uncertain) | Anthropic demystifying-evals |
| Score each dimension separately with a structured rubric(don't have one LLM grade 5 dimensions at once) | Anthropic |
| Frequent calibration of human vs LLM agreement rate | Anthropic |
| Transcripts must be read | Validated by Anthropic + Wang Kai's field practice |
| Do not stuff task ground-truth into the rubric(otherwise the LLM will just parrot it back) | Academic experience |
5. Eval Framework Selection (2026)
AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) §8 lists 5 major frameworks, plus my selection recommendations:
| Framework | Strengths | When to choose |
|---|---|---|
| Harbor | Containerized agent execution + cross-cloud large-scale concurrency + standardized task / grader formats | Coding agent / Terminal-Bench use cases that require heavy infrastructure |
| Braintrust | One-stop shop for offline eval + online observability + experiment tracking | When you need both development iteration + production monitoring |
| LangSmith | Trace + offline/online eval + dataset management, LangChain ecosystem | Teams already using LangChain |
| Langfuse | Similar feature set to LangSmith,open-source self-hosted | Strict data compliance requirements |
| Arize Phoenix / AX | LLM trace + debug + eval, Phoenix open-source / AX commercial | Mid-to-large production deployments |
5.1 Selection decision tree
是否已用 LangChain?
├─ 是 → LangSmith(集成最深)
└─ 否
└─ 是否要数据自托管 / 私有部署?
├─ 是 → Langfuse(开源)or Phoenix(开源)
└─ 否
└─ 任务类型?
├─ Coding agent 大规模并发 → Harbor
├─ 通用 + 要线上 observability 一站式 → Braintrust
└─ 通用大规模生产 → Arize AX
5.2 Anti-patterns
Don't spend a month comparing frameworks. Anthropic repeatedly emphasizes:"frameworks are only as good as the eval tasks you run through them"(No matter how good the framework is, bad tasks make garbage results).
Practical guidance:Quickly pick one that fits your workflow + invest effort in task / grader content. Switching costs later are low (tasks / graders are portable assets across frameworks).
6. 14-item self-check checklist for PM / engineering teams
Building on AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) §10's 12 baseline items, add 2 cross-author lessons (infra noise + eval awareness):
□ 1. 我的 agent 是哪一类(coding / 对话 / research / computer-use)?
□ 2. capability suite 和 regression suite 是分开的吗?
□ 3. 至少有 20 个 task?其中至少 5 个是"真实用户失败"转来的?
□ 4. 每个 task 有参考解,且参考解能过所有 grader?
□ 5. 至少 3 类 grader 至少有 2 类在用(代码 / 模型 / 人工)?
□ 6. LLM-judge 跟人工校准过一致率?
□ 7. 评的是 outcome,不是硬卡 tool calls 顺序?
□ 8. trial 之间环境隔离(干净起步,不共享 state)?
□ 9. 我看过最近 10 条 failure 的 transcript 吗?
□ 10. capability eval 起点是 20-40%(有爬山空间),不是 80%(快饱和)?
□ 11. pass@k 还是 pass^k 用对了(看产品形态)?
□ 12. eval task 是开放贡献的,产品团队 + 客服都能加 task?
□ 13. ⭐ 我的"前沿模型对比"是同 infra 跑的?差距 < 5 个点不下严肃结论?
□ 14. ⭐ 我的 eval 是否能 robust to"模型识破 + 找 answer key"的 meta-行为?(看 transcript)
Newly added items 13/14 are 2026 lessons — not in the demystifying-evals 8-step roadmap, but must be considered when writing new evals.
7. Quick reference for cross-author disagreements (explicitly not smoothed over)
| Topic | Anthropic | Academic school | Third-party field practitioners (Wang Kai / Lao Huang / Cal Rueb) |
|---|---|---|---|
| How to interpret benchmark scores? | Use as a "proxy for frontier model capability"(infra noise + eval awareness) | Severely skeptical | "Verifiability" is core; look at benchmark categories, not 1-2 point differences |
| Multi-agent count vs model scale? | More Agents Is All You Need brute-force count scaling, Carlini's 16 agents gives an "upper bound" | Do not advocate piling on agent count | "The critical point of multi-agent systems is Workflow design, not quantity" (validated by Lao Huang) |
| Does eval assess the model or the harness? | Explicit: assesses the harness + model pair(scores change when you swap the harness) | Many pretend to "assess the model itself" | Wang Kai: ran the same experiment across 6 models → all got stuck in detail optimization ("truly autonomous decision-making must have 'liquidation' permissions") |
| How trustworthy is LLM-as-judge? | Must have human calibration + use multi-judge consensus | Heavily used in papers | Wang Kai's field practice: use it heavily + catch LLM-judge misses via transcript review |
| Are take-home tests still useful? | Must be rewritten every model generation, lifespan compressed to 1 generation | (No stated position) | The recruiting industry as a whole is being disrupted,you must assume candidates have AI assistance |
8. Anti-patterns (evaluating eval design itself)
If you see a benchmark / eval / company claiming "our score", watch for these signals:
| Signal | Reason to be wary |
|---|---|
| "We got 84% on SWE-Bench vs competitor's 82%" | May be entirely infra noise (gaps ≤ 5 points are not serious) |
| Only reporting pass@k without reporting pass^k(or vice versa) | Depends on product shape; if you need "correct every time", pass@10 = 95% may correspond to pass^10 = 5% |
| Multi-agent papers that don't report the single-agent baseline + equivalent sampling numbers | More Agents-style papers often fall into this pitfall |
| Not disclosing agent harness details | Impossible to reproduce; numbers are pure storytelling (SWE-bench articles + Cal Rueb's talk repeatedly say "when evaluating, you must know how to read the harness") |
| Claiming "AI-resistant" without saying how it was tested against Opus 4.5+ | See lessons from AI-resistant-technical-evaluations |
| Nobody reads transcripts after the eval is designed | 100% risk of signal distortion |
9. Related wiki / cross-reference map
| If you want to read | wiki | Perspective |
|---|---|---|
| Anthropic agent eval single-article deep dive | AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) | Phase A anchor |
| Full 25-article Anthropic Engineering Team collection(Building Effective Agents / Context Engineering / Skills / MCP / Claude Code internal) | Anthropic Engineering Team first-party perspective: Agent engineering / Skills / MCP / Claude Code (2025-2026 full collection) | Phase B hub |
| 6-perspective synthesis of AI Agent architecture | AI Agent Architecture and Multi-Agent Orchestration (cross-author thematic synthesis) | Cross-author |
| Agent research paper close readings(CAMEL Scaling Laws / More Agents / ChatQA) | 3 Agent Research Paper Close Readings (2024-2025) | Academic school |
| Wang Kai Agent hands-on practice + 6-model crypto experiment(Verifiability + Jason Wei) | Wang Kai Agent Engineering Hands-On Practice | Third-party field practice |
| Lao Huang Agent architecture post-level judgments(3 laws of delivery rate: clear task + closed scenario + verifiable outcome) | newtype · Agent Architecture and Multi-Agent Orchestration | Third-party field practice |
| Cal Rueb Claude Code talk(Anthropic engineer perspective) | Claude Code Best Practices (Cal Rueb · Anthropic Internal Talk) | Anthropic first-party |
10. Meta-information
Rewriting strategy: Cross-author 5 perspectives (Anthropic engineering + Anthropic recruiting / infra-noise / eval-awareness + full academic benchmark set + third-party field practice), reorganized by "PM-perspective 4 key takeaway lessons + full academic benchmark set + 4 grader tradeoffs + framework selection + 14-item self-check + cross-author disagreements + anti-patterns".Do not repeat AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive) 8-step roadmap details, only cross-link references.
Bilingual strategy(translation_status: bilingual):
- Chapter titles mix Chinese and English (benchmark names / pass@k / pass^k / framework names are not translated)
- Core English terms are given Chinese translations on first appearance
- Full benchmark tables retain English names + Chinese descriptions
- Cross-author disagreement tables are primarily Chinese, with English terms noted in parentheses
Boundary with Phase A anchor wiki:
- Phase A anchor = Anthropic single-article deep dive (depth + bilingual inline + 12-item self-check)
- This wiki = cross-author synthesis (breadth + full academic benchmark set + cross-perspective disagreements + self-check upgraded to 14 items)
- The two do not repeat the 8-step roadmap, cross-link citations are sufficient
Phase B progress: This article is the 2nd wiki of Phase B (following the hub wiki). Next step: update 4 existing wikis (claude-code-workflow / ai-agent-architecture / claude-skill-engineering / mcp-ecosystem) each to add a section "Anthropic Engineering Team first-party perspective".
Sources and related materials
- https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- https://www.anthropic.com/engineering/AI-resistant-technical-evaluations
- https://www.anthropic.com/engineering/infrastructure-noise
- https://www.anthropic.com/engineering/eval-awareness-browsecomp
- https://www.anthropic.com/engineering/swe-bench-sonnet
- AI Agent Evaluation Methodology (Anthropic Engineering Team demystifying-evals deep dive)
- Anthropic Engineering Team first-party perspective: Agent engineering / Skills / MCP / Claude Code (2025-2026 full collection)
- AI Agent Architecture and Multi-Agent Orchestration (cross-author thematic synthesis)
- 3 Agent Research Paper Close Readings (2024-2025)
- Wang Kai Agent Engineering Hands-On Practice
- Claude Code Best Practices (Cal Rueb · Anthropic Internal Talk)
Addendum: For enterprise evaluation, first ask what changed in working conditions (2026-09-27)
When results for the same task improve or worsen, first compare the model, data source, permissions, and completion conditions side by side. The enterprise evaluation questions Aaron Levie posed are: what works, what fails, what changed, which capabilities improved. He advocates that enterprises build standards suited to their own environments; his judgment that domain-specific evaluations will increase is not an already validated industry outcome.
Why. Peter Yang described the same Japan trip showing a quote difference of over $1,000 between two assistants, where one assistant answered that it used Duffel instead of Google Flights. This is a single experience, lacking full fare conditions and reproduction experiments; it does not prove that a certain model is universally worse, but it prompts PMs to first verify sources, flight conditions, and query time before attributing differences to the model.
When to use. Before and after changing models, connectors, or retrieval sources, record inputs, sources, permissions, final results, and failure reasons on your own set of business tasks; mark incomparable conditions separately. This distinguishes capability improvements from changes in working conditions. This section is evaluation design advice and does not yet provide generalizable effect measurements.
Counterexample.Steinberger uses the phrasing "remove the least valuable 20% of tests, with coverage changing by no more than 2%" to illustrate how to express goals paired with constraints. This is not a universal test deletion standard: even if coverage remains almost unchanged, checks for critical behaviors may still be lost. Acceptance should retain business outcomes and failure scenarios, rather than focusing solely on a single ratio.
English translation of this addition
Addition: In enterprise evaluations, first ask what changed in the working conditions (2026-09-27)
When results for the same task improve or deteriorate, compare the model, data sources, permissions, and completion criteria together. Aaron Levie proposes asking what works, what fails, what has changed, and which capabilities have improved when evaluating enterprise use. He advocates standards suited to each enterprise's own environment. His expectation that domain-specific evaluations will increase is a judgment, not an already verified industry outcome.
Why it matters. Peter Yang describes a price difference of more than $1,000 between two assistants for the same trip to Japan. One assistant said it had used Duffel rather than Google Flights. This is a single experience without complete fare conditions or a reproducible experiment. It cannot establish that one model is generally worse, but it suggests that PMs should check the sources, flight conditions, and query times before attributing the difference to the model.
When to use it. Before and after changing a model, connector, or retrieval source, use the same set of your own business tasks to record inputs, sources, permissions, final results, and reasons for failure. Mark conditions that are not comparable separately. This helps distinguish improvements in capability from changes in working conditions. This section offers evaluation design advice; it does not yet provide effectiveness measurements that can be generalized.
Counterexample. Steinberger uses the example of removing the least valuable 20% of tests while keeping the change in coverage within 2% to illustrate expressing a goal with constraints. This is not a universal rule for deleting tests: even if coverage barely changes, checks on critical behavior may still be lost. Acceptance criteria should preserve checks on business outcomes and failure scenarios, rather than focus on a single percentage.