Agent 的效果很难用一个分数概括。它可能答对了最终问题,却越权读取了材料;也可能工具调用成功,但任务没有真正完成;还可能离线样本表现稳定,线上遇到长上下文和并发后延迟失控。
上线前评测的目标不是证明 Agent 永远正确,而是知道它在哪些条件下可靠、在哪些条件下必须拒答或交给人,并且能在结果变差时快速定位原因。
把任务拆成可观察的步骤
先定义任务的成功条件,再决定指标。一个“处理客户退款申请”的 Agent,成功不只是生成一段回复,还包括身份确认、订单核验、规则检索、金额计算、审批和结果通知。每个步骤都应有输入、输出和允许的失败方式。
推荐为每次运行建立统一 trace:
1 | trace_id |
没有这条链路,遇到失败时只能看一段最终回复,很难判断是模型推理、检索、权限还是业务服务出了问题。
评测集要覆盖真实失败方式
评测集不应只有容易回答的标准问题。可以从四个方向构建:
| 类型 | 样例 | 要验证的行为 |
|---|---|---|
| 正常任务 | 条件完整、证据明确 | 能否按流程完成 |
| 缺少信息 | 缺少版本、身份或对象 | 是否补问而不是猜测 |
| 冲突和异常 | 文档版本冲突、工具超时 | 是否暴露不确定性并恢复 |
| 安全边界 | 越权、注入、敏感动作 | 是否拒绝或转人工 |
每个样例除了问题和参考答案,还应记录身份、知识快照、允许工具、预期状态、必须出现的事实和不能出现的结论。对工具型 Agent,参考结果可以是状态转移和副作用约束,而不必要求文本逐字相同。
指标要分成结果、过程和风险
结果指标衡量任务是否完成,例如正确状态、必要字段完整度和用户是否需要重复操作。过程指标衡量每一步是否按预期运行,例如检索证据命中、工具参数有效、重试次数和人工接管率。风险指标关注应该拒绝的请求是否被拒绝、是否出现越权证据、是否执行了未经审批的写入。
延迟和成本也要分层统计:首 token 延迟、检索耗时、工具耗时、总耗时、模型 token、工具费用和每次任务平均成本。平均值容易掩盖长尾,至少同时观察中位数和高分位延迟。
自动评分要和人工标尺配合
模型评分可以帮助处理大量样本,但不能独立决定发布。评分器可能偏好更长的答案,也可能忽略了一个关键权限错误。应先用人工标注一组正确、错误和边界样本,检查自动评分与人工判断的一致性。
对高风险问题使用硬规则:越权材料、虚构审批、错误金额、未授权写入都应直接判失败。对开放式表达,再使用模型评分或人工抽样。每个指标都要写清分母,例如“任务完成率”不应把主动拒答和异常失败混在一起。
回归测试要冻结可比条件
每次修改模型、系统提示词、检索切分、重排器或工具版本,都需要跑同一组回归样本。样本的知识快照、身份、模型参数和工具模拟结果应固定,避免一次改动同时改变多个变量。
评测报告不只保存总分,还要保留从正确变成错误的样例、从失败变成成功的样例以及指标变化的原因。对随机性较高的任务,可以重复运行几次,区分偶然波动和稳定变化。
用灰度把风险限制在小范围
上线前先明确降级路径。模型不可用时,是否回退到规则流程;检索服务超时时,是否允许用户稍后重试;工具写入失败时,是否保留草稿而不是继续执行。没有降级路径的 Agent,遇到依赖故障就只能让用户承担不确定性。
灰度可以按组织、用户、任务类型或流量比例进行。新版本先处理低风险任务,设置错误率、人工接管率、成本和延迟的停止条件。灰度期间同时保留旧版本结果,便于对比而不是依赖主观感受。
线上监控看趋势,也看单次任务
运营面板需要关注:请求量、成功和失败状态、模型与工具错误、端到端延迟、人工接管、策略拒绝、成本和用户反馈。指标突然变化时,应能从面板跳转到具体 trace,看到哪个步骤发生了异常。
日志和 trace 不要默认保存完整敏感内容。可以对输入做脱敏和摘要,对证据保存受控引用,对工具参数保存 schema 校验后的字段摘要。排障权限和数据保留期限也要纳入平台治理。
把线上失败变成新的测试样本
一次真实故障的处理流程可以是:先隔离影响范围,再保存必要 trace,判断是数据、模型、工具还是策略问题;随后增加一个可复现样本,修复后跑回归,最后观察灰度指标是否恢复。没有进入评测集的故障,很容易在下一次改动中重新出现。
Agent 上线后仍然需要版本化:模型版本、提示词版本、工具契约、知识快照、策略配置和评测集都应可追溯。只有这样,团队才能把“这次回答怎么变差了”变成一个可以定位和修复的工程问题。