一文讲透 Agent 评测：维度、方法和落地实践

作者将 Agent 评测定义为：在固定环境中，以一组有代表性的任务验证 Agent 的结果、过程、效率与安全性。它不是上线前的一次“答案打分”，而是把需求、测试、运行记录、问题归因和回归测试连起来的工程系统。

为什么 Agent 评测不同于传统测试

Agent 输出有随机性，环境、模型、Prompt、工具、知识库和 Skill 都会影响结果；一次配置变更也常同时牵动多个变量。最终答案看似正确，过程仍可能绕路、误调用工具、消耗过多 Token 或触发外部副作用。因此评测需要允许多个合理答案，分别观察结果和轨迹，用多维标准而非单一断言判断，并以多次运行的统计结果抵抗波动。对 LLM 裁判本身也要保留误判意识。

从 PRD 开始定义可评测目标

文章建议在 PRD 阶段先写清 Agent 的范围、成功标准和发布门禁。成功标准不应只有“答对”，还要包括正确性、完整性、格式、过程、延迟、成本和安全。随后从真实业务流程抽取典型任务，由工程侧补齐边界和失败场景，测试侧做去重、维护和发布；线上问题在脱敏后也要回流到测试集。

任务可先按查询、知识问答、内容生成和执行类拆分，以获得更清晰的指标和定位能力；但仍应保留端到端用例，防止只在局部优化。用例需要覆盖正常、边界和失败三类场景。

评什么：结果、过程与非功能质量

文章列出六类主要维度：

1. 任务完成度：是否完成目标，答案是否正确、完整、格式合规。
2. 工具调用质量：工具是否选对、参数是否正确、调用顺序是否合理，是否出现无效或危险调用。
3. Skill 使用质量：是否选对 Skill、按要求调用，并让中间状态与最终结果符合预期。
4. 执行过程质量：规划、检索、推理、异常处理和状态转移是否可解释、可控。
5. 非功能质量：耗时、Token、成本、稳定性、安全和隐私。
6. 业务约束：同一任务可有多种正确答案，评测必须把业务规则显式转成可执行标准。

怎么评：分层组合评分

确定性规则适合字段、格式、JSON Schema、正则、包含关系和固定答案；轨迹评分适合检查关键工具和步骤是否出现、顺序是否满足约束。对于开放回答，LLM-as-Judge 要搭配清晰 Rubric，并输出结构化的分维结论和理由，由服务端重新计算分数。高风险、主观性强或裁判存在争议的结果需要人工复核；高价值案例则需要多次运行，观察均值、通过率和方差。

每次改动都应相对固定基线比较任务通过率、成本和延迟，而非只看新版本的绝对分数。线上抽样评测可以发现离线集没有覆盖的真实问题，但要做好脱敏和数据治理。

评测平台的运行闭环

文章将平台拆成几项可操作能力：

• 数据集分为开发集、回归集和保留集，发布后冻结版本；每条样本包含问题、上下文、预期、评分方式、标签和优先级，复杂任务还可绑定多轮对话、断言和评分器。
• 评分器按“确定性优先、LLM 补开放题、人工覆盖高风险/争议”的顺序组合，并管理评分器版本、权重和门禁。
• 每次运行要记录完整快照：数据集、Agent、Prompt、模型参数、工具、Skill、MCP、知识库、评分器和协议版本。对外部副作用采用禁用、Mock、录制回放或受控环境。
• 为单用例和整批运行设置时间、Token、成本预算，超预算即停止，避免评测本身失控。
• 尽量复用生产 Agent Runtime 和可观测数据，形成含目标 Agent Trace 与评分器 Trace 的完整 Run，避免评测运行时和生产运行时出现两套行为。
• 报告应同时呈现平均分、通过率、方差、相对基线的提升或回归、成本和延迟；高价值案例可重复执行。
• 失败结果进入问题中心：结合目标 Agent Trace 与评分器 Trace，判定问题属于 Prompt、模型、知识库、工具、环境还是评分器，记录严重度、负责人和修复版本，修复后重新发起评测。
• 线上问题、人工争议和开发失败经脱敏、去重和审核后进入回归集；评分器也要用人工标注持续校准，并通过定时任务或 CI 持续回归。

文章结论

作者的核心主张是，Agent 评测平台应在真实案例中迭代。只有把用例、评分、运行上下文、问题归因和回归门禁做成同一闭环，团队才知道一次 Agent 改动是确实变好，还是只是换了一种失败方式。

证据边界

本文为作者对自身 Agent 评测平台实践的经验总结，未提供可独立复现的系统实现、样本规模、基准结果或性能数据。平台能力、实施效果和方法适用范围均应在具体业务、模型和安全约束下自行验证。