
Agent-Human Handoff: Vì Sao Pause/Resume Và Handoff Không Phải Cùng Một Pattern
"Escalate cho con người" thật ra là hai hành vi khác nhau: một pause chờ duyệt rồi agent tự tiếp tục, và một handoff nơi agent từ bỏ hẳn quyền sở hữu. Nhầm lẫn hai cái này là lý do một handoff thường có nghĩa là một người phải bắt đầu lại từ đầu.
Thuộc chuỗi bài: Agentic Workflow Design: 4 Quyết Định Giữ Cho AI Agent An Toàn Khi Chạy Thật
"Escalate cho con người" nghe như một hành vi duy nhất, nhưng thật ra đó là hai hành vi khác nhau đang mang chung một cái tên. Đôi khi agent chỉ cần một người nói "cứ làm tiếp đi" trước khi nó tiếp tục làm đúng việc của mình. Đôi khi agent đã chạm giới hạn của những gì nó có thể làm, và công việc cần chuyển hẳn thành việc của người khác. Build cả hai như thể chúng là cùng một pattern chính là lý do "escalation" thường có nghĩa là một người đang nhìn một tác vụ dở dang mà chẳng biết chuyện gì đã xảy ra.
Hai Kiểu Escalation Khác Nhau, Một Điểm Kích Hoạt
Tách Bạch Pause/Resume Khỏi Human Handoff
Đây là hai pattern vòng đời khác nhau, không phải hai cái tên cho cùng một thứ. Ở pause state, agent lưu tiến độ hiện tại vào một checkpoint và tạm dừng, chờ sự cho phép từ con người - nhưng nó vẫn là chủ sở hữu của workflow và sẽ tiếp tục thực thi ngay khi được duyệt. Resume là nửa còn lại của hợp đồng đó: agent thức dậy từ checkpoint và tiếp tục, nhưng nếu thời gian chờ đủ dài để thế giới có thể đã thay đổi, nó chạy một staleness check trước - xác minh lại bất kỳ input nào có thể đã cũ trong lúc chờ, trước khi mutate bất cứ thứ gì. Human handoff là một sự kiện hoàn toàn khác: agent từ bỏ quyền sở hữu vĩnh viễn, đóng gói mọi thứ đã thu thập được vào một handoff payload, và chuyển giao tác vụ cho con người để hoàn tất từ đầu tới cuối. Nó không quay lại resume - con người sở hữu phần còn lại.
Ví dụ xuyên suốt: InsuranceClaimBot - một agent xử lý claim bảo hiểm ô tô: xem ảnh thiệt hại được gửi lên, kiểm tra phạm vi bảo hiểm, và duyệt hoặc điều hướng khoản chi trả.
Hai Claim, Hai Kiểu Escalation Khác Nhau
Một claim $6,000 tiền thiệt hại va chạm vượt qua mọi kiểm tra tự động và chỉ cần chữ ký duyệt của adjuster vì nó vượt ngưỡng chi trả. Agent tạm dừng, checkpoint claim, và gửi cho adjuster một thẻ phê duyệt. Bốn ngày sau adjuster duyệt. Đây là một pause, không phải handoff - InsuranceClaimBot vẫn sở hữu việc hoàn tất khoản chi trả, nó chỉ cần một cái gật đầu giữa chừng.
Một claim khác có ảnh mờ và không khớp với mô tả tai nạn, và bản thân tài liệu hợp đồng bảo hiểm không parse được. Agent thử lại việc trích xuất ba lần và vẫn không đọc được sạch. Ở đây không có gì để chờ duyệt - vì chưa có gì hợp lệ để duyệt. Đây là một handoff: agent đóng gói ảnh gốc, các lần trích xuất dang dở, và một mô tả cụ thể về việc gì đã thất bại, rồi đưa claim vào hàng đợi của con người. Nó không quay lại agent sau đó.
Điều Hướng Escalation Của InsuranceClaimBot
Ba claim, ba lý do khiến agent dừng lại - chỉ một trong số đó quay lại cho agent sau đó.
Mọi kiểm tra tự động đều pass. Claim hợp lệ - nó chỉ đủ lớn để cần chữ ký duyệt của adjuster trước khi giải ngân.
Agent checkpoint claim và chờ adjuster. Khi được duyệt, nó resume - nhưng chạy staleness check trước: xác minh lại hợp đồng bảo hiểm vẫn còn hiệu lực và ước tính sửa chữa chưa bị điều chỉnh kể từ lúc claim tạm dừng.
Staleness Check Là Hợp Đồng Khiến Resume An Toàn
Lỗi đặc trưng riêng của pause/resume là giả định rằng bất cứ điều gì đúng lúc agent tạm dừng vẫn đúng lúc nó resume. Thường thì không, và khoảng cách giữa hai thời điểm đó chính xác bằng độ dài của thời gian chờ. Nếu InsuranceClaimBot tạm dừng để chờ duyệt chi trả và adjuster mất bốn ngày, việc resume bằng cách giải ngân ngay theo tỷ giá hoặc mức định giá claim tính từ bốn ngày trước sẽ hấp thụ bất cứ thứ gì đã trôi trong lúc đó - một biến động tỷ giá, một ước tính sửa chữa đã được cập nhật, một hợp đồng bảo hiểm đã hết hạn trong khoảng thời gian đó. Staleness check là thứ biến "resume" từ một sự tiếp tục mù quáng thành một sự tiếp tục an toàn: query lại bất kỳ input nào nhạy cảm với thời gian trước khi bước mutate tiếp theo chạy, không phải sau đó.
Chờ Càng Lâu, Staleness Check Càng Phải Nghiêm
Độ dài thời gian chờ → mức độ có thể tin tưởng vào state đã checkpoint lúc resume
Duyệt nhanh hiếm khi cần verify lại - dữ liệu vẫn còn mới lúc kiểm tra, và rất khó thay đổi trong chưa đầy một giờ.
Các trường nhạy cảm với thời gian - tỷ giá, báo giá, điều khoản khuyến mãi - có thể trôi trong một ngày. Kiểm tra lại bất cứ thứ gì cập nhật theo chu kỳ đó trước khi resume.
Bất cứ thứ gì có thể thay đổi theo ngày - trạng thái hợp đồng, tình trạng tín dụng, tình trạng còn hàng - cần được kiểm tra lại đầy đủ trước khi resume, gần như coi request là vừa được nộp mới.
Bản năng sau một lần trễ duyệt nhiều ngày là resume ngay và đi tiếp - claim đã chờ đủ lâu rồi. Bản năng đó đang đi ngược:chờ càng lâu, càng có nhiều thời gian để mọi thứ trôi bên dưới nó
Các mốc thời gian chờ này chỉ mang tính minh hoạ, không phải phổ quát - trường nào thật sự bị stale, và nhanh tới đâu, phụ thuộc vào domain cụ thể của bạn (tỷ giá thay đổi theo phút, trạng thái hợp đồng theo ngày, tín dụng theo tuần). Hãy map các trường nhạy cảm thời gian của riêng bạn với tốc độ trôi thật của chúng thay vì mặc định theo đúng thang này.
Handoff Là Một Hợp Đồng Dữ Liệu, Không Phải Một Hành Vi UX
Các khuyến nghị nghiêm túc về handoff giữa nhiều agent và giữa agent-con người coi nó trước hết là một hợp đồng dữ liệu, và chỉ sau đó mới là một bước trong workflow: bên chuyển giao phải biết chính xác cần đóng gói gì, bên nhận phải biết chính xác nên kỳ vọng gì. Một handoff chỉ nói "claim này cần con người" buộc adjuster phải bắt đầu lại từ số 0 - đọc lại ảnh, chạy lại đúng những kiểm tra agent đã chạy, và tự tìm lại đúng vấn đề agent đã tìm thấy. Một handoff payload làm đúng bao gồm những gì đã thu thập được (ảnh, trường dữ liệu đã trích xuất, kết quả dang dở), kết luận của chính các kiểm tra của agent (một điểm số similarity cụ thể, một trường cụ thể không parse được), và lý do cụ thể khiến việc thực thi dừng lại - không phải "trích xuất thất bại," mà là "trường VAT không đọc được sau 3 lần OCR trên một vùng biên lai bị nhoè." Sự khác biệt là một con người tiếp quản giữa chừng so với một con người bắt đầu lại đúng tác vụ mà agent đã thử.
Cạm Bẫy Thường Gặp Trong Agent-Human Handoff
Một nhóm sai lầm lặp lại khi các đội build logic pause/resume và handoff đầu tiên: bỏ qua staleness check lúc resume vì thời gian chờ "chắc cũng ổn thôi" - đúng là cái giả định sẽ sụp đổ sau một lần trễ duyệt nhiều ngày; gửi một handoff không kèm payload nào ngoài "cần người review," buộc phải điều tra lại từ đầu; coi mọi escalation là cùng một pattern thay vì quyết định ngay từ đầu cái nào là một pause mà agent sẽ hoàn tất và cái nào là một handoff mà nó sẽ không quay lại; và để một tác vụ đang pause không có thời hạn hay nhắc nhở, khiến nó nằm chờ một người đã quên mất nó tồn tại.
Handoff là nơi ba quyết định còn lại trong agentic workflow design gặp giới hạn của chúng: một tool surface được scope tốt, một autonomy tier được calibrate đúng, và một kế hoạch recovery vững đều giả định agent có thể tiếp tục. Handoff là sự thừa nhận thành thật cho trường hợp nó không thể - và một handoff tốt trao cho con người một tác vụ họ thật sự có thể tiếp quản, thay vì một tác vụ họ phải bắt đầu lại từ đầu.