Agent 上线前怎么验收？一套覆盖准确率、成本与异常的测试方法

Agent 与普通问答不同，它会规划步骤、调用工具、读取数据并可能写回业务系统。一次错误不只是答案不准确，还可能发错消息、改错订单或反复调用造成成本。因此验收不能看几段成功演示，而要覆盖任务完成、事实准确、工具选择、权限、异常恢复、成本和人工接管，并能在模型或流程变化后重复执行。

先定义任务边界和成功状态

把“销售数字员工”拆成可验证任务，例如读取指定商机、生成跟进草稿、创建待办，而不是笼统要求提升销售。每个任务写清允许输入、可调用工具、预期输出、禁止动作、完成证据和最大步骤。边界越明确，越容易判断 Agent 是否真正完成而不是看起来很忙。

建立四类测试样本

正常样本验证主流程，边界样本覆盖缺字段和模糊请求，异常样本模拟接口失败、超时和权限不足，对抗样本测试诱导泄密、越权和忽略规则。样本来自真实历史并脱敏，由业务专家确认代表性。只测正常情况会高估生产表现。

分开测推理与工具执行

Agent 可能判断正确却调用错接口，也可能接口成功但业务结论错误。记录每一步输入、选择、参数和返回，分别评估计划、事实、工具、结果。关键动作使用确定性校验，例如订单编号、金额范围和状态机，不要再让另一个模型凭感觉判断全部正确。

权限测试必须覆盖越权企图

使用不同角色账号验证可见数据和可执行动作，测试跨客户、跨部门、批量查询和提示注入。即使模型被诱导，工具层也必须拒绝越权。密钥不应出现在提示和日志中，写操作需要二次确认或审批。权限是系统能力，不能依赖 Agent 自觉遵守。

定义异常与人工接管

遇到信息不足、连续失败、低置信、高风险或用户要求时，Agent 应停止并把上下文交给人工，而不是编造完成。测试接管信息是否完整、任务是否重复、人工能否回滚。设置最大步骤、最大调用和超时，避免陷入循环。失败状态也要给用户清晰说明。

测量成本与延迟分布

记录每个任务的模型、工具、存储和人工复核成本，以及平均与高分位延迟。少数复杂任务可能消耗大部分费用，需要优化上下文、缓存或任务拆分。不能只看平均值，高峰并发和长尾会直接影响体验。设定单任务预算并对异常调用告警。

用业务标准评估准确性

答案语句通顺不代表可用。由业务专家制定关键字段、证据、容忍误差和红线错误，对不同错误设置权重。客户承诺、金额、身份和合规错误应一票否决。自动评分与人工抽检结合，评测结果要能追溯到具体版本和配置。

灰度上线而不是一次放量

先在沙箱和只读环境测试，再给内部小组使用，随后开放低风险真实任务。每一阶段都有流量上限、监控和回滚。保留人工旧流程，对比完成率、质量、成本和采用。达到门槛后才扩大权限和人群，不因管理层演示成功直接全量上线。

变更后必须回归测试

模型版本、提示、知识库、接口和业务规则任何变化都可能影响行为。建立自动回归套件，每次发布运行核心和红线样本；生产中发现的新错误加入评测集。定期检查性能漂移和数据变化。Agent 是持续运营的产品，不是交付后不再维护的脚本。

老板的下一步

要求项目组提交一页验收表：任务完成率、红线错误、越权结果、人工接管、单次成本、延迟和回滚方式。没有固定样本和上线门槛的 Agent 不得连接生产写权限。企业真正需要的不是会表演的数字员工，而是行为可测、风险可控、成本可知且能持续改进的业务角色。