Trần Ngọc Minh

Thời đại của Trải nghiệm Tác nhân (AX – Agent Experience)

Thiết kế cho Trải nghiệm Tác nhân

Các tác nhân AI (AI agents)—từ ChatGPT Operator đến các công cụ lập trình như Devin và Lovable—đang thay đổi cách chúng ta tương tác với ứng dụng. Các tác nhân này có thể điều hướng giao diện, thực hiện yêu cầu và hoàn thành nhiệm vụ thay cho người dùng, thậm chí dần thay thế con người trong việc duyệt web. Đã đến lúc chúng ta cần xây dựng trải nghiệm không chỉ dành cho con người mà còn cho một đối tượng mới: tác nhân tự động (the autonomous agent).

Thay vì chỉ tập trung vào thiết kế trải nghiệm cho người dùng, chúng ta cần cân nhắc cách máy móc có thể truy cập dữ liệu và thực hiện hành động một cách an toàn, minh bạch và có sự đồng ý của người dùng.

Ở cấp độ tổng quát:

  • Tác nhân cần có khả năng “đăng nhập” hoặc chứng minh rằng chúng có quyền thực hiện hành động thay mặt người dùng.
  • Người dùng cần đảm bảo rằng các tác nhân chỉ thực hiện những gì họ cho phép và có cách thu hồi quyền truy cập nếu cần.
  • Các nhà cung cấp dịch vụ cần có cơ chế xác thực và ủy quyền mạnh mẽ để xác nhận sự đồng ý của người dùng và quản lý rủi ro.

Tin tốt là chúng ta đã có một tiêu chuẩn vững chắc để cấp quyền truy cập một cách an toàn, có phạm vi cụ thể và có thể thu hồi: OAuth. Thay vì chia sẻ mật khẩu với mọi ứng dụng hoặc tác nhân mới, OAuth được thiết kế để cấp đúng quyền cho đúng đối tượng theo cách an toàn và chuẩn hóa.

AX: Biên giới mới sau UX và DX

Trong một bài viết gần đây, “Introducing AX: Why Agent Experience Matters“, đồng sáng lập kiêm CEO của Netlify, Mathias Biilmann, lập luận rằng trải nghiệm tác nhân (AX) sẽ trở thành một yếu tố quan trọng ngang hàng với trải nghiệm người dùng (UX) và trải nghiệm nhà phát triển (DX) từng có trước đây. Lịch sử cho thấy:

  • UX (được Don Norman đặt ra vào năm 1993) đã thay đổi cách chúng ta nghĩ về giao diện con người—bao gồm mọi thứ từ trực quan, luồng công việc, đến cách một sản phẩm “cảm nhận” đối với người dùng thực tế.
  • DX (phổ biến vào năm 2011) nhận ra rằng các nhà phát triển cũng là một đối tượng quan trọng. Những nền tảng cung cấp tài liệu tốt hơn, API dễ sử dụng hơn, và ít ma sát hơn đã chứng kiến sự phát triển mạnh mẽ và được chấp nhận rộng rãi.
  • AX đang nổi lên khi các tác nhân AI—được hỗ trợ bởi mô hình ngôn ngữ lớn (LLMs), đầu vào đa phương thức, và khả năng xử lý tác vụ một cách tự động—đang ngày càng trở nên phổ biến. Theo Biilmann, “chúng ta cần tập trung vào AX—tổng thể trải nghiệm mà tác nhân AI sẽ có khi sử dụng một sản phẩm hoặc nền tảng.”

Tác nhân như một động lực mới

Đầu tư vào trải nghiệm tác nhân sẽ trở thành điều tất yếu, khi ngày càng nhiều công ty triển khai các tác nhân AI và người dùng chuyển sang sử dụng sản phẩm thông qua các tác nhân này thay vì trực tiếp tương tác với giao diện người dùng.

  • Tác nhân không chỉ tạo nội dung (generative), mà còn có quyền tự hành động (agency)—tức là chúng có thể chủ động thực hiện các hành động hoặc giao dịch thay vì chỉ phản hồi yêu cầu của người dùng.
  • Những công cụ hoặc nền tảng không phù hợp với LLMs sẽ nhanh chóng tụt lại phía sau, vì con người sẽ dựa vào AI để tối ưu hóa công việc của họ.
  • Các hệ sinh thái mở sẽ có lợi thế hơn so với các nền tảng đóng. Nếu bạn chào đón mọi tác nhân mà người dùng thích—với quy trình khởi động dễ dàng, API mở, và luồng xác thực bảo mật—sản phẩm của bạn sẽ mạnh mẽ hơn và thân thiện với tác nhân hơn.
  • OAuth là chìa khóa để mở ra trải nghiệm tác nhân chất lượng cao, giúp hệ thống của bạn dễ dàng truy cập mà vẫn đảm bảo tính bảo mật.

Xây dựng trải nghiệm tác nhân xuất sắc

Nhiều nguyên tắc cốt lõi của UX và DX vẫn có thể áp dụng vào AX, nhưng một số khía cạnh cần điều chỉnh. Con người có giao diện người dùng (UI) vì chúng ta giỏi trong việc nhận diện ý nghĩa từ biểu tượng và hình ảnh—chúng ta đã giao tiếp bằng hình ảnh từ trước khi có ngôn ngữ viết.

Ngược lại, ngôn ngữ tự nhiên của AI là các biểu diễn số (numerical embeddings)—cả văn bản và hình ảnh đều cần được dịch sang dạng số. Tuy nhiên, hình ảnh không có “tokenization” tự nhiên như văn bản, khiến quá trình xử lý tốn kém hơn. Vì vậy, chúng ta nên thiết kế AX xoay quanh cách giao tiếp mà máy tính có thể xử lý tối ưu, thay vì chỉ dựa vào cách con người giao tiếp. Các trình duyệt web chậm, mã máy khách (client-side) mất thời gian để render—vậy nên ta cần tập trung vào những yếu tố cốt lõi sau:

  1. API rõ ràng, được định nghĩa tốt
    • Một API được thiết kế tốt cho DX sẽ là điểm khởi đầu vững chắc cho AX.
    • Các ứng dụng trước đây không cần API có thể sẽ phải đầu tư vào việc xây dựng API hoặc mở rộng API để đảm bảo tác nhân AI có thể truy cập toàn bộ chức năng.
    • Tài liệu rõ ràng, dữ liệu có cấu trúc tốt, endpoint ổn định giúp tác nhân tương tác với sản phẩm dễ dàng hơn.
  2. Quy trình khởi động đơn giản cho cả người dùng và tác nhân
    • Người dùng và tác nhân nên có trải nghiệm bắt đầu mượt mà, ít ma sát.
    • Một quy trình khởi động được đơn giản hóa—như một lệnh duy nhất hoặc quy trình xác thực OAuth tinh gọn—giúp tác nhân hoạt động nhanh hơn trong khi vẫn giữ quyền kiểm soát cho người dùng.
  3. Hoạt động của tác nhân không bị gián đoạn
    • Khi đã có quyền, tác nhân nên có khả năng vận hành mà không cần quá nhiều thao tác thủ công.
    • Việc khởi chạy một phiên làm việc mới, quản lý tài nguyên, hoặc phân tích dữ liệu nên được tự động hóa để tối đa hóa năng suất.
  4. Xác thực nâng cao khi cần thiết
    • Một số hành động quan trọng vẫn cần sự phê duyệt của con người, chẳng hạn như:
      • Chuyển khoản với số tiền lớn
      • Thực hiện hành động ghi (write) có ảnh hưởng đến mã nguồn sản phẩm
    • Hệ thống nên có luồng xác thực bổ sung, yêu cầu người dùng can thiệp khi thực sự cần thiết.

