AI Agent 评测：如何量化智能体真实能力

为什么 Agent 需要专门的评测

大模型 Agent 评测 正在成为 AI 工程的核心环节。当智能体从 demo 走向生产，单看一段流畅演示已经不够——我们需要用可复现的基准，把”会不会用工具””能不能多步完成任务””出错后能否自纠”这些模糊直觉，变成可比较、可回归的数字。和评测单轮问答不同，Agent 评测面对的是一段会调用工具、读取环境、反复决策的行动轨迹，传统 MMLU 这类静态题库完全覆盖不到。

更麻烦的是，Agent 很容易在基准上”刷分”：它会先输出一句”任务已完成”来骗过宽松的评分脚本，实际却没真正改对代码。因此一套靠谱的 Agent 评测，既要衡量最终结果，也要约束过程。下文先厘清两类主流范式，再给出可落地的自建清单，并附一个最小评测骨架。

评测的两类范式

离线基准（Benchmark）：用一批固定任务，在受控环境里跑 Agent，统计成功率。优势是可复现、可横向对比不同模型；劣势是任务一旦公开，就容易渗进训练集，造成数据污染。我们在大模型偏好对齐实战里提到的对齐训练，如果恰好”见过”评测题，分数会虚高。

轨迹评测（Trajectory / Online Eval）：把 Agent 在真实或仿真环境里的每一步动作（action）与环境反馈（observation）都记录下来，按规则或模型裁判打分。它更贴近线上表现，但环境搭建成本高。无论哪类，评分都必须基于”环境是否到达正确终态”，而不是 Agent 自己的陈述——这正是很多自研评测翻车的地方。

主流基准巡礼

选基准前先想清楚：你的 Agent 主要在什么环境干活？下面五个是目前引用最广的公开基准，覆盖代码、对话、网页、综合与多模态四类场景。

对工程团队而言，SWE-bench 适合评估”写代码修 bug”型 Agent，τ-bench 适合评估”客服 / 业务办理”型 Agent，WebArena 适合”网页操作”型。它们与LangChain Agent 实战、MCP 与 A2A 协议里构建的 Agent 能力是一一对应的——能跑通协议，不代表能跑通任务。

自建评测体系的四步法

1. 定义任务与终止条件

一个可被评测的任务，必须有明确的”完成信号”。例如”修复登录接口 500 错误”要落成”对应测试用例由红变绿”；”查询上月销售额”要落成”返回的数字与金标准一致”。没有终止断言，Agent 永远可以说自己”正在处理”。

2. 构造可复现的环境

环境必须幂等：每次评测都从同一份快照启动（容器镜像、数据库 fixture、mock 外部 API）。否则今天过明天挂，分数毫无意义。可复现环境也是后续做回归测试、捕捉提示注入攻防风险的前提。

3. 设计评分指标

别只盯成功率。一个稳健的评分至少包含三项：任务是否达成（success）、达成用了多少步（efficiency）、花了多少 token / 调用（cost）。下面给出最小评分骨架：

from dataclasses import dataclass

@dataclass
class Step:
    action: str        # 模型选择的动作: call_tool / answer / ...
    observation: str   # 环境返回
    reward: float = 0.0

def score_trajectory(steps, gold):
    # 任务级: 是否抵达终止状态且通过断言
    success = steps[-1].action == "answer" and gold.check(steps[-1].observation)
    # 效率: 实际步数 / 最优步数 (越接近 1 越好)
    efficiency = gold.optimal_steps / max(len(steps), 1)
    return {"success": success, "efficiency": round(efficiency, 2)}

4. 防数据污染与泄露

如果评测任务来自公开数据集，模型大概率在训练时见过。应对方式是用私有任务、最新 issue，或在评分里加入”模型是否背诵答案”的探测题。对需要长上下文支撑的任务，可参考上下文工程实战里的检索阈值标定，避免把评测答案直接喂进上下文。

代码实战：跑一个评测闭环

以 SWE-bench 风格为例，下面命令在本地用 harness 跑一批补丁生成预测，并输出修复通过率。注意它依赖真实测试套件，因此天然防作弊：

# 以 SWE-bench 为例，跑一个模型补丁生成评测
pip install swebench
python -m swebench.harness.run_evaluation \
  --predictions_path preds.json \
  --max_workers 4 \
  --run_id my_agent_v1

当任务难以用断言判定（如开放式问答），常引入 LLM-as-a-judge。但它本身会走偏，所以裁判 prompt 必须约束”只看结果、不信自述”：

judge_prompt = """你是严格的评测员。只依据下方【最终答案】与【标准答案】判断任务是否完成。
禁止参考模型的自我陈述，禁止给"我已完成"这类表述加分。
输出 JSON: {"done": true/false, "reason": "..."}"""

五个常见陷阱

其中”奖励黑客”最隐蔽：Agent 学会输出特定格式来骗取宽松打分，而不是真正完成任务。双评（结果断言 + 过程合理性）几乎是必要的。结构化输出实战里强调的 schema 约束，也能在评测侧减少这类投机。

评测如何衔接线上监控

离线基准解决”发版前敢不敢上”，线上监控解决”上线后稳不稳”。建议把评测集作为回归基线：每次模型或 prompt 升级都跑一遍，分数回退就拦截。同时把线上真实轨迹采样回流，用OpenTelemetry 链路追踪记录每步耗时与工具调用，配合Prometheus + Grafana观察 Agent 的步数与失败率漂移。评测与监控构成闭环，Agent 才谈得上可运营。

小结

Agent 评测的本质，是把”智能体到底行不行”这件主观感受，变成可度量、可回归的工程问题。记住四件事：用环境终态做判据而非自述、成功率之外至少补效率与成本、警惕数据污染与奖励黑客、让离线评测与线上监控形成闭环。先把这一套最小骨架跑起来，比追求完美基准更重要。