Computer Use & Browser Use Agents 2026 - Kiến trúc Production cho AI điều khiển trình duyệt và máy tính với Claude Computer Use, OmniParser V2, Playwright MCP, Browser Use, Redis và ClickHouse cho Multi-Agent

Posted on: 4/15/2026 2:18:08 PM

1. Kỷ nguyên Agent điều khiển máy tính: Khi LLM cầm chuột và gõ phím

Suốt năm 2023-2024, hình dung phổ biến về "AI Agent" là một chatbot gọi API: model đọc prompt, sinh JSON tool call, backend thực thi, trả kết quả dạng text. Kiến trúc đó xử lý tốt các tác vụ có API sẵn — Slack, Linear, Stripe, GitHub — nhưng đụng tường khi phải làm việc với phần lớn phần mềm thế giới thực không có API công khai: ERP nội bộ, dashboard legacy, trang web bảo vệ captcha, công cụ SaaS tính phí per-seat, các ứng dụng desktop lập lịch qua UI. Cuối 2024, Anthropic mở màn một thế hệ agent mới với Computer Use API — cho phép Claude nhìn screenshot, nhấp chuột, gõ phím, cuộn trang. Năm 2026, mảng "Computer Use & Browser Use Agents" đã bước vào trạng thái production thực thụ: Claude Opus 4.6 đạt 66.3% trên OSWorld, Claude Managed Agents đóng gói hạ tầng , và hệ sinh thái mở với Browser Use, Steel, BrowserBase, Hyperbrowser, E2B đều trưởng thành.

Bài viết này mổ xẻ kiến trúc production của agent điều khiển máy tính và trình duyệt từ góc nhìn System Design: ba trường phái grounding (pixel / DOM / accessibility), cách Anthropic thiết kế tool spec, pattern Planner-Executor cho computer use, session pool với Redis, hàng đợi nhiệm vụ, observability qua ClickHouse, cơ chế an toàn, và checklist triển khai thực tế cho Multi-Agent.

2. Ba trường phái perception: Pixel, DOM, Accessibility

Trước khi agent có thể "click" hay "type", nó phải trả lời được câu hỏi căn bản: cái gì đang ở trên màn hình và ở toạ độ nào? Đây là bài toán element grounding — ánh xạ mô tả ngôn ngữ ("nút Đăng ký", "trường email") thành một toạ độ pixel hoặc một handle DOM ổn định. Có ba trường phái cạnh tranh nhau, mỗi trường phái thắng ở một nhóm use-case khác nhau.

graph TB
    INPUT["User request click nut Dang ky"] --> PERC{"Perception approach"}
    PERC --> PIX["Pixel Vision"]
    PERC --> DOM["DOM Structure"]
    PERC --> AXT["Accessibility Tree"]
    PIX --> SS["Screenshot 1920x1080"]
    SS --> VLM["VLM Claude Opus 4.6"]
    VLM --> COORD["x y coordinate"]
    DOM --> CHROME["Chrome DevTools Protocol"]
    CHROME --> SELECTOR["CSS selector hoac XPath"]
    AXT --> AX["Accessibility Snapshot"]
    AX --> REF["Stable element ref e1 e2 e3"]
    COORD --> ACT["Action click"]
    SELECTOR --> ACT
    REF --> ACT
    style PIX fill:#e94560,stroke:#fff,color:#fff
    style DOM fill:#2196F3,stroke:#fff,color:#fff
    style AXT fill:#4CAF50,stroke:#fff,color:#fff

Hình 1: Ba đường đi từ input của người dùng đến action thực thi — Pixel, DOM và Accessibility Tree

2.1. Pixel — Khi agent nhìn màn hình như con người

Đây là cách tiếp cận "pure vision": agent chụp screenshot, gửi ảnh cho VLM (Vision-Language Model), và model trả về toạ độ click. Anthropic chọn con đường này cho computer_20250124 tool trong Claude 4.6, với hai cải tiến quan trọng: scale-aware coordinate (model tự hiểu độ phân giải ảnh, không cần user normalize) và Zoom Action — một hành động mới trong Claude Opus 4.6 cho phép model chủ động "phóng to" một vùng để đọc chữ nhỏ trước khi click. Zoom action giải quyết bài toán "blurry text" — lỗi kinh điển trước đó khi screenshot 1920×1080 bị downsample về 1280×720 làm model đọc sai nhãn button.

