AI 代理長出雙手：從操作 GUI 到觸碰真實世界的互動設計

早上醒來對著電腦說了一句「幫我訂下個月飛東京的機票，順便整理這個月的報表寄給老闆」，接著轉身去泡咖啡。回頭一看，螢幕上的滑鼠游標正自行移動，自己點選網頁、切換視窗，甚至會因為網頁載入太慢而稍微停頓——操作方式幾乎與真人無異。這不再是遙遠的科幻場景，而是已經發生的技術事實。

我們過去習慣在瀏覽器開一個視窗，把 AI 當作隨問隨答的諮詢物件——就是一個很聰明的聊天機器人。但當 AI 開始具備主動規劃與執行的能力，我們面對的不再只是一台強大的計算機，而是一套全新的運作思維。它改變了軟體與軟體之間的邊界，甚至改變了人與軟體之間的邊界。

為什麼不直接走 API，而要繞路操作 GUI

過往要讓系統自動化，例如把 A 系統的資料倒進 B 系統，工程師通常的作法為寫腳本，或者直接用 API 串接，這早已是業界標準。但 AI 操作軟體的方式開始出現轉變——它捨棄後台的捷徑，轉而走向軟體的視覺前門，也就是直接操作 GUI（圖形使用者介面）。

從純粹的執行速度來看，API 當然最快。但 API 存在一個根本性的架構限制：脆弱性與維護成本。API 需要開發者針對每一套軟體客製化撰寫並持續維護，只要對方變更端點規則，自動化流程就全面失效。面對那些根本沒有提供 API 的老舊企業內部系統，傳統自動化更是無從施力。

Agent Computer Interface（ACI）解決的正是這個通用性問題。它像是給 AI 穿上一套數位外骨骼——AI 本身是顆聰明的大腦，而原本為人類肌肉與視覺設計的 GUI，變成了它的四肢。AI 不要求系統為它開後門寫 API，而是直接穿上這套外骨骼，適應我們所處的人類環境。

傳統自動化                      ACI 驅動的代理
─────────────────────────     ─────────────────────────
每套軟體寫專屬 API            不需要任何後台 API
┌──────────────┐             ┌──────────────────┐
│ 企業系統 A    │──API──►     │  GUI 就是數位外骨骼  │
│ 端點一改就壞   │             │  AI 大腦 ──► 滑鼠鍵盤 │
└──────────────┘             └──────────────────┘
脆弱性：極高                    通用性：任何有 GUI 的軟體都能操作
維護成本：每套都要養              容錯率：動態適應畫面變化

ACI 的運作機制：從像素到語義結構

ACI 的運作遠比單純的影像辨識複雜。它透過視覺語言模型（VLM）將畫面解析成語義結構圖：螢幕右上角由三條橫線組成的圖案不只是線條，而是漢堡選單；帶有搜尋意圖的放大鏡圖示，即使從右上角移到左下角，AI 也找得到。VLM 把視覺特徵與大型語言模型的推理能力結合，形成跨模態的上下文連結。

整個流程可以拆成四個階段，串成一個封閉的迴圈：

① 視覺感知        ② GUI 元素辨識     ③ 上下文解釋      ④ 動態操作與回應
捕捉畫面表示  →   從畫素中分辨         把視覺特徵接上     以程式控制滑鼠鍵盤
(本質是截圖)      可點擊的按鈕、        大語言模型的        並持續監看畫面，
                  可編輯的文字欄位      推理，理解          對載入畫面、錯誤
                  ── 把畫素當成         放大鏡 = 搜尋       彈窗做出回應
                  結構化佈局看待

前三階段回答「AI 怎麼看懂畫面」，第四階段回答「它怎麼回應畫面」——把螢幕視為具有互動元件的結構化佈局，而不是一堆像素的集合。

這是傳統自動化腳本做不到的。腳本直接寫死「點選座標 (100, 200)」，網站一改版就會出錯失效；ACI 驅動的代理則用視覺找到放大鏡的位置再點擊，賦予系統極高的容錯率與動態適應力。

動態回饋迴圈：觀察、判斷、等待或換招

