Cloudflare ra mắt Kitesurf: Trình duyệt chuyên dụng cho AI Agent chạy trên nền tảng Workers

Chúng ta có nên tự xây dựng trình duyệt của riêng mình không? Đây là một trong những câu hỏi đã xuất hiện vài tháng một lần tại nội bộ Cloudflare trong nhiều năm qua. Không có gì ngạc nhiên khi đây là chủ đề khơi mào cho những chuỗi thảo luận dài với vô số lý do và lập luận thuyết phục về việc tại sao chúng ta nên làm điều đó. Trình duyệt rõ ràng là phần mềm quan trọng nhất mà chúng ta sử dụng hàng ngày trên máy tính; có thể nói đó chính là hệ điều hành của Internet. Chúng ta là một công ty với sứ mệnh xây dựng một Internet tốt đẹp hơn — ai mà chẳng muốn đón nhận thử thách xây dựng một trình duyệt mới chứ?

Nhưng chúng ta chưa bao giờ tìm thấy sự cân bằng giữa độ khó kỹ thuật của một nỗ lực như vậy và những vấn đề độc đáo mà chúng ta sẽ giải quyết khi thực hiện nó. Và thế là, ý tưởng này cứ bị gác lại hết lần này đến lần khác. Cho đến tận bây giờ.

Một điều kỳ diệu đã xảy ra: chúng ta đã đạt đến điểm bùng phát, nơi hàng loạt tiến bộ kỹ thuật mạnh mẽ trong Nền tảng Nhà phát triển (Developer Platform) của chúng ta trở thành hiện thực, đồng thời sự ra đời của các tác nhân AI (AI agents) và nhu cầu về một loại trình duyệt mới cũng trở nên cấp thiết cùng lúc.

Việc chạy WebAssembly (Wasm) trong Workers hiện đã rất hoàn thiện. Các thành phần cơ bản như dynamic workers, Durable Objects dựa trên SQLite, RPC giữa các worker, service bindings, khả năng tương thích NodeJS cao hơn và các giới hạn được nới rộng đã mở ra cánh cửa cho nhiều ứng dụng phức tạp và đầy tham vọng hơn mà trước đây đơn giản là không thể thực hiện được.

Browser Run, sản phẩm API tự động hóa trình duyệt không giao diện (headless browser) của chúng ta, đã chứng kiến sự tăng trưởng vượt bậc cùng với sự trỗi dậy của AI. Các tác nhân cần trình duyệt để thực hiện nhiều tác vụ, và trong nhiều trường hợp, chúng không thể thành công nếu thiếu chúng.

Nhưng có một vấn đề — các công cụ trình duyệt như Chromium được xây dựng cho con người, không phải cho các tác nhân, và chúng đi kèm với những chi phí vận hành (overhead) mà các mô hình AI không hề cần đến. Chúng tiêu tốn quá nhiều bộ nhớ và tài nguyên tính toán đến mức việc cung cấp cho mỗi tác nhân một phiên bản riêng là cực kỳ đắt đỏ, khiến phần lớn Web chỉ giới hạn cho các mô hình AI tinh vi và tốn kém nhất với kiến thức tham số cao hơn, đồng thời loại bỏ nhiều ứng dụng tác nhân khác.

Chúng ta nên cung cấp cho tất cả các tác nhân một trình duyệt vượt trội ở những gì quan trọng đối với mô hình AI, ngay cả khi điều đó có nghĩa là lược bỏ những thứ chỉ hữu ích cho con người. Ví dụ:

Đối mặt với những nhận thức này, 12 tuần trước chúng ta đã đặt lại câu hỏi: Chúng ta có nên xây dựng trình duyệt của riêng mình không? Lần này câu trả lời là nhất trí: Có!

Hôm nay, chúng tôi công bố Kitesurf, một trình duyệt mới chạy hoàn toàn trên nền tảng Workers mà chúng tôi xây dựng dành riêng cho các tác nhân, hiện đã có sẵn miễn phí trong giai đoạn beta trên Browser Run.

Kitesurf hiệu quả hơn đáng kể về mức tiêu thụ CPU và bộ nhớ so với Chromium đối với các tác vụ tác nhân phổ biến như chụp ảnh màn hình và trích xuất HTML. Sau đây là câu chuyện về cách chúng tôi đã xây dựng nó. Hãy thắt dây an toàn, nội dung sẽ khá kỹ thuật đấy — nhưng chúng tôi hứa sẽ giữ cho nó thật thú vị.

Khởi đầu như thế nào

