Agent lướt web — vụ án chưa ai phá

Agent của bạn gãy giữa chừng khi fetch trang web thật? Đây không phải bug — đây là bài toán hạ tầng mà cả ngành đang đua nhau giải.

Tại sao agent "chết" mà không để lại log?

Bao nhiêu lần bạn build một agent, chạy đẹp trên demo, rồi thả ra ngoài web thật thì... im lặng? Không lỗi, không log — chỉ trả về một cục HTML rỗng hoặc tệ hơn, một trang Cloudflare "Verify you are human".

Tuần rồi mình ngồi debug cùng một team ở Sài Gòn đang xây agent thu thập giá đối thủ trên mấy sàn thương mại điện tử. Agent chạy ngon trên 3 trang test, nhưng khi gặp trang thật — JavaScript render, lazy loading, anti-bot — thì trả về đúng một dòng: "Access Denied". Hiện trường vụ "chết" này quen thuộc đến mức mình nghĩ đây không phải lỗi của team nào cả, mà là lỗ hổng cấu trúc của cả hệ sinh thái agent hiện tại.

Khoan — vấn đề không chỉ là "fetch không được"

Khi agent cần tương tác với web thật, có ít nhất 4 công việc riêng biệt đang xảy ra cùng lúc:

Trước giờ, mỗi việc một tool khác nhau. Search thì SerpAPI hay Tavily. Fetch thì Jina Reader hoặc tự viết scraper. Browser thì Playwright, Puppeteer, hoặc Browserless. Orchestration thì... tự ráp.

Nói thẳng ra: team nào build agent lướt web cũng đang ráp 3–4 service từ 3–4 vendor, mỗi cái một API key, một hệ thống billing, một cách xử lý lỗi riêng. Khi pipeline gãy, bạn phải đi lần từng manh mối xem đoạn nào fail — search trả sai? fetch bị block? browser timeout? — mà mỗi vendor log một kiểu.

TinyFish, startup vừa raise hơn 47 triệu USD Series A do ICONIQ dẫn dắt, vừa launch một platform gộp cả 4 thành phần trên dưới một API key duy nhất: Web Agent, Web Search, Web Browser, và Web Fetch. Theo công bố, Web Search trả kết quả JSON với P50 latency khoảng 488ms (so với trung bình hơn 2.800ms của các đối thủ), còn Web Browser cold start dưới 250ms với 28 cơ chế anti-bot tích hợp ở tầng C++ — không phải inject JavaScript như cách phổ biến vốn dễ bị detect hơn.

Khi pipeline gặp đời thật

Ví dụ cụ thể 1: Monitor giá đối thủ

Giả sử team bạn 4 người, cần agent tự check giá 50 sản phẩm trên 5 sàn thương mại điện tử mỗi ngày. Flow truyền thống: mở Playwright headless từng trang, chờ JS render (5–10 giây/trang), parse HTML bằng BeautifulSoup, rotate proxy khi bị block, debug thủ công khi gãy.

Với một platform hợp nhất, flow rút gọn: gọi Web Fetch cho trang tĩnh, Web Browser cho trang cần render JS nặng — tất cả cùng hệ thống log, cùng billing. Quan trọng hơn, khi pipeline gãy bạn chỉ cần nhìn một dashboard thay vì đi hỏi 3 vendor khác nhau.

Ví dụ cụ thể 2: Agent tổng hợp competitive intelligence

Team product cần agent đọc 10 bài blog đối thủ, 5 trang pricing, và 3 bài research mỗi tuần để tạo competitive brief. Mỗi trang một kiểu: có trang chỉ cần fetch text, có trang cần browser thật, có trang cần search trước để tìm URL mới nhất. Khi tất cả nằm trong một platform với chung một credit system, agent có thể tự chọn tool phù hợp mà bạn không cần viết hàng đống logic routing.

Như mình từng chia sẻ trong bài về agent không biết đọc — nếu input cho agent là rác thì output cũng rác. Chất lượng web content mà agent nhận được chính là nền tảng cho mọi bước sau đó.

Cái bẫy "đổi tool là xong"

Mình từng thấy một team thay nguyên bộ scraping pipeline sang managed service mới, hào hứng vì latency giảm rõ rệt. Hai tuần sau, flash sale đầu tiên — agent cần burst 200 requests trong 5 phút — pipeline gãy lại. Lý do: rate limit của service giới hạn requests/phút, mà không ai đọc mục pricing kỹ.

Trước khi commit vào bất kỳ platform nào, checklist tối thiểu:

Open-source không thiếu lựa chọn

Nếu chưa muốn phụ thuộc managed service:

Tradeoff: open-source cho toàn quyền kiểm soát, không lo vendor lock-in, nhưng bạn tự quản proxy rotation, scaling, và maintenance. Managed service giải quyết phần đó, đổi lại bạn trả tiền và phụ thuộc uptime của họ.

Thử ngay chiều nay

Bước 1 — Liệt kê 5 trang web mà agent của bạn cần truy cập thường xuyên nhất.

Bước 2 — Test từng trang bằng curl đơn giản:

curl -s "https://target-url.com" | head -50

HTML đầy đủ = chỉ cần fetch. Trang trống hoặc redirect = cần browser rendering.

Bước 3 — Phân loại: bao nhiêu trang cần fetch đơn giản, bao nhiêu cần browser, bao nhiêu cần search trước để tìm URL?

Bước 4 — Thử với Crawl4AI (miễn phí) hoặc TinyFish (nếu muốn test managed):

# Ví dụ minh họa với Crawl4AI
from crawl4ai import AsyncWebCrawler

async with AsyncWebCrawler() as crawler:
    result = await crawler.arun(url="https://target-url.com")
    print(result.markdown[:500])

Bước 5 — So sánh: content có sạch không? Latency chấp nhận được không? Anti-bot xử lý ổn không?

Năm bước này mất khoảng 2 tiếng và cho bạn đủ dữ liệu để quyết định tự build hay dùng managed.

Bức tranh lớn hơn

TinyFish không phải tín hiệu đơn lẻ. Cùng tuần, OpenAI update Agents SDK với sandboxing — cho phép agent chạy trong môi trường cô lập, chỉ truy cập file và tool trong phạm vi được phép. Vercel ra mô hình durable execution mới cho long-running workflow. Ở tầng research, Parcae từ UC San Diego và Together AI thử nghiệm looped transformer — kiến trúc cho model đạt chất lượng tương đương transformer gấp đôi kích thước mà không tăng memory footprint.

Dấu vân tay chung của những chuyển động này: ngành đang dịch chuyển từ "model nào thông minh nhất" sang "agent chạy ở đâu, chạy thế nào, và chạy có an toàn không". Hạ tầng cho agent — chứ không chỉ bản thân model — mới là cuộc đua tiếp theo.

Và nếu bạn đang xây agent mà chưa nghĩ kỹ về lớp hạ tầng web bên dưới, thì plot twist: bottleneck không nằm ở model — nó nằm ở cái trang web mà agent của bạn đang cố đọc.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo