从真实开发需求构建Agent评测集

Agent 能不能用好你的产品，不能只看它有没有生成一段像样的回答。更有用的评估，是让它完成用户每天真的会做的事：安装 CLI、执行核心操作、排查错误，再检查结果是否达标。

作者给出了一套五步方法：从真实工作流选题，明确成功标准，加入常见变数，验证评判方式，再持续维护任务集。它值得读的地方，是把「测测 Agent 好不好用」变成了可以重复执行、定位问题的工程流程。

评估任务应该从用户的日常工作里选

任务数据集不是一组随手写的提示词。每个任务都要交代三件事：Agent 要完成什么、从什么数据和环境开始、最后如何确认成功。

作者建议从用户依赖的工作流入手，覆盖首次使用、核心操作和常见故障处理。选题时看两个维度：用户多常遇到，以及做错后的后果。高频任务值得优先覆盖，低频但后果严重的任务也不能漏掉。

再按工作流分组，才能看见覆盖缺口。例如，安装流程测得很细，错误恢复却完全没测，整体通过率就很难代表实际体验。

评估的单位应该是可验证的工作结果，而不是一段看起来合理的回答。

这里也有一个信息缺口：原文在列举任务来源的位置写了「Draw from:」，但提供的正文没有后续列表。因此，作者具体从哪些渠道收集真实需求，并没有说清。

成功不一定是执行完，也可能是先停下来

明确任务目标之后，要写清可检查的输出或状态变化，同时记录起始条件，把必要要求告诉 Agent。

但任务说明不能把答案提前喂进去。如果你想评估 Agent 能否找到相关文档，就需要保留发现文档这一步；如果只想评估操作执行，则可以提供相应信息。提示给多少，取决于你究竟想测什么。

成功标准还应允许不同的有效路径。只要结果满足要求，就不该因为操作顺序与预设答案不同而判错。

接下来，在已经能跑通的任务上加入日常变数。原文给出三个例子：

• 凭证已经过期。
• 用户没有指定目标位置。
• 要创建的资源已经存在。

这些情况测的不只是操作能力，还包括决策是否恰当。目标不明确时，成功可能是请求澄清；需要授权时，成功可能是请求批准；条件不满足时，成功也可能是解释为什么无法继续。

如果评判方式只接受「资源创建成功」，就可能把合理的暂停判为失败，反过来奖励擅自猜测。

先验证判题方式，再比较通过率

任务写好后，作者建议先试跑，确认描述清楚、目标可达。随后，用已知正确和已知错误的结果测试检查逻辑：不同的有效方案都应通过，不满足要求的结果则应被拒绝。

这一步很容易被忽略。一次失败既可能来自 Agent，也可能来自含糊的任务描述或错误的判定规则。作者建议在 Quantiles 中查看通过和失败的交互记录，区分问题出在哪里。

任务和检查逻辑准备好以后，再进行多次试验，观察完成情况是否稳定。每次试验前，都要把环境恢复到任务规定的起始状态，否则上一次留下的资源或数据可能影响下一次结果。原文称，Quantiles 会自动为每个任务运行多次试验，但没有提供具体次数或实测结果。

维护任务集时，还要保留可靠的工作流作为回归检查，记录任务说明、初始数据和验证逻辑的变化，并持续补充新的使用情形。

作者特别提出：留出一部分任务，不参与文档或技能的改进过程，再用它们检查改进能否迁移到其他工作流。大白话就是，别只拿反复练过的题证明自己进步了。

我的判断

我认可这套方法对「成功」的处理：它把澄清、批准和无法继续的解释纳入评估，更接近日常开发中的真实协作。相比只检查最终回答文本，它更能发现产品文档、操作流程和 Agent 决策之间的断点。

不过，这是一套方法建议，原文没有给出任务样本、通过率变化、成本数据，也没有比较采用前后的效果。不能据此认定它已经证明了某种评估方案更优，更不能把 Quantiles 的产品描述当成效果证据。

它还有一个实施前提：团队能够重建起始环境，并可靠地验证结果。安装 CLI 这类任务相对容易界定；依赖外部账户、权限和已有资源的操作，准备成本可能更高。作者强调了重置环境，但没有展开这些成本怎么控制。

对一般团队来说，先把少量关键任务的目标、条件和检查方式写扎实，比一开始追求很大的任务集更有价值。这也符合作者从少量真实任务起步的建议。

能拿来做什么

• 如果你维护 CLI 或开发者工具，可以先选安装、核心操作、常见报错各一个任务，分别写清初始环境和可检查的结果，形成第一版评估集。
• 在日常 AI 编程评估中，可以给同一任务加入凭证过期、目标缺失、资源已存在的变体，并提前规定何时应该继续、询问或停止。
• 调整产品文档或 Agent 技能后，可以重跑已有任务，同时检查没有参与调整的留出任务，判断改进是否适用于更多工作流。
• 遇到失败记录时，可以同时检查 Agent 的行为、任务描述和验证逻辑；做多次试验前，先确认环境能够恢复到相同起点。