什么是评测？如何测试代理及其使用的软件
内容提要
文章讨论如何为AI代理构建端到端评测以衡量其完成用户任务的成功率。作者以咖啡下单CLI为例，提出代理测试金字塔（确定性测试、单轮评测、端到端评测），并给出五步流程：设定目标、定义指标（成功率、pass@k、pass^k、步数、时间、成本）、设计任务集、用Harbor运行评测、分析轨迹找出失败根因并迭代改进。
延伸解读
为什么端到端评测对代理至关重要
文章指出，代理可能成功下单却下错饮品（如热拿铁而非冰拿铁），而传统日志只记录请求成功，无法反映用户意图是否满足。由于LLM输出存在随机性，单次手动测试无法判断修复是否有效，必须重复相同任务并评分结果。端到端评测通过让代理在完整环境中执行任务并检查最终状态，能捕捉单步看似合理但整体错误的情况，这是确定性测试和单轮评测无法覆盖的。
选择正确指标：pass@k与pass^k的区别
文章用咖啡订单例子说明，pass@k衡量k次尝试中至少一次成功的概率，回答“代理能否做到”；pass^k衡量k次全部成功的概率，回答“能否每次都可靠”。对于早晨咖啡这类失败代价高的场景，用户没有重试机会，应优化pass^k；而对于编码代理等失败可廉价重试的场景，pass@k更合适。指标选择取决于失败对用户的实际成本，不能盲目追求单一数字。
任务设计需覆盖边界与“不应行动”场景
文章建议任务集应包含常见情况、易错边界以及至少一个正确做法是不行动的任务。例如“不可能请求”任务中，代理应告知用户无合适选项，而非强行下单。其验证器还需检查代理是否先搜索再放弃，防止代理未经尝试就给出否定答案。每个任务需定义指令、环境、验证器和可选已知良好解决方案，环境可部分真实部分模拟，但需保护种子数据和验证器代码，防止代理作弊。
轨迹分析揭示失败根因与误导性通过
文章强调，分数只告诉失败频率，轨迹才能解释原因。通过阅读失败轨迹，发现代理可能将菜单价误认为最终价而跳过报价步骤，从而超预算。同时，通过轨迹也能发现误导性通过：例如代理未搜索就放弃，却被验证器误判为成功。文章还提到，首次运行可能因代理不知道工具存在而全部失败，这属于发现阶段问题，需在指令中明确工具名称。分析后应针对根因提出具体修复并重新运行对比基线。
Q&A
什么是代理测试金字塔？它包含哪几个层级？
代理测试金字塔按LLM调用次数将代理软件测试分为三层：确定性测试（0次LLM调用）、单轮评测（1次LLM调用）和端到端评测（整个任务中2次以上LLM调用）。金字塔建议从最底层开始，用最低层级捕获问题；对于成功性评估，则需要顶层端到端评测。
如何为AI代理构建端到端评测？具体步骤是什么？
构建端到端评测分为五步：1. 设定目标：从可观测性、客户反馈或路线图中选择一个用户关心的结果；2. 定义指标：包括成功率、pass@k、pass^k、步数、时间和成本；3. 设计任务集：包含常见案例、边缘案例和不应行动的任务，每个任务需有指令、环境、验证器和可选已知良好解决方案；4. 运行评测：使用Harbor框架在容器中运行代理并记录结果；5. 分析轨迹：检查失败和通过的轨迹，找出根本原因并迭代改进。
pass@k和pass^k有什么区别？分别适用于什么场景？
pass@k表示k次尝试中至少有一次通过的概率，回答“代理能否做到”；pass^k表示k次尝试全部通过的概率，回答“代理能否每次都可靠”。选择取决于失败对用户的代价：如果失败代价高（如早晨咖啡订单），应优化pass^k；如果失败代价低且可重试（如编码代理有测试套件），则pass@k更合适。
在设计评测任务时，如何防止代理作弊（奖励黑客）？
需要保护种子数据和验证器代码，确保代理只能通过产品工具（如CLI）修改被检查的状态。例如，在咖啡订单评测中，cafes.json应放在代理环境之外，并限制代理只能通过CLI更新订单记录，防止代理直接编辑库存或orders.json来通过验证。
如何分析评测轨迹并利用结果改进代理？
分析轨迹时，不仅要看失败案例，也要抽样查看通过案例，因为通过只代表验证器被满足。通过阅读轨迹（如trajectory.json）可以找出失败的根本原因，例如代理跳过报价步骤导致超预算。然后针对性地修复（如添加--max-total标志），重新运行相同任务并与基线比较，确认修复有效且未引入新问题。
Harbor是什么？它在评测中起什么作用？
Harbor是一个开源框架，由Terminal-Bench的创建者开发，用于在容器中运行代理、检查结果并记录其行为。它支持并发运行试验、缓存任务环境，并与Vercel Sandbox和AI Gateway集成，方便大规模运行端到端评测。
