1. 首頁 > 生活百科 > >

拜拜了GUI！中科院團隊“LLM友好”計算機使用接口來了

拜拜了GUI！中科院團隊“LLM友好”計算機使用接口來了

文章圖片

拜拜了GUI！中科院團隊“LLM友好”計算機使用接口來了

文章圖片

拜拜了GUI！中科院團隊“LLM友好”計算機使用接口來了

文章圖片


大模型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） 。
【拜拜了GUI！中科院團隊“LLM友好”計算機使用接口來了】
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
— 完 —
量子位 QbitAI
關注我們 ， 第一時間獲知前沿科技動態

    推薦閱讀