Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 7 — Kiểm thử, xử lý lỗi và giám sát agent

Đã đọc 0/8 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Agent chạy nền, không ai nhìn. Nếu nó chết lúc 2h sáng mà bạn không biết, khách hàng chịu hậu quả và bạn mất uy tín. Bài này biến agent "chạy được" thành agent "đáng tin cậy".

Ba tầng phòng thủ

Tầng 1 - KIỂM THỬ trước khi bật (ngăn lỗi).
Tầng 2 - XỬ LÝ LỖI khi đang chạy (chịu lỗi).
Tầng 3 - GIÁM SÁT sau khi bật (phát hiện lỗi).

Tầng 1: Kiểm thử có hệ thống

Đừng chỉ test "đường hạnh phúc" (mọi thứ đẹp đẽ). Test cả ca xấu:

Bộ ca test tối thiểu:
[ ] Ca chuẩn: dữ liệu đầy đủ, đúng định dạng.
[ ] Ca thiếu trường: SĐT rỗng, email trống.
[ ] Ca dữ liệu bẩn: chữ hoa/thường, khoảng trắng, ký tự lạ.
[ ] Ca biên: giá = 0, danh sách rỗng, số âm.
[ ] Ca trùng lặp: cùng bản ghi vào hai lần.
[ ] Ca AI trả rác: output không đúng định dạng mong đợi.

Tầng 2: Xử lý lỗi (error handling)

Mỗi nền tảng có cơ chế riêng, nhưng nguyên lý chung:

  • Retry: với lỗi tạm thời (mạng chập chờn, app bận), cho agent thử lại 2-3 lần trước khi bỏ cuộc.
  • Error path / fallback: nếu một bước lỗi, rẽ sang nhánh dự phòng thay vì để cả luồng sập.
  • Thông báo lỗi: khi có lỗi, tự gửi tin cho chính bạn (email/Slack) kèm chi tiết.
Mô hình xử lý lỗi cho một bước quan trọng:
Bước gửi email khách
  |-- Thành công -> ghi log "đã gửi"
  |-- Lỗi -> Retry x3
             |-- Vẫn lỗi -> gửi Slack #alerts
                            + ghi row "CẦN XỬ TAY" vào Sheet

Nguyên tắc: thà agent báo lỗi to còn hơn im lặng làm sai. Lỗi âm thầm là loại nguy hiểm nhất.

Tầng 3: Giám sát (monitoring)

Sau khi bật, bạn cần biết agent còn sống và chạy đúng:

  • Xem execution history: mỗi nền tảng lưu lịch sử chạy; đặt lịch ngó qua hàng tuần, tìm dấu đỏ.
  • Heartbeat / báo sống: với agent chạy theo lịch, thêm bước cuối gửi "OK - đã chạy lúc {{now}}, xử lý {{so_luong}} mục" vào một kênh log. Ngày nào không thấy tin = agent chết.
  • Cảnh báo bất thường: ví dụ nếu số đơn xử lý hôm nay = 0 trong khi mọi ngày ~50, gửi cảnh báo.
  • Theo dõi chi phí: ngó số task/token dùng để không vượt hạn mức bất ngờ.

Ví dụ cụ thể

Agent nhắc công nợ mỗi sáng. Bạn thêm:

  • Bước cuối: gửi Telegram "Nhắc nợ xong: 12 email đã gửi, 0 lỗi" lúc 9h05.
  • Nếu bước gửi email lỗi: retry x2, vẫn lỗi thì ghi Sheet "cần gọi điện" + báo bạn.
  • Mỗi thứ Hai bạn mở execution history, xem tuần qua có run nào đỏ không.
Nhờ vậy, ngày nào 9h05 không có tin Telegram, bạn biết ngay có chuyện, thay vì đợi khách phàn nàn.

Checklist "sẵn sàng lên production"

[ ] Đã test đủ 6 loại ca ở Tầng 1?
[ ] Các bước quan trọng có retry?
[ ] Có đường dẫn lỗi + báo cho người?
[ ] Có heartbeat / log mỗi lần chạy?
[ ] Có cách biết khi agent chết?
[ ] Đã đặt hạn mức / cảnh báo chi phí?

Sai lầm thường gặp

  • Chỉ test đường hạnh phúc: rồi ngã ngửa khi gặp dữ liệu thật lộn xộn.
  • Không có báo lỗi: agent chết âm thầm nhiều ngày, phát hiện thì đã trễ.
  • Retry vô hạn: với lỗi do dữ liệu sai (không phải mạng), retry mãi chỉ tốn tài nguyên; phân biệt lỗi tạm thời và lỗi logic.
  • Không lần vết được: thiếu log/timestamp nên khi có sự cố không biết chuyện gì đã xảy ra.
  • Bật rồi quên: không ai review, agent trôi dạt cho tới khi hỏng nặng.
Bài cuối: đưa agent vào vận hành thật, phối hợp con người, mở rộng và tránh cạm bẫy chi phí/bảo mật.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi