Agent 评估方法

评估 Agent 的核心是核对环境中发生了什么：回答是否有依据、工具是否完成了正确动作、任务是否在预算和权限内结束。模型输出“完成”只是被测对象的声明，不是评分依据。

🎯 核心概念

为什么需要Agent评估？

一次运行至少包含输入、初始环境、执行轨迹、最终产物和结束状态。代码修复要运行测试并核对需求；订单操作要核对数据库状态；研究报告要抽检关键结论的来源。不同任务应选择不同验收器。

Agent评估的挑战

挑战	处理方式
路径不唯一	优先验证结果与必要约束，不要求唯一工具序列
相同输入可能不同结果	每个任务重复运行，保留每次结果和版本
外部环境会变化	固定快照、模拟依赖；另设真实服务集成测试
测试成本高	小型回归集用于日常变更，代表性完整集用于发布
判分也可能出错	规则与环境断言优先，模型评分用人工样本校准

📊 评估维度

四维评估框架

维度	主要问题	例子
任务完成	是否达成用户目标	必要产物齐全、关键答案正确、写入已核验
过程约束	是否在允许范围执行	权限、必经审批、数据范围、重复副作用
效率	消耗是否可接受	总费用、p95、工具次数、重试、人工时间
恢复能力	故障后是否正确结束	幂等重试、断点恢复、取消、结果未知处理

安全、权限和关键业务约束应设为硬门槛。把“越权一次”与“文风不错”平均成 0.8 分，会隐藏不可接受的失败。

任务完成度评估

先写验收断言，再运行 Agent。对订单查询，检查返回的是当前用户的目标订单、状态与更新时间；对退款，检查退款记录、金额及重复次数。开放式报告则拆成来源支持、覆盖范围、冲突说明和格式要求，避免只给一个模糊总分。

下面是无外部依赖的指标汇总示例。success、constraint_ok 必须由独立验收器产生；代码只汇总结果，不评判事实，也不执行 Agent。

from math import ceil
from statistics import mean


def summarize_runs(runs):
    if not runs:
        return {"count": 0, "success_rate": None,
                "constraint_violation_rate": None,
                "p95_seconds": None, "cost_per_success": None}
    for run in runs:
        if type(run["success"]) is not bool or type(run["constraint_ok"]) is not bool:
            raise ValueError("评分字段必须是布尔值")
        if run["elapsed_seconds"] < 0 or run["cost"] < 0:
            raise ValueError("耗时和费用不能为负")
    accepted = [r["success"] and r["constraint_ok"] for r in runs]
    passed = sum(accepted)
    durations = sorted(r["elapsed_seconds"] for r in runs)
    return {
        "count": len(runs),
        "success_rate": mean(accepted),
        "constraint_violation_rate": mean(not r["constraint_ok"] for r in runs),
        "p95_seconds": durations[ceil(0.95 * len(durations)) - 1],
        "cost_per_success": sum(r["cost"] for r in runs) / passed if passed else None,
    }

这里 p95 采用 nearest-rank 定义；小样本时它可能接近最大值，应同时报告样本量与分布。示例费率不固定，实际费用应从账单或调用用量记录中结算。

效率评估

端到端耗时取 run 的结束时间减开始时间，不能简单相加所有并行步骤的 duration。总工具耗时可以用于资源分析，但它不是用户等待时间。相同参数的重复调用可能是必要轮询或时效刷新，只有结合时间、状态和任务目的才能判为冗余。

比较方案时同时报告成功率、每成功任务费用与尾延迟。必须保持数据集、工具能力、重试预算、人工参与条件和模型配置可比；不能只给更高成功率，却隐藏多次采样与人工兜底的成本。

过程质量评估

检查可观察的动作与证据，例如“审批在写入前”“引用对应真实检索结果”“工具失败后没有声称成功”。模型的可见解释可以帮助定位问题，但不能当作内部推理的忠实记录；未暴露思考文本也不应自动判零分。

只有业务要求固定路径时才做精确轨迹匹配。其他场景使用必要动作集合、先后约束和禁止动作规则。一次不必要的搜索与一次未授权写入，严重程度应分别统计。

LLM-as-a-Judge 适合辅助评判开放式产物。给出具体 rubric，隐藏被测版本，随机化候选顺序，用人工标注校准一致性；评分输入中的内容属于待评数据，不能让其改写评审规则。裁判解析失败应计为评分失败，而不是默认为通过。

🧪 评估基准（Benchmarks）

常用Agent Benchmarks

