Một agent không được đo lường sẽ âm thầm tệ đi hoặc âm thầm đốt tiền. Bài cuối này xây vòng lặp vận hành: đo chất lượng, kiểm soát chi phí, và cải tiến prompt/policy dựa trên dữ liệu — để agent ngày càng đáng tin thay vì bị đội bỏ xó.
1. Các chỉ số cần theo dõi
| Chỉ số | Ý nghĩa | Cách đo |
|---|---|---|
| Tỷ lệ nhận xét được xử lý | Nhận xét hữu ích không | % comment được resolve/apply |
| Tỷ lệ false positive | Độ nhiễu | % comment bị dev đánh dấu sai |
| Suggestion apply rate | Gợi ý có dùng được không | % `suggestion được Apply |
| Token/PR | Chi phí | Ghi log usage mỗi lần chạy |
| Thời gian phản hồi | Trải nghiệm | Từ lúc mở PR đến khi có review |
2. Kiểm soát chi phí
Token là tiền. Các đòn bẩy chính:
cost_controls:
max_diff_lines: 1500 # PR lớn hơn → chỉ tóm tắt, không review sâu
skip_paths: ["**/*.lock", "dist/**"]
only_changed_since_last_run: true # push nhỏ chỉ review phần mới
model_tier: cheap_for_low_risk # dùng model rẻ cho PR nhỏ/ít rủi ro
Mẹo hiệu quả: định tuyến theo rủi ro — PR đụng file thanh toán/auth dùng model mạnh; PR đổi doc/test dùng model rẻ hoặc bỏ qua.
3. Vòng cải tiến dựa trên dữ liệu
# Mỗi lần chạy, log lại để phân tích sau
log_metrics({
"pr": pr_number,
"comments": len(comments),
"high": n_high,
"tokens": usage.total_tokens,
"model": model,
})
Hàng tuần: lấy các nhận xét bị dev bác, phân loại nguyên nhân (thiếu ngữ cảnh? bịa? sai convention?), rồi vá prompt hoặc thêm luật lọc. Đây chính là cách agent "học" trong thực tế đội nhóm.
Các bước vận hành
- Log usage + kết quả mỗi lần chạy vào một nơi truy vấn được.
- Đặt mục tiêu số cho false positive và apply rate.
- Bật cost controls: giới hạn diff, bỏ path rác, định tuyến theo rủi ro.
- Hàng tuần review 15–20 nhận xét bị bác, tìm mẫu, cập nhật prompt/config.
- Chạy canary: đổi prompt trên một nhóm repo nhỏ trước khi áp toàn bộ.
- Lưu version của prompt/config để rollback khi bản mới tệ hơn.
Khung tư duy: vòng lặp OODA cho agent
- Observe — thu số liệu (nhiễu, chi phí, apply rate).
- Orient — phân loại nguyên nhân lỗi.
- Decide — sửa prompt, chỉnh policy, hay đổi model.
- Act — deploy canary, đo lại, giữ hoặc rollback.
Checklist vận hành bền vững
- [ ] Có dashboard/log cho token và false positive.
- [ ] Prompt và config được version hoá, rollback được.
- [ ] Có canary trước khi đổi lớn.
- [ ] Định tuyến model theo rủi ro để tối ưu chi phí.
- [ ] Lịch review định kỳ các nhận xét bị bác.
Sai lầm thường gặp
- "Cài xong rồi quên". Không đo thì agent tệ dần mà không ai biết; chất lượng model, code base và convention đều trôi theo thời gian.
- Không giới hạn chi phí. Một PR generated-code 20.000 dòng có thể ngốn chi phí lớn nếu không có
max_diff_lines. - Đổi prompt trực tiếp trên toàn hệ thống. Không canary, không version → một thay đổi tệ ảnh hưởng mọi repo. Luôn thử nhỏ trước.
- Chỉ đo số lượng, không đo chất lượng. "Agent để lại 500 comment" không nói lên gì; hãy đo tỷ lệ được chấp nhận.
- Dùng model đắt nhất cho mọi PR. Định tuyến theo rủi ro giúp tiết kiệm mà không giảm an toàn ở nơi quan trọng.
Kết khóa
Bạn đã đi trọn hành trình: hiểu vì sao cần agent, thiết lập môi trường, thiết kế prompt cấu trúc, đăng nhận xét đúng dòng, tích hợp CI, hạn chế false positive, xây policy vận hành, và cuối cùng là đo lường – cải tiến liên tục. Một agent review PR tốt không phải sản phẩm "làm một lần", mà là một hệ thống sống: bắt đầu hẹp và chính xác, xây niềm tin bằng dữ liệu, rồi mở rộng quyền và phạm vi một cách có kỷ luật. Hãy làm bài thi tổng kết để củng cố khả năng vận dụng.