Ép thứ tự các bước và chuyển giao có cấu trúc

Có những quy trình mà thứ tự các bước là bắt buộc: phải xác minh khách là ai rồi mới được đổi vé, phải có người duyệt rồi mới được chi tiền. Bạn có thể dặn agent điều đó trong system prompt. Nhưng dặn thôi có đủ không?

Bài này trả lời câu hỏi đó, rồi đi tiếp hai việc hay đi kèm: xử lý một yêu cầu có nhiều ý, và chuyển giao cho nhân viên sao cho họ làm tiếp được ngay.

Ví dụ xuyên suốt: agent đổi vé máy bay

Một hãng bay giá rẻ dùng agent trả lời khách qua chat. Agent có các tool:

• verify_booking: kiểm mã đặt chỗ và họ tên, trả về mã đặt chỗ đã xác minh.
• change_flight: đổi sang chuyến khác.
• add_baggage: mua thêm hành lý.
• refund_ticket: hoàn tiền vé.
• escalate_to_agent: chuyển cho nhân viên, kèm bản tóm tắt.

Quy định của hãng: chưa xác minh đặt chỗ thì không được đổi vé, không được hoàn tiền.

Sau một tháng chạy thử, đội vận hành thấy khoảng 3% cuộc chat agent gọi change_flight ngay khi khách đưa mã đặt chỗ, mà không gọi verify_booking trước. Vài lần khách gõ nhầm một chữ trong mã, và agent đã đổi vé của người khác.

Dặn trong prompt và chặn bằng code

Có hai cách giữ thứ tự các bước:

Lời dặn trong prompt luôn có một tỉ lệ thất bại khác 0 (non-zero failure rate). Với phần lớn việc thì chấp nhận được. Nhưng khi làm sai gây mất tiền hay lộ thông tin, như đổi vé của người khác, thì "phần lớn thời gian" là không đủ.

Viết điều kiện chặn

Ý tưởng: code của bạn ghi nhớ đã xác minh xong chưa. Khi agent gọi change_flight hay refund_ticket mà chưa có mã đặt chỗ đã xác minh, code từ chối và báo lý do để agent biết phải làm gì.

Trong Agent SDK, chỗ để làm việc này là hook PreToolUse, chạy ngay trước mỗi lần gọi tool. Cách viết hook nằm ở bài 1.5; ở đây chỉ cần thấy ý chính:

const verified = new Set<string>(); // các mã đặt chỗ đã qua verify_booking

const requireVerification: HookCallback = async (input) => {
  const { tool_name, tool_input } = input as PreToolUseHookInput;
  const booking = (tool_input as { booking_code: string }).booking_code;
  if (!verified.has(booking)) {
    return {
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "Chưa xác minh đặt chỗ. Gọi verify_booking trước.",
      },
    };
  }
  return {};
};

Mã đặt chỗ chỉ được thêm vào verified khi verify_booking trả về thành công. Agent có quên thế nào thì change_flight cũng không chạy được với mã chưa xác minh. Theo tài liệu Agent SDK, lý do từ chối được đưa cho Claude đọc, nên agent sẽ quay lại gọi verify_booking.

Yêu cầu có nhiều ý

Khách nhắn: "Mình muốn đổi chuyến sang thứ Sáu, mua thêm 10kg hành lý, và vé của con mình hôm trước bị huỷ thì hoàn tiền chưa?"

Đây là ba việc khác nhau trong một tin nhắn. Nếu agent xử lý theo kiểu đọc lướt, nó dễ làm việc đầu rồi quên hai việc sau. Cách làm tốt:

1. Tách tin nhắn thành từng mục riêng: đổi chuyến, mua hành lý, kiểm tra hoàn tiền.
2. Tra từng mục, có thể song song, dùng chung thông tin đã có như mã đặt chỗ đã xác minh.
3. Gộp lại thành một câu trả lời đầy đủ cho cả ba mục.

Chuyển giao cho nhân viên

Giả sử vé của con khách bị huỷ do hãng đổi lịch bay, nhưng hệ thống hoàn tiền báo lỗi. Agent phải chuyển cho nhân viên.

Nhân viên nhận ca thường không đọc được cuộc chat giữa khách và agent. Nếu agent chỉ gửi "Khách cần hỗ trợ hoàn tiền", nhân viên phải hỏi lại khách từ đầu. Khách sẽ rất bực.

Vì vậy, bản tóm tắt chuyển giao phải có cấu trúc rõ ràng (structured handoff summary), đủ để nhân viên làm tiếp ngay:

{
  "booking_code": "K7Q2XM",
  "customer_request": "Hoàn tiền vé của con, chuyến bị huỷ ngày 28/10",
  "root_cause": "Hãng đổi lịch bay, refund_ticket báo lỗi hệ thống 2 lần",
  "amount": "1.250.000 đ",
  "done_so_far": "Đã đổi chuyến sang thứ Sáu và mua thêm 10kg hành lý",
  "recommended_action": "Hoàn tiền thủ công về thẻ đã thanh toán"
}

Bốn thông tin đề thi hay nhắc: mã khách hoặc mã đặt chỗ, nguyên nhân gốc (root cause), số tiền, và đề xuất hành động (recommended action).