DMI论文学习：为什么LLM Agent不该直接操作GUI

对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Rethinking OS Interfaces for LLM Agents 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_9.pdf
• 包含 DMI（Declarative Model Interface）、GUI Agent 执行模型、面向LLM的OS接口设计、computer-use 任务优化 相关的基础认知与实践思考。
• 它的出发点很直接：让 LLM 负责高层语义决策，让系统负责低层 GUI 导航与交互
• 理解不足小伙伴帮忙指正 :),生活加油

对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文最重要的观点是：

对 computer-use agent(桌面智能体) 而言，问题不只是“模型看图够不够强”，而是 GUI 这种为人类设计的命令入口，本身就在给 LLM 制造额外负担。

人类使用 GUI 时，擅长做两件事：

• 识别视觉布局
• 通过多次细粒度交互慢慢到达目标控件

但 LLM 并不擅长这两件事。它更擅长的是：

• 根据任务语义直接判断“应该用哪个功能”
• 输出结构化、声明式的目标

所以论文提出，不要逼模型去一步步点菜单、拖滑条、滚界面，而应该给它一个更接近“声明目标”的 OS 接口。

名词解释

• DMI：Declarative Model Interface，面向模型的声明式系统接口
• GUI Agent：通过截图、点击、滚动和控件操作来完成任务的智能体
• policy：高层决策，决定“做什么”
• mechanism：低层执行细节，决定“怎么做到”
• UI Automation：操作系统提供的界面可访问性和自动化接口
• access：DMI 中“访问某个控件”的声明式原语
• state：DMI 中“把控件设置成某种状态”的声明式原语
• observation：DMI 中“读取结构化结果”的声明式原语
• UI Navigation Graph：把界面控件和可达关系组织成图结构后的导航表示
• grounding：把语言目标准确映射到界面中的具体控件或对象
• computer-use agent：把桌面或应用界面当执行环境来完成任务的智能体
• OSWorld-W：用于评估 computer-use / GUI agent 的任务基准

先搞懂：现在的GUI Agent到底在做什么

现在我们做 computer-use agent（桌面智能体），主流的玩法几乎都是复刻人类用电脑的方式，整个执行流程是这样的：

1. 截一张当前屏幕的图，传给多模态大模型
2. 模型识别界面元素，定位要操作的按钮/输入框
3. 输出坐标，驱动鼠标执行点击、滚动、拖拽、输入等操作
4. 再截图，再识别，再操作，循环往复直到任务完成

这套逻辑完全是照着人类的行为复刻的，就像我们之前聊内存管理时说的「单级页表」，逻辑上通顺，但天然有无法规避的瓶颈。

论文里把GUI的使用，拆成了两个完全独立的部分：

• policy（决策层）：决定要调用什么功能、按什么顺序完成任务，是任务的核心目标，回答「做什么」的问题
• mechanism（执行层）：怎么找到目标控件、展开哪层菜单、滚到哪个位置、点哪个坐标，是实现目标的细节，回答「怎么做到」的问题

传统的GUI设计，把这两个部分死死地绑在了一起——你要完成一个功能，必须自己走完所有的操作路径，没有任何捷径。这就导致LLM一边要做高层的任务规划，一边还要处理底层的像素级操作细节，两头分心，最终带来了三个致命问题：

1. 操作链路太长，LLM调用次数指数级上升，耗时和token成本都下不来
2. 视觉识别和坐标交互天生脆弱，窗口位置变一下、界面布局改一点，就会出现点错、漏点的问题
3. 执行层任意一步的小失误，都会被放大成整个任务的失败，容错率极低

那有没有办法把这两个部分拆开？让LLM只负责它擅长的决策，把不擅长的执行细节交还给系统？这就是论文提出的 DMI 要解决的核心问题。

DMI到底是什么？核心思想拆解

DMI 全称 Declarative Model Interface，翻译过来就是「面向模型的声明式系统接口」，它的核心逻辑特别直白：让LLM只负责高层的语义决策，把底层的GUI导航和交互细节，交还给操作系统本身来做。