Khi bạn xây dựng API an toàn, đơn giản hóa onboarding và loại bỏ các điểm nghẽn trong quy trình tác nhân, bạn không chỉ cải thiện trải nghiệm cho AI agents, mà còn giúp người dùng con người có trải nghiệm tốt hơn. Trên thực tế, nhiều quyết định thiết kế nhằm cải thiện AX cũng giúp tăng sự hài lòng của người dùng và khả năng chấp nhận sản phẩm một cách tổng thể.

Tại sao OAuth là giải pháp hoàn hảo cho xác thực tác nhân?

Trong nhiều năm qua, OAuth đã cho phép người dùng “Đăng nhập bằng [nhà cung cấp]” và cấp quyền cho ứng dụng hoặc dịch vụ truy cập dữ liệu của họ. Cơ chế này thường bao gồm token truy cập ngắn hạn, refresh token, và phạm vi quyền hạn cụ thể để xác định chính xác những gì bên thứ ba có thể thực hiện.

Khi tác nhân AI trở thành bên thứ ba, yêu cầu bảo mật cốt lõi vẫn không thay đổi:

  • Đồng ý của người dùng một cách an toàn:
    Người dùng không cần chia sẻ tên đăng nhập và mật khẩu với tác nhân AI. OAuth cung cấp luồng xác thực an toàn, đảm bảo rằng người dùng rõ ràng phê duyệt dữ liệu hoặc hành động mà tác nhân có thể truy cập.
  • Ủy quyền dựa trên token:
    • Tác nhân nhận được token truy cập có thể giới hạn quyền và bị thu hồi khi cần thiết.
    • Điều này bảo vệ thông tin xác thực cốt lõi của người dùng và cho phép quản lý quyền hạn chi tiết, linh hoạt.
  • Hỗ trợ quyền truy cập dài hạn với khả năng thu hồi:
    • Tác nhân AI có thể cần quyền truy cập liên tục vào tài khoản.
    • Với OAuth, người dùng có thể thu hồi quyền của tác nhân bất cứ lúc nào mà không cần đặt lại mật khẩu chính.
  • Xác thực nâng cao khi cần thiết:
    • Đối với các hành động nhạy cảm, tác nhân sẽ yêu cầu sự phê duyệt của con người trước khi tiếp tục.
    • Điều này đảm bảo mức độ bảo mật cao hơn, đặc biệt trong các tác vụ quan trọng như giao dịch tài chính hoặc cập nhật dữ liệu quan trọng.

Không cần phát minh lại bánh xe—OAuth là một tiêu chuẩn bảo mật đã được kiểm chứng và mang đến trải nghiệm quen thuộc trong thế giới mới của tác nhân AI. Tuy nhiên, điều này cũng đồng nghĩa với việc tất cả các ứng dụng cần phải trở thành nhà cung cấp OAuth để cho phép tác nhân truy cập dễ dàng và an toàn.

Tận dụng các luồng OAuth hiện có cho tác nhân AI

Khi nghĩ về OAuth, bạn có thể hình dung một người dùng nhấp vào nút “Đồng ý” trong trình duyệt. Trong nhiều trường hợp, cách này cũng phù hợp để xác thực tác nhân AI. Tuy nhiên, với một số kịch bản tác nhân không có giao diện đồ họa, cần đến các luồng OAuth chuyên biệt để xử lý tương tác một cách mượt mà:

  1. Device Authorization Grant (Device Flow)
    • Thường được sử dụng khi ứng dụng chạy trên một thiết bị khác với thiết bị chính của người dùng (ví dụ: TV).
    • Cách hoạt động:
      • Tác nhân thông báo cho người dùng và cung cấp một liên kết.
      • Người dùng truy cập liên kết này trên thiết bị chính để cấp quyền.
      • Sau khi xác nhận, tác nhân nhận được token OAuth để thực hiện tác vụ.
    • Điều này đảm bảo rằng tác nhân có thể hoạt động ngay cả khi không có trình duyệt hoặc giao diện đồ họa.
  2. CIBA (Client-Initiated Backchannel Authentication)
    • Đây là một luồng xác thực OpenID Connect hữu ích cho các hành động có rủi ro cao (ví dụ: giao dịch chứng khoán lớn).
    • Thay vì dựa vào tác nhân để yêu cầu quyền, dịch vụ (ví dụ: công ty môi giới chứng khoán) có thể thông báo trực tiếp cho người dùng để xác nhận.
    • Điều này đảm bảo rằng người dùng phải xác nhận rõ ràng trước khi tác nhân thực hiện hành động quan trọng.