代理執行的關鍵在於動態回饋迴圈。AI 點選按鈕之後，會持續觀察畫面的狀態變化——如同我們按下按鈕會確認有沒有反應。若跳出系統錯誤的彈出視窗，或出現網路延遲的載入動畫，AI 會像人類一樣判讀當下狀態：現在是正在載入，還是操作失敗？它自行決定要等待、重新整理，還是改換另一種方法嘗試。

點選按鈕
   │
   ▼
觀察畫面狀態變化 ◄────────────────────┐
   │                                │
   ├─ 正在載入（轉圈圈）──────► 等待再觀察
   ├─ 操作成功 ──────────────► 進入下一步
   └─ 操作失敗（錯誤彈窗）────► 換方法重試 ─┘

真實世界的應用：跨軟體的工作流編排

各大科技廠商都已推出實際展示。以 Anthropic 的 Computer Use 為例，它能跨越多個互不相通的軟體編排工作流：從一份冗長的 PDF 財報中抓取特定營收資料，輸入試算表執行樞紐分析並生成圖表，最後把圖表貼進郵件草稿、寫好摘要寄給老闆。對人類而言，這是每天在辦公室發生的例行工作——切換視窗、複製貼上——但對早期 AI 來說，PDF、試算表與郵件軟體是完全孤立的環境。

透過 ACI，整個作業系統的桌面變成它統一的畫布。它不需要理解試算表的底層程式碼，只需要看懂介面邏輯，把前一個軟體在畫面上呈現的視覺結果，直接轉化為下一步操作的輸入值。這就像有一個速度快、而且永遠不會抱怨的超級虛擬實習生。

其中開源的 Browser Use 值得一提：它透過讓 AI 代理存取與控制文件物件模型（DOM），把網頁上缺乏結構的資訊提取成乾淨的結構化資料，對需要進行市場調查或資料收集的人來說是極具價值的工具。

以 Google 的 Project Mariner 為例，可以更具體地看到代理如何在瀏覽器內自主完成任務。使用者只需要下一個高階指令，剩下的全部由代理接手：

指令：「幫我在信義區找三套月租金兩萬以內的公寓，整理成一份比較表。」

步驟序列（Mariner 自主執行）
─────────────────────────────
① 造訪租屋網站（如 591、樂屋網）
② 設定過濾器：信義區、月租金 ≤ 20000
③ 逐一瀏覽列表，進入詳情頁
④ 擷取每間公寓的坪數、格局、租金、照片、連結
⑤ 把三間符合條件的結果彙整成一份結構化比較表
⑥ 回傳給使用者

代理不只是「看」網頁，它會做出人類瀏覽時才會做的判斷：某間公寓租金雖然符合預算但坪數過小，就跳過；列表頁沒有直接顯示坪數，就得點進詳情頁補齊資料。整個過程不需要任何房地產網站的 API，因為它直接操作瀏覽器這個「視覺前門」。

安全煞車：高風險節點與人類授權

賦予系統如此大的自主權，風險也隨之而來。萬一 AI 產生幻覺，擅自將一筆款項轉給錯誤的人，或刪除公司重要的客戶資料，該如何避免？此時系統不再只是給出錯誤的建議文字，而是可能造成實質的破壞。

以 OpenAI 針對 ChatGPT Agent 設計的防護機制為例，它在系統架構中引入了嚴格的關卡：使用者授權（Human-in-the-Loop）。開發者會在代理的行動空間中定義出高風險節點——例如傳送對外郵件、執行金流交易、修改系統許可權、刪除重要檔案，這些是不可逆的操作。當 AI 的行動軌跡即將觸及這些節點時，自主執行權會被暫時凍結，必須將當下的畫面狀態與即將執行的動作，透過提示框拋回給人類使用者確認，直到人類明確授權才能繼續執行。

高風險節點定義（TypeScript 示意）
────────────────────────────────
type HighRiskAction = 'send_email' | 'transfer_funds'
                     | 'change_permissions' | 'delete_files'

const APPROVAL_REQUIRED: HighRiskAction[] = [
  'send_email', 'transfer_funds',
  'change_permissions', 'delete_files',
]

if (APPROVAL_REQUIRED.includes(nextAction)) {
  await freezeAutonomy()          // 凍結自主執行權
  const approved = await askHuman({   // 拋回畫面狀態與動作給人類
    screen: currentScreenshot,
    action: nextAction,
  })
  if (!approved) return cancel()
}

