Browser control trong Antigravity: agent tự mở Chrome test web

TL;DR: Antigravity browser control cho phép agent làm việc xuyên suốt ba môi trường — editor, terminal và trình duyệt. Nó viết code, tự chạy app bằng terminal, rồi tự mở Chrome click từng bước để verify tính năng, kèm screenshot và browser recording làm bằng chứng. Bài 6 hướng dẫn chuẩn bị Chrome, dùng slash command /browser, một ví dụ thực tế với form đăng ký, và các nguyên tắc an toàn khi trao quyền điều khiển trình duyệt cho agent.

Vòng lặp quen thuộc của dân làm web: sửa code → chuyển sang trình duyệt → F5 → click thử → quay lại editor. Lặp vài chục lần mỗi ngày. Antigravity browser control nhắm thẳng vào vòng lặp đó: agent tự làm luôn phần "chuyển sang trình duyệt và click thử", còn bạn chỉ xem bằng chứng cuối cùng. Theo tìm hiểu của mình, đây là mảnh ghép khiến Antigravity khác hẳn các trợ lý code chỉ biết sinh text.

Bài này nối tiếp bài 5 về Artifacts — vì sản phẩm của browser control chính là hai loại artifact đặc biệt: screenshot và browser recording.

Antigravity browser control hoạt động như thế nào?

Điểm cốt lõi của nền tảng Antigravity là agent không bị nhốt trong khung chat. Nó được cấp quyền thao tác trên ba surface:

1. Editor — viết và sửa code trong workspace.
2. Terminal — chạy lệnh: cài dependency, khởi động dev server, chạy test.
3. Browser — mở Chrome, điều hướng, click, điền form, đọc nội dung trang.

Ghép ba thứ lại, agent thực hiện được một chu trình khép kín mà theo tài liệu công bố Google gọi là thực thi task end-to-end: viết tính năng → tự khởi động app → tự mở trình duyệt test → tự xác nhận kết quả. Không cần bạn ngồi cạnh bấm từng bước.

Ví dụ dễ hình dung: bạn yêu cầu "thêm nút dark mode cho trang chủ". Agent sửa code, chạy npm run dev trong terminal, mở Chrome vào localhost:3000, click nút dark mode, chụp màn hình trước/sau, rồi đính kèm bằng chứng vào Walkthrough. Toàn bộ diễn ra tự động.

Chuẩn bị: Chrome là điều kiện bắt buộc

Muốn dùng browser control, máy bạn cần Google Chrome được đặt làm trình duyệt mặc định. Đây là yêu cầu ghi rõ trong hướng dẫn chính thức — browser sub-agent của Antigravity làm việc qua Chrome chứ không hỗ trợ Safari, Firefox hay Edge tại thời điểm viết bài.

Checklist nhanh trước khi bắt đầu:

• Đã cài Chrome bản mới (nếu chưa, cài xong nhớ đặt làm default browser).
• Đã cài và đăng nhập Antigravity — chưa thì xem lại bài 2: cài đặt Antigravity trên macOS, Windows, Linux.
• Project đã được tạo với đúng folder chứa web app của bạn.
• Dev server chạy được bằng lệnh terminal thông thường (agent sẽ tự gọi lệnh này).

Lần đầu agent mở trình duyệt, bạn có thể được hỏi xác nhận quyền. Đây là hành vi bình thường — Antigravity muốn bạn chủ động cho phép trước khi agent thao tác web.

Slash command /browser: triệu hồi browser sub-agent

Trong hội thoại của Antigravity có các slash command tiện dụng, và /browser là lệnh dành riêng cho việc tương tác web. Gõ /browser kèm mô tả việc cần làm, hệ thống sẽ spawn một browser sub-agent — một agent con chuyên trách thao tác trình duyệt.

Vài tình huống mình thấy /browser phát huy tốt:

• Test thủ công có kịch bản: "mở localhost:3000, đăng nhập bằng tài khoản test, kiểm tra trang dashboard hiển thị đủ 4 widget".
• Kiểm tra responsive: yêu cầu agent mở trang và chụp màn hình để xem bố cục có vỡ không.
• Đối chiếu tài liệu: cho agent mở trang docs của thư viện đang dùng để đọc thông số mới nhất thay vì đoán từ trí nhớ của model.

Sub-agent chạy xong sẽ trả kết quả về hội thoại chính, kèm screenshot từng bước. Bạn không phải rời khỏi cửa sổ làm việc.

Ví dụ thực tế: nhờ agent build form đăng ký rồi tự test submit

Để thấy rõ giá trị, mình mô tả lại một bài thực hành theo dạng codelab mà Google hướng dẫn, với đề bài kiểu: "Thêm form đăng ký nhận bản tin vào trang chủ, validate email, hiện thông báo thành công khi submit."

Diễn biến task trong Antigravity sẽ đi qua các chặng:

1. Implementation Plan xuất hiện. Agent liệt kê: tạo component form, thêm validate, viết handler submit, test trên trình duyệt. Bạn đọc, ưng thì bấm Proceed — như quy trình đã bàn ở bài 4 về tạo task đầu tiên.
2. Agent viết code trong editor. Task List tự tích từng mục.
3. Agent chạy dev server qua terminal. Nếu thiếu package, nó tự cài rồi chạy lại.
4. Agent mở Chrome và test như người thật: điền email sai định dạng → xác nhận có báo lỗi; điền email hợp lệ → bấm submit → xác nhận thông báo thành công hiện ra.
5. Bằng chứng nộp về: screenshot form ở từng trạng thái + browser recording quay trọn luồng test + Walkthrough tóm tắt.

Điều đáng giá nhất nằm ở bước 4–5: bạn xem video 30 giây thay vì tự ngồi test tay. Nếu recording cho thấy validate chưa chặn email sai, bạn comment thẳng vào artifact và agent sửa tiếp — không cần mô tả lại lỗi dài dòng.

An toàn khi trao quyền điều khiển trình duyệt

Trao cho agent quyền mở trình duyệt và thao tác thay mình là bước nhảy về quyền hạn, nên mình giữ mấy nguyên tắc sau:

• Luôn review Implementation Plan trước khi Proceed. Đặc biệt chú ý những bước agent định mở URL ngoài localhost. Kế hoạch có bước lạ → hỏi lại trước, chạy sau.
• Giới hạn scope project. Khi tạo project, chỉ add đúng folder cần thiết và chọn security preset phù hợp. Phạm vi hẹp thì rủi ro hẹp.
• Tách môi trường test. Cho agent test trên dev server với dữ liệu giả. Đừng để nó thao tác trên trang production hay tài khoản có dữ liệu thật.
• Xem recording trước khi tin kết quả. Bằng chứng sinh ra là để dùng — nghiệm thu qua video vẫn nhanh hơn tự test tay rất nhiều.

Cách tiếp cận "cấp quyền nhưng kiểm soát bằng bằng chứng" này nhất quán với triết lý agent-first mà mình phân tích trong bài mở đầu series: agent càng tự chủ, cơ chế kiểm chứng càng phải rõ ràng.

Mẹo xử lý khi browser control không chạy như ý

Trong quá trình tìm hiểu, mình gom được vài lỗi người mới hay gặp và cách gỡ tương ứng:

• Agent báo không mở được trình duyệt. Nguyên nhân phổ biến nhất là Chrome chưa phải trình duyệt mặc định. Vào cài đặt hệ điều hành, đổi default browser sang Chrome rồi chạy lại task.
• Agent mở Chrome nhưng trang trắng. Thường do dev server chưa kịp khởi động xong. Nhắc agent chờ server sẵn sàng (hoặc mô tả rõ port trong prompt: "app chạy ở localhost:5173").
• Recording không thấy thao tác mong muốn. Kịch bản test bạn mô tả quá chung chung. Viết prompt kiểu checklist: bước 1 mở trang, bước 2 điền ô email giá trị X, bước 3 bấm nút Y, bước 4 xác nhận thấy thông báo Z. Agent bám checklist sẽ test đúng trọng tâm.
• Popup đăng nhập chặn luồng test. Chuẩn bị sẵn tài khoản test và ghi rõ trong prompt, hoặc tắt bước auth trong môi trường dev. Tránh đưa mật khẩu thật của bạn vào hội thoại.

Một mẹo nữa: khi task test dài, hãy tách "build tính năng" và "test trên trình duyệt" thành hai lượt yêu cầu. Agent làm từng việc gọn hơn, và nếu phần test hỏng, bạn chỉ chạy lại phần test — đỡ tốn quota model cho việc build lại từ đầu.

Browser control phù hợp với ai?

Nếu bạn chủ yếu viết script, thư viện backend hay tool CLI, browser control ít khi cần đến. Nhưng với dân làm web — từ landing page tới dashboard — đây là tính năng đáng để chuyển sang thử Antigravity, vì nó tự động hoá đúng phần việc nhàm chán nhất: test tay lặp đi lặp lại.

Còn nếu bạn thích so sánh trước khi chọn công cụ, mình có viết về Codex, Claude và Gemini cho vibe coding và cách viết code AI miễn phí với OpenCode — đọc kèm để có bức tranh đầy đủ. Các chuỗi bài khác của blog nằm ở chuyên mục Công nghệ.

Kết: để agent test thay bạn, nhưng đừng ký giấy khống

Antigravity browser control biến agent từ "máy sinh code" thành người thực thi trọn vẹn: viết, chạy, tự test trên Chrome và nộp bằng chứng. Bạn tiết kiệm được vòng lặp sửa-F5-click tẻ nhạt, đổi lại phải giữ kỷ luật review — duyệt plan trước khi chạy, xem recording trước khi tin.

Trọn bộ sức mạnh này không chỉ nằm trong app desktop. Bước tiếp theo, mình sẽ đưa agent xuống hẳn terminal — nơi tự động hoá thật sự bắt đầu — với bài 7: Antigravity CLI (agy), dùng agent ngay trong terminal.