Playwright MCP: điều khiển trình duyệt bằng AI Agent (Model Context Protocol)

1. MCP là gì và vì sao nó quan trọng với kiểm thử

Model Context Protocol (MCP) là một giao thức mở cho phép mô hình ngôn ngữ lớn kết nối với các 'công cụ' bên ngoài theo cách chuẩn hoá. Playwright MCP là một server MCP đóng gói khả năng của Playwright thành tập công cụ mà mô hình như Claude, GPT hay Gemini có thể gọi: mở trang, bấm nút, gõ chữ, đọc nội dung. Nói cách khác, thay vì bạn viết script, bạn ra chỉ dẫn tiếng Anh (hoặc tiếng Việt) và mô hình tự dịch thành hành động trên trình duyệt.

Với người kiểm thử, MCP mở ra kiểu làm việc mới: kiểm thử khám phá bằng ngôn ngữ tự nhiên, tái hiện bug nhanh, dựng nháp test từ mô tả. Nhưng nó cũng mang theo những vấn đề đặc thù của AI: tính không tất định và nguy cơ hallucination. Bài này đi sâu cả hai mặt — sức mạnh và ranh giới an toàn — để bạn dùng MCP đúng chỗ.

Điều làm MCP khác với những nỗ lực 'AI điều khiển máy tính' trước đây là nó không dựa vào ảnh chụp màn hình để đoán vị trí. Nhiều hệ thống computer-use đời đầu chụp màn hình rồi để mô hình đoán toạ độ click — cách này chậm, tốn, và cực giòn. MCP đi đường khác: mô hình làm việc với biểu diễn ngữ nghĩa của trang (cây accessibility), giống cách một lập trình viên viết Playwright chọn phần tử theo vai trò và tên. Nhờ vậy MCP vừa nhanh hơn, vừa đáng tin hơn, vừa dễ debug hơn vì mọi tool call đều minh bạch.

2. Kiến trúc: LLM → MCP server → trình duyệt

Luồng cơ bản gồm ba lớp. Mô hình (Claude/GPT/Gemini) nhận yêu cầu bằng ngôn ngữ tự nhiên và quyết định gọi công cụ nào. MCP server (@playwright/mcp) nhận lời gọi công cụ dạng JSON và dịch sang lệnh Playwright thật. Trình duyệt (Chrome for Testing từ v1.57) thực thi và trả về trạng thái. Điểm cốt lõi khiến MCP hiệu quả: phản hồi cho mô hình là cây accessibility dạng text (role, name, giá trị), không phải ảnh pixel.

// Khai báo Playwright MCP server cho một MCP client (ví dụ Claude Desktop)
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Vì mô hình 'nhìn' cấu trúc ngữ nghĩa thay vì pixel, nó chọn phần tử theo vai trò và tên có thể đọc (giống cách người dùng screen reader điều hướng). Cách này bền hơn với thay đổi giao diện thuần thẩm mỹ (đổi màu, đổi layout) và cũng chính là lý do accessibility tốt của ứng dụng lại giúp cả AI lẫn người khuyết tật.

3. Vì sao dùng accessibility tree, không dùng pixel

Điều khiển bằng pixel (chụp màn hình rồi đoán toạ độ) mong manh và tốn kém: ảnh nặng, mô hình dễ nhầm vị trí, và mỗi thay đổi CSS làm hỏng. Cây accessibility ngược lại là mô tả có cấu trúc: 'button tên Đăng nhập', 'textbox tên Email', 'heading tên Bảng điều khiển'. Mô hình đọc mô tả này gọn hơn nhiều, chọn phần tử chính xác hơn, và ít bị lệ thuộc vào hình thức trình bày.

# ARIA snapshot mà MCP trả cho mô hình (rút gọn) — mô hình chọn theo role/name
- banner:
  - link "Trang chủ"
  - navigation:
    - link "Sản phẩm"
    - link "Giỏ hàng"
- main:
  - heading "Bảng điều khiển" [level=1]
  - textbox "Email"
  - textbox "Mật khẩu"
  - button "Đăng nhập"
  - status "Đơn #1042 · PAID"   # từ v1.60: kèm bounding box toạ độ

Từ v1.60, ARIA snapshot còn kèm bounding box (toạ độ layout), giúp agent vừa có ngữ nghĩa vừa biết vị trí khi cần thao tác đòi hỏi toạ độ (kéo-thả, cuộn tới). Đây là sự dung hoà: mặc định dùng ngữ nghĩa cho bền vững, chỉ dùng toạ độ khi thật cần. Cách tiếp cận này giữ được cả độ tin cậy lẫn khả năng thao tác phức tạp.

// Bạn có thể xem chính cây a11y mà MCP đưa cho mô hình, để hiểu vì sao nó chọn phần tử
import { test, expect } from '@playwright/test';

test('kiểm chứng ARIA snapshot mà agent "nhìn"', async ({ page }) => {
  await page.goto('/login');
  // Snapshot ngữ nghĩa — đây là thứ mô hình đọc, không phải ảnh màn hình
  await expect(page.locator('body')).toMatchAriaSnapshot(`
    - textbox "Email"
    - textbox "Mật khẩu"
    - button "Đăng nhập"
  `);
  // Nếu accessibility kém (thiếu name), agent sẽ khó chọn đúng -> đây cũng là test a11y
});