一个 Agent 在演示里完成过一次任务，不等于它已经可以进入真实工作流。
演示通常只有一个输入、一个顺利路径和一个漂亮结果。真实任务却会遇到资料缺失、工具超时、权限不足、重复提交、格式异常和用户临时改口。只看最后一段回答，无法知道 Agent 是真的完成了任务，还是碰巧走通了这一条路径。
上线前验收真正要回答的是：在什么版本、什么权限、什么数据和什么任务范围内，它能稳定完成哪些事情；遇到不能完成的事情时，是否会停下来、说明原因，并把控制权交还给人。
本文给出一套小型但可重复的验收方法。它不提供某个模型或平台的排名，文中的阈值是示例值，应该根据业务风险重新设定。任务集、日志和回归记录是本文的核心产物。
1. 先定义上线决策
验收之前先写清楚结果要服务于哪个决定。至少有四种不同结论：
| 结论 | 含义 | 后续动作 |
|---|---|---|
| 可以上线 | 在限定范围内满足硬性条件，失败有接管路径 | 小范围灰度，不直接全量 |
| 需要人工 | 能减少整理工作，但关键步骤仍需复核 | 保留草稿模式和人工确认 |
| 退回重做 | 目标、输入或工具边界没有定义好 | 重新设计任务和流程 |
| 暂停 | 风险超过当前团队能承担的范围 | 关闭自动动作，保留调查记录 |
不要把“通过率达到 80%”直接当作上线标准。一个低风险的内部摘要任务，和会修改客户订单的 Agent，不能使用同一个门槛。先确定动作风险，再决定哪些指标是硬性阻断项。
一个最小决策表可以这样写：
这里的停止条件比平均分更重要。平均分会掩盖一次不可接受的越权动作。
2. 把真实工作拆成任务卡
不要从 Prompt 开始，而要从用户真正要完成的工作开始。每张任务卡只描述一个可以验收的目标，并固定输入、范围、约束和预期行为。
任务卡的最小字段
任务卡要写“禁止做什么”。如果只写“请完成摘要”，Agent 可能为了看起来完成而主动补全不存在的信息，甚至调用不必要的工具。
任务集至少覆盖六类情况
如果任务集只有正常样例，测到的只是 Agent 的最佳路径。对真实系统而言，“知道什么时候不能做”往往和“知道怎么做”同样重要。
3. 冻结版本和执行环境
一次验收至少记录以下信息：
| 字段 | 记录内容 | 目的 |
|---|---|---|
| 日期 | 执行时间和时区 | 便于判断版本变化 |
| Agent 版本 | Prompt、Skill、代码或配置的提交号 | 区分行为来源 |
| 模型标识 | 实际模型名、推理档位或路由模式 | 避免把模型差异归因于流程 |
| 数据版本 | 固定输入文件、知识库快照或时间范围 | 保证输入一致 |
| 权限 | 只读、工作区写入、联网和审批状态 | 记录行动边界 |
| 依赖 | 运行时、工具版本、服务地址 | 避免环境漂移 |
| 重试规则 | 单任务最大尝试次数和是否允许人工提示 | 防止人为挑结果 |
建议为每一次运行生成一个目录：
如果接口或平台不方便导出完整对话，至少保存任务输入、工具调用、最终输出、错误信息和人工修改。不要只保存 Agent 最后生成的总结，因为它可能漏掉失败尝试和中途的权限拒绝。
4. 验收输出，而不是评价语气
Agent 的输出可以分成三层检查。
第一层：结构
检查输出是否满足机器可以判断的格式：
例如摘要任务可以要求 JSON：
结构检查只能证明“长得对”，不能证明内容正确，但它能先拦截大量无法进入下游的结果。
第二层：行为
行为检查关注 Agent 做了什么：
行为日志应当能回答“为什么得到这个结果”。一次正确输出如果是通过越权读取得到的，仍然应该判定为失败。
第三层：业务
业务检查由熟悉流程的人确认：
业务检查不能完全自动化，但可以通过固定样例、评分说明和双人抽检减少主观差异。
5. 设计可重复的检查器
最小检查器不需要先搭建复杂平台。一个 JSON 输出可以用脚本检查字段和禁止动作：
这个示例只检查结构，不代表内容已经正确。检查器的职责是把“必然错误”快速拦截出来，把需要人工判断的部分留给评审人。
对于工具调用，可以对 tool-calls.jsonl 做白名单检查：工具名称、参数字段、调用次数、是否产生写入，以及写入前是否出现审批事件。实际字段依赖你的运行环境，不能把一套日志格式假设成所有平台的通用接口。
6. 先定硬性门槛，再看平均表现
建议把指标分成阻断项和观察项。
阻断项
下面任一项失败，都不应直接扩大范围：
观察项
这些指标可以用于比较版本，但需要结合任务风险：
数字阈值应该来自基线或业务承受能力。比如“人工修改比例低于 30%”可以作为一个试点假设，但它不是行业标准，更不能脱离任务类型单独解释。
7. 回归测试要测什么变化
Agent 的回归不只是检查代码有没有挂。模型、Prompt、Skill、知识资料、工具权限和路由变化，都可能改变结果。
每次变更至少标记变化层：
| 变化层 | 常见影响 | 必须重跑的任务 |
|---|---|---|
| Prompt | 语气、步骤和拒答边界 | 正常、信息不足、越权 |
| 工具 | 参数、返回结构和权限 | 工具成功、失败、重复执行 |
| 知识资料 | 新版本、删除和冲突 | 引用、过期、冲突资料 |
| 模型或路由 | 格式、延迟和工具调用 | 全部硬性任务 |
| Agent 代码 | 状态、重试和写回 | 全部任务，尤其是有副作用任务 |
可以先建立一份小型黄金集：十到三十个固定任务，包含正常和异常样例。每次提交自动或手动运行，并把本次结果与基线结果对比。黄金集不需要假装覆盖所有场景，它的作用是及时发现已知能力退化。
一个回归记录可以这样写：
8. 失败分类比总分更有用
一次失败至少要归到一个可行动类别：
| 类别 | 现象 | 可能改动 |
|---|---|---|
| 目标误解 | 做了相邻但错误的工作 | 改任务卡和验收文字 |
| 上下文缺失 | 找不到必要资料 | 补输入、索引或来源 |
| 工具问题 | 参数错、超时或返回异常 | 改工具契约和错误处理 |
| 推理或实现错误 | 资料足够但结果不对 | 补样例、检查器或人工节点 |
| 权限边界问题 | 尝试访问禁止资源 | 收紧权限和审批 |
| 环境问题 | 依赖、端口、网络不稳定 | 修复环境后重新运行 |
| 验收问题 | 没有办法判断结果 | 把主观标准改成例子或测试 |
“模型能力不足”不应该成为默认分类。只有排除任务定义、输入、工具、权限和环境问题后，才有资格把问题归因于模型或 Agent 策略。
9. 人工评审怎样减少主观波动
人工评审不等于凭感觉打分。给评审人一张短表，要求逐项给出证据：
高风险任务建议由两个人独立评审一部分样本，先比较分歧，再修改评分说明。不要在看完模型结果后临时更换标准，否则“评估”会变成给既有结论找理由。
10. 一个可以直接执行的最小流程
这套流程可以从本地目录和表格开始。任务数量、日志规模和自动化程度，应该随着风险和调用量增长，而不是一开始就建设一个无法维护的评估平台。
11. 发布前检查清单
12. 结论与限制
Agent 上线验收的核心，不是证明它“足够聪明”，而是证明它在一个明确范围内能够被观察、被复核、被停止和被恢复。
任务集解决“测什么”，版本冻结解决“在什么条件下测”，结构与行为检查解决“结果是否合格”，人工评审解决“业务上是否真的可用”，回归测试解决“下一次改动有没有让已知能力退化”。这几层缺一层，最后的通过结论都可能过早。
本文给出的任务卡、示例阈值和检查器是作者整理的工程模板，不是任何平台的官方验收标准。不同任务需要重新定义关键字段、风险等级和人工门槛；涉及支付、合同、医疗、人事、客户承诺或自动外部写入时，应增加专业审查和更严格的审批与演练。
资料与说明
- Anthropic：Demystifying evals for AI agents：用于参考 Agent 评估中任务、环境、轨迹和结果检查的思路。
- OpenAI：Evals guide：用于参考评估数据集、运行和比较的官方接口说明；具体接口和字段应以当前文档为准。
- OWASP：Top 10 for Large Language Model Applications：用于检查提示注入、敏感信息泄露、过度代理和不安全输出等风险类别。
- 本文的任务卡、指标分层、失败分类和回归流程是作者基于工程实践整理的模板，不代表上述资料的原文结论。
