1.4 Workflow Enforcement and Handoff

Những gì cần nắm

Task Statement 1.4 kẻ một ranh giới cứng giữa hai cách kiểm soát hành vi của agent: hướng dẫn bằng prompt và cưỡng chế bằng code. Đề thi hỏi đi hỏi lại sự phân biệt này, và trả lời sai ở các tình huống rủi ro cao là mất điểm.

Phổ cưỡng chế

Có hai cách rất khác nhau để ép đúng thứ tự workflow trong một hệ agentic:

Hướng dẫn bằng prompt là đưa chỉ thị vào system prompt. Ví dụ: “Luôn xác minh danh tính khách hàng trước khi xử lý hoàn tiền.” Nó chạy được phần lớn thời gian — có thể 90–95% số ca. Nhưng nó mang tỷ lệ lỗi khác 0. Model mang bản chất xác suất. Đôi khi nó bỏ bước, đảo bước, hoặc đọc chỉ thị một cách lỏng lẻo. Với thao tác rủi ro thấp, tỷ lệ lỗi đó chấp nhận được.

Cưỡng chế bằng code là cài hook, prerequisite gate, hoặc kiểm tra ở tầng code, chặn vật lý các tool phía sau cho tới khi điều kiện tiên quyết hoàn tất. Ví dụ: tool process_refund không chạy được cho tới khi get_customer trả về một customer ID đã xác minh. Cách này đúng mọi lần. Nó tất định, không phải xác suất. Model có quyết định làm gì đi nữa thì cái gate vẫn chặn sai thứ tự thực thi.

Quy tắc quyết định của đề thi

Đề thi áp cùng một quy tắc quyết định qua nhiều tình huống:

Thao tác tài chính (hoàn tiền, chuyển khoản, thanh toán): cưỡng chế bằng code. Một lần hoàn tiền không xác minh vào nhầm tài khoản là mất tiền thật.
Thao tác bảo mật (xác minh danh tính, kiểm soát truy cập): cưỡng chế bằng code. Một lần lách xác minh danh tính là một sự cố bảo mật.
Thao tác tuân thủ (kiểm tra AML, yêu cầu pháp lý): cưỡng chế bằng code. Một lần bỏ sót kiểm tra tuân thủ có thể dẫn tới chế tài pháp lý.
Thao tác rủi ro thấp (sở thích định dạng, style guideline, thứ tự trình bày output): hướng dẫn bằng prompt là đủ. Định dạng không đồng nhất không phải rủi ro kinh doanh.

Đề thi sẽ đưa các giải pháp dạng prompt vào làm phương án cho tình huống rủi ro cao. Loại chúng. System prompt mạnh hơn, ví dụ few-shot, chỉ thị gắt hơn — tất cả đều cải thiện độ chính xác nhưng không cái nào cho đảm bảo tất định. Khi tình huống dính tới tiền, bảo mật hoặc tuân thủ, đáp án luôn là cưỡng chế bằng code.

Prerequisite gate trong thực tế

Prerequisite gate là một kiểm tra ở tầng code, chặn tool không cho chạy cho tới khi điều kiện trước đó thỏa. Trong một agent hỗ trợ khách hàng:

Agent có các tool get_customer, lookup_order và process_refund.
Gate kiểm tra: get_customer đã trả về customer ID đã xác minh cho session này chưa?
Nếu rồi, process_refund chạy bình thường.
Nếu chưa, process_refund trả về lỗi: “Cannot process refund — customer identity not verified. Please call get_customer first.”

Gate là code, không phải chỉ thị trong prompt. Model không lách được bằng cách quyết định bỏ qua bước xác minh. Kể cả khi model cố gọi thẳng process_refund, gate vẫn chặn và trả lỗi, buộc model phải xác minh danh tính trước.

Hook vòng đời subagent: SubagentStart và SubagentStop

