Agent 到底好不好用？一文讲透 AI Agent 评测体系

weixin_51228134 · 2026-08-09 15:15:44 发布

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

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

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

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

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

这条链路具有三个特点：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

测试任务：

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

可以设置如下评分：