Bài 4 — Orchestration: các mẫu điều phối đội agent

Orchestration là "nhạc trưởng" của đội

Có tool và role prompt rồi, câu hỏi lớn là: agent nào chạy khi nào, ai gọi ai? Đó là orchestration. Chọn sai mẫu điều phối khiến đội chậm, vòng lặp vô tận, hoặc chi phí bùng nổ. Bài này giới thiệu 4 mẫu chính và cách chọn.

4 mẫu orchestration phổ biến

• Router (điều hướng): một router agent phân loại yêu cầu rồi giao cho đúng agent chuyên môn. Đơn giản, rẻ, phù hợp phần lớn phòng ban.
• Sequential pipeline (dây chuyền): agent A → B → C, output cái này là input cái kia. Hợp với quy trình cố định (ví dụ: tạo báo cáo: thu thập → phân tích → viết).
• Manager/Worker (quản lý — nhân viên): một manager agent chia nhỏ task, giao cho nhiều worker chạy song song, rồi tổng hợp. Hợp việc phức tạp, đa phần việc.
• Blackboard/Shared state (bảng chung): các agent cùng đọc/ghi một shared state, tự quyết khi nào tham gia. Linh hoạt nhưng khó kiểm soát nhất.

Khung chọn mẫu

Ví dụ: Router cho phòng CSKH (pseudocode)

def orchestrate(user_msg):
    route = router_agent.classify(user_msg)   # 'order' | 'refund' | 'other'
    if route == 'order':
        return order_agent.run(user_msg)
    elif route == 'refund':
        result = refund_agent.run(user_msg)
        if result['action'] == 'escalated':
            return escalation_agent.run(user_msg, context=result)
        return result
    else:
        return escalation_agent.run(user_msg)

Lưu ý cơ chế hand-off: refund_agent tự quyết escalate, orchestrator chuyển tiếp kèm context.

Hai kiểu hand-off: chuyển hẳn vs. hỏi rồi quay lại

Khi một agent cần agent khác giúp, có hai kiểu hand-off, đừng nhầm lẫn:

• Transfer (chuyển hẳn): agent A giao đứt việc cho B và không quan tâm nữa (ví dụ router → order_agent). Đơn giản, ít lỗi.
• Delegate-and-return (nhờ rồi nhận lại): agent A nhờ B làm một việc con rồi lấy kết quả về để tiếp tục (ví dụ refund_agent nhờ policy_agent kiểm tra chính sách). Cần data contract chặt để A parse được kết quả của B.

Chọn nhầm kiểu hand-off gây rối luồng: nếu A tưởng đã chuyển hẳn nhưng thực ra cần kết quả về, request sẽ treo hoặc trả lời thiếu. Hãy ghi rõ trong thiết kế mỗi hand-off thuộc kiểu nào.

Vì sao nên ưu tiên Router/Sequential

Router và Sequential dễ debug vì đường đi của request là tuyến tính, đọc trace là thấy ngay. Manager/Worker và Blackboard có tính phi tuyến (song song, tự quyết) nên khó lần ra nguyên nhân khi sai. Kinh nghiệm thực chiến: 80% phòng ban chỉ cần Router hoặc Sequential; chỉ dùng mẫu phức tạp khi bạn thực sự có nhiều việc con song song và đã đo được lợi ích.

Các bước thiết kế orchestration

• Xác định task điển hình có bao nhiêu bước và có song song được không.
• Chọn mẫu theo bảng trên; ưu tiên Router/Sequential vì đơn giản, dễ debug.
• Định nghĩa hợp đồng dữ liệu (data contract) giữa các agent — output của A phải khớp input của B.
• Đặt GIỚI HẠN VÒNG LẶP (max steps) để tránh agent gọi nhau vô tận.
• Đặt timeout cho mỗi agent để không treo cả đội.
• Ghi lại "đường đi" (trace) của mỗi request để phân tích sau.

Checklist orchestration an toàn

• [ ] Đã chọn mẫu phù hợp độ phức tạp
• [ ] Có data contract rõ giữa các agent
• [ ] Có giới hạn số bước (max steps)
• [ ] Có timeout mỗi agent
• [ ] Có trace đường đi request
• [ ] Hand-off luôn kèm đủ context

Sai lầm thường gặp

• Chọn Blackboard khi chưa cần: linh hoạt nhưng cực khó debug và dễ loop. Bắt đầu bằng Router.
• Không giới hạn vòng lặp: hai agent "lịch sự" đẩy việc qua lại vô hạn → cháy token, treo hệ thống.
• Hand-off thiếu context: chuyển việc mà không kèm kết quả trước đó → agent nhận việc phải hỏi lại từ đầu.
• Data contract lỏng lẻo: A trả text tự do, B mong JSON → chuỗi đứt giữa chừng.
• Nhồi mọi thứ vào một manager "siêu thông minh": manager quá tải, chậm, và trở thành điểm chết duy nhất (single point of failure).