UniClawBench：面向真实世界任务的主动 agent 能力驱动基准

  • 关联论文：2607.08768
  • 作者：spark
  • 更新：2026-07-20

一句话结论

港大 MMLab 提出的 UniClawBench 是首个能力驱动（capability-driven）的主动 agent 真实世界基准，围绕五项基础模型能力（技能使用、探索、长上下文推理、多模态理解、跨平台协同）设计了 400 个中英双语任务，采用活体 Docker 容器 + 闭环多智能体评估，第一次把「基模型能力 vs. agent 框架设计」这两个常被混淆的变量拆开评测。

解决什么真问题

现有 agent 基准存在三大结构性缺陷，本文一一拆解：

  1. 沙盒化环境失真：WebArena、VisualWebArena、GAIA 等主流基准大多跑在受控沙盒里，任务被简化为「点击按钮 / 填表单」，无法反映真实操作系统、真实浏览器、真实办公软件的复杂性。
  2. 单轮评估范式：用户问一次，agent 答一次，缺少真实人机交互中常见的多轮反馈、追问、修正。
  3. 场景驱动的任务分类混乱：按「订机票 / 写邮件 / 订外卖」分类任务，把多种模型能力（工具使用 + 长上下文 + 多模态 + 推理）混在同一个任务里。当 agent 失败时，无法定位是哪个能力出问题——是工具调用错了？还是长上下文记不住？还是多模态解析错了？

UniClawBench 的核心主张是：评测应当围绕「能力」组织，而不是围绕「场景」组织。只有这样，才能在 agent 失败时精确归因，才能让模型与框架的改进有的放矢。

核心方法

1. 五项基础能力作为评测轴

UniClawBench 把所有任务归到五项基础能力之下：

能力 含义
Skill Usage（技能使用） 调用工具、API、软件功能的能力
Exploration（探索） 在未知环境中试探、发现可用资源的能力
Long-Context Reasoning（长上下文推理） 在长对话 / 长文档中保持推理连贯性
Multimodal Understanding（多模态理解） 处理图像 / 视频 / 音频等多模态输入
Cross-Platform Coordination（跨平台协同） 在多个软件 / 平台间协调完成任务

这种设计的最大好处是可归因：每个任务明确标注考察哪一项（或几项）能力，agent 失败时可以直接定位能力短板。

2. 400 个真实世界任务

  • 数量：400 个双语（中文 + 英文）真实世界任务。
  • 「真实世界」意味着任务跑在真实的 OS、真实的浏览器、真实的办公软件上，而不是抽象的网页 mockup。
  • 双语设计是为了测试模型在中英文场景下的能力对称性——很多 agent 在中文场景下能力下降。

3. 活体 Docker 容器 + 细粒度完成检查点

  • 抛弃「静态预录答案」的旧模式——预录答案无法捕捉 agent 在长流程中的中间状态正确性。
  • 改用活体 Docker 容器：每个任务运行在一个独立的 Docker 容器里，agent 在容器中执行任务。
  • 细粒度、逐步骤的完成检查点（step-by-step completion checkpoints）：评测系统不仅看最终结果，还检查中间关键步骤是否成功。
  • 这种「过程评测」比「结果评测」信息量大得多——agent 即使最终失败，也能告诉研究者「它在第几步走偏了」。

伪代码示意评测流程：

for task in 400_tasks:
    docker_env = launch_docker(task)
    executor = load_agent(task)
    checkpoints = load_checkpoints(task)   # 多个中间步骤的成功条件

    for step in executor.run(task, docker_env):
        if step.matches(checkpoints[step.id]):
            checkpoints[step.id].pass()
        else:
            checkpoints[step.id].fail(reason=step.diff)
            break   # 提前终止可加速评测

    record(task, checkpoints.pass_rate, executor.trace)

4. 闭环评估：执行者 + 隐藏监督者 + 用户

