Thực Thi Quy Trình và Bàn Giao

Những điều bạn cần biết

Task Statement 1.4 vạch ra ranh giới rõ ràng giữa hai cách tiếp cận để kiểm soát hành vi của agent: hướng dẫn dựa trên prompt và thực thi theo lập trình. Kỳ thi kiểm tra sự khác biệt này liên tục, và nếu hiểu sai ở các tình huống rủi ro cao thì bạn sẽ mất điểm.

Phổ Thực Thi

Có hai cách hoàn toàn khác nhau để thực thi thứ tự quy trình làm việc trong một hệ thống agentic:

Hướng dẫn dựa trên prompt nghĩa là đưa các 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." Cách này hoạt động hầu hết thời gian — có lẽ 90-95% trường hợp. Nhưng nó có tỷ lệ thất bại khác không. Model mang tính xác suất. Đôi khi nó sẽ bỏ qua các bước, sắp xếp lại thứ tự, hoặc diễn giải chỉ thị một cách lỏng lẻo. Với các thao tác rủi ro thấp, tỷ lệ thất bại này là chấp nhận được.

Thực thi theo lập trình nghĩa là triển khai hook, cổng điều kiện tiên quyết (prerequisite gate), hoặc kiểm tra ở mức mã nguồn để chặn vật lý các tool ở giai đoạn sau cho đến khi các điều kiện tiên quyết được hoàn thành. Ví dụ: tool process_refund không thể thực thi cho đến khi get_customer đã trả về một ID khách hàng đã được xác minh. Cách này hoạt động mọi lần. Nó mang tính tất định, không mang tính xác suất. Dù model quyết định làm gì đi nữa, cổng vẫn ngăn chặn thứ tự thực thi sai.

Quy Tắc Quyết Định Trong Kỳ Thi

Kỳ thi áp dụng một quy tắc quyết định nhất quán trên nhiều tình huống:

• Các thao tác tài chính (hoàn tiền, chuyển khoản, thanh toán): thực thi theo lập trình. Một lần hoàn tiền chưa được xác minh vào sai tài khoản là một tổn thất tài chính.
• Các thao tác bảo mật (xác minh danh tính, kiểm soát truy cập): thực thi theo lập trình. Một lần vượt qua xác minh danh tính là một vi phạm bảo mật.
• Các thao tác tuân thủ (kiểm tra AML, yêu cầu quy định): thực thi theo lập trình. Một lần bỏ sót kiểm tra tuân thủ có thể dẫn đến hình phạt pháp lý.
• Các thao tác rủi ro thấp (sở thích định dạng, hướng dẫn phong cách, thứ tự đầu ra): hướng dẫn dựa trên prompt là chấp nhận được. Một sự không nhất quán về định dạng không phải là rủi ro kinh doanh.

Kỳ thi sẽ đưa ra các giải pháp dựa trên prompt như các lựa chọn đáp án cho các tình huống rủi ro cao. Hãy loại bỏ chúng. System prompt được tăng cường, các ví dụ few-shot, và các chỉ thị mạnh hơn đều cải thiện độ chính xác nhưng không cái nào cung cấp đảm bảo tất định. Khi tình huống liên quan đến tiền bạc, bảo mật, hoặc tuân thủ, đáp án luôn là thực thi theo lập trình.

Cổng Điều Kiện Tiên Quyết Trong Thực Tế

Một cổng điều kiện tiên quyết là một kiểm tra theo lập trình chặn một tool không cho thực thi cho đến khi một điều kiện trước đó được đáp ứng. Trong một agent hỗ trợ khách hàng:

1. Agent có quyền truy cập các tool get_customer, lookup_order, và process_refund.
2. Một cổng điều kiện tiên quyết kiểm tra: get_customer đã trả về một ID khách hàng đã được xác minh cho phiên này chưa?
3. Nếu có, process_refund thực thi bình thường.
4. Nếu không, process_refund trả về thông báo lỗi: "Không thể xử lý hoàn tiền — danh tính khách hàng chưa được xác minh. Vui lòng gọi get_customer trước."

Cổng là mã nguồn, không phải một chỉ thị prompt. Model không thể vượt qua nó bằng cách quyết định bỏ qua bước xác minh. Ngay cả khi model cố gắng gọi process_refund trực tiếp, cổng vẫn chặn lệnh gọi đó và trả về một 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 cung cấp các sự kiện hook vòng đời dành riêng cho việc quản lý subagent. Chúng bổ sung cho các hook PreToolUse và PostToolUse được đề cập trong Task Statement 1.5.

SubagentStart kích hoạt khi một subagent được sinh ra thông qua Agent tool (trước đây là Task tool). Nó cung cấp cho coordinator một điểm hook để ghi nhật ký, xác thực, hoặc sửa đổi lệnh gọi subagent trước khi subagent bắt đầu thực thi. Các trường hợp sử dụng bao gồm thực thi giới hạn tốc độ khi sinh subagent, ghi nhật ký subagent nào được gọi để phục vụ quan sát, và xác thực rằng coordinator đang truyền đúng ngữ cảnh cần thiết.

