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

June 21, 2026 • 23 min read • Yen

AI Multimodal Agent Computer Use VLM Document AI RKK Interview

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

面試情境

你的公司正在開發一個企業級 RPA Agent，能自動完成跨系統的報表匯出與郵件歸檔任務。目前系統在 POC 階段成功率約 62%，但 PM 要求上線後達到 90%+。請設計一個多模態 Computer Use Agent 架構，說明你如何提升可靠性、如何控制成本，以及如何在不破壞生產環境的前提下安全執行自動化操作。

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

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

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

真正的挑戰在四個層次：

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

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

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

二、三個演進階段（POC / MVP / Scale）

╔══════════════════════════════════════════════════════════╗
║  Phase 1：POC / < 500 自動化任務/日                      ║
╚══════════════════════════════════════════════════════════╝

目標：驗證可行性，快速迭代，容忍較高錯誤率（~30%）。

┌──────────────────────────────────────────────────────┐
│  User Task Request                                   │
│         │                                            │
│         ▼                                            │
│  ┌─────────────┐    截圖    ┌──────────────────┐    │
│  │  Agent LLM  │──────────▶│  VLM (雲端 API)  │    │
│  │  (規劃層)   │◀──────────│  GPT-4V / Claude │    │
│  └──────┬──────┘  理解結果  └──────────────────┘    │
│         │                                            │
│         ▼                                            │
│  ┌─────────────┐                                    │
│  │  行動執行   │  pyautogui / playwright             │
│  │  (點擊/輸入)│                                    │
│  └─────────────┘                                    │
└──────────────────────────────────────────────────────┘

新增元件：單一 Agent Loop、雲端 VLM API、基礎截圖工具
成本：VLM API ~$0.03/截圖，500 任務/日 × 平均 15 截圖 = $225/日
遺留問題：無狀態驗證、無錯誤恢復、無沙箱隔離

╔══════════════════════════════════════════════════════════╗
║  Phase 2：MVP / 500–5,000 任務/日，目標成功率 ≥ 85%     ║
╚══════════════════════════════════════════════════════════╝

目標：生產可用，建立可觀測性，引入驗證機制。

┌─────────────────────────────────────────────────────────────────┐
│                     多模態 Agent 平台（MVP）                      │
│                                                                   │
│  ┌────────────┐   Task Queue    ┌─────────────────────────────┐  │
│  │  Task API  │────────────────▶│  Agent Orchestrator         │  │
│  └────────────┘                 │  (規劃 + 重試 + 狀態機)     │  │
│                                 └───────────────┬─────────────┘  │
│                                                 │                 │
│              ┌──────────────────────────────────┤                 │
│              │                                  │                 │
│              ▼                                  ▼                 │
│  ┌───────────────────┐              ┌───────────────────────┐    │
│  │  截圖服務          │              │  VLM 推理服務          │    │
│  │  + 差異偵測        │              │  (本地 + 雲端混合)     │    │
│  └───────────────────┘              └───────────────────────┘    │
│              │                                  │                 │
│              ▼                                  ▼                 │
│  ┌───────────────────┐              ┌───────────────────────┐    │
│  │  行動執行引擎      │              │  驗證層               │    │
│  │  (虛擬桌面/VM)    │              │  (後截圖狀態確認)      │    │
│  └───────────────────┘              └───────────────────────┘    │
│                                                                   │
│  Observability: Trace ID + 截圖日誌 + 行動序列回放               │
└─────────────────────────────────────────────────────────────────┘

新增元件：任務狀態機、差異截圖偵測（減少 40% VLM 呼叫）、行動後驗證、虛擬桌面隔離
成本：混合 VLM（本地處理簡單 UI 辨識，雲端處理複雜判斷），降至 ~$0.018/截圖
遺留問題：無多租戶隔離、跨應用任務協調複雜

╔══════════════════════════════════════════════════════════╗
║  Phase 3：Scale / 5,000+ 任務/日，目標成功率 ≥ 92%      ║
╚══════════════════════════════════════════════════════════╝

目標：企業級、多租戶、可審計、自動擴縮。

