「你刚才说点一遍，点的是哪条流程？」
「查一条工单，能查到。」
「那我让它查完拟一条催办，等我确认再发。结果它直接发了。你那套评测能查出来吗？」
这下就知道该聊什么了。给 Agent 换了提示词、工具或者上下文管理，怎么知道原来能干的活还干得好？要是跑坏了，去哪里查？这些问题，我会按下面四步回答。
1. 先挑 30 道题，每道都说得清怎么判
我会从实际任务里挑 20 条，覆盖单工具查询、跨工具执行、中途变更需求。来源可以是有权使用的历史请求和人工处理记录。产品还没上线，就找将来真要用的人，请他带一件最近办过的事来演示。把原话、当时能查到的数据和账号权限留好，再另挑 10 条曾经失败或风险较高的场景。数字是起步用的，题怎么选比凑够 30 道重要。
拿工单 Agent 举例，我会这么选。
日常任务和风险题分开出成绩。故意多测了越权、超时和重复写入，就别把这一组的失败比例当成用户平时会遇到的概率。相反，日常查询全过，也不能替一条提前发送的失败抵账。
每道题在跑之前定验收。比如「给客户拟一条催办，等确认再发」，我会在隔离环境里准备对应的工单和客户数据。跑完直接查草稿和发送记录。草稿写得挺好，但用户没确认，消息已经出去了，这趟就判失败。再补一个用户必须确认才发送的版本，看它能不能在批准后发给正确的人。这样也能防着它为了过题，干脆一条都不发。
2. 旧版先跑，新版做同一张卷子
假设这次改的是上下文压缩。我会让旧版和新版跑同一批题，固定模型、工具、初始数据、权限和预算，只换压缩策略。每趟清空会话、重置测试环境，免得新版捡到旧版留下的草稿。关键题每版各跑 3 次。报告里一道题占一行，左边记旧版过几次，右边记新版过几次。旧版三次都过，新版只过一次，就点开这道题的两条失败记录。
这里的「一次」是一趟完整任务。中间调了几次工具、遇到报错自己又试了一次，都算在这趟里。该向用户确认的就确认。要是工程师看了日志，告诉它「你发错客户了，重来」，那就记为人工介入，修完的成绩另外算。超时和预算用光也要记下来，别只剩成功的那几条在表里。
最后我会看同一道题两版都做成时，谁更快、谁更省 Token。再用整组运行费用除以实际通过的次数，失败和重试的钱也算进去。人工接手花的时间另记。新版本跳过确认，当然能回得快一点。用户是少等了几秒，还是压根没来得及点头，光看耗时看不出来。
3. 失败了就翻 Trace，找到第一处不对劲的地方
还拿提前发送这道题说。打开执行记录，先看工具有没有把「待确认」这个状态返回，再看压缩后实际交给模型的内容里还有没有它。如果压缩前有，压缩后只剩「草稿已完成」，就拿同一份输入查上下文组装。如果模型看到了「待确认」，自己却选了发送，就查它收到的指令和工具描述。如果模型明明选了等待，发送工具却照样被调用，那就去查编排，也就是负责决定下一步实际执行什么的代码。
修完我会做两次检查。第一遍用录下来的工具响应，检查关键状态能不能保住，或者在没批准时发送工具能不能拦住。第二遍让模型重新跑完整任务，再查发送记录。第一遍好复现，也方便定位。第二遍才知道换了新版本，Agent 碰到这道题到底会怎么做。把上一次的模型回复原样播出来，当然不会告诉你这一次模型会怎么选。
4. 发版前看退步的题，再看省了多少
本地开发先跑改动影响到的用例，合并前再跑一批关键回归。耗时长、需要反复跑或者要模拟断线的题，可以放到定时任务。准备发版时，再拿一批平时没用来调提示词的任务，把候选版和稳定版并排跑。只换了客户名的近似用例要分到同一组，免得留出题看着没见过，实际就是昨天改到通过的那道。
发版条件在开跑前定好。比如发现未经确认就发送，查实就拦。普通任务的通过率和成本允许波动多少，按业务影响定。结果刚好卡在门槛，两版按同一个规则补跑。哪道题真的退步了，就留下最小复现，放进下次的回归集。
面试官要是最后问「那你这次发不发」，我会先翻到退步的那几道题。如果新版确实省了 Token，但有一条消息在确认前发了，我会先修发送这一步。省下来的账，等它能按要求办完再算。
