Không phải trình duyệt nào cũng cần có người nhìn

Giả sử mình thuê một người chạy xuống cửa hàng xem giá một chai nước.

Người đó chỉ cần:

• đi tới đúng chỗ,
• đọc cái giá,
• ghi lại con số,
• rồi quay về.

Nhưng vì một lý do rất con người, mình không đưa cho anh ta đôi dép.

Mình đưa luôn một chiếc ô tô.

Chiếc ô tô có máy lạnh, màn hình giải trí, sáu cái loa, camera lùi, ghế chỉnh điện, kính cách âm, Bluetooth, đèn nội thất và một đống thứ rất tuyệt vời.

Chỉ có điều anh ta đi cách nhà… 200 mét.

Nghe hơi ngáo.

Nhưng đó gần như là cách chúng ta đang cho AI agent truy cập Internet.

Khi một agent cần vào website, đọc vài dòng HTML, tìm một nút, điền một form hoặc chụp một screenshot, kiến trúc thường trông đại khái như sau:

1AI Agent
2    ↓
3Playwright / Puppeteer / CDP
4    ↓
5Chrome / Chromium
6    ↓
7Website

Chrome là một công trình kỹ thuật khổng lồ được xây để phục vụ con người.

Nó phải phát video.

Nó phải chạy WebGL.

Nó phải render font đẹp.

Nó phải cuộn trang mượt.

Nó phải chạy extension.

Nó phải có tab.

Nó phải xử lý webcam, microphone, GPU, audio, animation, accessibility, media codec, đồng bộ tài khoản và hàng nghìn thứ khác.

Nhưng con AI đang bò vào website để đọc giá một cái nồi cơm điện thì không quan tâm tab có bo góc đẹp hay không.

Nó chỉ muốn biết:

1Tên sản phẩm là gì?
2Giá bao nhiêu?
3Nút "Mua" nằm đâu?

Ngày 6 tháng 8 năm 2026, Cloudflare giới thiệu Kitesurf, một browser engine được xây theo một giả định khá thú vị:

Nếu người sử dụng trình duyệt không còn là con người thì tại sao chúng ta vẫn phải xây trình duyệt giống Chrome?

Kitesurf chạy hoàn toàn trên Cloudflare Workers bằng V8 isolates, không mang Chromium bên dưới, và được Cloudflare gọi là một browser “agent-first”. (The Cloudflare Blog)

Cái đáng quan tâm ở đây không chỉ là Kitesurf.

Cái đáng quan tâm là một lớp hạ tầng mới đang bắt đầu xuất hiện:

browser dành riêng cho AI agent.

Chúng ta đang dùng browser của con người cho robot

Playwright và Puppeteer bản thân chúng không phải vấn đề.

Playwright thậm chí đã có BrowserContext, cho phép tạo nhiều môi trường cô lập kiểu incognito bên trong cùng một browser process. Các context này khá nhẹ, có cookie, local storage và session storage riêng. Vì vậy không nên hiểu đơn giản rằng cứ một agent là phải khởi động một container Chromium hoàn toàn mới. (Playwright)

Trong production người ta có thể:

11 Chromium
2├── Browser Context A
3├── Browser Context B
4├── Browser Context C
5└── Browser Context D

hoặc giữ một pool browser đang nóng rồi phân phối task vào đó.

Nghe thì có vẻ giải quyết xong rồi.

Nhưng vấn đề bắt đầu xuất hiện khi hệ thống chuyển từ:

110 agent

sang:

110.000 agent

Một research agent có thể mở vài chục website.

Một shopping agent có thể kiểm tra hàng trăm sản phẩm.

Một crawler phục vụ RAG có thể cần render hàng triệu URL.

Một monitoring agent có thể thức cả ngày để xem giá, trạng thái đơn hàng, tài liệu kỹ thuật hoặc các trang JavaScript động.

Lúc đó Chrome không còn chỉ là một chương trình.

Nó trở thành một loại tài nguyên hạ tầng.

Bạn phải quan tâm:

• bao nhiêu browser chạy đồng thời,
• bao nhiêu RAM mỗi browser chiếm,
• CPU tiêu tốn bao nhiêu,
• browser chết thì làm sao,
• session nào cần giữ,
• cookie nằm đâu,
• task nào có thể retry,
• browser pool cần lớn bao nhiêu.

Và đây là chỗ Kitesurf đi theo một hướng khác.

Kitesurf: trình duyệt sinh ra rồi chết đi