Ưu điểm lớn nhất của pixel là phổ quát: chạy được trên mọi app (desktop, browser, mobile emulator), không phụ thuộc framework UI. Nhược điểm là chi phí — mỗi action cần một screenshot ~200-500KB gửi kèm prompt, model phải reason qua hàng triệu pixel, latency 2-5 giây/step. Hơn nữa, độ chính xác grounding thuần vision trên screen dày đặc element vẫn chưa theo kịp DOM-native: benchmark ScreenSpot Pro cho thấy GPT-4o thuần đạt 0.8%, chỉ khi ghép với OmniParser V2 mới leo lên 39.6%.

2.2. DOM — Khi agent đọc cấu trúc HTML trực tiếp

Với web app, cách tiếp cận này hiệu quả gấp bội: agent kết nối qua Chrome DevTools Protocol (CDP), trích toàn bộ DOM tree, filter những node có thể tương tác (button, a, input, [role=button], [onclick]), rồi gắn stable element reference (e1, e2, e3...) cho model. Model chỉ cần trả về "click e23", không cần đoán toạ độ. Các dự án tiêu biểu: browser-use của browser-use.com, Playwright MCP, Chrome DevTools MCP, rtrvr.ai DOM Intelligence.

Ưu điểm: token tiết kiệm (accessibility snapshot thường nhỏ hơn raw HTML 90%), action ổn định (element ref không bị lệch khi user scroll), latency thấp (~200ms/step). Nhược điểm: không làm được với Canvas-based app (Figma, Google Sheets cells), không làm được với iframe cross-origin, không làm được với desktop app ngoài trình duyệt.

2.3. Accessibility Tree — Trung đạo

Accessibility tree là cấu trúc mà trình duyệt/hệ điều hành xây dựng để phục vụ screen reader: mỗi element có role (button, link, textbox), name (visible label), state (focused, disabled, expanded). Cấu trúc này đã được browser "chưng cất" từ DOM + CSS + ARIA, bỏ đi mọi noise, chỉ giữ thông tin có ý nghĩa với người dùng. Từ khi Claude Code Cowork hỗ trợ Chrome DevTools MCP với take_snapshot (full accessibility tree), đây trở thành tuỳ chọn tối ưu cho hầu hết workflow web: độ chính xác gần bằng DOM, token thấp nhất trong ba trường phái, và còn làm được với native app Windows/macOS qua UIAutomation/AX API.

3. Claude Computer Use tool spec: Giải phẫu từng trường

Anthropic công bố tool computer_20250124 như một "tool đặc biệt" — khác với tool JSON thông thường, client bắt buộc phải hiểu semantic và tự thực thi. Schema tối giản nhưng đủ mạnh để mô tả gần như mọi thao tác người dùng.

{
  "name": "computer",
  "type": "computer_20250124",
  "display_width_px": 1920,
  "display_height_px": 1080,
  "display_number": 1
}

Khi model muốn hành động, nó phát tool_use với input.action là một trong 14 action chính:

3.1. Coordinate system — Điểm mấu chốt thường sai

Claude luôn trả toạ độ theo hệ đơn vị của ảnh screenshot gần nhất mà client đã gửi, không phải theo hệ của màn hình vật lý. Nếu bạn chụp retina display 5120×2880 rồi resize xuống 2560×1440 trước khi gửi (để tiết kiệm token), thì toạ độ model trả về cũng nằm trong không gian 2560×1440 — client phải tự nhân tỉ lệ khi dispatch tới hệ điều hành. Đây là nguồn gốc của lớp bug kinh điển "click lệch 50px", nhất là khi trộn DPI khác nhau giữa monitor chính và phụ.

3.2. Interleaved thinking kết hợp Computer Use

Một thay đổi quan trọng của Claude 4.6 là interleaved thinking được bật mặc định cho computer use. Ở mỗi bước, Claude sinh một khối thinking ngắn (vd: "Đã thấy nút Đăng ký ở top-right, nhưng có captcha trước đó — phải giải captcha trước khi click") rồi mới phát tool_use. Điều này giúp agent có "working memory" xuyên suốt chuỗi hành động dài mà không cần kỹ sư prompt thủ công. Đổi lại, cần quản lý thinking budget cẩn thận: mỗi step tốn 500-2000 thinking tokens, một tác vụ 30 bước có thể đốt 30-60K thinking tokens — nhiều hơn cả output text. Liên kết với bài Reasoning Models & Extended Thinking 2026 trên anhtu.dev.

