📝 摘要 #

企业级 Agent 的评测不能靠公共榜单：Cursor 客服 bot 编造政策、Air Canada 聊天机器人被判赔等事故说明，换更强的模型或 harness 只会把失败挪到你看不见的地方。作者用飞行员「笔试 vs checkride」类比，主张用客户真实请求、私有数据和生产环境中的同一套 agent/工具/权限来跑 eval，并按业务结果而非执行步骤评分。文章给出优秀 eval 的五条标准（真实工作、生产 agent、结果评分、每次运行都算、难度可教），强调回归套件接近 100% 用于发布门控、前沿套件保持 30–70% 通过率用于发现能力边界，同时必须「评测评分器本身」。构建层面介绍 Harbor 的 Task/Environment/Agent/Verifier/Trial/Job/Dataset/Sandbox 抽象与 Prime Intellect 的 verifiers，并用 hacker-fixer-solver 循环自动审计验证器（KernelBench 上漏洞利用成功率从 62% 降到 0%）。最后指出三大现实难点：高难度任务稀缺且会过期、合成数据过于干净、完整流水线仍主要靠人工。

核心概念： 公共 benchmark 是「笔试」，企业 eval 是「模拟机里的 checkride」——用你自己的客户、数据和最怕的失败场景，在生产同构环境中反复验证 agent。

关键技术栈 / 关键要点：

1. 五条优秀 eval 标准 — 真实工作、生产 agent、按结果评分、每次运行都算、难度适中（回归套件≈100%，前沿套件 30–70%）。
2. Grade your graders — Anthropic 发现修复评分 bug 后 Claude Opus 4.5 在 CORE-Bench 上从 42% 升至 95%，评分器本身必须被评测。
3. Harbor 抽象 — Task / Environment / Agent / Verifier / Trials / Jobs / Datasets / Sandbox；环境每次重建且永不连接生产。
4. Verifier 审计循环 — hacker 设法不解题通过、fixer 修补验证器、solver 确认真实解仍通过；每次变更至少检查「参考解通过、空操作 agent 失败」。
5. Payoff 复利 — 好的 grader 可复用为 reward function，eval 数据可反哺后训练（如 Cursor 训练 Composer）。

关键结论 / 实践建议： 先从 20–50 条真实失败案例起步建 eval；用回归套件守住发布门控、用前沿套件探测能力边界；eval 是地板而非保证，但能让你「有依据地发布」而不是靠运气。

---

Imagine your worst nightmare: your agent passes every demo, then a customer asks something you never tested, and it fails in public.

In April 2025, @cursor_ai's support bot told users that being logged out on a second machine was a new policy. There was no such policy. "Hey! We have no such policy," co-founder Michael Truell wrote on Reddit. A year earlier, a court ordered Air Canada to pay a passenger $812.02 after its chatbot described a refund the airline didn't offer.

When an agent fails like this, the typical instinct is to try a different and better model, a new harness or framework, or a longer tuned prompt.

A better model or harness doesn't always fix your agent. It only moves the failures somewhere you aren't looking.

To build a successful agent company, what you need isn't a SOTA model or harness. It's the boring tests: tests that run the same model, harness and environment as your customer-facing agent, on the work your customers actually send. Evals.

Evals (short for evaluations) are systematic tests used to measure the quality, accuracy, and behavior of AI models and agents.

Airplane pilots solved this long ago. A pilot moving to a new airliner passes a written exam, then a checkride in a full-flight simulator of that exact aircraft. One such required task is an engine failure on takeoff. The examiner doesn't ask what you would do. They fail the engine and watch.

Analogously, public benchmarks are the written exam. An enterprise eval is the checkride: your agent, on your customers' work and data, with the failure you fear most.

A public benchmark tests someone else's tasks on public data; an enterprise eval tests your customers' requests on your private data with your production agent, graded on the outcomes that matter to the you.

Why you need evals #

EnterpriseOps-Gym, built by ServiceNow's research team, drops AI agents into a simulated company and gives them real jobs, like resolving IT tickets, handling customer service and sharing files, then checks whether the work actually got done. GPT 5.5 ranked 1st at customer service, 3rd overall and 20th of 28 on Teams. If you run customer support, "3rd overall" undersells the model; but if your company runs on Microsoft Teams, it oversells it badly.

GPT-5.5 ranks 1st, 3rd and 20th of 28 on EnterpriseOps-Gym depending on the domain

On top of this, public leaderboards are keeping more of their tests away from the public: in late October, Artificial Analysis rebuilt its index so that 60% rests on private test sets or held-out answers.

The best public benchmarks also share similar blind spot: the public work doesn't represent your enterprise work. OpenAI's GDPval is one of the best benchmarks with 1,320 tasks across 44 occupations. But its tasks are "precisely-specified and one-shot, not interactive," with the full context handed over in the prompt. In real work finding that context often takes effort as OpenAI adds.

MIT's NANDA initiative found that 95% of organizations it studied got zero return from generative AI, and the ones who did better "benchmarked tools on operational outcomes, not model benchmarks". In LangChain's survey of 1,340 practitioners, 89% could observe their agents but only 52% ran offline evals. Most teams can watch their agent fail. Few can make it fail on purpose, before a customer does.

