大模型 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
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
我们正在招聘一名眼疾手快、关注 AI 的学术编辑实习生 � �
感兴趣的小伙伴欢迎关注 � � 了解详情
� � 点亮星标 � �
科技前沿进展每日见
短线股票配资提示：文章来自网络，不代表本站观点。