Ý tưởng quan trọng nhất của Kitesurf không phải Rust.

Không phải WebAssembly.

Cũng không phải V8.

Mà là:

stateless whenever possible.

Cloudflare mô tả Kitesurf như một engine tạm thời, cô lập hoàn toàn, được sinh ra để tồn tại trong đúng thời gian thực hiện một task rồi có thể biến mất. (The Cloudflare Blog)

Kiến trúc tư duy chuyển từ:

1Agent
2    ↓
3Browser lâu dài
4    ↓
5nhiều task

sang:

1Task
2    ↓
3browser nhẹ xuất hiện
4    ↓
5đọc HTML / chạy JS / render
6    ↓
7trả kết quả
8    ↓
9browser biến mất

Nó giống ly giấy hơn là cái bình thủy.

Dùng xong bỏ.

Nếu một thành phần bị treo:

1kill

Nếu cần retry:

1tạo cái khác

Nếu đột nhiên có 1.000 task:

1tạo 1.000 execution environment

Xong việc thì giải phóng.

Trong hệ thống phân tán, state luôn là thứ làm mọi chuyện trở nên đau đầu.

Có state nghĩa là phải nghĩ tới:

• khôi phục,
• đồng bộ,
• migration,
• persistence,
• failover,
• locking.

Không có state thì triết lý đơn giản hơn nhiều:

Hỏng à? Vứt đi làm lại.

Hơi phũ.

Nhưng máy tính rất thích sự phũ phàng này.

Vì sao V8 isolate quan trọng?

Để hiểu Kitesurf, phải xuống thấp thêm một tầng.

Cloudflare Workers không tạo một virtual machine mới cho mỗi request.

Nó cũng không nhất thiết tạo một process hoàn chỉnh.

Workers sử dụng V8 isolates.

Có thể tưởng tượng một process là một chung cư.

Thay vì mỗi khách thuê một căn biệt thự riêng có móng, mái, cổng và bảo vệ, V8 chia chung cư thành rất nhiều căn hộ nhỏ.

1V8 Runtime
2├── Isolate A
3├── Isolate B
4├── Isolate C
5├── Isolate D
6├── ...
7└── Isolate N

Mỗi isolate có vùng nhớ riêng và không được tùy tiện nhìn sang hàng xóm.

Một runtime có thể chạy hàng trăm hoặc hàng nghìn isolate và chuyển đổi giữa chúng. Cloudflare cho biết isolate khởi động nhanh hơn đáng kể và cần ít memory hơn cách tạo runtime trong container hoặc VM cho từng workload. (Cloudflare Docs)

Đây vốn là nền móng của Workers.

Kitesurf lấy triết lý ấy rồi đem áp vào browser.

Thay vì:

1Browser = một khối Chromium khổng lồ

ta bắt đầu có:

1Browser
2=
3nhiều component nhỏ
4+
5isolation
6+
7RPC
8+
9stateless execution

Đây mới là phần thú vị.

Một trang web đi qua Kitesurf như thế nào?

Ở mức đơn giản hóa, Kitesurf có ba thành phần chính:

1                ┌───────────────┐
2Agent / CDP ───▶│    Engine     │
3                └───────┬───────┘
4                        │
5            ┌───────────┴───────────┐
6            ↓                       ↓
7      ┌────────────┐          ┌──────────────┐
8      │ PageScript │          │ PageRenderer │
9      └────────────┘          └──────────────┘

Nhưng phía sau còn có một thằng đứng ngoài cửa làm bảo vệ mạng: SandboxOutbound.

Engine

Engine là phần duy nhất trực tiếp nói chuyện với client.

Nó xử lý:

• Chrome DevTools Protocol (CDP),
• WebSocket,
• REST API,
• session state.

Việc giữ CDP cực kỳ quan trọng.

Bởi vì hệ sinh thái đã có sẵn:

1Playwright
2Puppeteer
3chrome-remote-interface
4MCP tools
5Chrome DevTools

Cloudflare không muốn cả thế giới viết lại tool.

Về phía client:

1Playwright
2     ↓
3    CDP
4     ↓
5 Chromium

có thể đổi thành:

1Playwright
2     ↓
3    CDP
4     ↓
5 Kitesurf

Cloudflare hiện cho phép chọn Kitesurf chỉ bằng tham số browser=kitesurf trên Browser Run endpoint. (The Cloudflare Blog)

Đây là một quyết định kiến trúc khá khôn.

Muốn thay động cơ thì thay.

