Khi Agent thực hiện tác vụ web, lỗi thường tập trung ở bốn khu vực: định vị phần tử, chờ và timeout, lưu trạng thái, và chặn từ phía môi trường. Thiết kế từng bước theo tính idempotent, retry lỗi có thể phục hồi, lưu trạng thái bền vững và cô lập môi trường theo từng tác vụ sẽ giúp tỷ lệ thành công ổn định hơn nhiều.
Khi mới bắt đầu tự động hóa web, cách nghĩ thường khá trực tiếp: viết luồng xử lý rồi cho script chạy. Logic trông không có vấn đề, nhưng tác vụ vẫn thỉnh thoảng thất bại và trạng thái tài khoản đôi khi xuất hiện bất thường. Phản ứng đầu tiên là kiểm tra code, nhưng khi phân tích kỹ hơn, vấn đề thường tập trung ở bốn khu vực.
Trang thay đổi là định vị phần tử có thể hỏng
Phần lớn script dựa vào selector để tìm element. Khi selector bị viết cố định, gần như bất kỳ thay đổi nào trên page cũng có thể làm nó mất hiệu lực: button đổi class name, nội dung thay một từ, một section chuyển từ server-side rendering sang tải bất đồng bộ, hoặc element được bọc trong container mới. Khi chạy A/B test, cùng một page thậm chí có thể có structure khác nhau với các account khác nhau.
Biểu hiện thường gặp là không tìm thấy element, click lệch vị trí, hoặc bấm vào control cùng tên nhưng nằm ở vị trí khác. Loại failure này không phải do network jitter, nên retry vài lần cũng không khắc phục được.
Cách làm thực tế là giảm phụ thuộc vào absolute path. Nên ưu tiên accessibility attributes, business ID ổn định hoặc quan hệ tương đối giữa các elements; đồng thời chuẩn bị fallback selectors cho cùng một loại page để tự động hạ cấp khi primary selector thất bại. Nếu page có iframe hoặc Shadow DOM, cần chuyển sang đúng context trước, nếu không việc định vị chắc chắn thất bại.
Khoảng chờ và timeout được đặt không đúng
Nếu thời gian chờ quá ngắn, element có thể bị đánh dấu thất bại trước khi render xong, trông giống như script có bug. Nếu quá dài, thời gian của một task bị kéo dài không cần thiết, throughput giảm và timeout dài còn có thể che mất error thật.
Explicit wait đáng tin cậy hơn fixed sleep: hãy chờ một condition cụ thể, chẳng hạn target element xuất hiện, request trả về hoặc loading animation biến mất. Timeout budget nên được chia theo tầng, với giới hạn riêng cho một step, một page và toàn bộ task, rồi thu hẹp dần theo từng tầng thay vì dùng một giá trị ở mọi nơi.
Cũng cần phân biệt giữa chờ page có thể sử dụng và chờ business result được tạo ra. Trường hợp đầu thường chỉ cần DOM ready; trường hợp sau có thể phải chờ API callback hoặc thay đổi của status text trên page. Chờ sai signal có thể khiến operation trông như đã thành công trong khi data thực tế chưa được ghi.
Tác vụ nhiều bước đi được nửa đường thì mất progress
Các task như đăng ký, đặt hàng và xuất bản có thể dễ dàng có hơn mười steps. Nếu process thoát giữa chừng do timeout, browser crash hoặc host restart, trong khi state chỉ nằm trong memory, lần chạy tiếp theo hoặc phải làm lại từ đầu, hoặc submit lại step trước đó.
Hậu quả của duplicate execution còn khó điều tra hơn một failure đơn thuần: cùng một operation được thực hiện hai lần, upstream system có thêm một record và rất khó truy vết nguồn gốc.
Giải pháp là tạo điểm persistence cho từng step. Sau mỗi bước hoàn tất, ghi progress vào nơi lưu trữ bền vững cùng unique identifier của task; sau khi restart thì tiếp tục từ điểm thành công gần nhất. Không cần framework phức tạp, một file hoặc một state record là đủ.
Bị chặn từ phía environment nhưng biểu hiện giống code error
Ba loại vấn đề đầu tiên nằm bên trong task, còn một loại khác đến từ environment. Site có thể kết hợp browser characteristics, access behavior và network origin để đánh giá nguồn truy cập. Nếu bị xem là đáng ngờ, site có thể trả về verification page, content rỗng hoặc đơn giản là timeout. Trong task logs, điều này gần như không khác execution error.
Một số nguyên nhân phổ biến:
- Vị trí của egress IP, time zone và language không khớp nhau
- Tất cả task đều gửi requests từ cùng một browser environment, khiến request density theo đơn vị thời gian cao hơn rõ rệt so với người dùng thật
- Environment thay đổi thường xuyên hoặc account liên tục login lại
Bốn việc giúp nâng success rate
- Làm mỗi step trở nên idempotent. Trước khi thực thi, kiểm tra prerequisite đã được đáp ứng hay chưa để việc lặp lại action không tạo thêm side effect. Read operations vốn idempotent; write operations cần unique identifier hoặc deduplication key để bảo vệ.
- Phân loại failure. Các lỗi tạm thời như element chưa render, network jitter hoặc API trả 5xx có thể retry với backoff. Các lỗi xác định như account bị hạn chế, parameter không hợp lệ hoặc target resource không tồn tại sẽ không thay đổi dù retry bao nhiêu lần; nên kết thúc để không tiếp tục chiếm concurrency capacity.
- Persist state định kỳ. Lưu progress, intermediate outputs và current step để sau khi task restart có thể chạy tiếp từ điểm dừng thay vì quay lại step đầu tiên.
- Cô lập runtime environment theo task. Mỗi account hoặc task nên có browser environment riêng, không dùng chung Cookies và local storage, fingerprint characteristics có khác biệt hợp lý, còn time zone và language phải phù hợp với region của egress IP.
Việc thứ tư đặc biệt quan trọng khi quy mô task tăng lên. Khi hàng chục hoặc hàng trăm task chạy song song, environment layer quyết định giới hạn trên của stability và cả phạm vi ảnh hưởng khi có sự cố. Trong các tình huống như vậy, PurpleMark cung cấp khả năng tạo isolated environments theo nhu cầu và thu hồi theo batch, để mỗi account có environment riêng và state giữa các task không làm ảnh hưởng lẫn nhau.
Nội dung này chỉ nhằm mục đích nghiên cứu kỹ thuật và chia sẻ thực hành phát triển. Hãy sử dụng các công nghệ liên quan một cách hợp pháp, đúng quy định và tuân thủ terms of service của nền tảng mục tiêu.
