Agent 评测框架

摘要：Agent（智能体）会调用工具、改环境状态、做多步决策，传统"答案字符串匹配"基本失效。本文解释 Agent 评测的三大独特挑战，介绍四类主流端到端基准（AgentBench / WebArena / GAIA / τ-bench），并给出"代码评测器 + LLM-as-Judge + 人工"三层方法与"能力评估 vs 回归评估"的工程分工。所有基准分数均来自原始论文并标注版本。

核心概念：为什么 Agent 难评

挑战	含义	对评测的影响
解法非唯一	"订上海机票"可先查航班也可先查高铁	不能字符串匹配标准答案
环境副作用	Agent 操作会改变世界状态（库里多一条订单）	必须在沙箱里跑，支持状态重置
多维权衡	成功率/效率/安全/鲁棒需同时看	单指标无法概括，要分维度

三个关键术语

轨迹（Trace / Transcript）：一次试验的完整记录，含工具调用、推理、中间结果。
评测器（Grader）：对轨迹某方面打分的逻辑，一个任务可有多个 grader。
试验（Trial）：同一任务跑多次取稳定结果（因非确定性）。

详见 agentic_ai_guide 7.2。

四类主流端到端基准

基准	论文 / 来源	环境	关键分数（来自论文）
AgentBench	Liu et al., ICLR 2024, arXiv:2308.03688	8 环境（OS/DB/知识图谱/卡牌/谜题/家居/购物/浏览）	闭源与开源差距大；论文用 reciprocal-difficulty 加权 Overall，GPT-4 约 4.01 vs CodeLlama-34B 约 0.96 `[分数来自原论文特定加权口径]`
WebArena	Zhou et al., ICLR 2024, arXiv:2307.13854	自托管 4 站点（电商/论坛/代码/CMS）	最佳 GPT-4 agent 14.41% vs 人类 78.24%
GAIA	Mialon et al., ICLR 2024, arXiv:2311.12983	开放式真实任务（需 Web/工具）	人类 92% vs GPT-4-with-plugins 约 15%
τ-bench	Yao et al., 2024, arXiv:2406.12045	零售/航空多轮工具对话 + 用户模拟	GPT-4o 航空 pass@1 约 35%、零售约 61%；pass@8 远低（一致性差）
SWE-bench	Jimenez et al., ICLR 2024, arXiv:2310.06770	真实 GitHub Issue 修复	2,294 任务；发布时 SOTA 约 1.96%，后续不断提升 `[分数为历史快照，随榜单演进]`

分数是快照，禁止跨日期/跨 harness 横比

上表每个数字都绑定"特定模型版本 + 特定评测协议 + 特定日期"。例如同一 AgentBench 有"原始 8 环境基准"与"后续 function-calling 工程版"，任务子集不同，分数不可混用。引用时务必带来源与口径。

三类评测器

代码评测器：os.path.exists('test.txt')、单元测试、JSON Schema 校验、工具白名单。便宜、客观、可复现，但对"有效变体"过于脆弱。
LLM-as-Judge：用量规（rubric）打分、成对比较、参考答案评估。灵活但非确定，必须人工校准（见 auto-human.md）。
人工评测：SME 审查、众包、A/B。质量最高但贵且慢，用于校准与抽检。

能力评估 vs 回归评估

两种评估目标不同

能力评估（Capability Eval）：测 Agent 还做不好的任务，初始通过率常 20–50%，用于指导研发方向。
回归评估（Regression Eval）：测已验证可用的任务，初始通过率应 95–99%，用于防止退化。每次发布前跑，跌破阈值立即回滚。
生命周期：高通过率的能力任务可"毕业"转成回归任务，团队持续推新能力评估。

操作步骤：三层法落地

第一层单元测试（代码评测器）：验证工具调用格式。

python

def test_weather_tool():
    agent = Agent(tools=[Calculator()])
    resp = agent.run("23 * 4 等于多少？")
    assert "calculator" in agent.trace.tool_calls   # 是否调用了正确工具
    assert "92" in resp.text                        # 最终结果是否正确

第二层轨迹评估（LLM-as-Judge，先做硬门禁再上 judge）：

python

EVAL_PROMPT = """请评估以下 Agent 执行轨迹：
任务：{task}
轨迹：{trace}
请从 1-5 打分：1.目标达成度 2.工具使用效率 3.推理逻辑性
明确定义每档含义（如 3=完成但有冗余，4=完成且高效）。"""
# 进阶：成对比较法消除位置偏差；定期用 50-100 条 SME 标注做 Cohen's Kappa 校准

第三层端到端基准：在隔离沙箱跑 WebArena / AgentBench 等，用环境状态变化判定成功（如数据库是否新增订单）。

黄金轨迹回归

对已知良好的 Agent 运行保存轨迹（工具调用序列 + 最终答案 hash），未来运行对比，捕获"行为漂移"而不只是最终答案变化。参考 engineersofai.com Agent Evaluation 的 GoldenTrajectoryStore 思路 [未实测具体实现]。

验证

代码评测器：本地 pytest 全绿即通过。
LLM-Judge：先抽 50–100 条与人工对齐，算 Cohen's Kappa；<0.8 必须改量规或换更强 judge。
端到端：在沙箱多次 trial（如 5 次取均值），报告 pass@1 与方差。

回滚 / 清理

端到端基准必须在可重置沙箱中运行；跑完重置环境，避免脏状态污染下次。
轨迹日志与失败样本回流到黄金集（dataset.md），但需脱敏。

bash

# 重置沙箱（示意，依实际环境）
docker compose -f agent-env/docker-compose.yml down -v
docker compose -f agent-env/docker-compose.yml up -d

故障排查

现象	原因	处理
端到端分数忽高忽低	trial 数太少 / 非确定性	增加 trial 数，报均值±方差
Judge 与人工不一致	量规模糊 / judge 偏弱	细化 rubric，做 Kappa 校准
沙箱状态串味	未重置环境	每轮 down -v 重建
工具调用格式错	prompt/函数定义不符	单元测试先行拦截

安全与合规

Agent 评测特有风险

环境副作用：Agent 在评测中误删/误改数据。必须在隔离沙箱，且禁止连接生产数据库。
评测数据泄露：轨迹含用户输入与工具返回，可能含 PII。回流黄金集前脱敏（见 dataset.md）。
越权工具：评测时限制工具白名单，防止 Agent 调用未授权接口。

成本 / 性能

端到端基准：需在沙箱起整套环境（WebArena 需 Docker 自托管站点），一次性搭建成本高但可复用。
LLM-Judge：每轨迹一次或多次打分，长轨迹 token 消耗大；用更小 judge + 硬门禁前置过滤可降本。
trial 数：为稳定需多次运行，成本线性增长；按任务重要性分级（核心回归 5–10 次，探索性 1–3 次）。

Agent 评测框架 ​

核心概念：为什么 Agent 难评 ​

四类主流端到端基准 ​

三类评测器 ​

能力评估 vs 回归评估 ​

操作步骤：三层法落地 ​

验证 ​

回滚 / 清理 ​

故障排查 ​

安全与合规 ​

成本 / 性能 ​

参考资料 ​