Mọi người đều ám ảnh với prompt. Họ tinh chỉnh lời chào, điều chỉnh tông giọng, và lo lắng liệu mô hình nghe có đủ ấm áp hay không. Đó là một sự xao nhãng. Khi một agent AI bắt đầu gửi email thật đến người dùng thật, mối nguy hiểm không phải là nó viết "Trân trọng" thay vì "Thân ái". Mối nguy hiểm là bạn không thể biết chắc chắn điều gì đã xảy ra giữa quyết định của agent và lúc tin nhắn nằm trong hộp thư đến. Tôi nhìn vào ranh giới trước tiên. Đó là nơi các hệ thống production âm thầm sụp đổ.
Hợp đồng chính là điểm yếu
Các bản demo AI rất dễ dãi. Một cuộc hội thoại mượt mà trong cửa sổ trình duyệt che giấu một mớ các giả định. Trong môi trường production, lỗ hổng thực sự nằm ở "hợp đồng" giữa ba thứ: quyết định của agent, công cụ thực thi hành động, và bước xác minh kết quả. Nếu ranh giới đó mờ nhạt, hệ thống sẽ hoạt động tuyệt vời cho đến khi nó không còn như vậy nữa. Sau đó, nó thất bại một cách âm thầm, gửi trùng lặp cho toàn bộ phân khúc khách hàng, hoặc gửi tin nhắn sai thời điểm mà không có hồ sơ rõ ràng về lý do tại sao. Prompt có thể hay như thơ, nhưng kiến trúc bên dưới vẫn có thể chỉ được gắn kết bằng những sợi dây thừng.
Đừng để Agent viết tự do
Sai lầm phổ biến nhất là giao cho agent một trang giấy trắng. Các đội ngũ để nó mô tả một email bằng văn bản thô, rồi tin tưởng vào một công cụ hạ nguồn sẽ phân tích ý định từ văn bản đó. Điều này rất mong manh. Một LLM có thể gợi ý một ý định hợp lý, nhưng hạ tầng của bạn không cần sự sáng tạo. Nó cần một hợp đồng. Nó cần các trường cụ thể mà máy móc có thể xác thực mà không có sự mơ hồ.
Khi một agent phát ra một yêu cầu gửi email, đầu ra nên mang chính xác những gì hệ thống vận hành yêu cầu:
- Template version: Phiên bản thân email nào đang được sử dụng, để bạn biết người dùng đã thấy gì.
- Recipient scope: Ai sẽ nhận email này, được xác định bởi ID người dùng hoặc các quy tắc phân khúc, chứ không phải bằng ngôn ngữ tự nhiên như "người dùng vừa đăng ký".
- Trace ID: Một mã định danh duy nhất đi theo yêu cầu này từ agent qua bộ thực thi, qua nhà cung cấp email và vào nhật ký (logs) của bạn.
- Time window: Khung thời gian gửi email này có hiệu lực, để các quyết định cũ của agent không kích hoạt việc gửi email vào lúc nửa đêm sau đó vài giờ.
- Idempotency: Một khóa để ngăn chặn cùng một lệnh gửi logic bị thực hiện hai lần nếu agent thử lại hoặc mạng gặp sự cố.
Văn bản thô là một API tồi tệ. Nó để lại kẽ hở cho sự mơ hồ về mức độ khẩn cấp, đối tượng và hành động. Các trường cụ thể thì máy có thể đọc được, có thể kiểm chứng và có thể kiểm thử. Chúng biến một chỉ dẫn mơ hồ thành một lệnh có thể xác minh.
Hành động, thay vì Văn xuôi
Thay vì giao cho agent một nhiệm vụ viết lách không giới hạn, hãy giới hạn nó trong một menu các hành động được cho phép. Hãy coi nó như một API nội bộ với một enum cố định. Agent không soạn dòng tiêu đề hay băn khoăn về lời chào. Nó chọn một hành động như send_review_request hoặc send_retry_notice. Đó là giới hạn cho sự tự do sáng tạo của nó.
Một bộ thực thi (executor) mang tính xác định sau đó sẽ lấy khóa hành động đó, lấy đúng template từ hệ thống quản lý phiên bản, đổ dữ liệu đã được chuẩn hóa vào, điền danh sách người nhận từ một nguồn đã được xác minh, và xây dựng lệnh cuối cùng. Agent quyết định điều gì cần xảy ra. Những dòng code nhàm chán, có thể dự đoán được sẽ quyết định cách thức nó diễn ra.
Sự tách biệt này giúp hệ thống dễ dàng kiểm thử. Bạn có thể xác minh rằng một trạng thái đầu vào nhất định sẽ kích hoạt send_retry_notice một cách đáng tin cậy mà không cần chạy suy luận LLM. Các bài kiểm thử đơn vị (unit tests) của bạn sẽ trở nên nhanh chóng và mang tính xác định vì chúng kiểm tra logic ánh xạ, chứ không phải nhiệt độ (temperature) của mô hình. Các bài kiểm thử tích hợp (integration tests) của bạn sẽ tập trung vào việc liệu bộ thực thi có ánh xạ hành động chính xác đến dịch vụ email hay không, chứ không phải liệu mô hình có đang "vui vẻ" hay không.
Xây dựng theo năm lớp
Một hệ thống vững chắc không nảy sinh từ một prompt duy nhất. Nó được xây dựng theo từng lớp, và mỗi lớp sở hữu một trách nhiệm duy nhất, rõ ràng.
1. Backend giảm thiểu sự kiện thành dữ liệu an toàn.
Cho dù tác nhân kích hoạt là một webhook, một thay đổi trong cơ sở dữ liệu hay một tác vụ định kỳ, lớp này sẽ làm sạch đầu vào, loại bỏ các trường không mong muốn và chỉ đưa cho agent những gì nó cần. Nếu một payload webhook chứa hai mươi trường nhưng agent chỉ cần hai trường, hãy chỉ truyền hai trường đó. Không có văn bản thô nào của người dùng được phép chạm đến lớp quyết định mà không qua kiểm tra.
2. Agent chọn một hành động từ schema cố định.
Nó xem xét ngữ cảnh, đưa ra quyết định và xuất ra một trong các khóa hành động đã được định sẵn cùng với siêu dữ liệu (metadata) bắt buộc. Nó không soạn văn bản. Nó không đoán người nhận. Nó trả về một payload có cấu trúc mà lớp tiếp theo có thể xác thực dựa trên JSON schema.
3. Công cụ xác thực các quyền và các trường bắt buộc.
Ngữ cảnh agent này có quyền kích hoạt send_review_request cho người dùng này không? Phạm vi người nhận có khác rỗng và nằm trong giới hạn cho phép không? Khóa idempotency có hiện diện và là duy nhất trong nhật ký của bạn không? Trace ID có đúng định dạng không? Hãy báo lỗi tại đây một cách rõ ràng trước khi bất kỳ dịch vụ email nào được chạm tới.
4. Dịch vụ email ghi nhật ký việc gửi kèm theo một trace ID.
Mọi tin nhắn rời khỏi hệ thống của bạn nên mang theo mã định danh trace đó thông qua API của nhà cung cấp và đi vào ngăn xếp quan sát (observability stack) của bạn. Nếu người dùng phàn nàn rằng họ nhận được hai bản sao, bạn sẽ có thể truy vấn một ID và thấy chính xác nơi sự trùng lặp bắt nguồn: một lệnh gọi agent được thử lại, một executor không ổn định, hoặc một callback hoạt động sai.
5. Kiểm thử đầu cuối (end-to-end test) kiểm tra hộp thư đến thực tế về nội dung và hiệu quả.
Mở tin nhắn đã được hiển thị trong một hộp thư thực tế. Dòng tiêu đề có được điền chính xác không? Liên kết hủy đăng ký có hoạt động không? Việc nhấp vào nút kêu gọi hành động (call-to-action) chính có dẫn đến đúng trang với trạng thái người dùng chính xác không? Một unit test vượt qua chỉ có nghĩa là mã đã chạy. Chỉ có kiểm thử hộp thư mới cho bạn biết email thực sự hoạt động đối với con người.
Bằng chứng thay vì phỏng đoán
Khi một bài kiểm tra thất bại trong quy trình này, bạn cần bốn bằng chứng cụ thể. Đừng chấp nhận bất cứ điều gì ít hơn thế.
- Quyết định ban đầu từ agent. Nó đã chọn hành động nào, và ngữ cảnh đầu vào đầy đủ là gì?
- Lệnh đã được chuẩn hóa từ công cụ. Deterministic executor đã xây dựng cái gì sau khi áp dụng template, logic hydration và các quy tắc xác thực?
- Tin nhắn trong hộp thư cô lập. Không phải là nhật ký về những gì bạn nghĩ mình đã gửi, mà là tin nhắn MIME thực tế, bao gồm cả headers và tất cả mọi thứ, được ghi lại trong một hộp thư kiểm thử chuyên dụng.
- Hiệu quả cuối cùng sau khi nhấp vào liên kết. Trạng thái trang kết quả, thay đổi cơ sở dữ liệu, hoặc sự kiện bên ngoài chứng minh rằng email đã đạt được mục đích của nó.
Nếu thiếu một mảnh ghép, đội ngũ của bạn sẽ lấp đầy khoảng trống đó bằng những giả định. Họ sẽ phỏng đoán. Phỏng đoán trong tự động hóa rất tốn kém. Nó tiêu tốn hàng giờ đồng hồ, làm xói mòn niềm tin và biến mọi sự cố thành một bí ẩn pháp y thay vì một