Agent Browser biến browser thành interface cho AI agent

Khi nghĩ về browser automation, ta thường nghĩ đến Playwright, Selenium, DOM selector, hoặc screenshot. Cách nghĩ đó đúng nếu người điều khiển là developer viết script. Nhưng nếu người điều khiển là AI agent, vấn đề hơi khác.

Agent không cần một browser chỉ để “mở được web”. Agent cần một interface đủ gọn để hiểu trang, đủ ổn định để thao tác, và đủ bền để không mất login sau mỗi lần chạy.

Đó là chỗ Agent Browser đáng chú ý.

Nó không chỉ là một CLI để click và fill form. Điểm hay hơn là: Agent Browser biến browser thành một lớp I/O thân thiện với AI agent. Thay vì bắt model đọc HTML dài, đoán CSS selector, hoặc nhìn screenshot tốn token, nó đưa cho agent một bản đồ tương tác ngắn gọn của trang.

1. Vấn đề không phải là “AI có mở được browser không?”

AI agent có nhiều cách để dùng browser. Nó có thể gọi Playwright. Nó có thể đọc HTML. Nó có thể nhìn screenshot. Nó có thể chạy JavaScript trong page.

Nhưng mỗi cách có một điểm đau.

HTML và DOM quá dài. Một trang web thật có thể chứa rất nhiều node, class name, script, menu, footer, banner, tracking element. Nếu nhét hết vào context, agent tốn token mà vẫn dễ chọn sai thứ cần click.

Screenshot thì trực quan hơn, nhưng không phải lúc nào cũng cần. Ảnh giúp hiểu layout, màu sắc, trạng thái visual. Nhưng ảnh không trực tiếp nói element nào là button, input nào có label gì, hay click vào đâu là ổn định.

Selector thì mạnh với developer, nhưng không tự nhiên với agent. Nếu bảo model tự đoán .btn-primary:nth-child(3), rủi ro vỡ rất cao. UI đổi nhẹ, selector chết. DOM có nhiều button giống nhau, agent click nhầm.

Và còn một vấn đề thực tế hơn: login/session.

Automation đồ chơi thì mở trang public là đủ. Automation thật thường đi vào dashboard, admin panel, staging app, analytics, social app, hoặc tool nội bộ. Nếu mỗi lần chạy lại mất cookie, localStorage, profile, 2FA, thì agent chưa kịp làm việc đã kẹt ở login.

Vì vậy câu hỏi đúng hơn là:

Làm sao để browser trở thành một môi trường mà agent có thể hiểu, thao tác, quan sát và quay lại nhiều lần?

Agent Browser trả lời bằng snapshot, refs, sessions, profiles, CDP mode và một bộ command được thiết kế quanh workflow của agent.

2. Snapshot là bản đồ tương tác, không phải ảnh chụp màn hình

Điểm dễ hiểu sai nhất là chữ snapshot.

Trong Agent Browser, snapshot không phải PNG/JPG. Nó là một accessibility tree dạng text, thường gọn hơn DOM rất nhiều, và có gắn ref cho các element tương tác.

Một trang login có thể được agent nhìn như thế này:

Page: Example - Log in
URL: https://example.com/login

@e1 [heading] "Log in"
@e2 [form]
  @e3 [input type="email"] placeholder="Email"
  @e4 [input type="password"] placeholder="Password"
  @e5 [button type="submit"] "Continue"

Từ đó workflow trở nên tự nhiên:

agent-browser fill @e3 "user@example.com"
agent-browser fill @e4 "password"
agent-browser click @e5

Agent không cần đoán selector. Nó đọc trang như một bản đồ hành động: đây là input email, đây là password, đây là button Continue.

Nhưng có một rule quan trọng: refs chỉ sống trong snapshot hiện tại.

Sau khi click, submit form, navigate, mở modal, hoặc page re-render, các ref như @e3 không nên được dùng tiếp theo trí nhớ. Agent cần snapshot lại để lấy refs mới.

agent-browser snapshot -i
agent-browser click @e5
agent-browser wait --load networkidle
agent-browser snapshot -i

Đây là mental model rất đáng nhớ: snapshot dùng để hành động; screenshot dùng để kiểm tra visual.

3. Core loop: open, snapshot, act, wait, snapshot lại

Một browser workflow tốt cho agent thường không phức tạp ở tầng ý tưởng. Nó là một vòng lặp:

agent-browser open https://example.com
agent-browser snapshot -i
agent-browser click @e2
agent-browser wait --load networkidle
agent-browser snapshot -i

Các bước chính:

1. Open đúng URL.
2. Snapshot để hiểu trang và lấy refs.
3. Act bằng click, fill, press, select, check, hoặc upload.
4. Wait nếu action làm đổi trang hoặc đổi state.
5. Snapshot lại trước tương tác tiếp theo.

Điểm hay của loop này là nó ép agent vận hành theo kiểu quan sát-trước-khi-hành-động. Đây là thói quen quan trọng với browser automation, vì web app không đứng yên. Một click có thể mở modal. Một form submit có thể redirect. Một button có thể disabled. Một SPA có thể re-render khiến element cũ biến mất.

Nếu agent cứ hành động theo kế hoạch cũ mà không snapshot lại, nó đang thao tác trên ký ức chứ không phải trên trạng thái hiện tại của trang.

4. Session và profile mới là phần làm automation thật sự dùng được

Nhiều demo browser automation dừng ở trang public. Nhưng công việc thật thường cần trạng thái đăng nhập.

Agent Browser hỗ trợ session và profile để giữ cookie, localStorage, navigation history và auth state. Ví dụ:

agent-browser --session-name internal-dashboard open https://dashboard.example.com

