Tiêu chuẩn chọn fingerprint browser cho AI Agent đã thay đổi — và BitBrowser đang ở một vị trí khá thú vị

Nếu bạn vẫn đang dùng puppeteer-extra-plugin-stealth để “nuôi” AI Agent, đến một lúc nào đó Agent sẽ gặp một trong hai kiểu thất bại rất khó chịu. Kiểu thứ nhất: Agent đứng im trước một trang có Cloudflare, không đi tiếp được. Kiểu thứ hai: Agent “click thành công” vào một phần tử, nhưng phần tử đó thực ra nằm sau một modal popup hoặc ngoài vùng nhìn thấy, nên hành động diễn ra mà không có tác dụng thật. Hai kiểu lỗi này trông khác nhau, nhưng cùng chỉ về một thay đổi: fingerprint browser không còn là công cụ để con người quản lý nhiều tài khoản, mà đang trở thành hạ tầng danh tính cho Agent gọi vào. Và khi vai trò thay đổi, tiêu chuẩn chọn công cụ cũng phải thay đổi theo.

Hai lớp thay đổi, không phải một

Lớp thứ nhất nằm ở cách chống bị phát hiện. Các plugin stealth kiểu cũ hoạt động bằng cách chèn JavaScript vào trang trước khi code của trang chạy, sửa navigator.webdriver, thêm nhiễu Canvas, đổi thông số WebGL. Cách này đủ dùng vào năm 2023, nhưng đến 2026 thì đã mất hiệu lực một cách có hệ thống. puppeteer-extra-plugin-stealth không có cập nhật thực chất nào kể từ tháng 3/2023 — lần commit gần nhất chạm vào plugin này là ngày 1/3/2023, dù repository cha vẫn có một commit vào tháng 7/2024 nhưng không liên quan đến plugin. Trong khi đó, đến tháng 9/2026 nó vẫn có 238 issue mở, 41 issue liên quan trực tiếp đến bị phát hiện và 18 issue nhắc đến Cloudflare — dù npm vẫn ghi nhận hơn 830.000 lượt tải mỗi tuần. Các lớp phòng thủ như Cloudflare, DataDome hay PerimeterX đã chuyển trọng tâm từ “bạn khai báo mình là ai” sang “runtime của bạn hành xử như thế nào”: dấu vết CDP, fingerprint TLS, và sự không nhất quán giữa những gì Canvas/WebGL khai báo với những gì thực sự được thực thi. Chèn JavaScript có thể sửa lời khai, nhưng không sửa được đường đi thực thi bên dưới của engine.

Lớp thứ hai nằm ở cách Agent tương tác với trang. LLM không giỏi CSS selector, đặc biệt khi trang có shadow DOM, iframe chéo domain, hoặc class name sinh động. Các MCP server mới cho Agent thường chuyển sang mô hình snapshot-and-ref: Agent xin một bản snapshot của accessibility tree, mỗi phần tử tương tác được trả về một handle ổn định, rồi Agent dùng handle đó để click hoặc nhập liệu. Đây là thay đổi về giao diện nhận thức, không chỉ là thay đổi về fingerprint.

Điểm cần nhấn mạnh: hai lớp này độc lập với nhau. Một browser có thể rất giỏi ở lớp chống phát hiện nhưng vẫn khiến Agent thất bại vì accessibility tree nghèo nàn. Ngược lại, một browser có giao diện Agent tốt vẫn có thể bị chặn ngay từ cửa nếu fingerprint lộ. Chọn công cụ chỉ dựa trên một trong hai lớp là cách chọn thiếu.

Vì sao các giải pháp “vá từ bên trong trang” không còn đủ

Có một chi tiết kỹ thuật đáng để dừng lại. Khi một plugin stealth sửa webgl.vendor thành “Intel Inc.” trên mọi máy, nó tạo ra một mâu thuẫn không thể che giấu: trang vẽ một scene WebGL và đọc lại pixel sẽ thấy output của GPU thật, hoặc của SwiftShader trong môi trường headless, nằm cạnh một chuỗi khai báo “Intel GPU”. Detector không cần tìm một cờ cụ thể; nó chỉ cần so sánh hai nguồn thông tin độc lập và thấy chúng không khớp.

Đây là lý do các giải pháp MCP stealth browser mới chọn con đường khác: vá ở tầng engine hoặc source code, không chèn JavaScript runtime. CloakBrowser dùng Chromium đã được patch ở mức C++ và công bố vượt Cloudflare Turnstile, reCAPTCHA v3, FingerprintJS cùng hơn 30 dịch vụ phát hiện khác mà không cần inject JS. EyeBrowse đi theo hướng tương tự nhưng ở tầng MCP server, và backend của nó có thể là Camoufox — một Firefox fork với fingerprint伪装 ở mức C++ engine. CamoFox, xét cho chính xác về mặt kiến trúc, là một browser engine/fingerprint tool, và nó được đưa đến Agent thông qua một MCP server như EyeBrowse, chứ không tự thân là một MCP server. zendriver-mcp lại là một hướng độc lập khác. Điều này không có nghĩa là các giải pháp cũ “vô dụng hoàn toàn”, nhưng nếu mục tiêu là Agent chạy ổn định trên các trang có phòng thủ thương mại, lớp stealth dựa trên injection đang ngày càng giống một khoản nợ kỹ thuật hơn là một giải pháp.

