Từ "chạy được" đến "chạy bền"
Agent chạy tốt sprint đầu không có nghĩa nó tốt mãi. Sản phẩm đổi, giọng đổi, team đổi, và AI đôi khi "trôi" chất lượng. Bài cuối này biến bạn từ người dựng agent thành người vận hành nó: đo hiệu quả, bắt lỗi sớm, và cải tiến liên tục — để 6 tháng sau nó vẫn đáng tin.
Đo lường: agent này có thật sự tiết kiệm không?
Đừng chỉ cảm tính. Theo dõi vài chỉ số đơn giản:
- Thời gian mỗi release: trước và sau khi có agent (mục tiêu: 3h → 20 phút).
- Tỷ lệ sửa của người duyệt: bao nhiêu % câu phải sửa? Cao = prompt cần chỉnh.
- Sự cố lọt lưới: số lần thông tin sai/khách phản hồi nhầm.
- Độ phủ kênh: có quên kênh nào không.
Ví dụ cụ thể: một tình huống sự cố
Sprint 18, agent viết "Đã hỗ trợ thanh toán bằng thẻ tín dụng" nhưng tính năng đó bị hoãn phút chót — ticket vẫn ở Done do dev merge code nhưng feature flag tắt. Agent không biết flag. Khách nhận email → tưởng có tính năng → CS ngập ticket.
Bài học vận hành: agent chỉ biết những gì bạn cho nó biết. Trạng thái "Done" ≠ "đã release cho khách". Cần thêm bước kiểm feature flag / trạng thái thực release vào quy trình duyệt.
Prompt mẫu: rà soát trước phát hành (pre-flight)
Đây là bản release notes agent vừa sinh và danh sách ticket nguồn.
Hãy đóng vai người soát độc lập và trả về CHECKLIST RỦI RO:
1. Câu nào chứa số liệu/tuyên bố cần kiểm chứng? Liệt kê + trích ticket tương ứng.
2. Câu nào mô tả tính năng có thể CHƯA bật cho khách (cần xác nhận feature flag)?
3. Có breaking change nào chưa được cảnh báo không?
4. Có thông tin nào giống dữ liệu nhạy cảm (tên KH, số liệu nội bộ) lọt vào không?
Chỉ liệt kê điểm cần người kiểm, KHÔNG tự sửa nội dung.
Prompt này dùng chính AI để soát AI — nhưng kết quả vẫn do người quyết.
Các bước vận hành (numbered)
- Ghi baseline: đo thời gian & công sức làm tay trước khi có agent.
- Thêm bước pre-flight (prompt trên) vào mọi lần trước khi phát hành.
- Kiểm trạng thái release thật (feature flag/canary), không chỉ tin "Done".
- Ghi nhật ký sự cố: mỗi lỗi lọt lưới → ghi nguyên nhân → cập nhật prompt/quy trình.
- Review prompt hằng quý: cập nhật style card, từ cấm, ví dụ few-shot.
- Thu phản hồi người duyệt: hỏi "bản này sửa nhiều không", dùng để tinh chỉnh.
- Diễn tập thủ công định kỳ: một sprint tự làm tay để team không mất kỹ năng nền.
- Cập nhật tài liệu vận hành để người khác tiếp quản được.
Template: Sổ vận hành agent (checklist tái dùng)
- [ ] Baseline thời gian/công sức đã ghi.
- [ ] Pre-flight checklist chạy trước mọi phát hành.
- [ ] Xác nhận trạng thái release thật (không chỉ "Done").
- [ ] Nhật ký sự cố + hành động khắc phục.
- [ ] Lịch review prompt hằng quý.
- [ ] Chỉ số: thời gian/lần, tỷ lệ sửa, số sự cố.
- [ ] Phương án dự phòng thủ công + người backup.
- [ ] Quyền truy cập tối thiểu, key trong secret manager (rà định kỳ).
Sai lầm thường gặp
- Tin "Done" là "đã release": như ví dụ trên — nguồn sai thì mọi bản đều sai. Luôn kiểm trạng thái thực.
- Không đo lường: không biết agent tiết kiệm thật hay chỉ tạo cảm giác bận rộn mới. Đo baseline.
- Chất lượng "trôi" mà không ai để ý (ảo giác tích lũy): AI dần thêm sáo ngữ, phóng đại. Review quý để bắt sớm.
- Rò rỉ tích lũy qua log: log lưu cả dữ liệu nhạy cảm nhiều tháng → rủi ro. Đặt chính sách xóa log và rà quyền truy cập log.
- Phụ thuộc quá mức đến mức mất kỹ năng: khi agent hỏng đúng ngày release, không ai làm tay kịp. Diễn tập thủ công định kỳ và luôn có người backup.
Điều rút ra
Dựng agent chỉ là 20% công việc; 80% còn lại là vận hành: đo lường, pre-flight, kiểm trạng thái release thật, ghi nhật ký sự cố và review định kỳ. Làm được vậy, agent của bạn không chỉ nhanh mà còn đáng tin lâu dài — và bạn vẫn là người nắm quyền kiểm soát cuối cùng.