這本質上是在代理的自主迴圈中強制嵌入人類的最終煞車機制——一個極度聰明、但在執行不可逆操作前必定會徵求確認的助手，能大幅降低災難性後果。人類介入的完整機制設計，可參考這裡-AI 為什麼需要人類救場：Human-in-the-Loop 架構探討。

值得強調的是：風險等級的判定權不該交給代理自己。 上述範例把 APPROVAL_REQUIRED 清單寫在代理邏輯裡，僅是示意；在正式的系統中，這份判定應該由後端的閘道層（Guardrail）掌握，代理只提出「我想做這個動作」，由閘道層依動作型別與權限範圍決定風險等級，再決定要不要凍結並詢問人類。若把「要不要問人」交給 AI 自行判斷，它可能因過度自信而跳過人類審查，讓煞車機制形同虛設。這個原則在後端事件流實作中會再次出現。

原生多模態：聽懂語氣、看懂空間

前述場景仍侷限在 2D 的電腦螢幕內。當這些具備理解與行動能力的 AI 進入我們所處的真實 3D 物理世界，事情就變得更加複雜。關鍵在於原生多模態——這與過去幾年的智慧音箱有本質上的區別。智慧音箱就是 Amazon Echo（Alexa）、Google Nest（Google Assistant）、Apple HomePod（Siri）這類能透過語音指令操作的喇叭裝置。

傳統智慧音箱使用串聯架構：語音轉文字模組把聲音變成純文字逐字稿 → 餵給語言模型理解 → 語言模型生成回覆文字 → 文字轉語音模組念出來，像工廠流水線一層一層往下傳。最大的問題是資訊流失——當語音被強行轉換成純文字，語氣中的猶豫、激動甚至嘲諷，以及背景環境的聲音細節，全部被過濾掉。這正是以前的語音助理無法判讀使用者情緒的原因。

串聯架構（傳統語音助理）              原生多模態（GPT-4o 等）
──────────────────────            ──────────────────────
語音 → 轉文字 → LLM → 轉語音        同一個神經網路
  每層轉換都流失資訊                直接處理聲音波形、影像像素、文字
  延遲疊加                         低延遲、可打斷、理解語氣與環境

OpenAI 的 GPT-4o 這類原生多模態模型徹底打破這條流水線——直接用同一個神經網路同時處理聲音的波形、影像的像素與文字的 token。當我們嘆一口氣或講話結巴時，它讀到的不只是一行寫著「（嘆氣）」的文字，而是直接感知到那個嘆息背後的挫折感。這也解釋了為何使用 Gemini Live 或 GPT-4o 時反應時間幾乎沒有延遲，而且可以隨時打斷——過去的語音助理一打斷就卡死，現在它能像真人一樣瞬間調整話題。更進階的版本甚至能感知使用者的語氣，並聰明地過濾掉不相關的背景噪音，在嘈雜的環境中也能正確判讀對話。

對開發者而言，OpenAI 還提供了 Realtime API，讓應用程式直接串接這種低延遲的語音互動能力，不必自己處理語音轉文字與文字轉語音的膠水程式碼。

加上視覺又是另一個層次。Google 的 Project Astra 不只透過手機鏡頭看到我們桌上的馬克杯，還具備空間記憶：半小時後問它「我的眼鏡去哪了」，它會想起二十分鐘前鏡頭曾掃過床頭櫃，直接告訴我們眼鏡的位置。它把指令放在當下所處的時間與空間脈絡中——這就是情境感知。微軟的 Seeing AI 則是一個值得關注的應用：這個協助視障人士的免費 App，不只是把文字念出來，而是透過鏡頭掃描整個場景——閱讀文件、識別貨幣面額、透過條碼辨識產品、描述場景與顏色，並告訴使用者正前方有一張空椅子、左邊有個人正朝自己走過來，大幅擴展了人類感知世界的邊界。

Vibe Coding：用氛圍寫程式

當 AI 能透過 ACI 流暢操作數位介面、又能透過原生多模態理解物理空間與情緒，勢必會回過頭來改變一件事：我們創造數位工具的方式。這就是 Vibe Coding——軟體工程史上的一次正規化轉移。

