大模型Agent帮你自动操作电脑，理想很丰满，现实却骨感。

现有的LLM智能体，几乎都绕不开两大核心“痛点”：

成功率低：稍微复杂一点的任务，Agent就“翻车”，常常卡在某个步骤不知所措。效率差：完成一个简单任务，Agent需要和系统进行几十轮“极限拉扯”，耗时漫长，看得人着急。

问题到底出在哪？难道是现在的大模型还不够聪明吗？

来自中国科学院软件研究所团队的最新研究给出了一个出乎意料的答案：真正的瓶颈，在于那个我们用了40多年、无比熟悉的图形用户界面（GUI)。

将“命令式”GUI转换为“声明式”

没错，就是那个从上世纪80年代开始流行，彻底改变了人机交互方式的GUI。它一直以来都是为人类量身定制的，其设计哲学与LLM的能力模型，简直是背道而驰。

研究团队指出了GUI的核心问题：在使用GUI时，应用程序的功能无法被直接访问，而是必须依赖于导航和交互。

例如，GUI功能控件藏在层层菜单、选项卡和对话框后面，控件的访问需要点击菜单、下拉框等进行导航，以使控件出现在屏幕上。其次，许多控件的使用（如滚动条、文本选取）需要反复调整并观察反馈，形成高频“观察-操作”循环。

研究团队一针见血地指出，GUI的这种命令式（Imperative）设计背后，隐藏着对人类用户的四个“关键假设” ：

眼神好：人类精于视觉识别，能快速定位按钮、图标和菜单的位置。动作快：人类进行“观察-操作”循环，又快又容易。记忆容量小：人类的临时记忆空间有限，所以界面要简洁，一次只展示少量选项。懒得动脑：人类学习和回忆具体规则的认知成本高（例如编程语言语法），但擅长做“选择题”。

然而，这些假设和LLM的能力完全错配：

LLM偏偏眼神不好，视觉能力有限，让它在屏幕上精准识别信息，非常困难。LLM的反应偏慢，一次推理需要几秒甚至若干分钟，等待时间过长。LLM记性超群，巨大的上下文窗口让它能轻松处理极大的信息量，根本不怕选项多。LLM是格式达人，输出精确的结构化指令是它的拿手好戏。

结果就是，在使用GUI时，LLM被迫同时承担“大脑”（策略）和“双手”（机制）的角色，既要根据语义规划任务，又要处理自己不擅长且繁琐的底层操作，不仅效率低下，而且认知负担过重，极易出错。

这种“命令式”的交互方式，就像是你打车去一个地方，但不能直接告诉司机目的地，而是必须一步步指挥他如何开：“前方200米左转，再直行50米，在红绿灯处右转……”。一旦你说错一步，或者司机理解错了，就前功尽弃。这正是当前LLM智能体面临的窘境。

那么，有没有一种可能，让LLM“打车”时，只需要说出最终目的地，剩下的路线规划和具体驾驶操作，都交给一个“老司机”来自动完成呢？

这就是这项研究的核心思路：将接口从“命令式”转换为“声明式”（Declarative）。为此，研究团队基于GUI和操作系统的可访问性机制，提出了一个全新的抽象——声明式接口（GOI）。

GOI的精髓在于“策略-机制分离”（policy-mechanism separation）：

策略（Policy）：要完成什么，即任务的高层语义规划和功能编排。例如，“把所有幻灯片的背景都设置为蓝色”这一任务，需要依次用到”蓝色”和“应用到全部”这两个功能。这是LLM擅长的。机制（Mechanism）：具体怎么做，即底层的导航和交互。例如，“点击‘设计’选项卡 -> 点击‘格式背景’ -> 点击‘纯色填充’ -> …”。或者来回不停地拖拽滚动条以移动到合适的位置。这是LLM不擅长，但可以被自动化的。

