AI 工程從零開始｜Phase 12 Part 2：多模態 Agent 與電腦操作 — 跨模態推理與行動

大多數人把多模態 Agent 想像成「截一張圖，讓 AI 看一下，再點按鈕」。
真正的系統設計者問的是：感知、規劃、行動、驗證 四個迴圈如何在 latency、cost 與安全邊界之間取得平衡？
初學者相信截圖就等於理解；資深工程師知道 UI 狀態是動態的、DOM 是脆弱的、截圖是時間切片。
架構的差距，在於你能不能在每一個行動之後，確保系統仍處於可預期的狀態。

這篇給已經讓 VLM 看過截圖、但還沒把它放進一個會自己點按鈕的迴圈裡的工程師看。讀完你會能把 Computer Use Agent 拆成感知→理解→規劃→行動→驗證五步並說出每一步的失敗模式、為文件理解設計 OCR + Layout + VLM 管線、用狀態機與行動後驗證把成功率從六成拉到九成以上，並在沙箱、許可權與人工審批之間畫出讓 Agent 能安全碰生產系統的邊界。

一、核心問題：從感知到行動的多模態 Agent

傳統 RPA 工具（UiPath、Selenium）依賴固定選擇器：XPath、CSS selector、元素 ID。當應用升版、DOM 結構改變，自動化腳本立刻失效，維護成本以指數成長。

多模態 Agent 的出現改變了遊戲規則：它透過截圖理解 UI 語意，而非解析 DOM 結構。這讓自動化腳本對前端變動具有天然的韌性。但這只是第一步。

真正的挑戰在四個層次：

1. 感知層（Perception）：截圖解析度、遮擋、動態載入元素、多螢幕佈局
2. 理解層（Comprehension）：VLM 對 UI 語意的理解精度，圖示 vs 文字按鈕的辨識差異
3. 規劃層（Planning）：多步驟任務的拆解、回溯、錯誤恢復
4. 行動層（Action）：座標精度、點擊時機（元素是否已載入）、鍵盤輸入的上下文狀態

每一層都有獨立的失敗模式。系統設計的核心問題是：如何在每一層建立可觀測的錯誤信號，並設計對應的重試與降級策略？

此外，文件理解（PDF 報表、圖表截圖）與 UI 操作共享同一個底層能力：視覺語意理解。但它們的精度要求、延遲容忍度和成本模型截然不同。一個設計良好的多模態 Agent 平台需要統一的 VLM 推理層，同時為不同場景提供差異化的 SLA。

二、何時該升級：從單一 Agent 迴圈到狀態機驗證、再到多租戶平台的觸發條件

起點是一個「截圖 → 雲端 VLM → pyautogui 點擊」的單一迴圈：幾天就能跑通，適合驗證某類任務到底能不能自動化。它的三個缺口——無行動後驗證、無錯誤恢復、無沙箱隔離——在任務量小、錯誤可以人工補救時還能忍受。該升級的訊號是：成功率卡在六成上下而且失敗原因無法定位（沒有 trace 與截圖日誌，§六）、同一個錯誤反覆發生卻無法只重跑失敗步驟、或是 Agent 開始接觸會改變真實資料的操作（送出表單、發信）。對應的動作是加上任務狀態機、行動後截圖驗證、虛擬桌面隔離，以及差異截圖偵測來壓低 VLM 呼叫次數（§五、§七）。

第二道門檻是多團隊共用與成本：當多個部門的任務跑在同一套平台上、需要各自的許可權邊界與審計回放，就需要多租戶隔離與可逆操作記錄；當雲端 VLM 的帳單成為主要成本、而大多數步驟只是簡單的 UI 辨識時，才值得自建 VLM 推理叢集，把雲端 API 留作置信度不足時的後備（§四的 hybrid routing）。

三、文件理解：OCR + Layout Analysis + VLM

文件 AI 是多模態 Agent 的核心子系統之一。企業中最常見的場景：PDF 報表解析、發票資訊提取、合約條款審閱。

管線架構：

┌──────────────────────────────────────────────────────────┐
│               Document Understanding Pipeline             │
│                                                           │
│  PDF / 圖片                                               │
│     │                                                     │
│     ▼                                                     │
│  ┌──────────────┐    ┌──────────────┐   ┌─────────────┐ │
│  │  前處理      │───▶│  Layout      │──▶│  OCR 引擎   │ │
│  │  去噪/去偏斜 │    │  Analysis    │   │  Tesseract/ │ │
│  └──────────────┘    │  (文字區塊/  │   │  PaddleOCR/ │ │
│                      │   表格/圖片) │   │  AWS Textract│ │
│                      └──────┬───────┘   └──────┬──────┘ │
│                             │                   │        │
│                             ▼                   ▼        │
│                      ┌──────────────────────────────┐   │
│                      │  結構化中間表示               │   │
│                      │  (Bounding Box + 文字 + 型別) │   │
│                      └──────────────┬───────────────┘   │
│                                     │                    │
│                             ┌───────▼────────┐          │
│                             │  VLM 語意理解  │          │
│                             │  (表格關係/     │          │
│                             │   跨欄位推理)  │          │
│                             └───────┬────────┘          │
│                                     │                    │
│                             ┌───────▼────────┐          │
│                             │  結構化輸出     │          │
│                             │  JSON / Schema  │          │
│                             └────────────────┘          │
└──────────────────────────────────────────────────────────┘

