Agent chịu trách nhiệm ra quyết định, Playwright thao tác trình duyệt, nhưng lớp môi trường thường bị bỏ quên. Với các tác vụ thu thập chạy lâu, lỗi thường tập trung ở chính lớp này.
Khi dùng Agent framework để điều khiển trình duyệt thu thập dữ liệu, kiến trúc thường có ba lớp: Agent lập kế hoạch và ra quyết định, Playwright phụ trách nhấp chuột, nhập dữ liệu và trích xuất, còn cuối cùng workflow tương tác với trang đích. Các tác vụ ngắn thường chạy trơn tru và vượt qua kiểm thử cục bộ. Nhưng khi thời gian chạy kéo dài và số lượng tác vụ tăng lên, lỗi bắt đầu tập trung ở một nơi hiếm khi được chú ý đúng mức: browser environment.
Nhìn lại các vấn đề gặp trong thực tế, lỗi ở environment layer thường có ba dạng chính.
Environment bị đánh giá bất thường và toàn bộ pipeline dừng lại
Một trường hợp là nền tảng xử lý trực tiếp chính environment. Biểu hiện thường không phải chặn hoàn toàn mà là suy giảm: trả về trang đơn giản hơn, kết quả rỗng hoặc yêu cầu xác minh. Script không phát sinh lỗi, nhưng dữ liệu nhận được không còn giá trị. Các bước phía sau vẫn chạy bình thường và đưa dữ liệu sai đến tận bảng cuối cùng.
Điểm khó là những environment này thường được nhiều tác vụ dùng chung. Khi một environment gặp vấn đề, tất cả tác vụ gắn với nó có thể dừng theo. Retry cũng không giải quyết được vì nguyên nhân không nằm trong script.
Nhiều tác vụ chen vào cùng một environment và trạng thái phiên bị trộn lẫn
Khi các tác vụ chạy đồng thời trong cùng một browser instance, Cookie, localStorage và IndexedDB có thể ghi đè lên nhau và làm mất trạng thái đăng nhập. Trong thời gian ngắn có thể chưa thấy gì, nhưng sau vài ngày sẽ xuất hiện những lần yêu cầu đăng nhập lại khó giải thích.
Ngoài ra còn có một dạng drift kín đáo hơn. Với trình duyệt chạy lâu, cache, storage và thậm chí trạng thái render của WebGL sẽ tích lũy thay đổi theo thời gian. Cùng một environment có thể mang đặc trưng khác nhau giữa hôm nay và ba ngày sau. Nhiều người cho rằng Cookie đã hết hạn, trong khi thực tế chính environment không còn như trước. Vì vậy, biến environment thành đối tượng persistent và có thể reuse thường hiệu quả hơn việc tạo trình duyệt mới cho mỗi lần chạy.
Khi tiếp tục từ checkpoint, environment cũ có thể không còn dùng được
Tác vụ thu thập dữ liệu hiếm khi hoàn thành trong một lần chạy. Tiếp tục từ checkpoint sau khi bị gián đoạn là việc rất thường gặp, nhưng cũng dễ làm công sức trước đó bị lãng phí: khi restart script có thể vô tình tạo một browser instance mới và mất trạng thái đăng nhập; hoặc tiếp tục dùng environment cũ dù nền tảng đã flag nó, khiến việc chạy tiếp chỉ tiêu tốn resource.
Điểm mấu chốt không phải là số lần retry mà là granularity của recovery. Nếu không lưu bên ngoài script tác vụ đang ở bước nào, dữ liệu nào đã lấy được và environment nào đang dùng, thì sau khi restart chỉ còn cách làm lại từ đầu.
Có thể xử lý gì ở environment layer
Đặt ba vấn đề trên cạnh nhau, cách tiếp cận có thể gói gọn trong ba ý.
Nhóm environment theo tác vụ. Mỗi tác vụ nên có một nhóm environment riêng, không nên dồn nhiều tác vụ vào cùng một instance. Sau khi nhóm, từng tác vụ có thể cấu hình network egress, time zone và language riêng. Giữ các tham số này đồng bộ theo một bộ thống nhất đáng tin cậy hơn việc đặt thủ công từng giá trị rời rạc. Trong kiến trúc này, PurpleMark nằm ở environment layer: tạo browser environment theo lô, gắn mỗi environment với một network egress độc lập, rồi cung cấp qua API cho task-orchestration layer để lập lịch.
Cô lập lỗi. Khi một environment bị đánh giá bất thường, chỉ các tác vụ gắn với nó mới nên bị ảnh hưởng. Cách phổ biến là duy trì health status cho từng environment, kiểm tra định kỳ và khi phát hiện bất thường thì đưa environment đó ra khỏi luồng, thay bằng environment dự phòng, thay vì để script ở lớp trên retry cùng một environment hỏng nhiều lần. Cách này còn giúp xác định rõ hơn vấn đề nằm ở environment hay do cấu trúc trang đã thay đổi.
Làm cho state có thể phục hồi. Lưu persistent bên ngoài script các thông tin về tiến độ, deduplication fingerprints và environment identifiers. Khi restart, đọc các bản ghi này trước rồi mới quyết định tiếp tục từ đâu và dùng environment nào. Chia tác vụ thành các giai đoạn như discovery, loading và extraction, đồng thời xử lý lỗi riêng cho từng giai đoạn để một lỗi đơn lẻ không làm cả vòng chạy trở nên vô ích. Cũng cần chú ý đến resource: instance chạy lâu có thể bị memory leak, trang treo hoặc connection timeout, nên các session không hợp lệ cần được recycle định kỳ.
Những ranh giới cần được phân biệt rõ
Environment ổn định và việc có được phép thu thập dữ liệu hay không là hai chuyện khác nhau. Trước hết cần kiểm tra robots rules và terms of service của trang đích, vì nhiều trang giới hạn rõ automated access; kiểm soát request rate để không ảnh hưởng đến dịch vụ của bên kia; không thu thập personal information; và khi gặp technical protection measures, cách đúng là điều chỉnh strategy hoặc xin authorization thay vì tìm cách bypass. Technical stability không thể thay thế đánh giá compliance.
Nội dung chỉ nhằm phục vụ nghiên cứu kỹ thuật và trao đổi kinh nghiệm phát triển. Hãy tuân thủ điều khoản của trang đích và pháp luật áp dụng tại nơi bạn hoạt động.