Claude Agent SDK có các sự kiện hook vòng đời dành riêng cho quản lý subagent. Chúng bổ sung cho PreToolUse và PostToolUse được nói ở Task Statement 1.5.

SubagentStart kích hoạt khi một subagent được spawn qua Task tool (Claude Code hiện tại gọi là Agent). Nó chỉ mang tính quan sát: hook nhận type và id của subagent, và có thể log lại lần spawn. Các trường output được tài liệu hóa là systemMessage và terminalSequence, nên nó không chặn được lời gọi, cũng không tiêm được context vào lượt chạy của subagent. Muốn cưỡng chế quy tắc ngay ở khâu spawn — giới hạn tần suất, hay kiểm tra coordinator đã truyền đủ context chưa — hãy gắn một PreToolUse hook vào tool Agent; hook đó từ chối hoặc viết lại được lời gọi trước khi subagent khởi động.

SubagentStop kích hoạt khi subagent chạy xong và trả kết quả về cho coordinator. Hook nhận id và message cuối của subagent, nên nó kiểm tra được output và log lại thời điểm hoàn tất để theo dõi hiệu năng. Nếu kiểm tra thất bại — chẳng hạn output không đúng schema mong đợi — hook thoát với exit code 2, ngăn subagent dừng và đẩy nó quay lại làm tiếp. Exit code 2 là cơ chế chặn được tài liệu hóa; sự kiện này không có trường decision. SubagentStop không biến đổi output trả về, và hooks reference không mô tả trường nào trên bất kỳ sự kiện nào cho phép ghi đè tool result tại chỗ, nên hãy coi việc nắn lại output là việc coordinator làm sau đó, không phải việc hook làm hộ bạn.

Hook phạm vi subagent: subagent có thể tự định nghĩa hook trong frontmatter của nó. Mọi sự kiện hook đều được hỗ trợ ở đó, gồm cả PreToolUse và PostToolUse, và chúng chỉ sống trong vòng đời của component đó — chỉ chặn tool call do chính subagent đó thực hiện, không chạm tới coordinator hay subagent khác. Nhờ vậy mỗi subagent có chính sách riêng (ví dụ subagent billing có PreToolUse hook chặn hoàn tiền vượt ngưỡng, còn subagent hỗ trợ kỹ thuật thì không cần ràng buộc đó).

Stop hook tự chuyển đổi: khi frontmatter của subagent định nghĩa Stop hook, chúng tự động được chuyển thành sự kiện SubagentStop, vì SubagentStop mới là sự kiện kích hoạt lúc subagent hoàn tất. Nhờ vậy bạn có thể đặt logic dọn dẹp hoặc kiểm tra ngay trong cấu hình của subagent và tin rằng nó chạy khi kết thúc.

Xử lý yêu cầu nhiều vấn đề

Khách hàng rất hay gửi yêu cầu chứa nhiều vấn đề cùng lúc: “Tôi muốn trả hàng, đổi địa chỉ giao hàng, và hỏi về điểm tích lũy.” Đề thi kiểm tra cách agent nên xử những yêu cầu gộp kiểu này.

Cách đúng:

Phân rã yêu cầu thành các mục riêng (trả hàng, đổi địa chỉ, hỏi điểm tích lũy).
Xử lý song song từng mục, dùng chung context (thông tin tài khoản khách hàng liên quan tới cả ba).
Tổng hợp một phương án trả lời thống nhất, giải quyết cả ba mục trong một response.

Cách sai là xử lần lượt qua các hội thoại tách rời, hoặc chỉ trả lời mục đầu tiên rồi quên phần còn lại.

Giao thức handoff có cấu trúc

Khi agent không xử lý được và phải escalate lên nhân viên người thật, việc bàn giao phải theo một giao thức có cấu trúc. Ràng buộc then chốt: nhân viên người thật KHÔNG truy cập được transcript hội thoại. Họ không thể cuộn lại lịch sử chat để hiểu vấn đề.

