AI Agent闭环工程如何做测试？重点看任务成功率和失败样本复盘
AI Agent闭环工程测试不要只看一次演示能不能跑通，重点要把任务成功率、工具调用轨迹和失败样本复盘放在一起看。先固定测试集，再拆节点、边和局部路径，线上样本回流后再补进评估集。
测试集先固定，别拿临时问题当标准
很多团队做Agent验证时，会在聊天框里随手问几个问题，看到结果像样就进入下一轮开发。这个做法最容易漏掉真实失败：同一个需求换一种问法，工具参数就错了；读者少给一个条件，Agent开始乱补；外部页面变慢，流程直接停住。
更稳的做法是先准备一组小而清晰的离线测试集，每条样本都写明输入、期望结果、允许的工具、禁止的动作和成功判断。测试集不必一开始很大，20到50条高频任务就能暴露不少问题，重点是每次改提示词、改图结构、改工具封装后都能重复跑。
任务成功率不是单次通过率，而是同一批任务在固定条件下反复执行后的稳定结果。一次跑通只能说明演示没坏，多次稳定通过才说明闭环有工程价值。
节点、边和局部路径要拆开测
端到端测试能看到最终结果，却很难判断错在计划、检索、工具调用还是结果整理。闭环工程里，Agent通常由多个节点、状态和条件边组成，测试也要拆到这些位置。
- 单测节点：给节点一份固定状态，看它输出的字段是否完整，是否会把读者需求改写偏。
- 单测条件边：准备几种状态，让路由判断走到正确分支，避免错误任务进入错误工具。
- 测试局部路径：只跑计划到工具调用、工具结果到回答生成这类短路径，减少端到端噪音。
- 每次测试使用干净的状态存储或新的检查点，避免上一次运行残留影响判断。
这个拆法适合排查“Agent有时对、有时错”的问题。比如最终回答错了，不一定是模型不会答，也可能是前一环给错了工具参数，或条件边把简单查询送进了复杂执行流。
轨迹比最终回答更早暴露问题
AI Agent测试不能只看回答文本。一个回答看起来正确，背后的工具选择可能已经偏了；一次任务失败，也可能不是模型理解错，而是参数格式少了字段。轨迹记录要覆盖工具名称、参数、返回值、重试次数、是否出现重复动作和是否产生副作用。
工具调用轨迹是失败复盘的主线，不能只保留最终回复。网页Agent、搜索Agent、数据Agent都应记录从读者输入到每次动作的链路。发现重复点击、重复搜索、无意义重试时，要把这类样本单独标记，因为它们会拉低真实可用性。
评估维度可以拆成三类：结果是否完成任务，过程是否选对工具，执行中有没有造成负面影响。规则评估适合批量统计，人工复核适合判断复杂任务，二者要配合使用。只靠规则分数，容易把“绕远路但完成”的样本判坏，也可能放过“答案对但过程危险”的样本。
失败样本复盘要回到评估集
闭环工程的关键不是找到一个失败样本后手动修掉，而是把失败变成下一轮测试资产。每次线上监控、灰度试用或人工验收发现问题，都要补齐失败原因、复现输入、期望行为和修复后验证方式。
- 标记失败类型：理解错、工具错、参数错、状态丢失、权限不足、外部依赖异常、输出格式不合格。
- 保留原始输入：不要只写概括句，读者原话和上下文会影响Agent判断。
- 补充轨迹截图或日志：记录哪一步开始偏离，便于开发定位。
- 修复后回归：同一条失败样本必须重新进入固定测试集，防止下次改动又打回原形。
失败样本库越贴近真实任务，任务成功率才越有参考价值。只用理想输入测试，分数会很好看，正式使用时却容易在缺字段、口语化表达、多轮追问里掉线。
上线后看真实流量中的异常模式
离线测试解决预发布质量，线上评估解决真实使用质量。上线后要看读者任务是否完成、人工接管比例、工具报错率、重复执行比例、超时比例和低分反馈。某个指标突然变化时，不要只改提示词，先看最近是否换了模型、工具接口、权限配置或外部页面结构。
比较实用的闭环节奏是：开发阶段跑固定测试集，灰度阶段抽查轨迹，正式阶段监控异常模式，每周把高频失败样本合并进评估集。这样做的价值在于，每一次失败都会压缩下一次出错空间，而不是停留在临时补丁。
做AI Agent闭环工程测试时，把任务成功率当作总指标，把轨迹评估当作定位工具，把失败样本复盘当作迭代入口。测试能稳定复现、失败能被分类、修复能被回归，Agent才算进入可维护状态。