DevOps & giám sát

Tại sao các bài kiểm thử đơn vị không bảo vệ được AI agents trong các sự cố production

Một tiêu chuẩn kiểm thử mới cho thấy các máy chủ Model Context Protocol thường vượt qua các bài kiểm tra tiêu chuẩn nhưng lại thất bại khi được điều khiển bởi các AI agent phi xác định trong các sự cố thực tế.

Các kệ server dưới một mái vòm kính với đèn cảnh báo và một cánh tay robot đang kiểm tra chúng
Ảnh minh họa tạo riêng cho bài viết

Bài được dịch tự động từ bản gốc tiếng Anh.

Model Context Protocol (MCP) đã nhanh chóng phát triển từ một thử nghiệm trên GitHub thành cơ sở hạ tầng quan trọng để kết nối các Mô hình Ngôn ngữ Lớn (Large Language Models) với các công cụ giám sát. Tuy nhiên, một phân tích gần đây đã chỉ ra một khoảng trống nguy hiểm: các máy chủ có thể vượt qua mọi bài kiểm thử đơn vị nhưng vẫn thất bại thảm hại khi một AI agent cố gắng sử dụng chúng trong một sự cố lúc 3 giờ sáng. Sự khác biệt này xuất hiện vì các bài kiểm tra tiêu chuẩn giả định người gọi là lịch sự và xác định (deterministic), trong khi các AI agent hoạt động dựa trên xác suất và thường đưa ra những lựa chọn lộn xộn, phi tuyến tính.

Chuyện gì đã xảy ra

Anthropic đã giới thiệu đặc tả MCP đầu tiên vào tháng 11 năm 2024, cho phép các LLM kết nối trực tiếp với cơ sở dữ liệu và công cụ thông qua các tiêu chuẩn như OAuth 2.1 và Streamable HTTP. Các nhóm nền tảng hiện đang tích hợp những máy chủ này vào Prometheus, Grafana và Loki để tạo ra các agent tự động phân loại sự cố on-call. Mục tiêu là để một AI điều tra các cảnh báo PagerDuty và chẩn đoán vấn đề trước khi kỹ sư con người thức dậy. Tuy nhiên, khi mức độ áp dụng tăng lên, rủi ro về các lỗi im lặng cũng tăng theo, nơi agent hiểu sai dữ liệu hoặc làm hỏng vòng lặp phân loại sự cố.

QuietDesk Studio đã công bố một bộ tiêu chí phân biệt giữa hai cấp độ kiểm thử. Cấp độ 1 bao gồm tính đúng đắn của giao thức và handler, đảm bảo mã máy chủ hoạt động theo đặc tả. Cấp độ 2 bao gồm hành vi dưới sự điều khiển của agent, kiểm tra những gì xảy ra khi một mô hình phi xác định thực sự vận hành các công cụ. Phân tích cho thấy nếu điểm số dưới 5/6 ở bất kỳ cấp độ nào, nghĩa là công cụ chưa sẵn sàng cho production. Một máy chủ có thể về mặt kỹ thuật là chính xác nhưng lại gây nguy hiểm về mặt vận hành nếu nó không thể xử lý hành vi thất thường của một AI đang cố đoán mò cách khắc phục sự cố mất điện.

Chi tiết chính

  • Các bài kiểm thử Cấp độ 1 xác minh schema JSON, xử lý lỗi có cấu trúc, phạm vi phủ sóng của các bài kiểm thử âm (negative tests), phân biệt timeout, xác thực auth cho mỗi lần gọi và độ trễ dưới tải.
  • Các bài kiểm thử Cấp độ 2 đánh giá sự tương đồng về transport so với production, chấm điểm riêng biệt cho việc lựa chọn công cụ và tham số, nhiều lần thử cho mỗi tác vụ và khả năng xử lý prompt đối kháng.
  • Timeout phải trả về mã lỗi rõ ràng thay vì kết quả trống để ngăn chặn agent báo cáo sai tình trạng hệ thống khỏe mạnh trong thời gian xảy ra sự cố.
  • Xác thực phải được kiểm chứng trong mỗi lần gọi, không chỉ khi khởi động, để tránh các lỗi im lặng khi thông tin đăng nhập hết hạn giữa chừng sự cố.
  • Cần phải so sánh trạng thái sau khi chạy (post-run state diffs) để đảm bảo các công cụ chỉ đọc không vô tình thay đổi dashboard hoặc quy tắc cảnh báo.
  • Hành vi khôi phục phải được kiểm thử bằng cách tiêm các lỗi mạng để đảm bảo agent thử lại một cách hợp lý thay vì phát động các cuộc tấn công từ chối dịch vụ (DoS).

