UX phê duyệt tác vụ AI agent trên điện thoại: thiết kế để quyết định đúng

Xác định đúng thời điểm cần người dùng quyết định

UX phê duyệt tác vụ AI agent bắt đầu từ một câu hỏi cụ thể: ở bước nào tác nhân chuyển từ chuẩn bị sang làm thay đổi dữ liệu, thiết bị hoặc giao tiếp với người khác? Điểm xác nhận nên nằm sát thời điểm đó. Nếu xuất hiện quá sớm, người dùng chưa có đủ thông tin để quyết định. Nếu xuất hiện sau khi thao tác đã hoàn tất, nút xác nhận chỉ còn mang tính thông báo.

Hãy xét một yêu cầu trên điện thoại: “Soạn tin báo tôi sẽ đến muộn 15 phút”. Tác nhân có thể hiểu ngữ cảnh và tạo bản nháp mà chưa cần thay đổi bên ngoài. Thời điểm cần quyết định là ngay trước khi gửi. Màn hình xác nhận nên hiển thị người nhận, ứng dụng liên lạc, nội dung hoàn chỉnh và tài khoản gửi. Người dùng có thể chọn gửi, sửa hoặc hủy mà không phải quay lại toàn bộ cuộc trò chuyện.

Mức độ tác động quyết định cách đặt điểm kiểm soát. Mở bản đồ tới một địa chỉ có hậu quả thấp hơn gửi tin nhắn cho khách hàng. Xem trang cài đặt khác với bật một quyền nhạy cảm. Chọn tệp khác với xóa tệp. Vì vậy, giao diện không nên dùng cùng một hộp thoại chung cho mọi trường hợp; nội dung xác nhận phải phản ánh đúng thay đổi sắp xảy ra.

Trong FoneClaw, chúng tôi giữ trạng thái chuẩn bị, đang chạy và chờ người dùng tách biệt. Xác nhận được gắn với đúng phiên và đúng tác vụ để quyết định của người dùng áp dụng vào công việc đang hiển thị. Với phần chuyên sâu về mối quan hệ giữa môi trường cách ly và quyền Android, bài Sandbox AI agent và quyền trên điện thoại: vì sao vẫn cần ranh giới giải thích vì sao một màn hình xác nhận cần đi cùng quyền hệ thống và phạm vi công cụ phù hợp.

Tách đề xuất, xem trước và áp dụng trong giao diện

Ba trạng thái dễ bị trộn lẫn nhất là đề xuất, xem trước và áp dụng. Đề xuất nói rằng tác nhân đã tìm ra một hành động khả dĩ. Xem trước cho người dùng thấy kết quả dự kiến với dữ liệu cụ thể. Áp dụng mới làm thay đổi trạng thái thật. Mỗi trạng thái cần nhãn, động từ và phản hồi thị giác riêng để người dùng không phải đoán việc đã hoàn tất hay vẫn đang chờ.

Trong bản xem trước công khai ngày 23 tháng 7 năm 2026, GitHub giới thiệu cơ chế kiểm soát tự động hóa trong GitHub Issues: những thay đổi được hỗ trợ có thể được đưa ra dưới dạng đề xuất để người dùng xem xét trước khi áp dụng. Đây là mẫu tương tác dành cho GitHub Issues, nhưng bài học thiết kế phù hợp với điện thoại là trạng thái chờ phải rõ ràng và quyết định của người dùng phải tác động đúng vào đề xuất đang xem.

Giao diện di động cần đặc biệt tiết kiệm không gian mà vẫn đủ dữ kiện. Với tin nhắn, hàng đầu tiên có thể là người nhận; phần giữa là nội dung; hàng cuối là tài khoản và nút gửi. Với cài đặt, bản xem trước nên nêu giá trị hiện tại và giá trị mới. Không nên dùng một nút chung như “Tiếp tục” khi động từ chính xác hơn là “Gửi”, “Bật”, “Xóa” hoặc “Tạo lịch”.

Dùng độ tin cậy để phân bổ công sức kiểm tra

Độ tin cậy hữu ích khi nó giúp hệ thống quyết định việc nào cần được đưa lên trước để người dùng kiểm tra. Chỉ số này không phải lời bảo đảm về tính đúng đắn. Một thao tác có độ tin cậy cao vẫn có thể gây hậu quả lớn nếu chọn nhầm tài khoản, người nhận hoặc thời điểm. Ngược lại, một đề xuất có độ tin cậy trung bình nhưng dễ đảo ngược có thể chỉ cần một bước xem nhanh.

Mẫu của GitHub Issues cho thấy một cách định tuyến rõ: hành động được đánh giá cao có thể được áp dụng tự động theo cấu hình, còn mức trung bình hoặc thấp được giữ lại dưới dạng đề xuất. Khi chuyển bài học này sang UX điện thoại, cần bổ sung mức độ tác động. Hệ thống có thể tự mở một màn hình đã xác định chắc chắn, nhưng gửi dữ liệu, xóa nội dung hoặc thay đổi quyền vẫn cần điểm kiểm soát phù hợp với hậu quả, kể cả khi việc nhận diện mục tiêu có vẻ chắc chắn.

