智能体编排的分层测试方法
智能体演示成功，并不说明它能稳定地完成业务任务。工具参数、上下文、权限和外部服务同时变化时，问题才会出现，因此测试要按职责拆开。
单元测试覆盖提示词组装、参数校验、状态转换和权限判断，可以用固定模型响应验证失败分支。集成测试在隔离环境连接检索、数据库与工具服务，检查超时、重试和幂等性。端到端测试选取脱敏任务，记录人工改写的原因和用户中断的位置。
尤其要保留失败样本。它能帮助团队区分模型理解错误、工具接口缺陷和产品流程不清。分层不是为了提高报表上的通过率，而是把不确定性限制在可观察、可回退的范围内。
评估集要跟着风险走
测试报告还应保存输入版本、配置和运行时间，保证结果能够复现。没有复现条件的高分，不能作为上线依据。
评估结果还要区分模型失败与系统失败。检索未命中、工具不可用、权限拒绝和模型误解的处置方式不同，混在一个成功率里无法指导改进。为每类失败指定负责人和复测条件，才能让测试真正服务于发布决策。
测试资料要避免泄露真实用户信息，可以使用脱敏样本或受控副本。每个用例应记录预期结果的依据，尤其是权限、金额和状态转换规则。工具或知识库升级后，除重跑总体结果外，还应检查旧失败用例是否改善、旧正确用例是否退化，并把变化写进发布说明。
测试资料要避免泄露真实用户信息。可以用脱敏样本、经过批准的合成数据，或在隔离环境中访问受控副本。对每个用例记录预期结果的来源，尤其是权限、金额、状态转换等规则；否则评估者之间也会对“正确”产生分歧。
当工具或知识库升级后，不仅重跑总结果，也要检查此前失败的用例是否改善、此前正确的用例是否退化。把这些变化写进发布说明，值班和客服才知道新版本可能在哪些问题上需要额外关注。
测试用例不能只覆盖正常完成的任务。对每一种工具，都要准备缺参数、超权限、服务超时、重复请求和空结果；对每一种高风险业务，也要写清模型应当拒绝、转人工还是只生成草稿。固定用例让团队能比较版本，线上新发现的问题则应在脱敏和审核后回流到用例库。
端到端评估除任务是否完成外，还要记录执行轮次、工具调用、人工介入、耗时和失败原因。模型给出看似合理却没有依据的回答，与参数错误一样，都应成为可统计的失败类别。涉及外部写入时，测试环境使用隔离账号与可清理的数据。
发布门槛不必追求单一总分。更重要的是高风险用例没有越权，失败可以停止，结果能够追溯到输入和工具记录。这样模型或提示词变化时，系统仍知道该在哪里收口。
)