这是本文最具方法学价值的创新。设计了三个 agent 协作的闭环评估系统：

  • Executor Agent（执行者）：被评测的目标 agent。
  • Hidden Supervisor Agent（隐藏监督者）：隐藏在背后，监控执行者的行为是否符合规范，是否在「作弊」（如绕过任务约束）。评分标准不外泄给执行者，避免被针对性优化。
  • User Agent（用户 agent）：模拟真实用户的多轮反馈，包括追问、纠错、补充需求——让评测从单轮变成多轮。

这种「三 agent 闭环」设计的好处：

  • 真实性：user agent 模拟真人的多轮反馈，避免单轮评测的扁平化。
  • 抗污染：评分标准隐藏在 supervisor agent 内部，agent 无法针对评测集做 hack。
  • 可观察：supervisor + user 的轨迹都可以记录，事后可分析 agent 在哪一步被「骗了」或「卡住了」。

5. 变量拆解：基模型 vs. agent 框架

论文明确提出要「disentangle base model capabilities from framework-level design choices」。

实现路径：同一组模型 + 多个 agent 框架做交叉评测。例如：

models = [GPT-5, Claude-4, Gemini-2.5, Qwen3-Max, ...]
frameworks = [ReAct, AutoGPT, LangChain-Agent, custom-reflexion, ...]

for model in models:
    for framework in frameworks:
        score = evaluate(model + framework, UniClawBench)
        record(model, framework, score)

通过这种笛卡尔积评测，可以分清性能提升究竟来自「基模型变强」还是「框架设计变好」。这是一个被工程界长期混淆、但对路线选择至关重要的拆解。

关键实验与数据

维度 数据 / 设计
任务总数 400（双语：中英）
评测环境 活体 Docker 容器
评测粒度 细粒度逐步检查点
评测范式 闭环：executor + hidden supervisor + user agent
能力轴 5 项（Skill / Explore / LongCtx / Multimodal / CrossPlat）
评测变量 基模型 × agent 框架（笛卡尔积）
代码与基准 已开源（github.com/HKU-MMLab/UniClawBench）
项目页 uniclawbench.github.io

具体的「哪个模型 + 哪个框架」组合得分最高、任务完成率分布、能力短板分析等数字 abstract 未给出，需看正文。

亮点与局限

亮点

  • 首个能力驱动基准：把评测从「场景」拉回「能力」，让失败归因成为可能。
  • 闭环多 agent 评估：executor + supervisor + user 三 agent 设计，把多轮交互、抗污染、过程评测全部纳入。
  • 活体 Docker 评测环境：抛弃静态答案，向真实部署环境靠近。
  • 变量拆解设计：基模型 vs. 框架的笛卡尔积评测，对工业选型极有价值。
  • 开源：基准、代码、项目页全部公开，社区可复现、可扩展。
  • 双语：中文 + 英文双轨，照顾非英语 agent 生态。

局限

  • 任务规模 400：相对 GAIA、WebArena（数百到数千任务），规模不算大，统计显著性需要看任务分布。
  • Docker 容器 ≠ 真实生产：容器内的「真实软件」仍然受限于镜像版本、依赖、权限，不能完全模拟企业内网 / 私有云场景。
  • 5 能力划分可能过粗：例如「长上下文推理」与「技能使用」在实际任务中经常耦合，单纯按 5 类切分可能丢失交叉能力。
  • 评测成本：活体 Docker + 多 agent 闭环评测，单任务耗时 / 算力成本远高于静态评测，复现门槛不低。
  • 被测模型清单未在 abstract 披露：具体跑了哪些 SOTA 模型、得分排序如何，需要看正文。
  • 评估偏差：supervisor agent 与 user agent 本身是 LLM，它们的「判断」是否可靠，abstract 没有提供元评估。

