Agent评测如何兼顾真实与可复现

Agent 跑完一次任务，不等于它在真实工作中也能稳定完成。同一个请求，换个工作目录、多一份缓存、少一个权限，结果就可能变样。Quantiles 这篇文章讨论的，正是如何搭建既接近实际使用、又能重复比较的评测环境。

作者的结论是：不必复制整套生产系统，但必须保留会影响 Agent 判断、操作和结果的条件。对正在接入 AI 编程工具的团队，这比多跑几道题更值得先想清楚。

你测的是 Agent，还是预先铺好的路？

评测环境不只是题目和数据。工具、应用、文档、权限、初始状态，都在决定 Agent 能做什么。对于 coding agent，仓库、终端、已安装依赖和 CLI 是显眼的部分；当前目录、已有配置、缓存、前序命令留下的文件，则很容易被漏掉。

作者给了一个 Quantiles 经常使用的任务：安装 Quantiles skill，使用附带的 5 个任务的数据集运行评测，再分析结果、总结发现，并说明遇到的错误。

这件事至少需要数据集、相关文档、运行所需的凭证，以及每项任务开始前的干净状态。他们还刻意让 skill 可以被安装，却不告诉 Agent 去哪里找，用来观察它能否自行发现入口。

这里有个很实际的区别：提前把安装地址塞进提示词，和让 Agent 从文档中找到安装方法，测到的能力不同。前者能观察执行，后者还覆盖了发现和理解产品入口的过程。

环境里替 Agent 提前完成的步骤，也会从评测范围里消失。

因此，评测前先明确自己究竟想验证哪一段流程。否则，结果看起来很顺利，却可能绕过了用户最容易卡住的地方。

真实感要留在决策处，不必复制整个生产系统

作者把环境设计归纳为四部分：任务与数据、工具行为、上下文与权限，以及一致的起点。

任务最好来自日常工作流，并覆盖不同类型：直接请求、需要解释规则的情况、信息不足时需要继续询问的情况、新用户上手，以及团队原本就在测试的流程。

数据可以合成，也可以脱敏。关键不在于它是否来自生产库，而在于有没有保留影响判断的细节和差异。若删掉了决定规则适用范围的字段，数据虽然更整洁，任务却已经变简单了。

结果也要能验证。对于边界明确的任务，可以设定预期结果；对于探索性任务，Quantiles 会使用更宽的成功标准，允许不同解法，再观察 Codex、Claude 和其他 Agent 如何处理同一个问题。

工具则需要表现得像实际产品：校验输入、返回有用信息、失败时给出清晰错误。作者也建议主动注入故障，观察 Agent 能否恢复，但必须记录哪些故障是人为安排的，避免把测试设施的问题算到 Agent 头上。

他们提到，模型供应商限流是 Quantiles 经常遇到的故障，因此已经在 skill 中补充恢复指引。原文没有给出恢复成功率，也没有提供具体请求参数，不能进一步推断这种指引有多大效果。

如果真实服务成本高、风险大，或者难以重复测试，可以使用模拟服务。但模拟器覆盖了哪些行为，结果就只能支持相应范围的判断。没有模拟的服务故障，仍可能在实际运行时出现。

权限和初始状态，也应该写进成功标准

上下文应该放在 Agent 实际会遇到的位置，例如文档中的安装指南、仓库里的项目指令、工具返回的使用说明。部分任务还应明确考察它能否找到这些信息，并正确应用。

权限设计同样需要提前确定：开始时已有登录会话，还是提供 API key，或者允许 Agent 请求访问？凭证解决的是能否连接服务，权限决定的是连接之后允许做什么。这两件事不能混为一谈。

如果登录必须由人完成，成功标准可以是：到达登录页、说明需要什么操作，并请求用户接管。此时完成的是交接任务，不能因为后续还没登录，就直接判整个测试失败；也不能把完成交接算成已经完成全部业务流程。

作者还提到正在关注 WorkOS 的 auth.md，希望用它帮助 Agent 发现服务注册方式和可申请的访问权限。不过，文中表达的是后续测试意向，没有给出验证结果。

另一个容易被忽视的问题是任务之间的状态串扰。前一个 Agent 可能改了文件、更新了记录，或者留下已登录会话，后一个 Agent 便不再面对相同条件。

作者建议每项任务使用独立环境，并在开始前恢复预定的数据、配置、权限和相关历史。隔离用于约束操作影响，重置用于还原起点，两者解决的问题不同。

起点不一致，成功率就很难直接比较。

这也是为什么只清理工作区文件还不够：如果缓存、配置或认证状态仍在，下一轮评测依然可能享受到上一轮留下的便利。

我的判断

我认同文章最有价值的一点：把评测从「给 Agent 出题」推进到「设计一段可验证的工作过程」。对于需要查文档、装工具、处理报错的任务，只检查最终回答确实不够。

不过，这篇更接近实践方法说明。作者给出了他们团队使用的任务和遇到的限流问题，却没有提供环境改造前后的成功率、重复运行次数，也没有 Codex 与 Claude 的对照数据。因此，四部分设计是否带来多少收益，目前只能视为经验之谈。

原文没有展开另一个难点：怎样判断某个简化会不会改变任务难度。模拟工具返回过于规整，可能让 Agent 更容易处理；文档入口藏得过深，也可能把业务任务变成检索测试。两者都需要结合真实使用路径判断，不能仅凭「更复杂」就认定「更真实」。

与直接连接真实服务相比，模拟服务更便于控制条件；真实服务则能暴露模拟器未覆盖的问题。我更倾向于按待验证的问题选择环境，并明确结论的边界。验证恢复逻辑时可以控制故障，判断实际服务兼容性时则需要真实调用的证据。

能拿来做什么

• 给 AI 编程工具设计一组小任务，覆盖直接修改、查阅仓库指令和信息不足时请求补充等情况，并为每项任务写清可检查的结果。
• 评测 Node CLI 或项目安装流程时，把依赖状态、当前目录、已有配置和缓存纳入起始条件，每次运行前恢复，避免把环境便利误判为 Agent 能力。
• 为依赖外部服务的任务加入明确记录的失败场景，检查 Agent 是否读懂错误、找到恢复说明并继续执行，同时区分主动注入的故障和测试环境异常。
• 对需要人工登录的流程，单独定义交接成功标准，检查 Agent 是否能准确说明接下来需要用户做什么，再与完整业务流程的完成情况分别记录。