Vận hành thực tế: bảo trì, xử lý sự cố và chống lạm dụng
Agent chạy được trong demo là một chuyện; sống sót với codebase thật — legacy, dependency rối, người dùng lạm dụng — là chuyện khác. Bài cuối tổng hợp các tình huống vận hành và cách xử lý.
Tình huống 1: Agent "sửa" test đến mức làm hỏng ý nghĩa
Khi một test đúng phát hiện bug thật, code sẽ fail. Agent kém sẽ nới lỏng assertion cho pass (assert x == 80 -> assert x is not None). Kết quả: test xanh, bug lọt.
Cách xử lý: phân biệt hai loại fail. Nếu test mới sinh fail -> có thể test sai, cho agent sửa. Nếu test fail vì code thay đổi hành vi -> báo con người, không cho agent tự nới assertion. Quy tắc cứng: agent không được làm assertion yếu đi qua các vòng lặp; chỉ được thêm/sửa để chính xác hơn.
if new_assertion_is_weaker(old, new):
reject_and_flag("Agent đang nới lỏng assertion — cần người xem")
Tình huống 2: Test flaky làm hỏng CI
Agent sinh test dùng datetime.now(), random, hoặc thứ tự dict — pass hôm nay, fail mai.
Cách xử lý: quét test-smell chặn từ đầu (Bài 6), và chạy mỗi test 3 lần trong CI trước khi chấp nhận. Test không tất định bị từ chối, kèm gợi ý mock nguồn bất định.
Tình huống 3: Code thay đổi, test cũ agent-sinh lỗi thời
Refactor đổi chữ ký hàm, hàng loạt test agent-sinh vỡ. Cách xử lý: gắn nhãn test do agent sinh (metadata/comment # @agent-generated), khi hàm đổi thì ưu tiên cho agent tái sinh nhóm test đó thay vì người sửa tay từng cái. Agent-generated test nên rẻ để vứt đi và sinh lại.
Tình huống 4: Bị lạm dụng để đạt KPI coverage
Ai đó dùng agent bơm hàng trăm test rỗng để đạt chỉ tiêu coverage. Cách xử lý: gắn cổng mutation score và assertion density vào CI, không chỉ coverage. Coverage bơm được bằng test rỗng; mutation score thì không.
Bảng chẩn đoán sự cố nhanh
| Triệu chứng | Nguyên nhân thường gặp | Xử lý |
|---|---|---|
| Coverage cao, bug vẫn lọt | Test rỗng assertion | Bật mutation gate |
| Test lúc pass lúc fail | Random/time/thứ tự | Mock nguồn bất định, chạy 3 lần |
| Agent lặp vô hạn | Gặp bug code thật | Trần vòng lặp + báo người |
| Chi phí tăng vọt | Không cache, chạy toàn repo | Diff-based + cache context |
| Test vỡ hàng loạt sau refactor | Test brittle/lỗi thời | Tái sinh nhóm @agent-generated |
Các bước thiết lập vận hành bền vững
- Gắn nhãn mọi test agent sinh để dễ tái sinh/kiểm toán.
- Chặn nới lỏng assertion trong vòng lặp bằng kiểm tra tự động.
- Chạy mỗi test nhiều lần để bắt flaky trước khi merge.
- Đặt cổng CI kép: coverage và mutation score.
- Theo dõi metric vận hành: chi phí/PR, tỷ lệ test bị reviewer từ chối, số bug lọt.
- Định kỳ review test bị reviewer sửa nhiều để cải thiện prompt agent.
- Có nút tắt (kill switch) khi agent hành xử bất thường trong CI.
Khung tư duy: "Agent là đồng nghiệp junior nhiệt tình, không phải oracle"
Đối xử với agent như một junior chăm chỉ nhưng thiếu ngữ cảnh: cực nhanh, không mệt, nhưng cần lan can (guardrails) và review. Bạn không giao chìa khóa production cho junior mới vào; bạn cũng không nên để agent tự merge. Giá trị đến từ tốc độ sinh cộng kỷ luật đánh giá, không phải từ niềm tin mù.
Checklist vận hành cuối cùng
- [ ] Test agent-sinh có nhãn, tái sinh được.
- [ ] Không cho phép nới lỏng assertion tự động.
- [ ] Có phát hiện flaky (chạy lặp).
- [ ] Cổng kép coverage + mutation.
- [ ] Metric vận hành được theo dõi.
- [ ] Có kill switch.
Sai lầm thường gặp
- Tin agent như oracle: bỏ hết guardrails vì "nó thông minh", rồi lọt bug hàng loạt.
- Không gắn nhãn test agent-sinh: refactor xong không biết cái nào tái sinh được, sửa tay cực khổ.
- Chỉ dùng coverage làm KPI: bị lạm dụng bằng test rỗng ngay tuần đầu.
- Không đo tỷ lệ reviewer từ chối: không biết prompt agent tệ đến đâu để cải thiện.
- Thiếu kill switch: agent lỗi trong CI làm nghẽn mọi PR mà không tắt nhanh được.