Test, triển khai và giám sát AI Agent tùy chỉnh

Xây dựng một agent chỉ mất một buổi chiều. Duy trì hoạt động ổn định của nó lại cần một chiến lược.

🔄 Tóm tắt nhanh: Trong Bài học 6, bạn đã học cách xây dựng quy trình làm việc nhiều bước với các nhánh, vòng lặp, xử lý song song và xử lý lỗi. Những trình xử lý lỗi mà bạn đã thêm vào thì sao? Chúng là tuyến phòng thủ đầu tiên của bạn trong môi trường sản xuất. Bài học này sẽ bao gồm mọi thứ khác.

Hầu hết các agent không cần code đều thất bại không phải vì chúng được xây dựng sai, mà vì chúng được triển khai mà không được kiểm thử đúng cách và bị bỏ quên mà không được giám sát. Đừng trở thành người xây dựng như vậy.

Kiểm thử: Không chỉ là "Nó đã hoạt động một lần"

Kiểm thử diễn ra trong ba giai đoạn, và hầu hết mọi người bỏ qua hai giai đoạn cuối.

Giai đoạn 1: Kiểm thử trường hợp thành công (5 phút)

Đây là những gì bạn đã làm trong Bài học 4 - gửi một vài đầu vào rõ ràng và xác nhận rằng agent xử lý chúng chính xác. Email hỗ trợ nhận được phản hồi hỗ trợ. Email bán hàng nhận được phản hồi bán hàng.

Kiểm thử trường hợp thành công xác nhận logic cơ bản hoạt động. Nó không xác nhận rằng agent đã sẵn sàng cho môi trường sản xuất.

Giai đoạn 2: Kiểm thử các trường hợp ngoại lệ (20 phút)

Các trường hợp ngoại lệ là những dữ liệu đầu vào bất thường mà agent của bạn chắc chắn sẽ gặp phải trong môi trường sản xuất. Hãy kiểm thử những trường hợp này:

Đối với mỗi trường hợp ngoại lệ, hãy ghi lại những gì đã xảy ra và liệu phản hồi có thể chấp nhận được hay không.

✅ Kiểm tra nhanh: Agent của bạn tự động trả lời email đến. Một công ty khác cũng có agent tự động trả lời. Điều gì xảy ra khi họ gửi email cho nhau?

Câu trả lời: Một vòng lặp vô hạn. Agent A tự động trả lời agent B. Agent B tự động trả lời agent A. Cứ thế tiếp diễn mãi mãi - cho đến khi tài khoản của bạn bị gắn cờ là thư rác hoặc bạn đạt đến giới hạn số lượng email gửi đi. Cách khắc phục: thêm bộ lọc bỏ qua email từ các địa chỉ tự động trả lời đã biết, hoặc kiểm tra tiêu đề "tự động trả lời".

Giai đoạn 3: Kiểm tra khối lượng (10 phút)

Gửi 20-30 email liên tiếp nhanh chóng. Điều này sẽ cho thấy:

• Giới hạn số lượng: Nền tảng của bạn có bị hạn chế sau 10 lần kích hoạt nhanh chóng không?
• Thứ tự: Email có được xử lý theo thứ tự hay ngẫu nhiên?
• Xử lý trùng lặp: Nếu cùng một email được kích hoạt hai lần, agent có xử lý nó hai lần không?
• Chi phí: 30 lần chạy đã tốn bao nhiêu chi phí cho các cuộc gọi API và hoạt động trên nền tảng?

Triển khai lên môi trường sản xuất

Agent của bạn đã vượt qua kiểm thử. Đã đến lúc đưa vào hoạt động chính thức. Nhưng không phải cùng một lúc.

Triển khai từng bước

Tuần 1: Chế độ ẩn. Agent chạy trên tất cả các email đến nhưng không gửi phản hồi. Nó ghi lại những gì đáng lẽ nó sẽ gửi. Bạn xem xét nhật ký hàng ngày và phát hiện sự cố trước khi khách hàng nhìn thấy chúng.

Tuần 2: 10% lưu lượng truy cập. Chuyển hướng 10% email đến agent (sử dụng bộ lọc — chỉ email từ các địa chỉ kết thúc bằng A-C, chẳng hạn). Giám sát chặt chẽ. Khắc phục mọi sự cố.

Tuần 3: 50% lưu lượng truy cập. Nếu tuần 2 diễn ra tốt đẹp, hãy tăng lên một nửa. Vẫn tiếp tục giám sát.

Tuần 4: 100% lưu lượng truy cập. Triển khai đầy đủ. Nhưng việc giám sát không bao giờ dừng lại.

Không thể triển khai từng bước? Ít nhất, hãy chạy chế độ ẩn trong 2-3 ngày trước khi đưa vào hoạt động chính thức. Nó giúp phát hiện các vấn đề rõ ràng nhất mà không ảnh hưởng đến khách hàng.