GOI将繁琐、易错的“机制”部分接管，只给LLM提供三个简单直接的“声明式”原语：访问（access）、状态（state）和观察（observation）。

现在，LLM不再需要像新手司机一样战战兢兢地发出每一个微操指令，而更像一位运筹帷幄的指挥官：它只需通过GOI下达“访问‘蓝色’和‘应用到全部’”，或“设置滚动条到80%” 这样的高层指令，GOI就会自动完成所有中间的GUI导航和交互。

如此一来，LLM终于可以从GUI的泥潭中被解放出来，专注于它最擅长的语义理解和任务规划。更重要的是，整个过程不需要修改应用程序的源代码，也不依赖应用程序对外提供API。

GOI如何实现“策略”与“机制”的解耦？

GOI的实现分为两个阶段：离线建模和在线执行。

第一步：离线“绘制地图”。在离线阶段，GOI会自动探索目标应用（如Word）的可访问控件，分析点击前后界面元素的变化，从而构建出一张完整的“UI导航图”（UI Navigation Graph）。

但挑战随之而来：复杂的应用中充满了循环路径和“合并节点”（即多个路径可以到达同一个控件），而不同的路径会触发同一控件的不同功能。

GOI的巧妙之处在于，它通过一套去循环和基于成本的“选择性外化”算法，将这张复杂的图（Graph）转换成了一个路径清晰、无路径歧义的“森林”（Forest）结构 。这确保了无论LLM想访问哪个功能，都有唯一且确定的路径可以到达。

第二步：在线执行。在执行任务的在线阶段，LLM不再需要输出细粒度的GUI导航和交互序列。

取而代之的，是GOI提供的一份压缩后、对LLM上下文窗口非常友好的文本化“地图” 。当LLM需要执行任务时，它只需调用GOI提供的三大声明式原语接口：

访问（Access）：通过visit接口，直接声明要访问的目标功能控件ID 。GOI会自动计算路径并完成导航。状态（State）：通过set_scrollbar_pos(), select_lines()或select_controls()等接口，直接声明控件要达到的最终状态。例如，将滚动条直接设置到80%的位置，而无需模拟拖拽。观察（Observation）：通过get_texts()等接口，直接获取控件的结构化信息，而无需LLM进行像素级的屏幕内容识别。

这些接口不依赖于特定应用程序对外暴露”API”，而是直接基于GUI和操作系统的通用可访问性实现。

实验效果：从“机制性”错误到“策略性”错误

为了验证GOI的真实能力，研究团队在包含Word、Excel和PowerPoint的OSWorld-W基准测试集上进行了全面评估。

结果显示，GOI带来了压倒性的性能提升。在使用GPT-5推理模型的核心设置下，成功率从44%飙升至74%。

此外，超过61%的成功任务，Agent只用了一次LLM调用就“一遍过”，高效完成了用户的核心意图。

更有趣的是失败分析。

对于使用GUI的基线，53.3%的失败都属于机制层面的错误，比如通过视觉等信息对控件进行定位和识别时发生了错误、导航规划错误、在与控件进行交互时发生错误等。这就像一个人因为不认识路而失败。

引入GOI后，81%的失败集中到了策略层面，例如对任务的语义理解有误，对图片内容的语义分析有误，或者对控件功能的认知出现偏差。

这意味着GOI成功地将LLM从繁琐的机制中解放了出来，降低了机制原因导致失败的可能。LLM不再轻易犯“低级错误”，更集中于LLM自身的语义理解能力。这好比于，LLM定位错了目的地，而不是因为不认识路而失败。

团队表示，GOI的提出，为设计更适合大模型的交互范式指明了清晰方向。

这项工作不仅为提升现有Agent的性能提供了解决思路，也启发我们思考：

未来的操作系统和应用程序，是否应该原生提供这种“LLM友好”的声明式接口，从而为更强大、更通用的AI Agent铺平道路。

论文地址：https://arxiv.org/abs/2510.04607