面试官问
“同一个Agent，评测重跑一遍分数就变了，你先查哪里？”
最常见的反应是去改提示词，或者认定模型这次发挥不好。可要是负责打分的判定器读到的是上一轮留下的结果文件，一个什么都不做的Agent也能判通过。所以改Agent之前，得先弄清两轮测的是不是同一件事。
**Anthropic测过，光是机器给的资源不一样，分数就能差出6个百分点。**评测条件和运行环境没核对过，分数差多少都说明不了Agent变了。
直接回答
先证明两轮测的是同一件事，再谈模型波动：
① 每轮在干净目录里从同一份初始快照开跑，判定器只对着这一轮存下的执行记录打分；
② 附一份条件清单，版本、超时和资源限制逐项对齐；
③ 这些都对上，剩下的差异才算模型输出的波动，要在同样条件下多跑几次比通过比例。
01先找出旧文件造成的假通过
为了说明哪怕Agent的输出完全稳定，评测流程自己也能造出假分数，先做个控制变量实验：把模型摘出去，换成写死的Python函数当测试桩，数据都是合成的。桩读取orders.csv（三笔金额120、80、45），把合计写进result.json，正确答案是245。
第一轮用正常桩，它写下245，判定器判通过。第二轮还在同一目录，换上什么都不做的空操作桩，判定器读到的仍是上一轮的245，又判了通过。其实负责跑评测的执行器开跑前检查过目录，记录里写着“结果文件运行前已存在”，只是第一版判定器没看这一项。
Anthropic的Agent评测指南也提醒，几轮运行共用遗留文件、缓存，分数反映的可能是环境而不是Agent。所以分数一变就去改提示词，很可能改错了地方。
02把执行、记录和判定拆开
拿pytest打个比方：断言写在用例里，跑完当场就判，一收尾现场就没了，想换断言只能整条重跑。Agent重跑一次要花钱，输出也会变，所以最好反过来先存现场再打分：执行器准备输入、调用Agent；记录器存下这一轮的输入、工具调用和写出的文件；判定器事后只读存档打分。
Inspect是英国AI安全研究所等开发的开源Python评测框架，算是大模型评测里的pytest。它就是这么做的：日志按样本（相当于一条用例）存下输入、输出、标准答案和得分，判定规则改了，换个判定器重判，不用重跑Agent。
实验给判定器加了一条规则：结果文件运行前已存在就判失败。不重跑桩，只拿存档重判，第二轮的空操作桩就从通过变成了失败。三个环节共用一个运行编号，才对得上每条记录属于哪一轮。
03每轮换个新目录，旧文件才混不进来
靠判定器揪出旧文件，守的是最后一道防线；想从根上断掉污染，还得在开跑前把环境隔离开。所以执行器每轮先把orders.csv的快照复制到新目录，确认里面没有result.json，记录器存下检查结果。
实验又加了一个把合计写成200的错误桩。换成干净目录后，空操作桩判失败是因为真没写出结果文件，“运行前已存在”那条规则退成了第二道保险；错误桩写成了200也判失败，只有正常桩通过。
真实Agent还会碰数据库、缓存和记忆，复位范围要按它的工具碰得到的东西列。库太大、每轮整库重建太慢的话，每轮至少要把判定要查的那几张表重建一遍。
04给每次运行附上条件清单
环境复位了，两轮也未必测的是同一件事。同事看到一个分数，还得知道测的是哪个版本、在什么限制下跑的，所以每次运行附一份条件清单：
条件清单
① 测的是什么：任务版本、任务参数、输入数据的哈希值（数据库就记快照编号）。
② 谁在被测、谁来判：Agent代码的提交号、带日期的模型版本号、判定器版本、依赖包版本。
③ 在什么限制下跑：实际生效的超时时间和资源限制。
限制这一组最容易漏。Git锁得住代码，锁不住启动命令：超时和资源上限多半写在启动命令或机器配置里，不跟着代码一起提交，所以提交号一样，限制也可能不一样。一轮超时60秒、另一轮300秒，前一轮因超时失败的任务就会被当成Agent能力差。
开头那6个百分点出自Anthropic在编程基准Terminal-Bench 2.0上的内部实验，比的是资源最多和最少的两档配置。
**他们建议，评测配置写明、对齐之前，排行榜上不到3个百分点的差距都要存疑。**自己两轮配置没对齐时，差几个点也别算到Agent头上。
主机负载这类锁不住的条件，在清单里单独记成“不可控项”：比对时不算差异，排查时再拿出来当线索。
05面试官追问链
追问 1
“两轮分数差了几个点，具体按什么顺序排查？”
先看两轮的运行前检查有没有遗留文件，有就先复位；再逐项比对条件清单：
**有对不上的项：**先假定分数差就是这些项造成的，把它们改成一致，在同样条件下重跑几次；差异还在，就说明不是这几项的问题，接着看不可控项。
**可控项全部对上：**再看一眼不可控项，负载明显异常就换个时段重跑；都正常，才轮到模型输出波动。这时要在同样条件下多跑几次，比通过的比例，每次结果都算进去，不是重跑到通过为止。
追问 2
“评测流程改过以后，怎么确认它本身没坏？”
留一个故意什么都不做的空操作桩当负例。这跟写单元测试时先故意让它失败一次是一个道理：一个什么都不做的程序要是也能判通过，说明评测本身有漏洞，问题不在Agent。
每次改了执行器、记录器或判定器，先跑一遍空操作桩：判定得是失败，运行前检查还得写着“结果文件不存在”。只看判定不够：实验里把它留在旧目录，新判定器照样判失败，检查却写着文件已存在，说明复位根本没做。
追问 3
“配了沙箱，是不是就不用操心复位了？”
不是。新目录挡不住Agent读写目录外的东西，那才要靠沙箱。但Inspect文档提醒，配了沙箱，工具函数本身仍在主进程里跑，只有经沙箱接口发出的命令才进容器。工具里直接用open()写的文件落在评测主机上，复位时也得算上。
06本题总结
一句话总结
评测分数变了，先证明两轮测的是同一件事：干净目录开跑、判定器只读这一轮的存档、条件清单逐项对齐；这些都对上，剩下的差异才算模型波动。
面试锦囊
**先说：**分数变了先别改提示词，先查判定器读到的结果文件是不是这一轮写的；旧文件能让什么都不做的桩也判通过。
**再说：**执行、记录、判定拆开，判定器只读存档，改了规则不用重跑Agent；每轮在新目录从同一快照开跑，再附条件清单，超时和资源限制最容易漏。
**最后补：**用空操作桩当负例验收评测流程；清单对齐后差异还在，才在同样条件下多跑几次比通过比例，不是重跑到通过为止。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