Một ma trận thực dụng gồm hai trục: độ tin cậy và khả năng gây tác động. Độ tin cậy cao, tác động thấp có thể dẫn tới thực hiện trực tiếp rồi hiển thị kết quả. Độ tin cậy thấp, tác động thấp nên tạo đề xuất hoặc hỏi lại. Độ tin cậy cao, tác động lớn vẫn cần xem trước. Khi cả độ tin cậy thấp và tác động lớn, tác nhân nên dừng, nêu phần chưa rõ và yêu cầu người dùng bổ sung dữ kiện.

Không nhất thiết phải hiển thị một con số phần trăm. Trên màn hình nhỏ, các nhãn như “Đã xác định rõ”, “Cần kiểm tra người nhận” hoặc “Chưa chắc thời gian” hữu ích hơn. Người dùng cần biết yếu tố nào còn mơ hồ và phải sửa gì. Cách diễn đạt này biến độ tin cậy thành hướng dẫn hành động thay vì một điểm số trừu tượng.

Hiển thị lý do, đối tượng, hậu quả và bằng chứng

Trước khi yêu cầu xác nhận, tác nhân nên trả lời ngắn gọn bốn câu hỏi: vì sao thao tác này được đề xuất, nó tác động vào đâu, điều gì sẽ thay đổi và dữ kiện nào được dùng. Phần giải thích cần đủ để quyết định nhưng không biến thành bản ghi kỹ thuật dài. Trên điện thoại, một dòng lý do và vài trường dữ liệu có cấu trúc thường hiệu quả hơn một đoạn văn chung chung.

Ví dụ, thay vì chỉ hiển thị “Tạo sự kiện?”, giao diện có thể ghi: “Đề xuất tạo lịch vì tin nhắn nhắc cuộc họp vào 14 giờ ngày 8 tháng 8”. Bên dưới là tên lịch, giờ bắt đầu, múi giờ, người tham gia và nguồn thông tin. Nếu ngày được suy ra từ cụm “thứ Sáu tới”, giao diện nên đánh dấu đây là dữ kiện cần kiểm tra. Người dùng có thể sửa đúng trường thời gian mà không phải viết lại yêu cầu.

GitHub ghi lại lý do cho từng thay đổi Issues được hỗ trợ, dù hành động được áp dụng trực tiếp hay chờ xem xét. Trên điện thoại, nguyên tắc tương tự giúp người dùng hiểu một thao tác xuất phát từ câu lệnh nào và dựa trên dữ liệu nào. Tuy nhiên, phần giải thích chỉ hỗ trợ quyết định; quyền, chính sách công cụ và kiểm tra phía hệ thống vẫn đảm nhiệm vai trò kiểm soát riêng.

Trong FoneClaw, chúng tôi ưu tiên kết quả có thể đối chiếu: mục tiêu, công cụ sắp dùng, dữ kiện chính và trạng thái hiện tại. Khi cần tìm hiểu sâu hơn về danh tính thực hiện, quyền được cấp và lịch sử thao tác, bài Danh tính tác nhân AI: quyền, phê duyệt công cụ và nhật ký kiểm toán cung cấp phần nền quản trị mà một hộp xác nhận ngắn không thể trình bày hết.

Gắn xác nhận với đúng tác vụ và cuộc trò chuyện

Một điện thoại có thể xử lý nhiều yêu cầu gần như cùng lúc: tác vụ đầu đang đợi người dùng duyệt tin nhắn, tác vụ thứ hai đang tìm địa chỉ và tác vụ thứ ba vừa thiếu quyền lịch. Nếu các màn hình xác nhận không gắn với đúng cuộc trò chuyện và trạng thái chờ, người dùng có thể đồng ý một việc trong khi nghĩ mình đang xác nhận việc khác.

FoneClaw hiện tách riêng trạng thái đang chạy và đang chờ giữa các tác vụ. Xác nhận được ràng buộc với phiên, còn công việc được cô lập để quyết định của người dùng không bị dùng lại cho yêu cầu khác. Trên giao diện, mỗi mục chờ nên hiển thị tên tác vụ, thời điểm tạo, hành động cần quyết định và nội dung tóm tắt đủ để nhận biết.

Hãy tưởng tượng hai bản nháp cùng chờ gửi. Một bản dành cho khách hàng từ tài khoản công việc, bản còn lại dành cho gia đình từ tài khoản cá nhân. Hai nút “Duyệt” giống hệt nhau là chưa đủ. Mỗi mục cần nêu người nhận, tài khoản, nội dung và cuộc trò chuyện nguồn. Sau khi người dùng chọn một mục, những mục khác vẫn phải giữ nguyên trạng thái chờ.

