没有生产日志时，AI Agent 上线前的评估集应该怎么做？

1. 从产品承诺和失败代价出发，不从随机 Persona 出发

列出 Agent 上线时明确承诺完成的任务，例如查订单、改预约、生成报告或修改代码。每条承诺至少对应一个正常案例、一个信息缺失案例和一个工具失败案例。

再列出绝不能发生的结果：越权操作、写错客户数据、泄露隐私、重复付款、未确认就执行不可逆动作。高代价失败即使未来出现频率低，也应该在 Day‑0 评估里占一席之地。

2. 把案例写成可验证的状态转换

对会调用工具的 Agent，只判断最终回复是否“听起来对”远远不够。记录任务开始前的数据库、文件或应用状态，以及任务结束后应该出现的目标状态。τ-bench 和 OSWorld 都强调用环境结果判断完成，而不是只读模型文本。

一个案例应包含：输入或用户目标、初始环境、可用工具与权限、成功状态、禁止状态、超时与停止条件、确定性评分器。无法二值判断的语气或解释质量，再交给人工或模型评分。

3. 覆盖不同失败层，不追求虚假的“大而全”

把测试分成任务理解、计划、工具选择、参数、状态恢复、规则遵循和最终验证。AgentBench 的多环境结果说明，长程推理、决策和指令遵循不是同一个问题；一个总成功率会掩盖真正的薄弱层。

种子集应小到每个失败都能被人解释和修复。只有当新案例覆盖了新的承诺、风险或历史失败时才加入，不要为了看起来像数据集而批量生成同义改写。

• 正常路径：信息完整、工具可用、目标明确。
• 模糊路径：缺字段、目标冲突、用户中途改变要求。
• 工具路径：超时、部分成功、重复响应、返回旧状态。
• 安全路径：权限不足、隐私请求、不可逆操作、提示注入。
• 恢复路径：重试后状态是否一致，是否产生重复副作用。

4. 重复运行，测可靠性而不是一次演示

同一个 Agent 在同一案例上成功一次，不代表生产稳定。对关键案例重复运行，报告单次成功率和连续多次均成功的比例。τ-bench 使用 pass^k 揭示多次交互中的不一致性。

同时记录成本、延迟、工具调用次数、人工升级率和失败后是否能安全停止。HELM 的多指标思路适合这里：准确只是一个维度，鲁棒性、效率和安全同样决定能否上线。

5. 上线后让真实 Trace 接管覆盖面

为生产 trace 预先定义失败标签，例如目标未完成、工具参数错误、越权、状态漂移、错误拒绝和用户放弃。每天或每周抽样，把新的真实失败最小化成可重复案例。

合成案例可以被真实案例替换，但不要删除最初的高代价风险种子。生产频率和风险严重度不是一回事：很少出现的付款或隐私失败，仍应长期保留为回归门槛。