Bài 1 — Triage bug là gì và vì sao cần một AI agent

Triage (phân loại) là bước đầu tiên khi một bug report đến: quyết định nó có phải bug thật không, nghiêm trọng đến đâu, ai xử lý, xử lý khi nào. Trong đội ngũ đông báo cáo, triage thủ công ngốn hàng giờ mỗi ngày và thường thiếu nhất quán. Đây chính là chỗ một AI agent tỏa sáng: nó đọc report, gom thông tin còn thiếu, gán mức độ nghiêm trọng và định tuyến — 24/7, theo một khung chuẩn.

Agent triage khác chatbot ở đâu

Chatbot chỉ trả lời. Agent có vòng lặp quan sát → suy nghĩ → hành động → quan sát lại: nó gọi công cụ (đọc log, chạy lại test, tra issue trùng), rồi dựa kết quả để quyết định bước tiếp theo. Một agent triage điển hình phải làm được 4 việc:

• Chuẩn hóa report lộn xộn thành cấu trúc (title, steps, expected, actual).
• Đánh giá severity và priority theo tiêu chí rõ ràng.
• Định tuyến đến đúng team/nhãn (label).
• Đề xuất bước tiếp theo (yêu cầu thêm thông tin, tái hiện, hay gán fix).

Ví dụ cụ thể

Một report thật: "App bị crash khi tôi bấm nút". Con người sẽ hỏi lại: nút nào? màn hình nào? phiên bản app? Agent làm y hệt nhưng tự động — nó phát hiện thiếu thông tin và sinh câu hỏi làm rõ trước khi phân loại.

Input:  "App crash khi bấm nút"
Agent:  [thiếu: repro steps, version, platform]
Output: status=needs_info
        questions=["Bạn dùng phiên bản nào?",
                   "Màn hình nào? Nút nhãn gì?",
                   "Có log/ảnh chụp không?"]

Các bước xây khung triage tối thiểu

• Định nghĩa output schema trước khi viết prompt: severity, priority, component, status, next_action.
• Viết rubric severity rõ ràng (xem checklist dưới) để agent không đoán mò.
• Xác định "đủ thông tin": liệt kê trường bắt buộc để tái hiện (repro steps, expected, actual, env).
• Chọn hành động khi thiếu tin: chuyển needs_info thay vì đoán severity.
• Ghi lại lý do (rationale) cho mọi quyết định để con người kiểm tra.

Khung tư duy: thang Severity vs Priority

• Severity = mức độ hư hại kỹ thuật (crash, mất dữ liệu, sai kết quả, lỗi hình thức).
• Priority = mức độ khẩn về mặt kinh doanh (bao nhiêu người bị, có workaround không).

Hai trục này độc lập: một lỗi chính tả (severity thấp) trên nút thanh toán của toàn bộ khách hàng có thể là priority cao.

Checklist rubric severity

S1 Blocker : mất dữ liệu / sập hệ thống / chặn luồng chính, không workaround
S2 Major   : tính năng chính hỏng, có workaround khó
S3 Minor   : lỗi cục bộ, workaround dễ
S4 Trivial : hình thức, chính tả, gợi ý cải tiến

Sai lầm thường gặp

• Gộp severity và priority làm một → định tuyến sai, đội on-call bị dựng dậy vì lỗi chính tả.
• Cho agent tự đoán khi thiếu thông tin thay vì chuyển needs_info → dữ liệu triage nhiễu.
• Không lưu rationale → không ai tin agent, không sửa được khi nó sai.
• Bắt đầu bằng prompt trước khi định nghĩa schema → output không parse được, không tự động hóa tiếp được.

Kết bài: bạn đã có bức tranh tổng thể và một rubric severity. Bài 2 sẽ dựng môi trường và bộ khung agent để bắt đầu code.