当前位置:首页>排行榜>Agent 上线前,至少要评测这 4 件事

Agent 上线前,至少要评测这 4 件事

  • 更新时间 2026-10-27 11:08:40
Agent 上线前,至少要评测这 4 件事

AGENT EVAL FIELD NOTES · 11

演示成功不等于上线可靠。用一个虚构的数据分析 Agent,拆解多轮状态、工具调用、失败恢复、成本与延迟四类测试,以及怎样把评测接入版本发布。

Agent 在演示里答对一次,不等于上线后可靠。上线前要验证的,不只是它能不能给出答案,还包括条件变化时是否保持一致、工具出错时会不会乱猜,以及完成任务花了多少时间和成本。评测应是每次变更都能复跑的反馈系统,而不是发布前的一次考试。

下面用一个虚构的数据分析 Agent贯穿全文:用户要比较本周与上周的华东退货率,随后补充“排除取消订单”,并要求列出数据来源。场景和数据均为示意,不对应真实业务。

先把“成功”写成验收条件

回答里出现一个百分比,不代表任务完成。这个 Agent 至少要选对时间范围和地区、按约定公式计算、排除取消订单、说明数据来自哪张表;如果“退货率”的业务定义不清,就应先追问,而不是自行选一种口径。查询失败时,它也不能编出一个看起来合理的结果。

把这些要求写成可观察的验收项:查询参数、计算结果、引用依据、澄清动作和失败出口分别检查。成功标准越具体,产品、研发和业务人员越容易对“答对了”达成一致。

测试一:条件变化后,状态还一致吗

真实用户不会一次把需求说完。他可能先问“本周华东退货率”,再补一句“排除取消订单”,最后改成“和上周比较”。Agent 要保留仍然有效的地区和排除条件,只更新比较周期;如果用户后来纠正了指标定义,则应按新定义重算,而不是沿用旧结果。

评测时,逐轮检查状态快照与最终查询条件:新增条件有没有进入任务,修改有没有覆盖旧值,未修改的约束有没有丢失。还要加入指代不清、前后矛盾和用户纠错,验证系统会澄清,而不是把“记住上下文”误当成“猜到用户意思”。

多轮状态测试

测试二:工具选对了,参数也对吗

Agent 可能说对了计算方法,却把地区、日期或排除条件传错;也可能在权限被拒后换一条路径继续查。只检查最终文字,会漏掉这些过程错误。

为每次调用检查工具选择、参数、顺序、权限判断和返回结果。结构化数据可以逐字段比对:日期范围是否正确、地区是否符合请求、公式所需字段是否齐全。权限拒绝后,系统只能说明限制、请求授权或转人工,不能换工具绕过拒绝。评测要把“正确拒绝不该做的事”也记为成功行为。

工具调用测试

测试三:异常发生后,能停在安全位置吗

至少要覆盖检索为空、接口超时和返回格式异常。每种异常都要有预期动作:可重试的按策略重试;证据不足的明确说明缺少什么;无法恢复的停止并转人工。不能把空结果补成常识答案,也不能把错误响应当作有效数据继续计算。

保存异常前后的状态、工具返回类别、重试记录和接管结果。这样才能区分是数据缺失、工具故障还是编排逻辑的问题。即使用户最终拿到了答案,只要过程把错误数据当成真值,评测就应判失败。

失败恢复测试

测试四:成功率值得它花的时间和成本吗

同一任务要同时记录完成质量、模型与工具调用次数、Token 成本和端到端延迟。平均延迟不能遮住少数特别慢的请求,所以发布门槛还应看 P95;成本也应按“完成一个合格任务”计算,而不是只看单次模型调用。

如果正确率提高,却让等待时间超过业务预算或成本失去可行性,这个版本未必适合上线。预算应从产品基线和实际业务约束确定,不照抄其他团队的数字。反过来,单纯减少调用,也不能以漏查证据或降低安全性为代价。

成本与延迟测试

把四类测试接进发布闭环

评测集要来自真实任务,而不是只有措辞完整的标准题。对线上日志、客服工单、销售记录和人工反馈脱敏后取样,再补充错别字、半句话、多重诉求、过期信息、无答案和诱导越权等边界输入。按高频、长尾、高风险、无答案和对抗输入分类,才能看清系统在哪些场景可靠。

能明确判定的内容先自动评分:字段完整性、工具参数、计算结果和权限规则。语气、相关性和是否解决问题可以用模型评分,但要定期抽样由人工复核校准。不要把不同问题压成一个总分;正确性、完整性、忠实度、安全性、成本和延迟应分别呈现。

评测过程也要留痕:Agent 选了什么工具、权限检查结果如何、依据来自哪里、重试几次、是否转人工。每次更换模型、Prompt、Embedding、Reranker 或工具,都跑同一套任务集并与上一版本比较。保留失败输入、执行 Trace、预期和实际结果,再标出问题属于数据、检索、编排还是模型。

发布门槛应由业务基线确定:关键任务成功率不得下降,安全违规率为零,P95 延迟不超预算,单任务成本在目标范围内。通过离线回归后先小流量运行,观察用户修改率和转人工率;指标恶化时可以回滚到上一个稳定版本。

产品与研发可以为每项任务共用一张评测卡:输入与上下文、可用工具、预期动作、可接受答案、不可接受答案、评分规则。每周复盘失败样本,决定补数据、修检索、改流程、加工具约束,还是调整模型提示。

评测不是为了得到一个好看的离线分数,而是明确系统可靠的范围,以及必须交给人工的边界。无法复现的成功不足以支持放权;无法定位的失败也无法指导下一次改进。

如需梳理 Agent 场景的验收条件、回归集或上线门槛,可通过公众号底部菜单〔商务合作〕联系。

参考资料

  1. Anthropic,《Demystifying evals for AI agents》:https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

案例为虚构示意;正文中的测试结构与落地模板依据参考资料和本文归纳,不代表特定企业的评测结果。

随机文章