Agent 评测框架调研报告

调研时间：2026 年 4 月
调研目的：系统梳理当前主流 Agent 评测框架，为内部 Agent 评测平台（annto-eval）建设提供技术选型参考
说明：本报告所有信息均来自 GitHub 公开仓库、官方文档及学术论文，无虚构内容；部分数据（如 Stars 数）以调研时公开数据为准。

目录

  1. 背景与动机
  2. 评测框架分类体系
  3. 第一梯队：通用评测基础设施
  4. 第二梯队：垂直领域评测框架
  5. 综合对比分析
  6. 技术架构共性分析
  7. 选型建议
  8. 结论与展望

1. 背景与动机

1.1 为什么需要评测 Agent

与传统 LLM 不同，Agent 具有以下本质特征：

  • 自主决策：Agent 可在无人工干预下执行多步操作
  • 工具调用：通过 API / 函数调用与外部系统交互
  • 状态变更：操作会真实改变环境状态（数据库、文件系统、网页等）
  • 轨迹可回溯：每一步决策都有执行记录，可回放分析

这些特性决定了 Agent 不能仅靠文本输出的质量来评测，必须评估其行为过程和最终结果的正确性。

1.2 评测的四个核心维度

维度含义示例指标
任务完成度Agent 是否完成了用户指定目标任务成功率、数据状态一致率
过程合理性Agent 的执行路径是否合理、高效工具调用准确率、平均交互轮数
效率与成本在完成任务的前提下资源消耗如何平均耗时、Token 消耗、成本/$
安全性与合规是否遵守业务规则和安全约束规则违背率、越界操作率

1.3 本次调研范围

调研覆盖 GitHub Stars 数较高（>200）、近期有活跃更新的 10 个主流 Agent 评测框架，涵盖通用综合评测、垂直领域评测、过程性评测三大类别。

2. 评测框架分类体系

Agent 评测框架按评测粒度和适用场景可划分为三大类：

┌─────────────────────────────────────────────────────┐
│                    Agent 评测框架                     │
├──────────────┬──────────────────┬───────────────────┤
│   第一梯队    │    第二梯队       │      第三梯队     │
│ 通用评测基础设施│  垂直领域专项    │  企业内部定制     │
├──────────────┼──────────────────┼───────────────────┤
│ CUA          │ SWE-bench（代码） │ 自建测试集 +     │
│ AgentBench   │ τ-bench（客服）   │ OpenCompass /    │
│ AgentBoard   │ GAIA（通用能力）  │ Langfuse 自定义  │
│ WebArena     │ Chronos（调试）   │ 评测管道         │
│ OSWorld      │ SanityHarness    │                  │
│              │ （编程场景）      │                  │
└──────────────┴──────────────────┴───────────────────┘
类别核心特征代表框架
环境仿真型构建标准化仿真环境，Agent 在其中执行任务WebArena、OSWorld、CUA
综合基准型多任务多环境统一评测，输出横向对比AgentBench
过程分析型不只看结果，还拆解 Agent 的决策过程AgentBoard
领域垂直型专注单一场景（代码/客服/工具调用等）SWE-bench、τ-bench、GAIA
轻量工具型简单可扩展，适合快速接入自定义 AgentSanityHarness

3. 第一梯队：通用评测基础设施

3.1 CUA

属性值
GitHubhttps://github.com/trycua/cua
Stars⭐ 14,798（截至 2026-04）
Fork928
协议MIT License
最新更新2026-04-27（持续活跃）
官方主页https://cua.ai
3.1.1 核心定位

CUA（Computer-Use Agent Infrastructure）定位为 Computer-Use Agent 的完整基础设施栈，强调"训练+评测"一体化。不同于传统只关注评测的框架，CUA 同时提供：

  • Sandbox（沙箱）：macOS / Linux / Windows 全平台隔离执行环境
  • SDK：标准化 Agent 与沙箱交互的接口
  • Benchmark：专门评估 Agent 控制完整桌面的能力
