待验证｜UniClawBench：400 个真实任务把 Agent 评测推向闭环执行

UniClawBench 值得看，原因在于它把 Agent 评测问题换成了「真实环境里能不能把事做完」。论文在 2026 年 7 月 9 日提交 arXiv，并在 7 月 10 日进入 Hugging Face Papers。作者把它定义为面向 proactive agents 的 capability-driven benchmark，重点是动态真实环境、闭环反馈和失败归因。

确定事实有几条。UniClawBench 覆盖 400 个双语真实任务，GitHub README 写明其中 200 个为英文任务，200 个为镜像中文任务。任务按 5 类基础能力组织：Skill Usage、Exploration、Long-Context Reasoning、Multimodal Understanding、Cross-Platform Coordination。每个能力族下，英文与中文各 40 个任务。

它的执行方式也不同。论文明确说，UniClawBench 不依赖静态、预录答案，而是在 live Docker containers 中让 Agent 执行任务，再用 fine-grained step-by-step completion checkpoints 判断进展。闭环结构由 executor agent、hidden supervisor agent 和 user agent 组成，目标是在不泄露评分规则的情况下模拟多轮用户反馈。

不确定部分同样要前置。本文按低置信处理，原因是少源且未复现。虽然本文使用了 6 个话题相关 URL，但绝大多数证据来自论文、GitHub 仓库和项目自带数据端点。论文里关于框架优劣、模型表现、自动监督一致性的结果，仍应视为作者自报实验。

读者影响很直接。做 Agent 框架的人，会看到自己系统的 context management、工具执行、状态传递和多轮修复能力正在被独立拎出来评估。企业试点 Agent 的团队，则可以借鉴它的 checkpoint 和 hidden supervisor 思路，把「任务完成」拆成可审计的中间证据，而不是只看最后一句回复。

从静态答题到闭环执行

传统 Agent benchmark 常见的问题，是把真实工作流压成一道题。模型回答对了，看起来分数很高；但到了真实用户环境里，它可能忘记前文、误点页面、丢文件路径、无法处理 GUI 弹窗，或者在跨应用切换时丢失目标。UniClawBench 的论文把这个问题拆成三层：环境真实度不足、单轮评测不足、场景分类无法定位失败根因。

第一层是环境。WebArena、OSWorld 这类基准已经把评测从纯文本推到浏览器和操作系统，但很多任务仍依赖镜像页面、缓存状态或固定环境。UniClawBench 试图再往前走一步，让任务在 Docker 里装好真实软件、浏览器、本地文件和服务资源。GitHub README 也显示，仓库包含 task resources、Docker-based runtimes、distributed dispatch scripts，以及用于查看 leaderboard、task definitions、traces、artifacts 和 timelines 的 WebUI。

第二层是交互。真实用户不会只给一次 instruction，然后等待 Agent 一次性完成所有事情。任务进行到一半时，用户可能补充约束、指出错误、要求改格式或解释结果。UniClawBench 的三角色闭环正是为这个问题设计：executor 负责实际执行；hidden supervisor 读取 private references 和 rubrics，对轨迹和产物打分；public user simulator 只能看到可见轨迹和经过处理的进展信号，再生成自然反馈。

第三层是归因。论文批评 scenario-based taxonomy 会把多种能力混在一个标签里。一个「office」任务失败，可能是模型不会读图，也可能是长上下文记不住，也可能是工具链状态同步失败。UniClawBench 改用能力驱动分类，至少能让失败分析更接近工程问题：是工具使用失败，还是探索失败，还是跨平台协调失败。

评测维度	传统静态评测常见做法	UniClawBench 的设计	仍需验证的风险
环境	固定页面、预录答案或沙盒状态	live Docker 容器、真实软件、浏览器和本地文件	真实服务变化会影响复现稳定性
交互	单轮输入和单轮输出	executor、hidden supervisor、user simulator 闭环	用户模拟器是否足够像真实用户
评分	最终答案匹配或整体判断	分步 checkpoint 和隐藏 rubrics	rubrics 泄漏与 LLM 监督偏差
分类	按 office、research 等场景归类	按 5 类基础能力定位失败根因	同一任务仍可能混合多种能力
对照	主要比较模型	同时比较模型和 Agent 框架	框架配置公平性需要外部复核

400 个任务如何组织

GitHub README 给出的 benchmark suite 很清楚：公开版本包含 400 个任务，其中 200 个英文任务与 200 个镜像中文任务。五个 capability family 分别是 Skill Usage、Exploration、Long Context、Multimodal、Cross Platform。每个英文路径下 40 个任务，每个中文路径下也 40 个任务。

这组设计的价值在于，它把语言和能力拆开了。很多 Agent 评测只测英文任务，或者只在中文任务上做翻译式扩展。UniClawBench 至少在任务清单层面把中英文平铺到同等规模：每类能力都有英文和中文两套目录，任务编号也区分 101 到 105 与 201 到 205。论文和 README 都指向五类能力各 80 个任务，英文与中文各 40 个。

