先看回复
是否正确理解意图；信息不足时有没有追问；没有执行成功时是否如实表达。
返回精选项目
Agent 说创建成功，
Agent 评测 / 产品策略
Schedule Agent Eval
Agent 说创建成功，
任务真的创建了吗？
围绕信息缺失、跨时区、周期任务、多轮修改和工具异常，我从用户日志中建立固定评测集，把判断对象从“回复是否自然”推进到“任务是否真实、正确并可执行地落地”。
01 / 问题
自然的回复，
不代表正确的结果
语言质量仍然重要，但在能操作真实系统的 Agent 中，它只能证明“说得像对的”。最危险的失败，是 Agent 明确回复任务已经创建，而系统里没有任务，或时间、周期、时区和状态与用户意图不一致。
再看工具与参数
调用动作、任务类型、日期、时间、时区、频率和目标任务标识是否正确。
最后看系统状态
任务是否真实存在，配置与状态是否一致，后续实例是否能按预期执行。
系统真实状态
高于工具返回
高于参数记录
高于Agent 回复
02 / 成功标准
先把“任务成功”拆成
可以逐项核验的门槛
我把一条用例从用户表达一路检查到任务实际执行。信息不足时必须正确追问；信息充分时不能多问；时间、时区、周期和最终参数必须与最后一次用户意图一致；工具调用、系统状态和最终回复也必须相互匹配。
严格判定
任一关键核验点失败，整条用例即判定失败。只有所有门槛同时通过，才计入端到端任务成功率。
- 01理解与追问
定位意图，只在关键信息缺失时追问。
- 02时间与参数
核对日期、时区、周期和最终参数。
- 03工具与系统
调用可信，任务在系统中真实存在。
- 04回复与执行
回复符合系统事实，任务能够按时执行。
03 / 固定评测集
评测题不是拍脑袋写的，
而是从真实使用中长出来
我先从用户日志抽取高频问题，再按任务类型和失败模式归类。主路径用例保证基础体验，边界与极端用例主动撞击时间、时区、多轮上下文和格式约束；线上出现的新问题则持续加入固定评测集。
- 01收集用户日志
从真实表达开始，不靠想象用户。
- 02提取高频场景
合并同类需求与重复失败。
- 03场景分类
按意图、风险和失败层拆分。
- 04构建评测问题
补齐正常、边界、极端与异常恢复。
- 05制定评分标准
固定预期处理与关键核验点。
- 06持续更新
把新失败沉淀为回归用例。
创建、修改、暂停和恢复等高频主路径。
信息缺失、无效日期、模糊时间和时区歧义。
长上下文、多轮改写、复杂周期和冲突约束。
从日志中抽取高频表达与已发生的失败模式。
用户问题样例
每道题都同时写清“怎么回答”和“系统里应该发生什么”
一条用例固定输入、上下文基准、期望处理、关键断言和最终判定，避免优化前后临时改变标准。
| 场景 | 用户问题 | 期望处理 | 关键核验点 | 通过标准 |
|---|---|---|---|---|
| 信息缺失 | “提醒我交周报” | 追问具体日期或周期与时间 | 追问字段是否完整；此时不得调用创建工具 | 补齐信息前，系统中没有新增任务 |
| 周期任务 | “每天 9:30 推送 AI 新闻” | 创建每日 09:30 的周期任务 | 任务类型、频率、时间、时区与后续实例 | 任务真实存在，并持续生成正确实例 |
| 无效日期 | “2026-02-30 提醒我提交材料” | 识别日期无效并要求用户修正 | 不能静默改日期，不能调用工具或声称成功 | 回复明确指出问题，系统状态不变 |
| 跨时区 | “伦敦时间周五下午 3 点提醒我开会” | 按目标日期的伦敦时区解释 | 时区、夏令时、日期基准和最终执行时间 | 回复、参数与任务系统中的时间完全一致 |
| 多轮修改 | “每天提醒我运动；改成工作日；再改成 19 点” | 合并多轮信息，以最后一次明确意图为准 | 工作日、19:00，其余旧参数不应残留 | 最终只保留一条正确配置的任务 |
| 工具异常 | 创建工具返回超时 | 先核验系统状态，再决定重试或说明未确认 | 不得提前回复成功；重试需要幂等 | 最终只存在一个任务，或明确告知失败 |
04 / 失败归因与优化
失败发生在哪一层，
决定下一步具体改什么
我不把失败笼统归为“模型不稳定”。每条失败先从系统状态向上追溯，依次核对工具返回、参数记录和对话理解，再判断应该修改 Prompt、参数校验还是产品规则。
案例 / 虚假成功
回复说“每天”，
工具却创建成了“单次”
用户需要每日任务，Agent 也承诺每日执行，但工具参数把周期任务映射成单次任务，系统只生成一个实例。回复自然、工具也返回已接受，仍然必须判定失败。
归因 / 四个断点
先找最早出现偏差的环节，
再选择产品动作
同一个失败表象可能来自完全不同的根因。相对时间理解错误需要补边界样本；本应追问却直接执行需要提高 Prompt 门槛；周期被传成单次需要参数一致性校验；工具成功但系统查不到任务，则需要创建后回查与成功回复门控。
我实际推动的调整
每个策略动作都对应一类失败证据和一组回归用例
失败证据
归因
采取的动作
同集回归核验
信息不完整却直接创建任务
Prompt 策略把“信息不足需要追问”从软提示改为创建前门槛；一次补齐必要字段。
缺日期、缺时间、模糊时段时不调用工具，补齐后才创建。
周期任务被传成单次，回复仍声称每天执行
工具参数校验任务类型、频率和执行周期的一致性；调用前回读最终参数。
每日、工作日、双周和月末任务均核对后续实例。
跨时区任务时间正确，但时区基准缺失
Prompt + 参数相对时间、模糊时段与跨时区表达增加澄清规则；参数显式携带日期基准与时区。
覆盖伦敦、纽约、东京与夏令时切换边界。
工具超时后 Agent 直接回复创建成功
产品规则系统状态未核验前禁止成功回复；超时重试加入幂等约束。
查询不到任务时必须说明未确认，重试后系统中只能存在一个任务。
多轮修改后仍保留旧时间或旧周期
Prompt 策略以最后一次明确意图为准，调用工具前合并并回读最终参数。
连续修改名称、周期和时间后，只核验最终配置。
回复已暂停，但系统仍在生成后续实例
产品规则创建、修改、暂停、恢复后回查任务状态；失败时保持原状态并明确反馈。
同时核对状态字段与未来实例变化，不能只看回复文案。
闭环 / 同集回归
调整以后，继续用同一批题验证
我没有换一批更容易的问题来证明优化有效。策略调整后保持测试输入、环境、成功门槛和指标分母不变；复现过的失败继续沉淀为固定用例，防止后续版本再次出现。
05 / 结果与反思
三个结果，来自同一套
成功标准和判定口径
优化前后都使用同一批 50 条固定测试用例。端到端任务成功率要求整条成功链全部通过；虚假成功率专门捕捉“回复承诺成功，但系统事实不支持”的高风险失败。
同时通过全部关键核验点的用例数50 条固定测试用例
理解、追问、时间、时区、参数、工具调用、系统落地、回复一致性与可执行性必须全部通过。声称成功但系统未正确落地的用例数50 条固定测试用例
系统中任务不存在、状态错误，或关键参数与最终用户意图不一致，均计入虚假成功。产品判断
Agent 的可信度，不来自一句流畅的成功回复
真正建立信任的是：信息不足时知道追问，执行失败时如实说明，并让最终回复、工具参数和系统真实状态保持一致。评测不是上线前的一次检查，而是连接日志、策略、产品规则和版本质量的长期资产。
我的贡献
- 从用户最终结果出发定义端到端成功
- 从用户日志构建 50 条固定评测集
- 建立逐条核验门槛与两项产品指标
- 把失败转化为 Prompt、参数和产品规则动作
- 用同集回归验证优化并沉淀后续质量门槛