Khi giao thao tác trình duyệt cho MCP, quy trình làm việc thay đổi ra sao và phần nào biến mất khỏi mã? Bài viết thực tế này trình bày cách phân chia trách nhiệm, bốn lỗi cấu hình thường gặp và thứ tự kiểm tra khi gặp sự cố.
Khi dùng Claude Code để viết tự động hóa trình duyệt, phần gây mệt mỏi đầu tiên thường là glue code: khởi động trình duyệt, gắn proxy, tạo environment và chờ handle. Những việc này không liên quan trực tiếp đến business logic nhưng vẫn phải viết đi viết lại. Khi chuyển thao tác trình duyệt sang MCP, phần này gần như biến mất khỏi mã. Bạn chỉ cần mô tả việc cần làm, còn mô hình sẽ tự quyết định gọi tool nào.
Phân chia trách nhiệm như thế nào
Claude Code là trợ lý lập trình trên command line, có thể đọc và ghi file, chạy lệnh và làm việc với Git. Điểm mạnh của nó nằm ở code và terminal. Tương tác trực tiếp với browser không phải sở trường và cũng không nên là trách nhiệm của nó.
MCP bù đúng phần còn thiếu đó. Nó đóng gói khả năng của browser automation environment thành một bộ tools mà mô hình có thể gọi sau khi đăng ký: liệt kê environment, tạo environment, khởi động và dừng browser, chụp screenshot và đọc nội dung trang. Một bên quản lý code và logs, bên kia quản lý browser và pages. Khi ranh giới rõ ràng, việc xác định nguyên nhân sự cố cũng dễ hơn.
Workflow thay đổi như thế nào
Thay đổi rõ nhất là tốc độ dựng toàn bộ chain. Trước đây, mỗi lần đổi flow đều phải sửa script. Bây giờ có thể thử trước bằng ngôn ngữ tự nhiên: liệt kê các environment hiện có, đăng nhập trên hai environment rồi chụp screenshot và tổng hợp kết quả. Khi luồng chạy ổn, mới cố định nó thành script.
Trong dự án thực tế, thường có ba layer phối hợp. MCP nhận natural-language instructions, phù hợp cho exploration và tác vụ tạm thời. Local HTTP API xử lý bulk actions, chẳng hạn tạo hàng chục environment trong một lần, ổn định và dễ retry. Những tương tác chi tiết hơn, như chờ một state cụ thể xuất hiện hoặc lấy structured data từ trang, có thể giao cho CDP kết nối trực tiếp với browser. Ba cách này không xung đột; mỗi cách phụ trách một phần của workflow.
Việc quản lý riêng environment layer cũng là điều trở nên rõ ràng ở giai đoạn này. Khi environment nằm rải rác trong nhiều script, số lượng task càng tăng thì việc tìm lỗi càng khó. Hiện tại, environment-level tools được dùng để tạo, xem và reclaim theo lô một cách tập trung, còn script chỉ nhận một environment ID để sử dụng. Trong kịch bản nhiều tài khoản, giải pháp cách ly như PurpleMark đảm nhiệm đúng layer này: tách riêng environment, session và cache của từng tài khoản để execution layer có thể lên lịch ổn định.
Bốn điểm dễ gặp trục trặc
Điểm thứ nhất là tool không được nhận diện. Phần lớn client chỉ đọc configuration một lần khi khởi động, vì vậy đăng ký xong mà không restart thì thường không có hiệu lực. Dùng sai path của configuration file cũng khá phổ biến vì mỗi tool đặt file ở vị trí khác nhau. Một cách kiểm tra đơn giản nhưng hiệu quả là khởi động service thủ công. Nếu service chạy được, vấn đề có khả năng nằm ở configuration; nếu không chạy được, vấn đề nằm ở environment.
Điểm thứ hai là authentication thất bại. Nguyên nhân phổ biến nhất là khi copy credential đã vô tình mang theo space hoặc newline. Hãy kiểm tra điều này trước, sau đó xem cách environment variables được đọc. Kết quả có thể khác nhau tùy operating system và cách launch.
Điểm thứ ba là local API không chạy. Nhiều MCP service phụ thuộc vào việc chính client application phải đang mở. Nếu client không chạy, service có thể không khởi động hoặc connection bị timeout. Cũng cần kiểm tra port có đang bị chiếm hay không; process cũ chưa thoát hẳn có thể vẫn giữ port. Port number có thể xác nhận trong client settings.
Điểm thứ tư là concurrent tasks gây nhiễu lẫn nhau. Một task chạy riêng thì tốt, nhưng khi chạy nhiều task cùng lúc có thể xuất hiện dữ liệu lẫn lộn hoặc login session ghi đè lên nhau. Nguyên nhân thường là nhiều task dùng chung một environment. Loại vấn đề này không thể giải quyết chỉ bằng debugging mà cần quy tắc: mỗi task một environment, việc tạo và reclaim environment đi qua batch API, không tạo tạm thời trong script.
Một vài thói quen khi gỡ lỗi
Hãy nói rõ waiting condition trong instruction. Câu “bấm nút Gửi” chưa đủ thông tin. “Chờ đến khi nút Gửi có thể bấm rồi mới bấm” cho tỷ lệ thành công cao hơn rõ rệt. Mô hình quyết định cần làm gì, còn thời điểm phải chờ thì bạn cần chỉ ra.
Bắt đầu kiểm tra chain bằng các read-only task. Liệt kê environment, chụp screenshot và đọc page text không tạo side effect nhưng có thể kiểm tra authentication, network và service trong một lần. Khi chain chưa thông, đừng vội chạy các operation có side effect.
Không ghi credential vào code. Hãy dùng environment variables hoặc local configuration files và thêm các file đó vào ignore list; khi thành viên team thay đổi thì rotate credential. Nếu local API tắt validation của chính nó, tối thiểu phải bảo đảm nó chỉ listen trên máy local và không thể được truy cập từ bên ngoài.
Cuối cùng là ranh giới: MCP kết nối technical chain nhưng không thay đổi quy tắc của platform. Dù integration có trơn tru đến đâu, tác vụ vẫn phải tuân thủ mọi terms of service áp dụng.
