What Limits Virtual Agent Application? OmniBench: A Scalable Multi-Dimensional Benchmark for Essential Virtual Agent Capabilities

Paper: arXiv:2506.08933
Code: antgroup/OmniBench
Code reference: main @ 78d75ef (2025-06-12)

1. Motivation (研究动机)

这篇论文要解决的不是“再造一个 GUI agent 排行榜”，而是指出现有虚拟代理评测在任务结构、数据构造和诊断粒度上同时不够用。作者观察到，MLLM-based virtual agents 已经能在网页导航、移动端操作和桌面任务中展示可观能力，但很多 benchmark 仍把任务当作一条固定线性指令或一个最终状态判定：只看 agent 是否到达终点，较少追踪它在中间子任务、依赖关系、并行分支、跨应用知识和长指令语义上的真实失败点。这会导致一个模型在 OSWorld、WebArena 或移动端 benchmark 上看似有进展，却无法解释它到底是不会规划、不会识别子任务、不会维持长上下文，还是缺乏某个软件域知识。

论文把现有 benchmark 的瓶颈概括为三类。第一是任务复杂度不可控且固定：许多数据集直接给出完整任务，复杂度来自人工经验或演示轨迹步数，不能系统地产生 easy / medium / hard 层级，也很难随着 agent 能力提升而扩展。第二是人工标注成本高且场景覆盖有限：演示轨迹、评测函数和任务说明往往需要人工写，数据规模难放大，场景也容易被少数标注者先验限制。第三是缺少多维度评估：任务成功率只给出最终结果，无法评估中间过程；trajectory matching 又过度约束 agent 必须模仿某条人工路径，忽略真实任务中可能存在的多条合理执行顺序。

OmniBench 的目标是把“虚拟代理任务”形式化为 graph-structured tasks，再通过可控 DAG 组合生成任务，而不是从头到尾人工写任务。这样做有两个直接价值：其一，任务难度可以由图的拓扑和资源依赖显式控制；其二，评测可以从节点级 evaluation functions 出发，既评价完成了多少关键子任务，也评价执行顺序是否符合人类更自然的操作逻辑。论文最终给出 36,076 个任务实例、20 个交互场景、49 个应用、255 个子任务，声称任务规模约为多数 environment-based benchmark 的 40 倍，并通过 3 名训练过的标注者在采样任务上得到约 90.7% / 91% 的 human acceptance。

Figure 1 解读：主图把论文的贡献压缩成三层：底层是可跨 Desktop / Mobile / Web 的环境与应用集合；中间是以资源输入输出为约束的 graph-structured task synthesis；上层是 OmniEval 的 10 个能力维度。这里最关键的是“任务复杂度”不再是单一的步数，而是由依赖、指令、层级、分支和知识五个维度共同决定，因此同一套任务生成机制可以构造平行规划、长程规划、依赖识别、跨域知识等不同测试切片。

从研究价值看，OmniBench 更像一个“诊断仪”而不是单纯排行榜。论文主结论之一是，即使 GPT-4o 在总分上领先，它在 graph-structured tasks 上仍远低于人类：在作者控制变量的 chain-vs-graph 对比中，GPT-4o graph task accuracy 只有 20.5%，而人类是 80.1%。另一个重要结论是当前 agent 的短板集中在 Subtask Identification 和 Long Instruction Following：GPT-4o 在 SI / LIF 上分别只有 30.6 / 32.2，Omni-UGround 也只有 21.9 / 31.7，而人类基线是 69.1 / 66.1。这说明 agent 应用的限制并不只是视觉 grounding 或单步动作 API，而是复杂指令拆解、依赖建模和长流程一致性。

2. Idea (核心思想)

核心洞见：虚拟代理任务天然是一个由子任务和资源依赖组成的 DAG，而不是一条唯一的演示轨迹；只要把任务构造和评测都建立在这个 DAG 上，就能同时获得可控复杂度、自动扩展和过程级诊断。OmniBench 不是让模型看更多 GUI screenshot 后做粗粒度成功/失败判断，而是先用环境资源定义 subtask dependency，再从子任务池 bottom-up 组合出整体任务，最后用图上的 evaluation states 和 graph metrics 来评价 agent 的执行。

