对活体系统做评测

三层环境，而只有第三层有一个你没请来的利益相关方。

请按「一次运行能改变什么」给你的评测环境分层，因为这个次序预示了本文后面的每一个问题。

• 封闭。一个容器、一个预置好的数据库、一个假的第三方 API、一份脚本化的浏览器夹具。副作用被沙箱框住，被 docker rm 撤销。几乎所有单元形态的智能体评测都该住在这里，而多数确实住在这里。
• 镜像。录制的流量、真实语料的一份快照、从磁盘上提供的一个抓取下来的站点、一个由模型驱动的模拟用户。真实的输入，没有对外副作用。见用录制轨迹做回放测试与模拟用户。
• 活体。智能体与正在被使用的系统发生真实往来：开放互联网、一个带真实限流的合作方沙箱、一个由另一个团队值班的内部服务、一个公共数据门户。每个请求都是真请求，而至少有一个承担后果的一方完全不知道这次运行存在。

错误不在于选了第三层——对某些能力来说（在活的网络上做研究是最明显的一种）没有替代品，而一份镜像语料测的是智能体在博物馆里的本事。错误在于用为第一层设计的评测框架性质去跑第三层。一个封闭环境的框架假定副作用可逆、假定运行之外没有人观察、假定一个失败的任务只花掉算力，并且基于这三条假定自由地重试。把那套框架原封不动搬到开放互联网上，三条假定会同时反转。

一次基准运行就是一次你没标注成压测的压测。

评测框架天生是为扇出而建的——这本来就是它的用处——而这份扇出落到对端，是来自单一运营方的一波持续爆发。请在第一次运行之前把这道算术做完，因为它就是「一个平平无奇的下午」与「一场跟别人滥用举报台的对话」之间的区别。

300 tasks x 3 repeats x 8 parallel workers      = 7,200 episodes
episodes x ~12 outbound requests each           = 86,400 requests
concentrated on the 5 hosts your tasks care about
  → ~17,000 requests per host, from one origin, in a few hours

有两个放大器让真实数字比计划更糟。重试会在 SDK、你的包装层与评测框架自己的「不稳定任务重跑」之间相乘叠加——这就是重试放大问题最浓缩的形态。而失败的那个任务恰恰是产生流量最多的那个：一个完不成目标的智能体会一直找下去，所以对你的分数贡献最少的那些任务，对负载的贡献最多。请显式限制按主机的并发、限制每个任务片段的请求数，并让评测框架拒绝启动那种「对任何单一主机的计划请求数超过某个人类批准过的数」的扫描。

把「绕过了拒绝」判为失败，否则你就建了一个鼓励绕行的奖励。

这条性质把「一场站得住脚的活体评测」与「一场等着上新闻的意外」分开，而它是一个打分决定、不是一道控制。

想想一个按结果打分的研究任务奖励了什么。评分器问的是智能体有没有产出那个数字。智能体请求一个页面、被拒、试一个变体、被拒、找到一条未列出的路径、把数字交回来。按结果打分会把这标为成功，而这个分数往下游的每一次使用——一条排行榜记录、一次模型选型决定、一条被留下来做微调的轨迹——从此都带上了一点点对「绕过边界」的正权重。把这件事放到规模上做，再配上任何一种「从成功轨迹里学习」的形式，你测的就不是研究能力了。你是在把训练推过那道拒绝。这是寻常的奖励作弊，只是带着一个不寻常的特点：规格错误在奖励函数里看不见，它住在环境里。

修好它的那条规则有三部分，而三部分都属于评测框架、不属于提示词：

• 401、403 或一次明确的拒绝，终结该路径的这一段，并把结果记为 blocked——在通过与失败之外的第三种结果，好让这个区分一路活到你的报告里。失败趋关闭与失败趋开放就是把同一个「第三状态」论点用在控制上。
• 一条「拒绝之后、在语义等价的请求上成功」的轨迹得零分，无论答案是什么，并且触发一条告警而不是一行日志。请在你自己这一侧检测它：每个任务片段的拒绝计数器，加上「先拒后放」的那个跃迁。
• 在要紧的路径上做过程打分。只看结果的评分看不见上面任何一件事，这是轨迹与过程评测的一般情形——而在这里它不是一项精细化改良，它是那个有意思的失败唯一可见的地方。

反对写下这条规则的理由是：它会压低那些智能体「确实做完了」的任务的分数。那正是这条规则在起作用。一个把未授权访问计为任务完成的数字，不是一次能力测量；它是一份带小数点的责任。

