AI Agents sẽ thay thế UI hay định nghĩa lại giao diện người dùng?

Khi AI Agents ngày càng mạnh hơn, một câu hỏi bắt đầu xuất hiện trong giới phát triển phần mềm doanh nghiệp: liệu giao diện người dùng truyền thống có còn cần thiết không?

Nếu người dùng có thể nói với agent: “Tạo khách hàng mới, lập đơn hàng, gửi phê duyệt và nhắc tôi tuần sau nếu chưa ký”, thì có còn cần nhiều màn hình, form, button, menu và wizard như hiện nay không?

Câu trả lời thực tế có lẽ không phải là “UI sẽ biến mất”. Đúng hơn, AI Agents sẽ làm thay đổi vai trò của UI. Một phần giao diện nhập liệu lặp lại có thể giảm đi, nhưng một loại giao diện mới sẽ trở nên quan trọng hơn: giao diện để giám sát, kiểm tra, phê duyệt, giải thích, can thiệp và kiểm soát những gì agent đang làm.

Vì sao ứng dụng doanh nghiệp hiện nay có nhiều màn hình?

Trong nhiều năm, ứng dụng doanh nghiệp được thiết kế quanh một giả định rất quen thuộc: người dùng là người tự vận hành hệ thống.

Người dùng mở menu, vào đúng page, nhập dữ liệu, chọn giá trị trong LOV, bấm Save, chuyển sang màn hình tiếp theo, kiểm tra trạng thái, gửi phê duyệt, rồi tiếp tục theo quy trình.

Cách thiết kế này không sai. Nó phù hợp với giai đoạn phần mềm cần con người chuyển đổi ý định nghiệp vụ thành các thao tác mà máy tính có thể hiểu được.

Ví dụ, khi muốn tạo một đơn hàng, người dùng phải biết:

• Vào màn hình khách hàng ở đâu.
• Kiểm tra khách hàng đã tồn tại chưa.
• Tạo khách hàng mới nếu chưa có.
• Chọn điều khoản thanh toán.
• Chọn sản phẩm.
• Nhập số lượng.
• Kiểm tra giá.
• Lưu đơn hàng.
• Gửi phê duyệt.

Nói cách khác, UI truyền thống là nơi người dùng phải tự chia nhỏ mục tiêu nghiệp vụ thành nhiều bước vận hành hệ thống.

AI Agent thay đổi giả định này như thế nào?

AI Agent đặt ra một giả định mới: người dùng không nhất thiết phải tự làm từng bước. Người dùng có thể mô tả mục tiêu, còn agent sẽ hiểu yêu cầu, lấy ngữ cảnh, xác định các bước cần làm và thực hiện một phần công việc thay cho người dùng.

Ví dụ thay vì đi qua nhiều màn hình, người dùng có thể nói:

Tạo khách hàng Acme nếu chưa tồn tại.
Sau đó tạo đơn hàng 1.000 sản phẩm A100 theo bảng giá khách hàng mới.
Nếu tổng tiền vượt hạn mức, gửi phê duyệt cho quản lý kinh doanh.

Với mô hình cũ, người dùng phải tự biết từng bước. Với agent, hệ thống có thể tự chia nhỏ yêu cầu thành các hành động:

• Kiểm tra khách hàng Acme đã có chưa.
• Tạo khách hàng nếu chưa tồn tại.
• Lấy bảng giá phù hợp.
• Tạo đơn hàng.
• Kiểm tra hạn mức.
• Tạo workflow phê duyệt nếu cần.
• Trả lại bản tóm tắt cho người dùng.

Đây là thay đổi rất lớn. Ứng dụng không còn chỉ xoay quanh page và form. Ứng dụng bắt đầu xoay quanh mục tiêu, hành động, ngữ cảnh và kết quả.

UI không biến mất, UI đổi vai trò

Vì sao “chỉ cần một ô chat” là chưa đủ?

Nhiều người hình dung tương lai của phần mềm là một màn hình chỉ có một ô nhập lệnh. Người dùng nói điều mình muốn, agent làm phần còn lại.

Với một số tác vụ đơn giản, cách này có thể rất hiệu quả.

Ví dụ:

• “Tóm tắt doanh thu tháng trước theo khu vực.”
• “Tạo ticket hỗ trợ từ email này.”
• “Đánh dấu khách hàng này cần gọi lại.”
• “Tìm các đơn hàng chưa giao trong tuần này.”

Nhưng với các tác vụ quan trọng, chỉ một ô chat là không đủ. Người dùng không thể tin tưởng hoàn toàn nếu không thấy:

• Agent sắp thay đổi bản ghi nào.
• Dữ liệu nào được dùng làm cơ sở quyết định.
• Giả định nào agent đã đưa ra.
• Trường hợp nào agent không chắc chắn.
• Hành động nào cần phê duyệt.
• Có thể rollback hoặc sửa lại không.

Vì vậy, tương lai không đơn giản là “mọi thứ thành chat”. Tương lai hợp lý hơn là sự kết hợp giữa chat, form, report, workflow, audit log, dashboard trạng thái và các màn hình kiểm soát.

Những phần UI có thể bị giảm mạnh

AI Agents có thể làm giảm vai trò của các màn hình chỉ tồn tại để người dùng nhập dữ liệu theo quy trình cứng.

Ví dụ:

• Màn hình tạo bản ghi đơn giản.
• Form cập nhật trạng thái lặp lại.
• Wizard nhiều bước nhưng logic không phức tạp.
• Màn hình tìm kiếm rồi copy dữ liệu sang màn hình khác.
• Report chỉ dùng để lọc dữ liệu cơ bản.
• Các thao tác admin lặp lại hằng ngày.

Những phần này không biến mất ngay, nhưng có thể được “nén lại”. Thay vì người dùng đi qua năm màn hình, agent có thể thực hiện phần lớn thao tác, rồi chỉ hiển thị kết quả cuối cùng hoặc yêu cầu xác nhận.

Những phần UI sẽ quan trọng hơn

Khi agent làm nhiều việc hơn, những phần UI sau sẽ quan trọng hơn:

• Preview: xem agent sắp làm gì trước khi thực hiện.
• Approval: phê duyệt hành động có rủi ro.
• Exception handling: xử lý các trường hợp agent không chắc chắn.
• Audit trail: xem agent đã gọi tool nào, thay đổi gì, lúc nào.
• Rollback: khôi phục hoặc sửa kết quả sai.
• Policy control: giới hạn agent được phép làm gì.
• Monitoring: theo dõi các tác vụ agent đang chạy nền.
• Explanation: hiểu vì sao agent đề xuất hành động đó.

Đây vẫn là UI, nhưng không còn là UI kiểu “người dùng tự lái từng bước”. Đây là UI kiểu “người dùng giám sát và kiểm soát hệ thống tự động”.

Điều này có ý nghĩa gì với Oracle APEX?

Oracle APEX vốn rất mạnh trong việc xây ứng dụng dữ liệu, form, report, workflow và dashboard. Khi AI Agents xuất hiện, APEX không mất vai trò. Ngược lại, APEX có thể trở thành một nền tảng rất tốt để xây giao diện kiểm soát agent.

Nhưng để làm được điều đó, developer APEX cần thay đổi cách thiết kế. Không nên xem APEX chỉ là công cụ tạo CRUD page thật nhanh. Nên xem APEX là lớp ứng dụng nơi con người kiểm soát các hành động tự động hóa.

APEX có nhiều thành phần phù hợp với mô hình này:

• Interactive Report để xem kết quả và audit log.
• Interactive Grid để kiểm tra và chỉnh dữ liệu.
• Workflow và Approvals để xử lý human-in-the-loop.
• REST Data Source để kết nối hệ thống bên ngoài.
• APEX Automations để chạy tác vụ nền.
• Background processing để xử lý agent task dài.
• Notifications để báo trạng thái cho user.
• Authorization Scheme để giới hạn quyền hành động.

Từ Page Process sang Agent-ready APIs

Một thay đổi rất quan trọng là business logic không nên bị khóa chặt trong Page Process.

Nếu logic tạo đơn hàng chỉ nằm trong một process của Page 10, agent rất khó dùng lại logic đó một cách rõ ràng. Agent không nên “click button” thay người dùng để kích hoạt Page Process.

Cách tốt hơn là đưa logic nghiệp vụ vào package PL/SQL hoặc ORDS endpoint rõ ràng.

Ví dụ:

order_pkg.create_order(
  p_customer_id => ...,
  p_item_id     => ...,
  p_quantity    => ...,
  p_requested_by => ...
);

Sau đó UI APEX gọi package này, và agent cũng có thể gọi thông qua một tool được kiểm soát.

Điều này tạo ra kiến trúc sạch hơn:

• UI không chứa toàn bộ business logic.
• Agent có tool rõ ràng để gọi.
• Validation nằm ở server-side.
• Quyền truy cập được kiểm soát tập trung.
• Dễ audit và test hơn.

Human-in-the-loop là trung tâm của thiết kế mới

Trong các hệ thống doanh nghiệp, không phải hành động nào agent cũng được tự làm. Một số hành động cần con người phê duyệt.

Ví dụ:

• Tạo đơn hàng giá trị lớn.
• Thay đổi hạn mức tín dụng.
• Đóng kỳ kế toán.
• Hủy hợp đồng.
• Cập nhật thông tin ngân hàng nhà cung cấp.
• Xóa hoặc vô hiệu hóa tài khoản người dùng.

Với APEX, các hành động này có thể được đưa vào Workflow hoặc Unified Task List. Agent chuẩn bị đề xuất, thu thập dữ liệu, ghi lý do, sau đó tạo task cho người có thẩm quyền.

Người dùng không còn phải tự nhập từng bước, nhưng vẫn giữ quyền quyết định ở điểm quan trọng.

Agent task thường là bất đồng bộ

Nhiều tác vụ agent không hoàn thành ngay trong một request. Agent có thể cần gọi nhiều hệ thống, đọc tài liệu, kiểm tra dữ liệu, gọi API, đợi response hoặc chạy một chuỗi tool.

Vì vậy, thiết kế UI theo kiểu đồng bộ truyền thống có thể không đủ. APEX app nên có cách hiển thị trạng thái tác vụ:

• Agent task đang chạy.
• Đã gọi tool nào.
• Bước nào thành công.
• Bước nào lỗi.
• Có cần user can thiệp không.
• Kết quả cuối cùng là gì.

Một bảng như AGENT_TASKS và AGENT_TASK_LOGS có thể rất hữu ích.

AGENT_TASKS
- task_id
- requested_by
- task_type
- status
- created_at
- completed_at
- summary

AGENT_TASK_LOGS
- log_id
- task_id
- step_name
- tool_name
- status
- message
- created_at

APEX có thể hiển thị các bảng này bằng report, timeline hoặc dashboard. Đây chính là UI mới: không phải để nhập liệu, mà để quan sát agent đang làm gì.

Audit trail là yếu tố bắt buộc

Với tác vụ đơn giản, chỉ cần biết kết quả có thể là đủ. Nhưng với môi trường doanh nghiệp, đặc biệt là tài chính, nhân sự, y tế, pháp lý hoặc procurement, audit trail là bắt buộc.

Khi agent thực hiện hành động, hệ thống nên lưu:

• Ai yêu cầu agent làm việc.
• Agent nhận yêu cầu gì.
• Agent đã gọi tool nào.
• Input và output quan trọng của từng tool.
• Bản ghi nào bị thay đổi.
• Validation nào đã chạy.
• Confidence hoặc lý do agent chưa chắc chắn.
• Ai phê duyệt nếu có.
• Kết quả cuối cùng.

Không có audit trail, người dùng sẽ khó tin agent. Có audit trail tốt, UI trở thành nơi tạo niềm tin.

Thiết kế agent boundaries trong APEX

Một agent không nên được phép làm mọi thứ trong ứng dụng. Developer cần thiết kế ranh giới rõ ràng:

• Agent được gọi tool nào?
• Tool nào chỉ đọc dữ liệu?
• Tool nào được phép ghi dữ liệu?
• Tool nào cần approval?
• Tool nào bị cấm trong production?
• User nào được phép yêu cầu agent chạy tool nào?

Trong APEX, các ranh giới này nên được thực thi ở server-side:

• PL/SQL package kiểm tra quyền.
• ORDS endpoint yêu cầu authentication và authorization.
• Database role và privilege được giới hạn.
• Workflow xử lý approval cho hành động quan trọng.
• Log đầy đủ các tool invocation.

Không nên chỉ dựa vào prompt để nói với agent “đừng làm điều này”. Prompt là hướng dẫn, không phải lớp bảo mật.

Ví dụ: agent tạo đơn hàng trong APEX

Giả sử người dùng nhập:

Tạo đơn hàng cho khách hàng Acme gồm 100 sản phẩm A100.
Nếu tổng tiền vượt 50 triệu thì gửi phê duyệt.

Hệ thống có thể xử lý như sau:

1. Agent gọi tool kiểm tra khách hàng Acme.
2. Agent gọi tool kiểm tra sản phẩm A100.
3. Agent gọi tool tính giá và tổng tiền.
4. Nếu tổng tiền dưới ngưỡng, tạo đơn hàng nháp.
5. Nếu tổng tiền vượt ngưỡng, tạo workflow phê duyệt.
6. APEX hiển thị preview đơn hàng và trạng thái phê duyệt.
7. Người có quyền approve hoặc reject trong Unified Task List.

Ở đây, agent không thay thế UI hoàn toàn. Agent giảm thao tác tạo đơn hàng, còn UI đảm nhận phần preview, approval, audit và exception.

Ví dụ: agent xử lý report và phân tích dữ liệu

Một user có thể hỏi:

So sánh doanh thu tháng này với cùng kỳ năm trước,
nhóm theo chi nhánh và chỉ ra các chi nhánh giảm trên 10%.

Agent có thể tạo hoặc chạy query phù hợp, nhưng UI vẫn cần hiển thị kết quả bằng:

• Report có filter rõ ràng.
• Biểu đồ so sánh.
• Danh sách chi nhánh giảm mạnh.
• Giải thích công thức tính.
• Nút export hoặc lưu view.

Với dữ liệu phân tích, chat giúp đặt câu hỏi nhanh. Nhưng report và chart vẫn rất quan trọng để kiểm tra, so sánh và ra quyết định.

Thiết kế UI cho agent cần những thành phần nào?

Một APEX app có agent nên cân nhắc các thành phần UI sau:

• Prompt panel: nơi người dùng mô tả mục tiêu.
• Suggested actions: các hành động mẫu để user không phải gõ từ đầu.
• Preview region: hiển thị agent sắp làm gì.
• Approval task: nơi phê duyệt hành động quan trọng.
• Status timeline: cho biết agent đang ở bước nào.
• Exception queue: danh sách việc agent không xử lý được.
• Audit log: lịch sử tool calls và thay đổi dữ liệu.
• Rollback/correction: cách sửa hoặc đảo ngược kết quả.

Đây là cách nghĩ khác với việc chỉ tạo thêm form và report. Developer cần thiết kế trải nghiệm kiểm soát, không chỉ trải nghiệm nhập liệu.

Không phải workflow nào cũng nên agent hóa

AI Agents phù hợp nhất với các công việc:

• Lặp lại nhiều lần.
• Có quy tắc rõ ràng.
• Có thể kiểm tra được kết quả.
• Có rủi ro thấp hoặc có approval rõ ràng.
• Cần tổng hợp thông tin từ nhiều nơi.
• Cần giảm thao tác thủ công cho người dùng.

Nhưng không phải workflow nào cũng nên giao cho agent. Cần thận trọng với:

• Quyết định tài chính lớn.
• Thao tác pháp lý hoặc compliance.
• Xử lý dữ liệu cá nhân nhạy cảm.
• Thay đổi bảo mật hoặc phân quyền.
• Xóa dữ liệu hoặc thay đổi không thể rollback.
• Quy trình có nhiều ngoại lệ chưa được chuẩn hóa.

Với các phần này, agent có thể hỗ trợ phân tích và chuẩn bị đề xuất, nhưng con người vẫn cần kiểm soát chặt.

Câu hỏi thiết kế mới cho APEX developer

Trước đây, khi nhận yêu cầu, developer thường hỏi:

• Cần những page nào?
• Form nào?
• Report nào?
• Button nào?
• Process nào chạy khi submit?

Trong mô hình agent, bộ câu hỏi nên thay đổi:

• Phần nào của workflow thật sự cần con người nhập liệu?
• Phần nào agent có thể tự suy luận từ ngữ cảnh?
• Hành động nào cần phê duyệt?
• Tool nào agent được phép gọi?
• Kết quả nào cần preview trước khi ghi dữ liệu?
• Log nào cần lưu để audit?
• Nếu agent sai, user sửa hoặc rollback bằng cách nào?

Đây là sự chuyển dịch từ thiết kế theo page sang thiết kế theo hành động, kiểm soát và niềm tin.

Kiến trúc gợi ý cho APEX Agent Control Plane

Một kiến trúc thực tế có thể gồm:

• APEX UI: prompt, dashboard, approval, audit, exception handling.
• Agent service: điều phối yêu cầu và gọi tool.
• PL/SQL packages: business logic chuẩn, có validation và authorization.
• ORDS APIs: expose tool cho agent hoặc hệ thống bên ngoài.
• Workflow: xử lý human approval.
• Agent log tables: lưu task, step, tool call, kết quả và lỗi.
• Security layer: kiểm soát user, role, policy và quyền hành động.

Trong mô hình này, APEX vẫn là trung tâm trải nghiệm người dùng. Nhưng trải nghiệm đó không chỉ là CRUD. Nó là control plane cho hành động thông minh và có kiểm soát.

Best practice khi đưa AI Agents vào APEX UI

• Không để business logic quan trọng chỉ nằm trong Page Process.
• Đưa logic nghiệp vụ vào PL/SQL package hoặc ORDS API rõ ràng.
• Thiết kế tool nhỏ, deterministic và có input/output rõ ràng.
• Áp dụng authorization ở server-side cho mọi tool quan trọng.
• Dùng workflow cho hành động rủi ro cao.
• Luôn có preview trước khi agent ghi dữ liệu quan trọng.
• Lưu agent task log và tool invocation log.
• Không dùng prompt như lớp bảo mật.
• Thiết kế exception queue để user xử lý việc agent không chắc chắn.
• Cho phép user hiểu agent đã làm gì và vì sao.

Checklist khi thiết kế UI có AI Agent

• Agent có được phép thực hiện hành động này không?
• User hiện tại có quyền yêu cầu hành động này không?
• Có cần preview trước khi thực hiện không?
• Có cần approval không?
• Có log đủ để audit không?
• Có cách rollback hoặc sửa kết quả không?
• Có hiển thị rõ trạng thái agent đang chạy không?
• Có xử lý trường hợp agent không chắc chắn không?
• Có phân biệt read-only tool và write tool không?
• Có test với dữ liệu thật nhưng an toàn chưa?

Kết luận

AI Agents sẽ không đơn giản xóa bỏ giao diện người dùng. Nhưng chúng sẽ làm thay đổi rất mạnh lý do UI tồn tại.

Nhiều màn hình nhập liệu lặp lại, nhiều wizard cứng nhắc và nhiều thao tác thủ công có thể được rút gọn khi agent có thể hiểu mục tiêu và thực hiện công việc thay người dùng.

Tuy nhiên, trong môi trường doanh nghiệp, UI vẫn rất cần thiết. UI sẽ trở thành nơi người dùng biểu đạt ý định, xem trước hành động, phê duyệt thay đổi, theo dõi trạng thái, xử lý ngoại lệ, xem audit trail và giữ quyền kiểm soát.

Với Oracle APEX, đây là một cơ hội lớn. APEX có đầy đủ nền tảng để xây dựng giao diện kiểm soát agent: reports, workflows, approvals, automations, ORDS integration, PL/SQL packages, authorization và audit UI.

Vì vậy, câu hỏi không phải là “AI Agents có thay thế UI không?”. Câu hỏi đúng hơn là: chúng ta sẽ thiết kế UI như thế nào khi người dùng không còn phải tự làm từng bước, nhưng vẫn cần hiểu, kiểm soát và tin tưởng những gì hệ thống đang làm?