回顧從組合語言、C 語言到高階語言的演進，軟體開發的本質一直沒變：人類必須用極度精確、容不下一點語法錯誤的邏輯指令告訴電腦該怎麼做，少一個分號整個系統就無法運作。Vibe Coding 完全顛覆這個過程——開發者的角色從作者拉高到策展人或導演的層次。

過去寫程式就像滿場跑的攝影師，要自己調焦距、測光；現在只要對著 AI 團隊說「我要一個帶有現代感、極簡風格、有乾燥花氛圍的儀表板」，AI 就會根據這個高階的語義，把背後的 HTML、CSS 與 API 串接全部處理好。

Vibe Coding 的精髓不在於 AI 一次就能寫對——很多時候 AI 產生的程式仍有 bug 或風格不符預期。關鍵在於急速的迭代微調迴圈：AI 生成程式並嘗試執行後，如果編譯器丟出錯誤訊息或網頁畫面排版跑掉，AI 能自己去讀錯誤的 log、理解出錯原因、在幾秒鐘內自行修復。人類開發者不必再翻閱 Stack Overflow 或說明文件，只需要用自然語言給出方向性的指導：「這按鈕的轉場動畫太生硬，讓它柔和一點」「加上資料庫的錯誤處理機制，連不上就顯示友善的提示」。

這個過程還有另一個容易忽略的特質——創意夥伴。Vibe Coding 不是單向的「我們下指令、AI 照做」，而是雙向對話。AI 會主動提出開發者可能沒想過的作法：例如給出一個更快的 API 選擇、建議改用另一種資料結構、甚至推翻原本的設計方向提出更簡潔的方案。這讓開發從「一個人埋頭寫」變成「與一個有想法的夥伴共同推敲」，也加速了產品的創新。

Vibe Coding 迭代微調迴圈
────────────────────
開發者給出高階意圖（氛圍）
   │
   ▼
AI 生成程式碼 → 執行 → 出錯？
   │                        │
   │                        是
   │                        ▼
   │             AI 自己讀 log、理解原因、修復 bug
   │                        │
   └─────── 開發者用自然語言微調 ◄──────┘
   （持續到符合預期）

記憶庫：維持跨專案的一致性

若每次開啟新專案都要重新向 AI 說明「氛圍」與架構限制，溝通成本其實很高。為了維持這種跨專案的上下文，Vibe Coding 流程中引入了記憶庫（Memory Bank）的概念。它不是簡單的複製貼上，而是讓 AI 深度鎖定某個專案的特定架構決策與程式碼風格——就像團隊的共同默契。系統的自然規範或特定的 UI 元件庫設定都可以存入記憶庫，AI 在後續每次生成程式碼時都會自動套用這些氛圍限制，確保產出的系統不會隨著迭代而產生架構劣化。

記憶庫（Memory Bank）示意
────────────────────────
{
  project: 'career-dashboard',
  codeStyle: {
    language: 'TypeScript',
    framework: 'React + Tailwind',
    conventions: ['函式式元件', 'named export', 'zustand 管理狀態'],
  },
  uiConstraints: {
    palette: ['#0F172A', '#38BDF8'],
    animation: 'ease-out 200ms',
    radius: '8px',
  },
  architecture: ['一頁式儀表板', '服務層抽離 API 呼叫'],
}

對 UI/UX 的影響：把代理的行動軌跡攤開給使用者看

當 AI 開始自主操作軟體，使用者介面的角色也跟著改變。過去的介面是「我們操作，AI 回應」；現在變成「我們下指令，AI 自己操作」。這種轉變對 UI/UX 有兩個直接影響。

第一，代理的行動軌跡必須可視化。 當 AI 自己移動滑鼠、切換視窗時，最差的 UX 就是螢幕上只有一個游標在動，使用者完全不知道它在做什麼、做到哪一步。好的作法是把代理的每個動作轉譯成看得懂的軌跡：現在正在讀哪份 PDF、下一步要輸入到哪個試算表、目前卡在哪個步驟。這就像導航系統顯示「前方 200 公尺轉彎」，讓使用者即使不盯全程，也能在出錯時立刻察覺。

