Agent 怎样评测？把任务结果和执行过程分开看
先定义什么叫完成
Agent 返回一段看起来合理的文字，不代表任务已经完成。查询订单应返回正确订单；创建工单应在目标系统留下正确且唯一的记录；资料调研则应提供能支持结论的来源。评测标准必须落到业务结果，而不是模型是否自称成功。
为每类任务明确输入、允许的动作、预期结果和不能发生的行为。可自动判定的条件优先用代码检查，例如字段、状态、记录数量和访问范围；开放式质量再引入人工或模型评审。
测试集怎样构成
第一批可以来自真实常见问题和已经发现的失败案例，覆盖正常完成、信息不足、参数歧义、工具失败和越权请求。数据应脱敏，工具指向隔离环境，避免评测发送真实邮件或产生实际扣款。
把开发时反复调提示词的样本与保留评测样本区分开，否则很容易只记住题目。模型、提示词、工具 schema 和测试集版本都要记录，才能解释一次分数变化来自哪里。
结果与过程分别计分
结果层观察事实正确性、字段完整性、来源支持和是否完成业务目标。过程层观察是否选择合理工具、参数是否正确、有没有重复写入、是否访问无权资源，以及失败后是否安全停止。
同一个结果可能由危险过程得到。例如 Agent 最终返回了正确工单号，却先重复创建又删掉多余记录；单看最终文本会漏掉这个问题。另一方面，不必强制所有任务都走唯一工具序列，合理的替代路径也应被接受。
如何使用模型评审
给评审器清楚的判定项和参考证据，比要求它“整体打分”更容易复核。对边界样本做人工抽查，检查评审是否偏好长答案或被待评文本中的指令影响。不能让被评 Agent 的解释替代真实执行记录。
Agent 存在随机性，重要样本应重复运行，观察成功与失败分布。不要只展示最好的一次，也不要在没有定义分母和样本来源时宣称某个准确率。
一次可操作的回归
当工具响应超时导致重复工单时，保留任务输入和受控失败条件。修复后检查下游只有一条记录、Agent 没有越过预算、用户收到准确状态。再运行原有正常样本，确认修复没有让所有写入都停住。
本文提供评测设计，未执行具体 Agent 实验。面试时可以按“任务定义、样本来源、结果检查、过程约束、失败回归”讲清方法，并报告实际测得的耗时和成本；没有数据时说明计划如何测量。