┌──────────────────────────────────────────────────────────────────────┐
│                    Enterprise Computer Use Platform                    │
│                                                                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                           │
│  │ Tenant A │  │ Tenant B │  │ Tenant C │  ... 隔離的任務佇列        │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘                           │
│       └──────────────┴──────────────┘                                 │
│                      │                                                 │
│                      ▼                                                 │
│  ┌───────────────────────────────────────────────────────────────┐   │
│  │  Agent Scheduler（優先權 + 資源配額 + SLA 監控）               │   │
│  └───────────────────────────┬───────────────────────────────────┘   │
│                               │                                        │
│         ┌─────────────────────┼─────────────────────┐                │
│         ▼                     ▼                     ▼                │
│  ┌─────────────┐    ┌─────────────────┐    ┌──────────────────┐     │
│  │  VLM Pool   │    │  Sandbox Fleet  │    │  Audit & Replay  │     │
│  │  自動擴縮   │    │  (隔離 VM/容器) │    │  系統            │     │
│  └─────────────┘    └─────────────────┘    └──────────────────┘     │
│         │                     │                     │                │
│         └─────────────────────┴─────────────────────┘                │
│                               │                                        │
│                      ┌────────▼────────┐                             │
│                      │  Action DB      │                             │
│                      │  (可逆操作記錄) │                             │
│                      └─────────────────┘                             │
└──────────────────────────────────────────────────────────────────────┘

新增元件：多租戶隔離、VLM 推理叢集自動擴縮、全行動審計日誌、可逆操作回滾機制
成本：自建 VLM 推理（LLaVA-1.6 / InternVL2）成本降至 ~$0.004/截圖；雲端 API 保留作後備
成功率演進：Phase 1 ~62% → Phase 2 ~85% → Phase 3 ~93%

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

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

管線架構：

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

各元件的性能特性：

元件	延遲	精度	成本
PaddleOCR（本地）	80–150ms/頁	95–97%	~$0
AWS Textract	800–1,500ms/頁	98–99%	$0.015/頁
Layout Analysis（LayoutLMv3）	120–200ms/頁	94%	~$0（本地）
VLM 表格推理（Claude Sonnet）	2,000–4,000ms	91–95%	$0.003–0.015/頁

關鍵設計決策：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 對圖表的理解能力（基準測試）：

圖表類型	GPT-4V 精度	Claude 3.5 Sonnet 精度	LLaVA-1.6（7B）精度
長條圖數值讀取	91%	89%	73%
折線圖趨勢判斷	94%	93%	81%
圓餅圖比例估算	85%	83%	64%
複合圖表（雙軸）	78%	76%	51%

精度 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%。

失敗率分布（100 次任務實測）：

失敗類型	佔比	主要原因
UI 狀態判斷錯誤	34%	VLM 誤判元素狀態（disabled/hidden）
座標偏差	22%	縮放/解析度差異
任務規劃錯誤	19%	LLM 誤解任務意圖
載入超時	15%	網路慢或應用響應慢
不可預期 UI 變化	10%	應用升版、A/B 測試

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

多模態 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

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

選擇	選截圖+VLM 的理由	不選純 DOM 的理由
截圖+VLM	對前端升版天然韌性，無需更新選擇器；支援桌面應用（非 Web）；能理解視覺語意（圖示按鈕）	DOM 選擇器脆弱，應用升版後維護成本極高；無法處理 Canvas/Flash/桌面 GUI；Shadow DOM 穿透複雜

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

決策 2：本地 VLM vs 雲端 API

選擇	選本地 VLM（InternVL2/LLaVA）的理由	不選純雲端 API 的理由
本地 VLM	每次推理成本 ~$0.001（vs 雲端 $0.015–0.03）；資料不離境，符合企業隱私合規；延遲可控（500–800ms 本地 GPU vs 1,500–3,000ms 雲端）	雲端 API 成本在高併發下線性增長；截圖包含企業敏感資料（財務報表）不宜外送；SLA 依賴第三方

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

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

選擇	選虛擬桌面的理由	不選瀏覽器沙箱的理由
虛擬桌面	支援所有桌面應用（Excel、SAP、ERP 系統）；完整 OS 隔離，安全邊界清晰；可錄製完整操作影片供審計	瀏覽器沙箱（Playwright Profile）只支援 Web 應用；跨應用任務（從網頁下載報表再開 Excel）無法處理；隔離度不足以滿足金融/醫療合規要求

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

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

選擇	選 OCR+Layout+VLM 管線的理由	不選端對端 VLM 直接理解的理由
OCR+Layout+VLM 管線	OCR 文字提取精度 97–99%，VLM 專注語意理解而非像素級文字識別；管線各步驟可獨立監控與除錯；成本可控（OCR 便宜，VLM 只用於語意）	端對端 VLM（直接輸入文件圖片）在文字密集文件上精度只有 85–88%；長文件（20+ 頁）超出 context window；錯誤難以定位（哪一步出問題）

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

決策 5：任務狀態機 vs 純 LLM ReAct 迴圈

選擇	選顯式狀態機的理由	不選純 ReAct 迴圈的理由
顯式任務狀態機	明確的狀態轉移讓失敗點可定位；支援精確的步驟重試（只重跑失敗的步驟）；超時/最大步驟數等 SLA 控制點清晰	純 ReAct 迴圈的 LLM 容易「發散」（無限嘗試新路徑）；失敗後重試整個任務成本高；難以在不同 step 設置差異化的 timeout 策略