3.1.2 技术特点
  • 多平台沙箱化：基于容器和虚拟化，Agent 在隔离环境中执行桌面操作，无法影响宿主机
  • 跨平台覆盖：同时支持 macOS、Linux、Windows 三大桌面操作系统
  • 评测任务类型：文件操作、应用启动、浏览器控制、系统设置、多应用协作等真实桌面任务
  • 与 OpenAI Operator / Anthropic Computer Use 对标：是开源社区中唯一对标的完整复现
3.1.3 适用场景
  • 评测需要操作完整桌面应用的 Agent（如 RPA 类应用）
  • 研究 Computer Use 场景下的安全性和可靠性
  • 需要在 Windows / macOS 环境验证 Agent 跨平台行为
3.1.4 局限性
  • 专注于桌面操作场景，不适合纯对话/纯工具调用类 Agent
  • 沙箱环境部署复杂度较高，对硬件资源有一定要求
  • 作为 2025 年初发布的新项目，部分功能仍在快速迭代中

3.2 AgentBench

属性值
GitHubhttps://github.com/THUDM/AgentBench
Stars⭐ 3,369（截至 2026-04）
Fork249
协议Apache 2.0
发表ICLR 2024
最新更新2025-02-08
维护方清华大学 THUDM 团队
3.2.1 核心定位

AgentBench 是 目前应用最广泛的综合多环境 Agent 评测基准，通过统一的接口和标准化任务集，对不同 LLM 作为 Agent 的能力进行横向评估，覆盖 8 大真实模拟环境。

3.2.2 评测环境覆盖
环境类型评测任务
Operating System (OS)Ubuntu 虚拟机文件操作、命令执行、系统配置
Database (DB)MySQLSQL 生成与执行、数据库操作
Knowledge Graph (KG)知识图谱知识问答、路径推理
Digital Card Game (DCG)卡牌游戏策略决策、多步推理
Lateral Thinking Puzzles (LTP)横向思维谜题创意推理
House-Holding (HH)家务仿真物品操作、任务规划
Web Shopping (WS)电商仿真商品检索、比价、下单
Web Browsing (WB)网页浏览仿真信息检索、页面导航
3.2.3 评测指标
  • Success Rate (SR)：Agent 在限定交互步数内完全达到目标的比例（DB/OS/WB 等）
  • F1 Score：基于问答任务，Agent 输出与标准答案的调和平均（KG）
  • Reward：策略质量综合得分（DCG/WS）
3.2.4 技术架构
AgentBench
├── agents/           ← Agent 实现（VanillaAgent / ReActAgent / 自定义）
├── llm/              ← LLM 调用接口（OpenAI / Claude / vLLM / 本地模型）
├── tasks/            ← 各环境评测任务（9 个独立任务模块）
│   ├── db.py         ← Database 任务
│   ├── os.py         ← OS 任务
│   └── ...
├── utils/
│   └── logging/      ← 轨迹记录 + 指标汇总
└── eval_main.py      ← 统一评测入口

设计亮点：每个 Task 独立实现 execute() 和 compute_metrics()，通过注册表模式（Registry）实现插件化扩展，新增任务只需实现基类接口并注册。

3.2.5 局限性
  • 部分环境依赖 Docker，部署复杂度较高（特别是 WebArena 子集）
  • 主要评估"LLM 作为 Agent"，对已部署的自研 Agent 服务的适配需要额外开发
  • 结果评估以成功率为主，缺乏过程性分析维度

3.3 WebArena

属性值
GitHubhttps://github.com/web-arena-x/webarena
Stars⭐ 1,444（截至 2026-04）
Fork~190
协议—
发表NeurIPS 2023 (Spotlight)
最新更新2026-04-25（持续活跃）
3.3.1 核心定位

WebArena 是一个 高仿真、可控、可复现的 Web 交互环境，专门用于评测 AI Agent 在仿真网站上执行自动化任务的能力。核心价值在于构建了与真实网站高度一致的仿真环境，避免了公开互联网环境的不稳定性和不可复现问题。

3.3.2 仿真网站类型
  • 电商论坛（e.g., Online Forum）：多步骤表单填写、帖子管理
  • 社交协作平台（e.g., CMS 系统）：内容管理、权限操作
  • 开发协作工具（e.g., GitLab 简化版）：代码审查、Issue 管理
  • 购物网站（e.g., Reddit 类）：信息检索、比价
  • 实用工具：地图搜索、日程管理等