第二，高風險節點的授權畫面是代理介面的成敗關鍵。 前面提到的 HITL 提示框，如果只是彈出一句「是否允許繼續執行？」，使用者沒有足夠脈絡判斷，最終只會變成機械式地點「允許」。授權畫面必須把當下畫面狀態、即將執行的動作、背後的風險等級一次攤開，使用者才知道自己批准的是什麼：

┌─────────────────────────────────────────────────────────┐
│ ⚠ 需要您的授權才能繼續                                ✕  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  AI 即將執行以下動作：                                   │
│  ┌─ 動作 ──────────────────────────────────────────┐  │
│  │ 📤 傳送郵件給 boss@example.com                  │  │
│  │    主旨：Q3 財報分析                             │  │
│  │    附件：revenue-chart.png（來自試算表分析）     │  │
│  └──────────────────────────────────────────────────┘  │
│                                                         │
│  風險等級：高（對外通訊，不可撤銷）                     │
│  ┌──────────────────┐  ┌──────────────────┐           │
│  │   允許執行       │  │   退回修正       │           │
│  └──────────────────┘  └──────────────────┘           │
└─────────────────────────────────────────────────────────┘

前後端技術怎麼實作

對應到上述 UI/UX 影響，前後端有一條清晰的分工線。

後端：把代理的動作流當成事件串流推送

代理的每個動作（讀取檔案、點擊按鈕、送出請求）都要被記錄成結構化事件，透過即時通道推送到前端，而不是等整段工作流結束才回傳一個結果：

type AgentActionEvent = {
  stepId: string
  action: 'read_file' | 'click' | 'type' | 'send_email'
  target: string              // 作用對象，例如 'revenue.pdf'
  status: 'running' | 'done' | 'failed'
  riskLevel: 'low' | 'high'   // 由後端閘道層判定，供前端決定要不要渲染授權畫面
}

後端在執行到 riskLevel: 'high' 的動作前，先暫停工作流並回傳該事件的完整上下文（screen、action、target），等待前端回報使用者的授權結果後才繼續。

這裡與前文 HITL 範例的分工一致：riskLevel 由閘道層依動作型別與權限範圍判定，代理本身沒有「決定要不要問人」的權限，避免因過度自信而跳過人類審查。

前端：把事件串流渲染成代理軌跡，並實作授權面板

• 收到 AgentActionEvent 就更新軌跡面板，顯示目前的動作與狀態，失敗的步驟用不同顏色標示並允許使用者點進去查看細節
• 收到高風險事件時，彈出授權面板，完整呈現畫面截圖與動作內容，點「允許執行」才回傳授權結果
• 多模態對話介面則要支援「可打斷」的串流渲染——使用者在 AI 說話時能插話打斷，介面要立即停止目前輸出並切換到聆聽狀態，延遲必須控制在毫秒級

這個分工讓「代理自主操作」從一個不可見的黑箱，變成使用者可以隨時介入、事後追蹤的透明流程。

總結

無論是 AI 操作現有的軟體，還是人類利用 AI 創造新的軟體，所有技術突破都指向同一個終極目標：降低摩擦力——消除傳統數位世界裡僵化死板的指令邊界。從 ACI 讓 AI 突破文字框、直接操作 GUI；到原生多模態讓它聽懂語氣、看懂空間；再到 Vibe Coding 徹底改變我們創造軟體的方式。

值得思考的是：未來如果有 90% 在網路上瀏覽網頁、點選按鈕、填寫表單的「使用者」其實根本不是人類，而是 AI 代理——那我們還需要把應用程式設計成現在這種樣子嗎？還需要把介面設計成人類肉眼容易看、滑鼠容易點的形式嗎？如果 AI 本身不需要那些華麗的視覺設計也能理解系統結構，未來的數位世界是否會演變成一個專門為 AI 代理設計的巨大場域，而人類只需要坐在導演椅上設定目標與意圖。「數位介面到底為誰而存在」這個問題，非常值得在未來幾年觀察科技發展軌跡時持續思考。

參考資料

• Agentic Design Patterns - Appendix B: AI Agentic Interactions: From GUI to Real World Environment
• Anthropic Computer Use
• OpenAI Operator
• OpenAI ChatGPT Agent
• OpenAI Realtime API
• Google Project Mariner
• Browser Use 文件
• Google Project Astra
• Gemini Live
• OpenAI GPT-4o
• Anthropic Claude 4
• Microsoft Seeing AI