Không bắt tài xế học lái lại từ đầu.

PageScript

Khi trang web được mở, Kitesurf tạo một PageScript isolate.

Trong đó có:

1globalThis
2DOM
3JavaScript
4WebAssembly

HTML được parse để tạo DOM.

CSS được xử lý.

JavaScript chạy và thay đổi DOM giống cách các ứng dụng React, Vue hay Angular vẫn làm.

Kitesurf tận dụng Blitz, một web engine modular viết bằng Rust, cùng Stylo, CSS engine được dùng trong Firefox. (The Cloudflare Blog)

Một chi tiết khá vui là Workers hiện không cho phép eval() native vì lý do security.

Website ngoài đời thì tất nhiên không quan tâm kiến trúc đẹp đẽ của chúng ta và vẫn có code dùng eval.

Cloudflare xử lý bằng cách nhét thêm Boa, một JavaScript engine viết bằng Rust, vào để chạy những đoạn này.

Tức là về cơ bản:

1JavaScript runtime
2    chạy
3JavaScript runtime khác

Nghe có vẻ hơi ngáo.

Cloudflare cũng thừa nhận nó không tối ưu.

Nhưng nó chạy được.

Đôi khi engineering chỉ đơn giản vậy thôi.

SandboxOutbound

Trang web cần tải:

• HTML,
• JavaScript,
• CSS,
• font,
• image,
• Wasm,
• API request.

Kitesurf không để mọi component thích đi Internet đâu thì đi.

Tất cả outbound network được gom qua một Worker riêng.

Nó xử lý:

• CORS,
• browser-like headers,
• response filtering,
• cookie jar riêng cho từng page.

Tư duy ở đây là:

Web là dữ liệu không đáng tin.

Agent có thể được bảo:

1hãy vào website X

nhưng website X có thể chứa bất cứ thứ gì.

JavaScript độc hại.

Prompt injection.

Redirect.

Iframe.

Script từ domain thứ ba.

Vì vậy browser của agent về bản chất không chỉ là renderer.

Nó còn là sandbox thực thi nội dung thù địch. (The Cloudflare Blog)

PageRenderer

Cuối cùng mới tới pixel.

PageRenderer nhận scene đã tính toán, rasterize nó rồi tạo:

1PNG
2JPEG
3PDF

Renderer gần như không giữ state.

Nếu render treo:

1kill renderer
2create renderer mới
3retry

Engine và PageRenderer giao tiếp bằng RPC giữa các Workers isolates. (The Cloudflare Blog)

Đây chính là tinh thần “throwaway infrastructure”.

CPU và RAM giảm 3-7 lần, nhưng có một chi tiết thú vị

Cloudflare benchmark Kitesurf trên corpus 14 URL, lấy median từ năm lần chạy Browser Run Quick Actions.

Kết quả họ công bố như sau: (The Cloudflare Blog)

Đọc bảng này sẽ thấy một chuyện rất đẹp.

Kitesurf tốn ít CPU và RAM hơn rất nhiều.

Nhưng…

Chromium vẫn chạy xong nhanh hơn.

Screenshot của Kitesurf chậm hơn khoảng 1,8 lần.

HTML extraction chậm hơn khoảng 1,7 lần.

Xong rồi.

Chromium thắng?

Chưa chắc.

Bởi vì có hai loại “nhanh”.

Một là:

1Một task chạy bao lâu?

Hai là:

1Một máy xử lý được bao nhiêu task cùng lúc?

Giả sử bạn chỉ mở một browser.

Thời gian hoàn thành tuyệt đối rất quan trọng.

Nhưng nếu bạn chạy hàng nghìn agent, bài toán lại trở thành:

$$ Throughput \approx \frac{Available\ Resources}{Resource\ per\ Task} $$

Một task có thể chậm hơn vài trăm mili giây nhưng ăn RAM ít hơn bốn, năm, bảy lần.

Khi đó cùng một cục máy, ta có khả năng nhét nhiều task hơn vào.

Và với workload kiểu:

1crawl 1.000.000 URL

thì đôi khi:

11.000 browser hơi chậm

lại thắng:

1200 browser rất nhanh

Đây là khác biệt giữa tối ưu latency và tối ưu throughput.

Cũng cần nói rõ benchmark trên là benchmark do Cloudflare tự thực hiện trên corpus nhỏ, không phải một đánh giá độc lập trên toàn bộ Web. Bản thân Cloudflare cũng xác nhận Chromium hiện nhanh hơn Kitesurf về wall-clock time. Vì vậy con số 3-7 lần nên được hiểu là kết quả của các workload họ đo, không phải định luật vật lý áp dụng cho mọi website.