3.3.3 评测指标
  • Task Success Rate：Agent 是否正确完成全部子任务
  • Step-by-Step Accuracy：每个操作步骤（点击、输入）的执行正确率
  • Action Precision：操作动作的类型和目标是否正确
3.3.4 局限性
  • 环境依赖 Playwright + Xvfb，对 CI/CD 集成有一定要求
  • 仿真网站与真实网站存在差异，评测结果可能与生产环境有偏差
  • 任务以短交互为主，对复杂多轮推理场景覆盖有限

3.4 OSWorld

属性值
GitHubhttps://github.com/xlang-ai/OSWorld
Stars⭐ 2,814（截至 2026-04）
Fork~130
协议—
发表2024
维护方XLang Lab
3.4.1 核心定位

OSWorld 是第一个 基于真实 Ubuntu 桌面的多任务操作系统评测基准，每个任务都需要 Agent 在真实桌面环境中执行多步操作（如打开文件、运行脚本、配置系统参数等），以截图+状态变化作为评判依据。

3.4.2 与 WebArena 的区别
维度WebArenaOSWorld
仿真对象Web 应用完整操作系统（Ubuntu）
交互方式浏览器 DOM 操作键盘+鼠标+命令行
环境真实性高（仿真网站）更高（真实 OS）
评测成本中等较高（需要虚拟机）
主要场景Web 操作 AgentOS 操作 Agent / DevOps Agent
3.4.3 局限性
  • 评测成本高（需要维护多个真实虚拟机实例）
  • 评判依赖截图+状态比对，自动评测难度大
  • 主要覆盖 Linux 桌面场景，macOS/Windows 支持有限

3.5 AgentBoard

属性值
GitHubhttps://github.com/hkust-nlp/AgentBoard
Stars⭐ 409（截至 2026-04）
Fork42
协议GPL-2.0（数据）/ Apache 2.0（代码）
发表NeurIPS 2024（Oral）
最新更新2024-05-20（代码最后推送）
3.5.1 核心定位

AgentBoard 首次提出 过程性评测（Analytical Evaluation） 理念——不只评估"是否成功"，更拆解 Agent 在执行过程中的能力短板，是目前过程性评测方向最有影响力的开源工作。

3.5.2 评测的 9 个任务
类型任务特点
Embodied AIAlfWorld、ScienceWorld、BabyAI物品操作、科学实验、游戏导航
GameJericho、PDDL文字冒险游戏、规划任务
WebWebShop、WebArena电商操作、网页浏览
ToolTool-Query、Tool-OperationAPI 调用、工具链编排
3.5.3 核心评测指标体系

1. Success Rate（任务成功率）

任务在最大交互步数内完全达到目标 = 1，否则 = 0
整体成功率 = 成功任务数 / 总任务数

2. Progress Rate（进度率） ⭐ AgentBoard 首创

Progress Rate = 已完成子目标数 / 总子目标数
  • 取值范围 [0, 1]
  • 能区分"完成了 60%"和"完成了 90%"的 Agent
  • 两个 Agent 成功率相近时（1% vs 3.9%），进度率可能差异显著（18.9% vs 24.6%）

3. Grounding Accuracy（落地准确率）

Grounding Accuracy = 无 ERROR 报错的工具调用数 / 总工具调用数
  • 衡量"动作是否可执行"，不衡量"是否最优"
  • 只要调用不报错就算对，即使选择了次优工具

4. 六大能力维度评分

维度考察能力典型任务
Memory长程上下文信息利用多轮对话、跨步信息传递
Planning目标分解为可执行子目标复杂任务拆解
World Modeling环境隐状态推断与维护部分可观测环境探索
Retrospection基于反馈的自我修正错误检测与回退
Grounding有效动作生成与执行工具调用成功率
Spatial Navigation空间目标定位与移动游戏导航、路径规划

5. Score State（得分状态）

[(step_id, score), ...]
  • 记录每个任务执行过程中得分变化的节点
  • 用于绘制 Agent 的"学习曲线"，看任务推进节奏
  • 仅当得分提高时才记录
