Agent 能力评测体系设计技术文档

本文提出了一套企业级Agent能力评测体系，旨在评估智能Agent在任务执行、工具调用、环境交互等方面的全栈能力。该体系包含6类核心能力模型（任务理解、分解、工具使用、环境交互、执行稳定性和任务完成度），采用三层评测结构（基础能力、业务子流程和端到端流程）和四类评分模块（规则打分、过程分析、LLM裁判和安全合规检查）。评测流程涵盖数据集设计、执行流水线、LLM裁判系统和结果可视化，强调安全合规、成

10％光速

397人浏览 · 2025-11-29 08:55:56

10％光速 · 2025-11-29 08:55:56 发布

Agent 能力评测体系设计（完整版·企业级）

版本：v1.0
撰写人：——
适用对象：AI 工程团队 / 产品团队 / 测试团队 / 业务线负责人

概述
Agent 能力模型
评测总体框架
评测场景体系
指标体系（能力维度）
评测数据集设计
评测执行流水线（Pipeline）
LLM-as-a-Judge 评分体系
报告呈现与 Leaderboard
安全、合规、成本与稳定性
版本管理、治理与持续评测
附录：配置样例 / Prompt 模板 / JSON Schema

1. 概述

1.1 背景

随着大型语言模型（LLMs）逐步从“聊天助手”演变为能够执行任务、调用工具、完成业务流程的 智能 Agent，企业内部对 Agent 的质量、稳定性、安全性提出了高要求。

然而，Agent 的行为不同于问答模型：

需要多步推理
需要调用工具和 API
需要操作环境（浏览器、系统、文件、数据库…）
需要处理错误、自我恢复
需要最终完成业务目标

因此，过去的模型评测体系（如 MMLU、BLEU、ROUGE、代码 pass@k）无法覆盖 Agent 的全栈能力。

本技术文档给出一套可落地、可扩展、可版本化的企业级 Agent 能力评测体系。

2. Agent 能力模型（Capability Model）

企业级 Agent 的核心能力可分为 6 类：

任务理解（Task Comprehension）
能否正确理解用户需求、业务意图、流程要求。
任务分解（Task Decomposition）
能否把复杂任务拆分为执行步骤（Subtasks）。
工具使用（Tool Use / API Calling）
能否选择正确工具、构造正确参数、理解返回值。
环境交互（Environment Interaction）
操作浏览器、系统界面、文件系统、数据库等。
执行稳定性（Execution Robustness）
能否在执行中途出现错误时恢复；
能否避免死循环、错误泛滥、操作丢失。
任务完成度（Goal Completion）
最终是否真正完成业务任务。

注意：
Agent 的核心评价不是“回答是否好看”，而是“最终能否完成业务目标”。

3. 评测总体框架

评测平台遵循以下体系：

3.1 三层评测结构

层级	说明	示例
L1 基础能力	工具调用、数据抽取、小任务	调数据库、填表、调用内部 API
L2 业务子流程	中等复杂、多工具链路（5–10 步）	创建工单、合规检查、业务查询
L3 端到端流程	多阶段组合任务（10–50 步）	报销流程自动化、周报自动生成、客服工单全流程

3.2 四类评分模块

规则打分（Deterministic Rules）
过程分析（Execution Trace Analysis）
LLM-as-a-Judge（主观质量评估）
安全与合规检查（Safety/Compliance）

最终总体评分通常是：

总分 = 功能成功率 × 权重1 + 质量评分 × 权重2 + 稳定性 × 权重3 + 安全合规 × 权重4

4. 评测场景体系（Scenario Taxonomy）

企业需要构建一个“场景矩阵”，覆盖所有业务线需求：

4.1 典型企业场景库结构

场景类别	示例	对应层级
客服/知识库问答	KB QA、问询分流、多轮意图确认	L1–L2
文档处理	总结、结构化抽取、生成报告、PDF 解析	L1–L3
业务流程自动化（RPA 2.0）	填表、审批、系统跳转、数据更新	L2–L3
数据分析	抓取数据 → 清洗 → 生成图表 → 报告	L2–L3
代码与内部工具助手	阅读代码、修改、写脚本、调试	L1–L2
邮件/沟通自动化	回复邮件、生成总结、编写行动项	L1–L2

场景需要：

Versioning（v1 / v2）
难度等级（1~5）
题库规模（100–10,000）
是否涉及安全要求（敏感字段、合规限制）

5. 指标体系（Scoring Dimensions）

5.1 一级指标（主要向管理层汇报）

任务成功率（Task Success Rate）
质量分（Quality Score – LLM Judge）
执行稳定性（Robustness）
安全与合规通过率（Safety Pass Rate）
资源效率（Cost Efficiency）

5.2 二级指标（工程团队使用）

① 任务完成度（Functional Correctness）

是否满足关键成功条件
是否生成正确文件/字段
工具调用链是否完整
结果是否满足验收规则

② 质量质量（LLM Judge）

正确性（Correctness）
有用性（Helpfulness）
清晰性（Clarity）
推理链合理性（Reasoning Quality）
风格/语气一致性（企业 Tone）

③ 稳定性

步骤失败率
错误恢复率
是否出现死循环
环境交互成功率（DOM find、click、input 等）

④ 资源消耗

Token 成本
平均步数
总耗时
平均 API 调用次数

⑤ 安全合规

是否泄露敏感信息
是否生成错误指南（金融/医疗风险）
是否越权操作
是否违反政策（隐私、法律、伦理）

6. 评测数据集设计（Dataset Design）

