大模型回答一个问题，我们通常只需要判断答案是否正确；但 Agent 不仅要“回答”，还要规划步骤、选择工具、生成参数、读取结果，并在失败后继续完成任务。

因此，评测 Agent 不能只看最后一句话。一个 Agent 即使给出了正确结果，也可能调用了错误接口、重复执行有副作用的操作，或者消耗了过多时间和 Token。反过来，它也可能因为外部接口暂时不可用而失败，但工具选择和恢复策略其实是正确的。

一套可靠的 Agent 评测体系，至少要同时回答三个问题：任务完成了吗？执行过程正确吗？成本与风险可接受吗？

一、Agent 评测与普通模型评测有什么不同？

普通问答更接近“输入—输出”，Agent 则是一条动态执行链：

用户请求 → 任务规划 → 工具选择 → 参数生成 → 工具执行
        → 读取反馈 → 调整计划 → 生成最终结果

这条链路具有三个特点：

1. 路径不唯一：完成同一任务可能存在多条合理路线；

2. 依赖外部环境：数据库、搜索服务和业务接口都会影响结果；

3. 具有随机性：同一输入多次运行，工具调用和最终回答可能不同。

所以，Agent 评测不能只做一次，也不能只用字符串匹配判断答案。

二、Agent 应该评测哪些指标？

1. 任务成功率

任务成功率是最核心的指标：Agent 是否真正完成了用户目标，而不是只回复“已经完成”。

例如，用户要求“创建明天下午三点的项目评审待办”，应检查数据库中是否出现正确记录，而不是检查回答里有没有“创建成功”。

Task Success Rate = 成功完成的任务数 / 总任务数

对有副作用的任务，最好通过系统状态或接口返回值进行确定性验证。

2. 工具调用正确性

工具评测可以继续拆成四项：

• 工具选择是否正确；

• 参数名称、类型和值是否正确；

• 多个工具的调用顺序是否合理；

• 不需要工具时，是否避免了多余调用。

例如“查询待办”与“删除待办”含义接近，但风险完全不同。选错工具即使最终话术自然，也必须判为失败。

3. 执行轨迹质量

Trace 是一次运行中模型调用、工具调用、返回结果、路由与异常处理的完整记录。通过 Trace 可以发现仅看最终答案无法发现的问题，例如：

• 同一接口被重复调用；

• 查询失败后不断重试，形成循环；

• 已获得充分信息，却继续调用无关工具；

• 工具报错后，Agent 编造了一个成功结果。

轨迹不要求和标准答案逐步一致，重点是判断关键步骤是否正确、是否违反约束。

4. 稳定性与恢复能力

同一个测试用例建议运行 3～5 次，统计成功率，而不是只保留最好的一次结果。同时应主动注入异常：接口超时、空结果、参数缺失、权限不足或限流，观察 Agent 能否重试、换路、追问用户或安全退出。

5. 成本与性能

“能够完成”不代表“适合上线”，还应记录：

• 端到端响应时间；

• 模型调用次数与 Token 消耗；

• 工具调用次数；

• 单次任务平均成本。

若两个版本成功率接近，调用更少、延迟更低的版本通常更有工程价值。

6. 安全性

对删除、支付、审批等高风险操作，需要单独设置硬性指标：是否进行权限校验，是否在执行前确认，是否泄露敏感信息，是否抵抗提示注入。安全项不适合被平均分掩盖，关键规则一旦违反，应直接判定该用例失败。

三、如何构建 Agent 评测集？

评测集不应只有“标准问题”，建议按四类组织：

类型	示例	主要目的
正常任务	创建一个普通待办	验证基本成功率
复杂任务	查询日程后创建不冲突的待办	验证规划与多工具协作
边界任务	时间缺失、对象不存在	验证追问和边界处理
风险任务	删除全部待办、越权审批	验证确认、权限与安全策略

每个用例至少包含：用户输入、初始环境、允许使用的工具、预期状态、关键约束和评分规则。生产环境出现过的失败案例也应脱敏后加入回归集，防止同类问题再次出现。

四、规则、模型裁判和人工评测怎么结合？

规则评分

适合判断可以精确验证的内容，如工具名、参数、数据库状态、调用次数和耗时。它成本低、结果稳定，应作为首选。

LLM-as-a-Judge

适合判断表达质量、计划合理性和答案是否满足复杂要求。使用时要提供清晰量表，例如从“正确性、完整性、依据充分性”三个维度分别评分，避免只问“这个答案好吗”。裁判模型也会产生偏差，因此需要先用人工标注样本校准。

人工评测

适合高风险、主观性强或规则尚未成熟的场景。工程上通常采用“规则自动评测为主，模型裁判补充语义判断，人工抽检和仲裁”的组合，而不是全部依赖某一种方法。

五、一个企业待办 Agent 的评分示例

测试任务：

帮我创建明天下午三点的项目评审待办，并提醒项目组成员。

可以设置如下评分：

维度	权重	判定标准
任务结果	40%	待办创建成功，标题和时间正确
工具调用	25%	选择创建与通知工具，参数正确
执行过程	15%	先创建后通知，无重复写入
异常处理	10%	成员不明确时先追问，不擅自发送
成本效率	10%	调用次数和延迟处于阈值内

此外还应设置硬门槛：如果收件人未确认、权限校验失败或产生重复待办，无论加权总分多高，都判定失败。

六、一套可落地的评测流程

1. 定义成功标准：先明确业务结果、关键过程和禁止行为；

2. 采集运行轨迹：记录模型、工具、参数、返回值、延迟和异常；

3. 从少量真实任务开始：人工查看 Trace，归纳高频失败模式；

4. 沉淀评测集与评分器：将明确标准转成规则或模型裁判；

5. 执行多次回归：比较成功率、稳定性、成本和安全指标；

6. 接入发布流程：修改 Prompt、模型、工具或路由后自动运行评测；

7. 持续补充线上案例：把新故障转成新的回归用例。

不要只看一个综合分。综合分适合快速比较版本，但定位问题时，仍需分别查看任务、工具、轨迹、成本和安全指标。

七、常见误区

第一，只看最终回答。Agent 可能“说成功了”，实际没有改变系统状态。

第二，测试集过于理想。没有歧义、异常与危险请求，就无法反映真实生产环境。

第三，要求轨迹完全一致。Agent 的合理路径可能不止一条，应约束关键节点和结果，而非机械匹配全部步骤。

第四，用线上用户做实验。高风险操作应先在隔离环境或模拟工具中评测，再逐步灰度。

总结

Agent 评测不是给最终回答打一个分，而是验证它能否在真实约束下，选择正确工具、走完合理流程，并以可接受的成本安全地完成任务。

实践中可以记住一句话：结果决定有没有完成，轨迹解释为什么成败，约束决定能不能上线。

当 Trace、评测集和回归流程形成闭环后，每次 Prompt、模型或工具调整就不再依赖主观体验，而能通过数据回答：这个 Agent 是否真的变好了。

参考资料

• OpenAI：Evaluate agent workflows

• OpenAI：Trace grading