这一思想与 WebArena / OSWorld / VisualWebArena 等环境 benchmark 的根本差别在于：后者主要提供真实交互环境和最终状态检查，任务本身仍然依赖人工设计；AitW / Mind2Web / GUI Odyssey 等 trajectory-based 数据集则把“人类演示”当作强监督信号，但容易把其他可行路径误判为错误。OmniBench 试图把 benchmark 的“任务生成、任务难度、评测函数、能力切片”全部参数化：任务由子任务图生成，难度由图指标约束，评测函数由 subtask-level API 组合而来，能力维度由不同复杂度组合定义。

Figure 2 解读：pipeline 展示 bottom-up 生成路径：先在可探索环境中发现 subtask，再迭代合成轨迹和 evaluation function，然后按资源依赖进行 task composition，最后用 consistency validator 检查总结出的高层 task instruction 是否保留原图的非线性依赖。这个流程的重点不是让 LLM 一次性写出复杂任务，而是把“简单可验证子任务”作为可复用积木。

具体创新可以拆成三层。第一层是 OmniBench 的任务表示：每个子任务有 input resources 和 output resources，若某个子任务的输出资源满足另一个子任务的输入资源，就形成有向边。第二层是可控合成：作者定义五个复杂度维度，并通过约束 DAG composition 来构造不同难度和能力类型的任务。第三层是 OmniEval：把每个节点设置为 Waiting / Evaluating / Completed，并在 agent 每一步动作后运行对应 evaluation function；最终指标不只看成功，还要看 Coverage Rate 和 Logical Consistency。直觉上，这能避免“最终状态失败但过程已完成大量关键节点”和“没有按人工演示走但逻辑合理”的两类误判。

Figure 3 解读：这张图对比三种评测范式。result-based 只看最终状态，会把两个失败轨迹都当成失败，即使其中一个已经完成更多子任务；trajectory-based 要求动作序列贴近人类演示，会把另一条同样能完成任务的拓扑顺序误判为错误；graph-based evaluation 则以子任务节点和可行拓扑为依据，更适合多路径、多应用、多分支的虚拟代理任务。

3. Method (方法)

3.1 Task graph 与五维复杂度

OmniBench 把整体任务定义成图 $G = {S, R}$ 。其中 $S = {s_{1}, s_{2}, \dots, s_{n}}$ 是子任务集合， $R = {(s_{a}, s_{b})}$ 表示依赖关系：当 $s_{a}$ 的 output resources 能满足 $s_{b}$ 的 input resources 时， $s_{b}$ 依赖 $s_{a}$ 。这个定义让任务不必被压扁成一句线性 instruction；同一个 high-level intent 可以对应多个并行分支和多个合法拓扑排序。

五个复杂度维度如下。Dependency Complexity 由边数衡量，Easy / Medium / Hard 分别为 $\leq 1$ 、 $2 \sim 3$ 、 $\geq 4$ ；Instruction Complexity 由节点数衡量，阈值为 $\leq 2$ 、 $3 \sim 4$ 、 $\geq 5$ ；Knowledge Complexity 由涉及的 application categories 数衡量，阈值为 $\leq 1$ 、 $2 \sim 3$ 、 $\geq 4$ ；Hierarchy Complexity 由图深度衡量，阈值为 $\leq 2$ 、 $3 \sim 4$ 、 $\geq 5$ ；Branch Complexity 由图宽度衡量，阈值同样为 $\leq 2$ 、 $3 \sim 4$ 、 $\geq 5$ 。相比“人类演示步数”，这些指标更接近任务结构本身，也能支持构造特定能力测试集。

Complexity	Calculation	Easy	Medium	Hard
Dependency	# edges	$\leq 1$	$2 \sim 3$	$\geq 4$
Instruction	# nodes	$\leq 2$	$3 \sim 4$	$\geq 5$
Knowledge	# app categories	$\leq 1$	$2 \sim 3$	$\geq 4$
Hierarchy	depth	$\leq 2$	$3 \sim 4$	$\geq 5$
Branch	width	$\leq 2$	$3 \sim 4$	$\geq 5$

3.2 自动合成：Subtask Discovery → Iterative Synthesis → Composition → Validation

Subtask Discovery

Subtask Discovery 阶段构造一个含 49 个异构应用的动态环境，应用分为社交通信、多媒体播放、多媒体编辑、Office、工具、编程、系统管理、浏览器、截图、任务管理、笔记管理、生活方式等 12 类。MLLM 在这些应用中探索，并结合 API 文档、用户手册、示例子任务和预定义资源列表提出可执行子任务。每个子任务都需要显式声明 input resources 和 output resources，这一步是后续 DAG 依赖的基础。

