简介：很多技术人回答“Agent怎么评测”时，只停留在任务准确率这一结果指标上。本文从工程实践出发，对比“只看最终答案”与“全链路可观测评测”两种思路的差异，拆解离线评测、在线评测、指标设计、样本回流等关键环节，帮助开发者建立可落地的Agent评测体系，理解不同阶段应该关注什么、怎么选、怎么迭代。
在面试或技术方案评审中，如果被问到“Agent 怎么评测”，只回答“看任务准确率”或“看最终答案对不对”，通常会暴露出一个关键问题：把 Agent 当成一个单步函数来评估，而不是当成一个多步骤执行系统来评估。
Agent 与普通模型调用的本质区别在于，它不是一个“输入—输出”的简单映射。一个典型的 Agent 任务可能包含意图判断、检索决策、工具选择、参数构造、工具调用、结果校验、异常重试、下一步规划等多个阶段。最终答案只是整条执行链路的结果投影，中间任何一步出错，都可能导致最终结果偏差、成本上升或延迟不可控。
因此，Agent 评测的核心问题不是“答案对不对”，而是：我们能不能看清这个过程，并且对这个过程的不同维度分别做出判断。
从这个角度看，Agent 评测更接近分布式系统或复杂业务链路的评测，而不是传统分类模型或回归模型的评测。传统模型评测关注的是输入与输出的映射质量，Agent 评测则还需要关注执行过程、资源消耗、失败恢复和外部依赖表现。
为了更清楚地说明差异，可以把 Agent 评测分成两种思路：
| 对比维度 | 结果导向评测 | 过程导向评测 |
|---|---|---|
| 关注对象 | 最终答案是否正确 | 最终答案 + 执行链路 + 中间步骤 |
| 适用阶段 | 早期原型验证 | 工程化落地、生产环境 |
| 可定位性 | 只知道错了，不知道为什么错 | 可以定位到具体步骤、具体工具、具体调用 |
| 指标类型 | 准确率、完成率 | 准确率、工具调用正确率、耗时、成本、重试率、错误率等 |
| 工程价值 | 低 | 高 |
| 实现成本 | 低 | 需要可观测性、日志、链路追踪等基础设施 |
| 对团队要求 | 只需要标注最终结果 | 需要定义步骤规范、工具调用规范、失败分类 |
| 能否驱动迭代 | 只能判断整体好坏 | 可以指导具体优化方向 |
结果导向评测并不是完全没有价值。在 Agent 原型刚搭建、执行链路还未稳定、工具集成尚未完成时，先看最终结果是否大致可用，可以快速判断方向是否正确。这个阶段的评测成本低，适合做快速验证。
但一旦 Agent 进入工程化阶段，需要对外提供服务、接入业务系统、面对真实用户时，结果导向评测就不够用了。原因有三点：
第一，最终答案正确并不代表系统健康。一个 Agent 可能调用了多次模型才得到正确答案，成本远高于预期；也可能在某个工具调用上反复重试，用户等待时间被拉长。
第二，最终答案错误时，无法定位问题。是意图识别错了？是检索结果不够好？是工具参数构造错误？是外部工具超时？没有过程记录，就只能靠人工复现和猜测。
第三，评测结果无法回流到开发迭代。如果只记录“这题错了”，开发侧不知道改哪里；如果能记录“这题在第三步工具调用失败，重试两次后超时”，优化方向就非常明确。
因此，结果导向评测适合“能不能做出来”的阶段，过程导向评测适合“能不能稳定上线、能不能持续优化”的阶段。两者不是互斥关系，而是递进关系。
要实施过程导向评测，首先要解决一个问题：能不能看到 Agent 的完整执行过程。
可观测性在传统后端系统中已经是一个成熟概念，通常包含日志、指标和链路追踪。对 Agent 来说，可观测性的对象从服务调用延伸到了模型调用和工具调用。一次完整的 Agent 执行可以被视作一条 trace，其中每一步模型推理、每一次工具请求、每一次重试都是一个 span。
在具体实现中，需要至少记录以下信息：
记录这些信息的目的，不是单纯为了“有日志”，而是为了后续评测能够量化。比如，工具调用正确率需要知道每次调用的是不是预期工具；重试率需要知道总调用次数和成功次数；失败原因分布需要知道异常类型。没有这些现场数据，很多指标是算不出来的。
此外，可观测性也为线上问题排查提供了基础。当用户反馈某个任务失败时，如果能回溯到具体 span，看到是外部工具超时还是模型输出不符合预期，定位效率会远高于仅凭最终答案推断。
Agent 评测不能只在上线前做，也不能只在上线后做。两者的目标、数据来源和判稳标准不同，需要分开设计。
离线评测的目标是在可控环境下，用固定数据集验证 Agent 是否达到上线标准。它通常包含两类用例：冒烟用例集和回归用例集。
冒烟用例集用于快速验证核心链路是否可用，比如“能否完成一次完整的工具调用”“能否正确解析用户意图”。冒烟用例一般数量不多，但覆盖最关键的路径。任何一条冒烟用例失败，都不应进入下一阶段。
回归用例集用于防止已有能力回退。当模型版本更新、提示词调整、工具接入方式变化时，需要跑回归集确认历史能力没有被破坏。回归用例通常来自历史线上数据、人工标注数据和边界场景整理。
离线评测的指标设计需要避免只看一个数字。建议至少从以下几个维度分别统计：
这些指标放在一起，才能比较完整地描述离线阶段的表现。
离线评测再完善，也无法覆盖真实环境的所有情况。真实用户的问题分布、表达方式、上下文长度、外部工具状态都与离线环境有差异。因此，上线后需要建立在线评测机制。
在线评测的数据来源更加多样，包括：
在线评测的一个关键点是：不能只统计“最终失败率”。如果只记录失败，不知道失败发生在哪一步，后续优化仍然无从下手。结合可观测性数据，把失败任务按错误类型、工具分布、步骤分布进行聚合，才能形成可执行的优化结论。
另一个容易忽略的点是，在线评测需要容忍一定程度的噪声。用户反馈可能存在主观性，业务指标可能受外部因素影响，A/B 测试需要足够的样本量和合理的分流策略。因此，在线评测更适合作为趋势判断和问题发现机制，而不是唯一的精度判断标准。
在 Agent 评测中，指标设计是争议较多的地方。有人倾向于用一个综合分数来排名，有人倾向于用多个指标分别呈现。两种方式各有适用场景。
单指标的优势是直观，适合向非技术角色汇报，也适合做版本间的快速比较。比如，把任务完成率、工具正确率、耗时和成本加权成一个总分。但单指标的缺点是会掩盖细节。一个总分提升可能来自成本降低，也可能来自准确率提升，二者对业务的影响完全不同。
多指标的优势是可解释性强，适合工程师做问题定位和优化决策。比如，一个版本在准确率上提升了两个点，但平均耗时增加了 30%，这种变化只有分开统计才能看到。多指标的缺点是不利于快速比较，指标之间可能存在冲突，需要结合业务目标做权衡。
实践中更推荐的做法是：平时用多指标做工程分析，汇报时用少量关键指标做综合呈现。 也就是说，底层数据要细，上层展示要简。评测平台内部需要保留每一步、每个维度的原始统计，对外报告则根据受众选择性地提炼核心信息。
评测体系如果只有“评”而没有“改”，价值会大打折扣。一个完整的 Agent 评测闭环应该包含以下环节：
这个闭环的核心在于第 4 步到第 5 步：线上失败样本能不能进入离线回归集。只有让离线集持续吸收线上问题，离线评测才不会被架空。否则，离线集长期不更新，评测通过率再高也不能说明线上表现。
在设计回流机制时，需要注意样本的去重、脱敏、标注一致性和版本管理。不是所有线上失败都适合回流，有些是用户输入本身不完整，有些是外部工具临时故障，这些样本需要经过人工或规则筛选后才能成为有效的回归用例。
综合来看，怎么评测 Agent，取决于当前所处的阶段和团队具备的基础能力。
原型验证阶段： 以结果导向为主，关注任务能否大致完成，指标可以简单，使用少量人工标注样本即可。重点是快速判断方向是否可行。
工程化阶段： 需要引入可观测性，建立 trace 和 span 记录机制，开始补充工具调用正确率、耗时、成本、重试率等过程指标。离线评测逐步体系化，冒烟集和回归集并行推进。
生产运营阶段： 在线评测成为重点，结合真实用户反馈、业务指标和 A/B 测试观察系统表现。离线集不断吸收线上失败样本，形成持续迭代闭环。此时评测不再是一次性动作，而是日常运营的一部分。
如果团队资源有限，建议优先把可观测性做好。因为即使暂时没有完善的自动化评测集，只要链路数据完整，至少可以支持人工分析和问题定位。反之，如果只有一堆准确率数字，却没有链路数据，后续优化会非常被动。
最后需要强调的是，Agent 评测不是一个静态任务，而是一个持续演进的工程体系。它的核心价值不在于“给一个分数”，而在于“让每一步都有据可查、让每一次失败都能回流、让每一个指标都能指导下一步动作”。