Bạn đã có đủ mảnh ghép: một-agent vs nhiều-agent, planner/worker/critic, hand-off, supervisor, phân cấp, ngang hàng, và vận hành. Bài cuối này gói tất cả thành một quy trình chọn kiến trúc và đi qua một tình huống thật từ đầu đến cuối.
Cây quyết định kiến trúc
Tác vụ cần multi-agent? (khung bài 1)
├─ KHÔNG -> Một agent + tool. DỪNG.
└─ CÓ:
Các phần độc lập, cần tốc độ? -> Fan-out/fan-in (bài 6)
Cần phản biện/độ tin cậy cao? -> + Critic (bài 2) hoặc vote/debate
Luồng thích ứng theo kết quả? -> Supervisor (bài 4)
>6-8 worker, nhiều lĩnh vực? -> Phân cấp (bài 5)
Hội thoại cần chuyển tuyến? -> Transfer hand-off (bài 3)
Luôn kèm: hợp đồng hand-off + tracing + ngân sách + cổng an toàn (bài 3,7)
Hầu hết hệ thực tế là lai ghép: một supervisor điều phối, có một critic phản biện, và một nhánh fan-out cho phần lặp lại. Đừng ép mình vào một pattern thuần.
Tình huống end-to-end: trợ lý xử lý ticket hỗ trợ
Yêu cầu: nhận ticket khách hàng, tự phân loại, tra cứu, soạn phản hồi, và với ticket hoàn tiền thì cần người duyệt.
Bước 1 — Phân tích. Có nhiều vai trò (phân loại, tra cứu, soạn, kiểm duyệt) và một hành động không hoàn tác được (hoàn tiền). → cần multi-agent + human-in-the-loop.
Bước 2 — Chọn tô-pô. Luồng thích ứng theo loại ticket → supervisor. Số agent ít (~4) → không cần phân cấp.
Supervisor
├─ Classifier (phân loại ý định)
├─ Retriever (tra KB + lịch sử khách)
├─ Responder (soạn phản hồi)
└─ Critic (kiểm giọng điệu + chính sách)
[Cổng người duyệt] -> chỉ khi intent = refund
Bước 3 — Hợp đồng hand-off. Classifier trả {intent, confidence, customer_id}. Nếu confidence < 0.6, supervisor định tuyến sang người thật thay vì đoán.
Bước 4 — Vòng critic. Responder soạn → Critic kiểm theo rubric (đúng chính sách hoàn tiền? giọng lịch sự? không hứa điều không có?). Chưa đạt thì trả feedback, tối đa 2 vòng.
Bước 5 — Cổng an toàn. Nếu intent == refund, supervisor KHÔNG tự gửi — đẩy cho nhân viên duyệt kèm bản nháp. Đây là human-in-the-loop cho hành động tiền bạc.
Bước 6 — Vận hành. Gắn trace_id mỗi ticket; đo tỷ lệ auto-resolve, p95 latency, token/ticket; cảnh báo khi critic-fail-rate tăng.
def handle_ticket(ticket):
cls = classifier.run(ticket)
if cls["confidence"] < 0.6:
return escalate_to_human(ticket, reason="low_confidence")
ctx = retriever.run(cls["customer_id"], cls["intent"])
draft = responder.run(ticket, ctx)
for _ in range(2):
v = critic.run(draft, policy)
if v["passed"]:
break
draft = responder.run(ticket, ctx, feedback=v["feedback"])
if cls["intent"] == "refund":
return queue_for_approval(draft) # human-in-the-loop
return send(draft)
Khung tư duy tổng: bắt đầu nhỏ, tách khi đau
Luôn khởi đầu bằng kiến trúc đơn giản nhất chạy được, đo lường, rồi tách/thêm agent đúng chỗ đang đau thật (nghẽn ngữ cảnh, cần phản biện, cần tốc độ). Kiến trúc đẹp là kiến trúc vừa đủ.
Checklist triển khai một hệ mới
- [ ] Đã chạy khung bài 1 để xác nhận thật sự cần multi-agent.
- [ ] Chọn tô-pô theo cây quyết định, chấp nhận lai ghép.
- [ ] Mọi hand-off có schema + validate.
- [ ] Có critic với rubric cho phần cần độ tin cậy.
- [ ] Human-in-the-loop cho mọi hành động không hoàn tác.
- [ ] Tracing, ngân sách token, trần bước toàn cục đã bật.
Sai lầm thường gặp
- Ép một pattern thuần cho mọi thứ. Thực tế cần lai ghép; giáo điều làm hệ vừa phức tạp vừa yếu.
- Bỏ cổng người duyệt cho hành động tiền/dữ liệu. Một lỗi agent = một khoản bồi thường.
- Tối ưu kiến trúc trước khi đo. Bạn tách agent để chữa vấn đề chưa từng xác nhận tồn tại.
- Không tính đường thoát khi độ tin cậy thấp. Agent đoán bừa thay vì chuyển cho người — hại hơn không có agent.