Webwright: Tại sao đại lý web AI nên viết mã chứ không phải nhấp chuột

AI đặc vụ Webwright: Tại sao đại lý web AI nên viết mã chứ không phải nhấp chuột Trong nhiều năm, các đại lý web đã làm việc chỉ bằng một cú nhấp chuột—và thường thất bại trong các nhiệm vụ dài. Webwright của Microsoft Research lại đặt cược một điều khác: cung cấp cho mô hình một thiết bị đầu cuối và để nó viết chương trình thay thế. Đối với các nhiệm vụ có thời gian dài, mô hình GPT-5.4 tương tự có tỷ lệ thành công từ 33,5% lên 60,1%. Và thay vì để lại dấu vết nhấp chuột, nó để lại thứ mà bạn thực sự có thể sử dụng lại: công cụ dòng lệnh. Chiến Vũ Minh Ngày 17 tháng 8 năm 2026 đọc 21 phút Chia sẻ Ảnh của Hal Gatewood trên Bapt 1. Giới thiệu: web sẽ không đứng yên Nếu gần đây bạn đã xây dựng một đại lý web, bạn sẽ biết kiểu lỗi. Bạn giao cho nó một nhiệm vụ như “kéo mọi danh sách từ thư mục này vào một bảng tính” và theo dõi nó từng bước một. Nó đọc trang. Nó dự đoán một cú nhấp chuột. Nó chờ DOM mới, cấu trúc trang mà trình duyệt nhìn thấy. Nó đọc lại, dự đoán lại, lại chờ đợi. Hình 1: Kiểu lỗi: mỗi bước của trình duyệt là một cơ hội khác để đọc sai trang. Cho dù tác nhân hoạt động từ pixel, thành phần trang, menu hành động cố định hay trình bao bọc khung, bốn chi phí đều trả về: hành động dễ vỡ, giá mỗi bước, trạng thái trang cũ và không có công cụ tái sử dụng nào ở cuối. (Sơ đồ của tác giả.) Sau đó, ở đâu đó ở bước 40, mọi thứ sụp đổ. Một phương thức bật lên bất ngờ. Nút “trang tiếp theo” di chuyển. Tác nhân nhầm lẫn phần tử này với phần tử khác. Bất kỳ một trong những điều này có thể làm hỏng toàn bộ nhiệm vụ. Vấn đề sâu xa hơn không phải là cú nhấp chuột tồi. Đó là cách tác nhân vận hành: nhìn vào trang, quyết định một hành động, xem điều gì đã thay đổi, sau đó quyết định lại. Nó lặp đi lặp lại vòng lặp này mà không có kế hoạch lâu dài về cách hoàn thành nhiệm vụ từ đầu đến cuối. Hiện trường đã thử một số cách khác nhau để làm cho vòng lặp này trở nên đáng tin cậy hơn. Một số tác nhân, như Người vận hành của OpenAI và Người sử dụng máy tính của Anthropic, hoạt động từ ảnh chụp màn hình và tương tác với một trang web giống như một người. Những người khác, như WebVoyager, sử dụng DOM của trang để hiểu những thành phần nào có sẵn và quyết định tương tác với thành phần nào. Các điểm chuẩn như Mind2Web và WebArena giúp các hệ thống này dễ so sánh hơn bằng cách cung cấp cho các tổng đài viên một bộ hành động tiêu chuẩn—nhấp, nhập, cuộn, chọn. Và các công cụ nguồn mở như sử dụng trình duyệt, Skyvern, Stagehand và LaVague đã đóng gói những ý tưởng này thành các API mà các kỹ sư có thể dễ dàng xây dựng thành các ứng dụng thực tế hơn. Những cách tiếp cận này làm cho vòng lặp trở nên đáng tin cậy hơn, nhưng về cơ bản chúng không thay đổi cách thức hoạt động của vòng lặp: tác nhân vẫn thực hiện từng hành động một, chờ xem điều gì xảy ra, sau đó quyết định phải làm gì tiếp theo. Và khi nhiệm vụ kết thúc, nó vẫn chưa tạo ra bất kỳ thứ gì có thể tái sử dụng được—nó chỉ hoàn thành một chuỗi nhấp chuột. Ba năm làm đại lý web, theo màu sắc của gia đình. Hầu hết các hệ thống vẫn tiến hành một hành động mong manh tại một thời điểm. Webwright, được phát hành vào tháng 5 năm 2026, tiếp tục chuỗi viết mã mà CodeAct đã bắt đầu. (Dòng thời gian theo tác giả; ngày phát hành của mỗi dự án.) Webwright, một khung tác nhân trình duyệt của Microsoft Research và Đại học Hồng Kông, có một cách tiếp cận khác. Khẩu hiệu của nó nắm bắt được ý tưởng: “Thiết bị đầu cuối là tất cả những gì bạn cần đối với các đại lý web”. Thay vì yêu cầu mô hình tìm ra lần nhấp tiếp theo, Webwright yêu cầu các nhân viên viết và chạy mã—sử dụng tập lệnh bash và Playwright để mở trình duyệt, kiểm tra trang và thực hiện tác vụ. Kết quả không chỉ là một chuỗi hành động dài của trình duyệt. Đó là chương trình mà các kỹ sư có thể kiểm tra, chạy lại, sửa đổi và tái sử dụng. Sự khác biệt này quan trọng nhất khi web là nguồn dữ liệu của bạn: trang tổng quan, danh mục sản phẩm, kết quả tìm kiếm, công cụ nội bộ, trang web nặng về JavaScript và quy trình làm việc mà bạn mong muốn chạy nhiều lần. Trong những trường hợp đó, câu hỏi không chỉ là liệu người đại diện có thể hoàn thành nhiệm vụ hay không. Vấn đề là liệu nó có nên tiếp tục nhấp qua trình duyệt hay viết một chương trình có thể sử dụng lại để thực hiện công việc hay không. Chúng ta sẽ bắt đầu với bốn cách tiếp cận chính để xây dựng đại lý web và những hạn chế mà chúng vẫn có. Sau đó, chúng ta sẽ xem xét bên trong Webwright: ba thành phần cốt lõi của nó hoạt động như thế nào, một khung gồm khoảng một nghìn dòng hoạt động như thế nào trên các điểm chuẩn và kết quả nói lên điều gì về chi phí và độ tin cậy. Cuối cùng, chúng tôi sẽ áp dụng phương pháp này để giải quyết ba vấn đề thường gặp—các trang được phân trang, nội dung được hiển thị bằng JavaScript và nguồn cấp dữ liệu cuộn vô hạn. 2. Tại sao các đại lý web liên tục gặp sự cố Việc chuyển sang “viết mã” quan trọng vì nó giải quyết vấn đề cơ bản chứ không chỉ các triệu chứng. Các đại lý web ngày nay khác nhau về cách họ hiểu một trang—một số xem ảnh chụp màn hình, một số khác đọc DOM—nhưng hầu hết vẫn hoạt động theo cùng một cách: thực hiện một hành động trên trình duyệt, xem điều gì xảy ra, sau đó quyết định hành động tiếp theo. Điều đó làm việc cho các nhiệm vụ ngắn. Nhưng tác vụ càng chạy lâu thì càng có nhiều khả năng xảy ra một cú nhấp chuột không hợp lệ, một trang bị thay đổi hoặc một phần tử đọc sai khiến mọi thứ bị hỏng. Gia đìnhMô hình nhìn thấy gìTại sao nó hữu íchNơi nó phá vỡTác nhân tầm nhìnẢnh chụp màn hìnhHoạt động khi trang chỉ có thể hiểu được bằng trực quanThay đổi bố cục, sự mơ hồ về pixel, ảnh chụp màn hình đắt tiềnTác nhân DOM / tập hợp nhãn hiệuHTML, cây trợ năng, hộp được đánh sốCăn cứ nhiều hơn pixel thôTrạng thái trang lớn, thay đổi ID phần tử, nối đất cứngCác tác nhân API hành động cố địnhMột menu như nhấp/loại/cuộn/chọn Vòng lặp điểm chuẩn có thể tái tạoKhông thể biểu thị vòng lặp, số lần thử, đầu ra tệp hoặc “làm điều này” cho mỗi hàng”Khung trình duyệtVòng kiểm soát trình duyệt được đóng góiDễ vận chuyển và quan sátDễ dàng vận chuyển và quan sátThường vẫn theo từng bước, tập trung vào phiên và ít tạo tác Các tác nhân tầm nhìn rất dễ hiểu: họ xem trang giống như một người và quyết định nhấp vào đâu. Điều đó hoạt động tốt đối với nhiều tác vụ của trình duyệt, nhưng việc thu thập dữ liệu đòi hỏi tính nhất quán hơn. Một sự thay đổi bố cục nhỏ có thể di chuyển một nút vừa đủ để nhân viên bấm nhầm vị trí—hoặc không có gì cả. Việc liên tục xem ảnh chụp màn hình cũng phải trả giá. Mỗi ảnh chụp màn hình mới đều tiêu thụ mã thông báo và tác nhân phải chuyển tiếp đủ ngữ cảnh để ghi nhớ những gì nó đã làm. Trên một