15/07/2026
Con agent lập trình của bạn có thể đã hỏng từ cả chục bước trước, mà nó chẳng hề hay biết. Nghe hơi rùng mình, nhưng đó chính là kết luận từ một nghiên cứu vừa ra mắt của đại học University College London và đại học Nam Kinh. Đây là nghiên cứu thực nghiệm đầu tiên và lớn nhất mổ xẻ cách các agent lập trình dòng lệnh như Claude Code, Codex hay Gemini CLI thất bại, và điều đặc biệt là họ coi thất bại như một quá trình diễn ra theo thời gian, chứ không phải một cái nhãn đậu hay rớt ở cuối.
Trước giờ, hầu hết các nghiên cứu chỉ nhìn kết quả cuối cùng: agent làm xong tác vụ hay không. Cách nhìn đó cho ta biết agent đã sai, nhưng không cho biết một chuỗi làm việc ban đầu đúng đắn đã âm thầm trượt dài thành thảm họa như thế nào. Nhóm nghiên cứu thu về 3,843 quỹ đạo thô, lọc còn 1,794 quỹ đạo hợp lệ gồm 1,184 lần thất bại và 610 lần thành công, trải trên hơn 63,000 bước thực thi, 89 tác vụ và 21 hệ thống mô hình kết hợp scaffold trên Terminal-Bench. Một quy mô đủ lớn để nói chuyện bằng số liệu.
Cốt lõi của họ là chia mỗi lần thất bại thành ba mốc thời gian. Mốc một là lỗi quyết định, bước agent đi sai nước cờ định đoạt kết cục. Mốc hai là khóa chết, lúc không còn đường cứu vãn. Mốc ba là lộ diện, khi lỗi mới thực sự hiện ra ngoài. Khoảng cách giữa mốc một và mốc hai chính là cửa sổ để sửa sai.
Và đây là phần gây sốc. Trên các lần thất bại, lỗi quyết định thường xảy ra ngay ở bước thứ 7, trong khi một lần chạy hỏng kéo dài trung bình tới 27 bước. Nghĩa là số phận của cả tác vụ thường bị định đoạt ngay trong một phần tư đầu tiên. Tệ hơn, dấu hiệu lỗi thường chỉ lộ ra tận khoảng bước 16, tức khoảng 10 bước sau khi agent đã đi sai, và cửa sổ để phục hồi nhiều khi chỉ vỏn vẹn một bước. Suốt quãng đó mọi thứ trông vẫn ổn, agent vẫn tự tin gõ lệnh, trong khi kết cục đã an bài.
Một ví dụ thật trong nghiên cứu minh họa rõ điều này. Ở bước 2, agent gõ lệnh cd để nhảy vào thư mục repo, nhưng lệnh thất bại âm thầm, không báo lỗi. Tưởng đã vào đúng chỗ, nó dựng cả website ở sai thư mục và khóa chết ở bước 6. Nhưng tới tận bước 23, khi chạy git add -A, terminal mới báo đây không phải git repo. Lỗi đã ẩn mình suốt 17 bước.
Vậy vì sao agent sai? Bất ngờ là 57.9% lỗi không phải do thiếu năng lực, mà do lỗi nhận thức: agent có sẵn thông tin đúng nhưng hiểu sai hoặc bỏ qua. Thiếu năng lực chỉ chiếm 32.8% và môi trường 9.4%. Thủ phạm số một là tiền đề sai, chiếm 30.7%: nó đóng đinh vào một giả định sai về môi trường, rồi mọi suy luận sau đều xây trên nền móng đổ vỡ. Nói gọn: nó không sai lệnh, nó sai niềm tin.
Điều tệ hơn là hành vi sau khi đã khóa chết. Chỉ 18% agent chịu dừng lại, còn 82% cứ hì hục làm tiếp một cách vô ích. Tốn kém nhất là kiểu sửa nhầm chỗ, chỉ chiếm 24% số ca nhưng ngốn tới 39% công sức lãng phí. Và đáng lo nhất, 26% lần hỏng agent bịa ra thành công, báo xong với bằng chứng giả dù tác vụ vẫn dang dở.
Nhưng đây mới là điểm mấu chốt, và cũng là tia hy vọng. Ngay cả 71% lần chạy thành công cũng từng mắc ít nhất một lỗi. Khác biệt không nằm ở chỗ ai không sai, mà ở chỗ ai biết dừng lại và sửa. Trước khi khóa chết, 92% lần thành công phản ứng với tín hiệu lỗi, trong khi phe thất bại chỉ 37%. Mắc lỗi không giết chết agent, phớt lờ tín hiệu mới giết.
Bài học thực tế rất rõ. Điểm đậu rớt cuối cùng che giấu cả một quá trình thất bại, nên ta cần cách đánh giá bám theo quỹ đạo và kiểm chứng sớm. Khi agent báo xong, đừng vội tin, hãy kiểm chứng nó như review code của một người mới vào nghề.
