差旅助理回复：“机票已经为你预订好了。”这句话读起来很顺畅，用户也可能暂时放心。但如果预订系统里没有订单，任务仍然没有完成。评测 Agent 时，产品团队需要核对外部系统里实际发生了什么，再检查关键步骤是否遵守了业务约束。
此前介绍大模型评测时，我们讨论过评测集、评分方式和版本对比。这篇文章把范围缩小到 Agent 的整项任务：它接收目标、调用工具、可能与用户反复沟通，最终还可能改变订单或其他业务状态。判定成功的依据，不能停留在最终那句话。
任务完成，要有可以核对的结果
Anthropic 在 Agent 评测文章里区分了执行轨迹和环境结果。轨迹记录 Agent 的回复、工具调用和中间步骤；环境结果是一次尝试结束后，外部系统呈现的最终状态。文章举了航班预订的例子： Agent 即使声称已经订票，评测仍需检查预订记录是否真实存在。Anthropic ： Demystifying evals for AI agents[1]
产品经理可以把一项任务拆成三个可验收的问题：
1.目标是否达成？ 用户要求的业务结果是否真的发生，例如订单已创建、权限已调整、工单已提交。2.条件是否满足？ 日期、预算、对象、数量等约束是否与用户要求一致。3.过程是否越界？ 需要确认的动作有没有提前执行；遇到异常时有没有如实告知；有没有重复产生副作用。前两项主要检查结果，第三项检查关键过程。 OpenAI 的 Agent 工作流评测文档说明，端到端轨迹能够呈现模型调用、工具调用、安全检查与交接等环节，帮助团队找到退步和失败原因。OpenAI ： Evaluate agent workflows[2]
因此，结果检查决定任务有没有完成；过程检查解释任务怎样完成，以及是否触碰关键边界。两者共同支持上线判断。
为任务定义四种结束状态
如果只设置“成功/失败”，产品团队容易把尚待外部确认的任务归错类。更实用的做法是结合业务设定几种可区分的结束状态：
•已完成：业务系统能提供结果证据，所有关键约束都满足。•部分完成： Agent 已经完成查询或整理，但尚未达成最终业务目标。•待确认：用户授权、供应商回执或人工审核尚未到位，继续等待明确结果。•失败：关键步骤没有完成，或者结果违反重要约束，需要重新处理或人工接管。这是一种产品设计上的状态划分。具体系统可以使用不同名称，但每个状态都应有可核对的进入条件。尤其要防止“工具请求发送成功”被误读为“业务处理已经生效”。
假设教学示例：差旅预订助理
下面是一个假设的产品教学示例，不代表真实预订系统、用户经历或效果数据。
一位员工希望预订下周二从上海前往北京的航班，预算上限为 1200 元，要求出发时间在上午。她提供出发城市、目的地、日期、时间范围和预算，差旅 Agent 负责查询候选航班、展示可选项、取得必要确认，然后调用预订工具。
这项任务的评测卡可以这样写：输入是员工要求与可用航班数据；预期输出是符合日期、航线、时间和预算的有效订单，以及能供员工核对的订单信息；结果证据是预订系统里的订单编号、订单状态和行程明细。仅有一条“预订成功”的聊天回复，没有订单记录，仍然不能判定完成。
过程检查则聚焦少数会改变结论的节点： Agent 是否沿用正确日期和预算；下单前是否取得流程要求的确认；预订接口超时后是否查询订单状态，避免重复下单；没有符合条件的航班时是否如实说明。产品经理还需要检查用户看到的最终提示，能否和后台订单状态保持一致。
为了避免只在顺利场景里得到好成绩，首版评测集至少需要覆盖几类代表性情况：条件齐全且有可选航班；缺少出行日期；符合时间但超出预算；用户拒绝确认；预订请求超时而订单状态暂时未知。每条样本都先写清目标、初始环境、允许的动作和判定依据，再运行 Agent 。样本数量和通过门槛应由实际业务风险决定。
评分时避免两个误区
第一个误区是只给最终回复打分。语言自然、态度礼貌值得关注，却无法证明订单真实存在。对预订任务，程序规则可以核对订单状态、日期与金额；需要理解含糊表达时，可以辅助使用模型评分；争议案例交由人工复核。 Anthropic 的 Agent 评测文章也建议按任务性质组合程序、模型和人工评分，并提醒评测者关注最终环境结果。Anthropic ： Demystifying evals for AI agents[3]
第二个误区是规定唯一的“正确操作顺序”。 Agent 可能通过不同但有效的路径完成同一目标。如果把每一步工具调用顺序都写死，评测会把合格结果误判为失败。需要严格约束的，应当是用户授权、金额上限、禁止重复下单等关键边界。其余过程可用于定位问题，不必全部作为硬性门槛。 Anthropic 也提醒，过度依赖固定轨迹会使评测变得脆弱。Anthropic ： Demystifying evals for AI agents[4]
产品经理怎样建立首版任务评测
可以从一类高频任务开始：先写明用户真正想得到的业务结果，再找出系统中可以查询的结果证据；接着列出必须遵守的限制和可能中断的节点；随后挑选正常、信息不足、约束冲突和系统异常的代表性案例。每次修改提示词、工具或流程后，使用相同的任务集再次运行，并把失败样本加入后续回归检查。 OpenAI 的文档也将轨迹检查与可重复的数据集、评测运行结合起来，用于比较 Agent 工作流的变化。OpenAI ： Evaluate agent workflows[5]
当 Agent 说“已经完成”，产品经理最终需要追问的是：哪个业务系统能够证明这件事，哪些用户条件得到了满足，执行过程中有没有越过必须遵守的界限？把这三个问题写成可执行的检查项，任务评测才能真正服务产品决策。
参考链接
[1] Anthropic ： Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[2] OpenAI ： Evaluate agent workflows: https://developers.openai.com/api/docs/guides/agent-evals
[3] Anthropic ： Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[4] Anthropic ： Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[5] OpenAI ： Evaluate agent workflows: https://developers.openai.com/api/docs/guides/agent-evals
