中科院團隊打造AI專屬交互界面，任務成功率提升67%

在日常使用電腦時，看著屏幕、點擊鼠標是再自然不過的基本操作。但這種對人類明明很容易的操作方式，卻成為 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 專注于策略的處理，規避了大量來自機制層面的失敗和交互開銷，因此帶來了準確率和效率的大幅提升。”陳海波表示。

（來源：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 智能體”這一全新的計算機用戶提供原生支持。

參考資料：

1. A Case for Declarative LLM-friendly Interfaces for Improved Efficiency of Computer-Use Agents. Yuan Wang, Mingyu Li, Haibo Chen . https://arxiv.org/abs/2510.04607.

2. 模型原生操作系統：機遇、挑戰與展望. 陳海波、夏虞斌、陳榕、王肇國、糜澤羽、古金宇. 中國計算機學會通訊. 2025 年第 2 期

運營/排版：何晨龍