Kitesurf chưa thay Chrome

Đây là phần quan trọng.

Kitesurf mới khoảng 12 tuần tuổi khi được công bố.

Cloudflare cho biết nó đã pass hơn 215.000 Web Platform Tests, đặc biệt các khu vực hữu ích cho agent như:

• HTML,
• DOM,
• CSS,
• SVG,
• selection,
• XHR.

Nhưng nó chưa phải Chromium. (The Cloudflare Blog)

Hiện tại Kitesurf chưa phù hợp nếu cần:

• video playback,
• WebGL,
• TLS fingerprint giống browser thật để vượt browser challenge,
• session authentication kéo dài,
• độ tương thích web gần như tuyệt đối,
• pixel-perfect rendering.

Cloudflare thậm chí nói khá rõ:

Nếu workload cần những thứ trên thì cứ dùng Chromium của Browser Run. (The Cloudflare Blog)

Đây không phải câu chuyện:

1Kitesurf
2    ↓
3giết Chrome

Mà hợp lý hơn sẽ là:

1               ┌── API / WebMCP
2               │
3Agent ─ Router ┼── Kitesurf
4               │
5               └── Chromium

Trang có API hoặc WebMCP?

Gọi thẳng tool.

Chỉ cần DOM, accessibility tree, HTML, screenshot đơn giản?

Kitesurf.

Website kỳ quặc, login dài, video, WebGL, fingerprint phức tạp?

Chromium.

Theo mình, browser routing mới có khả năng trở thành kiến trúc production thú vị trong vài năm tới.

Agent không nhất thiết phải nhìn pixel

Có một hướng phát triển khác cũng đáng chú ý.

Con người nhìn website như thế này:

1PIXEL

Agent không nhất thiết phải vậy.

Trong tháng 7/2026, Browser Run bổ sung endpoint trả trực tiếp accessibility tree.

Thay vì đưa cho model một screenshot rồi bảo:

1Nhìn hình và đoán xem nút mua nằm đâu.

ta có thể đưa:

1button
2  name: "Mua ngay"
3
4textbox
5  name: "Tìm kiếm"
6
7link
8  name: "Thông số kỹ thuật"

Cloudflare mô tả cách này giúp agent lấy cấu trúc semantic của trang mà không phải xử lý đống HTML hoặc suy luận từ pixel. (Cloudflare Docs)

Xa hơn nữa là WebMCP.

Website có thể chủ động khai báo:

1searchFlights()
2bookTicket()
3getProduct()
4addToCart()

Agent gọi function trực tiếp thay vì:

 1screenshot
 2↓
 3LLM nhìn
 4↓
 5tìm nút
 6↓
 7click
 8↓
 9screenshot
10↓
11LLM nhìn tiếp

WebMCP hiện vẫn đang ở giai đoạn thử nghiệm, nhưng hướng đi rất rõ: browser cho agent đang dần trở thành một machine interface, không chỉ là cái màn hình giả lập cho robot bấm chuột. (Cloudflare Docs)

Nếu xu hướng này tiếp tục, có thể stack tương lai sẽ giống:

1AI Agent
2   ↓
3Browser Runtime
4   ├── Structured Tools
5   ├── Accessibility Tree
6   ├── DOM
7   ├── Network
8   └── Pixels khi thật sự cần

Pixel trở thành phương án cuối cùng.

Điều này khá buồn cười.

Con người đã mất ba mươi năm biến Internet từ chữ thành hình ảnh đẹp.

Bây giờ AI xuất hiện và nói:

Cho tôi chữ lại được rồi.

Đây có thể là một lớp hạ tầng mới

Kitesurf không phải dự án duy nhất nhìn thấy vấn đề này.

Cloudflare cho biết cảm hứng ban đầu đến từ Obscura, một headless browser engine viết bằng Rust dành cho AI automation và web scraping, cũng hỗ trợ CDP để làm việc với Playwright/Puppeteer mà không cần Chrome. (GitHub)

Điều đó cho thấy một pattern đang hình thành.

Ngày trước chúng ta có:

1Database cho người

rồi sinh ra database cho analytics, time-series, vector search.

Có:

1Server cho application

rồi sinh ra container, function, serverless runtime.

Có:

1Search cho con người

rồi bây giờ bắt đầu có retrieval infrastructure cho LLM.

