Oracle đưa Supervisor Agent vào Workflow: orchestration không còn là “hộp đen”

Ngày 9/9/2026, Oracle đăng hướng dẫn về thay đổi trong AI Agent Studio: Workflow Agent đang trở thành nền tảng cho thế hệ phát triển agent tiếp theo, còn mô hình Supervisor được đưa vào bên trong một graph có thể quan sát và chỉnh sửa.

Thay đổi này đáng chú ý vì nó chạm đúng một vấn đề thường gặp khi doanh nghiệp triển khai multi-agent. Supervisor có thể tự phân việc cho các agent chuyên môn, nhưng đường đi của một yêu cầu dễ trở thành “hộp đen”: khó biết agent nào chạy trước, dữ liệu chuyển qua đâu, nhánh nào gây lỗi và vì sao thời gian phản hồi tăng.

Workflow biến orchestration thành một cấu trúc hiển thị. Đội triển khai có thể định nghĩa agent, mô hình ngôn ngữ, tool, hàm nghiệp vụ, Code node, điều kiện, switch, vòng lặp, nhánh song song và chuỗi nhiều node. Supervisor không biến mất; nó có thể nằm trong Multi Agent node để giữ khả năng định tuyến động, trong khi phần còn lại của quy trình vẫn được khóa bằng logic rõ ràng.

Oracle đang thay đổi điều gì?

Theo Oracle, một Supervisor Agent hiện có thể được migrate sang Workflow Agent mà không phải xây lại từ đầu. Hệ thống mang theo hành vi nghiệp vụ, prompt, worker agent, tool và output hiện có, sau đó biểu diễn chúng thành các node và cạnh trên graph.

Lộ trình được Oracle mô tả gồm ba bước:

1. Convert: chuyển Supervisor hiện tại thành Workflow.
2. Inspect: kiểm tra node, dependency, data flow và xác nhận hành vi cũ được giữ lại.
3. Refine: tối ưu từng điểm — chẳng hạn chạy các tác vụ độc lập song song, chuyển phép tính sang Code node, thêm vòng lặp hoặc sửa mapping.

Điểm quan trọng là migration chỉ tạo ra điểm bắt đầu dễ quan sát hơn. Oracle không khuyến nghị bấm chuyển đổi rồi lập tức bỏ hệ thống cũ. Cách an toàn hơn là thay đổi từng phần, test kịch bản liên quan và so sánh kết quả với Supervisor trước khi tiếp tục.

Vì sao “nhìn thấy luồng” quan trọng hơn một giao diện đẹp?

Trong production, một workflow không chỉ cần trả lời đúng. Đội vận hành còn phải biết:

• yêu cầu đã đi qua node nào;
• tool nào được gọi;
• dữ liệu nào được truyền giữa các bước;
• nhánh nào có thể chạy song song;
• kết quả trung gian nào làm thay đổi quyết định;
• lỗi xảy ra ở prompt, mapping, quyền truy cập hay code.

Supervisor thuần động có lợi khi bài toán cần linh hoạt, nhưng càng nhiều worker agent thì việc truy vết càng khó. Graph hiển thị biến hành vi thành thứ mà kỹ sư và chủ sở hữu nghiệp vụ có thể cùng xem. Đây là điều kiện quan trọng để test, bảo trì và phê duyệt thay đổi.

Nói cách khác, giá trị không nằm ở việc kéo-thả node. Giá trị nằm ở khả năng biến một chuỗi quyết định ngầm thành “hợp đồng vận hành” có thể kiểm tra: bước nào được phép linh hoạt, bước nào phải xác định, bước nào cần con người duyệt.

Không phải việc nào cũng cần LLM

Một trong những khuyến nghị thực tế nhất của Oracle là tách đúng loại việc cho đúng node.

Agent hoặc LLM node phù hợp với suy luận, diễn giải, phán đoán theo ngữ cảnh và sinh ngôn ngữ. Code node phù hợp với phép tính, biến đổi dữ liệu, mapping trường và validation có quy tắc. Các tác vụ truy xuất độc lập có thể chạy song song thay vì nối tuần tự.