4. Element Grounding Models: OmniParser V2, SeeClick, ShowUI, Gelato

Với các VLM đa dụng như GPT-4o, Gemini 2.5 Pro, khả năng grounding thuần (cho toạ độ chính xác) còn yếu. Giải pháp phổ biến: ghép với một grounding model chuyên dụng chạy trước LLM, parse screenshot thành cấu trúc có nhãn và bounding box, rồi cho LLM chọn element theo tên.

graph LR
    SHOT["Screenshot"] --> OMNI["OmniParser V2 YOLO icon det"]
    OMNI --> BBOX["List box nhan text icon"]
    BBOX --> PROMPT["Prompt element set structured"]
    PROMPT --> LLM["LLM any model"]
    LLM --> PICK["Chon element theo ten"]
    PICK --> COORD["Toa do chinh xac"]
    style OMNI fill:#e94560,stroke:#fff,color:#fff
    style LLM fill:#4CAF50,stroke:#fff,color:#fff

Hình 2: Pipeline OmniParser + LLM — tách bạch phần nhận diện và phần quyết định

4.1. OmniParser V2 — Microsoft Research

OmniParser V2 là pipeline hai giai đoạn: (1) YOLO icon detection train trên tập Web-150K để phát hiện mọi UI element (nút, icon, ô text), (2) BLIP2 hoặc GPT-4o captioning để gán nhãn ngữ nghĩa. Kết quả là danh sách có dạng [{id:1, bbox:[x,y,w,h], label:"Button Sign Up"}, ...] gửi vào LLM cùng với screenshot. Hiệu quả ấn tượng: nâng GPT-4o từ 0.8% lên 39.6% trên ScreenSpot Pro — benchmark khó nhất cho element grounding vì tập chứa các app chuyên dụng (Photoshop, Blender, CAD).

4.2. SeeClick, CogAgent, ShowUI, Gelato

Đây là nhóm model được huấn luyện end-to-end cho GUI grounding: input là screenshot + instruction, output là toạ độ click. SeeClick (2024) nhỏ gọn 9.6B params nhưng hiệu quả nhờ pretrain trên 1M cặp GUI-instruction. CogAgent 18B dùng encoder ảnh kép (low-res cho context toàn trang, high-res 1120×1120 cho chi tiết nhỏ). ShowUI-Aloha tập trung dựng dataset từ screen recording thực tế. Gelato của mlfoundations (3/2026) đẩy state-of-the-art thêm một bậc bằng pipeline data curation + RL fine-tuning.

5. Kiến trúc production 3 tầng: Task → Orchestration → Execution

Triển khai một computer use agent đơn lẻ để demo thì dễ — một script Python + Playwright + vài chục dòng Claude SDK. Nhưng đưa lên production phục vụ hàng nghìn tác vụ/giờ với retry, timeout, cost control, và isolation giữa các tenant là bài toán System Design thực thụ. Chuẩn mực 2026 là kiến trúc ba tầng:

graph TB
    USER["API client"] --> TM["Tang 1 Task Management"]
    TM --> Q["Redis queue Priority"]
    Q --> SCHED["Scheduler"]
    SCHED --> ORCH["Tang 2 Orchestration"]
    ORCH --> POOL["Session Pool"]
    POOL --> BR1["Browser worker 1"]
    POOL --> BR2["Browser worker 2"]
    POOL --> BRN["Browser worker N"]
    BR1 --> LLM["Claude 4.6 API"]
    BR2 --> LLM
    BRN --> LLM
    BR1 --> EX["Tang 3 Execution"]
    EX --> FIRE["Firecracker microVM"]
    EX --> E2B["E2B "]
    EX --> HYP["Hyperbrowser"]
    BR1 --> OTEL["OpenTelemetry"]
    OTEL --> CH["ClickHouse traces"]
    style TM fill:#e94560,stroke:#fff,color:#fff
    style ORCH fill:#ff9800,stroke:#fff,color:#fff
    style EX fill:#4CAF50,stroke:#fff,color:#fff
    style CH fill:#9b59b6,stroke:#fff,color:#fff

