Những công việc tạo thu nhập nào AI Agents đã có thể vận hành ổn định, những việc nào chưa phù hợp để tự động hóa và các điểm kiểm soát nào vẫn phải giữ con người trong quy trình.
Ranh giới rõ nhất giữa AI Agent và AI hội thoại là Agent có thể trực tiếp hành động: mở trình duyệt, điền biểu mẫu, đọc và ghi bảng tính, rồi tiếp tục theo quy trình mà không bắt bạn phải liên tục sao chép và dán.
Khác biệt này thực sự nâng cao năng lực, nhưng đồng thời cũng làm lộ rất nhanh giới hạn giữa những việc làm được và chưa làm được. Sau vài lần chạy, bạn thường sẽ thấy điểm nghẽn hiếm khi nằm ở kỹ thuật đơn thuần mà chủ yếu xuất hiện ở những ràng buộc khác trong thực tế.
Nhóm công việc hiện có thể chạy ổn định
Các tình huống đang ổn định hiện nay có một điểm chung: con người có thể kiểm tra kết quả nhanh và nếu sai cũng không gây hậu quả không thể đảo ngược.
Dễ triển khai nhất là tổ chức và giám sát dữ liệu. Agent có thể định kỳ thu thập dữ liệu rải rác từ nhiều nguồn, căn chỉnh trường dữ liệu, loại bỏ bản trùng và tạo báo cáo thay đổi theo ngày hoặc theo tuần một cách nhanh chóng mà không mệt mỏi. Biến động giá, trạng thái tồn kho, thay đổi thứ hạng và cập nhật dữ liệu công khai đều có thể xử lý theo cách này. Nếu quy trình chỉ đọc mà không ghi, chi phí của một lỗi gần như bằng không.
Việc tạo hàng loạt bản nháp đầu tiên và viết lại nội dung cũng đã thực tế. Khi có một chủ đề, Agent có thể thu thập thông tin công khai, sắp xếp thành ghi chú có cấu trúc và tạo khung cho bản nháp đầu tiên, giúp tiết kiệm rất nhiều thời gian tìm tài liệu. Viết lại cũng tương tự: một nội dung dài có thể được chia và điều chỉnh theo độ dài, giọng điệu của từng kênh với mức độ hoàn thiện khá cao. Tuy vậy, đầu ra vẫn phải được xem là bản nháp. Những phần cần kinh nghiệm, phán đoán hoặc quan điểm cá nhân phải do con người bổ sung, nếu không nội dung sẽ thiếu chiều sâu.
Tuyến đầu của chăm sóc khách hàng và trả lời email cũng có thể hấp thụ một khối lượng công việc lớn. Câu hỏi thường gặp, kiểm tra trạng thái vận chuyển, hướng dẫn trả hoặc đổi hàng và xác nhận lịch hẹn thường có câu trả lời tiêu chuẩn. Có thể để Agent xử lý trước, sau đó đánh dấu các cuộc hội thoại vượt phạm vi để chuyển cho người phụ trách. Tốc độ phản hồi sẽ cải thiện rõ rệt.
So sánh giá và tổng hợp thông tin cũng là một nhu cầu ổn định. Việc gom giá của cùng một sản phẩm trên nhiều kênh, khác biệt về thông số và các khiếu nại lặp lại trong đánh giá vào một bảng thường đáng tin cậy hơn so với việc con người tự mở từng trang để xem. Khi tiêu chí so sánh được xác định rõ, kết quả thường có thể dùng ngay.
Bốn nhóm tình huống này còn có một điều kiện ngầm: ranh giới của nhiệm vụ phải rõ ràng. Bạn càng mô tả chính xác “đầu vào là gì, đầu ra là gì và dừng trong trường hợp nào”, quy trình càng chạy ổn định.
Nhóm công việc hiện vẫn chưa chạy tốt
Phía còn lại của ranh giới cũng khá rõ. Vấn đề không nhất thiết do năng lực mô hình mà do các giới hạn trong thế giới thực.
Điển hình nhất là những thao tác cần danh tính của tài khoản. Trạng thái đăng nhập, thông tin danh tính đã xác minh và uy tín tích lũy đều là quyền mà nền tảng cấp cho một chủ thể cụ thể. Agent không thể có được quyền đó chỉ bằng biện pháp kỹ thuật. Yêu cầu Agent “vận hành một tài khoản” khác về bản chất với yêu cầu Agent “xử lý một tập dữ liệu”.
Các hành động liên quan đến thanh toán cũng không nên giao hoàn toàn cho tự động hóa. Đặt hàng, trừ tiền, chuyển khoản hoặc quy đổi tài sản đều là thao tác làm dịch chuyển giá trị thật. Với bất kỳ thao tác nào như vậy, nên giữ một bước xác nhận cuối cùng cho con người. Không chỉ vì sợ sai, mà còn vì các hành động tài chính thường không thể đảo ngược.
Ngoài ra còn có những hành động bắt buộc phải được nền tảng công nhận hoặc chấp thuận. Vượt qua đánh giá, được duyệt tư cách, đăng ký sự kiện hoặc được phê duyệt nội dung đều do nền tảng quyết định. Không có con đường kỹ thuật nào để đi vòng qua phán quyết đó. Những tuyên bố rằng một công cụ có thể bảo đảm lấy được kiểu phê duyệt này thay bạn thường không đứng vững.
Đăng ký tài khoản hàng loạt và tự động chạy nhiệm vụ để tích lũy phần thưởng cũng không nên nằm trong một quy trình hợp lý. Những cách làm này đụng vào một số quy định rõ ràng nhất của nền tảng, và cơ chế phát hiện không chỉ nhìn vào một thao tác riêng lẻ. Nhịp thao tác, đường đi hành vi và tính nhất quán của môi trường đều có thể được xem xét. Ngay cả khi chạy được về mặt kỹ thuật, tài khoản tồn tại bao lâu vẫn phụ thuộc vào mức độ nền tảng sẵn sàng dung thứ, và điều kiện đó có thể thay đổi bất cứ lúc nào.
Những điểm kiểm soát nên để con người xử lý
Agent phù hợp nhất khi đóng vai trò lớp thực thi. Một số khâu dưới đây nên được cố định dưới sự kiểm soát của con người.
Đặt mục tiêu và xác định ưu tiên. Quyết định làm việc gì, dùng tiêu chuẩn nào và khi nào dừng có trọng lượng lớn hơn nhiều so với tốc độ thực thi. Agent sẽ không gánh hậu quả thay bạn nếu chọn sai hướng.
Rà soát nội dung gửi ra bên ngoài. Bất kỳ thứ gì sẽ được đọc dưới tên của bạn—email, câu trả lời, bài đăng hay báo cáo—đều nên được kiểm tra trước khi gửi. Lý do rất thực tế: nếu sai, người chịu trách nhiệm là bạn.
Xác nhận các thao tác liên quan đến tiền và quyền. Quyền đọc có thể mở rộng để Agent xem dữ liệu và tạo báo cáo bất cứ lúc nào. Những điều chỉnh thông thường như thay tham số hoặc tạm dừng một tác vụ kém hiệu quả cũng có thể giao cho Agent. Nhưng thay đổi lớn và thao tác hàng loạt nên đi qua một lần xác nhận thứ hai của con người. Cách này giữ được cả hiệu quả lẫn khả năng kiểm soát.
Giữ lại lịch sử thực thi. Cần có ghi chép về việc Agent đã làm gì và theo quy tắc nào. Khi có vấn đề, đây là căn cứ để điều tra; trong hoạt động bình thường, nó cũng là đầu vào để cải thiện quy trình.
Khi muốn chạy nhiều tài khoản song song hơn
Sau khi một quy trình đơn lẻ đã chạy ổn định, rất tự nhiên để nghĩ đến việc có thể tái sử dụng nó cho nhiều tài khoản hơn hay không.
Lúc này, điểm nghẽn thường không nằm ở Agent mà ở môi trường tài khoản. Nếu nhiều tài khoản hoạt động trong cùng một môi trường trình duyệt và đi qua cùng một đầu ra mạng, nền tảng rất dễ xếp chúng thành một nhóm và xử lý cùng nhau. Cách khả thi là ghép môi trường với tài khoản theo tỷ lệ một-một: mỗi tài khoản có một môi trường trình duyệt độc lập và một đầu ra mạng cố định; khi chạy nhiệm vụ thì tải đúng môi trường tương ứng với tài khoản đó. Các công cụ như PurpleMark cung cấp chính khả năng quản lý nhiều môi trường kiểu này và có thể phối hợp với script để chuyển môi trường theo từng tài khoản.
Nhưng đừng đảo ngược thứ tự. Tách môi trường chỉ giải quyết câu hỏi các tài khoản có “trông giống người dùng độc lập hay không”. Nó không trả lời câu hỏi “việc này có nên làm hay không”. Hoạt động của chính tài khoản phải tuân thủ quy định trước thì việc tách môi trường mới có ý nghĩa.
Một thứ tự triển khai ít dễ gặp sự cố
Hãy bắt đầu bằng một tình huống nhỏ và cụ thể thay vì tự động hóa toàn bộ quy trình ngay từ đầu. Kiểm tra xem đầu ra có dùng trực tiếp được không; nếu dùng được, mới thêm khâu tiếp theo. Thiết lập ranh giới quyền ngay ở bước này, đặc biệt là quyền ghi và các thao tác liên quan đến tiền. Để một quy trình đơn lẻ chạy ổn định trong một thời gian rồi mới mở rộng sang nhiều tài khoản, và chuẩn bị tách môi trường trước khi mở rộng quy mô.
Thứ tự này chậm hơn một chút, nhưng chi phí thất bại ở mỗi bước đều thấp và kết luận rút ra ở từng bước đều có thể tái sử dụng.