Ví dụ, một agent xử lý đơn hàng có thể dùng LLM để hiểu yêu cầu tự nhiên của khách, nhưng không nên nhờ LLM cộng tiền, kiểm tra định dạng mã số thuế hay quyết định một trường bắt buộc có bị thiếu không. Các bước đó nên nằm trong code xác định. Khi ba nguồn dữ liệu không phụ thuộc nhau, gọi song song sẽ giúp tổng độ trễ gần với nhánh chậm nhất, thay vì cộng thời gian của cả ba.

Cách phân vai này có thể giảm những lần gọi model không cần thiết, giảm token và làm kết quả dễ dự đoán hơn. Oracle không công bố benchmark chi phí hay độ trễ cho thay đổi này, vì vậy chưa thể gắn một tỷ lệ tiết kiệm chung cho mọi workflow.

Ba rủi ro khi migrate Supervisor

Rủi ro đầu tiên là tin rằng convert đồng nghĩa hoàn tất. Graph được tạo tự động có thể đúng chức năng nhưng chưa tối ưu, khó đọc hoặc chứa các nhánh tuần tự không cần thiết.

Rủi ro thứ hai là tối ưu quá nhiều điểm cùng lúc. Nếu vừa đổi mapping, vừa thêm loop, vừa chạy song song và thay prompt, đội triển khai khó xác định nguyên nhân khi kết quả lệch.

Rủi ro thứ ba là giữ mọi việc trong LLM node. Workflow nhìn có vẻ rõ hơn, nhưng logic cốt lõi vẫn bất định và tốn kém. Chỉ khi code, rule và human gate được dùng đúng chỗ, graph mới thực sự tạo ra kiểm soát.

Đây cũng là tinh thần của bảy giai đoạn AgentOps đưa AI Agent vào production: quan sát, đánh giá và rollback phải đi cùng lúc với thiết kế agent. Một xu hướng tương tự đang xuất hiện ở lớp quản trị runtime, như cách Microsoft chuyển Responsible AI từ tài liệu sang kiểm soát khi agent hành động.

Góc nhìn Học viện AI: orchestration cần hai chế độ, không phải một

Học viện AI cho rằng doanh nghiệp không nên chọn cực đoan giữa “để agent tự quyết” và “mã hóa toàn bộ quy trình”. Workflow tốt có hai chế độ cùng tồn tại:

• Dynamic zone: dùng agent/Supervisor khi cần hiểu ngữ cảnh, chọn chuyên gia hoặc xử lý biến thể khó dự đoán.
• Deterministic zone: dùng code, điều kiện, allowlist và validation khi cần tính đúng, tuân thủ hoặc tạo output ổn định.

Giữa hai vùng phải có interface rõ: dữ liệu đầu vào, schema đầu ra, tiêu chí lỗi và điều kiện bàn giao. Khi graph thể hiện được ranh giới này, đội nghiệp vụ có thể xem agent như một nhân sự AI có quy trình, thay vì một chatbot được cấp thêm tool.

Một cách bắt đầu thực tế là chọn một Supervisor đang vận hành ổn định, migrate sang Workflow, đóng băng hành vi cũ làm baseline rồi chỉ tối ưu một thay đổi mỗi vòng. Đo bốn chỉ số: tỷ lệ hoàn thành, lỗi cần can thiệp, độ trễ và chi phí mỗi lượt. Chỉ mở rộng sau khi graph giúp đội giải thích được kết quả.

Nếu doanh nghiệp muốn thiết kế AI Agent theo luồng có graph, guardrail, human-in-the-loop và KPI production, có thể tham khảo chương trình AI Agent & Workflow Automation của Học viện AI.

Nguồn

• Oracle Fusion Development Center of Excellence, “From Supervisor to Workflow: What’s Changing in Oracle AI Agent Studio”, ngày 9/9/2026: https://blogs.oracle.com/fusioncoe/from-supervisor-to-workflow-whats-changing-in-oracle-ai-agent-studio

Ghi chú kiểm chứng: Bài viết sử dụng hướng dẫn chính thức của Oracle về tính năng và lộ trình migration. Oracle không công bố benchmark chi phí, độ trễ hay tỷ lệ thành công; các khuyến nghị triển khai dưới mục “Góc nhìn Học viện AI” là nhận định biên tập, không phải số liệu của Oracle.