Flip Condition：探索性任務（任務目標模糊，需要 Agent 自主探索）或 step 數 < 5 的簡單任務，ReAct 迴圈的靈活性更有價值，狀態機的設計成本不划算。

決策 6：Human-in-the-Loop 審批 vs 完全自動執行

選擇	選 Human-in-the-Loop 的理由	不選完全自動化的理由
Human-in-the-Loop（高風險行動）	不可逆操作（發郵件、提交訂單）的錯誤代價極高；企業合規要求關鍵操作有人工審批記錄；初期 Agent 精度不足時降低業務風險	完全自動化在高風險操作上的錯誤代價（客戶投訴、資料錯誤、財務損失）遠超 45 秒的審批等待成本

Flip Condition：當 Agent 在特定任務類型上的歷史成功率連續 30 天 > 99.5%，可逐步開放該類型的完全自動化執行，減少人工審批負擔。

九、系統效應

系統從 Phase 1 到 Phase 3 的演進，對關鍵業務指標的影響：

指標	Phase 1（POC）	Phase 2（MVP）	Phase 3（Scale）	改善幅度
任務自動完成率	62%	85%	93%	+31 pp
平均任務耗時	45 秒	28 秒	22 秒	-51%
每任務 VLM 成本	$0.45	$0.27	$0.06	-87%
誤操作導致的資料錯誤率	4.2%	0.9%	0.15%	-96%
Agent 月度維護工時	N/A	40 hrs	8 hrs	-80%
P95 任務延遲	120 秒	65 秒	45 秒	-63%
截圖-VLM 呼叫次數/任務	15 次	10 次（差異優化）	9 次	-40%
高風險操作誤執行事件數/月	12 件	2 件	0 件	-100%

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

Phase 1：1,000 × $0.45 = $450/日，月費 $13,500
Phase 2：1,000 × $0.27 = $270/日，月費 $8,100
Phase 3：1,000 × $0.06 = $60/日，月費 $1,800（含本地 GPU 折舊後仍比 Phase 1 低 87%）

任務類型完成率細分（Phase 3）：

任務類型	完成率	備註
Web 表單填寫	97%	最穩定，DOM 輔助定位
PDF 報表提取	95%	OCR+VLM 管線成熟
Excel 資料整合	89%	桌面應用，座標精度要求高
跨系統資料同步	83%	多應用切換，狀態管理複雜
圖表數值讀取	88%	純 VLM 視覺推理

十、面試答題要點

面試官問：你的 Computer Use Agent 在 POC 成功率只有 62%，如何系統性地提升到 90%+ 並安全上線到生產環境？

「要從 62% 提升到 90%+，我會先做失敗模式分析，將失敗分為 UI 狀態判斷錯誤（34%）、座標偏差（22%）、規劃錯誤（19%）三大類，針對每類設計對策。第一，建立行動後驗證機制：每次點擊後截圖確認預期 UI 狀態變化，讓「行動成功但未生效」的靜默失敗變成可偵測的錯誤。第二，引入混合定位策略（VLM 語意 + DOM 選擇器），將點擊精度從 82% 提升至 91%，同時用差異截圖優化把 VLM 呼叫次數減少 40%，每任務成本從 $0.45 降至 $0.27。第三，安全上線的關鍵是「沙箱隔離 + HITL 審批閘道」：所有任務在獨立 KVM 虛擬桌面中執行，網路存取限制白名單；對發郵件、提交訂單等高風險行動強制人工審批，讓不可逆誤操作事件歸零。最後，在 Phase 3 透過自建 VLM 推理叢集（InternVL2）將推理成本從 $0.015/截圖降至 $0.004/截圖，使 1,000 任務/日的月費從 $13,500 降至 $1,800，讓規模化在財務上可行。」

十一、系列導航

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

← 上一篇：Phase 12 Part 1：多模態基礎 — VLM 架構與視覺語言對齊

→ 下一篇：Phase 13 Part 1：Agent 評估框架 — 基準測試、自動評分與人工標注管線

系列索引：

Phase 1–4：基礎建設（資料工程、訓練基礎設施、模型服務）
Phase 5–8：LLM 應用工程（RAG、Prompt 工程、Fine-tuning、評估）
Phase 9–11：Agent 系統（工具呼叫、多 Agent 協作、記憶體管理）
Phase 12（本系列）：多模態 Agent（VLM 基礎 → 電腦操作 Agent）
Phase 13–15：Agent 評估、安全與生產運維

本文為 AI 工程從零開始系列內容，適用於準備 Staff/Principal Engineer 面試的工程師，以及正在設計企業級 AI 自動化平台的架構師。