Danh sách kiểm tra trước khi vận hành

Trước khi bật công tắc:

• [ ] Đã kiểm thử với hơn 20 đầu vào đa dạng, bao gồm cả các trường hợp ngoại lệ
• [ ] Trình xử lý lỗi được thiết lập cho mọi lệnh gọi API bên ngoài
• [ ] Ghi nhật ký được kích hoạt (mọi email đã xử lý đều được ghi vào bảng tính)
• [ ] Phản hồi dự phòng được cấu hình khi AI gặp lỗi
• [ ] Giới hạn tỷ lệ đã được kiểm tra (nền tảng sẽ không hạn chế bạn)
• [ ] Ngăn chặn vòng lặp trả lời tự động đã được thiết lập
• [ ] Có đường dẫn chuyển tiếp cho người dùng (agent không thể xử lý mọi thứ)
• [ ] Kill switch sẵn sàng (bạn có thể vô hiệu hóa agent trong 30 giây)

✅ Kiểm tra nhanh: "Kill switch" cho agent là gì?

Câu trả lời: Một cách để dừng ngay lập tức agent xử lý các đầu vào mới. Trên Zapier, hãy tắt Zap. Trên Make, hãy hủy kích hoạt kịch bản. Trên n8n, hãy vô hiệu hóa quy trình làm việc. Bạn cần điều này trong trường hợp khẩn cấp — nếu agent bắt đầu gửi phản hồi sai, bạn cần dừng nó nhanh chóng. Hãy biết vị trí của nút tắt trước khi đưa vào hoạt động.

Giám sát: Cuộc chơi dài hạn

Agent của bạn đã hoạt động. Bây giờ thì sao?

Ba chỉ số quan trọng

1. Tỷ lệ chính xác. Agent phân loại chính xác bao nhiêu phần trăm email? Xem lại bảng tính nhật ký của bạn hàng tuần. Kiểm tra ngẫu nhiên 10 phân loại. Nếu độ chính xác giảm xuống dưới 85%, hãy điều tra.

2. Thời gian phản hồi. Mất bao lâu từ khi nhận email đến khi gửi phản hồi? Hầu hết các nền tảng đều hiển thị thời gian thực thi trong nhật ký của chúng. Nếu quy trình làm việc bắt đầu mất hơn 30 giây, bạn có thể gặp phải tắc nghẽn API hoặc mô hình AI bị quá tải.

3. Tỷ lệ lỗi. Tỷ lệ phần trăm các lần chạy quy trình làm việc bị lỗi là bao nhiêu? Kiểm tra bảng điều khiển lỗi của nền tảng. Bất kỳ tỷ lệ lỗi nào trên 5% đều cần được điều tra. Nguyên nhân thường gặp: Sự cố API, mã xác thực hết hạn, định dạng dữ liệu thay đổi.

Quy trình rà soát hàng tuần (15 phút)

Mỗi thứ Hai, hãy dành 15 phút cho việc này:

1. Mở bảng tính nhật ký của bạn. Quét tìm bất kỳ điều gì bất thường — phân loại không mong muốn, dữ liệu bị thiếu, các mục trùng lặp.
2. Kiểm tra nhật ký lỗi nền tảng. Có bất kỳ lần chạy nào thất bại không? Nguyên nhân là gì?
3. Xem xét 5-10 tương tác ngẫu nhiên của agent từ đầu đến cuối. Khách hàng có nhận được phản hồi chính xác không?
4. Ghi chú bất kỳ mẫu nào. Thứ Hai có phải là ngày có khối lượng giao dịch cao không? Có phải một số loại email nhất định luôn bị phân loại sai?

Thói quen 15 phút này giúp phát hiện các vấn đề trước khi chúng trở thành khủng hoảng.

Khi nào cần cập nhật agent

Agent của bạn không phải là công cụ "cài đặt một lần và quên đi". Cập nhật khi:

• Độ chính xác phân loại giảm — cần tinh chỉnh prompt AI
• Xuất hiện các danh mục email mới — doanh nghiệp của bạn đã thêm dòng sản phẩm mới
• Số lượng khiếu nại của khách hàng tăng — có điều gì đó không ổn
• Lỗi quy trình làm việc tăng đột biến — API đã thay đổi, token đã hết hạn
• Các quy tắc kinh doanh thay đổi — SLA mới, giá cả mới, chính sách mới

Quy trình cập nhật an toàn: Sao chép quy trình làm việc → thực hiện thay đổi trên bản sao → kiểm tra với hơn 20 đầu vào → so sánh kết quả với bản gốc → chỉ thay thế khi phiên bản mới tốt hơn.

Những rủi ro trong sản xuất

Tạo bộ kiểm thử trước khi ra mắt

Đừng tung ra thị trường cho đến khi bạn đã chạy thử nghiệm với các agent gây hại. Mở ChatGPT, Claude hoặc Gemini:

Đóng vai trò là kỹ sư kiểm thử chất lượng cho các AI agent. Thiết kế cho tôi một bộ kiểm thử trước khi ra mắt gồm 25 đầu vào đa dạng cho agent của tôi, bao gồm cả các trường hợp ngoại lệ có khả năng gây lỗi.

Agent của tôi:
- Mục đích: [mô tả trong một câu]
- Kích hoạt: [điều gì bắt đầu một lần chạy — ví dụ: email mới, gửi biểu mẫu, đã lên lịch]
- Các hành động chính: [các bước theo thứ tự]
- Công cụ được kết nối: [danh sách các dịch vụ bên ngoài]
- Định dạng đầu vào dự kiến: [ví dụ: "Email tiếng Anh, 50-500 từ, từ khách hàng bên ngoài"]
- Đầu ra chấp nhận được trông như thế nào: [ví dụ: "được phân loại là hỗ trợ/bán hàng/thư rác + thư trả lời nháp nếu không phải thư rác"]
- Chế độ lỗi nghiêm trọng nhất: [ví dụ: "gửi sai số tiền hoàn trả", "trả lời email lừa đảo có dữ liệu khách hàng"]

Thiết kế bộ kiểm thử với 25 đầu vào thuộc các danh mục này:

TRƯỜNG HỢP THUẬN LỢI (5 đầu vào) — các trường hợp rõ ràng mà agent nên xử lý thành công. Đối với mỗi trường hợp: đầu vào, đầu ra dự kiến, tiêu chí đạt.

CÁC TRƯỜNG HỢP NGOẠI LỆ (10 đầu vào) — kỳ lạ nhưng thực tế. Tối thiểu bao gồm:
- Đầu vào trống/tối thiểu
- Độ dài cực lớn (gấp 3-5 lần bình thường)
- Nội dung không phải tiếng Anh
- Đầu vào có định dạng phức tạp (bảng, khối mã, biểu tượng cảm xúc)
- Đầu vào tự động trả lời / do bot tạo ra
- Đầu vào có hướng dẫn nhúng cố gắng chèn lời nhắc
- Bản sao của một đầu vào gần đây (kiểm tra tính bất biến)

KIỂM TRA GIỚI HẠN (5 đầu vào) — những thứ nằm ngay ngoài phạm vi dự định của agent. Liệu nó nên từ chối một cách lịch sự hay thử và thất bại?

KIỂM TRA THẤT BẠI (5 đầu vào) — cố tình làm hỏng các công cụ. Điều gì xảy ra nếu API CRM bị lỗi? Điều gì xảy ra nếu phản hồi của AI là JSON bị lỗi? Điều gì xảy ra nếu trường giữ chỗ bị trống?

Đối với mỗi bài kiểm tra, hãy xuất ra dưới dạng bảng: TEST_ID | CATEGORY | INPUT | EXPECTED_BEHAVIOR | HOW_I_KNOW_IT_PASSED.

Cuối cùng: xếp hạng 3 bài kiểm tra QUAN TRỌNG NHẤT mà tôi phải vượt qua trước khi triển khai — những bài kiểm tra bảo vệ tôi khỏi các chế độ lỗi có rủi ro cao nhất ở trên.

Những gì bạn sẽ thấy: Một bộ kiểm thử gồm 25 đầu vào mà bạn có thể sao chép vào bảng tính và chạy qua agent của mình trước khi đưa vào hoạt động. Hầu hết các công cụ xây dựng không cần code đều được phát hành sau khi kiểm thử 3 đầu vào thành công và phát hiện ra một cách khó khăn rằng agent của họ lặp vô hạn khi gửi phản hồi tự động.

Chạy tất cả 25 đầu vào ở chế độ ẩn — agent xử lý chúng nhưng không gửi phản hồi. Xem xét từng đầu vào so với cột hành vi dự kiến. Chỉ đưa vào hoạt động sau khi ít nhất 22/25 đầu vào vượt qua và 3 bài kiểm thử quan trọng vượt qua 100%.

Những điểm chính cần ghi nhớ

• Kiểm thử có ba giai đoạn: Trường hợp bình thường (cơ bản), trường hợp ngoại lệ (đầu vào bất thường) và quy mô lớn (mức độ) — đừng bỏ qua hai giai đoạn cuối
• Triển khai dần dần: Chế độ thử nghiệm → 10% → 50% → 100%, phát hiện sự cố trước khi khách hàng gặp phải
• Theo dõi ba chỉ số hàng tuần: Tỷ lệ chính xác, thời gian phản hồi và tỷ lệ lỗi
• Không bao giờ sửa đổi trực tiếp quy trình làm việc đang hoạt động — sao chép, kiểm thử, so sánh, sau đó thay thế
• Thiết lập một quy trình đánh giá hàng tuần 15 phút — đó là sự khác biệt giữa một agent hoạt động bền bỉ và một agent bị lỗi âm thầm