Một bản tóm tắt handoff đúng chuẩn phải tự chứa và gồm:

Customer ID — để nhân viên kéo được hồ sơ tài khoản.
Tóm tắt hội thoại — khách yêu cầu gì và đã thử những gì.
Phân tích nguyên nhân gốc — đánh giá của agent về vấn đề nằm dưới.
Số tiền hoàn (nếu có) — con số cụ thể, không phải nhắc chung chung.
Hành động đề xuất — theo agent thì nhân viên nên làm gì.

Bản tóm tắt này là toàn bộ thông tin nhân viên nhận được. Nếu nó thiếu, nhân viên buộc phải bắt khách kể lại từ đầu, tạo trải nghiệm tệ.

Ví dụ thực tế: tỷ lệ lỗi 8%

Dữ liệu production cho thấy một agent hỗ trợ khách hàng xử lý hoàn tiền mà không xác minh quyền sở hữu tài khoản trong 8% số ca. System prompt đã ghi: “Luôn xác minh danh tính khách hàng trước khi xử lý bất kỳ khoản hoàn tiền nào.” Prompt đúng 92% số ca và trượt 8%.

Tỷ lệ lỗi 8% đó đã dẫn tới những khoản hoàn tiền vào nhầm tài khoản. Đây là thao tác tài chính với hậu quả tiền bạc thật.

Cách sửa là một prerequisite gate ở tầng code. Trước khi process_refund chạy được, hệ thống kiểm tra rằng get_customer đã trả về customer ID đã xác minh trong session hiện tại. Cách này triệt tiêu hoàn toàn tỷ lệ 8% — không phải bằng cách viết prompt hay hơn, mà bằng cách chặn vật lý thứ tự thực thi sai.

Bẫy thi

Tình huống luyện tập

Dữ liệu production cho thấy trong 8% số ca, một agent hỗ trợ khách hàng xử lý hoàn tiền mà không xác minh quyền sở hữu tài khoản, thỉnh thoảng dẫn tới hoàn tiền vào nhầm tài khoản. System prompt đã ghi rõ “luôn xác minh danh tính khách hàng trước khi xử lý hoàn tiền”. Cách sửa phù hợp nhất là gì?

A. Cài prerequisite gate ở tầng code, chặn process_refund cho tới khi get_customer trả về customer ID đã xác minh
B. Thêm chỉ thị mạnh hơn vào system prompt, nhấn mạnh tầm quan trọng sống còn của việc xác minh trước mọi lần hoàn tiền
C. Thêm ví dụ few-shot minh họa đúng thứ tự xác minh rồi mới hoàn tiền
D. Cài routing classifier đẩy mọi yêu cầu hoàn tiền vào một pipeline chuyên biệt ưu tiên xác minh trước

Đáp án & giải thích

Đúng: A

A — Thao tác tài chính đòi cưỡng chế tất định. Prerequisite gate chặn vật lý tool hoàn tiền cho tới khi xác minh danh tính xong, triệt tiêu hoàn toàn tỷ lệ lỗi 8%. Đây là phương án duy nhất cho đảm bảo 100%.
B — Prompt hiện tại đã yêu cầu xác minh mà vẫn trượt 8%. Prompt mạnh hơn có thể kéo xuống 3–4% nhưng không xóa được. Thao tác tài chính cần đảm bảo tất định, không phải cải thiện xác suất.
C — Few-shot tăng độ nhất quán nhưng vẫn để lại tỷ lệ lỗi khác 0. Với thao tác tài chính mà một lần lỗi là tiền vào nhầm tài khoản, cải thiện xác suất là không đủ.
D — Routing classifier lo việc yêu cầu đi tới agent nào, không lo việc agent thực thi workflow nội bộ ra sao. Vấn đề là agent đôi khi bỏ bước xác minh ngay trong lượt chạy của nó, và điều đó cần cơ chế cưỡng chế ở cấp agent, không phải thay đổi định tuyến.