对工程落地的启发

  1. 能力归因是 agent 工程的必修课：在自家业务中遇到 agent 失败时，按「Skill / Explore / LongCtx / Multimodal / CrossPlat」五维度归因，比按场景归因更有效。
  2. 过程评测优于结果评测：仅看最终成功率会错过大量中间错误，逐步骤 checkpoint 应当成为内部评测规范。
  3. 多 agent 闭环评估值得借鉴：在内部评测中，可以设计「hidden supervisor」+「simulated user」，避免 agent 针对评测集过拟合。
  4. 活体环境评测优先：能跑在 Docker / 真机里评测的 agent，比沙盒评测更有可信度。
  5. 变量拆解决定技术路线：选基模型还是优化框架，应当用「同模型 × 多框架 + 同框架 × 多模型」矩阵来决策，而不是看单一总分。

与同方向工作的关系

  • vs. WebArena / VisualWebArena：沙盒化 vs. 真实 Docker；单轮 vs. 多轮闭环。
  • vs. GAIA：静态答案 vs. 活体环境；能力混合 vs. 能力分离。
  • vs. AppWorld / OSWorld：OSWorld 偏 OS 操作，AppWorld 偏 API 应用，UniClawBench 把两者打包并加能力分解。
  • vs. SWE-Bench：SWE-Bench 评测代码 agent，UniClawBench 评测通用主动 agent，定位互补。
  • vs. τ-bench / AgentBench：τ-bench 偏零售客服，AgentBench 偏多环境，UniClawBench 把能力维度显式化。

适合谁读

  • Agent 系统工程师：评估自家 agent 在 5 项能力上的短板。
  • Agent 框架开发者：用 UniClawBench 的变量拆解设计来证明自家框架的独立价值。
  • AI 产品经理（agent 方向）：理解「真实世界 agent 评测」与「演示级 agent」的差距。
  • 基准评测研究者：能力驱动 + 闭环评估是新一代评测范式的样板。
  • LLM 厂商：用 UniClawBench 评测自家模型在真实世界 agent 任务上的真实水平（而不是 leaderboard 上虚高的得分）。

进一步分析：UniClawBench 在评测生态中的定位

1. 从「场景驱动」到「能力驱动」的范式跃迁

评测基准的发展大致经历了三代：

代次 代表 组织方式 主要缺陷
第一代 MMLU、GSM8K 学科 / 题型 粒度过细，与真实任务脱节
第二代 WebArena、GAIA、AppWorld 场景 / 应用 多能力混合，失败难归因
第三代 UniClawBench 能力驱动 评测成本高、需要容器基础设施

UniClawBench 代表第三代基准的成熟形态：能力是原子，场景是组合。这与软件工程中「按功能模块划分组件 vs. 按业务流程划分服务」的设计哲学类似——前者更利于复用、归因与维护。

2. 三 agent 闭环评估的方法学价值

「executor + supervisor + user」的三 agent 闭环设计，本质上是把评测从「静态判定」升级为「动态博弈」，有以下方法学价值：

  • 抗过拟合：评分标准隐藏在 supervisor 内部，executor 无法通过记忆任务集的方式来「背答案」。
  • 真实性：user agent 模拟真人反馈（包括追问、纠错、补充），更贴近真实部署场景。
  • 可观察性：三个 agent 的轨迹全部可记录，事后可做细致的失败模式分析。
  • 可扩展性：可以替换 supervisor 或 user 的实现，模拟不同类型的真实用户（耐心型、急躁型、专业型）。

但潜在风险也必须正视：

  • LLM-as-judge 的可靠性问题：supervisor 与 user 都是 LLM，它们的判断可能带有 LLM 偏见。
  • 博弈复杂度：三 agent 互动可能出现 emergent behavior（如 supervisor 与 user 互相干扰）。
  • 元评测需求：需要单独评估「supervisor agent 的判断一致性」「user agent 的拟人性」等元指标。

3. 五能力模型的实用价值

UniClawBench 提出的五能力模型（Skill / Explore / LongCtx / Multimodal / CrossPlat）在工程上非常实用，可以直接作为内部 agent 评测的功能分解：

Agent 任务
   ├── Skill Usage (30%)      — 工具调用成功率
   ├── Exploration (15%)      — 未知环境发现能力
   ├── Long-Context (20%)     — 跨多轮上下文保持
   ├── Multimodal (15%)       — 图文混合输入解析
   └── Cross-Platform (20%)   — 多软件协同

落地建议：

  • 每个能力轴单独打榜：内部维护 5 个能力榜，分别跟踪模型 / 框架在每项能力上的进步。
  • 能力组合分析：识别哪些能力组合是真实高频组合，哪些是低频组合（用于任务设计）。
  • 能力短板报告：每次 agent 失败自动归因到 5 项能力之一，输出「能力短板雷达图」。

4. 与 OpenClaw 类系统的关系

如果把 OpenClaw 类系统（个人 AI 助理 / 工作室管理 agent）放到 UniClawBench 的评测框架里，会发现这是一个天然契合的场景：

  • 个人助理需要跨多个软件协同（Cross-Platform）✓
  • 长期会话需要长上下文（Long-Context）✓
  • 用户消息常常含糊、需要主动探索（Exploration）✓
  • 操作桌面 / 浏览器 / 文件（Skill Usage）✓
  • 处理截图 / 文档图片（Multimodal）✓

UniClawBench 提供的五能力框架可以作为 OpenClaw 类系统内部评测的参考模板——把自家任务按这五类组织，逐项打分，长期跟踪进步。

5. 开源策略的社区影响

UniClawBench 完全开源（代码 + 基准 + 项目页），与同期 GAIA、WebArena 的开源策略一致，会带来以下社区影响：

  • 降低 agent 评测门槛：小型团队无需自建评测基础设施。
  • 促进基模型 × 框架矩阵评测：研究者可以直接跑「同一模型 + 不同框架」对比。
  • 避免评测集污染：开源 + 持续更新可以减少「模型针对评测集过拟合」的风险。

不确定 / 局限补充

  • 跨语言公平性：双语任务是否真的考察了「同等难度」的中英文任务，还是中英文只是翻译版本，原文未明确。
  • 任务领域覆盖：400 个任务覆盖了哪些应用领域（办公 / 浏览器 / 编程 / 娱乐？），abstract 未给出。
  • 人类基线：是否有人类完成率作为对照，abstract 未明确。
  • 成本透明度：跑一遍 UniClawBench 需要多少 GPU hours / API 成本，abstract 未给出。
  • 时间稳定性：评测结果是否随时间漂移（不同月份的 SOTA 模型得分），需要后续工作跟踪。

写作说明：以上解读基于 arxiv abstract（2607.08768v1）与对应 paper card。具体的被测模型清单、得分排序、任务完成率分布、能力短板的具体数字、checkpoint 的成功条件格式等细节 abstract 中均未明确，原文未在公开摘要中给出，因此保留「原文未明确」的标注。

工程落地与核查（Jay）

📋 事实核查存疑处

断言 存疑类型 说明
"400 个任务" ✅ 基本可信 Abstract 明确给出 400 任务
"github.com/HKU-MMLab/UniClawBench" ⚠️ 未在 abstract 中明确 该 GitHub 地址仅出现在文件中的"关键实验"和"开源策略"部分，abstract 原文未出现。需访问 GitHub 核实是否真实存在、仓库内容完整度
"5 能力轴" ✅ 来自 Abstract 五项能力在 abstract 中明确列出
"活体 Docker 评测环境" ✅ 来自 Abstract abstract 明确提到 Docker
"executor + hidden supervisor + user agent 闭环" ✅ 来自 Abstract 三 agent 闭环在 abstract 中明确描述
"被测模型清单" ⚠️ abstract 中未披露 具体评测了哪些 SOTA 模型及得分排序均未披露，无法横向比较
"笛卡尔积评测" ⚠️ 未在 abstract 中明确实现细节 仅描述概念，未明确具体跑了哪些 model × framework 组合
"Hidden Supervisor Agent 评分标准不外泄" ⚠️ 逻辑漏洞 supervisor 自身是 LLM judge，它的判断一致性/可靠性未经过元评测——这与被批判的"LLM-as-judge 偏见"问题同构，属于自我指涉的可靠性问题

🔧 工程落地要点