各元件的性能特性：

關鍵設計決策：Layout Analysis 必須在 OCR 之前執行，否則 OCR 引擎會把表格的欄位文字混在一起，無法還原結構關係。對於掃描 PDF，先做去偏斜（deskew）可將 OCR 精度從 88% 提升至 96%。

表格提取的特殊挑戰：合併儲存格（merged cells）在 OCR 輸出中會丟失結構資訊。解法：用 Layout Analysis 先偵測表格邊界，再用 VLM 進行語意對齊（semantic alignment），根據視覺位置還原欄列關係。這個步驟讓複雜表格的正確提取率從 67% 提升至 89%。

四、圖表與表格理解：結構化視覺資訊提取

圖表（bar chart、line chart、pie chart）是 OCR 完全失效的場景——它們沒有可提取的文字結構，必須完全依賴 VLM 的視覺推理能力。

VLM 對圖表的理解能力（示意估算，非公開基準測試結果）：

表中為 2024 年世代的模型，數字僅用來說明「雲端大模型 vs 本地 7B」的相對差距。實際選型請用 ChartQA 等公開基準與自己的報表樣本重測；電腦操作任務的端對端成功率，則可參考 OSWorld、WebArena 這類公開基準。

精度 vs 成本的取捨策略：

• 對精度要求 < 85% 的場景（如大量報表批次摘要），使用本地 LLaVA-1.6，成本 ~$0.001/圖
• 對精度要求 > 90% 的場景（如財務合規審查），使用雲端 GPT-4V / Claude，成本 ~$0.02/圖
• 路由邏輯：先用本地模型做置信度評估，置信度 < 0.75 時自動升級到雲端模型（hybrid routing）

表格理解的結構化輸出設計：

要求 VLM 輸出符合預定義 JSON Schema，而非自由文字。這樣下游系統不需要再做二次解析，同時可以透過 Schema 驗證快速偵測 hallucination（VLM 產生了不符合格式的輸出）。

示意估算（非實測）：強制 JSON Schema 輸出比自由文字格式的解析錯誤率約可降低 34%。但要注意：Schema 的欄位越多，VLM 遺漏欄位的機率越高（超過 15 個欄位時，遺漏率從 3% 上升至 12%）。設計原則：每個 Schema 最多 10–12 個必填欄位，複雜結構拆成巢狀 Schema。

五、電腦操作 Agent：截圖→理解→行動迴圈

Computer Use Agent 的核心是一個有狀態的感知-行動迴圈。每一輪迴圈包含四個步驟：

┌─────────────────────────────────────────────────────────────────┐
│                   Computer Use Agent Loop                        │
│                                                                   │
│  ┌──────────┐                                                    │
│  │  Task    │                                                    │
│  │  Goal    │                                                    │
│  └────┬─────┘                                                    │
│       │                                                           │
│       ▼                                                           │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │  Step N                                                    │  │
│  │                                                            │  │
│  │  1. PERCEIVE    ┌──────────┐                              │  │
│  │  截圖 + 差異 ──▶│ 螢幕狀態 │                              │  │
│  │                 └────┬─────┘                              │  │
│  │                      │                                    │  │
│  │  2. UNDERSTAND       ▼                                    │  │
│  │  VLM 推理    ┌──────────────┐   「目前在登入頁，          │  │
│  │  UI 語意 ───▶│  UI 語意理解 │    需要填入帳號密碼」        │  │
│  │              └──────┬───────┘                             │  │
│  │                     │                                     │  │
│  │  3. PLAN            ▼                                     │  │
│  │  LLM 決策   ┌──────────────┐   行動選擇：               │  │
│  │  下一步 ────▶│  行動規劃器  │   click(帳號欄位)           │  │
│  │              └──────┬───────┘   type("user@example.com") │  │
│  │                     │                                     │  │
│  │  4. ACT + VERIFY    ▼                                     │  │
│  │  執行行動   ┌──────────────┐   執行後再截圖，             │  │
│  │  + 確認 ───▶│  行動執行 +  │   確認帳號已填入 ✓          │  │
│  │              │  後置驗證   │                              │  │
│  │              └──────┬───────┘                             │  │
│  │                     │                                     │  │
│  └─────────────────────┘                                     │  │
│       │           重複直到任務完成或達到最大步驟數             │  │
│       ▼                                                           │
│  ┌──────────┐                                                    │
│  │  結果    │  success / failure / partial                       │
│  └──────────┘                                                    │
└─────────────────────────────────────────────────────────────────┘