Nguồn

Claude Agent SDK Overview — Anthropic
Hooks Reference — Anthropic (nguồn cho phần vòng đời subagent)
Building with Claude API, gồm tình huống Customer Support Resolution Agent (Skilljar) — Anthropic

Exam Simulator

Năm câu trắc nghiệm theo format đề thi về Workflow Enforcement and Handoff. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

A. Cài prerequisite gate ở tầng code, chặn process_refund cho tới khi get_customer trả về customer ID đã xác minh
B. Thêm chỉ thị mạnh hơn vào system prompt, nhấn mạnh tầm quan trọng sống còn của việc xác minh trước mọi lần hoàn tiền
C. Thêm ví dụ few-shot minh họa đúng thứ tự xác minh rồi mới hoàn tiền
D. Cài routing classifier đẩy mọi yêu cầu hoàn tiền vào một pipeline chuyên biệt ưu tiên xác minh trước

Đáp án & giải thích

Đúng: A

A đúng vì thao tác tài chính đòi cưỡng chế tất định. Prerequisite gate chặn vật lý tool hoàn tiền cho tới khi xác minh danh tính xong, triệt tiêu hoàn toàn tỷ lệ lỗi 8%. Đây là phương án duy nhất cho đảm bảo 100%.
B sai vì prompt hiện tại đã yêu cầu xác minh mà vẫn trượt 8%. Prompt mạnh hơn có thể kéo xuống 3–4% nhưng không xóa được. Thao tác tài chính cần đảm bảo tất định.
C sai vì few-shot tăng độ nhất quán nhưng vẫn để lại tỷ lệ lỗi khác 0. Với thao tác tài chính mà một lần lỗi là tiền vào nhầm tài khoản, như vậy là không đủ.
D sai vì routing classifier lo việc yêu cầu đi tới agent nào, không lo cách agent thực thi workflow nội bộ. Vấn đề nằm trong lượt chạy của agent, cần cơ chế cưỡng chế ở cấp agent.

Câu 2

Khi agent escalate lên nhân viên người thật, bản tóm tắt handoff phải chứa các trường cụ thể vì:

A. Nhân viên thích dữ liệu có cấu trúc hơn tóm tắt dạng hội thoại khi phân loại hàng đợi escalation
B. Claude API spec bắt buộc handoff phải có cấu trúc
C. Nhân viên KHÔNG truy cập được transcript hội thoại và cần một bản tóm tắt tự chứa
D. Hệ thống giám sát yêu cầu các trường cố định trên mọi handoff để theo dõi tuân thủ và xuất báo cáo audit

Đáp án & giải thích

Đúng: C

C đúng vì ràng buộc then chốt là nhân viên không cuộn lại được lịch sử chat. Bản tóm tắt handoff là toàn bộ thông tin họ nhận. Thiếu một bản tóm tắt đầy đủ và tự chứa (customer ID, tóm tắt hội thoại, phân tích nguyên nhân gốc, số tiền hoàn, hành động đề xuất), nhân viên buộc phải bắt khách kể lại từ đầu.
A sai vì đây không phải chuyện sở thích — mà là nhân viên đúng nghĩa không có quyền xem hội thoại trước đó.
B sai vì định dạng handoff không phải yêu cầu trong API spec. Đó là quyết định thiết kế kiến trúc, xuất phát từ thực tế nhân viên không xem được hội thoại.
D sai vì tuy giám sát cũng hưởng lợi từ dữ liệu có cấu trúc, lý do chính vẫn là nhân viên không truy cập được transcript.

Câu 3

Một đội compliance yêu cầu một bước workflow nhất định phải xảy ra 100% số lần trước một thao tác tài chính. Cách nào cho đảm bảo đó?