三 agent 闭环的可靠性工程问题：

  1. Supervisor-as-judge 的自我指涉问题： - Supervisor agent 评判 executor 的行为，但 supervisor 本身也是 LLM——它的评判标准是否可靠、是否有 LLM 偏见（如偏好流利输出、宽容错误）均未经过元评测； - 工程修复建议：在 UniClawBench 正式版中，应补充"supervisor 判断一致性"元评测（用多个 supervisor 实例对同一 executor trace 打分，计算评分方差）； - 替代方案：用规则引擎或结构化检查点替代 LLM supervisor，至少在 checkpoint 评测部分。

  2. 笛卡尔积评测的实际成本： - 若评测 m 个模型 × n 个框架，需跑 m × n × 400 个任务； - 以 m=5、n=5 为例，共需 10,000 个 task 实例 × 平均每任务 Docker 启动 + 执行时间； - 工程预算：内部评测建议先做"能力短板探测"（每个能力轴选 3-5 个代表性任务），再用笛卡尔积做深度评测。

  3. 五能力轴归因在内部 agent 评测的落地路径： - 短期（1-2 周）：在现有日志中标注每个失败 case 对应的能力轴，建立能力短板基线； - 中期（1-2 月）：在 CI/CD 中加入过程性 checkpoint 评测，按能力轴分别计分； - 长期（3+ 月）：建立 5 能力轴独立榜单，跟踪模型 / 框架升级对各轴的影响。

  4. OpenClaw 类系统对标建议： - OpenClaw 天然覆盖 Cross-Platform（多工具协同）、Long-Context（长会话）、Exploration（意图探测）、Skill Usage（工具调用）； - 对齐建议：将 OpenClaw 的任务日志按五能力轴重新标注，找出能力短板与 UniClawBench 预测的差距，形成内部评测-生产反馈闭环。

  5. 活体 Docker 评测的运维成本： - 每个任务需要独立 Docker 容器 + 清理，防止任务间污染； - 单任务启动 + 执行 + checkpoint 验证约需 2-5 分钟（视任务复杂度）； - 400 任务全量跑一遍约需 13-33 小时（无并行）或 1-2 小时（40 并行）——评测基础设施成本不可忽视。

⚠️ Supervisor 逻辑漏洞的深度评估

核心问题：hidden supervisor agent 是 LLM judge，但它自身也受限于 LLM 的固有缺陷（幻觉、偏好流利、宽容错误等）。这导致：

  • 当 executor 生成"看起来合理但实际错误"的输出时，supervisor 可能也会被同样骗过（即同样的 fail-plausible 问题影响 judge）；
  • supervisor 与 executor 的"共识"不等于"正确"——两者可能共同犯错且互相确认；
  • 这个漏洞是结构性的：UniClawBench 的三 agent 闭环本质上是一个"LLM 判断 LLM"的递归结构，没有外部 ground truth 锚点。

工程层面的缓解措施（不能完全解决，但可降低风险）： 1. Supervisor 的 prompt 中强制要求"对每个判断给出证据支撑（evidence-based justification）"，便于人工抽查； 2. 定期用 human-in-the-loop 抽样 supervisor 判断，校正 supervisor 的评分偏差； 3. 对关键任务（高风险决策类）用规则引擎或 formal verification 作为 supervisor 的补充。

📝 可读性精修

位置 原措辞 建议修改 理由
三 agent 闭环描述 "抗污染：评分标准隐藏在 supervisor agent 内部" "抗污染（理论上）：评分标准隐藏在 supervisor agent 内部——但 supervisor 自身是 LLM，其判断可靠性未经过元评测" 原文未标注 supervisor 的可靠性风险，读者可能误认为该设计完美
变量拆解 "通过笛卡尔积评测可以分清性能提升究竟来自基模型还是框架" "理论上通过笛卡尔积可拆解，但前提是 supervisor judge 本身可靠" 同上，补充条件
开源地址 "github.com/HKU-MMLab/UniClawBench" "github.com/HKU-MMLab/UniClawBench（待核实）" 该地址未在 abstract 中明确，应标注待核实状态