關鍵性能數字：

• 每步平均耗時：截圖 50ms + VLM 推理 1,200ms + 行動執行 200ms = ~1,450ms/步
• 典型任務步驟數：簡單表單填寫 8–12 步；複雜跨系統任務 30–60 步
• 簡單任務端對端耗時：~15 秒；複雜任務：~75–90 秒
• 每任務 VLM 成本：平均 15 次推理 × $0.018 = ~$0.27/任務

差異截圖優化（Delta Screenshot）：不是每一步都對全畫面做 VLM 推理，而是先計算前後截圖的像素差異（差異區域面積 < 5% 時跳過 VLM 重分析），可減少 35–40% 的 VLM 呼叫次數，相應降低成本與延遲。

行動類型設計：Agent 的行動空間應明確定義，不能讓 LLM 自由產生任意作業系統指令。合法行動集合：

click(x, y)              # 點擊座標
type(text)               # 鍵盤輸入
scroll(direction, steps) # 捲動
key(shortcut)            # 快捷鍵
wait(ms)                 # 等待
screenshot()             # 主動截圖
drag(x1,y1, x2,y2)      # 拖曳

任何超出此集合的指令（如 exec(shell_command)）必須被系統層攔截，不得傳遞給執行引擎。

六、UI 自動化的可靠性挑戰：動態 DOM vs 截圖

傳統 DOM-based 自動化（Selenium/Playwright）的失敗模式：

• 元素 ID 改變：版本升版後立即失效
• 動態載入元素：非同步渲染導致 ElementNotFound 錯誤
• Shadow DOM：選擇器無法穿透 Web Components 封裝
• iframe 嵌套：跨 frame 操作需要特殊處理

截圖-based VLM 自動化的失敗模式：

• 座標飄移：解析度不同、縮放比例改變，導致點擊位置偏差
• 遮擋問題：Tooltip、Dropdown 遮住目標元素
• 載入競態：截圖時元素已存在但尚未可點擊（disabled 狀態）
• 視覺相似性：兩個相似按鈕（「確認」vs「確認並送出」）VLM 誤判率高達 8%

可靠性提升策略：

策略 1：混合定位（Hybrid Locator）
先用 VLM 識別目標元素的語意（「登入按鈕」），再嘗試用 DOM 選擇器精確定位（button[type=submit]）。示意成功率（估算，非實測）：VLM-only 82% → Hybrid 91%。

策略 2：行動確認機制
每次點擊後，等待 500ms 再截圖，確認預期的 UI 狀態變化已發生（如按鈕變灰色、頁面跳轉、表單清空）。若狀態未變化，觸發重試邏輯。

策略 3：元素穩定性等待
點擊前先確認目標元素在連續 3 幀截圖中位置不變（排除動畫/載入中狀態），再執行行動。示意上，這個策略可把「點擊到錯誤位置」的錯誤率從 6% 降到 1.5% 左右（估算，非實測）。

策略 4：視覺對齊驗證
對於文字輸入，輸入後用 OCR 驗證輸入框的顯示內容是否與預期一致，而非只是「確認輸入動作已執行」。示意精度提升：資料填寫任務的欄位正確率從 94% 提升至 98.5%（估算，非實測）。

失敗率分布（示意估算，非實測）：

七、安全邊界：沙箱/許可權控制/可逆操作設計

多模態 Agent 在生產環境中執行真實操作，安全設計是不可妥協的基礎。

沙箱隔離架構：

每個任務在獨立的虛擬桌面環境中執行：

• 技術選項：Docker + VNC（低成本，隔離度中等）；KVM 虛擬機（高隔離度，~2–5 秒啟動延遲）；瀏覽器 Agent 使用 Playwright 隔離 Profile（最快，但僅限 Web 應用）
• 網路隔離：任務執行環境只允許訪問預設的白名單域名，阻斷所有外部資料外洩路徑
• 檔案系統隔離：任務環境使用臨時儲存，任務結束後自動清除，防止跨任務資料洩漏

許可權控制模型（最小許可權原則）：