这里怎么理解「声明式」和传统「过程式」的区别？给小伙伴们举个生活化的例子：

• 传统GUI Agent的过程式操作：就像你去政务大厅办社保转移，要自己先找咨询台问流程，再跑社保窗口开证明，再跑医保窗口盖章，再跑银行办关联，每一步都要自己找位置、填单子、排队，少一步都办不成
• DMI的声明式操作：就像你直接在政务APP上提交「我要办理社保从A市转移到B市」的申请，剩下的所有窗口流转、材料提交、盖章审核，全由系统自动完成，你只需要说清楚最终目标，不用管中间的任何流程

对应到系统接口上，DMI不再让模型去生成 click、drag、scroll 这类底层的过程式命令，而是只给模型提供三类极简的声明式原语：

原语	作用	核心逻辑
access	访问目标控件	模型只需要说「我要找哪个功能」，不用管它在哪个菜单、哪个选项卡
state	设置控件目标状态	模型只需要说「我要把这个功能设置成什么样」，不用管中间要点击多少次、拖拽多少距离
observation	读取结构化结果	模型只需要说「我要读取什么内容」，系统直接返回结构化文本，不用再做截图OCR和视觉识别

给小伙伴们看一个最直观的对比，我们要给PPT所有页面设置统一的蓝色纯色背景：

传统GUI Agent的过程式操作

Text

1. 移动鼠标到顶部菜单栏，点击「Design」选项卡
2. 移动鼠标到右侧面板，点击「Format Background」按钮
3. 在填充选项中，点击「Solid Fill」单选框
4. 点击颜色选择器，选中蓝色色块
5. 移动鼠标到面板底部，点击「Apply to All」按钮

DMI的声明式操作

Text

access 「幻灯片背景填充」控件
state 填充类型=纯色，颜色=蓝色，应用范围=全部页面

你看，原本需要5步、多次LLM调用才能完成的操作，在DMI里只需要一次声明就能完成。这就是DMI最核心的价值：把「逼模型手工走完整个GUI路径」的难题，变成了「模型声明意图，系统负责执行细节」的分工，让专业的模块做专业的事。

为什么说GUI对LLM天生不友好？

论文里给了两个非常扎心的观察，直接戳中了现在GUI Agent行业的痛点，也解释了为什么我们要重新设计面向LLM的系统接口。

1. GUI是过程式访问，而LLM天生适合声明式访问

GUI的设计逻辑，是把功能藏在层层嵌套的菜单、选项卡、对话框、折叠面板里。人类用的时候，顺着层级一步步找，慢慢缩小决策范围，非常顺手；但对LLM来说，它已经明确知道自己要找「字体颜色」「背景填充」，还要逼它一步步走完所有导航路径，完全是多余的内耗。

就像我们之前聊内存寻址时说的，四级页表要4次内存访问才能拿到物理地址，TLB缓存就是为了减少这种无效的访存开销。而DMI做的，就是给LLM的GUI操作加了一层「TLB缓存」，让它直接拿到目标，不用再走完整的寻址路径。

2. GUI交互依赖高频的observe-act循环，对LLM来说成本极高

很多GUI操作，本质上是不断的试探和微调：滚动到合适的位置、框选一段文本、拖动滑条到对应数值、把窗口拖到差不多的位置。

人类做这些操作，一秒钟可以完成好几次，几乎没有成本；但LLM完成一轮「观察-决策-执行」的循环，往往要几十秒，还要消耗大量的token。原本对人类来说「便宜到可以忽略」的交互，对模型来说，成本会被无限放大。

这就像我们之前聊的缺页异常，minor fault 是内存级的轻量操作，而 major fault 是涉及磁盘IO的重型操作。对人类来说，点击、滚动是 minor fault 级别的开销，而对LLM来说，每一次循环都是 major fault 级别的开销。

DMI是怎么落地实现的？

论文的实现基于Windows自带的 UI Automation 系统接口，把原本零散的GUI控件和交互模式，抽象成了可声明的标准化接口。整个系统设计，有三个最核心的关键点，我们一个个来看。

