Khi nhắc đến AI trong ứng dụng doanh nghiệp, nhiều người thường nghĩ ngay đến chatbot:
một ô nhập câu hỏi, một khung trả lời, và người dùng trò chuyện với mô hình ngôn ngữ.
Nhưng với Oracle APEX, cách tiếp cận thú vị hơn là xây dựng một AI Agent
có thể hiểu yêu cầu của người dùng, gọi các hàm PL/SQL phù hợp, đọc dữ liệu, thực hiện tác vụ
và trả kết quả lại trong phạm vi được kiểm soát.
Bài viết này tập trung vào cách thêm AI Agent vào một ứng dụng Oracle APEX đã có sẵn.
Điểm quan trọng không phải là tạo một chatbot đơn giản, mà là thiết kế một lớp agent có thể làm việc
với dữ liệu, PL/SQL APIs, tool calling, phân quyền, logging và các quy trình nghiệp vụ thực tế
trong một ứng dụng APEX.
Thay vì thay thế toàn bộ giao diện APEX, AI Agent có thể trở thành một lớp tương tác mới:
người dùng mô tả việc cần làm bằng ngôn ngữ tự nhiên, còn hệ thống sẽ quyết định cần gọi tool nào,
kiểm tra quyền, thực thi logic và trả về kết quả.
AI Agent trong APEX là gì?
AI Agent không chỉ là chatbot trả lời câu hỏi. Một agent trong ứng dụng doanh nghiệp thường gồm:
- Một mô hình ngôn ngữ lớn để hiểu ý định người dùng.
- Một danh sách tool mà agent được phép sử dụng.
- Các PL/SQL API hoặc web service để đọc và thao tác dữ liệu.
- Một lớp điều phối để quản lý hội thoại, tool call và kết quả trả về.
- Các guardrails để kiểm soát quyền, dữ liệu, thao tác ghi và audit.
Nói đơn giản, agent là một vòng lặp. Người dùng đưa yêu cầu, mô hình phân tích yêu cầu,
nếu cần thì yêu cầu gọi tool, hệ thống kiểm tra và thực thi tool, sau đó kết quả được đưa lại
cho mô hình để trả lời hoặc tiếp tục bước kế tiếp.
Vì sao nên thêm AI Agent vào ứng dụng APEX?
Các ứng dụng APEX sau một thời gian phát triển thường có nhiều page, nhiều report, nhiều form
và nhiều quy trình nghiệp vụ. Người dùng mới có thể mất thời gian để biết nên vào page nào,
lọc dữ liệu ra sao, hoặc thực hiện tác vụ theo thứ tự nào.
AI Agent có thể giúp đơn giản hóa trải nghiệm này. Thay vì phải nhớ menu và thao tác từng bước,
người dùng có thể hỏi:
- “Tìm các issue đang mở liên quan đến khách hàng A.”
- “Liệt kê các câu hỏi chưa trả lời được giao cho tôi.”
- “Tạo task follow-up cho rủi ro này.”
- “Tóm tắt tình trạng dự án trong tuần này.”
Nếu được thiết kế tốt, agent sẽ dùng dữ liệu và logic có sẵn trong ứng dụng APEX để thực hiện
các yêu cầu này một cách có kiểm soát.
Kiến trúc tổng quan: Orchestrator, Dispatcher và Tools
Một kiến trúc agent trong APEX có thể chia thành ba phần chính:
- Orchestrator: quản lý hội thoại, gọi LLM, nhận tool request và đưa kết quả tool lại cho LLM.
- Dispatcher: kiểm tra tool có tồn tại không, tham số có hợp lệ không, người dùng có quyền gọi tool không, rồi mới thực thi.
- Tools: các hàm hoặc procedure PL/SQL thực hiện nghiệp vụ cụ thể.
Trong kiến trúc này, LLM không được phép gọi database trực tiếp. Nó chỉ được yêu cầu gọi những tool
đã được định nghĩa. Dispatcher mới là lớp quyết định tool đó có được chạy hay không.
Tool trong AI Agent nên là gì?
Tool nên đại diện cho các hành động nghiệp vụ rõ ràng. Ví dụ trong ứng dụng quản lý dự án:
- Tìm task theo trạng thái, người phụ trách hoặc dự án.
- Lấy chi tiết một issue.
- Tạo câu hỏi mới cho dự án.
- Cập nhật trạng thái của risk.
- Tạo ghi chú hoặc follow-up action.
- Tìm kiếm ngữ nghĩa trong câu hỏi, issue, risk hoặc tài liệu.
Mỗi tool nên có input rõ ràng, output dạng JSON rõ ràng và được kiểm soát bởi PL/SQL.
Không nên tạo một tool quá rộng kiểu “chạy SQL bất kỳ”, vì như vậy rất khó kiểm soát bảo mật
và tính toàn vẹn dữ liệu.
Dispatcher: lớp bảo vệ quan trọng nhất
Dispatcher là thành phần cực kỳ quan trọng trong AI Agent. Khi LLM yêu cầu gọi một tool,
dispatcher cần kiểm tra ít nhất các điểm sau:
- Tool được yêu cầu có tồn tại trong danh sách cho phép không?
- Tham số truyền vào có đúng kiểu và đúng cấu trúc không?
- Người dùng hiện tại có quyền thực hiện hành động đó không?
- Dữ liệu được yêu cầu có nằm trong phạm vi người dùng được xem không?
- Tool này là đọc dữ liệu hay ghi dữ liệu?
- Có cần người dùng xác nhận trước khi chạy không?
Đây là điểm khác biệt giữa một demo AI đơn giản và một ứng dụng doanh nghiệp thật sự.
LLM có thể đề xuất hành động, nhưng code của bạn mới là nơi quyết định hành động đó có được phép chạy hay không.
Không để AI tự quyết định bảo mật
Một nguyên tắc quan trọng: không bao giờ giao bảo mật cho mô hình AI.
Mô hình có thể hiểu sai, suy luận sai hoặc gọi tool không phù hợp với ngữ cảnh.
Với Oracle APEX, bạn vẫn cần dùng các cơ chế quen thuộc như Authentication, Authorization Scheme,
session state, kiểm tra quyền trong PL/SQL, ràng buộc dữ liệu và audit log.
Agent chỉ là một lớp tương tác mới, không phải lớp thay thế bảo mật.
Nếu một user không được quyền xem một dự án trong UI bình thường, agent cũng không được phép trả dữ liệu
của dự án đó cho user.
Human approval cho thao tác tạo và cập nhật
Một trong những phần nhạy cảm nhất khi xây dựng AI Agent là cho phép agent tạo hoặc cập nhật dữ liệu.
Ví dụ, nếu người dùng nói “tạo task cho các issue này”, mô hình có thể hiểu sai phạm vi và tạo nhiều bản ghi
hơn mong muốn.
Cách an toàn là chia tool thành hai nhóm:
- Read tools: chỉ đọc dữ liệu, ít rủi ro hơn.
- Write tools: tạo, cập nhật hoặc xóa dữ liệu, cần kiểm soát chặt hơn.
Với write tools, nên có cơ chế xác nhận trước khi thực thi. Agent có thể chuẩn bị đề xuất:
“Tôi sẽ tạo 3 task sau đây, bạn có muốn tiếp tục không?”. Chỉ khi người dùng xác nhận,
dispatcher mới gọi procedure thực sự để ghi dữ liệu.
Sau này, khi hệ thống đã ổn định, bạn có thể cấu hình một số tool an toàn hơn để không cần xác nhận.
Nhưng ở giai đoạn đầu, yêu cầu xác nhận cho mọi thao tác ghi là lựa chọn hợp lý.
Vector Search cho tìm kiếm ngữ nghĩa
Một trong những use case mạnh của AI Agent là tìm kiếm ngữ nghĩa.
Thay vì người dùng phải nhớ chính xác từ khóa, họ có thể mô tả điều cần tìm bằng ngôn ngữ tự nhiên.
Ví dụ:
- “Tìm các câu hỏi đang mở liên quan đến California.”
- “Có rủi ro nào liên quan đến deadline không?”
- “Tìm các issue giống với vấn đề khách hàng vừa báo.”
Để làm được điều này, bạn có thể lưu embedding cho các nội dung như câu hỏi, câu trả lời,
issue, risk, ghi chú hoặc tài liệu. Khi nội dung được tạo mới hoặc cập nhật, hệ thống đưa vào queue.
Sau đó một APEX Automation có thể chạy định kỳ để xử lý queue và cập nhật dữ liệu tìm kiếm vector.
Cách này giúp agent tìm đúng nội dung theo ý nghĩa, không chỉ theo keyword.
Logging và audit: phải làm từ đầu
Với AI Agent trong ứng dụng doanh nghiệp, logging không phải phần phụ. Bạn nên ghi lại:
- User nào đã gửi prompt nào.
- LLM đã yêu cầu gọi tool nào.
- Tham số tool là gì.
- Dispatcher cho phép hay từ chối tool call.
- Kết quả tool trả về là gì.
- Agent đã trả lời người dùng ra sao.
- Thao tác nào đã thực sự ghi dữ liệu.
Khi có log đầy đủ, bạn có thể debug, audit, replay lại hội thoại và cải thiện prompt/system instruction.
Nếu không có log, việc điều tra lỗi agent gần như rất khó.
Quản lý context để tránh agent bị “nặng”
Mỗi lần gọi LLM, hệ thống thường gửi lịch sử hội thoại và kết quả các tool call trước đó.
Nếu cuộc hội thoại kéo dài, context ngày càng lớn. Agent có thể chậm hơn, tốn token hơn
và dễ bị nhiễu bởi thông tin cũ.
Vì vậy, khi thiết kế agent, bạn nên có giới hạn:
- Giới hạn số lượt hội thoại.
- Giới hạn kích thước JSON trả về từ tool.
- Tóm tắt context cũ nếu cần.
- Không trả về quá nhiều trường không cần thiết.
- Chặn tiếp tục hội thoại nếu context vượt ngưỡng an toàn.
Tool output nên ngắn gọn, đúng mục đích và có cấu trúc rõ ràng.
Đừng đưa toàn bộ bản ghi lớn vào context nếu agent chỉ cần vài trường chính.
PL/SQL API phải được thiết kế như public contract
Khi viết PL/SQL API cho agent, đừng giả định rằng người gọi luôn là một page APEX cụ thể.
Trong tương lai, API đó có thể được gọi bởi agent, automation, job, integration hoặc một service khác.
Vì vậy, PL/SQL API cần tự bảo vệ chính nó:
- Validate input đầy đủ.
- Kiểm tra quyền ở phía server.
- Không phụ thuộc quá nhiều vào UI state.
- Trả lỗi rõ ràng, có thể xử lý được.
- Không để lỗi nội bộ lộ trực tiếp ra cho người dùng cuối.
- Ghi log khi có thao tác quan trọng.
Đây cũng là một thói quen tốt khi phát triển ứng dụng APEX nói chung, không chỉ riêng AI Agent.
Gợi ý áp dụng cho Dokhala hoặc ứng dụng APEX của bạn
Nếu bạn đang xây dựng hệ thống học Oracle APEX, POS, quản lý tài liệu hoặc cộng đồng,
AI Agent có thể bắt đầu từ các use case nhỏ:
- Hỏi đáp tài liệu Oracle APEX tiếng Việt.
- Tìm bài học phù hợp theo trình độ người dùng.
- Tìm bài blog liên quan đến một vấn đề kỹ thuật.
- Tóm tắt nội dung một module học.
- Gợi ý bước tiếp theo cho người học.
- Trong POS: tìm sản phẩm, kiểm tồn kho, tóm tắt doanh thu, phát hiện đơn bất thường.
Không nên bắt đầu bằng việc cho agent tạo hoặc sửa dữ liệu quan trọng ngay.
Hãy bắt đầu với read-only tools, sau đó thêm write tools có xác nhận khi hệ thống đã đủ ổn định.
Một lộ trình triển khai đơn giản
Bạn có thể triển khai AI Agent trong APEX theo từng bước:
- Chọn một use case nhỏ, ví dụ tìm kiếm tài liệu hoặc hỏi đáp project.
- Thiết kế bảng lưu conversation và message.
- Viết 2–3 read-only PL/SQL tools.
- Viết dispatcher để validate tool call và quyền truy cập.
- Gọi LLM API thông qua PL/SQL hoặc ORDS service.
- Log toàn bộ prompt, tool call, response và lỗi.
- Thêm human approval cho write tools nếu cần.
- Đo lường, review log và cải thiện tool/schema/prompt.
Cách làm từng bước giúp giảm rủi ro và dễ học hơn so với việc cố xây một agent quá lớn ngay từ đầu.
Kết luận
Thêm AI Agent vào Oracle APEX không có nghĩa là bỏ giao diện hiện tại.
Thay vào đó, agent có thể trở thành một lớp tương tác mới giúp người dùng thực hiện công việc nhanh hơn,
tìm dữ liệu dễ hơn và giảm số bước thao tác trong những workflow phức tạp.
Tuy nhiên, để dùng trong ứng dụng doanh nghiệp, agent cần được thiết kế cẩn thận.
Bảo mật, phân quyền, validation, human approval, logging và audit phải nằm trong code của bạn,
không được giao cho mô hình AI tự xử lý.
Khi kết hợp đúng giữa Oracle APEX, PL/SQL APIs, tool calling và guardrails,
AI Agent có thể trở thành một phần rất mạnh trong các ứng dụng APEX hiện đại.