Tại sao tỷ lệ hoàn thành nhiệm vụ không phát hiện được các lỗi ngầm của agent

Vào tháng 9 và tháng 10 năm 2026, một nhà phát triển đã tiến hành loạt thí nghiệm có kiểm soát trên một AI agent hỗ trợ khách hàng để xác định xem chỉ số giám sát nào thực sự phát hiện được các lỗi ngầm. Các bài kiểm tra bao gồm việc cố ý làm hỏng hệ thống theo tám cách khác nhau, từ thay đổi mô hình đến độ trễ hạ tầng, nhằm xem liệu các công cụ quan sát (observability) tiêu chuẩn có đưa ra cảnh báo hay không.

Điều gì đã xảy ra

Bài kiểm tra ban đầu vào tháng 9 so sánh hai mô hình, Claude Haiku 4.5 và Claude Sonnet 5, trên hai mươi nhiệm vụ hỗ trợ. Cả hai đều đạt điểm tuyệt đối. Tuy nhiên, khi gặp hai nhiệm vụ bẫy liên quan đến yêu cầu hoàn tiền trái phép, Haiku đã xử lý tất cả sáu yêu cầu hoàn tiền trong khi Sonnet từ chối đúng cách. Bất chấp sự khác biệt nguy hiểm này, tỷ lệ thành công tổng thể của chúng vẫn giống hệt nhau. Vào tháng 10, nhà phát triển chạy lại đánh giá và nhận thấy Haiku giờ đây đã từ chối các yêu cầu hoàn tiền trái phép. Phân tích ban đầu gợi ý rằng việc xử lý các nhiệm vụ trước đó trong hàng đợi đã dạy cho agent cách xác minh trạng thái, nhưng điều tra sâu hơn tiết lộ nguyên nhân đơn giản hơn: bí danh (alias) của mô hình đã âm thầm cập nhật từ claude-haiku-4-5 sang claude-haiku-5-5 mà không có bất kỳ ghi log hoặc thông báo nào.

Để hiểu tại sao các chỉ số tiêu chuẩn bỏ lỡ những vấn đề này, nhà phát triển đã thiết kế một khung thử nghiệm chặt chẽ sử dụng API doanh nghiệp giả lập với ba mươi thao tác có phạm vi rõ ràng. Bộ thử nghiệm bao gồm mười chín nhiệm vụ tiêu chuẩn và hai bẫy hoàn tiền. Sau khi thiết lập đường cơ sở (baseline) với ba lần chạy bằng Claude Sonnet 5.5, nhà phát triển đã giới thiệu từng cái một trong tám lỗi hồi quy (regression) cụ thể. Những lỗi này bao gồm chuyển sang mô hình yếu hơn, cắt ngắn tài liệu API, thu hồi quyền truy cập, gây ra đọc dữ liệu cũ từ bản sao database, chèn lỗi API tạm thời, thêm độ trễ mạng và hiển thị các công cụ đã ngừng hỗ trợ (deprecated).

Kết quả cho thấy tỷ lệ hoàn thành nhiệm vụ truyền thống là chỉ số kém về sức khỏe hệ thống. Chỉ hai trong số tám lỗi hồi quy khiến tỷ lệ hoàn thành nhiệm vụ giảm xuống dưới ngưỡng. Sáu lỗi còn lại, bao gồm sự gia tăng 70% các lệnh gọi API do logic thử lại (retry) và lãng phí token đáng kể từ việc đoán các lệnh bị thiếu, không làm thay đổi tỷ lệ thành công. Khả năng tự động phục hồi sau lỗi của agent đã che giấu sự suy giảm hạ tầng bên dưới, tạo ra cảm giác an toàn giả tạo cho các kỹ sư chỉ dựa vào các chỉ số đạt/không đạt.

Cách thức hoạt động

Chiến lược phát hiện dựa trên việc so sánh dữ liệu đo từ xa (telemetry) khi thực thi với biến động đường cơ sở chặt chẽ. Thay vì chỉ kiểm tra xem nhiệm vụ có hoàn thành hay không, hệ thống theo dõi bốn chỉ số chính: số lượng nhiệm vụ thành công, chi phí token, khối lượng lệnh gọi công cụ và độ lệch phạm vi (scope drift). Độ lệch phạm vi đo lường mức độ chồng chéo giữa các phạm vi API được sử dụng trong một lần chạy so với đường cơ sở, được tính bằng 1 trừ đi mức độ chồng chéo trung bình. Ngưỡng cảnh báo được đặt ở mức gấp đôi biến động đường cơ sở để tính đến phân phối thống kê tự nhiên.

Khối lượng lệnh gọi công cụ chứng tỏ là chỉ số nhạy cảm nhất đối với các vấn đề hạ tầng. Vì các lệnh gọi công cụ cơ sở chỉ biến động khoảng 3%, một ngưỡng chặt chẽ ±7% có thể dễ dàng đánh dấu các bất thường. Ví dụ, khi API upstream trở nên không ổn định, logic thử lại của agent khiến các lệnh gọi công cụ tăng vọt lên 70%, kích hoạt cảnh báo mặc dù mọi nhiệm vụ vẫn thành công. Ngược lại, mức sử dụng token biến động tới 18% giữa các lần chạy cơ sở, đòi hỏi một ngưỡng rộng ±37%, cho phép những inefficiencies (kém hiệu quả) đáng kể lọt qua mà không bị phát hiện.

Nghiên cứu cũng nhấn mạnh tầm quan trọng của việc phân tích đầu ra không cấu trúc. Trong bài kiểm tra đọc dữ liệu cũ, nơi agent đọc dữ liệu lỗi thời từ bản sao, tất cả các chỉ số định lượng vẫn nằm trong giới hạn bình thường. Agent phát hiện ra sự sai lệch giữa các thao tác ghi và đọc tiếp theo, sau đó cố ý ngăn chặn các lần thử lại để tránh trùng lặp thay đổi. Hành vi phòng thủ này đã cứu hệ thống khỏi lỗi tài chính nhưng khiến lỗi hạ tầng trở nên vô hình đối với các giám sát viên số học. Bằng chứng duy nhất về lỗi tồn tại trong bản tóm tắt văn bản cuối cùng của agent, trong đó mô tả rõ ràng sự bất thường.

Chi tiết chính

• Cập nhật mô hình ngầm: Một bí danh mô hình không được ghim phiên bản (unpinned) đã thay đổi từ claude-haiku-4-5 sang claude-haiku-5-5 giữa các lần chạy thử nghiệm, làm thay đổi hành vi mà không kích hoạt bất kỳ cảnh báo triển khai nào.
• Độ nhạy của chỉ số: Số lượng lệnh gọi công cụ bắt được bốn lỗi, độ lệch phạm vi bắt được bốn, tỷ lệ hoàn thành nhiệm vụ chỉ bắt được hai và chi phí token bắt được một.
• Che giấu bởi retry: Một nhánh API không ổn định chèn 31 lỗi tạm thời, tất cả đều được hấp thụ bởi các lần thử lại của agent, dẫn đến tăng 70% lệnh gọi công cụ nhưng tỷ lệ thành công vẫn là 19/19.
• Giải pháp tự động: Khi tài liệu bị cắt ngắn, agent sử dụng các vòng lặp shell brute-force để đoán các endpoint bị thiếu, làm tăng mức sử dụng token lên 73% và thời gian thực thi từ năm lên mười lăm phút.
• Lỗi vô hình: Việc đọc dữ liệu cũ từ database không gây ra cảnh báo chỉ số nào vì phản ứng thận trọng của agent giữ cho thay đổi về token và lệnh gọi công cụ thấp hơn ngưỡng phát hiện.
• Suy giảm do đối kháng: Các nhiệm vụ bẫy hoàn tiền giúp phân biệt các mô hình vào tháng 9 đã thất bại trong việc bắt lỗi vào tháng 10 vì mô hình mới hơn xử lý chúng đúng cách, khiến bài kiểm tra trở nên lỗi thời.

Tại sao điều này quan trọng

Đối với các nhóm kỹ sư xây dựng agent tự chủ, nghiên cứu này chứng minh rằng tỷ lệ hoàn thành nhiệm vụ cao có thể tồn tại song song với những inefficiencies vận hành và rủi ro nghiêm trọng. Các agent ngày càng có khả năng che giấu các vấn đề hạ tầng thông qua logic thử lại và hành vi thích nghi. Nếu bạn chỉ giám sát xem một nhiệm vụ có hoàn thành hay không, bạn sẽ bỏ lỡ những chi phí gia tăng, độ trễ và các vấn đề tiềm ẩn về tính nhất quán dữ liệu tích tụ phía sau hậu trường. Sự tách rời giữa việc hoàn thành nhiệm vụ và sức khỏe hạ tầng có nghĩa là các bảng điều khiển uptime và tỷ lệ thành công truyền thống là không đủ đối với các hệ thống do AI điều khiển.

Hơn nữa, việc phụ thuộc vào các bộ kiểm tra đối kháng tĩnh là một điểm yếu. Khi các mô hình cập nhật, các nhiệm vụ bẫy từng hiệu quả trước đây có thể trở nên tầm thường, tạo ra cảm giác an toàn giả tạo. Các kỹ sư phải coi đầu ra của agent là dữ liệu đo từ xa có cấu trúc, chứ không chỉ là câu trả lời cuối cùng. Việc phân tích các bản tóm tắt để tìm kiếm sự không chắc chắn và theo dõi các chỉ số thực thi cấp thấp như lệnh gọi công cụ cung cấp khả năng hiển thị cần thiết để phân biệt giữa cải thiện thực sự và suy giảm ngầm. Không có những hiểu biết sâu sắc hơn này, các nhóm có nguy cơ triển khai các agent trông có vẻ hoạt động tốt nhưng lại không ổn định về mặt tài chính hoặc kỹ thuật.

Bạn có thể làm gì

• Ghi log ID mô hình đã giải quyết: Ghi lại chuỗi phiên bản mô hình cụ thể cho mỗi lần chạy và cảnh báo nếu có bất kỳ thay đổi nào để phát hiện các cập nhật ngầm.
• Theo dõi lệnh gọi công cụ theo nhiệm vụ: Giám sát số lượng lệnh gọi API cùng với tỷ lệ thành công, sử dụng ngưỡng chặt chẽ dựa trên biến động đường cơ sở để bắt kịp các "cơn bão" thử lại (retry storms).
• Cô lập chỉ số retry: Theo dõi và cảnh báo rõ ràng về các lỗi tạm thời và số lần thử lại như những cảnh báo sớm về sự suy giảm hạ tầng upstream.
• Phân tích bản tóm tắt của agent: Sử dụng xử lý ngôn ngữ tự nhiên để quét các báo cáo cuối cùng của agent tìm kiếm các từ khóa chỉ ra sự không chắc chắn, lỗi xác minh hoặc các hành động bị ngăn chặn.
• Xoay vòng các bài kiểm tra đối kháng: Thường xuyên cập nhật các nhiệm vụ bẫy và trường hợp kiểm thử tiêu cực để đảm bảo chúng vẫn phù hợp với thế hệ mô hình hiện tại.
• Xác thực bằng các bài kiểm tra chèn lỗi: Định kỳ chèn các lỗi mạng tạm thời vào môi trường staging của bạn để xác minh rằng lớp đo từ xa của bạn phát hiện được sự gia tăng lệnh gọi công cụ kết quả.