1. 路径唯一化导航：让模型只说「去哪」，不用管「怎么去」

一个应用里的控件访问关系，本质上是一张图，而不是一条直线——里面可能有环路、有合并节点、有同名控件在不同路径下语义完全不同的情况。比如Word里的「字体颜色」按钮，在「开始」选项卡和右键菜单里都有，对应的是同一个功能，但访问路径完全不同。

论文通过构建 UI Navigation Graph（UI导航图），再做路径消歧和唯一性处理，让系统能根据控件的唯一标识符，自动确定稳定的访问路径。这一步直接把「导航找路」的工作，从模型手里接了过来，模型只需要声明要访问的控件，不用管它在界面的哪个位置、要怎么点进去。

2. 把复杂交互，包装成有限的状态操作

别看GUI界面千变万化，从操作系统的底层接口来看，控件的类型和交互模式，其实是一个非常有限的集合。不管是按钮、输入框、滑条、下拉框、单选框，本质上都是「状态可读写的对象」。

论文把原本需要多步细粒度操作的动作，封装成了稳定的声明式指令。比如：

• 「把滚动条拉到50%的位置」，不用再模拟鼠标拖拽多少次，直接用 state 声明目标值
• 「选中文档第2到第5行文本」，不用再模拟鼠标按下、拖动、松开，直接用 state 声明选中范围
• 「读取这个文本框的全部内容」，不用再截图OCR，直接用 observation 读取结构化文本

这样一来，模型就不用再做像素级推理和精确坐标控制，彻底绕开了它最不擅长的部分。

3. 用结构化的Observation，代替截图理解

传统的GUI Agent，几乎都要依赖截图OCR、多模态视觉识别，来判断操作结果对不对。这不仅额外增加了成本，还很容易出现视觉误识别、解析误差，为了「看懂结果」还要多跑好几轮循环。

而DMI直接通过系统接口，返回结构化的观测结果，比如控件的当前状态、文本内容、是否可点击、是否可选中等，完全绕开了视觉识别的环节，从根上减少了误差和LLM调用回合数。

这就像我们之前聊内存管理时，直接从TLB里拿缓存的映射关系，比一次次遍历页表要快得多、稳得多。

论文的实验结果，到底有多能打？

论文先是在Microsoft Word/Excel/PowerPoint场景做了大量案例验证，又在业内通用的 OSWorld-W 基准测试集上，和当时主流的GUI-based baseline UFO2 做了横向对比，核心结果非常亮眼，我们直接看数据：

Text

┌──[root@liruilongs.github.io]-[~]
└─$ 任务成功率对比
GUI-based UFO2: 44.4%
DMI方案: 74.1%
# 绝对提升29.6个百分点，相对提升接近70%
┌──[root@liruilongs.github.io]-[~]
└─$ 平均完成步骤数对比
GUI-based UFO2: 8.16步
DMI方案: 4.61步
# 步骤数减少43.5%
┌──[root@liruilongs.github.io]-[~]
└─$ 平均完成耗时对比
GUI-based UFO2: 基准值100%
DMI方案: 61%
# 完成时间降低39%

还有一个特别有意思的结论：在核心测试设置下，61% 以上的成功任务，能在 4 步以内完成；针对单应用的简单任务，很多场景只需要 1 次 LLM 调用，就能完成核心意图。

论文还专门做了失败类型的分析，这也是我觉得最有价值的部分：

• 传统GUI-only的方案，绝大多数失败都是 mechanism-driven（执行层失败）——比如视觉识别错了控件、点击坐标偏了、导航路径走错了，本质上都是「知道要做什么，但操作没做对」
• 而DMI的方案，把 80.9% 的失败，收敛到了 policy（决策层）——也就是模型根本没想明白要做什么，而不是操作失误。

这才是DMI最核心的价值：它不只是让任务跑得更快、成功率更高，更是把问题从脆弱的执行层，重新拉回到了LLM最擅长的语义决策层。就像我们做系统优化，最终要解决的是「该不该做」的问题，而不是「怎么把错的事做快」。

