Module 5 • Bài 4135 phút

Thiết Kế Execution Trigger và Tính Idempotency

Phân loại 3 loại Trigger (User, Event, Scheduled) và thiết lập Idempotency Key để ngăn chặn nhân đôi tác dụng phụ trong môi trường không giám sát.

Nhận diện đặc thù và rủi ro không có người giám sát của Event-driven và Scheduled
Thiết lập Idempotency Key để chống lặp giao dịch và nhân đôi side-effects

Thiết Kế Execution Trigger và Tính Idempotency

Phần lớn các ví dụ AI chatbot cơ bản đều ngầm định một cơ chế kích hoạt duy nhất: người dùng chủ động gõ câu hỏi và chờ phản hồi. Tuy nhiên, trong các sản phẩm AI Agentic thực chiến, agent có thể tự khởi động theo nhiều cách khác nhau trong hạ tầng hệ thống. Hiểu rõ Execution Trigger (Cơ chế kích hoạt thực thi) và yêu cầu về Tính Idempotency là điều kiện tiên quyết để đảm bảo agent vận hành an toàn trong môi trường tự động.

Ví dụ xuyên suốt bài: DisputeGuard — agent xử lý khiếu nại giao dịch và gian lận thanh toán cho một ứng dụng ví điện tử.

1. Ba loại Execution Trigger trong Agentic Architecture

Mỗi loại trigger mang lại mức độ chủ động khác nhau và đi kèm với các ràng buộc kỹ thuật riêng biệt:

  • User-initiated (Do người dùng kích hoạt): Người dùng chủ động gửi yêu cầu (bấm nút "Giải quyết khiếu nại", gõ lệnh trên chat). Người dùng biết rõ hành động vừa diễn ra và thường trực tiếp theo dõi phản hồi.
  • Event-driven (Do sự kiện hệ thống kích hoạt): Agent tự động thức dậy khi có một sự kiện (webhook) từ hệ thống khác bắn sang (ví dụ: khách hàng gửi form khiếu nại, có giao dịch bất thường phát sinh, ngân hàng báo lỗi thẻ).
  • Scheduled (Kích hoạt theo lịch định kỳ): Agent chạy tự động theo một chu kỳ thời gian cố định (cron job — ví dụ: 6h00 sáng mỗi ngày tổng hợp báo cáo rủi ro, 23h00 rà soát toàn bộ giao dịch nghi vấn trong ngày).

Ba Loại Execution Trigger & Cơ Chế Idempotency

Phân biệt User-initiated, Event-driven và Scheduled cùng các ràng buộc an toàn bắt buộc.

Chọn một cơ chế kích hoạt (Trigger):

Event-driven (Do sự kiện hệ thống kích hoạt)

Giám sát thời gian thực: KHÔNG (Chạy nền bất đồng bộ khi có webhook)
Yêu cầu Idempotency Key: BẮT BUỘC 100% (Ví dụ key: order_id + timestamp)
Mức độ ghi log (Disclosure): Mức 4 (Full Trace Audit Log vào Database)
Thách thức sản phẩm lớn nhất: Xử lý các webhook trùng lặp do lỗi mạng mà không làm thất thoát tài chính.
Nguyên tắc Idempotency (Chống nhân đôi tác dụng phụ)

Khi cùng một sự kiện webhook hay cron job bị gọi lại 2 lần, Idempotency Key bảo đảm thao tác thanh toán / gửi thư chỉ được thực thi đúng 1 lần duy nhất.

Event-driven và Scheduled chạy không người giám sát, bắt buộc phải có Idempotency Key và Full Trace Logging.

2. Thách thức lớn nhất của Event-Driven và Scheduled: Thiếu giám sát thời gian thực

Khác biệt cốt lõi giữa User-initiated với Event-driven / Scheduled nằm ở chỗ: Không có con người ngồi quan sát trực tiếp tại thời điểm agent vận hành.

Điều này dẫn đến 2 hệ quả sản phẩm bắt buộc:

  1. Bắt buộc chuyển Reasoning Disclosure sang dạng Audit Log (Lesson 39): Vì không có ai theo dõi tại chỗ để can thiệp nếu AI suy luận lệch, hệ thống bắt buộc phải ghi lại (persist) toàn bộ dấu vết thực thi (Execution trace, tool inputs, outputs) vào database để đội vận hành có thể đối soát và kiểm tra khi có sự cố.
  2. Chi phí chạy ngầm của Scheduled Agent (Lesson 45): Agent theo lịch sẽ kích hoạt đều đặn bất kể dữ liệu có thay đổi hay không. Nếu ngày hôm đó không có giao dịch nghi vấn mới, agent vẫn quét qua database và tiêu tốn token. PM cần thiết kế điều kiện lọc trước (Pre-filtering check) để agent chỉ chạy full workflow khi có dữ liệu mới.

3. Nguyên tắc Idempotency — Chống nhân đôi tác dụng phụ (Side Effects)

Trong môi trường phân tán, các sự kiện webhook hoặc cron job có thể bị gửi trùng lặp (Network retry, server lag). Nếu cùng một sự kiện khiếu nại đơn hàng được kích hoạt 2 lần, điều gì sẽ xảy ra?

  • Không có Idempotency: Agent chạy 2 lần độc lập → Hoàn tiền 2 lần vào ví khách hàng, gửi 2 email xác nhận, trừ 2 lần tồn kho → Thất thoát tài chính.
  • Có Idempotency (Tính bất biến khi gọi lặp lại): Hệ thống gắn một mã định danh duy nhất (Idempotency Key — ví dụ: mã giao dịch #TXN_9921). Dù agent có bị kích hoạt 10 lần với cùng key đó, hành động ghi tiền/gọi API thanh toán chỉ được thực thi đúng 1 lần duy nhất, các lần sau chỉ trả về kết quả đã xử lý mà không tạo thêm tác dụng phụ.
Loại TriggerCó người giám sát trực tiếp?Yêu cầu Idempotency KeyMức độ Logging bắt buộc
User-initiatedCó (người dùng đang chờ)Khuyến khích (ngăn double-click)Mức 1–3 tùy rủi ro
Event-drivenKhông (chạy nền bất đồng bộ)Bắt buộc 100%Mức 4 (Full Trace Log)
ScheduledKhông (chạy tự động theo giờ)Bắt buộc với các bước ghi dữ liệuMức 4 (Full Audit Report)

4. Ẩn dụ: Lễ tân, Cảm biến chống trộm và Đội bảo trì sáng thứ Hai

Sự khác biệt giữa 3 cơ chế trigger giống như 3 vị trí trong một tòa nhà:

  • Lễ tân tiếp khách (User-initiated): Trả lời khi có khách tới quầy hỏi. Khách đứng đợi và sẽ nhận ra ngay nếu lễ tân đưa nhầm tài liệu.
  • Cảm biến chống trộm (Event-driven): Tự động kích hoạt còi báo động khi có kẻ đột nhập lúc nửa đêm. Không có ai đứng sẵn ở đó, nên cảm biến phải chuẩn xác và hệ thống phải ghi hình lại toàn bộ camera để kiểm tra sau.
  • Đội bảo trì sáng thứ Hai (Scheduled): Đến kiểm tra hệ thống điện định kỳ mỗi tuần dù tuần đó không có bóng đèn nào cháy. Nếu quy trình không chặt chẽ, họ có thể vô tình thay lại một bóng đèn vừa được thay tuần trước (thiếu tính idempotency).

Bài tập 41.1: Bạn thiết kế InvoiceReminderBot — agent tự động quét các hóa đơn công nợ quá hạn và gửi email nhắc nợ có kèm mức chiết khấu thanh toán sớm được cá nhân hóa cho từng khách hàng B2B.

  1. Agent này nên thuộc loại Trigger nào? Vì sao?
  2. Phân tích rủi ro nếu hệ thống gửi lặp webhook/cron job mà không có tính Idempotency.
  3. Đề xuất trường dữ liệu làm Idempotency Key và giải thích cơ chế ngăn gửi email trùng lặp cho khách hàng.