Agent 的演示很容易做得漂亮。输入一句话，它搜索、计算、整理，一分钟后给出一段完整答案。这个过程跑通一次，只能证明有一条成功路径。换一种问法，接口慢两秒，或者检索到两份冲突资料，结果可能完全不同。
所以评估要从真实任务开始，而且要重复跑。
先攒一批真实任务
我不太建议从“准确率要达到多少”开始讨论。先收集二三十个团队真的会交给 Agent 的任务，每个任务写清目标、输入约束、可用工具、预期产物和禁止发生的事。
任务难度可以混着放：查一条订单这样的单步题；检索政策、计算金额并生成草稿的多步题；还有权限不足、资料冲突、接口超时和信息缺失。标准答案也不必是一段固定文字，列出必须出现的字段、证据和业务限制往往更好评分。
同一个任务再准备几种说法。只测一条固定提示词，最后测到的可能是模型对措辞的记忆。
最终答案只占一部分
一次任务至少看下面几项：
| 项目 | 要检查什么 |
|---|---|
| 任务结果 | 用户要的东西有没有真正完成，字段是否齐全 |
| 工具轨迹 | 调了哪些工具，参数对不对，有没有空转或重复调用 |
| 检索与引用 | 正确证据有没有被召回，引用能否支撑对应结论 |
| 权限 | 有没有读取无权访问的数据，写操作是否经过确认 |
| 成本与时延 | token、调用次数、重试次数，以及 P50、P95 时延 |
这些项目会打架。多检索两轮可能提高召回率，也会增加成本和等待时间；加一道人工确认会降低自动完成率，却能挡住高风险错误。别急着揉成一个总分，分开看更容易决定要改什么。
评分尽量让人看得懂
另一个模型可以帮忙初筛，关键任务仍要人工抽查。评分项写得越具体，复核时争议越少：
任务完成：0/1
关键字段齐全：0/1
引用支持全部关键结论：0/1
发生越权动作：0/1（出现即失败）
无意义工具循环：0/1
每次运行保存输入、模型版本、工具版本和完整轨迹。升级模型或改提示词以后，用同一批任务重放。要不然团队只会记得新版表现最好的一次。
“模型答错了”这个结论没法修
失败应该按发生位置归类：意图判断错了，检索没召回，重排丢了正确证据，参数校验失败，权限判断漏了，工具结果没解析对，循环没停，或者最终格式不合要求。
分类以后，修法通常很具体。检索漏召回就查切块和过滤条件；工具参数老填错就收窄 schema；循环空转去改停止条件。不是每个问题都值得再加一段提示词。
Agent 有随机性，同一道关键题最好跑几次，记录成功率和最差轨迹。偶然成功不能遮住连续失败。越权动作则相反，出现一次就该停下发布检查。
上线以后继续收，但少收一点
线上可以记录脱敏后的轨迹摘要、结果是否被采纳、人工改动比例和失败反馈。身份证件、订单详情和原始对话这类内容按最小范围保存，并设置保留时间。
线上案例进入回归集前要脱敏、复核。用户没有投诉，不代表答案就是对的；一段错误答案也不能因为被复制过，就自动变成标准答案。
发布门槛写在前面
我会为关键任务先写几条硬门槛：成功率达到约定值，高风险工具零越权，关键结论有出处，P95 时延和单次成本没有超预算，异常任务能在规定步数内停下来。
某项没过时，缩小自动执行范围或加一道人工确认都可以。最怕的是演示已经排好了，指标才开始临时解释。