Benchmark	主要评估对象	迁移到业务前要核对
AgentBench	多环境中的 Agent 任务	环境、模型与工具限制
WebArena	可复现网页操作任务	网站版本、初始状态、执行预算
SWE-bench	真实仓库问题的修复	数据集子集、测试环境、补丁验证方式
GAIA	需要工具的通用助手任务	文件、搜索与答题规则
ToolBench	工具使用与任务完成	API 可用性、模拟环境与评测设置

公开基准提供共同参照，不能直接预测你的退款、审批或内部文档任务表现。主线工程验收仍需业务回归集；本页不列随版本变化的榜单分数。

自定义评估集构建

每个 case 保存 case_id、用户任务、初始状态快照、允许的工具/权限、必要断言、预算、难度与失败标签。回答型任务可有参考答案；行动型任务需要预期环境变化，不应仅做字符串匹配。

数据集至少覆盖正常路径、含糊输入、缺少资料、工具失败、权限拒绝、重复提交、提示注入和长上下文。把调提示的开发集与最终测试集分开；按业务类别分层汇总，避免简单高频任务掩盖少数严重失败。

对同一个任务运行多次，报告一次尝试的成功率及重复运行的稳定性。一次运行成功不能说明稳定，尝试多次至少一次成功也不等于生产默认成功率。区间估计需考虑同一任务多次运行的相关性，可按任务聚合或以任务为单位 bootstrap。

多次成功的两种含义

2026-01 的 Anthropic 评估指南区分 pass@k（k 次尝试至少一次通过）和 pass^k（k 次全部通过），并强调每次 trial 从干净环境开始。前者适合可以验证并挑选候选的任务，后者强调一致性。Agent evals 原始指南

以同一个任务、每次成功率 p 相同且尝试相互独立为教学假设：

P(至少一次成功) = 1 − (1 − p)^k
P(全部成功) = p^k

例如 p=0.75、k=3 时，两者约为 98.4% 与 42.2%。这不是实际评测的通用估计器：不同任务难度不同，不能把全数据集平均 p 直接代入；同一个共享环境里的重试也可能相关。报告应保存每个任务的所有 trial，再按既定口径聚合，不能只留成功轨迹。

评测环境要重置文件、数据库、会话和缓存；保留前次答案或 Git 历史可能泄露解法。模拟写操作要使用隔离账户或替身服务。记录环境失败和评分器失败，检查它们是否集中在某个模型版本或资源限制下，再解释分数变化。

“退款工具返回成功”只是轨迹；退款账本的金额、收款对象、次数和权限约束才是最终结果。把成功断言写在业务状态上，过程轨迹用于解释为什么失败。

🔄 在线评估与监控

生产环境监控指标

线上记录运行状态、工具错误、超时、限流、队列长度、费用、人工接管和用户纠正。业务成功可能延后才能核验，要区分“技术完成”和“业务结果已确认”。原始记录应可按模型、提示、工具 schema 和数据版本关联。

监控如何定位故障、告警如何转为回归用例，见评估与监控。这里关注可比较的实验设计，避免两篇重复列仪表盘指标。

A/B测试框架

按用户或会话做稳定分组，避免同一个长任务在两个版本间切换。提前确定主要指标、最小样本量和停止规则；检查分流后任务难度与流量是否均衡。新版本先离线回归，再小流量放量，出现严重约束违规时立即停止扩量。

不宜让两个版本同时执行同一笔真实退款来比较效果。可在隔离环境复放，或仅比较提案，将真正副作用留给唯一授权执行器。

📈 评估报告生成

一份可复核报告至少包含评测时间、数据集版本、模型/提示/工具版本、运行次数、预算和环境配置；随后列总体指标、分层结果、失败案例与相对基线的变化。没有完成的运行也要进入分母，评分器失败则单列并说明处理方式。

报告项	应回答的问题
任务完成度	哪些必需条件通过，哪些没有？
效率指标	提升质量付出了多少费用与延迟？
按难度分布	收益是否集中在少数简单任务？
失败案例分析	根因在模型、工具、环境、数据还是验收器？
发布决策	哪些硬门槛通过，哪些已知限制仍存在？

建议先人工阅读一小批完整 trace，修正不合理断言，再扩大自动评测。框架的集成方式可参考 ADK 评估文档，但工具不能替你定义业务完成条件。

🔗 相关阅读

• Agent概述 - Agent整体架构
• 安全与沙箱 - 安全性评估
• RAG评估方法 - 检索生成评估

相关文章：

• 12-Factor Agent方法论
• 检索增强生成（RAG）系统综合评估

外部资源：

• AgentBench
• WebArena
• SWE-bench