Iterative Synthesis

Iterative Synthesis 阶段分成轨迹合成和评测函数合成。轨迹合成用 advanced MLLMs 执行相对简单的子任务并记录 execution traces；评测函数合成则先人工设计 11 个 system-level APIs，例如读取鼠标位置下文本、检查剪贴板、检查文件目录、检查键盘输入等，再让 Code LLM 组合这些 API 生成 evaluate_agent_task_completion。作者提出 cross-verification：评价函数给出失败反馈，轨迹合成器根据环境状态反馈迭代修正；通过验证的函数还会被拿去评估来自其他任务的三条额外轨迹，以避免只会过拟合某条样本。

Figure 4 解读：图中展示 Code LLM 如何把基础系统 API 组合成子任务评测函数。它不是用自然语言问 judge “做完了吗”，而是调用环境可观测 API 检查关键动作和状态，例如是否点击特定按钮、是否输入路径、文件是否存在。这样能把子任务完成度分解为多步可解释反馈。

Task Composition

Task Composition 阶段不是随机把子任务连边，而是先从经过 cross-verification 的子任务池中抽取 coherent task intent，例如“为 Emily 创建个人介绍 PowerPoint”。task intent 起到锚点作用，把服务同一高层目标的子任务聚在一起，再根据资源输入输出建立依赖边。论文特别强调，如果只根据 shared resources bottom-up 组合，很容易产生“打开外卖 app 然后马上关闭”这类没有统一目标的任务；intent extraction 是为了避免图结构正确但语义荒谬。

Figure 5 解读：资源图把每个资源分为 category 和 concrete parameter，例如 img_path 是资源类别，/usr/example.png 是实际参数。一个子任务的输出资源如果满足另一个子任务的输入资源，就形成依赖。这种表示把 GUI 操作里的隐式前置条件显式化，因此能支持自动生成 DAG。

Task Validation

Task Validation 阶段用 GPT-4o 把子任务说明和图结构总结成高层 task instruction，但直接总结可能把并行/层级结构误写成线性步骤。为此，consistency validator 再让 GPT-4o 只根据生成的 task instruction 推断子任务依赖；如果推断图与原始 DAG 不一致，就要求重新总结。这个验证器解决的是“自然语言 instruction 是否忠实表达图结构”的问题，而不是简单语法校对。

Figure 6 解读：case 图展示同一 high-level instruction 下多个子任务如何共享资源并形成非线性结构。对 agent 来说，关键不是逐字执行 instruction，而是识别哪些子任务可以并行、哪些必须等待前置资源生成；这正是 OmniBench 要评估的能力。

Quality control ablation

质量控制包含 cross-verification、intent extraction 和 consistency validator 三个模块。论文对 400 个 sampled task graphs 进行 ablation，并让 3 名训练过的 annotators 计算平均 human acceptance：三个模块都去掉时只有 41.2%；去掉 cross-verification 但保留 intent + validator 为 61.2%；去掉 intent extraction 为 82.7%；去掉 consistency validator 为 86.5%；三者都启用为 90.7%。这说明最大贡献来自 cross-verification，但 intent 和 validator 也分别解决 coherent goal 和 instruction-graph alignment。

3.3 OmniEval：节点状态、CR 与 LC

OmniEval 的 evaluator 在任务图上维护三种状态：Waiting、Evaluating、Completed。初始化时，入度为 0 的节点进入 Evaluating，其余节点 Waiting；agent 每执行一步动作后，evaluator 对所有 Evaluating 节点运行对应 evaluation function；若某节点完成，则将其标记为 Completed，并把所有前置节点已完成的后继节点推进到 Evaluating。如果 agent 在最大步数 $N$ 内没有完成新子任务，或主动 FINISH 但图未完成，则任务失败，但仍保留过程分数。

Coverage Rate (CR) 用深度加权衡量 agent 在图上的完成进度。论文公式为： $w (s_{i}) = \frac{d ( s _{i} )}{\sum _{j = 1}^{n} d ( s _{j} )}$ $CR = \frac{\sum _{i = 1}^{n} w ( s _{i} ) \cdot I ( s _{i} )}{\sum _{i = 1}^{n} w ( s _{i} )}$ 其中 $d (s_{i})$ 是子任务深度， $I (s_{i}) = 1$ 表示子任务完成。深层节点权重大，是因为它们通常依赖更多前置步骤，完成它们说明 agent 已通过更长链条。