Kitesurf bắt đầu giống như nhiều ý tưởng tuyệt vời khác tại Cloudflare. Ai đó tìm thấy điều gì đó thú vị, và điều tiếp theo bạn biết là họ kết thúc bằng việc "nerd sniping" (lôi kéo sự chú ý của những người đam mê kỹ thuật) phần còn lại của nhóm bằng một ý tưởng tưởng chừng như bất khả thi nhưng lại rất hấp dẫn.

Chúng tôi lấy cảm hứng ban đầu từ obscura, một công cụ không giao diện được viết bằng Rust cho tự động hóa AI với tiêu chí "không Chrome, không Node.js, không phụ thuộc".

Sau đó, với sự trợ giúp của một tác nhân AI, chúng tôi đã cố gắng chuyển nó sang Workers. Ban đầu nó không hoạt động tốt lắm. Nhưng một khi chúng tôi cung cấp cho AI một kế hoạch vững chắc và định nghĩa rõ ràng về sự thành công — đủ chi tiết để tác nhân có thể lặp lại vô tận và đặt câu hỏi khi cần — thì nó đã hoạt động. Bị choáng ngợp bởi bằng chứng khái niệm (proof of concept) (dù chỉ mới) hoạt động này, chúng tôi quyết định để cả nhóm bắt tay vào thực hiện.

Các quyết định thiết kế

Dưới đây là một số quyết định thiết kế mà chúng tôi đã đưa ra trước khi bắt đầu.

Kiểm thử, kiểm thử và kiểm thử

Chúng tôi biết rằng việc chuyển từ một nguyên mẫu sang một trình duyệt hoàn chỉnh có thể thực sự hữu ích cho các tác vụ ở quy mô sản xuất sẽ cần rất nhiều công sức và sự lặp lại. Chúng tôi sẽ không giấu giếm rằng việc sử dụng AI để tăng tốc quá trình này là chìa khóa. Nhưng làm thế nào để bạn sử dụng AI trong một dự án phức tạp như vậy mà vẫn kiểm soát được chất lượng của cả mã nguồn và kết quả mà không làm giảm tốc độ? Câu trả lời là cung cấp càng nhiều bài kiểm thử càng tốt.

Hãy đến với Web Platform Tests (WPT), thiết lập lý tưởng: một bộ tiêu chí thành công mở rộng cung cấp cho các tác nhân AI những cột mốc rõ ràng để đánh giá sự tuân thủ tính năng. Chúng tôi đã tuyển chọn việc lựa chọn và thứ tự các tính năng để giao cho các tác nhân, cho phép con người tập trung vào công việc kiến trúc và xem xét các phương pháp tiếp cận của AI.

Tuy nhiên, các bài kiểm thử WPT chỉ có giới hạn: chúng đo lường sự tuân thủ các tiêu chuẩn W3C, chứ không phải khả năng hiển thị và tương tác với các trang web thực tế của trình duyệt. Để thu hẹp khoảng cách này, chúng tôi đã triển khai kết hợp kiểm thử tích hợp và kiểm thử hồi quy hình ảnh — nó chạy các bài kiểm thử Puppeteer đa bước trên các trang web thực tế so sánh giữa Chromium và Kitesurf, không chỉ bằng cách so sánh các khẳng định mà nó đưa ra, mà còn so sánh kết quả hiển thị ở mỗi bước để làm nổi bật bất kỳ sự khác biệt không mong muốn nào.

Sử dụng Rust khi có thể

Cloudflare đã và đang nỗ lực cung cấp hỗ trợ tuyệt vời cho WebAssembly (Wasm) trong Workers từ khá lâu. Điều này rất tuyệt vì chúng ta có thể sử dụng các gói C, C++ và Rust hiệu năng cao và biên dịch chúng sang Wasm. Nếu chúng ta sử dụng Emscripten (ví dụ) và nhiều lớp phụ thuộc giả lập của nó, tệp nhị phân được biên dịch có thể trở nên cồng kềnh và chậm chạp.

Thay vào đó, chúng tôi chọn Rust thuần túy bất cứ khi nào có thể và biên dịch trực tiếp sang WebAssembly bằng wasm-bindgen, từ đó tránh các lớp giả lập không cần thiết và chạy gần với phần cứng nhất có thể, một cách đáng tin cậy.

Xử lý ngoại lệ

Một trình duyệt phải hiển thị toàn bộ web không đáng tin cậy và đôi khi đầy rẫy nguy hiểm mà không bao giờ làm rơi trang mà nó đang giữ, vì vậy xử lý ngoại lệ không chỉ là vấn đề vệ sinh mã nguồn — đó là cách ứng dụng tồn tại trước các dữ liệu đầu vào xấu mà không bị treo ngay lập tức.

Vì vậy, chúng tôi đã cam kết một quy tắc ngay từ đầu: bất kỳ lỗi nào cũng sẽ dẫn đến một khung hình trống hoặc một phần tử bị thiếu, không bao giờ là một phiên làm việc bị chết. Bắt lỗi tại mọi ranh giới, mặc định về trạng thái an toàn và trống rỗng, đồng thời ghi nhật ký đủ để chẩn đoán.

Sự cô lập

Trái ngược với việc chạy trình duyệt trên máy tính xách tay của bạn (nơi bạn truy cập các trang web bạn tin tưởng và việc chia sẻ một số tài nguyên giữa chúng là chấp nhận được), một tác nhân được hướng đến bất cứ nơi nào mà tác vụ yêu cầu: mã tùy ý từ các nguồn tùy ý.

Vì vậy, chúng tôi đã xây dựng trình duyệt này trên giả định rằng mỗi lần tải trang đều là dữ liệu đầu vào không đáng tin cậy và mỗi phiên làm việc đều bắt đầu mới hoàn toàn. Mỗi thành phần đều được cô lập và chỉ có quyền truy cập vào các tài nguyên cần thiết cho chức năng của nó.

Điều này có vẻ hoàn toàn phù hợp với Cloudflare Workers, nơi mô hình bảo mật được xây dựng dựa trên sự cô lập ngay từ thiết kế. Nhưng nền tảng chỉ cung cấp cho chúng ta ranh giới giữa các isolate. Chúng ta vẫn phải thực thi cùng nguyên tắc đó ở cấp độ ứng dụng, quyết định xem mỗi thành phần được phép chạm vào cái gì và đảm bảo không có gì rò rỉ sang trang mà nó không được phép.

Không trạng thái (Stateless) bất cứ khi nào có thể

Trạng thái là thứ khiến lỗi trở nên đắt đỏ — nếu không có gì để khôi phục, việc phục hồi sau sự cố chỉ đơn giản là bắt đầu một phiên mới và phát lại yêu cầu. Một thành phần không trạng thái có bản chất là dùng một lần và song song: tiêu diệt nó ngay khi nó bị đình trệ, chạy hàng nghìn cái cùng lúc và điều chỉnh quy mô theo nhu cầu thay vì giữ cho mọi thứ luôn hoạt động. Điều đó hoàn toàn phù hợp với tự động hóa, nơi tải đến theo đợt và việc rẻ nhất bạn có thể làm là khởi chạy công việc chỉ tốn những gì nó đã sử dụng và biến mất khi hoàn thành. Tóm lại, bất cứ nơi nào một thành phần có thể không trạng thái, nó nên như vậy.

Cách chúng tôi xây dựng nó

Được trang bị một kế hoạch tốt, các bài kiểm thử mở rộng và môi trường công cụ tốt, chúng tôi đã sẵn sàng bắt đầu vượt ra ngoài bằng chứng khái niệm ban đầu. Đây là vòng đời cấp cao của một yêu cầu trong Kitesurf mà vẫn còn đúng cho đến ngày nay:

Hãy cùng đi sâu vào ba thành phần chính giúp Kitesurf hoạt động: Engine, PageScript và PageRenderer.

Tìm nạp từ các nguồn gốc

Để hiển thị một trang web không đáng tin cậy, trình duyệt phải tìm nạp các tài nguyên tùy ý — hình ảnh, phông chữ, CSS, JavaScript và tệp Wasm — từ Internet. Đây là một trong những thao tác nguy hiểm nhất mà một trình duyệt có thể thực hiện.

Kitesurf thực hiện điều đó thông qua một thành phần duy nhất, worker SandboxOutbound, và không gì khác có thể chạm trực tiếp vào mạng — được thực thi bởi Dynamic Workers. Engine sử dụng nó để khởi động trang, tìm nạp tài liệu chính và các tập lệnh của nó, còn PageScript tìm nạp mọi thứ khác: tệp kiểu, hình ảnh, phông chữ và các lệnh gọi fetch của chính trang đó.

Chúng tôi sử dụng SandboxOutbound để thực thi CORS, chèn các tiêu đề giả lập trình duyệt, lọc phản hồi và giữ cookie của mỗi trang trong hũ riêng của chúng. Bất cứ thứ gì không vượt qua chính sách của chúng tôi sẽ nhận được mã 403 — mỗi thành phần nhận được chính xác mạng mà nó cần và không hơn không kém.