Agent 评估浅记

虽然说 Agent 评估不像普通 chat 一样看看准确率就好，但很可惜，在我公司里，大家其实并不太在乎那些复杂的评估标准。业务更关心的无非是几件事：成本、延迟、准确率。

所谓成本，本质上就是大模型调用成本、硬件成本和人员成本的综合，细一点拆就是，这个 agent 最终带来的收益能不能覆盖我们投入的成本，而收益本身也不完全是直接的业务收入，有时候是降本提效，有时候是“看起来很先进”的数智化成果，甚至只是一个能写进汇报材料里的项目。毕竟在当前环境下，一个 agent 即使实际收益没有那么明显，只要能作为部门成果的一部分，通常也还是愿意去做的。

延迟也比较好理解，就是从用户输入问题到系统给出反馈的这段时间。在业务侧其实不会拆什么首 token、工具调用耗时这些细项，更多就是一种体感：我问了之后，等多久能看到结果，是快还是慢。

准确率就更直接了，回答是否正确、问题有没有被解决，这反而是三个指标里最“客观”的一个，也和工程上的评估体系更接近一些。

从工程视角来看

从工程视角，Agent 评估往往核心对象不是“回答”，而是“执行轨迹”：

Input → Plan → Tool Calls → Observations → Final Answer

所以评估对象变成三层：结果、过程与行为。

一、评估维度

1. 任务达成率

这是最核心的底线指标，成功 = 1，失败或中断 = 0。 用于衡量 Agent 是否真正完成目标。

2. 规划与推理能力

从规划层面看：

• 是否能正确拆解复杂任务
• 是否能处理模糊或多意图问题
• 是否能生成合理执行路径

常见问题包括：

• 陷入死循环（反复调用错误工具）
• 在不确定情况下强行决策（产生幻觉）
• 任务拆解不完整或逻辑混乱

3. 工具调用准确性

关注执行层面的准确性。

在不同系统中体现不同： RAG 系统：

• 检索触发是否合理
• query 重写是否正确 业务系统/API：
• 工具选择是否正确
• 参数是否符合规范
• 是否误用工具或漏用工具

4. 效率与成本

主要包括：

• 交互轮次
• Token 消耗
• 端到端延迟

在生产环境中，一个不合格的 Agent 往往表现为：

• 为简单问题进行多轮无意义推理
• 调用过多工具
• 响应时间过长
• 成本显著上升

二、工程实践中的评估方式

理论上的评估是一方面，但实际工作中通常更依赖工程手段：

1. 固定脚本指标统计
   定期拉取一段时间内核心指标（成功率、成本、延迟等）
2. 全链路监控
   实时观察线上行为，分析异常调用与失败路径
3. 人员调研 + 上线前测试
   通过人工反馈和真实使用验证系统效果，因为 Agent 是辅助工具，真实体验往往比指标更重要。 例如，在做工单归档智能体时，按照常理，设计为给用户推荐三个节点，但实际使用发现：用户基本只看第一个推荐节点，第二、第三个节点几乎不被点击。访谈后发现：用户默认认为“第一个 = 最准确”，如果第一个不对，后面的也不值得看，反而增加认知负担。

因此进行了改造：

• 改为首次只推荐一个节点
• 如果不准确，再逐步展开第二层、第三层推荐
• 从“列表推荐”改为“交互式逐步推荐” 改造后整体体验明显提升。

四、对齐业务时的指标表达

一般对业务侧汇报时，我主要提供这三类指标：

一、核心执行指标

• 任务成功率（最重要）
• 工具选择准确率
• 知识引用准确度（RAG 场景）

二、用户体验指标

• 首字响应时间
• 任务完成总耗时

三、稳定性与成本指标

• 死循环发生率（是否卡死）
• 单次交互轮次（平均调用深度）
• 平均消耗（Token / 计算成本）