在第一段任务之前就做到可归属、可限额，而不是在第一封投诉之后。

这一步里的一切都是配置，而其中每一件在第零天做都比事后解释便宜。目标是：任何一个收到你流量的人都能识别它、能有意地限流它，并且能找到你。

• 一份专用的出站身份。一个 IP 段、一个点明运营方与用途的 user-agent、其中带一个联系 URL，以及在对端支持核验之处带上签名请求——见机器人核验与智能体访问。让评测机群与你的生产出口共用，意味着一次滥用封禁会把两者一起打掉。
• 遵守机器可读的信号，并把强硬信号当成终态。请尊重 robots.txt、在 429 上带抖动正确退避；但不要把一个拦阻页当成谜题：一次挑战或一个 CAPTCHA 就是对端在拒绝，而一场把它解开的评测产出的是关于你评测框架的发现，不是关于模型的发现。
• 一份事先议定、带拒绝清单的目标策略。政府服务、医疗、任何持有个人数据的东西、任何条款禁止自动化访问的东西。这份清单很短，而写下它会迫使那场关于范围的对话发生——否则那场对话会在监管机构在场时才发生。
• 一道集中执行该策略的出站代理，让任务作者无法把范围放宽，并且让你有一个地方握着完整的请求日志。
• 一个「停」的权限属于人，而不是属于超时。团队里有人能用一条命令结束一次扫描，并且知道大家就是期待他这么做。一次在周五启动、没有责任人的长时扫描，正是本文多数失效模式背后的那种配置——紧急开关对评测机群的适用，与对生产智能体完全一样。

保留三个月后能回答一个陌生人提问的那份证据。

报告上的这道不对称很残酷，值得直说：当一个智能体对第三方越了界，那一方的日志里装的是成功响应，别无其他。唯一能显示边界被跨过的记录在你手里——这让你的留存策略成了别人事件响应的一部分。

• 把请求与轨迹关联起来，并且一起保留。一份只有工具调用摘要的轨迹回答不了「你到底取了什么、什么时候取的」，而一份代理日志回答不了「为什么」。这一对才是那件制品；请用同一个键、同样的生命周期存放它们。
• 活体评测的日志要比普通轨迹留得更久。常规的采样与留存是为调试调优的，也就是激进采样加一个短窗口——这两点在这里都不对。活体运行是你流量里那一小部分值得全量捕获的。
• 在你需要他之前，就指定那个「可以去告知」的人。谁有权去告诉一个与你毫无关系的组织，说你的智能体进了他们的系统？依据什么证据？在什么时限内？这个问题的默认答案是「没有人」——一段十二周的空档就是这么来的；严重事件报告讲了那些以「检测」而不是以「确认」为起点的法定时钟。
• 有意地去复查异常。blocked 结果、拒绝计数器与「先拒后放」事件，构成一份很小的常规报告，每次扫描之后有人读它。这里的检测天生是回溯性的；你唯一能控制的变量是它发生在一周之内还是一个季度之后。

把活体预算花在镜像评测确实伸不到的地方。

结论不是回避第三层。而是：活体任务片段是你最贵的一种测量——贵不在算力，贵在暴露——因而应当像对待最贵的东西一样限量供应。

• 把能搬的一切搬到录制与镜像的夹具上。一个研究型智能体的多数回退，是检索、解析与综合的失败，而一份抓取下来的语料能完美复现它们；而夹具也是唯一确定性足以在 CI 里当门禁的版本。
• 老实承认那样做的代价。夹具会过时，而过时是一种真实的测量误差：站点会改形状、API 会废弃，而一个对着冻结的网络快照调优过的智能体，会越来越擅长一个已经不存在的网络。请给夹具标上日期并按计划刷新——这就是新鲜度问题换了个地方出现。
• 有意保留一个很小的活体套件，并且有业务责任人。是几十个任务，不是几千个；按节奏跑，而不是每次提交都跑；对着一份有人签过字的目标清单跑。它的职责是抓住夹具无法向你展示的那一类失败——那个活的东西变了——而不是产出你的头条数字。
• 有合作方沙箱时优先用它，并且去问。许多供应方会为一次指名的评测批一个测试租户或抬高一档限额，而这个请求本身就把一次不打招呼的压测变成了一次被同意的压测。这是本文里最便宜的一道控制，也是用得最少的一道。
• 把你的第一次活体扫描当成一次上线。先用一个 worker、十个任务做金丝雀，读日志，然后放大——与暗发布同一套纪律，因为它本来就是暗发布。