Browser cũng có thể đi theo con đường tương tự.

Browser truyền thống tối ưu cho:

1Human
2+
3Screen
4+
5Mouse
6+
7Keyboard

Browser agent-first tối ưu cho:

 1Machine
 2+
 3DOM
 4+
 5Network
 6+
 7Tools
 8+
 9Isolation
10+
11Massive concurrency

Hai thứ cùng gọi là browser.

Nhưng bài toán vật lý bên dưới hoàn toàn khác nhau.

Từ browser process tới browser như một function

Có lẽ thay đổi thú vị nhất nằm ở cách chúng ta nghĩ về browser.

Ngày trước:

Browser là một chương trình.

Sau đó:

Browser là một service.

Và với những thứ như Kitesurf:

Browser có thể trở thành một function tạm thời.

1browse(url)

Nó xuất hiện.

Chạy JavaScript.

Tạo DOM.

Đọc dữ liệu.

Có thể render vài triệu pixel.

Trả kết quả.

Rồi biến mất.

Không có icon trên desktop.

Không có tab.

Không có bookmark.

Không có thanh địa chỉ.

Không ai nhìn thấy nó.

Nhưng có thể một ngày nào đó, hàng tỷ phiên browser như vậy đang sinh ra và chết đi trong các data center mỗi phút.

Một Internet thứ hai đang hình thành dưới Internet mà chúng ta nhìn thấy.

Ở tầng trên, con người vẫn vuốt chuột, nhìn banner, xem video và bấm những cái nút màu xanh.

Ở tầng dưới, những agent không có mắt đang bò qua DOM, RPC, cookie jar, WebAssembly, accessibility tree và hàng tỷ request HTTP.

Và khi người sử dụng Internet bắt đầu không còn hoàn toàn là con người, có lẽ phần mềm dùng để đi vào Internet cũng phải thay đổi theo.

Kitesurf còn rất sớm.

Nó chưa thay được Chromium.

Nó chưa xử lý được toàn bộ Web.

Cloudflare cũng chưa open source dự án tại thời điểm công bố, dù cho biết có kế hoạch làm việc này sau khi sản phẩm sẵn sàng hơn. (The Cloudflare Blog)

Nhưng ý tưởng phía sau nó thì đáng để quan sát:

Đừng đưa cho robot cả một chiếc ô tô nếu thứ nó cần chỉ là đôi dép.

Có thể vài năm nữa, khi xây AI agent, câu hỏi sẽ không còn là:

Dùng Playwright hay Puppeteer?

Mà sẽ là:

Task này có thực sự cần một browser hoàn chỉnh không?

Và đó là lúc browser dành riêng cho agent thực sự trở thành một lớp hạ tầng.

Tổng kết

Kitesurf cho thấy browser automation đang có khả năng tách thành một nhánh riêng khỏi browser truyền thống.

Thay vì cố mang toàn bộ Chromium vào mọi workload, một agent-first browser có thể giữ lại những thứ máy thực sự cần:

• HTML,
• DOM,
• JavaScript,
• network,
• CSS vừa đủ,
• rendering khi cần,
• isolation,
• CDP compatibility.

Rồi bỏ bớt những phần chỉ tồn tại vì phía trước browser từng có một con người.

Có lẽ bài học lớn nhất không nằm ở Kitesurf.

Nó nằm ở một nguyên tắc quen thuộc của engineering:

Khi đối tượng sử dụng hệ thống thay đổi, kiến trúc tối ưu cũng thay đổi theo.

Browser từng là cửa sổ để con người nhìn vào Internet.

Với agent, browser có thể không còn là cửa sổ nữa.

Nó chỉ là một đôi tay.

Và đôi tay thì không cần màn hình 4K.

Cảm ơn các bạn đã quan tâm và theo dõi bài viết, hẹn gặp lại ở các bài viết tiếp theo.

Tham khảo

• Cloudflare — Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers, 06/08/2026. Cloudflare Kitesurf Blog
• Cloudflare Workers — How Workers works. Cloudflare Workers Architecture
• Cloudflare Browser Run — WebMCP. Cloudflare WebMCP Documentation
• Cloudflare Browser Run — Changelog: Accessibility Tree. Browser Run Changelog
• Playwright — Browser contexts and isolation. Playwright Browser Contexts
• Obscura — The headless browser for AI agents and web scraping. Obscura GitHub
• Blitz — Modular, embeddable web engine written in Rust. Blitz Project