Hình 3: Kiến trúc production ba tầng cho computer use agent

5.1. Tầng 1 — Task Management

Tầng này nhận request từ client, chuẩn hoá thành task, đặt vào hàng đợi, và quản lý vòng đời. Stack điển hình: Redis Streams (hoặc BullMQ, SQS) cho queue, PostgreSQL/MongoDB cho persisted task state, và một scheduler tự tuỳ biến theo policy (FIFO, priority theo org, round-robin). Mỗi task có lifecycle state: queued → scheduled → running → waiting_action → succeeded/failed/timeout. Các trường quan trọng:

# Redis Streams format cho computer use task
XADD tasks:browser * \
  task_id "t_a7b2c3" \
  org_id "org_42" \
  priority "high" \
  goal "Dang ky tai khoan moi tren partner.example.com" \
  starting_url "https://partner.example.com" \
  max_steps "40" \
  max_cost_cents "150" \
  max_wall_clock_sec "900" \
  credentials_ref "vault:org42/partner" \
  trace_mode "full"

Policy quan trọng nhất ở tầng này là budget hard cap: một task không bao giờ được vượt quá giới hạn step, cost, hay wall-clock. Thiếu guard này, một agent rơi vào loop "Let me try again... let me try again..." có thể đốt hàng chục đô la chỉ trong vài phút. Redis hash theo org_id tracking token bucket đã triển khai tương tự trong bài LLM Gateway 2026.

5.2. Tầng 2 — Orchestration

Orchestrator là "bộ não" của một task chạy: nó lấy task khỏi queue, giành một session từ pool, khởi tạo browser/OS, gửi vòng lặp Claude API ↔ action, xử lý retry khi action fail, stream tiến trình về client, và đóng session khi done. Vòng lặp chính:

sequenceDiagram
    participant O as Orchestrator
    participant S as Sandbox browser
    participant C as Claude 4.6
    O->>S: Khoi tao browser goto URL
    S->>O: Ready
    O->>S: take screenshot
    S->>O: PNG base64
    O->>C: prompt goal screenshot
    C->>C: Thinking block
    C->>O: tool use left click 120 340
    O->>S: Execute left click 120 340
    S->>O: New screenshot
    O->>C: tool result screenshot
    C->>O: tool use type "email@example.com"
    O->>S: Execute type
    S->>O: New screenshot
    O->>C: tool result screenshot
    C->>O: text Da dang ky thanh cong
    O->>S: Close session

Hình 4: Vòng lặp perception-action giữa Orchestrator, Sandbox và Claude

Hai cải tiến quan trọng để orchestration không sụp đổ khi scale:

• Per-step timeout cấp độ hệ điều hành: mỗi action (click, type, wait) đặt timeout 3-10s; nếu vượt, kill action, chụp lại screenshot và cho model quyết. Không nên bật timeout dài ở tầng cao hơn vì page load bị lag ngẫu nhiên sẽ killed toàn bộ task.
• Action deduplication: nếu model liên tục lặp lại cùng action (cùng coordinate, cùng text) trong 3 step gần nhất mà screenshot không đổi, orchestrator chủ động inject message "Action không đem lại thay đổi nào. Hãy chọn cách khác." để phá vỡ loop.

5.3. Tầng 3 — Execution

Tầng execution là nơi thực thi thực tế: một trình duyệt hoặc một máy ảo mini. Tiêu chí chọn: (a) cô lập (mỗi task một độc lập, không chia sẻ cookie/cache), (b) khởi tạo nhanh (cold start <2s), (c) lifecycle quản lý được (destroy sau khi done), (d) quan sát được (stream video, logs). Các lựa chọn phổ biến:

6. Browser Use, Playwright MCP, Chrome DevTools MCP

Bên cạnh kiến trúc tự build, năm 2026 có ba thư viện open-source chi phối phần lớn thị trường agent trình duyệt. Hiểu rõ điểm mạnh từng thư viện giúp chọn đúng công cụ cho từng bài toán.

6.1. Browser Use (browser-use.com)

