Bài 7 — Kiến trúc & điều phối: dựng luồng agent nhiều hệ thống ổn định

Đã đọc 0/8 mục · còn khoảng 3 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Nghiệp vụ thật hiếm khi chạm một hệ thống. Một yêu cầu "tạo đơn cho khách VIP" có thể phải: tra khách (CRM) → kiểm tồn (ERP-DB) → tạo đơn (staging table) → in phiếu (RPA) → gửi SMS. Bài này ghép các mảnh của 6 bài trước thành một kiến trúc điều phối vững.

Lớp integration hub: agent không gọi hệ thống trực tiếp

Đừng để agent giữ chi tiết từng hệ thống. Dựng một integration layer (hub) đứng giữa:

[Agent] --(tool goi)--> [Integration Hub] --> CRM (API)
                                          --> ERP (DB view)
                                          --> Staging (INSERT)
                                          --> RPA bridge

Agent chỉ thấy các tool nghiệp vụ (tra_khach, kiem_ton, tao_don). Hub quyết định tool đó chạm hệ thống nào, qua tầng nào. Đổi backend (ví dụ ERP có API mới) chỉ sửa trong hub, agent không đổi.

Orchestration: workflow cố định vs agent tự quyết

Hai kiểu điều phối, chọn theo mức độ rủi ro:

Workflow cố định (deterministic): các bước nghiệp vụ quan trọng (tạo đơn, xuất kho) nên đi theo một quy trình do bạn code cứng. Agent chỉ điền tham số, không tự bịa thứ tự bước.
Agent tự quyết (agentic): chỉ cho phần linh hoạt như hội thoại, phân loại yêu cầu, chọn tool nào để tra cứu.

Quy tắc: việc càng ảnh hưởng dữ liệu/tiền bạc, càng ít để agent tự do.

Saga: xử lý giao dịch xuyên nhiều hệ thống

Bạn không thể "rollback" xuyên ERP + CRM + RPA như một transaction DB. Dùng mẫu Saga: mỗi bước có một hành động bù trừ (compensating action) nếu bước sau thất bại.

Buoc 1: tao don staging      -> bu: xoa don staging
Buoc 2: tru ton kho          -> bu: hoan ton kho
Buoc 3: in phieu (RPA)  FAIL -> chay bu buoc 2, roi bu buoc 1
         -> bao nguoi xu ly thu cong

Nếu bước RPA in phiếu lỗi, ta hoàn tồn kho, xóa đơn staging, và báo người — thay vì để dữ liệu "nửa vời".

Đồng bộ dữ liệu: real-time vs batch

Real-time (gọi khi cần): dữ liệu luôn mới, nhưng phụ thuộc hệ thống sống. Dùng cho tra cứu tức thời.
Batch/cache (đồng bộ định kỳ ra store riêng): giảm tải legacy, nhanh, chịu được khi legacy sập — nhưng có độ trễ. Dùng cho dữ liệu ít đổi (danh mục sản phẩm, bảng giá).

Mẹo phổ biến: cache danh mục vào một store riêng (Redis/Postgres) để agent tra nhanh, chỉ gọi ERP real-time cho tồn kho tức thời.

Khung thiết kế một luồng nhiều hệ thống

Vẽ sequence: yêu cầu → những hệ thống nào, theo thứ tự nào.
Đánh dấu bước nào đọc (an toàn) và bước nào ghi (cần Saga + idempotency).
Chọn deterministic cho các bước ghi, agentic cho phần hội thoại.
Định nghĩa compensating action cho mỗi bước ghi.
Quyết định real-time hay cache cho từng nguồn dữ liệu.
Đặt điểm human-in-the-loop ở đâu (hành động rủi ro cao).

Sai lầm thường gặp

Để agent gọi thẳng nhiều hệ thống, không có hub → thay đổi backend là phải sửa cả agent.
Cho agent tự do quyết thứ tự bước ghi → thao tác lộn xộn, khó tái hiện lỗi.
Không có compensating action → giao dịch dở dang khi một bước fail (đã trừ kho nhưng chưa có đơn).
Gọi real-time cho mọi thứ → quá tải legacy, chậm, sập là chết cả luồng.
Cache dữ liệu hay đổi (tồn kho) rồi bán vượt hàng → sai lệch nghiệp vụ.

Tổng kết

Luồng nhiều hệ thống cần một integration hub che chi tiết, workflow cố định cho bước quan trọng, mẫu Saga với hành động bù trừ để xử lý thất bại xuyên hệ thống, và chiến lược cache/real-time hợp lý. Kiến trúc tốt biến một mớ kết nối mong manh thành một luồng vận hành đoán trước được.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi