Agent của bạn có hai Playwright: một để kiểm thử, một để xem giao diện có đúng không

Một tác giả vừa đếm lại toàn bộ lần gọi trình duyệt của agent trong một tháng. Con số là 1.929 lần gọi, trải qua 62 phiên làm việc. Hầu hết trong số đó không chạy bộ kiểm thử nào cả.

Tác giả là Chirag Aggarwal, làm việc trên Appwrite, một nền tảng mã nguồn mở. Anh dùng Claude Code, một công cụ lập trình bằng AI. Công cụ này điều khiển trình duyệt qua Playwright MCP. MCP ở đây là cổng kết nối cho phép AI ra lệnh cho trình duyệt thật. Bài viết này kể lại phép đếm của anh, và rút ra cách dùng đúng cho từng loại Playwright.

Hai việc khác nhau của cùng một trình duyệt

Bộ kiểm thử trả lời một câu hỏi. Có thứ gì từng chạy tốt nay bị hỏng không. Nó chạy không giao diện trong CI, tức hệ thống tích hợp liên tục. Nó gần như xác định trước kết quả. Nó không quan tâm giao diện trông ra sao.

Trình duyệt qua MCP trả lời một câu hỏi khác. Thứ vừa làm ra trông có đúng không. Chưa ai viết kiểm thử cho câu hỏi này. Một giờ trước, thứ đó còn chưa tồn tại. Agent mở trình duyệt thật, vào trang, bấm thử, đọc lại nội dung và chụp ảnh màn hình.

Hai câu hỏi này cần hai cách quản lý khác nhau. Gộp chúng thành một công cụ là cách hiểu sai phổ biến nhất.

Con số nói lên điều gì

Trong 1.929 lần gọi, agent điều hướng 372 lần và chụp ảnh 332 lần. Agent đọc trang 304 lần và bấm 247 lần. Agent chạy mã không an toàn trong trang 188 lần. Agent chờ 160 lần và chụp nhanh trạng thái trang 120 lần.

Chia theo mục đích, bức tranh còn rõ hơn. Kiểm chứng giao diện, tài liệu hay bản phát hành chiếm 34 phiên và 1.209 lần gọi. Việc vặt trong các ứng dụng đã đăng nhập chiếm 23 phiên và 553 lần gọi. Nghiên cứu chiếm 5 phiên và 167 lần gọi.

Gần hai phần ba công việc là kiểm chứng. Trong các phiên kiểm chứng, ảnh chụp màn hình là thao tác phổ biến nhất. Agent chụp 281 ảnh, so với 226 lần điều hướng. Trong số các lần điều hướng đó, 209 lần đi tới máy local. Agent không lướt web. Agent đang nhìn thứ nó vừa làm ra.

Agent đọc trang chủ yếu bằng cách đọc, không phải chọc ngoáy. Trong các lần đọc trang, 175 lần dùng cách chọn nhiều phần tử cùng lúc. Có 151 lần đọc nội dung chữ trong trang. Một số ít lần đổi lớp giao diện tối để ảnh tiếp theo hiện chủ đề còn lại.

Ba lần kiểm chứng đáng nhớ

Lần thứ nhất bắt đầu từ một câu nói ngắn. Tác giả gửi ảnh chụp màn hình và viết: logo trông lệch, tìm nguyên nhân. Vấn đề là logo đen nằm trên thẻ gần như đen. Tệp logo vốn đúng, vì mọi logo chính thức đều đen trên nền trong suốt. Thành phần giao diện của chợ ứng dụng đã xử lý việc này. Nó đặt logo lên ô màu nhạt và đảo màu ở chế độ tối. Các màn hình xin phép đăng nhập (OAuth) thì không dùng thành phần đó.

Cách sửa là đưa logo vào một thành phần chung. Sau đó agent kiểm tra thêm các ứng dụng OAuth khác. Năm ứng dụng đó là Claude Code, Cursor, Codex, Claude Desktop và Gemini CLI. Nó dùng đường dẫn xem trước để dựng màn hình đồng ý và màn hình kết quả cho năm ứng dụng. Nó làm ở chế độ tối rồi làm một lượt ở chế độ sáng. Việc này tốn 19 lần gọi và cho ra tám ảnh chụp. Không kiểm thử nào trong bộ kiểm thử bắt được lỗi này. Không kiểm thử nào kiểm tra logo có nhìn thấy trên nền của nó hay không.

Lần thứ hai liên quan tới ảnh đại diện khi chia sẻ bài viết lên X. Bài thông báo về passkeys chỉ hiện khung xám. Nguyên nhân là ảnh bìa dùng định dạng AVIF. X chỉ hiển thị JPG, PNG, WEBP và GIF cho thẻ chia sẻ. Toàn bộ 538 ảnh bìa trong kho đều là AVIF.