能力分类本身也值得展开。Skill Usage 对应 Agent 是否能调用正确工具，例如 OCR、Excel、数据库、PDF、Git、Slack、Notion 等。Exploration 对应 Agent 能否寻找证据、探索网页、调用公开 API 或发现可用数据源。Long-Context Reasoning 对应长输入、长轨迹和多文档约束下的记忆与综合能力。Multimodal Understanding 对应截图、照片、音视频、图表和视觉证据。Cross-Platform Coordination 则是最接近真实工作流的一类，要求 Agent 在浏览器、桌面应用、文件系统、日历、表格、笔记或协作工具之间来回协调。

这些任务不是只看「有没有答出」。论文和 README 都强调结果布局里会保留 traces、artifacts、timelines、token ledgers 等运行证据。换句话说，UniClawBench 试图把 Agent 评测做成一次可回放的工作流审计，而不是只发布一个 pass rate。

hidden supervisor 的意义

UniClawBench 最关键的工程设计，是 hidden supervisor。论文面对的是一个现实矛盾：动态真实环境中很难使用固定答案，但如果把评测标准交给用户模拟器，用户模拟器又可能把答案或评分规则泄露给 executor。

三角色方案就是为了解这个矛盾。executor 只接触公开任务、工具和环境。hidden supervisor 可以读取 private references、eval rule 和完整可见轨迹，判断任务是否 pass、continue 或 fail。public user simulator 不直接读取隐藏答案，只接收可见轨迹与经过处理的进展信号，然后生成类似用户追问的反馈。

这个设计的本质，是把「评测知识」和「用户反馈」隔离。现实里用户可以指出 Agent 做得不对，但用户不一定拥有完整答案；评测系统则必须知道完整 rubric，但不能把 rubric 变成下一轮提示词。UniClawBench 用信息防火墙把两者分开，至少在设计上比「让一个裁判 Agent 同时评分又提示」更可审计。

论文还给了一个可靠性核查：随机抽取 50 条完成轨迹，让 3 名专家分别给 pass/fail 和连续完成度分数。作者称自动 pass/fail 与人工多数票一致率为 92.0%，checkpoint-based Average Score 与人工平均完成度的 Pearson 相关为 0.71，Spearman 相关为 0.68。这些数字说明自动监督不是无校验黑箱，但它仍然是作者实验。真正的下一步，是外部团队能否用同一批轨迹、同一套 rubric 复核出接近结果。

框架比模型更像变量

很多榜单默认把 framework 当作背景，把 model 当作主角。UniClawBench 的一个重要判断是，Agent 框架本身会强烈影响任务成功。论文在 Table 1 中让 10 个模型都跑在 OpenClaw 下，用于隔离模型能力；又在 Table 2 中让代表性模型跨 OpenClaw、EDICT、Nanobot 三个框架运行，用于观察框架设计。

论文 Figure 1 caption 直接写道，capability-level results reveal that framework choice exerts a stronger influence than model choice。这句话应该谨慎读：它不是独立事实，而是作者对自己实验结果的解释。但这个方向很符合 Agent 工程经验。长任务里，模型推理能力只是底座，真正决定成败的还有状态保存、工具调用封装、错误恢复、子任务调度、上下文压缩、文件和截图证据如何进入下一轮。

论文对三类框架的描述也很具体。OpenClaw 被写成 centralized, single-agent framework，优势在于统一轨迹中信息损失更少。EDICT 的问题被描述为多 Agent 编排里的 coordination friction：状态轮询和任务移交可能让上下文断裂。Nanobot 的特点是 token usage 更低，但在长证据链和严格产物要求中，简化的上下文管理可能不足以把 partial progress 转化为 final pass。

这对开发者的启发很直接。与其只换更强模型，不如先问框架是否保留了足够证据，是否能把失败定位到具体步骤，是否能让用户反馈进入正确上下文，是否能区分 runtime error、rate limit、budget exhaustion 和 executor incomplete。UniClawBench 的贡献不是告诉大家哪个模型第一，而是把这些框架问题变成可观测指标。

接下来看什么

第一，看外部复现。最重要的不是榜单上谁第一，而是第三方能否按 GitHub README 拉起 Docker、配置模型、跑通一批任务，并得到可解释的偏差。如果复现门槛太高，UniClawBench 会更像作者实验系统，而不是社区基准。

第二，看 hidden supervisor 的审计方式。LLM 裁判能处理动态环境，但也会带来偏差。后续如果能公开更多 rubric 格式、人工复核样本、分歧案例和失败归因，就能降低「裁判也在 hallucinate」的疑虑。

第三，看任务依赖如何维护。live web 与真实软件让任务更贴近生产，但也让基准暴露在外部环境变化中。理想做法是同时提供 live 模式、snapshot 模式和版本化任务资源，让不同研究目的可以选择真实度与可复现性的平衡点。

第四，看框架指标是否会被社区采用。Agent 框架的竞争不应只看工具数量和演示视频，而应看长任务中状态是否稳定、证据是否可回放、用户反馈是否能修复错误、跨应用操作是否能收敛。UniClawBench 如果能推动这套指标进入框架开发流程，它的价值会超过一次论文发布。

来源限制说明

本文使用的来源包括 Hugging Face Papers、arXiv PDF、GitHub 仓库和项目结果数据。它们都与 UniClawBench 直接相关，且能互相核对任务数量、能力分类、运行框架和公开数据结构。限制在于，这些来源主要来自作者发布渠道或项目自带数据，还没有看到独立实验室的复现实测。因此本文将 confidence 设为 low，而不是 medium。