Đưa output của agent ra đời thật mà không bị vỡ lặng lẽ

Bạn cần bài này khi agent đã tạo ra thứ "chạy được" trong chat hoặc preview, nhưng thứ đó sắp đi vào workflow thật: gửi cho khách, cập nhật dữ liệu, chạy nền, xuất báo cáo, đổi logic production, hoặc làm đầu vào cho một bước khác.

Checklist dùng ngay trước khi đưa ra đời thật:

1. Chạy ca đẹp để biết đường thường không vỡ.
2. Chạy 3-5 ca xấu: thiếu dữ liệu, dữ liệu dài/bẩn, input lạ, thao tác lặp, thao tác đồng thời.
3. Đặt tín hiệu ở ranh giới: nơi output của agent chạm người dùng, dữ liệu thật, file thật, tiền thật, hoặc hệ thống khác.
4. Chạy nhỏ trước: một nhóm, một file, một ngày, một batch.
5. Sau khi chạy, nhìn số thật rồi mới tăng phạm vi.

Production không hỏi "agent có trả lời hay không". Production hỏi "khi gặp dữ liệu bẩn, output có còn đúng không".

01Demo đẹp thường là ca dễ nhất

Trong khung chat, mọi thứ đẹp. Bạn đưa một ví dụ gọn gàng, agent xử lý ngon, trả về đúng cái mong đợi, bạn gật đầu. Rồi output đó gặp đời thật: một dòng thiếu nửa trường, một người nhập sai format, một ca hiếm mỗi tháng mới có một lần. Nó không nổ lớn. Nó chỉ âm thầm bỏ sót một dòng, tính sai một số, hoặc cho qua thứ đáng lẽ phải chặn.

Cái demo lừa bạn vì nó được chơi trên đường bạn tự dọn. Ví dụ của con người thường là ca điển hình: đủ dữ liệu, đúng format, không ai phá ngang. Agent rất giỏi ở ca điển hình. Nhưng đời thật không chỉ gửi ca điển hình.

02Ba kiểu vỡ hay gặp ngoài thực địa

Gần như mọi cú vấp production tôi từng thấy rơi vào ba khuôn này:

• Ngã ở rìa: ca thường đúng, ca hiếm sai, và agent vẫn tự tin như nhau.
• Mất cảnh giác: nó đúng nhiều lần, bạn thôi nhìn; lần sai đầu tiên lọt qua vì thói quen kiểm đã biến mất.
• Im lặng tưởng là ổn: không có lỗi nổ ra, nhưng output vẫn sai. Đây là loại mệt nhất vì hệ thống trông yên.

Ba kiểu này có chung một gốc: agent không tự biết khi nào nó đang ở vùng rủi ro. Vậy nên bạn phải đặt dấu hiệu bên ngoài nó.

Prompt dùng ngay để bắt agent tự tạo bộ ca kiểm:

We are preparing this agent workflow for real use.

Task:
[describe what the agent does]

Real boundary:
[what it may change / what it may only suggest / what needs human approval]

Create a release checklist with:
1. 3 normal cases it must pass.
2. 7 ugly cases that could happen in the real world.
3. The expected behavior for each ugly case.
4. Signals we should monitor after release.
5. A rollback or pause condition.

Be strict. Focus on quiet failures, not only obvious crashes.

03Đặt tín hiệu ở nơi output chạm đời thật

Sai lầm phổ biến là kiểm trong chat, rồi thôi. Nhưng rủi ro thật thường nằm ở chỗ output rời khỏi chat: email được gửi, dữ liệu được ghi, báo cáo được đọc, API được gọi, quyết định được đưa ra.

Đặt tín hiệu ở ranh giới đó. Ví dụ:

• Agent phân loại ticket → đo tỉ lệ ticket bị sửa lại sau đó.
• Agent trích dữ liệu hóa đơn → log các dòng thiếu field hoặc confidence thấp.
• Agent viết email → gửi cho chính bạn hoặc một nhóm nhỏ trước.
• Agent cập nhật file → diff và sample-check vài dòng thật.
• Agent chạy nền → có log số item xử lý, số item bỏ qua, số lỗi im lặng.

Không cần hệ thống đo phức tạp ngay từ đầu. Chỉ cần một tín hiệu khiến cái sai không nằm im.

04Khi nào có thể tin hơn

Bạn tăng mức tin khi có bằng chứng qua thời gian, không phải khi agent nói nghe chắc.

Tin hơn khi:

• Nó đã qua cả ca đẹp lẫn ca xấu.
• Bạn có log hoặc mẫu kiểm ở ranh giới thật.
• Canary nhỏ chạy ổn trong một khoảng đủ dài.
• Khi sai, hệ thống báo được hoặc người vận hành nhìn thấy được.

Chưa nên tin hơn khi:

• Chỉ mới test một ví dụ sạch.
• Agent chỉ mô tả rằng "nên hoạt động".
• Không có ai nhìn output sau khi chạy.
• Sai sẽ âm thầm đi vào dữ liệu, khách hàng, hoặc quyết định.

Cụm này gom các bài học ngoài thực địa: agent ngã ở rìa, bẫy mất cảnh giác, và phát hiện sớm lỗi im lặng. Điểm chung của cả ba là một câu: demo đẹp là điểm bắt đầu, không phải bằng chứng cuối.