6.1 样本结构（JSON Schema）

{
  "sample_id": "cs_kb_qa_00123",
  "scene": "customer_support_kb_qa",
  "layer": 2,
  "input": {
    "user_query": "我上个月账单没扣款？",
    "context": { "user_id": "u12345" }
  },
  "expected": {
    "key_points": [
      "解释扣款规则",
      "指出账单状态为未出账",
      "说明下一次扣款时间"
    ],
    "gold_output": null
  },
  "metadata": {
    "difficulty": 2,
    "sensitivity": "low",
    "biz_owner": "customer_support"
  }
}

6.2 数据来源

真实业务日志（脱敏）：70–80%
专家构造难题：10–20%
对抗样本：5–10%
边界条件/极端输入：5%

6.3 数据维护

场景版本化
每季度更新一次
“评测/训练隔离”：严禁把评测数据泄露到模型训练集

7. 评测执行流水线（Pipeline）

Pipeline 步骤：

① 选样本

根据场景 → 难度 → 场景版本 → 随机抽样 N 个 case。

② 执行 Agent（Execution Engine）

输入样本
记录所有轨迹：
- action（工具/浏览器/API 调用）
- observation（工具返回值/网页内容）
- LLM 内部思考（可选）

③ 规则打分（Rule-based Checker）

判断是否满足关键条件：

关键字段填对了吗？
生成的文件内容是否符合模板？
工具调用顺序是否正确？

④ 过程分析（Trajectory Analysis）

统计：

步数
错误次数
死循环
恢复次数
环境稳定性（如 click 成功率）

⑤ LLM-as-a-Judge 主观质量评估

评分维度：

正确性
有用性
清晰度
内容完整性
风格一致性
无幻觉程度

⑥ 安全 & 合规检查

包括：

敏感信息泄露
越权操作
不当内容（医疗/法律）
隐私违规

⑦ 写入数据库（Result Store）

保存：

时间戳
输入
Agent 输出
轨迹
评分
安全分析
成本

⑧ 可视化 Output

Dashboard / Leaderboard / Error Drill-down

8. LLM-as-a-Judge（裁判系统）

8.1 裁判角色

LLM 裁判应比被评模型 强一个等级，并且：

有较强对齐能力
有稳健的判断能力
没有明显风格偏见

8.2 裁判模式

Pointwise：逐条评分
Pairwise：比较 A vs B（推荐用于 A/B 测试）
Listwise：对多个候选进行排序

8.3 裁判 Prompt 模板（示例）

你是企业级 Agent 质量评估专家。
你的任务是评估候选回答是否满足业务关键点。

请按以下维度 0-10 分：
1. 正确性
2. 有用性
3. 清晰度
4. 风格一致性
5. 安全性

期望关键点：
- {key_points}

候选回答：
{candidate_output}

请输出 JSON：
{
  "correctness": 0-10,
  "helpfulness": 0-10,
  "clarity": 0-10,
  "safety": 0-10,
  "overall": 平均或加权平均,
  "reason": "你的分析"
}

8.4 人类校准 & 漂移监控

每季度对裁判进行一次校准
用“金标样本”检测裁判稳定性
检测 prompt 漂移、模型升级对评分的影响

9. 报告呈现（Dashboard & Leaderboard）

9.1 主面板（适合管理层）

场景成功率
LLM Judge 总分
成本（Token / 步数 / 时间）
安全违规率
趋势图（7 天 / 30 天）

9.2 技术面板（适合工程师）

行为轨迹（Action Trace）回放
工具调用密度图
错误类型分布
反复失败样本集
分场景雷达图

9.3 A/B 比较面板

多版本 Agent 的对比图
胜率（pairwise judge）
多指标对比（质量、安全、成本）

10. 安全、合规、成本与性能

10.1 安全要求

沙箱执行环境（Browser/OS/DB）
只连接测试/UAT 环境
隐私脱敏
操作记录审计

10.2 成本控制

LLM 裁判抽样
缓存重复评价
小模型预筛 + 大模型最终评分
限制最大长度、最大工具调用次数

10.3 性能优化

多 Worker 并行
数据库索引优化
分布式评测
批处理调用（Batch API）

11. 版本管理 & 持续评测（CI/CD 集成）

11.1 每次模型升级前强制评测

在 GitLab/Jenkins Pipeline 中加入：

单元测试
轻量评测（Smoke Evaluation）
全量评测（Nightly）
提交评测对比报告
通过门槛才能上线

11.2 场景版本管理

场景需：

有 Owner
有版本（v1 / v2 / v3）
每半年更新一次
去除已被模型过拟合的样本

11.3 偏差治理

检测 LLM 裁判偏差
检测模型行为漂移
检查是否出现模式化崩溃（mode collapse）

12. 附录

12.1 样本 JSON Schema

（略，已在上文给出）

12.2 评测 Run 配置

{
  "run_id": "eval_20251128_001",
  "scene": "cs_kb_qa",
  "candidates": ["agent_v3", "agent_v4"],
  "sample_size": 200,
  "judge": {
    "enabled": true,
    "model": "gpt-5.1-judge",
    "rubric": "kb_qa_v1"
  },
  "checker_ruleset": "kbqa_basic",
  "safety_module": "enterprise_safety_v2"
}

12.3 结果记录结构

{
  "sample_id": "...",
  "agent_output": "...",
  "trajectory": [...],
  "rule_score": 0.82,
  "judge_score": 8.4,
  "safety_flag": false,
  "latency_ms": 1850,
  "token_cost": 3400
}