從「步步驚心」到「一次到位」：GUI Agent 的下一步是任務編譯，不是無盡推理

目前主流的 GUI Agent（圖形化介面代理）在執行任務時，幾乎都遵循著「觀察、思考、行動」的循環。每一次點擊、每一次輸入，都需重新呼叫大型語言模型（LLM）來決定下一步。這種模式雖然直觀，卻帶來了難以忽視的成本與延遲問題。

我認為，要讓 GUI Agent 真正走向實用與可靠，關鍵的下一步並非追求模型在每一步的推理能力，而是要徹底改變互動範式：將使用者任務「一次性編譯」成可重播、可驗證的程式碼，把效能瓶頸從模型推理轉移到更可控的執行架構上。

這個觀點，與近期一篇名為 ActionEngine: From Reactive to Programmatic GUI Agents via State Machine Memory 的研究不謀而合。它點出了一個我們在實務中早已感受到的痛點，並提出了一套系統性的解決方案。

為什麼現行的 GUI Agent 既昂貴又遲鈍？

當我們談論現行的 GUI Agent，大多指的是基於 ReAct (Reasoning and Acting) 框架的實作。從 OpenAI 的桌面控制研究到 Anthropic 展示的 Claude 3.5 Sonnet 電腦操作能力，其核心邏輯都是讓模型分析當前畫面（通常是螢幕截圖或 DOM 結構），生成一個簡短的思考，然後決定執行一個原子操作（如 click(x, y) 或 type("text")）。

這個過程的根本問題在於「反應式」（Reactive）的本質。每一步行動後，Agent 都必須停下來，把新的畫面連同歷史紀錄一起打包，再次送給 LLM 進行分析。這就像一位需要停下來思考三秒鐘才能移動滑鼠點擊一次的員工，完成一個「登入網站、尋找商品、加入購物車」的簡單任務，可能需要數十次的 API 呼叫。每一次呼叫都意味著：

• 高昂的 Token 成本：反覆傳送包含圖片和文字的龐大上下文。
• 顯著的網路延遲：API 來回傳輸的時間累積起來非常可觀。
• 不穩定的決策鏈：只要鏈條中的任何一步推理出錯，整個任務就可能失敗，且難以除錯。

這種模式在展示概念時很有效，但在要求穩定、高效的生產環境中，就顯得捉襟見肘。它把所有壓力都放在了模型的即時、循序推理能力上，卻忽略了多數 GUI 任務本身具有高度的結構性與重複性。

ActionEngine 如何將任務「編譯」成程式？

發表於 2026 年 2 月的 ActionEngine 框架，提出了一個截然不同的思路：「程式化」（Programmatic）。它的核心是將任務執行分為兩個階段：探索與生成。

首先，由一個「爬取代理」（Crawling Agent）負責預先探索目標應用程式的介面。它會像網路爬蟲一樣，走遍應用程式的各個角落，識別出所有可互動的元件（按鈕、輸入框、下拉選單等），並將這些元件與其對應的狀態變化，建成一張「狀態機地圖」（State Machine Memory）。

這份地圖詳細記錄了「在哪個畫面、點擊哪個按鈕、會跳轉到哪個新畫面」。

接著，當使用者提出一個具體任務時（例如「幫我訂一張從台北到東京的機票」），「執行代理」（Execution Agent）會接手。它不再需要看著螢幕截圖一步步猜測，而是直接查閱那份預先建好的「狀態機地圖」，並根據地圖的指引，一次性生成一段完整的 Python 程式碼。這段程式碼精準地描述了完成整個任務所需的所有步驟。

這代表我們把問題從「如何讓 LLM 在每一步都做出正確決策」，轉化為「如何讓 LLM 根據 UI 地圖，一次性生成正確的執行腳本」。

這個轉變的意義是巨大的。原本需要數十次 LLM 呼叫的任務，現在只需要一次（或極少數幾次）高品質的程式生成呼叫。一旦程式碼生成完畢，後續的執行就完全脫離了 LLM，以本地機器的速度運行，幾乎沒有延遲。

「一次性編譯」的實務意義是什麼？

將 GUI 互動從反應式轉為程式化，不僅僅是技術路徑的改變，更帶來了商業與工程上的巨大優勢。

1. 成本與延遲的數量級下降

這是最直接的好處。將 N 次 API 呼叫壓縮成一次，成本和時間都能大幅降低。生成的腳本可以在本地快速執行，徹底消除了網路延遲對操作流暢性的影響。

2. 可靠性與可驗證性的大幅提升

反應式 Agent 的「思考過程」稍縱即逝，任務失敗時很難追溯原因。但一段生成的 Python 腳本是白紙黑字的。我們可以輕易地審閱、修改、除錯這段程式碼，甚至在執行前進行靜態分析，確保其安全性與正確性。這讓 Agent 的行為從一個黑盒子變成了一個可被工程方法管理的白盒子。

3. 前所未有的可擴展性

一旦我們為某個任務（例如「在電商網站上將商品 A 加入購物車」）生成了一段可靠的腳本，這段腳本就可以被輕易地參數化和重用。我們可以輕易地將其擴展為「將 1000 個不同的商品批量加入購物車」，並以平行化的方式高速執行。這是反應式 Agent 難以想像的，它為 GUI 自動化在數據處理、軟體測試等領域的規模化應用打開了大門。

當然，這種方法並非沒有挑戰。如何高效地建構與維護 UI 的「狀態機地圖」、如何處理動態變化的介面，都是需要解決的工程問題。

但它指明了一個更具前景的方向：與其無止盡地優化模型的單步推理，不如將重心放在建立一個更穩固、更結構化的執行框架上。這就像從早期需要人類操作員一步步接線的電話交換機（類似 WebGPT 時代的人機協作），進化到可以自動尋徑的程式控制交換機。

GUI Agent 的未來，不應是一個反應遲緩、成本高昂的「智慧滑鼠」，而應是一個能將人類意圖快速編譯為高效、可靠程式的「任務編譯器」。ActionEngine 的思路，正是朝著這個方向邁出的重要一步。

延伸閱讀

• Programmatic GUI interaction for LLM agents
• OpenAI Computer Use
• Anthropic Computer Use
• ReAct: Synergizing Reasoning and Acting in Language Models

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。