Cách sửa là thêm một đường dẫn chuyển ảnh bìa sang JPEG. Đường dẫn này chỉ phục vụ thẻ chia sẻ. Sau đó agent dựng hai trang nhỏ mô phỏng thẻ chia sẻ trước và sau khi sửa. Nó đổi kích thước trình duyệt bằng đúng kích thước thẻ rồi chụp ảnh từng trang. Lần thử đầu thất bại vì Playwright MCP chặn địa chỉ file local. Agent phải phục vụ trang qua HTTP local thì mới chụp được.

Sau đó bộ kiểm thử mới vào cuộc. Bot review nêu hai vấn đề. Một kiểm tra kiểu bị hỏng vì đường dẫn mới. Bốn job kiểm thử đầu cuối chạy xong. Khi cả 20 lần kiểm tra đều xanh, bản sửa mới sẵn sàng. Cả hai Playwright đều có mặt trong cùng một PR. Một bên cho người review thấy thứ đã đổi. Bên còn lại cho thấy không thứ gì khác bị đổi theo.

Lần thứ ba là kiểm thử bản phát hành 2.3.0. Đây là phiên lớn nhất trong tháng với 183 lần gọi. Agent dựng bản 2.3.0 trên máy local. Nó cài bản 2.2.0 trong một dự án riêng để dữ liệu dev không bị ảnh hưởng. Nó nạp dữ liệu mẫu rồi nâng cấp.

Lệnh migrate báo lỗi. Các dự án đã tồn tại không nhận được nhóm dữ liệu mới (collection) tên pushLedger. Sau khi sửa lỗi đó, agent phát hiện thêm một khoảng trống. Các chủ đề đã tồn tại thiếu ba trường mới là qos, expiry và sequence. Cả hai bản sửa đều đi kèm kiểm thử hồi quy. Cả hai đều vào nhánh phát hành trước khi ai nâng cấp.

Công bằng mà nói, trình duyệt không tìm ra lỗi migrate. Lệnh migrate thoát với mã lỗi mới là thứ báo lỗi. Trình duyệt chỉ đi từng màn hình của bản nâng cấp và đối chiếu từng tuyên bố trong ghi chú phát hành. Nhưng không kiểm thử nào trong bộ kiểm thử chạy thử một lần nâng cấp. Trước đây, kiểm thử bản phát hành là công việc kiểm thử thủ công. Nay nó là công việc kiểm thử thủ công giao cho agent.

Một trường hợp tương tự xảy ra sau bản 2.4.0. Có người phản ánh trình nâng cấp bỏ qua cổng tùy chỉnh. Agent cài một hệ thống trên cổng 8080 và 8443, bật HTTPS. Nó mở trình nâng cấp và chụp ảnh nó đang đề xuất cổng 80, 443 và tắt HTTPS. Sau khi sửa lỗi, nó chụp lại cùng một ảnh. Không ai viết kiểm thử cho loại lỗi này trước khi nó cắn mình.

Ảnh chụp màn hình là bằng chứng cho người review

Thói quen đáng giá nhất trong bài là đưa ảnh vào mô tả yêu cầu hợp nhất mã (PR). Người review không chạy được nhánh của bạn. Nhưng họ nhìn được ảnh.

Quy trình có bốn bước. Agent kiểm tra thay đổi bằng Playwright MCP. Agent lưu mỗi ảnh dưới cái tên nói rõ ảnh chụp gì. Trong 332 ảnh của tháng, 317 ảnh có tên kiểu này. Agent viết mô tả PR kèm liên kết ảnh tương đối. Agent dùng lệnh đính kèm của công cụ dòng lệnh GitHub để tải ảnh lên. Cuối cùng, agent xóa thư mục tạm và các ảnh PNG lẻ để chúng không bị commit vào kho.

Cách đính kèm này quan trọng hơn vẻ ngoài. Trước đây, tác giả đưa ảnh lên bằng ba cách. Một cách là commit ảnh vào nhánh mồ côi rồi liên kết tới đó. Một cách là commit ảnh thành tài nguyên tài liệu. Cách còn lại là đính kèm. Một người review đã chỉ ra vấn đề của cách đầu tiên. Ảnh bằng chứng biến mất sau khi merge. Nguyên nhân là nhánh chứa ảnh bị xóa theo hướng dẫn. Tệp đính kèm thì ở lại.