A. Ghi yêu cầu vào system prompt, in đậm và nhắc lại nhiều lần
B. Cài hook hoặc prerequisite gate chặn thao tác ở tầng code cho tới khi bước đó hoàn tất
C. Dùng ví dụ few-shot minh họa đúng thứ tự trong 10 tình huống khác nhau
D. Thêm một agent kiểm tra riêng, rà tuân thủ trước khi chuyển sang agent tài chính

Đáp án & giải thích

Đúng: B

B đúng vì hook và prerequisite gate cho cưỡng chế tất định. Thao tác vật lý không chạy được cho tới khi điều kiện tiên quyết hoàn tất. Đây là cơ chế duy nhất đảm bảo tuân thủ 100%.
A sai vì chỉ thị trong prompt, dù định dạng hay nhấn mạnh kiểu gì, vẫn mang tính xác suất. Nó nâng tỷ lệ nhưng không đảm bảo 100%. Một lần lỗi trong thao tác tài chính là hậu quả thật.
C sai vì few-shot tăng độ chính xác nhưng vẫn là xác suất. Mười ví dụ có thể đạt 98%, nhưng 100% đòi cơ chế tất định.
D sai vì bản thân agent kiểm tra cũng mang tính xác suất — nó có thể thỉnh thoảng bỏ sót vi phạm. Chỉ gate ở tầng code mới là đảm bảo tất định.

Câu 4

Một khách gửi yêu cầu gồm ba vấn đề: trả hàng, khiếu nại một khoản phí, và đổi địa chỉ. Agent nên xử thế nào?

A. Xử vấn đề gấp nhất trước rồi mời khách gọi lại cho hai vấn đề còn lại
B. Chuyển cả ba vấn đề cho nhân viên người thật vì yêu cầu gộp quá phức tạp
C. Xử mỗi vấn đề trong một hội thoại riêng để tránh nhầm lẫn
D. Phân rã thành ba mục, xử lý song song, rồi tổng hợp thành một phương án trả lời

Đáp án & giải thích

Đúng: D

D đúng vì yêu cầu nhiều vấn đề nên được phân rã thành các mục riêng, xử lý song song với context dùng chung (thông tin tài khoản khách liên quan tới cả ba), rồi tổng hợp thành một response giải quyết trọn vẹn.
A sai vì nó không giải quyết hết vấn đề và tạo trải nghiệm tệ khi bắt khách gọi lại.
B sai vì yêu cầu gộp là chuyện bình thường trong hỗ trợ khách hàng. Đẩy hết lên người thật thì agent còn nghĩa lý gì.
C sai vì hội thoại tách rời làm mất context dùng chung (thông tin tài khoản) và bắt khách đi qua nhiều vòng tương tác.

Câu 5

Trong tình huống nào thì hướng dẫn bằng prompt (thay vì cưỡng chế bằng code) là chấp nhận được?

A. Đảm bảo hoàn tiền chỉ được xử lý sau khi xác minh danh tính
B. Định dạng response của agent theo markdown với heading và bullet
C. Bắt buộc kiểm tra chống rửa tiền trước khi chuyển khoản quốc tế
D. Chặn xóa tài khoản khi chưa có phê duyệt của quản lý

Đáp án & giải thích

Đúng: B

B đúng vì sở thích định dạng là chuyện rủi ro thấp. Thỉnh thoảng trả về plain text thay vì markdown không phải rủi ro kinh doanh. Hướng dẫn bằng prompt là đủ cho yêu cầu về style và định dạng.
A sai vì hoàn tiền không xác minh là rủi ro tài chính. Thao tác tài chính cần cưỡng chế bằng code.
C sai vì kiểm tra AML là yêu cầu pháp lý. Một lần bỏ sót có thể dẫn tới chế tài. Cần cưỡng chế tất định bằng hook.
D sai vì xóa tài khoản là thao tác rủi ro cao và không hoàn tác được. Cần cưỡng chế bằng code (đòi token phê duyệt của quản lý) để đảm bảo bước phê duyệt.