Logical Consistency (LC) 衡量 agent 操作顺序与人类逻辑的相似性。论文直觉是：人类在多应用任务中通常倾向于在一个应用内完成尽可能多的相关子任务，再切换应用。LC 定义为： $L C = \frac{C S _{a g e n t}}{C S _{ma x}}$ 其中 $CS$ 根据执行序列中相邻子任务是否属于同一应用累加， $C S_{ma x}$ 是所有合法拓扑排序中的最大 coherence score。这个指标承认多条拓扑排序都可能正确，同时鼓励更少无意义应用切换的执行逻辑。

Figure 7 解读：作者随机采样 50 条来自不同模型的轨迹，由两名训练过的标注者按 0% 到 100% 给出任务完成度和逻辑一致性分数，再与 OmniEval 的 CR / LC 做 Pearson correlation。图中趋势用于支持 OmniEval 与人类判断有较强相关性，但样本量只有 50 条，因此更适合作为 sanity check，而不是充分证明自动评价完全替代人工。

3.4 Released code 对应关系与差异

官方 GitHub 仓库已发布探索与评测脚本，但截至 main@78d75ef，README 的 TODO 仍列出 OmniBench virtual environment、10 capabilities test tasks、automated data collection pipeline、OmniBench-36K training data、training scripts 等尚待发布。因此，本笔记中的数据合成流程主要依据论文和 arXiv LaTeX source；released code 可直接核对的是 agent/environment/evaluator 的 skeleton。

Code reference: main @ 78d75ef (2025-06-12) — pseudocode and mapping based on this commit

def released_evaluation_loop(configs):
    subtask_list = json.load(open(configs["SUBTASKS_JSON"]))
    task_dags = load_tasks_from_json(
        task_dag_dir=configs["TASK_PATH"],
        subtask_eval_func_dir=configs["SUBTASKS_EVALUATION_PATH"],
        subtask_list=subtask_list,
    )
    results = {}
    for task_dag in task_dags:
        env = DesktopEnv(
            path_to_vm=configs["VM_PATH"],
            observation_space=["Screen_A11Y"],
            action_space="pyautogui",
            snapshot_name="init_state",
            headless=True,
            uuid=task_dag.task_id,
            related_app=task_dag.task_data.get("related_app", "File Explorer"),
        )
        agent = Agent(uuid=str(uuid.uuid4()), related_app=task_dag.task_data.get("related_app", "File Explorer"), env=env)
        agent.set_task_info(task_instruction=task_dag.task_data["task_instruction"], task_id=task_dag.task_id)
        evaluator = Evaluator(task_dag=task_dag, configs=configs, env=env)
        while True:
            observation = env.get_observation()
            action, status = agent.get_inference_action(observation)
            env.execute_action(action)
            result = evaluator.run_step_evaluation(status)
            if result["outcome"] != "running" or status == "FINISH":
                break
        results[task_dag.task_id] = {"outcome": result["outcome"], "score": result["score"], "steps_taken": evaluator.step_count}
    return results

class ReleasedGraphEvaluator:
    def __init__(self, task_dag, max_steps=200, wait_limit=20):
        self.task_dag = task_dag
        self.step_count = 0
        self.wait_step = 0
        self.max_steps = max_steps
        self.wait_limit = wait_limit
 
    def run_step_evaluation(self, status):
        self.step_count += 1
        self.wait_step += 1
        if self.step_count > self.max_steps:
            return {"outcome": "Fail (exceeded max steps)", "score": self.get_task_score()}
        if self.wait_step > self.wait_limit:
            return {"outcome": "Fail (waited too long)", "score": self.get_task_score()}
        for sid, subtask in self.task_dag.subtask_dict.items():
            if subtask["status"] == "Evaluating":
                success, reason = self.run_eval_function(subtask)
                if success:
                    self.task_dag.update_node_status(sid)
                    self.wait_step = 0
        if status == "FINISH":
            outcome = "Success" if self.task_dag.all_subtasks_completed() else "Fail (Agent finished before completing all subtasks)"
            return {"outcome": outcome, "score": self.get_task_score()}
        return {"outcome": "running", "score": ""}
 
    def get_task_score(self):
        return {
            "completion": self.task_dag.get_completed_levels() / self.task_dag.depth,
            "coherence": self.longest_same_app_run_ratio(self.task_dag.successful_topo),
        }