Việc lựa chọn luồng OAuth phù hợp phụ thuộc vào cách bạn muốn xử lý thông báo cho người dùng, phê duyệt phạm vi quyền hạn và kiểm soát rủi ro. Tuy nhiên, nguyên tắc chung vẫn không thay đổi:
➡ OAuth đã giải quyết triệt để vấn đề ủy quyền cho bên thứ ba—dù đó là con người hay tác nhân AI. trợ tác nhân AI mà vẫn đảm bảo tính minh bạch, kiểm soát của người dùng và bảo mật dữ liệu.

Mọi hệ thống đều cần trở thành nhà cung cấp OAuth

Để hỗ trợ tác nhân AI một cách an toàn và linh hoạt, các ứng dụng và dịch vụ cần:
✅ Triển khai OAuth như một nhà cung cấp, cho phép tác nhân đăng nhập và truy cập dữ liệu theo cách bảo mật.
✅ Cung cấp các luồng OAuth phù hợp tùy vào loại tác nhân và mức độ rủi ro.
✅ Đảm bảo quyền kiểm soát của người dùng, giúp họ dễ dàng quản lý và thu hồi quyền truy cập của tác nhân.

Tương lai của tác nhân AI sẽ phụ thuộc vào khả năng tích hợp và ủy quyền an toàn, và OAuth chính là giải pháp hoàn hảo để hiện thực hóa điều này. 🚀

Nếu không hỗ trợ tác nhân AI, sản phẩm của bạn sẽ tụt lại phía sau

Nếu sản phẩm của bạn không hoạt động liền mạch với các tác nhân AI mà người dùng có thể đang sử dụng, bạn sẽ có nguy cơ mất lợi thế cạnh tranh vào tay các nền tảng chào đón mọi tác nhân và cung cấp trải nghiệm AX (Agent Experience) mượt mà.

Việc trở thành nhà cung cấp OAuth là một phần quan trọng để xây dựng hệ sinh thái mở đó. Với OAuth, ứng dụng của bạn có thể:

✅ Cung cấp các luồng xác thực tiêu chuẩn dựa trên token.
✅ Trao quyền cho người dùng lựa chọn bất kỳ tác nhân AI nào mà họ tin tưởng.
✅ Xác định phạm vi quyền hạn rõ ràng, phân biệt giữa:

  • Truy cập chỉ đọc (read-only) vs. quyền đọc-ghi (read-write).
  • Hành động thông thường vs. hành động có rủi ro cao.
    ✅ Cung cấp cơ chế thu hồi quyền truy cập hoặc yêu cầu xác nhận bổ sung đối với các thao tác nhạy cảm.

➡ Tóm lại, mọi nền tảng đều cần trở thành nhà cung cấp OAuth nếu muốn thu hút tác nhân AI hoạt động trong hệ sinh thái của mình và duy trì lợi thế cạnh tranh.

Đừng cố phát minh lại OAuth

