围绕任务终态、幂等写入、租户隔离和故障恢复，设计可重复执行的 Agent 验收流程。
验收从业务终态开始
企业知识库与工单助手的成功条件不只是返回一段回答。一次任务需要完成授权检索、引用校验、工单提案、用户确认和创建结果核实。验收应覆盖整个闭环，并将业务结果与任务状态关联起来。
例如，任务标记为成功时，下游应存在与原操作 ID 对应的唯一工单；任务等待确认时，下游不应发生写入；创建响应丢失时，系统应进入结果核实流程，避免立即生成新操作再次提交。
为正常路径和异常路径定义断言
| 验收场景 | 关键断言 | 检查依据 |
|---|---|---|
| 确认后创建工单 | 提交内容与用户确认的提案版本一致 | 提案摘要、确认记录、下游工单 |
| 重复提交同一操作 | 只产生一条业务记录，返回同一结果 | 操作 ID、唯一约束、请求日志 |
| 检索跨租户文档 | 未授权内容不进入模型上下文 | 两租户测试数据、检索结果、权限日志 |
| Worker 在写入后退出 | 恢复后先核实结果，避免重复创建 | 任务事件、工具调用记录、下游状态 |
| 权限在任务执行中撤销 | 后续检索、引用访问和写入重新校验权限 | 策略版本、拒绝记录、访问结果 |
权限撤销无法收回已经展示给用户的信息，因此断言应聚焦撤销后的访问与操作。对仍在执行的任务，需要明确在哪个边界重新检查权限，以及发现权限变化后如何终止或转入人工处理。
将外部依赖变成可控制的测试条件
模型回答具有随机性，外部工具也可能超时。状态机验收可以使用固定模型输出和模拟工具，让同一输入稳定触发相同分支。回答质量评测则使用真实模型，单独记录模型版本、提示词版本和采样参数。
测试工具应支持几种明确的行为：返回成功、写入前失败、写入成功后丢失响应、延迟返回和重复回调。模拟行为必须对应真实接口可能出现的故障窗口，否则测试只是在验证理想流程。
测试数据采用合成文档、租户和账号，保留稳定标识。每次运行使用独立的任务与操作命名空间，避免上次运行遗留的数据干扰判断。
一次恢复测试的执行顺序
- 创建任务，生成工单提案并记录用户确认的版本。
- 调用创建工具，让下游完成写入，但阻断成功响应。
- 在任务确认结果前停止 Worker，保留已持久化的任务和操作记录。
- 等待原租约失效，再启动新的 Worker 接管任务。
- 通过原操作 ID 查询下游结果，恢复本地状态并结束任务。
- 核对下游记录数量、任务终态和事件时间线。
验收不能只检查任务最后是否成功，还应检查恢复过程中是否生成了新的写入操作、是否绕过确认，以及旧 Worker 恢复后是否仍能提交过期结果。可通过租约版本或 fencing token 拒绝过期执行者的状态更新。
保存能够复查的验收产物
fixtures/ 合成知识、租户和账号数据
evals/ 固定样本、终态断言和质量评判
experiments/ 故障注入、检索对照和负载脚本
results/ 原始结果、事件时间线和报告摘要
每次运行应关联代码提交、配置版本、模型与工具契约版本，并保存测试输入和失败原因。日志中的任务 ID、操作 ID 和 trace ID 用于连接编排记录、工具请求和下游结果；敏感字段在保存前脱敏。
报告将确定性断言与回答质量分别统计。幂等、授权和任务恢复属于明确的通过或失败条件；回答质量则需要固定样本、评分规则与必要的人工复核。平均分不能掩盖越权或重复写入这类关键失败。
从验收结果形成发布门槛
发布前先运行状态机与工具契约测试，再执行检索和回答质量回归，最后验证容量与故障恢复。关键安全断言失败时阻止发布，质量指标的容忍范围则应按业务目标预先确定。
报告应同时保留失败样本、样本量、重复次数和运行环境。修复后使用同一组样本复测，并补充覆盖新故障的案例，使一次问题排查转化为可持续执行的回归检查。