论文公式与 released code 实现差异：论文 CR 是按每个 completed subtask 的 depth weight 加权求和；released evaluator/evaluator.py 的 __get_completion_score 返回 completed_levels / self.task_dag.depth，是层级完成比例，不是逐节点加权 CR。论文 LC 描述为相邻子任务同应用带来的 coherence score 与所有合法拓扑最大值之比；released __get_coherence_score 通过 get_all_topo() 枚举拓扑序，再比较执行序列和最优拓扑序的 longest same-application run，属于更简化的实现。论文方法解读应以论文公式为准；复现实验若使用当前仓库，需要把这两个差异视为版本锚定下的 released-code behavior。

Paper Concept	Source File	Key Class/Function	说明
Task DAG 表示	`evaluator/TaskDAG.py`	`TaskDAG.__load_data`, `__initialize_task_graph`, `update_node_status`	从 task JSON 读取 nodes / edges，入度为 0 的节点初始化为 `Evaluating`，完成节点后推进后继
Graph evaluator	`evaluator/evaluator.py`	`Evaluator.run_step_evaluation`, `__run_evaluation_function`	每步执行子任务 evaluation function，并处理 max step / wait limit / FINISH
Released metrics	`evaluator/evaluator.py`	`__get_completion_score`, `__get_coherence_score`	与论文 CR / LC 公式存在上述差异
评测入口	`evaluation.py`	`load_tasks_from_json`, `main`	创建 DesktopEnv、Agent、Evaluator 并循环执行动作
探索脚本	`exploration.py`	`main`	随机选择 Cursor、ShareX、Zotero、Evernote、Windows PowerShell ISE 等应用进行轨迹采集
环境封装	`envs/desktop_env.py`	`DesktopEnv.get_observation`, `execute_action`	Windows VM、Screen_A11Y observation、pyautogui action
Agent 调用	`agents/agent.py`	`get_llm_response`, `Agent.get_action`, `get_inference_action`	OpenAI-compatible chat completions；默认示例配置含 Qwen-VL-Max
运行配置	`config/config_dev.yaml`	`MAX_STEP=200`, `CONTROL_BACKEND=uia`	评测最大步数和 UIA 控制后端来自实际 config，不是 README 文字默认

4. Experimental Setup (实验设置)

数据规模方面，OmniBench 包含 36,076 个任务实例，其中 network-dependent real-world tasks 为 16,614 个（46.05%），network-independent local tasks 为 19,462 个（53.95%）。每个任务平均使用 2.21 个应用；high-level instruction 平均 51.7 words，low-level instruction 平均 237.9 words；总共覆盖 20 个 task scenarios 和 255 个 subtasks。环境覆盖 Desktop / Mobile / Web；附录以 desktop 为例，使用 Windows 11 guest OS + VMware Workstation 17 Pro 17.5.1，并从 snapshot 初始化以保证 episode 初始状态一致。

Figure 8 解读：统计图展示任务复杂度分布以及任务实例的基本组成。与只报告 instance count 的 benchmark 不同，OmniBench 同时报告网络依赖、本地任务、平均应用数、instruction 长度和 subtask 数量，这些统计帮助判断它到底在测试短单步 GUI、长链路任务，还是跨应用组合。

Figure 9 解读：20 个 task scenarios 来自应用类别组合，而不是只来自单一网页或单一手机 app。这个设计使 benchmark 能覆盖 image editing、video editing、office、web browsing、file operations 等跨域任务，也使 Knowledge Complexity 和 Cross-Domain Decision-Making 有了实际环境基础。

评测模型分为四类。Closed-source MLLMs 包括 GPT-4o、Qwen-VL-Max、Claude-3.5-Sonnet、Gemini-2.0-Flash；Open-source MLLMs 包括 Qwen2-VL-7B-Instruct、InternVL2-8B、InternVL2.5-8B；Virtual Agents 包括 Aguvis、OS-Atlas、ShowUI、UGround 等；Supervised Fine-Tuning Agents 选用 OS-Atlas-Base-4B 和 UGround-V1-7B 作为 backbone，并用 OmniBench 合成数据训练出 Omni-OS-Atlas-Base-4B 与 Omni-UGround-V1-7B。评测输入预处理上，论文按 Aguvis / UGround 等工作把截图缩放到 $1024 \times 1024$ ，尽量保持 aspect ratio 并 padding，平衡 GUI 细节和计算成本。

10 个能力维度由五个复杂度维度组合得到：Parallel Planning、Long-Range Planning、Cross-Domain Decision-Making、Sequential Decision-Making、Subtask Identification、Dependency Identification、Long-Sequence Reasoning、Long Instruction Following、Domain-Specific Knowledge、Cross-Domain Knowledge。例子：Long-Range Planning 需要 hard dependency + hard hierarchy；Subtask Identification 更强调 instruction complexity 和一定 dependency；Cross-Domain Knowledge 需要 hard instruction + hard knowledge。主表对每个能力用 CR 度量，同时报告 overall CR 和 LC。

Figure 10 解读：这张图聚焦 SI 与 LIF 两个瓶颈。它说明总分较高的模型并不一定会正确拆解子任务或长指令；例如 GPT-4o 在总体 CR 上最高，但 SI / LIF 仍远低于人类。这对虚拟代理应用很关键，因为真实用户请求往往是“长 instruction + 多个隐含资源依赖”。

与现有 benchmark 的比较中，OmniBench 相对 AitW、Mind2Web、MoTIF、OmniACT、GUI Odyssey、WebArena、VisualWebArena、OSWorld、Spider2-V 和 CRAB 的主要差异是：它同时支持 interactive + real-world、多平台、36,076 实例、5 个 complexity dimensions、dynamic scale、intent、20 scenarios、demonstration trajectory、automatic composition + human verification、high & low instruction levels、10 capability dimensions、subtask-level evaluation、255 evaluation functions 和 graph-based strategy。这个表体现论文的定位：不是某个环境的新任务集，而是一个可扩展 benchmark construction framework。

5. Experimental Results (实验结果)

主结果显示 human 仍显著领先：Human 的 overall CR / LC 为 80.1 / 92.8。Closed-source MLLMs 中 GPT-4o 最强，overall CR / LC 为 38.7 / 49.0；Claude-3.5-Sonnet 为 27.6 / 35.0；Gemini-2.0-Flash 为 25.9 / 38.0；Qwen-VL-Max 为 18.4 / 23.3。Open-source MLLMs 的 CR 更低：Qwen2-VL-7B 为 14.8，InternVL2-8B 为 14.2，InternVL2.5-8B 为 17.4。专门的 visual digital agents 介于中间：Aguvis-7B 为 22.9，OS-Atlas-Pro-4B 为 19.1，ShowUI-2B* 为 23.2，OS-Atlas-Base-4B* 为 22.2，UGround-V1-7B* 为 25.0。使用 OmniBench 合成数据 SFT 后，Omni-OS-Atlas-Base-4B 达到 29.7 / 30.1，Omni-UGround-V1-7B 达到 34.4 / 37.4，接近但仍低于 GPT-4o。

Model / Group	Overall CR	Overall LC	关键观察
Human	80.1	92.8	远高于所有 agent，说明 benchmark 尚未饱和
GPT-4o	38.7	49.0	closed-source 最强，但 graph task 和长指令仍弱
Claude-3.5-Sonnet	27.6	35.0	多数能力低于 GPT-4o
Omni-UGround-V1-7B	34.4	37.4	SFT agent 中最好，CDDK / SDK / LSR 提升明显
Omni-OS-Atlas-Base-4B	29.7	30.1	通过合成数据提升，但 LC 仍有限
Qwen2-VL / InternVL family	14.2–17.4	9.0–18.8	通用 MLLM 直接做 GUI agent 明显不足

能力边界分析进一步指出，当前 agent 对图结构任务特别不适应。作者构造相同节点数、边数、知识域和知识复杂度的 chain-structured 与 graph-structured tasks，以控制其他因素；在 graph tasks 上，即使 GPT-4o 也只有 20.5% accuracy，而人类为 80.1%。解释是许多 agent 训练在 chain-structured data 上，会把非线性图结构误解为线性流程，从而识别错子任务依赖。复杂度分层实验也显示，随着 Easy → Medium → Hard，所有模型平均下降 6.19 points，且五个复杂度维度上均有类似趋势。

