在日常使用电脑时，看着屏幕、点击鼠标是再自然不过的基本操作。但这种对人类明明很容易的操作方式，却成为 AI 的巨大挑战：它们视力差、动作慢、不擅长看也不擅长点。
几十年来，操作系统的图形用户界面（GUI）一直都是为人类使用而设计，从未考虑有一天，大语言模型（LLM）会成为操作系统新的使用者。
要知道，GUI 智能体与人类在能力上存在巨大的差异，完美适配人类能力特征的 GUI，反而非常不适合 LLM 使用。
LLM 擅长语义规划、定目标、决策要“做什么”，而 GUI 逼着使用者给出具体“怎么做”的详细步骤。但是，LLM 恰恰非常不擅长这种低层次、繁琐的机制性操作，因此很容易出错。
近期，中国科学院软件研究所基础软件与系统重点实验室团队提出了一种新的思路，他们为操作系统引入了新的抽象，为大模型量身定制了目标导向接口（GOI）。通过将 GUI 操作转化为声明式（Declarative）原语，显著提高了 LLM 在自动化计算机任务中的表现。
中国科学院软件研究所陈海波教授对 DeepTech 表示，GOI 的设计理念有望为领域带来新的思考——系统或程序本身在设计时即假设用户可能是 LLM，并提供 LLM 使用的接口，而非强迫 LLM 模仿人类，去使用那些为人类设计的接口。
简单来理解，GOI 让 LLM 更像是“指挥官”而非“操作员”。传统微调或重训练的方法，就像要求大模型模仿人类，学习掌握处理机制性操作的能力；而声明式的 GOI 就像一位专业的“执行助理”，接管了 LLM 不擅长的机制操作。指挥官（大模型）专注于发挥本就擅长的能力，下达“想要什么结果”（策略），GOI 这个“助理”会自动处理所有底层的导航和交互（机制）。
GOI 与传统接口最实质的不同在于：传统接口通常默认接口的使用者为人类，而 GOI 是让接口更适合 LLM 使用，对 LLM 更友好。研究人员在 Windows 上的微软 Office 套件（Word、PowerPoint、Excel）上评估了 GOI 的有效性。
结果显示，与领先的基于 GUI 的代理基线相比，GOI 将任务成功率提升了 67%，步骤减少了 43.5%。值得注意的是，GOI 在 61% 以上的成功任务中，仅用一次 LLM 调用即完成了相关任务。
图丨论文作者，从左至右依次为：李明煜、陈海波和王远（来源：陈海波）
GOI 当前基于 Windows 系统的 UIA 可访问性机制实现，其设计理念同时具有跨平台通用性，类似的可访问机制接口在 macOS、Linux（例如 Ubuntu）、Android 等系统中均可提供。据介绍，GOI 在这些系统上落地，更多的是一种工程上的开发适配。
对于游戏和部分媒体应用来说，这类应用程序为达到更高的性能，采取了自绘和自定义的方法，并没有全部使用操作系统通用的可访问性类型和模式。因此，GOI 在这类应用上的实现需要开发者进行配合。
相关论文以《一种提高计算机使用代理效率的声明式大语言模型友好界面的案例研究》（A Case for Declarative LLM-friendly Interfaces for Improved Efficiency of Computer-Use Agents）为题发表在预印本网站 arXiv[1]。论文作者包括中国科学院软件研究所基础软件与系统重点实验室陈海波教授、李明煜副研究员和王远博士研究生。
图丨相关论文（来源：arXiv）
研究团队首先从接口设计的角度分析问题。具体而言，为人使用设计的 GUI，对用户能力做了四个关键假设：用户视力好、操作快，但短期记忆空间小且不擅长写代码。
这些假设对 LLM 并不成立。LLM 视力差、推理慢，但是上下文空间巨大，且擅长结构化输出。这种错配使得 LLM 使用 GUI 时遇到了很多挑战。例如，在使用 GUI 时，功能不能被直接调用，而是需要输出长动作链进行“导航”和“交互”。
陈海波举例说道，这就好比 LLM 去打车，命令式的 GUI 需要告诉司机“前方直行 100 米，第一个红绿灯路口右转，靠右前方行驶 50 米”，而不能直接声明“目的地”。处理这些细粒度且繁琐的步骤，恰恰是 LLM 不擅长的。
该团队的一个很自然的思考是：是否可以将 GUI 使用中 LLM 不擅长的部分交给操作系统，而非由 LLM 负责一切呢？
图丨 GOI 抽象层概述（来源：arXiv）
基于此，他们发现 APP 的使用可以分为策略（policy）和机制（mechanism）两部分。简单来理解，策略就是“做什么”：分析完成用户任务需要用到什么功能；机制则是“怎么做”：如何通过一步步的 UI 导航和交互，触发这些功能。
图丨GUI 使用中的策略-机制耦合（来源：arXiv）
另一方面，研究人员将 GUI 的导航和交互抽象为访问（access）、状态（state）、观测（observation）三类声明式原语。这样，LLM 不再需要输出具体、繁琐且易错的导航和交互步骤，而是直接通过声明式原语声明期望的结果。
“正是这三类声明式原语将策略和机制解耦，允许 LLM 专注于策略的处理，规避了大量来自机制层面的失败和交互开销，因此带来了准确率和效率的大幅提升。”陈海波表示。
图丨 GOI 工作流：离线建模与在线执行。GOI 包含三个声明性基础组件：访问、状态和观测（来源：arXiv）
以幻灯片为例，用户的需求是“将 PPT 背景全部设置为蓝色”。在这一任务中，策略（功能编排）指的是使用“蓝色”和“应用到全部”这两个功能，而机制（导航和交互）是点击“设计”“设置背景格式”“纯色填充”“颜色”“蓝色”和“应用到全部”，以触发实际的功能。
（来源：资料图）
另一个例子是，用户要求将“滚动条移动到靠近结尾的位置”。在这一任务中，策略指的是确定一个最终位置，比如 80%，而机制（交互）指的是选中滚动条、保持按住不释放，多次拖拽和移动并观察最终状态是否符合预期，直到移动到目标位置。
（来源：资料图）
GUI 的设计耦合了策略与机制，应用功能的使用前置依赖于导航和交互，无法被直接访问。当使用 GUI 时，LLM 不仅面临着冗长的动作链条，过多的调用次数，还经常在导航和交互中犯错，导致任务失败。
“虽然 LLM 不擅长处理机制，但我们发现，导航和交互两个部分存在很强的确定性，这部分工作可以由算法确定性完成，不必 LLM 参与。”陈海波表示。
具体来说，应用控件间的转换关系是确定的，可以被建模为有限状态机；同时，在可访问性下，控件可被归类为有限数量的 41 种控件类型和 34 种控制模式。这为策略与机制的解耦提供了机会。
解耦后的结果，正是“声明式”的交互范式。在这种范式下，LLM 直接指定期望的结果，而不是输出完成结果的具体动作。例如，LLM 可以直接声明 visit（“蓝色”“应用到全部”），而非输出具体的导航路径。
LLM 可以直接调用 set_scrollbar_pos（80%）以设置最终位置，而非通过迭代交互以完成这一结果。这种声明式接口，允许 LLM 专注于语义推理，而非自身不擅长的细粒度的底层操作。
表丨命令式 GUI 与声明式 GOI 的案例对比（来源：arXiv）
研究中的一个挑战是，接口的设计必须考虑 LLM 的独特能力特点，尤其是 LLM 不完美的指令遵从（instruction-following）。比如，虽然研究人员在 prompt 中要求 LLM 直接指定期望访问的控件，而非输出访问这个控件所需要的具体导航步骤，LLM 仍有可能在回答中输出具体的导航路径，这会带来更多错误的可能性。
为解决该问题，他们对非叶子节点进行了整体过滤，接口会自动忽略这些导航节点，只保留 LLM 输出中的叶子节点，以确保 GOI 完全接管控件的导航过程。
总结来说，“声明式”协作范式的初衷，是通过重构接口设计以简化 LLM 的计算机使用难度，允许 LLM 充分发挥自身所长，规避自身能力短板，最终实现生产力的实质提升。
在这一范式下，人类可以简洁地用自然语言表达自己的需求，而 LLM 和系统则能力互补。其中，LLM 专注于无法被确定性处理的语义推理任务，系统则负责处理可以被确定性解决的机制性任务。
研究团队认为，LLM 时代下，操作系统正在加速演进。在未来，操作系统可能会原生支持这种声明式接口，支撑一种模型原生的操作系统设计 [2]。例如，在官方提供的应用开发框架中，集成自动构建导航拓扑的能力，而不是将应用程序视为“黑盒”进行外部探索以完成建模。最终，这种声明式接口可能内化于操作系统的构建中，从而为“LLM 智能体”这一全新的计算机用户提供原生支持。
