Một AI agent "đơn lẻ" gọi một API rồi trả lời là chuyện dễ. Nhưng nghiệp vụ thật hiếm khi gói gọn trong một lời gọi. Hãy tưởng tượng luồng duyệt đơn hàng B2B: nhận đơn → kiểm tra tồn kho (hệ thống WMS) → giữ hàng → tạo hóa đơn (hệ thống kế toán) → xin phê duyệt của quản lý (hệ thống HR/approval) → thu tiền (payment gateway) → phát lệnh giao hàng (đối tác 3PL). Sáu hệ thống, mỗi hệ thống một API, một tốc độ, một kiểu lỗi.
Orchestration là việc điều phối chuỗi bước đó theo đúng thứ tự, nhớ mình đang ở đâu, xử lý khi một bước lỗi, và đảm bảo kết quả cuối cùng nhất quán. AI agent chỉ là "bộ não" quyết định; orchestration là "hệ thần kinh" thực thi.
Orchestration vs Choreography
Có hai kiểu phối hợp nhiều dịch vụ:
- Orchestration (điều phối tập trung): một bộ điều phối trung tâm (orchestrator) ra lệnh cho từng service: "làm bước A", nghe kết quả, rồi "làm bước B". Dễ nhìn thấy toàn cảnh, dễ debug, dễ retry.
- Choreography (biên đạo phân tán): mỗi service tự phát event, service khác tự lắng nghe và phản ứng. Linh hoạt, ít ghép nối, nhưng khó theo dõi "đơn này đang ở đâu".
Ví dụ cụ thể: đơn hàng qua 3 hệ thống
[Đơn mới]
→ 1. Reserve tồn kho (WMS)
→ 2. Tạo hóa đơn (Accounting)
→ 3. Thu tiền (Payment)
→ [Hoàn tất] hoặc [Bù trừ nếu lỗi]
Nếu bước 3 thất bại (thẻ bị từ chối), bạn KHÔNG được để hàng bị giữ mãi và hóa đơn treo. Bạn phải "đi lùi": hủy hóa đơn, nhả tồn kho. Đây chính là lý do orchestration khó — và là trọng tâm cả khóa học.
Khung tư duy: 5 câu hỏi trước khi orchestrate
- Các bước: Quy trình gồm những bước nào, thứ tự và phụ thuộc ra sao?
- State: Tôi lưu "đang ở bước nào" ở đâu để không mất khi service chết?
- Retry: Bước nào được thử lại? Thử bao nhiêu lần, giãn cách thế nào?
- Idempotency: Nếu vô tình gọi 2 lần, hệ thống có bị trừ tiền 2 lần không?
- Compensation: Nếu nửa chừng hỏng, làm sao quay lui an toàn?
Các bước bắt đầu
- Vẽ sơ đồ luồng nghiệp vụ ra giấy, đánh số từng bước.
- Với mỗi bước, ghi rõ: gọi hệ thống nào, input, output, và "bước bù trừ" tương ứng.
- Xác định bước nào là side-effect không hoàn tác được (gửi email, giao hàng) — đặt chúng càng về cuối càng tốt.
- Chọn nơi lưu state (bảng DB, workflow engine) trước khi viết logic.
- Định nghĩa các trạng thái hợp lệ:
PENDING,RESERVED,INVOICED,PAID,FAILED,COMPENSATED.
Vì sao đây là bài toán khó hơn vẻ ngoài
Trong một hệ thống đơn lẻ, bạn có transaction ACID: nhiều thay đổi hoặc cùng thành công, hoặc cùng bị rollback. Nhưng khi quy trình trải qua WMS, kế toán và payment — ba hệ thống độc lập, thường của ba nhà cung cấp khác nhau — không có transaction chung. Bạn không thể ROLLBACK cả ba trong một lệnh. Mỗi bước là một cam kết cục bộ đã xảy ra thật, và nếu bước sau hỏng, bạn phải chủ động dọn dẹp thủ công. Chính khoảng trống "không có transaction xuyên hệ thống" này sinh ra toàn bộ nhu cầu về state bền, retry, idempotency và compensation mà khóa học sẽ lần lượt giải quyết.
Thêm một tầng khó nữa: các hệ thống ngoài giao tiếp qua mạng, mà mạng thì không đáng tin. Một request gửi đi có thể thành công ở phía nhận nhưng phản hồi bị rớt trên đường về — bạn không phân biệt được "chưa làm" với "đã làm nhưng không biết". Đây là lý do orchestration phải luôn giả định điều tệ nhất và thiết kế để an toàn khi mọi thứ được thử lại.
Vai trò của AI agent ở đâu
AI agent phù hợp cho các quyết định cần suy luận: phân loại đơn, đánh giá rủi ro, tóm tắt cho người phê duyệt, gợi ý bước xử lý ngoại lệ. Nhưng việc "đảm bảo chuỗi bước chạy đúng thứ tự, đúng một lần, và dọn dẹp khi hỏng" là công việc kỹ thuật của orchestrator — không phải của prompt. Ranh giới rõ ràng: AI quyết định, orchestrator thực thi đáng tin.
Sai lầm thường gặp
- Coi orchestration là một hàm gọi tuần tự trong RAM. Server restart giữa chừng là mất sạch trạng thái, đơn treo lơ lửng.
- Nhét toàn bộ logic vào prompt của AI agent. LLM giỏi quyết định, nhưng không phải nơi giữ state hay đảm bảo "chỉ chạy một lần".
- Bỏ qua đường thất bại. 80% độ khó nằm ở nhánh lỗi, không phải nhánh thành công.
- Đặt bước không hoàn tác được ở giữa. Đã gửi hàng rồi mới phát hiện hết tiền thì không compensate nổi.