Sử dụng máy tính là gì và tại sao lại quan trọng? Sử dụng máy tính là một ý tưởng đơn giản nhưng có ý nghĩa sâu rộng: thay vì yêu cầu mô hình trả lời câu hỏi, chúng ta yêu cầu chúng tự chủ vận hành phần mềm—điều hướng trang web, điền biểu mẫu, thao tác qua các quy trình và hoàn thành tác vụ từ đầu đến cuối.
Điều này mở ra một nhóm lớn các tác vụ thực tế hiện đang phân mảnh giữa nhiều giao diện, chẳng hạn như đặt chỗ trọn quy trình, thanh toán thương mại điện tử, lập kế hoạch du lịch nhiều bước và các quy trình hậu cần không có API tương đương phù hợp. Đây không phải là những vấn đề mới. Điểm mới là giờ đây có thể giải quyết chúng bằng các mô hình đa dụng.
Các hệ thống gần đây của Anthropic và OpenAI đã chứng minh rằng tác nhân không chỉ có thể hành động mà còn suy luận về trạng thái, phục hồi sau lỗi và lập tức xây dựng giải pháp riêng cho từng tác vụ. Điều này biến trình duyệt thành một môi trường thực thi đa dụng cho tác nhân, nhưng cũng đặt ra ngay một câu hỏi thiết kế: chúng ta nên cho mô hình tiếp cận môi trường đó đến mức nào?
Các hệ thống ban đầu giải quyết vấn đề bằng cách bọc trình duyệt trong một tập hợp cố định gồm các hành động an toàn, được định sẵn. Như bài viết này sẽ phân tích, cách tiếp cận đó đang chạm đến giới hạn.
Khi xây dựng tác nhân trình duyệt, người ta thường có một phản xạ quen thuộc: đừng quá tin tưởng mô hình.
Vì vậy, chúng ta bọc trình duyệt lại. Chúng ta cung cấp các công cụ định sẵn như click, type, scroll, select và read_text. Chúng ta đơn giản hóa Mô hình Đối tượng Tài liệu (DOM). Chúng ta thu hẹp không gian hành động. Chúng ta cố gắng làm cho hành vi trở nên dễ hiểu và dễ kiểm soát thông qua những lớp trừu tượng do mình thiết kế.
Đây là một điểm khởi đầu hợp lý. Nhưng về lâu dài, đây cũng ngày càng trở thành một kiến trúc sai lầm.
Khi các mô hình tiên phong ngày càng cải thiện, hạn chế không còn chỉ nằm ở việc mô hình thiếu công cụ. Vấn đề là chúng ta buộc mô hình phải hoạt động qua những lớp trừu tượng đã loại bỏ quá nhiều thông tin của hệ thống nền tảng. Chúng ta nén một môi trường lộn xộn, biến động thành một giao diện hành động cố định, rồi yêu cầu mô hình hoạt động hiệu quả dù đã mất đi nhiều thông tin.
Sự đánh đổi đó đang ngày càng kém hấp dẫn.
Bước chuyển mà chúng tôi đang khám phá tuy dễ mô tả nhưng có hệ quả đáng kể. Thay vì coi tác nhân là bộ chọn hành động định sẵn, chúng tôi xem tác nhân như một trình tổng hợp chương trình hoạt động trong môi trường thời gian chạy có ràng buộc.
Các mô hình đã trở nên thực sự giỏi và không còn cần những rào chắn trừu tượng của bạn—chúng cần toàn bộ không gian hành động để thiết kế, thực thi và lặp lại tác vụ cho đến khi đạt mục tiêu.
Bài viết này bàn về bước chuyển từ tự động hóa trình duyệt nặng tính trừu tượng sang sử dụng máy tính có ràng buộc, cũng như những thay đổi khi thiết kế hệ thống theo cách này.
Vấn đề không nằm ở chỗ giao diện hành động cố định sai về mặt khái niệm. Vấn đề là web không vận hành theo cách chúng mong muốn.
Các giao diện hiện đại được xây dựng bằng React, Vue và Angular, với cơ chế cập nhật trạng thái bất đồng bộ, hệ thống sự kiện tổng hợp và tiện ích bên thứ ba được nhúng trong các iframe khác nguồn, mỗi iframe có vòng đời riêng. Một lớp bọc ra lệnh “nhập vào trường này” chỉ chính xác nếu trang web cũng định nghĩa thao tác nhập giống như bạn. Nhiều trang không như vậy. Việc đặt giá trị trực tiếp thường bỏ qua hoàn toàn cơ chế phát hiện thay đổi của framework. Trường nhập liệu trông như đã được điền. Quy trình xác thực không bao giờ được kích hoạt. Biểu mẫu vẫn không hoạt động.
Bạn có thể vá lỗi này. Bạn có thể thêm trường hợp đặc biệt cho trường nhập liệu React, phát sự kiện blur sau focus và đợi mạng ở trạng thái rảnh trước khi đọc trạng thái. Mỗi bản vá đều đúng trong phạm vi cục bộ. Nhưng khi cộng dồn, chúng tạo thành một hệ thống ngày càng khó bảo trì và ngày càng bị bó hẹp vào những trang web bạn đã gặp.
Vấn đề sâu xa hơn là bạn đang mã hóa vào lớp trừu tượng những giả định về cách tương tác phải diễn ra, rồi nhận ra rằng web vận hành theo những giả định khác.
Hãy xét một biểu mẫu thanh toán của Stripe hoặc Adyen được nhúng trong iframe khác nguồn. Lớp bọc của bạn không thể truy cập trực tiếp vì biểu mẫu nằm ở một nguồn riêng biệt. Công cụ read_text không thể quan sát trạng thái nội bộ của biểu mẫu. Công cụ type không thể thao tác với các trường nhập liệu của biểu mẫu. Tác nhân dựa trên lớp bọc sẽ bế tắc tại đây. Lớp trừu tượng được thiết kế cho tài liệu chính. Tác vụ thực tế lại nằm ở nơi lớp trừu tượng không thể nhìn thấy.
Sự không tương thích tương tự cũng xuất hiện trong những quy trình khó nhận thấy hơn. Một danh sách thả xuống do framework kiểm soát có thể hoàn toàn không phản hồi khi nhấp trực tiếp, vì phần tử hiển thị không phải là thành phần điều khiển thực sự. Có thể cần một chuỗi sự kiện bàn phím để kích hoạt quá trình chuyển đổi trạng thái nền tảng. Nhìn từ bên ngoài, giao diện có vẻ như có thể nhấp được. Lớp trừu tượng ra lệnh “nhấp”. Không có gì xảy ra.
Hoặc hãy xét một quy trình hộp thoại nhiều bước, trong đó các cập nhật DOM hiển thị chậm hơn những thay đổi trạng thái nội bộ. Hành động đúng tiếp theo phụ thuộc vào một lần chuyển đổi trạng thái chưa được phản ánh trong các phần tử mà lớp bọc có thể nhìn thấy. Tác nhân dựa trên lớp bọc sẽ hành động quá sớm hoặc đọc trạng thái cũ vì nó đang vận hành dựa trên góc nhìn không đầy đủ về hệ thống.
Trong mỗi trường hợp, lớp trừu tượng đều che khuất những tín hiệu mà tác nhân thực sự cần.
Một mô hình hoạt động ở cấp độ thấp hơn—kiểm tra DOM trực tiếp, suy luận về ranh giới giữa các frame và tổng hợp chuỗi tương tác cho bề mặt cụ thể đó—có thể xử lý những tình huống này. Không phải vì bản thân mô hình thông minh hơn. Mà vì mô hình được tiếp cận những thông tin từng bị loại bỏ.
Thay đổi mà chúng tôi hướng tới có thể được mô tả đơn giản: thay vì yêu cầu mô hình chọn hành động định sẵn, chúng tôi cung cấp một bề mặt thực thi cấp thấp hơn và giới hạn bề mặt đó bằng chính sách thời gian chạy thay vì thiết kế lớp trừu tượng.
Lựa chọn thiết kế này xuất phát từ một chuyển biến rộng hơn trong ngành, vốn đang bắt đầu ưu tiên các công cụ cơ bản cấp thấp—những công cụ tận dụng năng lực vốn có của tác nhân trong việc tự hiệu chỉnh khi chạy và tạo mã chất lượng cao—thay cho các công cụ chuyên biệt được mã hóa cứng, tuy ổn định nhưng làm mất khả năng thích ứng của mô hình với nhiều môi trường.
Hãy nhìn vào thành công của Claude Code khi trở thành lựa chọn hàng đầu trong bộ công cụ của nhiều nhà phát triển, cũng như xu hướng chung của ngành hướng đến các tác nhân dựa trên terminal. Lợi thế lớn nhất của Claude Code không nằm ở bản thân mô hình mà ở hệ thống điều khiển cấp thấp hơn. Việc cung cấp cho mô hình ít công cụ hơn nhưng có tính mô-đun cao hơn và ở cấp thấp hơn—tức là terminal—mang lại hiệu quả gọi công cụ tốt hơn, chủ yếu vì tác nhân có thể suy luận và tạo tập lệnh tùy chỉnh cho tác vụ trước mắt, thay vì cố sử dụng các công cụ khái quát làm nhiễu cửa sổ ngữ cảnh.
Trong trường hợp tự động hóa trình duyệt, trên thực tế điều này có nghĩa là mô hình có thể trực tiếp kiểm tra trạng thái hiện tại của trang, duyệt qua các frame và xây dựng mã tương tác riêng cho giao diện hiện tại, thay vì ánh xạ mọi thứ vào một tập hành động dựng sẵn cố định.
Mô hình hoạt động ít giống một bộ chọn hơn và giống một tác giả mã thực thi hơn. Mô hình kiểm tra trạng thái hiện tại, suy luận về giao diện và tổng hợp logic tương tác cho tình huống cụ thể đó. Mô hình có thể xây dựng chuỗi nhiều bước, thích ứng với các quy trình khác thường và xác thực kết quả trước khi tiếp tục. Khi một hành động thất bại, mô hình nhìn thấy lỗi nền tảng và tự điều chỉnh. Cách này mạnh mẽ hơn và cũng rủi ro hơn—nhưng gần với bản chất thực tế của vấn đề hơn nhiều.
Điều quan trọng là việc loại bỏ lớp trừu tượng không khiến hệ thống kém chặt chẽ hơn. Nó chỉ chuyển sự chặt chẽ sang nơi khác.
Những công việc trước đây nằm trong khâu thiết kế lớp bọc và xử lý trường hợp biên được chuyển sang ba nơi: câu lệnh (trở thành một dạng huấn luyện vận hành), môi trường thời gian chạy (thực thi các giới hạn như phạm vi điều hướng, hành động nhạy cảm và hành vi thử lại) và lớp đánh giá (không chỉ xem tác vụ có thành công hay không mà còn đánh giá các bước trung gian có chính xác hay không). Ít lớp trừu tượng mong manh hơn. Hệ thống bao quanh mạnh mẽ hơn.
Một kết quả của bước chuyển này là mã sản phẩm thường trở nên đơn giản hơn, dù toàn bộ hệ thống có năng lực cao hơn. Thay vì mã hóa các mẫu tương tác thành những lớp bọc có thể tái sử dụng, tác nhân tự tổng hợp hành vi trong thời gian chạy. Bạn chỉ cần duy trì một tập nhỏ các thành phần cơ bản mạnh mẽ cùng một môi trường thực thi có ràng buộc, thay vì không ngừng mở rộng vô số công cụ chuyên biệt và logic xử lý trường hợp biên.
Điều này cũng thay đổi cách hệ thống khái quát hóa. Tác nhân dựa trên lớp bọc khái quát hóa tốt với những tác vụ tương tự các lớp bọc bạn đã xây dựng. Tác nhân hoạt động trong môi trường thời gian chạy có ràng buộc có thể khái quát hóa sang những tác vụ dùng chung một nền tảng thực thi, ngay cả khi giao diện hiển thị khác nhau.
Ví dụ, việc tương tác với biểu mẫu tìm kiếm, quy trình đặt chỗ hoặc trang cài đặt có thể trông hoàn toàn khác nhau ở cấp độ giao diện người dùng. Nhưng bên dưới, chúng có chung các mẫu: đọc trạng thái, kích hoạt sự kiện, xác thực kết quả và xử lý cập nhật bất đồng bộ. Một hệ thống hoạt động ở cấp độ đó có thể chuyển giao giữa các tác vụ một cách tự nhiên hơn.
Thành phần có thể tái sử dụng không phải là danh sách hành động, mà là khả năng kiểm tra trạng thái, hành động an toàn và xác minh kết quả của mô hình.
Bài học rõ ràng nhất từ công việc này là độ tin cậy không đến từ việc cung cấp thêm các hàm hỗ trợ cho mô hình. Độ tin cậy thường đến từ việc cung cấp ít thành phần cơ bản hơn nhưng mạnh mẽ hơn, đồng thời ràng buộc chúng đúng cách. Hỗ trợ quá mức sẽ mã hóa cứng các giả định về cách thực hiện tác vụ. Các ràng buộc xác định phạm vi vận hành an toàn và cho phép mô hình tự tìm ra giải pháp cục bộ tốt hơn.
Một bề mặt thực thi mạnh mẽ hơn cũng đòi hỏi mô hình an toàn chặt chẽ hơn. Khi tác nhân không còn bị giới hạn trong một tập nhỏ các hành động định sẵn, về thực chất tác nhân đang trực tiếp vận hành phần mềm thực tế. Điều đó lập tức làm thay đổi hồ sơ rủi ro.
Cần tính đến bốn vấn đề khi thiết kế:
Lộ dữ liệu. Khi tương tác với các giao diện thực tế, tác nhân thường sẽ gặp thông tin nhạy cảm. Vì vậy, cần có phương pháp che dữ liệu và kiểm soát truy cập nghiêm ngặt. Chỉ nên tiết lộ dữ liệu khi cần thiết cho việc thực thi; nhật ký và dấu vết cũng phải được xử lý cẩn thận để khả năng quan sát không trở thành phần nhạy cảm nhất của hệ thống.
Phạm vi thực thi. Một tác nhân mạnh mẽ không được phép tùy ý hoạt động. Trong thực tế, điều này có nghĩa là phải giới hạn nơi tác nhân có thể điều hướng, các miền có thể truy cập và những hệ thống được phép tương tác. Các ràng buộc này phải được thực thi ở cấp độ thời gian chạy, thay vì chỉ là quy ước trong câu lệnh.
Độ tin cậy của môi trường. Giao diện hiện đại có thể chứa chỉ dẫn, nội dung hoặc quy trình gây hiểu lầm hay mang tính đối kháng. Việc chèn câu lệnh qua nội dung trang là một bề mặt tấn công có thật. Hệ thống cần có hệ thống phân cấp chỉ dẫn, bước kiểm tra xác thực và điều kiện chấm dứt rõ ràng để ngăn tác nhân làm theo chỉ dẫn ngoài ý muốn.
Phổ tự chủ. Không phải mọi hành động đều nên hoàn toàn tự chủ. Trong nhiều môi trường sản xuất, điều quan trọng là xem mức độ tự chủ như một phổ liên tục. Hệ thống có thể cho tác nhân chủ động cao trong việc khám phá và thực thi, nhưng vẫn yêu cầu phê duyệt đối với một số nhóm hành động.
Nguyên tắc nền tảng rất đơn giản: trao thêm quyền năng cho mô hình đòi hỏi phải tăng cường sức mạnh của hệ thống bao quanh. Khả năng tự chủ không đi kèm chính sách thì chưa sẵn sàng để đưa vào môi trường sản xuất.
Chúng tôi không còn hỏi: nên cung cấp những hành động trình duyệt nào?
Chúng tôi bắt đầu hỏi: làm thế nào để cung cấp cho mô hình toàn bộ không gian hành động—và xây dựng các chính sách thời gian chạy xung quanh không gian đó ra sao để vẫn bảo đảm an toàn?
Cách nhìn mới đó làm thay đổi những điều bạn quan tâm. Hệ thống phân loại hành động và mức độ đầy đủ của lớp bọc trở nên ít quan trọng hơn. Chính sách thời gian chạy, khả năng quan sát và đánh giá ở từng bước trở nên quan trọng hơn. Năng lực của mô hình và thiết kế hệ thống không thể thay thế cho nhau. Mô hình càng tiến bộ, vai trò của hệ thống càng quan trọng chứ không hề giảm đi.
Các tác nhân trình duyệt hoạt động tốt trong bản trình diễn thường thành công vì tác vụ có phạm vi hẹp và môi trường thuận lợi. Hệ thống sản xuất đòi hỏi một cách tiếp cận khác: thực thi có ràng buộc, hành vi được đo lường và quy trình đánh giá có thể phân biệt kết quả đúng với kết quả đạt được nhờ may mắn.
Giảm thiết kế lớp bọc. Tăng cường kỹ thuật hệ thống.
Và dù tập trung vào tác nhân trình duyệt, những điều này gợi mở một cách nhìn rộng hơn: xem việc sử dụng máy tính như một ngành kỹ thuật hệ thống.