AI agent trong thực tế: định nghĩa và thông điệp cảnh báo
AI agent trong thực tế là các hệ thống tự động dùng mô hình ngôn ngữ kết hợp với scheduler, shell, công cụ và credentials để thực hiện chuỗi tác vụ trên hạ tầng sản xuất, nơi độ tin cậy phụ thuộc nhiều hơn vào cách chúng được tích hợp và kiểm thử so với bản thân mô hình AI. Các nhà cung cấp thích kể câu chuyện “agent thông minh, biết dùng tool, có planner, có memory”, nhưng lớp ngôn ngữ hào nhoáng này chỉ che đi sự thật: phần lớn lỗi AI agent failures trong môi trường production xuất phát từ những thành phần cũ kỹ mà chúng ta tưởng đã hiểu rõ – lịch chạy, đường dẫn, biến môi trường, đồng hồ hệ thống và trạng thái xác thực. Khi doanh nghiệp tin vào slide bán hàng thay vì nhật ký lỗi, họ đang đặt cược hệ thống của mình vào một thứ độ tin cậy AI mới chỉ được hứa hẹn, chứ chưa được chứng minh.
Những lỗi AI agent thực tế: không nằm trong mô hình mà trong scheduler và credentials
Điều đáng khó chịu nhất về lỗi AI agent thực tế là: mô hình thường không phải vấn đề chính. Agent systems dù được bọc bằng những từ nghe rất hiện đại như planners, tool use, memory, reflection, nhưng chúng vẫn phụ thuộc vào schedulers, shells, paths, credentials, clocks và exit codes. Lớp mới đó không hề xóa bỏ lớp cũ, nó chỉ cho các lớp cũ thêm nhiều cách để âm thầm thất bại. Khi một job đến muộn, bị bỏ qua bởi policy, hoặc không thể quan sát được đầu vào, bản thân mô hình có thể vẫn trả lời “đúng”, nhưng toàn bộ pipeline vẫn hỏng. Tác giả của một đội agent đã chuyển sang mô hình hóa mỗi lần chạy không chỉ là "thành công" hay "thất bại", mà còn thêm trạng thái đến muộn, bị skip và không rõ vì thiếu dữ liệu. Điều này làm dashboard nhiều "vàng" hơn, nhưng là màu vàng trung thực: "I would rather investigate an honest yellow than trust a fabricated green". Độ tin cậy AI vì thế không phải câu chuyện chỉnh vài tham số mô hình, mà là thiết kế lại cách chúng ta đo và nhìn nhận hạ tầng xung quanh agent.
Khi AI agent đi chệch đường ray: từ lỗi MCP search đến tài liệu hóa có kiểm thử
Một ví dụ sống động về AI agent failures đến từ một đồng duy trì (co-maintainer) của XMLUI, người "acutely sensitive to agents fumbling as they build XMLUI apps". Ở đây, lỗi không nằm ở khả năng suy luận chung, mà ở việc MCP search không tìm được câu trả lời cho một tác vụ tưởng như hiển nhiên. Khi "something that should be a no-brainer isn’t, because the MCP search didn’t find the answer it should have", ông không đổ lỗi mơ hồ cho "AI ngu", mà lập tức file một issue và yêu cầu một agent viết tài liệu còn thiếu. Tài liệu mới đó được coi là "testable fix". Sau khi bổ sung, ông yêu cầu Claude truy vấn lại các tìm kiếm thất bại liên quan đến chuyển đổi select-to-radio trong log MCP. Trước đó, các tìm kiếm chỉ trả về kết quả yếu với điểm liên quan khoảng 0,7. Sau tài liệu mới, "the new document surfaced at #1 with a 4.2 score, six times higher than anything else" – một câu nói đáng trích dẫn cho thấy tác động đo được của việc tài liệu hóa. MCP server có thể pin phiên bản tài liệu mà nó dùng, cho phép so sánh A/B trực tiếp, và những truy vấn tổng hợp như "radio buttons for a small set of options" tiếp tục xác nhận cải thiện. Đây là minh chứng rõ ràng: kiểm thử AI agent không phải lý thuyết mà là thao tác cụ thể trên log, truy vấn và tài liệu.
Độ tin cậy AI: từ "xanh giả" sang quan sát trung thực
Các nhà cung cấp thường bán cho bạn bảng điều khiển toàn màu xanh: mọi agent job đều "hoạt động bình thường", mọi tác vụ đều "trên mức độ tin cậy AI được bảo đảm". Nhưng khi một kỹ sư bắt đầu phân loại lại trạng thái chạy, chỉ báo trên dashboard lập tức đổi màu. Mỗi lần chạy được gắn deadline về độ "tươi" của dữ liệu, mỗi nguồn dữ liệu quan trọng có kết quả khả dụng riêng tách khỏi số lượng item, và heartbeat chỉ được chấp nhận sau khi job tạo ra đúng artifact mà lịch chạy tồn tại để tạo. Việc này "creates more yellow on the dashboard. Good. I would rather investigate an honest yellow than trust a fabricated green". Đáng chú ý là tác giả khẳng định: "The fleet is not less reliable than it was before I started tracking this. It is exactly as reliable as it always was, and I can finally see it". Độ tin cậy AI vì thế không phải tăng hay giảm, mà là được nhìn thấy rõ ràng hơn nhờ cách đo tốt hơn. Nếu doanh nghiệp chỉ hỏi nhà cung cấp "tỷ lệ thành công bao nhiêu", họ sẽ nhận những con số xanh giả. Nếu họ hỏi "những trạng thái lỗi nào đang bị giấu", họ mới bắt đầu quản lý được rủi ro AI agent thực tế.
Chiến lược kiểm thử AI agent: tài liệu hóa, bug, và vòng lặp cải tiến
Bài học rõ ràng từ cả hạ tầng scheduler lẫn câu chuyện XMLUI: độ tin cậy AI không tự xuất hiện, nó được xây dựng qua kiểm thử AI agent và tài liệu hóa lỗi một cách có hệ thống. Khi một tác vụ "no-brainer" bị agent làm hỏng vì MCP search không tìm thấy câu trả lời, phản ứng đúng không phải là cố gắng prompt-engineering cho đến khi may mắn trúng, mà là file bug, bổ sung tài liệu, rồi kiểm thử lại kết quả. Tài liệu mới đóng vai trò "testable fix", nghĩa là nó trở thành phần tử có thể đo đạc trong hệ thống. Sau đó, ta lặp lại truy vấn, so sánh điểm liên quan trước–sau, và thử thêm vài truy vấn tổng hợp để xác nhận. Trên hạ tầng scheduler, tư duy tương tự là mở rộng mô hình trạng thái job thay vì ép tất cả về "thành công" hoặc "thất bại". Độ tin cậy AI vì thế là sản phẩm của việc đối mặt với lỗi, đặt tên chính xác cho chúng, và biến mỗi lần sửa thành một bài kiểm thử có thể chạy lại – chứ không phải lời cam kết mơ hồ trên brochure của nhà cung cấp.