TaskPolicy {
  allowed_apps: ["Chrome", "Excel", "Outlook"]
  allowed_domains: ["internal.company.com", "erp.company.com"]
  allowed_actions: ["click", "type", "scroll", "screenshot"]
  forbidden_actions: ["file_delete", "exec_command", "network_request_to_external"]
  max_steps: 100
  max_duration_seconds: 300
  require_approval_for: ["send_email", "submit_form_with_payment"]
}

人機協作的審批閘道（Human-in-the-Loop Gate）：

對於高風險行動（送出訂單、刪除資料、發送郵件），系統自動暫停並向操作者發送確認請求。這個設計讓「誤操作不可逆損失」事件率降至接近零，但會增加任務平均耗時約 45 秒（等待人工確認）。

可逆操作設計：

並非所有操作都可逆，但可以通過設計降低不可逆操作的風險：

• 表單提交：在確認步驟前截圖儲存完整的填寫內容，供後續審計或重填
• 檔案操作：移動到回收桶而非直接刪除
• Email 發送：先存入草稿，由人工確認後才發送
• 資料庫操作：記錄操作前的快照，支援單步回滾

操作審計日誌（不可篡改）：

每個 Agent 行動記錄到不可篡改的審計日誌，包含：

• 操作前後的螢幕截圖
• 行動類型、座標、輸入值
• VLM 推理輸出（含置信度）
• 執行時間戳與操作者 ID

審計日誌支援完整的「任務回放」功能，讓合規審查人員可以逐步重現 Agent 的操作序列。

八、為什麼選 X 不選 Y

狀態機 vs ReAct 迴圈的取捨在 Phase 14 Part 1 §七–§八 展開；人工審批閘道的理由已在 §七說明。這裡只留四個真正需要權衡的決策。

決策 1：截圖-based vs DOM-based 自動化

Flip Condition：若目標系統是穩定的內部 Web 應用（DOM 結構 6 個月不變），且任務量 > 10,000/日（成本敏感），則 DOM-based 方案成本更低（$0 vs $0.27/任務），應優先考慮 DOM 方案。

決策 2：本地 VLM vs 雲端 API

Flip Condition：初期日任務量 < 500（GPU 成本無法攤銷）或精度要求極高（> 95%）且複雜場景多，應優先使用雲端頂尖模型；待規模化後再轉換到本地部署。

決策 3：虛擬桌面（VNC/KVM）vs 瀏覽器沙箱

Flip Condition：若 100% 任務都是 Web-only，且不需要跨應用操作，Playwright Isolated Profile 啟動時間 < 300ms（vs KVM 的 3–5 秒），應優先考慮 Playwright 沙箱以降低延遲。

決策 4：OCR 優先 vs 端對端 VLM（直接理解文件圖片）

Flip Condition：文件圖片品質極差（嚴重模糊/手寫/低解析度），傳統 OCR 精度 < 70%，此時端對端多模態 VLM 可能優於 OCR+管線方案。

九、系統效應

從單一迴圈升級到狀態機驗證、再到多租戶平台（§二的三個觸發點），對關鍵業務指標的影響：

以上為示意估算，非實測數據。

成本模型試算（1,000 任務/日）：

• 單迴圈：1,000 × $0.45 = $450/日，月費 $13,500
• 狀態機 + 驗證：1,000 × $0.27 = $270/日，月費 $8,100
• 多租戶 + 自建 VLM：1,000 × $0.06 = $60/日，月費 $1,800（含本地 GPU 折舊後仍比單迴圈低 87%）。降幅來自兩處：主路徑改由自建 VLM 處理（約 $0.004/截圖 × 9 次 ≈ $0.036），只有置信度不足的步驟才升級到雲端 API，其餘約 $0.02 攤給雲端後備與 GPU 折舊

任務類型完成率細分（多租戶 + 自建 VLM 階段）：

以上為示意估算，非實測數據。

十、系列導航

本文是 AI 工程從零開始 系列 Phase 12 的第 2 篇。

← 上一篇：Phase 12 Part 1：Vision Transformer 與多模態融合架構

→ 下一篇：Phase 13 Part 1：MCP 與 API 整合 — AI 與真實世界的介面

系列索引：

• Phase 1–3：數學基礎、傳統機器學習、深度學習核心
• Phase 4–6：電腦視覺、NLP、語音
• Phase 7–10：Transformer、生成模型、強化學習、從頭構建 LLM
• Phase 11：LLM 推論工程、RAG 與評估
• Phase 12（本階段）：多模態（ViT 與多模態融合 → 多模態 Agent 與電腦操作）
• Phase 13–16：MCP 與工作流程編排、Agent 系統、長時程自主系統、多 Agent 協調
• Phase 17–19：推論服務與可觀測性、AI 安全與治理、Capstone

本文為 AI 工程從零開始系列內容，適用於想深入 AI 工程的工程師，以及正在設計企業級 AI 自動化平台的架構師。