如何评测 AI Agent：从答案正确到过程可信

为什么“看起来不错”不是评测

Agent 输出往往语言流畅，演示时也能完成几次任务，这很容易制造已经可用的错觉。上线后，问题通常藏在长尾：选错工具、重复写入、引用不存在、成本失控，或在异常环境中无法停止。

评测 AI Agent 不能只给最终答案打分，因为相同答案可能来自可靠证据，也可能来自猜测。需要同时评估结果、过程、成本和安全边界。

先定义任务成功

每条评测用例都应包含初始环境、用户目标、允许动作和机器可检查的成功条件。例如“帮我创建退款”过于模糊，可以改成：仅当订单在退款期内时创建退款申请；金额不得超过已支付金额；不得直接执行打款；输出必须包含申请 ID。

任务结果可以分层判断：

• 业务成功：目标状态是否真实发生；
• 内容正确：结论、字段和计算是否准确；
• 证据充分：重要结论是否有可追溯依据；
• 约束遵守：权限、格式、时间和用户要求是否满足；
• 安全完成：没有产生越权或多余副作用。

不要把模型自报的“完成”当成标签。评测器应读取模拟环境或真实测试环境中的最终状态。

轨迹比最终答案包含更多信号

Agent 轨迹记录每次模型决策、工具参数、工具结果、状态变化和重试。可以据此计算：工具选择是否正确、参数是否有效、是否出现重复调用、无进展步数、重新规划次数和停止原因。

有些轨迹虽然最终成功，却暴露高风险行为。例如 Agent 先查询了不必要的敏感客户数据，最后仍给出正确答案。只看结果会漏掉这个问题。

轨迹评测应尽量基于可观察动作，不依赖隐藏思维文本。真正需要关心的是模型调用了什么、看到什么、改变了什么，以及系统为何允许。

建立分层测试集

第一层是单元场景，测试一个工具或一个决策：参数缺失是否修正、非重试错误是否停止、权限拒绝是否正确解释。

第二层是任务场景，覆盖端到端业务流程。每个主流程都要有正常、边界和失败用例。

第三层是对抗场景，在网页或文档中放入提示注入，提供冲突事实，模拟工具超时、空结果和超大结果，观察系统是否守住边界。

第四层是线上回放。对真实但已脱敏的运行轨迹进行离线重放，验证新模型、新 Prompt 或新工具描述是否造成回归。

测试集需要持续收集生产失败，而不是一次写完。每个严重事故都应转成一个可重复用例。

关键指标怎么选

任务成功率是核心，但要按场景和难度分组，平均值可能掩盖某类任务完全不可用。

工具调用准确率包括正确工具、正确参数和正确调用时机。写工具要单独统计，因为错误代价更高。

轨迹效率可以用成功任务的中位步骤数、重复调用率和无进展比例衡量。步骤越少不一定越好，但无价值循环一定是问题。

恢复能力关注超时、限流和中断后能否从检查点继续，是否产生重复副作用。

成本与延迟要统计完整分布，而不是只有均值。长尾任务可能消耗十倍 Token，拖慢队列。

安全指标包括越权尝试拦截率、敏感数据暴露、未经批准的高风险动作，以及恶意内容下的规则遵守率。

模型评分器要有边界

开放式内容很难完全用规则评分，可以使用另一个模型按量表判断完整性、清晰度或证据一致性。但模型评分器也会波动，不能成为唯一裁判。

一个稳妥组合是：确定性检查负责格式、数值、引用存在性和环境状态；模型评分负责语义质量；人工抽样校准模型评分。评分 Prompt 要给出具体等级定义和反例，并隐藏被评系统身份，减少偏差。

对高风险动作，人工或规则判断应拥有否决权。模型评分“总体很好”不能抵消一次越权写入。

回归评测与版本管理

每次改变模型、系统指令、工具 Schema、检索索引或记忆策略，都可能影响行为。评测报告应记录完整版本组合，而不是只写“新模型提升 5%”。

可以设置发布门槛：核心场景成功率不得下降；安全用例必须全部通过；单任务成本的高分位不能超过预算；新增能力至少在目标场景显著改善。门槛失败时停止发布，而不是靠主观挑选几个漂亮案例。

线上可以进行小流量影子评测，让新版本读取相同输入但不执行写操作，再比较决策。涉及真实用户数据时必须遵循最小化和脱敏规则。

从失败分类到工程行动

评测价值不在排行榜，而在定位。失败应归因到目标理解、上下文、规划、工具选择、工具执行、证据整合、验证器或恢复策略。不同归因对应不同修复方式。

如果工具参数频繁错误，应改 Schema 和示例；如果找不到事实，应检查检索；如果已经拿到正确证据却得出错误结论，才更可能需要调整模型或推理步骤。把所有问题归咎于 Prompt，会让迭代长期停留在碰运气。

小结

一套成熟的 Agent 评测体系应该回答：它是否完成任务、过程是否可信、失败能否恢复、成本是否可控、安全边界是否有效。只有这些指标可以持续回归，团队才知道每次修改究竟让系统变好还是只是变得不同。