3.5.4 技术架构
# BaseAgent 接口（极度简洁）
class BaseAgent:
    def reset(self, goal, init_obs, init_act=None): pass
    def update(self, action, state): pass
    def run(self): pass
    @classmethod
    def from_config(cls, llm_model, config): pass

# 评测入口（eval_main.py）
llm = load_llm(name, config)           # 加载 LLM
task = load_task(name, config)         # 工厂模式加载任务
for example in task.test_dataset:
    agent.reset(goal, init_obs)
    for step in range(max_steps):
        action = agent.step(state)                 # Agent 决策
        state, reward, done = task.execute(action) # 环境执行
        task.evaluator.update(...)                 # 记录轨迹
    task.evaluator.compute_metrics()               # 计算指标
summary_logger.log_run_result(...)

设计亮点：Registry 注册表模式 + Factory load_task + 可视化面板，三者构成高度解耦的评测生态。

3.5.5 局限性
  • Grounding Accuracy 无法判断工具选择的合理性（只要不报错就算对）
  • 没有内容质量评估（生成内容是否正确、准确）
  • 没有用户体验指标（响应时间、交互友好性）
  • 主要评估"LLM 作为 Agent"，对 API 类已部署 Agent 需要额外适配

4. 第二梯队：垂直领域评测框架

4.1 SWE-bench

属性值
GitHubhttps://github.com/SWE-bench/SWE-bench
Stars⭐ 4,806（截至 2026-04）
Fork~800
协议Apache 2.0
发表ICLR 2024
维护方Princeton NLP Lab / SWE-bench Organization
4.1.1 核心定位

SWE-bench 是目前 代码修复领域最权威的评测基准，其核心思路是：从真实 GitHub 仓库中提取已解决的 Issue，然后让 Agent 根据 Issue 描述自动生成修复补丁（Pull Request），通过对比补丁与真实修复的一致性来评估能力。

4.1.2 数据集规模
  • SWE-bench-Full：约 2,294 个真实 GitHub Issue（覆盖 Python、JavaScript 等多语言）
  • SWE-bench-Lite：精选约 300 个高质量 Issue，适合快速评测
  • 数据来源：django、flask、matplotlib、pytest 等主流开源项目
4.1.3 评测方式
  1. 环境复现：在 Docker 容器中复现 Issue 提到的 Bug 环境
  2. Agent 生成：Agent 阅读 Issue 描述、复现代码，生成修复补丁
  3. 结果验证：
    • Install：环境是否能正常安装（无 ImportError）
    • Pass：单元测试是否通过
    • Format：格式是否符合要求
  4. 评判指标：_patch 是否与真实修复一致（精确匹配）
4.1.4 局限性
  • 评测的是"LLM 的代码修复能力"，不是"已部署 Agent 服务的能力"
  • 评测的是单次交互，不涉及多轮对话和工具调用轨迹
  • 需要维护大量 Docker 容器，资源成本较高

4.2 τ-bench（TAU-bench）

属性值
GitHubhttps://github.com/sierra-research/tau-bench
Stars⭐ 1,191（截至 2026-04）
协议—
发表2024
维护方Sierra Research
4.2.1 核心定位

τ-bench 是专门用于评估 客服/业务流程 Agent 的评测框架，核心创新在于：通过比对任务完成后数据库状态变化来判断任务是否成功，而非依赖人工打分或 LLM as Judge。

4.2.2 评测流程
用户模拟（User Sim）→ 发送自然语言请求
       ↓
Agent 接收请求 → 多轮对话理解需求
       ↓
Agent 调用领域工具（预订航班、退货等）→ 操作内部数据库
       ↓
比对：数据库最终状态 vs 预期目标状态
4.2.3 核心指标
指标含义
pass¹（Task Success Rate）单次对话中，数据库状态达到目标的比例
passᵏ（Stability over Repeats）同一任务连续 k 次全部成功的概率，衡量稳定性
Rule Compliance RateAgent 是否遵守领域策略文档的比例（如"经济舱不可改签"）
Error Breakdown失败样本分类：未询票号、违规直改、API 调用失败等
4.2.4 两个评测场景
  • Retail（零售客服）：退货处理、订单修改、投诉等
  • Airline（航旅行程）：航班改签、预订、行李处理等