SubagentStop kích hoạt khi một subagent hoàn thành thực thi và trả kết quả về cho coordinator. Hook này cho phép bạn chặn, xác thực, hoặc biến đổi đầu ra của subagent trước khi coordinator xử lý nó. Các trường hợp sử dụng bao gồm xác thực rằng đầu ra của subagent tuân theo các schema mong đợi, loại bỏ dữ liệu nhạy cảm khỏi kết quả của subagent, và ghi nhật ký hoàn thành của subagent để giám sát hiệu năng.

Hook có phạm vi subagent: Các subagent có thể định nghĩa các hook PreToolUse và PostToolUse của riêng chúng trong frontmatter AgentDefinition của chúng. Các hook này có phạm vi giới hạn trong subagent — chúng chỉ chặn các lệnh gọi tool được thực hiện bởi subagent cụ thể đó, không phải coordinator hay các subagent khác. Điều này cho phép thực thi chính sách theo từng subagent (ví dụ: một subagent xử lý hóa đơn có thể có một hook PreToolUse chặn các khoản hoàn tiền vượt ngưỡng, trong khi một subagent hỗ trợ kỹ thuật không có giới hạn như vậy).

Tự động chuyển đổi hook Stop: Khi frontmatter của một subagent định nghĩa các hook Stop, chúng sẽ tự động được chuyển đổi thành các sự kiện SubagentStop khi chạy. Điều này có nghĩa là bạn có thể định nghĩa logic dọn dẹp hoặc xác thực ngay trong cấu hình của chính subagent, và SDK đảm bảo nó chạy như một sự kiện vòng đời SubagentStop khi subagent hoàn thành.

Xử Lý Yêu Cầu Nhiều Vấn Đề

Khách hàng thường xuyên gửi các yêu cầu với nhiều vấn đề: "Tôi muốn trả lại đơn hàng, cập nhật địa chỉ giao hàng, và hỏi về điểm thưởng thành viên của tôi." Kỳ thi kiểm tra cách các agent nên xử lý các yêu cầu ghép này.

Cách tiếp cận đúng:

1. Phân rã yêu cầu thành các mục riêng biệt (trả hàng, cập nhật địa chỉ, hỏi về điểm thưởng).
2. Điều tra từng mục song song bằng cách sử dụng ngữ cảnh dùng chung (thông tin tài khoản của khách hàng liên quan đến cả ba mục).
3. Tổng hợp một giải pháp thống nhất giải quyết tất cả các mục trong một phản hồi duy nhất.

Cách tiếp cận sai là xử lý chúng tuần tự bằng các cuộc hội thoại riêng biệt, hoặc chỉ giải quyết mục đầu tiên và bỏ quên phần còn lại.

Giao Thức Bàn Giao Có Cấu Trúc

Khi một agent không thể giải quyết một vấn đề và phải chuyển lên cho một nhân viên hỗ trợ (human agent), việc bàn giao phải tuân theo một giao thức có cấu trúc. Ràng buộc then chốt: nhân viên hỗ trợ KHÔNG có quyền truy cập vào bản ghi cuộc hội thoại. Họ không thể cuộn qua lịch sử trò chuyện để hiểu vấn đề.

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

• ID khách hàng — để nhân viên hỗ trợ có thể tra cứu tài khoản.
• Tóm tắt hội thoại — khách hàng yêu cầu điều gì và những gì đã được thử.
• Phân tích nguyên nhân gốc rễ — đánh giá của agent về vấn đề tiềm ẩn.
• Số tiền hoàn trả (nếu có) — con số tài chính cụ thể, không phải một tham chiếu mơ hồ.
• Hành động đề xuất — điều mà agent tin rằng nhân viên hỗ trợ nên làm.

Bản tóm tắt này là thông tin duy nhất mà nhân viên hỗ trợ nhận được. Nếu nó không đầy đủ, nhân viên hỗ trợ phải yêu cầu khách hàng lặp lại mọi thứ, tạo ra trải nghiệm tồi tệ.

Ví Dụ Thực Tế: Tỷ Lệ Thất Bại 8%

Dữ liệu thực tế 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% các trường hợp. System prompt chỉ thị: "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 hoạt động đúng 92% thời gian nhưng thất bại 8% thời gian.

Tỷ lệ thất bại 8% đã dẫn đến các khoản hoàn tiền được xử lý vào sai tài khoản. Đây là một thao tác tài chính với hậu quả tiền tệ thực sự.

Cách khắc phục là một cổng điều kiện tiên quyết theo lập trình. Trước khi process_refund có thể thực thi, hệ thống kiểm tra rằng get_customer đã trả về một ID khách hàng đã được xác minh trong phiên hiện tại. Điều này loại bỏ hoàn toàn tỷ lệ thất bại 8% — không phải bằng cách cải thiện prompt, mà bằng cách ngăn chặn vật lý thứ tự thực thi sai.

Bẫy thi

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

Không tìm thấy câu hỏi luyện tập "q-1-4-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Agent SDK Overview — Anthropic
• Customer Support Resolution Agent Scenario (Skilljar) — Anthropic
• Building with Claude API (Skilljar) — Anthropic