Sau khi login lần đầu, lần sau có thể dùng lại cùng session để quay lại môi trường đó. Với profile, agent có thể dùng state từ Chrome/Brave/Chromium phù hợp, thay vì luôn bắt đầu từ một browser sạch.

Điều này quan trọng vì login không chỉ là một bước phụ. Với nhiều app, login là phần dễ vỡ nhất của automation:

• 2FA thay đổi theo thời gian.
• Cookie hết hạn.
• OAuth redirect qua nhiều domain.
• Bot detection nhạy với browser mới tinh.
• App chỉ hoạt động đúng khi có extension hoặc profile state cụ thể.

Nếu session không bền, agent sẽ tiêu hao phần lớn thời gian để quay lại điểm xuất phát. Nếu session bền, agent có thể làm việc như một cộng sự quay lại cùng workspace cũ.

5. CDP Mode: dùng Chrome thật khi cần đúng context

Một feature đáng chú ý khác là CDP Mode. Nó cho phép Agent Browser connect vào browser đang chạy qua Chrome DevTools Protocol.

Điểm này hữu ích khi developer đã có một Chrome ở đúng state: đã login, đang mở app local, đang ở đúng màn hình có bug. Thay vì bắt agent tự dựng lại flow, có thể bật remote debugging rồi cho agent đọc trực tiếp context đó.

Ví dụ trên macOS:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222
agent-browser connect 9222
agent-browser snapshot -i

Nhưng cần hiểu đúng: Agent Browser không tự điều khiển Chrome hằng ngày đang mở bình thường. Nó chỉ attach được vào browser instance có CDP endpoint. Nếu Chrome được mở không có --remote-debugging-port, agent không thể tự nhiên nhảy vào đó.

CDP Mode vì vậy phù hợp nhất khi bạn chủ động mở một Chrome riêng cho automation, với profile/session phù hợp, rồi để Agent Browser connect vào.

6. Quan sát được agent đang làm gì

Một điểm khó chịu của automation là cảm giác “black box”. Agent nói nó đã click, nhưng bạn không biết nó đang ở đâu, gặp modal gì, hay có bị kẹt ở cookie banner không.

Agent Browser có Dashboard và Streaming để giải quyết phần này.

agent-browser dashboard start
agent-browser open https://example.com

Dashboard giúp quan sát live viewport, activity feed, session status. Streaming cho phép live preview hoặc pair browsing. Với QA, bug hunt, hoặc automation trên app phức tạp, đây không phải tính năng phụ. Nó là cách để human kiểm tra agent không đi sai đường.

Ngoài ra, diffing giúp xác nhận action có thật sự tạo thay đổi:

agent-browser snapshot -i
agent-browser click @e4
agent-browser diff snapshot

Console, network và profiler đưa workflow từ “click thử xem sao” thành debugging thật:

agent-browser console
agent-browser errors
agent-browser network requests
agent-browser profiler start
agent-browser profiler stop trace.json

Với frontend workflow, agent không chỉ cần click đúng. Nó còn cần biết sau click có console error không, API nào trả lỗi, UI có đổi state không, và page có chậm vì JavaScript hay layout không.

7. Khi nào nên dùng Agent Browser?

Agent Browser đáng dùng nhất khi tác vụ có một trong các dấu hiệu này:

• Agent cần thao tác nhiều bước trên web app.
• Trang có form, modal, dashboard, table, menu hoặc state động.
• Bạn cần giữ login/session giữa nhiều lần chạy.
• Bạn muốn agent dùng refs từ snapshot thay vì tự đoán selector.
• Bạn muốn quan sát live agent đang làm gì.
• Bạn cần debug console, network, diff hoặc performance trong cùng workflow.
• Bạn muốn connect vào Chrome thật qua CDP để dùng đúng context hiện tại.

Nếu chỉ cần scrape một trang static đơn giản, có thể không cần tới nó. Nhưng khi browser trở thành môi trường làm việc dài hạn của agent, Agent Browser bắt đầu có ý nghĩa.

8. Sai lầm thường gặp

Sai lầm đầu tiên là dùng snapshot như screenshot. Snapshot để lấy cấu trúc tương tác. Screenshot để nhìn visual. Hai thứ bổ sung nhau, không thay thế nhau hoàn toàn.

Sai lầm thứ hai là giữ ref quá lâu. @e5 không phải ID vĩnh viễn của button. Nó là ref trong snapshot hiện tại. Page đổi thì snapshot lại.

Sai lầm thứ ba là bỏ qua wait. Click xong mà snapshot ngay có thể đọc trạng thái giữa chừng. Với form submit, navigation, SPA update hoặc API call, cần wait đúng điều kiện.

Sai lầm thứ tư là coi session như chi tiết phụ. Với automation thật, session persistence thường quyết định workflow có dùng được hàng ngày hay không.

Sai lầm cuối cùng là bật CDP remote debugging một cách vô tư. CDP rất mạnh, nhưng cũng là quyền điều khiển browser. Chỉ bật trong môi trường tin cậy.

9. Takeaway

Agent Browser đáng chú ý không phải vì nó “có thể điều khiển browser”. Nhiều tool làm được việc đó.

Điểm đáng chú ý là nó thiết kế browser như một interface cho AI agent: đọc bằng snapshot, hành động bằng refs, giữ state bằng session/profile, attach vào Chrome thật bằng CDP, và quan sát/debug bằng dashboard, diff, console, network, profiler.

Nếu Playwright là API mạnh cho developer viết automation, thì Agent Browser là một lớp vận hành giúp agent hiểu và thao tác web ít mù mờ hơn.

Với AI agents, khác biệt lớn không nằm ở việc có click được hay không. Khác biệt nằm ở việc agent có biết mình đang click vào đâu, trang đã đổi thế nào, và lần sau có quay lại đúng trạng thái đó được không.