我对这篇论文的几个个人理解

下面这部分是我自己的学习思考，不是论文的原文内容，小伙伴们可以一起讨论。

1. 真正需要重写的，从来不是Agent，而是「系统接口」

很多人优化GUI Agent，第一反应永远是换更强的多模态模型、堆更高精度的OCR、优化控件定位的grounding能力。这些当然有用，但这篇论文最戳我的点，是它跳出来问了一句：

有没有可能，问题根本不是模型对GUI理解得不够，而是我们一直在逼模型用一个天生就不适合它的接口？

就像我们之前聊Linux内存管理，从单级页表到多级页表，再到TLB、大页，本质上都是在重新设计「适合硬件特性的内存接口」，而不是一味地提升硬件频率。面向LLM的系统设计，也是一样的道理。

2. GUI对人类友好，不等于对模型友好

这点真的值得反复强调。我们现在的界面设计原则，默认的前提是：人类擅长视觉分辨、能容忍高频的细粒度交互、对精确的语法记忆差，但对视觉空间查找的能力强。

而LLM的能力模型，刚好和这个前提完全反过来。它对精确的语法、结构化的语义有极强的理解能力，但对视觉空间定位、细粒度的交互操作非常不擅长。

所以，「照着人类的用法，给Agent做接口」这件事，从根上就值得被重新审视。

3. 未来的应用，大概率会出现「面向模型的第三层接口」

如果DMI这个思路继续发展，未来的商业应用，很可能不会只暴露两层接口：

• API 给程序员做二次开发
• GUI 给普通用户操作

还会出现第三层：Model Interface，专门给AI Agent用的声明式接口。

这可能是一个比「纯GUI模仿人类」，更靠谱、更稳定的Agent落地方向。就像Linux从最初的人机交互命令行，慢慢演化出了大量面向程序的系统调用，未来的操作系统，一定会演化出专门面向AI Agent的原生接口。

对我们现在做工程实践的启发

如果大家现在就在做computer-use相关的Agent开发，这篇论文至少能给我们三个非常落地的启发，不用等OS原生支持，现在就能用在项目里。

1. 别默认「click-based点击方案」就是唯一解

如果你的Agent目标应用是可控的（比如公司内部的业务系统、固定的桌面软件、自研的WEB应用），别上来就堆截图点击的方案，优先给Agent做一层高层的意图接口，收益远比卷模型精度来得快、来得稳。

2. 尽量把低层交互，包装成有限的声明式动作

哪怕你还是要用GUI操作，也尽量把细碎的点击、滚动、拖拽，封装成「设置XX为XX」「读取XX内容」这样的声明式动作。只要能从像素坐标的逻辑里跳出来，Agent的稳定性一定会上一个大台阶。

3. 失败分析，一定要区分policy失败和mechanism失败

做Agent的故障排查，别笼统地把问题归为「模型能力不行」。一定要拆清楚：是模型根本不知道要做什么（policy失败），还是它知道要做什么，但点错了、滚过了、找不着控件（mechanism失败）。拆清楚了，你才知道到底该优化模型，还是该优化交互层。

总结

如果用一句话总结这篇论文的价值，我会说：

DMI的核心，从来不是给GUI Agent加了几个新命令，而是彻底扭转了「让LLM模仿人类操作GUI」的固有思路——把这件事从模仿人类的过程式点击，改写成了更贴合LLM能力边界的声明式系统接口。

这件事的意义，远不止提升了几个百分点的任务成功率。它告诉我们：Agent不一定非得像人一样用电脑，操作系统的接口，也从来不是只能为人类用户设计。面向模型的能力边界，重新设计交互层，可能比继续给GUI方案堆视觉补丁，要有效得多。

参考

• 论文 PDF：<https://os-for-agent.github.io/papers/AgenticOS_2026_paper_9.pdf>
• AgenticOS 2026 Workshop 官网：<https://os-for-agent.github.io/>

---

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)