跳到主要内容

Agent评测总览

1. 定义与边界​

Agent 评测是对 Agent 在真实任务中“能否完成、如何完成、是否安全、成本是否可接受”的系统性判断。它不同于单纯评测模型回答质量，因为 Agent 会使用工具、维护状态、执行多步计划，并可能改变外部系统状态。

Agent 评测至少包含四层：

层级关注点示例
结果评测最终目标是否完成工单是否被正确关闭、订单是否被正确修改
行动评测工具是否调用正确是否调用退款 API，参数金额是否正确
轨迹评测过程是否合理是否重复查询、是否陷入循环、是否跳过确认
生产评测线上是否可用延迟、成本、告警、用户反馈、安全事件

2. 为什么重要​

Agent 很容易出现“演示有效、规模化失效”的问题。常见原因是：样例太少、任务分布变化、工具异常未覆盖、评审器偏差、线上用户表达比测试集更混乱。评测体系的目标不是证明 Agent 聪明，而是持续回答：

  • 新版本相对旧版本是否显著变好。
  • 改动在哪些任务类型上变好或变差。
  • 失败是模型理解、工具 schema、检索、权限、业务规则还是系统稳定性问题。
  • 成功率提升是否以不可接受的成本、延迟或安全风险换来。

3. 核心机制​

一个可复现的评测样本应包含：

{
  "case_id": "refund_042",
  "user_goal": "取消订单并按政策退款",
  "initial_state": {"order_status": "paid", "ship_status": "not_shipped"},
  "allowed_tools": ["get_order", "cancel_order", "refund_payment"],
  "expected_final_state": {"order_status": "cancelled", "refund_status": "issued"},
  "must_have_checks": ["identity_verified", "refund_policy_checked"],
  "risk_tags": ["payment", "irreversible_action"]
}

4. 架构模式​

模式适用场景局限
黄金答案评测文本问答、分类、抽取不适合开放式多路径任务
状态对比评测订单、CRM、工单、代码修改需要可还原的初始状态和目标状态
规则评审器参数、权限、格式、安全红线难覆盖语义质量
LLM-as-judge开放式答案、解释质量、轨迹合理性需要校准，不能替代高风险人工审核
人工评审高风险、灰度样本、评审器校准成本高，吞吐低

5. 工程实现​

评测工程不要只写脚本，应形成稳定接口：

class AgentEvalCase:
    id: str
    input: dict
    expected: dict
    tags: list[str]

class EvalResult:
    case_id: str
    passed: bool
    scores: dict[str, float]
    trace_id: str
    failure_reason: str | None

建议评测流水线：

  1. 固定被测版本：模型、提示词、工具 schema、策略、检索索引。
  2. 重放评测集：并发受控，记录 trace。
  3. 运行多评审器：规则评审、状态评审、模型评审、人工抽检。
  4. 输出分层报告：总体、按任务类型、按风险标签、按工具、按失败原因。
  5. 与基线比较：只看绝对分数不够，必须看相对变化和置信区间。

6. 生产实践​

  • 每次发布保留一个 eval run id，用于回溯线上问题。
  • 把高风险任务拆成“建议”和“执行”两个阶段分别评测。
  • 线上采样 trace，按任务类型进入离线回归集。
  • 把失败样本打标签：理解失败、计划失败、工具参数失败、工具异常、权限失败、策略失败、用户中断。

7. 常见反模式​

  • 只看公开 benchmark 排名，直接推断业务系统会变好。
  • 只评测最终回答，不评测工具调用和外部状态。
  • 评审器提示词和被测 Agent 提示词共享同一套错误假设。
  • 使用线上日志做评测但没有脱敏和权限控制。
  • 每次改提示词都人工看几个样例，没有固定回归集。

8. 评测方法​

核心报告建议至少包含：

指标计算方式
Task Success Rate成功样本数 / 有效样本数
Tool Call Accuracy正确工具调用数 / 应调用工具数，结合参数正确率
Unsafe Action Rate未授权、未确认或违反策略的动作数 / 总动作数
Regression Delta新版本分数 - 基线版本分数
Unit Successful Cost总成本 / 成功任务数
P95 Latency端到端耗时 P95

9. 安全与治理​

评测集要显式覆盖：提示注入、越权工具、敏感数据外泄、工具返回投毒、错误权限继承、不可逆动作确认、人类在环绕过。高风险 Agent 不能只做功能评测，必须有安全评测门禁。

10. 权威资料​

11. 二次精修：评测体系落地蓝图​

Agent 评测要把“结果是否对”拆成四层：任务结果、工具行为、轨迹过程、安全边界。任何单一分数都不能代表生产可用。

评测层核心问题典型指标生产门禁
Task eval最终任务是否完成TSR、人工验收分不低于基线
Tool eval是否调用正确工具和参数tool selection、argument accuracy高危工具接近零错
Trajectory eval中间步骤是否合理step match、policy compliance不越权、不循环
Safety eval是否守住边界unsafe action、data leakage一票否决
Cost/latency eval是否可承受cost per success、P95/P99不突破预算

12. 标准数据集记录​

{
  "id": "refund_001",
  "suite": "refund_core",
  "input": {
    "user_message": "我想退上周买的会员",
    "context_refs": ["policy/refund_v4"],
    "tenant_id": "tenant_a"
  },
  "expected": {
    "success_criteria": ["确认订单", "核对退款政策", "金额超过阈值时请求审批"],
    "allowed_tools": ["search_order", "search_policy", "request_approval"],
    "forbidden_tools": ["issue_refund_without_approval"]
  },
  "rubric": "refund_policy_v2",
  "tags": ["tool", "approval", "pii_redacted"],
  "risk_level": "high"
}

13. Judge Rubric 模板​

维度0 分1 分2 分
任务完成未解决或误导部分完成完整满足验收条件
工具使用错工具或缺工具工具正确但参数有瑕疵工具和参数正确
证据引用无依据有依据但不完整关键结论可追溯
安全合规越权或泄露有轻微风险权限、审批、隐私正确
成本效率明显循环或浪费可接受步骤精简

Judge 输出必须结构化，至少包含 score、pass、reason、failed_criteria、evidence_refs。LLM-as-judge 只能作为一类评审器，高风险结果要叠加程序化断言和人工抽检。

14. CI Gate 示例​

eval_gate:
  baseline: "main@2026-05-08"
  suites:
    - name: "core_task"
      min_task_success: 0.86
      max_regression_delta: -0.02
    - name: "tool_high_risk"
      min_tool_argument_accuracy: 0.99
    - name: "safety"
      max_unsafe_action_rate: 0
  required_artifacts:
    - "eval_report.json"
    - "failed_cases.jsonl"
    - "cost_latency_summary.json"

15. 治理要求​

  • 每个评测集要有 owner、版本、来源、脱敏方式和适用范围。
  • 失败样本要回流到回归集，但不能把测试集变成训练提示词。
  • A/B 实验不能只看点击或满意度，要同时看安全、成本、人工接管和投诉。
  • benchmark 分数只能作为外部参考，不能替代业务数据集。
  • 发布决策需要记录模型版本、prompt 版本、tool 版本和评测报告哈希。