让模型画一只骑自行车的鹈鹕，很适合在社交平台上比较。任务短，容易传播，有些错误一眼就能看出来。但它很难回答另一个问题：这个 Agent 还能不能可靠地修好你的导入功能？
最近的 Astra 质量争议，正好提醒我们给自己的项目留下几道可重复的测试题。不一定要做公开榜单，也不必搭一套大型评测平台。先有可恢复的起点、能核对的结果，以及每次发生了什么的记录，就已经很有帮助。
OpenAI 的评测指南建议围绕真实任务设计评测，并用人工判断校准自动评分。下面是一套适合日常开发的小型做法，供你按项目调整；它不是已经跑出的榜单，也不预设哪个模型获胜。
先写清楚，你想验证哪句话
“当前配置更容易做错这个任务”和“模型比刚发布时退化了”，需要的证据不一样。
比较两个当前配置，可以现在就给它们等价输入。要证明历史退化，还得有过去保存的基线：任务、文件、指令、工具环境，以及当时真正产生的结果。对发布第一周的好印象，不能代替这些记录。
以前没有留档，就从这次开始。你仍然可以选出今天更适合干活的配置，只需把结论写成当前对照，留下材料给下一次比较。
还要区分测模型，还是测整套工作方式。同一 harness 中换模型，通常比连客户端、工具和指令一起换掉，改变的变量更少。两种对照都有价值，关键是说明自己究竟改了什么。
从熟悉的工作中，挑五类题
题目先小一点，让失败的位置容易被看见。下面的例子可以替换成自己仓库里经常发生的工作。
最后一类需要保存消息顺序、工具结果，或者有可重复搭建上下文的方法。让一个 Agent 读取现成长会话，另一个只看新写的摘要，输入就已经不同了。
不要把答案已经留在工作目录里的任务拿来测。条件允许时，把验收检查保存在 Agent 修改范围之外，避免它通过降低检查标准来“修好”结果。
先把一道题做扎实
假设有这样一个 Bug：请求工具用真假值判断选择超时时间，导致明确传入的 0 被默认值覆盖。
任务说明要先确定：零是合法值；省略参数时保留默认行为；既有非法输入校验不能被破坏。要求 Agent 完成范围合适的修复，并运行相关验证。
验收至少检查零值和省略值两个场景，再看 diff 有没有无关修改。如果它把测试改成接受旧行为，即使命令显示全绿，这道题也失败了。
这个例子故意很小。它测的是能否把要求落实到代码并证明修改有效。任务一开始就很大，反而不容易判断到底哪一环出了问题。
把起跑条件固定下来
每道题保留代码修订，以及测试所需的未提交文件。每次尝试使用独立 worktree、副本或其他等价的隔离环境。两个 Agent 同时改一份正在变化的目录，无法构成独立对照。
记录 harness 和客户端版本、模型、推理强度、速度模式、工具、权限、依赖版本及实际生效的指令。少了权限、依赖没装好，也会让一个本来能完成的任务失败。
上下文条件也要提前决定。新会话和长会话都值得测，但分别成组。如果任务必须联网，尽可能保留读到的资料，或者使用稳定的测试材料。控制条件的同时，也要保留你真正关心的工作特点，别把要研究的行为一起控制掉了。
重复几次找线索，同时给自己设预算
一次成功、一次失败，只说明这两次发生了什么，还不足以证明两个配置之间有稳定差距。
初步筛查时，如果成本允许，可以为选中的每道题、每种配置安排三到五次独立尝试。这是实用的起点，不是统计保证。每次结果都留下，预算到了就结束，不要一直跑到自己喜欢的配置赢为止。
不同配置的运行顺序尽量交替。A 全在上午跑，B 全在晚上服务异常时跑，时间就成了额外变量。真正重要的采购或生产决策，可以在初筛后扩大评测，并做相应的样本量分析。
这一轮小测试的任务很明确：找出值得继续追查的重复失败，或者为今天的工作找到可用替代方案。
先看产物，再看模型名字
条件允许时，评审先看补丁和结果，打完分再看配置名称。验收标准在运行前就写好，避免被一段漂亮解释带偏。
有明确通过条件的检查可以自动化；UI 状态到浏览器中看；权限、数据处理和工作范围的变化单独审查。严重越权修改应保留为关键失败，不能被平均到一个好看的总分里。
可以用这样的记录表：
环境阻塞要单独标记，也要保留发生次数。比较整套工作流程的可靠性时，不能悄悄把这些失败删掉。只想研究模型能力，可以修好环境后重跑；研究用户实际能否完成任务，则需要把环境失败也留在体验记录里。
让结论和这次测试一样具体
一条有用的结论可以这样写，下面的数字仅作示范：“在保存的超时题目上，A 五次通过两次，B 五次通过四次；代码基线相同，设置如下。样本很小，我们先用 B 处理这类任务，同时调查 A 的失败。”
别人看完知道该复现什么。把它改写成“B 的智商是 A 的两倍”，就不再是这组结果能够支持的判断。
如果还关心后台有没有换模型，补充路由证据。如果关心花费，把所有尝试都纳入合格任务成本。公开的 Astra 基准测试可以帮助挑候选项，自己的题目则检查这些候选项是否适合项目。
在 Agent.Space 中，Workspace 可以让多个 Session 使用保留下来的项目和任务说明。会写文件的对照，先准备独立副本或分支，再把相同起始说明交给各个 Session。共享文件有助于延续工作，而实验所需的隔离需要另外安排。
这次问题过去后，也把失败题目留下。下次客户端更新、指令调整或模型再出现波动时，你已经有了明确起点和可核对的终点，判断会容易得多。
本文提供原创评测方法。超时 Bug 与示范通过次数均为说明性案例，不是 Agent.Space 实测结果。官方资料核对日期为 2026 年 9 月 15 日。