89% of agent teams have observability; 52% run offline evals

Learning only from failures in production isn't enough. Each one has already cost a customer. The rare, high-stakes cases show up once, then not again until they hurt. And without a test you can rerun, you can't prove a fix works or that it didn't break something else.

Airlines don't wait for a real engine failure to train for one.

What makes a great eval #

As Anthropic defines: an eval gives an AI an input and grades the output. Great evals share five traits:

1. Real work. Tasks come from your customers' requests, in their words, on their kind of data. Start with 20 to 50 drawn from real failures.
2. The production agent. Same model, prompts, tools and permissions as the agent customers use, in a similar sandboxed environment.
3. Graded on outcomes. Agents find valid paths you didn't plan, so check the end state, not just the steps. Was the refund issued? Was the right permission removed, and nothing else? Use code for that, and model judges only for prose.
4. Every run counts. On Sierra's τ-bench, GPT-4o solved 61% of retail tasks on one try and under 25% when it had to succeed eight times in a row. Customers don't retry until it works. (old model, but the principle stands)
5. Hard enough to teach you something. Keep a regression suite near 100% that gates every release, and a frontier suite your agent passes a 30-70% of the time.

Chance of succeeding k times in a row for agents at 95%, 90% and 75% per try

Most importantly, make sure to grade your graders! Anthropic found Claude Opus 4.5 scored 42% on CORE-Bench until researchers fixed grading bugs, and 95% after.

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".

The payoff also compounds. A grader can also be a reward function with the evals scaling to become training data to post-train custom models. Ideally inside its own agent harness the same way Cursor trained its Composer model.

How to build Evals #

Don't reinvent the wheel! Learn from existing research and leverage what already exists. @harborframework is an open-source framework from the makers of Terminal-Bench that makes it easier than ever to build evals and post-training data.

Harbor has a few core concepts that are worth learning even if you never use it.

Anatomy of an eval: task and agent feed a trial, trials make a job, jobs make results

• Task: an instruction, a container environment and a test script, kept as a folder you version like code. Ship a reference solution that proves it can be solved.
• Environment: rebuilt for every attempt and never connected to production. Replit's agent deleted SaaStr's production database because development and production were shared.
• Agent: your production harness behind a standard interface, so the model is a part you can swap.
• Verifier: runs after the agent stops, checks the end state and writes a reward.
• Trials, Jobs and Datasets: a trial (also known as a rollout) is one attempt, a job is many trials run in parallel, and a dataset is a versioned set of tasks. Keep one dataset for the gate and one for the frontier.
• Sandbox: an isolated container to run each trial using the environment task, environment, agent and verifier in.

@PrimeIntellect's verifiers is another library and framework you can use to build evals and datasets for post-training. Their blog post on verifiers goes deeper into technical design decisions on the core principles of the architecture for building evaluations.

Source: Prime Intellect's "verifiers v1: Decomposing Tasksets and Harnesses for Agentic RL & Evaluations"

Automate the audit. Verifiers are where evals quietly rot. In June, researchers audited 1,968 tasks across five terminal-agent benchmarks and found that 16% could be passed without doing the work. One agent, asked for a disk-health report, read test file names and hardcoded the answers, all of which make the tasks weak.

Their fix is a loop of three agents:

1. A hacker tries to pass without solving the task.
2. A fixer patches the verifier.
3. A solver confirms a real solution still passes.

On KernelBench, the loop cut exploit success from 62% to 0% while 98% of real solutions still passed. On Terminal-Bench it also rejected more good solutions, so a person still reviews the patches. Two cheap checks belong on every change: the reference solution must pass, and an agent that does nothing must fail.

The hacker-fixer loop: hacker, fixer and solver agents repeat until no new exploits appear

What is still hard with evals #

Most teams that try this hit the same three walls:

1. Hard tasks are scarce, and they expire. Each one needs a domain expert who can say what good looks like, and few have time. Anthropic notes that SWE-bench Verified went from 40% to over 80% in a year, so a frontier suite nobody refreshes becomes a regression suite.
2. Synthetic data comes out too clean. You often can't send customer records outside, so you simulate them. In a 451-person study, the same agent succeeded 63.6% of the time with real users and up to 77.8% with simulated ones.
3. Almost nobody has the full pipeline. Turning traces into tasks, writing reference solutions, keeping data private and retiring stale tasks are still mostly manual. As far as I can tell, only big labs and data vendors can afford the whole loop today.

None of this is a reason to wait. An eval is a floor, not a guarantee, and a floor lets you ship on purpose instead of by hope.

The checkride #

Nobody boards a plane because the pilot aced the written exam. They trust a checkride they'll never watch, flown with an engine failed on purpose. Your customers will trust your agent the same way once it has flown their routes, on their data, with the failure they fear most. Build that checkride before you ask anyone to board.

Read more on why I think synthetic data and simulations are key to scaling intelligence in my previous article.

10月29日