Thư viện Python của Magnus Müller nổi bật nhờ pipeline DOM-first: tại mỗi bước, extract mọi element có thể click/type, gắn selector index, build prompt dạng "Here are 47 interactive elements: [1] <button>Sign up</button>, [2] <a href=/about>About</a>, ...". Model chọn index, thư viện dispatch. Ưu điểm lớn: rất nhanh (không phải đợi VLM reasoning trên ảnh), token rẻ, dễ debug. Nhược điểm: chỉ web app, không làm được canvas-heavy (Figma, Sheets), và bị rối khi page dùng shadow DOM nhiều tầng.

from browser_use import Agent
from langchain_anthropic import ChatAnthropic

agent = Agent(
    task="Vao GitHub, tim repo co tu khoa 'computer use', sao chep URL cua 3 repo dau tien",
    llm=ChatAnthropic(model="claude-sonnet-4-6"),
    max_steps=25,
    use_vision=False,  # DOM-first, tiet kiem token
)
result = await agent.run()

6.2. Playwright MCP (Microsoft)

Microsoft phát hành Playwright MCP để "biến Playwright thành tool của bất kỳ MCP client nào" — Claude Code, Cowork, Cursor, Windsurf. Playwright MCP expose 20+ tool chuẩn (navigate, click, fill, screenshot, snapshot, select_option...) qua giao thức MCP, client chỉ cần declare server trong config. Đây là lựa chọn tốt nhất nếu bạn đã có pipeline MCP: agent không cần biết gì về Playwright, chỉ cần đọc tool spec và gọi. Liên kết với bài MCP - Giao thức Kết nối Vạn năng 2026 trên anhtu.dev.

6.3. Chrome DevTools MCP

Google ra mắt Chrome DevTools MCP đầu 2026 với tham vọng trở thành "chuẩn" cho trình duyệt agent: expose Chrome DevTools Protocol qua MCP, cho phép agent làm mọi việc mà DevTools làm được — network inspection, performance trace, screenshot, accessibility snapshot. Điểm đặc biệt là take_snapshot trả về full accessibility tree với stable ref ổn định cho click/type, rất thân thiện với LLM. Đây là backbone của tính năng "Computer Use" trong Claude Code Cowork chính thức.

7. Session, Auth, Cookies, Fingerprint

Tác vụ computer use thực tế hiếm khi đứng một mình — phần lớn cần đăng nhập vào một hệ thống nào đó trước (Salesforce, Jira, email, banking internal portal). Quản lý session và auth trở thành điểm đau kinh điển.

7.1. Vault Pattern — Không bao giờ để credential chạm LLM

Tuyệt đối cấm nhúng username/password vào prompt. Thay vào đó: (1) lưu credential trong secret vault (HashiCorp Vault, AWS Secrets Manager, 1Password CLI), (2) orchestrator cung cấp một tool ảo type_credential mà LLM gọi với tham số field="username" — orchestrator mới là nơi thực thi thao tác gõ, không bao giờ expose giá trị cho model. Cùng pattern này ngăn model prompt-inject credential ra ngoài qua agent-to-agent message.

7.2. Cookie Jar Pattern

Giải pháp hiệu quả cho tác vụ đăng nhập lặp đi lặp lại: lưu cookie jar đã xác thực vào vault, mỗi lần cần session mới thì inject jar vào browser trước khi navigate. Bạn không cần agent đăng nhập lại mỗi request, không cần để credential lại trên đĩa session, và các hệ thống có MFA không phải gửi OTP liên tục. Lưu ý: cookie jar cần xoay định kỳ (mỗi 24h-7 ngày) và tách biệt theo tenant tuyệt đối.

7.3. Browser fingerprint và anti-detection

Nhiều trang web triển khai bot detection (Cloudflare, DataDome, PerimeterX) dựa trên canvas fingerprint, WebGL, font list, timezone, và lịch sử hành vi chuột. Chạy Playwright headless mặc định sẽ bị chặn ngay. Các giải pháp:

• Stealth engines (Playwright Stealth, undetected-chromedriver, CamoFox): patch các tín hiệu dễ bị phát hiện như navigator.webdriver=true, missing chrome object, font list bất thường.
• Residential proxy (BrowserBase, Bright Data): IP dân cư thay vì datacenter IP.
• Human-like timing: thêm jitter 100-500ms giữa action, thêm mouse curve thay vì click thẳng toạ độ.

Đạo đức: chỉ dùng các kỹ thuật này cho use-case hợp pháp — tự động hoá hệ thống chính công ty, test QA, hay truy cập trang public có permission. Dùng để qua mặt rate limit hoặc scrape trái phép là vi phạm Terms of Service và có thể chạm luật.

8. Observability: ClickHouse cho Browser Agent Telemetry

Tác vụ computer use sinh dữ liệu theo bản chất "stateful, long-running, multi-modal" — mỗi task có chuỗi 10-100 step, mỗi step có screenshot + tool call + tool result + thinking + cost. Chỉ lưu text JSON là đủ để debug tình huống đơn giản, nhưng cần cấu trúc chuyên biệt để phân tích pattern failure trên hàng triệu task. ClickHouse là lựa chọn hàng đầu nhờ nén cột cực tốt với screenshot metadata và khả năng truy vấn cross-tenant nhanh.

8.1. Schema ClickHouse cho browser agent traces

CREATE TABLE browser_agent_steps
(
    task_id         String,
    step_idx        UInt16,
    ts              DateTime64(3) CODEC(DoubleDelta, ZSTD(1)),
    org_id          UInt64,
    model           LowCardinality(String),
    action_type     LowCardinality(String),
    action_payload  String CODEC(ZSTD(3)),
    screenshot_hash FixedString(32),
    screenshot_url  String,
    dom_node_count  UInt32 CODEC(T64, LZ4),
    ax_node_count   UInt32 CODEC(T64, LZ4),
    thinking_tokens UInt32 CODEC(T64, LZ4),
    output_tokens   UInt32 CODEC(T64, LZ4),
    latency_ms      UInt32 CODEC(Delta, LZ4),
    cost_usd        Float32,
    url             String,
    url_domain      LowCardinality(String),
    success         UInt8,
    error_code      LowCardinality(String),
    retry_count     UInt8
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(ts)
ORDER BY (org_id, task_id, step_idx)
TTL ts + INTERVAL 60 DAY
SETTINGS index_granularity = 8192;

8.2. Truy vấn phát hiện failure pattern

Một câu hỏi quan trọng khi vận hành: "Trên domain nào agent hay fail, và ở action nào?"

SELECT
    url_domain,
    action_type,
    countIf(success=0) AS fail_count,
    countIf(success=0) / count() AS fail_rate,
    quantile(0.95)(latency_ms) AS p95_latency,
    avg(retry_count) AS avg_retry
FROM browser_agent_steps
WHERE ts >= now() - INTERVAL 7 DAY
GROUP BY url_domain, action_type
HAVING fail_count > 20
ORDER BY fail_rate DESC
LIMIT 30;

Kết quả cho biết domain nào đang "làm khó" agent — tín hiệu để điều chỉnh prompt chuyên biệt, thêm waiter, hoặc chuyển sang accessibility snapshot thay vì pixel.

8.3. Screenshot storage — Bài toán riêng

Screenshot 1920×1080 PNG trung bình ~300KB, một task 40 step đã ~12MB. Với 10 nghìn task/ngày, đó là 120GB/ngày thô. Không nên lưu nguyên ảnh vào ClickHouse. Pattern chuẩn: (a) upload screenshot lên S3/MinIO với key theo {org}/{yyyymmdd}/{task}/{step}.webp (WebP quality 75 nén ~50%), (b) ClickHouse chỉ lưu hash + URL, (c) lifecycle policy xoá screenshot sau 14-30 ngày cho task succeeded và 60-90 ngày cho task failed (để còn replay debug). Liên kết với bài LLM Observability 2026.

9. Multi-Agent patterns cho Computer Use

Một trong các nhầm lẫn phổ biến là cố nhét toàn bộ tác vụ "điều tra + lập kế hoạch + thực thi" vào một session Claude Opus 4.6 dài. Cách này tốn kém, khó debug, và dễ rơi vào reasoning loop. Đúng hơn: phân vai như Planner-Executor kinh điển.

graph TB
    U["User request"] --> P["Planner Opus 4.6 effort high"]
    P -->|"plan JSON steps"| O["Orchestrator"]
    O --> G["Guardrail Llama Guard URL allowlist"]
    G -->|"allow"| E1["Executor 1 Sonnet 4.6 computer use"]
    G -->|"allow"| E2["Executor 2 Haiku 4.5 DOM only"]
    G -->|"block"| R["Return error"]
    E1 --> V["Verifier Sonnet 4.6 judge"]
    E2 --> V
    V -->|"ok"| RES["Result"]
    V -->|"retry"| O
    style P fill:#e94560,stroke:#fff,color:#fff
    style G fill:#ff9800,stroke:#fff,color:#fff
    style V fill:#9b59b6,stroke:#fff,color:#fff
    style E1 fill:#4CAF50,stroke:#fff,color:#fff
    style E2 fill:#4CAF50,stroke:#fff,color:#fff

Hình 5: Pattern Planner-Executor-Verifier với Guardrail cho computer use

• Planner: Claude Opus 4.6 effort high — đọc mô tả goal, khảo sát sơ bộ trang đích (1-2 screenshot), chia task thành các bước đơn giản dạng "navigate X → fill form Y → submit → verify Z". Không thực thi action nào.
• Guardrail: layer kiểm tra URL đích nằm trong allowlist, goal không vi phạm policy (ví dụ không phải task bank transfer trái phép).
• Executor: Claude Sonnet 4.6 (hoặc Haiku cho task đơn giản DOM-only) chạy từng step với context ngắn — không cần biết toàn bộ plan, chỉ cần biết step hiện tại và goal nhỏ.
• Verifier: một agent judge riêng, nhận screenshot cuối + goal gốc, trả "done/retry/abort". Tách bạch kiểm tra khỏi thực thi giảm hallucination kiểu "tôi đã hoàn thành".

Pattern này có thêm hai lợi ích quan trọng: cost control (chỉ Planner và Verifier tốn thinking tokens cao, Executor chạy effort low), và khả năng resume (plan được persist; nếu executor fail ở step 12/20, chỉ cần chạy lại từ step 12).

10. An toàn và Authorization: Khi agent có bàn tay

Khác biệt lớn nhất giữa tool-use truyền thống và computer use là hậu quả của action lan sang ngoài : click "Place Order" trên Amazon tiêu tiền thật, click "Send" trên email gửi đi thật, click "Delete" trên Google Drive xoá thật. Một policy an toàn vững chắc phải có các lớp sau:

10.1. Action Authorization Matrix

Phân loại mọi action theo mức độ nguy hiểm và gắn policy authorization:

Orchestrator gắn một hook trước khi dispatch: nếu classifier phân loại action là High/Critical, dừng lại, gửi webhook tới user (Slack/email/SMS), chờ confirm token trước khi tiếp tục. Với Critical, agent chỉ preview — không được bấm nút thật.

10.2. Kill switch và rollback

Mỗi session phải có một kill switch hard: (1) một HTTP endpoint để ngắt session ngay lập tức, (2) timer global timeout (ví dụ 15 phút), (3) circuit breaker trên error rate (nếu >30% action fail trong 1 phút, ngắt). Rollback không phải lúc nào cũng làm được với UI (không phải app nào cũng có Ctrl+Z), nên cần ghi lại đầy đủ chuỗi action để con người reverse thủ công nếu cần.

10.3. Content filter cho screenshot

Một vấn đề tế nhị: screenshot chứa cả nội dung nhạy cảm (email cá nhân, số thẻ tín dụng, PHI y tế). Khi lưu trace, cần redact vùng nhạy cảm trước khi upload S3. Pattern: chạy một small model (Claude Haiku 4.5 hoặc tesseract + regex) detect PII pattern trong screenshot, phủ black box, rồi mới lưu. Với tác vụ banking, healthcare cần compliance nghiêm ngặt, chỉ lưu hash screenshot cho audit và xoá bản gốc sau khi task hoàn tất.

11. Benchmark: OSWorld, ScreenSpot, WebArena

Ba benchmark chính đo năng lực computer use agent năm 2026:

• OSWorld (Xie et al., 2024): 369 task đa dạng trên Ubuntu + app thực (LibreOffice, GIMP, VS Code, Firefox). Đo success rate end-to-end. Claude Opus 4.6 đạt 66.3%, là state-of-the-art tháng 4/2026.
• ScreenSpot / ScreenSpot Pro: đo grounding accuracy trên screenshot tĩnh — cho instruction "click nút X", model phải trả toạ độ đúng. ScreenSpot Pro khó hơn với app chuyên dụng.
• WebArena / VisualWebArena: 812 task web trên self-hosted Gitlab, Shopping, Reddit — đo khả năng hoàn thành nhiệm vụ web thực tế.
• Mind2Web: 2350 task từ 137 website thực, đo generalization cross-domain.

12. Phân tích chi phí và latency

Ba chi phí chính của một computer use task:

1. LLM tokens: mỗi step ~15-25K prompt tokens (ảnh ~1.5K, history ~10-15K, system ~2K) + ~500-2000 thinking/output tokens. Một task 30 step ≈ 600K prompt tokens + 30K output. Với Claude Sonnet 4.6 ở $3/1M input và $15/1M output + 90% cache hit, chi phí thực tế ~$0.40-0.80/task.
2. Infrastructure: session . BrowserBase ~$0.08/session hour, Claude Managed Agents $0.08/session hour. Task 10 phút ≈ $0.013.
3. Storage: screenshot S3 ~$0.002/task (10MB × $0.02/GB/month × 10 task × 30 ngày).

Tổng ~$0.45-0.82/task cho workload "medium" (điền form web đa bước). Cao hơn 10-20 lần so với tool-use truyền thống dùng API Stripe/GitHub, nhưng vẫn rẻ hơn nhiều so với thuê người nếu tác vụ lặp đi lặp lại. Các đòn bẩy tối ưu:

• Cache screenshot hash: nếu screenshot giữa 2 step giống hệt, reuse kết quả perception thay vì gọi lại VLM.
• Hybrid model tiering: dùng Claude Haiku 4.5 cho 70% step đơn giản (click vào element đã biết), chỉ gọi Opus cho step "nhìn và quyết".
• DOM-first khi có thể: accessibility snapshot ~500 tokens, screenshot ~1500 tokens. Ưu tiên AX tree, fallback pixel chỉ khi cần.
• Pre-warmed pool: giảm cold start từ 1.5s xuống ~0ms.
• Prompt cache: system prompt + tool spec không đổi giữa step — cache 5 phút giảm 90% input cost.

13. Timeline tiến hoá Computer Use Agents

14. Kết luận: Khi AI có bàn tay, System Design càng quan trọng

Computer Use không phải "phép màu" biến mọi phần mềm cũ thành agent-ready. Thực chất, đó là một lớp adapter phổ quát cho phép LLM tương tác với bất kỳ UI nào — nhưng đi kèm đó là trách nhiệm System Design nặng nề: perception pipeline ba trường phái, orchestration ba tầng, session pool, vault, guardrail, observability, authorization matrix, và cost control. Một team chỉ cần Claude SDK và Playwright có thể demo trong vài giờ, nhưng đưa lên phục vụ thật đòi hỏi cùng kỹ năng hạ tầng như bất kỳ hệ distributed system nào.

Bài học cốt lõi của 2026: Computer Use là cây cầu chứ không phải đích đến. Nó bù đắp cho phần lớn phần mềm chưa có API, nhưng bất cứ khi nào có API thì vẫn nên ưu tiên API. Một agent trưởng thành biết khi nào gọi REST, khi nào gọi MCP, khi nào mới "xắn tay" điều khiển chuột — đúng như triết lý "deterministic tool selection" mà Claude Code áp dụng.

15. Nguồn tham khảo

• Anthropic — Computer use tool (Claude API Docs)
• Anthropic — Claude Managed Agents overview
• Microsoft Research — OmniParser V2: Turning Any LLM into a Computer Use Agent
• OmniParser for Pure Vision Based GUI Agent (OpenReview)
• SeeClick: Harnessing GUI Grounding for Advanced Visual GUI Agents (arXiv)
• Awesome GUI Agent — curated list of papers and resources
• Awesome Computer Use (trycua/acu) — AI agents for Computer Use
• Gelato — Building a Strong Grounding Model for Computer-Use Agents (mlfoundations)
• browser-use — Open-source library for AI browser agents
• Playwright MCP — Microsoft's MCP server for Playwright
• Chrome DevTools MCP — Google's MCP for Chrome DevTools Protocol
• Digital Applied — Claude Computer Use: Production Deployment Guide
• rtrvr.ai — DOM Intelligence Architecture: Why Screenshots Reduce Performance
• The New Stack — Claude Managed Agents: Anthropic wants to run your AI agents for you
• OSWorld — Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments
• ClickHouse — The three villains to agentic observability