Danh sách tác vụ nên cho phép mở chi tiết, sửa, từ chối hoặc quay lại sau. Khi một tác vụ đang chờ, hệ thống có thể tiếp tục công việc độc lập khác nếu điều kiện cho phép, nhưng không được làm mất điểm quyết định ban đầu. Bài Điều khiển AI agent trên điện thoại trình bày rộng hơn cách tập hợp tác vụ đang chạy, đang chờ và đã hoàn tất vào một nơi dễ kiểm tra.

Áp dụng mẫu thiết kế cho các thao tác trên điện thoại

Cùng một nguyên tắc xác nhận cần được điều chỉnh theo từng loại thao tác. Với tin nhắn, dữ kiện chính là người nhận, tài khoản, nội dung và tệp kèm theo. Với cài đặt, giao diện phải cho thấy giá trị hiện tại, giá trị mới và ảnh hưởng dự kiến. Với tệp, cần nêu tên, vị trí, thao tác sao chép, di chuyển hay xóa. Với điều hướng, người dùng cần nhìn thấy địa chỉ đích và ứng dụng bản đồ trước khi bắt đầu.

Đối với thao tác chỉ đọc, phản hồi sau khi thực hiện thường quan trọng hơn hộp xác nhận trước. Mở một ứng dụng được hỗ trợ hoặc đọc trạng thái đang hiển thị có thể hoàn tất rồi báo kết quả. Khi yêu cầu chuyển sang giao tiếp bên ngoài, chỉnh dữ liệu, thay đổi thiết bị hoặc xóa nội dung, điểm xem trước trở nên cần thiết. Thiết kế vì thế đi theo tác động thực tế chứ không theo số bước mà tác nhân dự kiến thực hiện.

Trong FoneClaw, chúng tôi áp dụng mô hình này cho những tác vụ Android được hỗ trợ. Một yêu cầu có thể bắt đầu bằng giọng nói, được tách thành các bước và hiển thị trạng thái trong suốt quá trình. Khi công cụ cần quyền, hệ thống đưa người dùng tới đường phục hồi phù hợp. Khi thao tác cần xác nhận, giao diện dừng tại đúng bước với dữ liệu cụ thể. Kết quả cuối được đưa ra để người dùng kiểm tra thay vì chỉ báo rằng tác vụ đã chạy.

Nút bấm cũng cần dùng động từ cụ thể. “Gửi tin nhắn”, “Tạo sự kiện”, “Mở chỉ đường”, “Áp dụng cài đặt” hoặc “Xóa tệp” truyền đạt hậu quả tốt hơn “Đồng ý”. Bên cạnh nút chính nên có lựa chọn sửa hoặc hủy. Với thao tác có thể đảo ngược, thông báo hoàn tất có thể kèm nút hoàn tác trong khoảng thời gian phù hợp.

Cho phép từ chối, sửa, hoàn tác và tiếp quản

Từ chối một đề xuất không nên kết thúc toàn bộ công việc. Người dùng có thể đồng ý với mục tiêu nhưng chưa đồng ý với dữ liệu cụ thể. Vì vậy, giao diện cần phân biệt “Từ chối”, “Sửa” và “Hủy tác vụ”. Từ chối bỏ qua hành động đang đề xuất; sửa giữ lại ngữ cảnh và mở trường cần điều chỉnh; hủy dừng toàn bộ chuỗi đang thực hiện.

Sau khi thao tác hoàn tất, đường phục hồi phụ thuộc vào khả năng đảo ngược. Một bản nháp có thể chỉnh lại. Một sự kiện lịch có thể cập nhật hoặc xóa. Một thay đổi cài đặt có thể đưa về giá trị cũ. Với tác động khó hoàn tác, trọng tâm phải đặt ở bản xem trước và xác nhận trước khi thực hiện. Thông báo kết quả cần nói rõ điều gì đã thay đổi và nơi người dùng có thể kiểm tra.

Thiếu quyền là một trạng thái riêng, không phải lời xác nhận bị từ chối. FoneClaw hiện cải thiện phục hồi quyền để người dùng biết quyền nào cần thiết cho bước hiện tại và có thể tiếp tục sau khi xử lý. Nếu thao tác Home bị gián đoạn, cơ chế phục hồi giúp xác định điểm tiếp tục. Tác vụ vẫn được gắn với phiên và trạng thái ban đầu để tránh áp dụng nhầm quyết định sau khi quay lại.

Tiếp quản bằng cảm ứng là phần bình thường của trải nghiệm trên điện thoại. Khi giao diện ứng dụng thay đổi, dữ liệu còn mơ hồ hoặc người dùng muốn kiểm tra trực tiếp, tác nhân nên giữ nguyên phần đã chuẩn bị và đưa tới màn hình phù hợp. Một thiết kế phê duyệt tốt không đo thành công bằng số lần loại bỏ con người; nó đo bằng việc người dùng có hiểu quyết định, sửa được sai lệch và hoàn thành mục tiêu mà không mất dấu trạng thái hay không.