Agent 单次回答正确,只能证明当前输入跑通。上线前还要确认换一种问法、缺少字段、知识更新、工具超时或权限不足时,系统会给出预期结果。批量测试把这些任务保存成可重复运行的样本,每次修改模型、知识、Skill 或 Workflow 后重新执行,比较关键字段和最终状态。
ZGI 将可复用批量测试放在 Agent 的发布与运行治理中。Agent 可以绑定批准的知识、数据库、Skills 和 Workflow,测试时用同一组任务检查变更是否影响检索、工具参数、分支判断和执行结果。运行日志用于定位失败发生在哪一步。

先把"回答正确"拆成可检查结果
不同任务的通过标准并不相同。知识问答需要检查引用资料是否匹配;结构化抽取关注字段名称、类型和必填项;工具任务还要确认调用对象、参数、权限与返回状态。只看最终自然语言,很容易漏掉中间步骤的错误。
例如订单查询任务返回了一段流畅说明,但调用时使用了错误客户编号,这条结果不能通过。退款流程正确判断了条件,却在审批前写入业务系统,也属于失败。通过标准应落到能够核对的字段和状态上。
| 样本类型 | 需要检查 | 预期结果 |
|---|---|---|
| 正常任务 | 内容、字段、工具结果 | 完成指定目标 |
| 信息缺失 | 必填字段与追问路径 | 停止执行并补充信息 |
| 权限不足 | 身份、对象与动作 | 拒绝越界调用 |
| 接口异常 | 超时、错误码与重试 | 进入预设失败路径 |
| 状态变化 | 旧参数与最新业务状态 | 重新读取后再判断 |
样本要来自真实任务分布
测试集只放标准问题,批量运行通常会得到很好看的结果。生产环境里更常见的麻烦来自缩写、旧名称、跨段资料、模糊时间和不完整输入。样本需要覆盖常见任务,也要保留曾经失败的问题。
每条样本至少记录输入、期望结果、检查字段、允许动作和数据版本。涉及知识库时,还要写明期望引用的资料范围;涉及工具时,保存应调用的工具和禁止发生的副作用。无法写出期望结果的任务,暂时不适合自动判定。
失败分类比一个总分更有用
一条任务失败后,应区分资料没有进入候选、模型提取错误、工具参数不符、权限拦截、流程分支错误或外部接口异常。把所有问题压成一个分数,很难指导修改,也可能让严重的越权问题被大量简单样本稀释。
测试报告可以按任务类型和失败阶段汇总。涉及资金、删除、外发和权限修改的样本需要单独设置上线门槛,即使整体通过数量较高,只要高风险样本失败,发布仍应停止。
变更后只跑相关样本还不够
修改知识切分时,先运行知识问答样本很合理,但还要保留一组跨模块回归任务。知识片段变化可能影响 Workflow 的条件判断,模型切换也可能改变工具参数。相关样本用于快速定位,固定回归集负责发现意外影响。
在 ZGI 中,可以先为一个 Agent 保存少量高频任务和已知失败任务,明确每条样本的关键字段与最终状态。每次调整模型、知识、Skill 或 Workflow 后重新运行,失败结果再结合运行日志定位。样本持续积累后,上线判断会逐渐从"演示看起来正常"变成可复查的发布条件。
GitHub:github.com/zgiai/zgi
Gitee:gitee.com/zgiai/zgi