4.2.5 局限性
  • 场景相对有限（零售 + 航旅），泛化到其他业务场景需要自行扩展
  • 用户模拟器质量直接影响评测有效性
  • passᵏ 的 k 值选择需要权衡评测时间与稳定性置信度

4.3 GAIA

属性值
Stars—（数据托管于 HuggingFace，非 GitHub）
发表NeurIPS 2023
维护方Hugging Face / GAIA Team
4.3.1 核心定位

GAIA（General AI Assistants benchmark）是一个 通用任务评测基准，专注于评测 AI 助手在真实世界复杂、多模态、多步骤问题上的综合能力，强调多轮推理和跨模态信息整合。

4.3.2 评测特点
  • 多模态：同时包含文本、图像、表格等多种信息源
  • 多阶段：任务需要多个推理阶段，Agent 需要自主规划步骤
  • 真实性：任务来源于真实世界问题，而非人工构造
  • 通用性强：覆盖问答、信息检索、推理判断等多种任务类型
4.3.3 局限性
  • 评测重点是"通用 AI 助手"而非"执行型 Agent"
  • 不涉及真实环境交互和状态变更
  • 以最终答案正确性为主要评判标准

4.4 SanityHarness

属性值
GitHubhttps://github.com/lemon07r/SanityHarness
Stars⭐ 219（截至 2026-04）
语言Go
协议—
最新更新2026-04（活跃）
主页https://sanityboard.lr7.dev/
4.4.1 核心定位

SanityHarness 是一个 轻量级编程 Agent 评测工具，设计理念是"简单、快速、通用"，用 Go 语言实现，评测成本极低，适合：

  • 快速验证新 Agent 的编程能力
  • 在 CI/CD 管道中嵌入 Agent 评测
  • 评测任意编程语言（Python / JavaScript / Rust 等）
4.4.2 局限性
  • Stars 数较低（219），社区活跃度和维护持续性有待验证
  • Go 语言实现的评测框架与 Python 主流 AI 生态集成可能需要额外适配

4.5 Chronos

属性值
GitHubhttps://github.com/Kodezi/Chronos
Stars⭐ 4,946（截至 2026-04）
Fork213
语言Java（主体）+ Python（集成）
最新更新2025-11
主页https://chronos.so/
4.5.1 核心定位

Chronos 是一个 调试专用语言模型，定位不是评测框架，而是一个在 SWE-bench Lite 上达到 80.33% 通过率的最先进调试模型。其技术特点（Adaptive Graph-Guided Retrieval + Persistent Debug Memory）对 Agent 评测有参考价值。

4.5.2 技术亮点
  • Adaptive Graph-Guided Retrieval：基于代码结构图引导检索相关代码上下文
  • Persistent Debug Memory：在调试过程中维护持久化的调试状态记忆
  • 真实修复准确率：67%（是 GPT-4 的 6 倍）
4.5.3 对评测的启示
  • 调试场景是 Agent 能力的重要检验维度
  • 代码结构感知（AST 级别的检索）对复杂调试任务至关重要

5. 综合对比分析

5.1 功能定位对比

框架定位是否框架是否有数据集是否开源环境
CUAComputer-Use Agent 基础设施✅✅✅（沙箱）
AgentBenchLLM-as-Agent 综合评测✅✅✅（Docker）
AgentBoard过程性评测 + 能力维度分析✅✅✅
WebArenaWeb 操作 Agent 评测✅✅✅（Playwright）
OSWorldOS 操作 Agent 评测✅✅✅（虚拟机）
SWE-bench代码修复 Agent 评测✅（数据集为主）✅✅（Docker）
τ-bench客服/业务流程 Agent 评测✅✅✅（模拟 DB）
GAIA通用 AI 助手能力评测❌（数据集为主）✅❌
SanityHarness轻量编程 Agent 评测工具✅✅❌
Chronos调试专用模型（非评测框架）——✅

5.2 评测指标对比