BitBrowser xuất hiện ở đâu trong bức tranh này

BitBrowser không được thiết kế như một “stealth browser chuyên đối đầu Cloudflare”. Nó giải quyết một bài toán khác, và chính vì giải quyết bài toán khác nên nó lại trở nên liên quan trong bối cảnh Agent.

Từ phiên bản 7.1.5, BitBrowser có một MCP server cục bộ. Chuỗi vận hành có thể mô tả ngắn gọn: AI client → MCP → MCP server cục bộ của BitBrowser → Local API → browser profile → trang hoặc ứng dụng được phép. Nói cách khác, Agent không nhất thiết phải tự mở một browser trần rồi tự lo mọi thứ. Agent có thể yêu cầu BitBrowser tạo profile, mở profile, gán proxy, đổi fingerprint, nhóm profile, hoặc thậm chí quản lý cloud phone — tất cả bằng ngôn ngữ tự nhiên, thông qua các tool mà MCP server công bố.

Giá trị cốt lõi của BitBrowser trong workflow Agent không nằm ở việc nó “giỏi vượt Cloudflare hơn” các stealth browser chuyên dụng. Nó nằm ở chỗ mỗi profile là một môi trường danh tính tách biệt: cookie riêng, localStorage riêng, proxy riêng, extension riêng, fingerprint riêng. Khi Agent xử lý nhiều tác vụ, nhiều tài khoản hoặc nhiều thị trường khác nhau, việc giữ các ngữ cảnh này không trộn lẫn là một yêu cầu vận hành, không phải một tính năng phụ. Một team QA có thể dành một profile cho kiểm thử localization ở Đức, một profile khác cho nghiên cứu thị trường ở Mỹ, và Agent mở từng profile theo lịch mà không sợ session của phiên này rò rỉ sang phiên khác.

Có một dự án MCP độc lập tên antidetect-browser-mcp cho thấy cách** BitBrowser** được dùng trong thực tế: nó chạy Playwright bên trên profile BitBrowser và thêm ba lớp stealth — fingerprint phần cứng của BitBrowser (WebGL, Canvas, Audio, WebRTC), lớp playwright-stealth cho các thuộc tính automation, và lớp hành vi (chuột Bezier, gõ phím có độ trễ và đôi khi có lỗi chính tả, RNG nhất quán theo persona). Dự án này không tuyên bố BitBrowser tự nó là stealth browser mạnh nhất; nó dùng BitBrowser làm nền tảng profile và bổ sung lớp hành vi bên trên. Đó là một cách định vị trung thực và thực dụng.

Một ví dụ khác đáng chú ý: một người dùng vận hành 20 ví crypto trên Variational, mỗi ví một profile BitBrowser, và một AI Agent mở từng profile một qua MCP, không ký giao dịch, chỉ duy trì trật tự và kiểm tra trạng thái. Trong trường hợp này, yêu cầu không phải là “vượt qua Cloudflare của Variational”; yêu cầu là không để lẫn lộn 20 danh tính và 20 phiên đăng nhập. BitBrowser đáp ứng đúng điểm đó.

Cách nhìn thực dụng khi chọn công cụ Nếu Agent của bạn chủ yếu làm việc trên các trang có phòng thủ mạnh, nơi việc bị chặn là rủi ro số một, thì lớp chống phát hiện ở tầng engine/source là điều kiện tiên quyết. Trong trường hợp đó, các MCP stealth browser như CloakBrowser hay EyeBrowse đáng để đánh giá trước, vì chúng được thiết kế cho chính bài toán đó. Cần phân biệt rõ: Camoufox là engine/fingerprint tool đứng sau một MCP server, zendriver-mcp là một hướng tiếp cận độc lập — cả hai đều đáng tham khảo nhưng không nằm cùng một tầng kiến trúc với CloakBrowser hay EyeBrowse.

Nhưng nếu Agent của bạn cần vận hành nhiều danh tính, nhiều phiên, nhiều proxy trong một thời gian dài, và việc giữ cho các ngữ cảnh không trộn lẫn quan trọng ngang với việc vượt qua một lần kiểm tra bot, thì BitBrowser giải quyết một phần bài toán mà các stealth browser thuần túy không giải quyết: quản lý profile như hạ tầng, với Local API và MCP để Agent điều khiển. Nó không hứa hẹn thay thế một stealth browser chuyên dụng, nhưng nó cung cấp một thứ khác — sự tách biệt có thể dự đoán được giữa các danh tính.

Và có một điểm cuối cùng cần giữ trong đầu: fingerprint browser chỉ giải quyết lớp “danh tính”. Nó không giải quyết lớp “nhận thức”. Một Agent có thể đi qua cửa bằng một profile hoàn hảo, rồi vẫn thất bại vì trang đó có accessibility tree quá kém để Agent hiểu được nút nào thực sự click được. Chọn công cụ cho Agent nên bắt đầu bằng việc tách hai lớp này ra, đánh giá từng lớp theo nhu cầu thật của workload, rồi mới quyết định có cần một giải pháp tích hợp cả hai hay không. BitBrowser, ở phiên bản 7.1.5, là một mảnh ghép đáng cân nhắc cho lớp thứ nhất — với điều kiện bạn không kỳ vọng nó tự động giải quyết lớp thứ hai.