Bối cảnh

Model Context Protocol cho phép các mô hình AI tương tác với phần mềm bên ngoài bằng cách sử dụng các giao diện chuẩn hóa. Không giống như các API client truyền thống do con người viết, các agent LLM là phi xác định, nghĩa là chúng có thể chọn các công cụ hoặc tham số khác nhau mỗi lần chạy. Chúng dựa vào xác suất token thay vì logic chặt chẽ, dẫn đến các đầu vào sáng tạo nhưng đôi khi không chính xác. Các bài kiểm thử đơn vị tiêu chuẩn thường xác minh các luồng thuận lợi (happy paths) với dữ liệu sạch, bỏ qua các trường hợp biên mà agent gặp khó khăn, chẳng hạn như mô tả công cụ mơ hồ hoặc lỗi mạng một phần.

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

Đối với các đội ngũ vận hành phần mềm riêng, việc phụ thuộc vào các máy chủ MCP chưa được kiểm thử đầy đủ tạo ra rủi ro vận hành đáng kể. Một agent hiểu sai timeout thành một kết quả trống thành công có thể thông báo rằng mọi thứ đều ổn trong khi cơ sở dữ liệu production đang bị sập. Niềm tin sai lệch này làm chậm sự can thiệp của con người và kéo dài thời gian sự cố. Hơn nữa, các agent không xử lý tốt việc hết hạn xác thực sẽ ngừng thu thập dữ liệu một cách im lặng, khiến các kỹ sư on-call mù mờ về nguyên nhân gốc rễ.

Sự khác biệt giữa kiểm thử Cấp độ 1 và Cấp độ 2 rất quan trọng cho việc phân bổ nguồn lực. Sửa các vấn đề Cấp độ 1 liên quan đến việc sửa lỗi mã, trong khi các lỗi Cấp độ 2 yêu cầu điều chỉnh cách mô tả công cụ và cách cấu trúc lỗi cho AI tiêu thụ. Bỏ qua Cấp độ 2 có nghĩa là triển khai các hệ thống hoạt động tốt trong bản demo nhưng thất bại dưới áp lực. Các đội ngũ phải coi tương tác với agent là một chế độ lỗi riêng biệt, đòi hỏi các chiến lược xác thực cụ thể vượt ra ngoài quy trình đảm bảo chất lượng phần mềm truyền thống.

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

  • Triển khai các bài kiểm thử âm trong pipeline CI của bạn, gửi đầu vào trống, kiểu dữ liệu sai và giá trị ngoài phạm vi cho các handler MCP của bạn.
  • Đảm bảo máy chủ của bạn trả về các cấu trúc JSON riêng biệt cho timeout so với kết quả trống để ngăn chặn ảo giác của agent về tình trạng hệ thống.
  • Chạy mỗi tác vụ phân loại sự cố ít nhất năm lần trong harness kiểm thử của bạn để đo lường độ tin cậy thay vì chỉ chọn một lần chạy thành công duy nhất.
  • Xác thực token xác thực trong từng lần gọi riêng lẻ thay vì chỉ khi khởi động máy chủ để xử lý việc hết hạn thông tin đăng nhập trong các sự cố kéo dài.
  • So sánh trạng thái hệ thống sau mỗi lần chạy kiểm thử tự động để phát hiện bất kỳ thay đổi không mong muốn nào đối với dashboard hoặc cấu hình cảnh báo.
  • Tiêm các lỗi mạng tổng hợp trong quá trình kiểm thử để xác minh rằng agent của bạn thử lại với backoff lũy thừa thay vì spam các yêu cầu.

Tin khác

Tất cả tin