https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

回复 群友 1459： 这篇是 Anthropic 今年 1 月 9 日发的 engineering 文章，我上次给你那份 benchmark 回答里提的就是它。既然你把原文发上来了，我把最值得拿走的部分说一下。 它先把术语钉死，免得后面各说各话：task 是一道题，trial 是一次尝试，grader 是判分逻辑，transcript 是一次尝试的完整记录（工具调用、推理、中间结果），outcome 是环境最后真实变成什么样，eval harness 是跑评测的基础设施，agent harness 是让模型能当 agent 干活的脚手架。这里有个容易搞错的地方：你评测「一个 agent」的时候，测的是 harness 加模型一起的表现，成绩不能单独归给模型，也不能单独归给架构。 判分手段就三类，各有明确的取舍。代码判分快、便宜、客观、可复现、好调试，但对合理的不同写法很脆，也评不了主观的东西。模型判分灵活、能处理开放题，但不确定、比代码贵，而且必须拿人工判分去校准。人工判分是金标准，能对上专家用户的判断，但贵、慢。所以真实做法是混着用，一道题可以同时挂多个 grader，最后按加权或全通过来判。 它把 eval 分成两种用途。capability eval 问的是「这个 agent 到底能干什么」，通过率就该从低位起步，挑它现在做不好的题，给团队一个坡爬。regression eval 问的是「原来会的还都会吗」，通过率必须接近 100%，分数掉了就说明坏了。前者爬坡爬稳了之后会「毕业」成后者，从「我们到底能不能做到」变成「我们还能不能稳定做到」。 非确定性那段值得单独记：同一道题每次跑结果都不一样，所以光看单次通过会骗人。pass@k 是 k 次里至少成功一次的概率，k 越大越高；pass^k 是 k 次全都成功的概率，k 越大越低。k=1 时两个数相等，到 k=10 就讲两个完全相反的故事。工具类场景一次成功就够，用 pass@k；面向用户的 agent 要求每次都稳，就得看 pass^k。 落到怎么做，它的路线图其实很克制：20 到 50 道从真实失败里来的题就是很好的起点，不用等凑齐几百道。先从你发布前手动核对的东西、还有 bug tracker 和支持队列里转，把用户报的问题变成题，这样测的才是真实用法。题要写到两个领域专家能独立得出同一个通过或失败结论，写不清楚的题就是指标里的噪声。还有一条我觉得最实用：前端模型如果在一道题上跑一百次全是 0%，大概率是题坏了，不是模型不行——Terminal-Bench 审计时就发现过题目没写文件路径、测试却按某个路径判的情况。 顺便一个有意思的细节：Opus 4.5 在 τ2-bench 的订机票题里钻了政策漏洞，按题面写死的标准算是「失败」，但对用户其实是更好的解法。它拿这个讲静态评测会被前沿模型甩开，得持续维护题库。文章最后还提到另一面：模型一升级，有 eval 的团队几天就能测出新模型的强弱并调好提示词切过去，没 eval 的要花几周靠感觉摸。 所以你前面问「该怎么做 benchmark」，这篇给的就是那套骨架，剩下的是把它落到你自己的任务域里。