框架成功率进度率工具调用准确率稳定性/pass^k规则遵循率过程回放
CUA✅❌❌❌❌✅
AgentBench✅（主要）❌❌❌❌✅
AgentBoard✅✅（首创）✅❌❌✅
WebArena✅❌✅（Step SR）❌❌✅
SWE-bench✅（patch 匹配）❌❌❌❌❌
τ-bench✅（pass¹）❌❌✅（pass^k）✅❌
GAIA✅❌❌❌❌❌
SanityHarness✅❌✅❌❌❌

5.3 适用场景对照

场景推荐框架
评测桌面/全栈操作类 AgentCUA（首选）、OSWorld
评测LLM 作为 Agent的综合能力AgentBench（首选）、AgentBoard
评测 Agent 执行过程的能力短板AgentBoard（首创 Progress Rate）
评测Web 操作类 AgentWebArena（首选）、AgentBench
评测代码开发/修复类 AgentSWE-bench（首选）、Chronos 参考
评测客服/业务流程类 Agentτ-bench（首创 DB 状态比对）
快速轻量接入自定义 AgentSanityHarness（首选）、自建基于 AgentBoard 架构
评测多模态通用助手能力GAIA

5.4 工程复杂度对比

框架部署难度资源需求维护成本扩展难度
CUA高（多平台沙箱）高（容器+隔离）中中（SDK 接口）
AgentBench高（多 Docker 环境）高高中（注册表模式）
AgentBoard中（部分任务有依赖）中中低（插件化架构）
WebArena高（Playwright+Xvfb）中高高
SWE-bench高（大量 Docker 实例）高高低（数据集独立）
τ-bench中（模拟环境）中中中（场景需扩展）
SanityHarness低（Go 单二进制）低低低

6. 技术架构共性分析

尽管各框架评测目标和场景各异，其评测管线存在高度共性的架构模式：

6.1 标准评测管线

输入（任务描述）
  ↓
Agent 初始化（reset）
  ↓
┌──────────────────────────────────────┐
│         多轮交互循环（for step）        │
│  Agent 决策（action = agent.step()）  │
│         环境执行（state = env.execute）│
│         指标更新（evaluator.update()） │
│         是否完成 → break             │
└──────────────────────────────────────┘
  ↓
指标计算（compute_metrics）
  ↓
结果输出（logs / JSON / WandB 可视化）

6.2 核心抽象模式

模式作用典型实现
BaseAgent 接口统一 Agent 行为定义，隔离评测与 Agent 实现AgentBoard：BaseAgent.reset/step/update
Task 工厂模式从配置加载任务，插件化扩展AgentBench：load_task(name, config)
注册表模式字符串名 → 类实例化，支持动态扩展AgentBoard：registry.register_task()
Evaluator 抽象每个任务独立实现 execute() + compute_metrics()各 Task 类
轨迹记录器记录每步决策和执行结果，支持回放AgentBoard：AgentLogger、SummaryLogger
状态比对评测目标状态 vs 实际状态，评判任务成功τ-bench：数据库状态比对

6.3 评测方法论分层

┌─────────────────────────────────────────┐
│           LLM as Judge（顶层裁判）          │
│  用强模型评估 Agent 输出质量、过程合理性      │
├─────────────────────────────────────────┤
│           规则/状态比对（中层验证）           │
│  规则库校验、数据库状态一致性检测             │
├─────────────────────────────────────────┤
│           任务成功与否（底层判定）            │
│  目标达成检测、输出匹配度检测                 │
├─────────────────────────────────────────┤
│           过程性指标（辅助分析）              │
│  Progress Rate、工具调用准确率、轮数         │
└─────────────────────────────────────────┘

7. 选型建议

7.1 按需求场景选型

需要评测的 Agent 类型？
│
├─ 通用 LLM-as-Agent 综合能力
│   └─ AgentBench（多环境覆盖）+ AgentBoard（过程分析）
│
├─ 客服/业务流程 Agent（数据库状态变更类）
│   └─ τ-bench（参考其 DB 状态比对思路）
│
├─ 代码开发/修复 Agent
│   └─ SWE-bench（数据集）+ Chronos（技术参考）
│
├─ Web 操作 Agent
│   └─ WebArena（首选）+ AgentBench Web 子集
│
├─ 桌面操作 Agent（macOS/Linux/Windows）
│   └─ CUA（最新最热）+ OSWorld（OS 仿真）
│
└─ 快速接入自定义 Agent（轻量级）
    └─ SanityHarness + 基于 AgentBoard 架构自建