Figure 11 解读：chain vs graph 对比是论文最有诊断价值的实验之一，因为它控制了节点和边数量，却改变了结构形态。如果模型在 chain 上可行、在 graph 上崩溃，说明问题不是单纯步数变多，而是模型没有稳定建模 partial order、并行分支和资源依赖。

合成图结构数据对训练有正向但有限的迁移。按 OS-Atlas 的训练设置微调后，Omni-OS-Atlas-4B 在 AndroidControl Low / High 的 SR 从 80.64 / 67.54 变为 81.38 / 67.71，平均提升约 0.46；Omni-UGround-7B-V1 从 83.29 / 70.31 变为 83.57 / 70.83，平均提升约 0.4。在 OmniAct-Web / Desktop 上，Omni-OS-Atlas-4B 从 73.91 / 84.78 到 74.62 / 85.53，平均提升约 0.73；Omni-UGround-7B-V1 从 79.85 / 91.89 到 80.24 / 92.10，平均提升约 0.30。提升幅度不算大，但方向一致，说明合成多步导航数据对 action type decision 和规划有帮助。

指令顺序敏感性实验说明，普通 MLLM 虽然对同义不同序 instruction 不太敏感，但总体性能差；导航 fine-tuning 提升性能时会牺牲鲁棒性。InternVL2-4B sensitivity 为 2.97，OS-Atlas-Pro 升到 9.07；加入 OmniBench 图结构样本后的 Omni-OS-Atlas 降到 3.49。Qwen2-VL-7B 为 2.58，Aguvis 升到 12.9，Omni-Aguvis 降到 2.67。论文报告 fine-tuning agent 的 sensitivity 平均增加 8.21 points，而加入 OmniBench 后平均减少 7.91 points，说明结构化样本帮助模型识别语义依赖，而不是死记 instruction 表面顺序。

Task intent 的作用也很明确。Open-source tuning 中，OS-Atlas-Base-4B 的 planning overall 从 28.6 提升到 30.3（+1.7），UGround-V1-7B 从 32.3 到 33.5（+1.2）。Closed-source prompt 中，Qwen-VL-Max 从 21.4 到 24.0（+2.6），Gemini-2.0-Flash 从 22.9 到 27.8（+4.9），Claude-3.5-Sonnet 从 24.0 到 29.4（+5.4），GPT-4o 从 25.4 到 34.3（+8.9）。这说明把 high-level intent 显式给模型能显著改善规划，尤其对强 closed-source 模型是 plug-and-play 的 prompt 增益。

Figure 12 解读：failure analysis 把每个模型随机 100 个错误样本交给专家标注。五类错误分别是 Instruction Understanding 23%、Lack of Knowledge 21%、Environmental Error 3%、Grounding Error 17%、Hallucinatory Success 36%。占比最高的 Hallucinatory Success 表明很多 agent 会过早认为任务完成，这与长流程上下文记忆和过程自检不足有关；Environmental Error 只有 3%，说明主要瓶颈仍在模型能力而不是环境噪声。

论文的限制也应明确记录。第一，官方仓库目前只发布了探索/评测代码骨架，数据、训练脚本和完整自动合成流水线在 README 与项目页中仍有 coming soon / TODO，因此复现 36K 数据构造需要等待后续 release 或自行实现。第二，OmniEval 的可信度依赖自动合成 evaluation functions 和环境 API；虽然作者用人类相关性与 acceptance 做了验证，但 50 条轨迹相关性和 400 个 task graph ablation 仍是有限采样。第三，released code 中 CR / LC 与论文公式存在差异，后续若仓库更新，需要重新锚定 commit 并核对 evaluator 行为。第四，benchmark 强调 Windows desktop、mobile、web 多平台，但附录细节和 release code 更偏 desktop/VMware，跨平台可复现性仍需要完整环境发布来确认。

Paper Notes

探索

What Limits Virtual Agent Application? OmniBench: A Scalable Multi-Dimensional Benchmark for Essential Virtual Agent Capabilities

What Limits Virtual Agent Application? OmniBench: A Scalable Multi-Dimensional Benchmark for Essential Virtual Agent Capabilities

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Task graph 与五维复杂度

3.2 自动合成：Subtask Discovery → Iterative Synthesis → Composition → Validation

Subtask Discovery

Iterative Synthesis

Task Composition

Task Validation

Quality control ablation

3.3 OmniEval：节点状态、CR 与 LC

3.4 Released code 对应关系与差异

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

目录