Con số trung thực là 53 PR có ảnh trên tổng số 904 PR. Tỷ lệ phụ thuộc vào kho. Trong hai kho Appwrite công khai, kho vibes có 11 trên 39 PR kèm ảnh. Kho appwrite có 25 trên 224 PR kèm ảnh. Kho nặng về backend có tỷ lệ thấp hơn, và điều đó phần nào là hợp lý. Nhiều PR backend không có gì để nhìn.

Nhưng còn một lý do kém đẹp hơn. Tác giả phải nhắc agent bằng tay khoảng 30 lần trong tháng. Các câu nhắc đều dạng yêu cầu thêm ảnh trước và sau vào mô tả PR. Thói quen chỉ xảy ra khi anh nhớ gõ câu nhắc. Vì vậy anh viết nó thành quy tắc chung. Quy tắc nằm trong tệp CLAUDE.md toàn cục của anh. Từ đó, agent tự kiểm chứng và tự đính kèm ảnh mà không cần được nhắc.

Ba giới hạn phải nhớ

Giới hạn thứ nhất là tỷ lệ lỗi. Khoảng 10 phần trăm lần gọi trả về lỗi, tức 195 trên 1.929 lần. Nguyên nhân lớn nhất rất đời thường. Trình duyệt hoặc thẻ đã đóng chiếm 36 lần. Mã cố đọc tệp ngoài vùng cát chiếm 25 lần. Chờ trang hoặc phần tử quá lâu chiếm khoảng 30 lần. Có 4 lần báo trình duyệt đang được dùng, thường vì hai phiên song song muốn dùng chung một hồ sơ trình duyệt.

Giới hạn thứ hai là điện thoại gần như vắng mặt. Trong 45 lần đổi kích thước trình duyệt, chỉ một lần dùng khung nhìn điện thoại 390 nhân 844. Phần còn lại đều là máy tính để bàn. Đây là điểm mù, không phải chính sách có chủ ý.

Giới hạn thứ ba là ảnh chụp mặc định rơi vào kho. Theo mặc định, ảnh nằm trong thư mục tạm ở gốc kho. Nhiều phiên kết thúc với việc agent tự dọn dẹp. Ít nhất một phiên để ảnh rơi vào bản checkout chính thay vì worktree, tức bản sao làm việc riêng. Quy tắc dọn dẹp phải đi kèm quy tắc chụp ảnh.

553 lần gọi còn lại kể một câu chuyện khác

Hơn một phần tư số lần gọi không liên quan tới giao diện. Các ứng dụng là Help Scout, Brightspace của trường đại học, bảng điều khiển Google Cloud và AWS, và bảng điều khiển của một nhà cung cấp SMS. Đây là công cụ tác giả dùng hằng ngày mà không có API. Hoặc API đó không dành cho anh.

Mẫu làm việc luôn giống nhau. Tác giả tự đăng nhập trong cửa sổ trình duyệt. Agent chỉ đọc. Trình duyệt trở thành API cho phần mềm không cung cấp API. Tác giả nói rõ đây là chủ đề của một bài khác. Nhưng nó lý giải vì sao máy chủ trình duyệt vẫn được cài đặt ngay cả trong tuần không làm giao diện.

Quy tắc áp dụng ngay

Giữ bộ kiểm thử cho thứ không bao giờ được hỏng. Ảnh chụp màn hình là bằng chứng, không phải kiểm thử hồi quy. Dùng trình duyệt MCP cho câu hỏi mà bộ kiểm thử không hỏi được. Câu hỏi đó là: thứ này trông có đúng không.

Đặt tên mỗi ảnh theo đúng thứ nó chụp. Kiểm tra cả hai chủ đề sáng và tối. Đưa ảnh trước và sau vào mô tả PR dưới dạng tệp đính kèm. Đừng liên kết tới nhánh sẽ bị xóa. Viết quy tắc ra thành văn bản để thói quen không phụ thuộc vào trí nhớ của bạn.

Và đừng quên phần còn lại của phép đếm. Nếu agent của bạn cũng dùng trình duyệt để đọc các ứng dụng không có API, hãy ghi nhận riêng việc đó. Đó là một công cụ khác, với rủi ro khác. Đừng để nó lẫn vào câu chuyện kiểm thử giao diện.

Nguồn tham khảo

• Chirag Aggarwal, "My agent has two Playwrights", DEV Community, ngày 26/10/2026: https://dev.to/chiragagg5k/my-agent-has-two-playwrights-5e6g.
• Mọi con số trong bài đều lấy từ bản ghi phiên làm việc của chính tác giả, không phải số liệu đo độc lập. Các tuyên bố về sản phẩm của bên thứ ba được ghi rõ là theo lời tác giả.