7.2 对 annto-eval 的具体建议

基于对各框架的分析，对 annto-eval Agent 评测模块的建设提出以下建议：

架构层面，推荐参考 AgentBoard 的 Registry 注册表模式：

# 参考 AgentBoard 的设计，自己实现
registry.register_task("sql", EvalSQL)      # SQL 评测任务
registry.register_task("api", EvalAPI)      # API 调用评测
registry.register_task("chatbot", EvalChatbot)  # 对话评测

# 统一评测入口
task = registry.get_task_class(name).from_config(config)
for example in task.test_dataset:
    agent.reset(example.goal)
    for step in range(max_steps):
        action = agent.step(state)
        state = task.execute(action)
    task.compute_metrics()

评测指标层面：

  • 基础层：任务成功率（数据状态比对 or 规则校验）
  • 过程层：参考 AgentBoard 引入 Progress Rate（子目标完成度）
  • 稳定性层：参考 τ-bench 引入 pass^k（多次运行的稳定性）
  • 效率层：平均交互轮数、平均 Token 消耗

数据层面：

  • 优先参考 τ-bench 的数据准备方式：从真实业务场景采集
  • 没有真实数据时参考 GAIA 的 self-instruct 方式冷启动
  • 优先级：真实用户 query 匿名化 > 人工构造边界 case > 开源 Benchmark 裁剪

8. 结论与展望

8.1 主要结论

  1. Agent 评测已形成完整的技术生态：从通用综合框架（AgentBench）到垂直领域专项（SWE-bench、τ-bench），从过程性分析（AgentBoard）到轻量工具（SanityHarness），各有明确定位。
  2. 评测方法论趋于成熟：以"数据状态比对 + 规则校验 + LLM as Judge"为主的多层评测体系已被广泛验证。
  3. 工程架构高度收敛：Registry 注册表 + Factory 加载 + Evaluator 抽象 + 轨迹记录的模式已成为事实标准，降低了自建评测系统的门槛。
  4. CUA 是 2025 年最值得关注的新框架：14.8k Stars 的增长势头和 MIT 协议使其成为 Computer-Use Agent 评测的首选基础设施。
  5. 过程性评测是重要趋势：AgentBoard 提出的 Progress Rate 理念填补了"成功率 vs 失败率"之间的评测空白，值得在 annto-eval 中优先引入。

8.2 展望

  • 多模态 Agent 评测：随着视觉-语言模型的发展，同时评估 Agent 的视觉理解与操作执行能力将成为新方向
  • 安全与对齐评测：Agent 的越界操作检测、指令遵循安全评测正在成为独立研究领域
  • 生产环境在线评测：相比离线评测，在生产环境中持续监控 Agent 表现的框架（如 Langfuse 集成）值得关注

参考资源

框架链接
CUAhttps://github.com/trycua/cua
AgentBenchhttps://github.com/THUDM/AgentBench
AgentBoardhttps://github.com/hkust-nlp/AgentBoard
WebArenahttps://github.com/web-arena-x/webarena
OSWorldhttps://github.com/xlang-ai/OSWorld
SWE-benchhttps://github.com/SWE-bench/SWE-bench
τ-benchhttps://github.com/sierra-research/tau-bench
GAIAhttps://huggingface.co/datasets/gaia-benchmark/GAIA
SanityHarnesshttps://github.com/lemon07r/SanityHarness
Chronoshttps://github.com/Kodezi/Chronos
# 人工智能
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

从零构建 Java 智能体 RAG 系统：Milvus 向量数据库实战指南

avatar CSDN-OPC开发者社区
cover

DeepSeek-Harness-入门指南

avatar CSDN-OPC开发者社区
cover

提升办公效率：OpenClaw 本地自动化 AI 工具搭建实战教程

avatar CSDN-OPC开发者社区