Có rất nhiều ý tưởng về tương lai của tác nhân AI. Nhiều bản demo tác nhân hiện nay chỉ đơn giản là để AI duyệt web như một con người chậm chạp mà không tận dụng OAuth, mặc dù OAuth đã giải quyết bài toán ủy quyền an toàn. Dưới đây là những lý do tại sao không nên tái tạo OAuth từ đầu:

  • Về xác thực tác nhân:
    ❌ Không nên cung cấp tài khoản và mật khẩu cho tác nhân AI—việc này vừa gây bất tiện cho người dùng, vừa là rủi ro bảo mật.
    ✅ OAuth giúp tác nhân xác thực mà không cần mật khẩu, đảm bảo tính an toàn và tiện lợi.
  • Về tương tác không ma sát:
    ❌ Nếu ứng dụng không hỗ trợ API và OAuth, cần phải sử dụng các kỹ thuật RPA (Robotic Process Automation) phức tạp để mô phỏng hành động của con người.
    ✅ Nếu ứng dụng có API tốt và luồng OAuth chuẩn, tác nhân AI có thể hoạt động trơn tru mà không cần mô phỏng thao tác thủ công.
  • Về phạm vi quyền truy cập:
    ❌ Không nên cho phép tác nhân AI làm mọi thứ như một người dùng thực.
    ✅ OAuth cho phép kiểm soát phạm vi quyền hạn (Scopes), giúp hạn chế quyền truy cập chỉ ở mức cần thiết.
  • Về sự đồng ý của người dùng:
    ❌ Các hành động lớn không nên được tự động thực hiện bởi AI mà không có xác nhận từ con người.
    ✅ Với Device Flow hoặc Backchannel Authentication (CIBA), người dùng có thể xác nhận trước khi tác nhân thực hiện các hành động quan trọng.
    👉 Cách tiếp cận này giúp người dùng tin tưởng hơn khi cho phép tác nhân AI hoạt động trên ứng dụng của bạn.

➡ Việc áp dụng các nguyên tắc OAuth giúp bạn tạo ra trải nghiệm tác nhân AI an toàn, mượt mà và tránh phải phát minh lại giải pháp từ đầu mỗi khi xuất hiện một công cụ AI mới.

Thiết kế hệ thống thân thiện với tác nhân AI

Việc chuyển đổi từ ứng dụng dành riêng cho con người sang thiết kế thân thiện với tác nhân AI không cần phải là một cuộc đại tu lớn. Dưới đây là các đề xuất quan trọng:

✅ Cung cấp API rõ ràng, dễ sử dụng cho máy móc

  • Các nền tảng khó sử dụng với LLMs và tác nhân AI sẽ ngày càng kém hấp dẫn.
  • API cần có các endpoint ổn định, dữ liệu có cấu trúc tốt, tài liệu dễ đọc cả với con người và máy.

✅ Xác định quyền truy cập một cách hợp lý

  • Không sử dụng quyền hạn chung chung, thay vào đó chia nhỏ theo cấp độ:
    • “Đọc dữ liệu tài khoản”
    • “Đăng nội dung mới”
    • “Thực hiện giao dịch tài chính lớn”
  • Điều này giúp kiểm soát tác nhân AI một cách an toàn.

✅ Lập kế hoạch lưu trữ và làm mới token OAuth

  • Tác nhân AI có thể lưu trữ token lâu dài, nhưng token cần có phạm vi giới hạn, dễ làm mới và có thể thu hồi ngay lập tức.

✅ Có chiến lược cho các hành động có rủi ro cao

  • Các hành động quan trọng hoặc không thể hoàn tác nên có lớp xác thực bổ sung.
  • Device Flow hoặc Backchannel Authentication (CIBA) có thể được sử dụng để đảm bảo người dùng luôn có mặt trong vòng kiểm soát.

✅ Hướng đến một hệ sinh thái AX mở

  • Hãy thiết kế với giả định rằng người dùng có thể sử dụng bất kỳ tác nhân AI nào.
  • Cung cấp OAuth tiêu chuẩn, cho phép bất kỳ tác nhân nào truy cập mà không cần mã tùy chỉnh phức tạp.

Tương lai của xác thực tác nhân AI

Việc thiết kế hệ thống thân thiện với tác nhân AI có thể nghe có vẻ xa vời, nhưng thực tế, AX đã ở đây, giống như UX và DX đã từng xuất hiện trước đó.

Những nền tảng mở cửa chào đón tác nhân AI, cung cấp API bảo mật, và cho phép người dùng kiểm soát quyền hạn của tác nhân sẽ chiếm ưu thế hơn so với những nền tảng đóng kín hoặc dựa quá nhiều vào thao tác thủ công.

Nguồn

Posted in , , ,