Hand-off là hành động một agent chuyển việc (và dữ liệu) cho agent khác. Đây là nơi hệ multi-agent hay đổ vỡ nhất — không phải vì LLM ngu, mà vì thông tin bị mất, mập mờ hoặc quá tải khi truyền qua ranh giới agent.
Hai kiểu hand-off
- Hand-off theo chỉ thị (delegation): agent A quyết định giao việc cho agent B rồi chờ kết quả trả về. A vẫn giữ quyền điều phối. Đây là kiểu supervisor gọi sub-agent.
- Hand-off chuyển giao hẳn (transfer): agent A trao toàn quyền cho agent B và rút lui. Thường dùng trong routing hội thoại: bot tổng đài chuyển khách cho "agent thanh toán".
Hợp đồng dữ liệu (data contract)
Mỗi hand-off nên có một schema cố định cho payload — như một API. Ví dụ hand-off từ Researcher sang Writer:
{
"task_id": "sec-3-competitors",
"objective": "Viết mục so sánh 3 đối thủ chính",
"facts": [
{"claim": "Đối thủ X có 12k khách", "source": "https://...", "confidence": 0.8}
],
"constraints": ["tối đa 300 từ", "chỉ dùng facts đã cung cấp"],
"open_questions": ["chưa rõ giá gói doanh nghiệp của X"]
}
Schema này ép agent gửi phải nói rõ điều chưa biết (open_questions) và đính nguồn — hai thứ hay bị đánh rơi khi truyền văn bản tự do.
Ví dụ cụ thể: routing tổng đài
Bot tuyến đầu nhận "Tôi bị tính phí sai". Nó phân loại ý định, rồi transfer sang billing agent kèm ngữ cảnh:
transfer_to("billing_agent", context={
intent: "disputed_charge",
customer_id: 8841,
summary: "Khách phản ánh bị tính phí trùng ngày 3/7",
already_asked: ["đã xác minh danh tính"]
})
Truyền already_asked để billing agent không hỏi lại danh tính — tránh trải nghiệm "kể lại từ đầu" khét tiếng của tổng đài.
Khung tư duy: mỗi hand-off tự hỏi 3 điều
1. Agent nhận CẦN GÌ để làm việc? -> chỉ truyền đúng chừng đó.
2. Có gì agent nhận KHÔNG NÊN THẤY? (thiên vị, rò rỉ) -> loại bỏ.
3. Kết quả trả về có SCHEMA rõ để agent gọi dùng lại không?
Các bước thiết kế một hand-off
- Định nghĩa schema payload đi (JSON có trường bắt buộc).
- Định nghĩa schema kết quả trả về.
- Quyết định delegation hay transfer.
- Thêm trường
open_questions/uncertaintyđể chống mất mát ngầm. - Validate payload trước khi truyền (từ chối nếu thiếu trường bắt buộc).
- Ghi log mọi hand-off kèm payload để debug về sau.
Checklist chất lượng hand-off
- [ ] Payload có schema, được validate.
- [ ] Chỉ truyền thông tin cần thiết (nguyên tắc tối thiểu đặc quyền).
- [ ] Có nơi để nêu điều chưa chắc chắn.
- [ ] Đúng kiểu (delegation vs transfer) so với luồng điều phối.
Sai lầm thường gặp
- Truyền cả cục lịch sử hội thoại thô. Agent nhận bị quá tải ngữ cảnh, chi phí tăng, dễ lạc trọng tâm. Hãy tóm tắt có cấu trúc.
- Không có schema, truyền văn bản tự do. Agent nhận diễn giải sai, không có cách nào validate.
- Đánh rơi độ bất định. Researcher "đoán" một con số nhưng không đánh dấu, Writer coi đó là sự thật chắc chắn.
- Dùng transfer khi cần delegation. A rút lui nhưng vẫn phải tổng hợp — luồng gãy, không ai gom kết quả.
Validate payload: chốt chặn rẻ nhất
Một hand-off không được validate là quả bom hẹn giờ. Trước khi truyền, hãy kiểm tra payload đủ trường bắt buộc và đúng kiểu; nếu thiếu, từ chối ngay thay vì để agent nhận đoán mò. Đây là chốt chặn rẻ nhất trong toàn hệ.
REQUIRED = {"task_id", "objective", "facts", "constraints"}
def validate_handoff(payload):
missing = REQUIRED - payload.keys()
if missing:
raise HandoffError(f"Thiếu trường: {missing}")
if not isinstance(payload["facts"], list):
raise HandoffError("facts phải là list")
return payload
Khi hand-off fail validate, bạn có hai lựa chọn: (a) trả về cho agent gửi kèm thông báo lỗi để nó bổ sung, hoặc (b) escalate cho người. Đừng bao giờ nuốt lỗi im lặng — một payload thiếu trường truyền đi sẽ gây lỗi mơ hồ ở agent nhận, khó lần ngược nguồn.
Ghi log hand-off để debug
Mỗi hand-off nên được log kèm payload đầy đủ và timestamp. Khi hệ đông agent, phần lớn lỗi thực tế nằm ở ranh giới giữa các agent chứ không nằm trong một agent. Log hand-off cho bạn thấy chính xác dữ liệu nào đã đi qua ranh giới nào — nền tảng cho tracing ở bài 7.
Bài 4 sẽ lên một tầng: supervisor pattern — kiến trúc trong đó một agent điều phối điều phối toàn bộ dàn worker.