IBM và UC Berkeley Chẩn đoán Nguyên nhân Thất bại của Đại lý Doanh nghiệp Sử dụng IT-Bench và MAST

Tác giả: Ayhan Sebin, Rohan Arora, Saurabh Jha

Ngày đăng: 18 tháng 2 năm 2026

Giới thiệu

IBM Research và UC Berkeley đã hợp tác để nghiên cứu cách các hệ thống LLM dựa trên tác nhân (agent) gặp sự cố trong tự động hóa CNTT trong thế giới thực, với các tác vụ liên quan đến phân loại sự cố, truy vấn nhật ký/chỉ số và hành động Kubernetes trong vòng lặp công cụ dài hạn.

Các điểm chuẩn thường giảm hiệu suất xuống một con số duy nhất, cho bạn biết tác nhân có thất bại hay không, nhưng không bao giờ biết tại sao. Để giải quyết vấn đề “hộp đen” này, chúng tôi đã áp dụng MAST (Multi-Agent System Failure Taxonomy - Phân loại Thất bại Hệ thống Đa Tác nhân), một thực tiễn mới nổi để chẩn đoán độ tin cậy của tác nhân. Bằng cách tận dụng MAST để phân tích ITBench - điểm chuẩn ngành cho tự động hóa SRE, Bảo mật và FinOps - chúng tôi đã biến các dấu vết thực thi thô thành các mẫu lỗi có cấu trúc, làm rõ chính xác điều gì đã hỏng và cách khắc phục. Chúng tôi đã chú thích 310 dấu vết ITBench SRE trên ba lớp mô hình khác nhau: Gemini-3-Flash, Kimi-K2 và GPT-OSS-120B.

Phát hiện chính

• Các mô hình tiên tiến như Gemini-3-Flash thất bại một cách sạch sẽ (trung bình 2,6 chế độ lỗi/dấu vết), thường gặp các điểm nghẽn riêng biệt như xác minh. Các mô hình mở lớn như GPT-OSS-120B gặp phải các mẫu lỗi chồng chéo (trung bình 5,3 chế độ lỗi/dấu vết). Một sự không khớp trong suy luận sớm trong quá trình xử lý sẽ làm ảnh hưởng đến ngữ cảnh, dẫn đến các lỗi ảo hóa chồng chéo.
• Trong tất cả các mô hình, yếu tố dự báo mạnh nhất cho sự thất bại là FM-3.3 (Xác minh không chính xác). Tác nhân liên tục “tuyên bố chiến thắng” mà không kiểm tra sự thật.
• Kimi-K2 gặp khó khăn trong việc nhận ra khi nào một tác vụ đã hoàn thành. Nó cho thấy sự gia tăng lớn về Chấm dứt Sớm (+46%) và Không nhận thức được Điều kiện Chấm dứt (+43%), thường dừng lại ngay trước khi giải quyết vấn đề hoặc lặp vô hạn.

Bài học kinh nghiệm khi xây dựng tác nhân

• Đối với các mô hình tiên tiến như Gemini: Cần ngoại suy hóa việc xác minh. Không bao giờ để LLM tự đánh giá bài làm của mình. Yêu cầu bằng chứng công cụ cứng trước khi thoát.
• Kiểm soát việc chấm dứt và lặp lại ngoài mô hình: Các vấn đề chấm dứt là nguyên nhân gây ra sự cố phổ biến (FM-1.5). Thêm các điều kiện dừng rõ ràng và bộ dò lặp cho các lệnh/hành động công cụ lặp lại hoặc triển khai Máy trạng thái hữu hạn.
• Buộc làm rõ hoặc chỉ đọc khi đầu vào không rõ ràng: Các lỗi làm rõ (FM-2.2) là một động lực gây lỗi lớn cho các mô hình nhỏ hơn. Biến sự không rõ ràng thành một nhánh hạng nhất trong biểu đồ tác nhân của bạn.

Nếu bạn đang xây dựng tác nhân cho quy trình làm việc CNTT doanh nghiệp, đây là loại đánh giá bạn muốn: không chỉ là “nó đã vượt qua chưa?”, mà là “điều gì đã hỏng, ở đâu và biện pháp can thiệp nào có đòn bẩy lớn nhất?”

---

Vấn đề “Hộp Đen” của các Điểm chuẩn Tác nhân

Các điểm chuẩn như ITBench đang trở thành tiêu chuẩn để đo lường hiệu suất tác nhân trong các tác vụ tự động hóa CNTT có rủi ro cao. Trong ITBench, tác nhân hoạt động như Kỹ sư Độ tin cậy Trang web (SRE) hoặc Nhà phân tích Bảo mật có nhiệm vụ chẩn đoán sự cố Kubernetes, vá lỗ hổng bảo mật hoặc quản lý chi phí đám mây trong môi trường sản xuất.

Các điểm chuẩn này sử dụng tỷ lệ thành công làm thước đo chính để đánh giá tác nhân. Tuy nhiên, thước đo này không đủ để kỹ thuật các hệ thống mạnh mẽ. Biết rằng một hệ thống tác nhân đạt tỷ lệ thành công 14% trên ITBench cho chúng ta biết rằng nó đã thất bại, nhưng không phải tại sao: Nó thất bại vì nó quên ngữ cảnh? Vì nó ảo giác một lệnh? Hay vì nó đơn giản là không dừng lại?

Nếu không có cách tiếp cận toàn diện để chẩn đoán các lỗi này, các nhà phát triển sẽ phải đoán mò, thường quay trở lại việc điều chỉnh các lời nhắc một cách mù quáng chỉ giải quyết được một vấn đề này nhưng lại tạo ra một vấn đề khác.

Là một tiêu chuẩn mới để phân tích các chế độ lỗi của các hệ thống tác nhân phức tạp, chúng tôi đã phát triển MAST (Multi-Agent System Failure Taxonomy - Phân loại Thất bại Hệ thống Đa Tác nhân). MAST mang lại nhiều hiểu biết sâu sắc hơn và mở ra quá trình đánh giá mờ ám của các điểm chuẩn này. Được phát triển từ phân tích nghiêm ngặt hơn 1.600 dấu vết trên bảy khuôn khổ khác nhau, MAST cung cấp một phân loại tiêu chuẩn cho các lỗi của tác nhân.

MAST chuyển đổi các nhật ký thực thi không có cấu trúc thành “véc-tơ lỗi” có cấu trúc dựa trên 14 mẫu riêng biệt trên ba danh mục chính:

• FC1: Vấn đề Thiết kế Hệ thống (The “Skeleton”)
  • Các lỗi ở đây bắt nguồn từ kiến trúc và định nghĩa vai trò của tác nhân.
  • Ví dụ: FM-1.3 Lặp lại Bước (lặp lại), FM-1.4 Mất Lịch sử Hội thoại (rò rỉ bộ nhớ), FM-1.5 Không Nhận thức được Chấm dứt (không dừng lại).
• FC2: Sai lệch giữa các Tác nhân (The “Communication”)
  • Các lỗi phát sinh trong thời gian chạy từ cách các tác nhân giao tiếp với nhau hoặc với môi trường.
  • Ví dụ: FM-2.2 Không Yêu cầu Làm rõ (giả định thay vì hỏi), FM-2.3 Lạc đề Nhiệm vụ (lạc đề).
• FC3: Xác minh Nhiệm vụ (The “Quality Control”)
  • Các lỗi trong đảm bảo chất lượng đầu ra của tác nhân.
  • Ví dụ: FM-3.1 Chấm dứt Sớm (bỏ cuộc quá sớm), FM-3.3 Xác minh không Chính xác (ảo giác thành công).

Thí nghiệm: Chẩn đoán Tác nhân ITBench

Chúng tôi đã kiểm tra nghiêm ngặt ý tưởng sử dụng MAST để làm cho các đánh giá tác nhân có thể hành động được và thu thập thông tin chi tiết về các chế độ lỗi bằng cách áp dụng nó cho ITBench, một bộ công cụ đánh giá phổ biến cho các tác vụ tự động hóa CNTT trên SRE, Bảo mật/Tuân thủ và FinOps.

Chúng tôi đã chú thích 310 dấu vết thực thi SRE của ITBench được tạo ra bởi một tác nhân SRE được xây dựng với Codex trong môi trường thực tế. Các dấu vết này ghi lại các tương tác ngôn ngữ tự nhiên giữa các tác nhân và công cụ của chúng trên ba mô hình đại diện cho các cấp độ khả năng khác nhau: Gemini-3-Flash, Kimi-K2 và GPT-OSS-120B. Điều này cho phép chúng ta xem xét sâu hơn các số liệu thành công đơn giản và điều tra các mẫu lỗi riêng biệt thúc đẩy các kết quả này. Chúng tôi sử dụng điểm số thu hồi (recall scores), vì theo thiết kế, các mô hình chỉ xuất ra tối đa 3-5 đầu ra và các SRE ưu tiên điểm số thu hồi hơn điểm F-1.

• Gemini-3-Flash: 100 dấu vết (75,5% Điểm thu hồi trung bình)
• Kimi-K2: 105 dấu vết (28,6% Điểm thu hồi trung bình)
• GPT-OSS-120B: 105 dấu vết (12,4% Điểm thu hồi trung bình)

Dưới đây, chúng tôi trình bày chi tiết các phát hiện từ phân tích chẩn đoán này.

Phát hiện 1: Các mô hình mạnh mẽ hơn như Gemini-3-Flash cho thấy các chế độ lỗi mang tính phẫu thuật (riêng biệt) trên mỗi dấu vết, trong khi Kimi-K2 và GPT-oss-120b mã nguồn mở lại thể hiện các mẫu lỗi chồng chéo.

Khi chúng ta xem xét các dấu vết bị lỗi, một sự phân cấp rõ ràng về độ phức tạp xuất hiện giữa ba mô hình. Điều này được đo bằng số lượng chế độ lỗi riêng biệt được quan sát trên mỗi lần chạy bị lỗi.

• Gemini-3-Flash: 2,6 chế độ lỗi trên mỗi dấu vết bị lỗi
• Kimi-K2: 4,7 chế độ lỗi trên mỗi dấu vết bị lỗi
• GPT-OSS-120B: 5,3 chế độ lỗi trên mỗi dấu vết bị lỗi

Sự khác biệt về mật độ chế độ lỗi này cho thấy sự khác biệt cơ bản trong cách các hệ thống này gặp sự cố. Gemini-3-Flash thể hiện một hồ sơ lỗi mang tính phẫu thuật. Ngay cả trong các lần chạy không thành công, nó vẫn duy trì sự mạch lạc nội bộ cao và thường thất bại do một lỗi riêng biệt duy nhất, chẳng hạn như bước xác minh không chính xác. Những lỗi này là chính xác và dễ chẩn đoán hơn nhiều.

Ở phía đối diện của phổ, GPT-OSS-120B gặp phải sự sụp đổ theo tầng. Trong các dấu vết này, chúng ta quan sát thấy các lỗi có xu hướng chồng chéo theo thời gian. Một sự không khớp nhỏ trong suy luận sớm trong quy trình thường dẫn đến sự sai lệch so với đặc tả nhiệm vụ, điều này đến lượt nó lại dẫn đến sự lệch hướng hoàn toàn của tác nhân. Kimi-K2 đại diện cho khoảng giữa, nơi các lỗi thường xuyên hơn và phức tạp hơn so với mô hình tiên tiến, nhưng không đạt đến sự bất ổn hệ thống được thấy ở mô hình trọng số mở 120B.

Ý nghĩa của phát hiện này là tỷ lệ thành công cao hơn thường đi kèm với các lỗi riêng biệt. Các hệ thống gặp sự cố với ít vấn đề đồng thời hơn có thể dự đoán được hơn nhiều và đơn giản hơn để cải thiện thông qua các biện pháp can thiệp kỹ thuật có mục tiêu.

Phát hiện 2: Lỗi “Không Tử vong” so với Lỗi “Tử vong”

Có lẽ hiểu biết sâu sắc nhất từ MAST là phân biệt giữa các lỗi mà hệ thống có thể chịu đựng so với các lỗi làm tử vong nhiệm vụ. Bằng cách so sánh phân phối các chế độ lỗi trong Dấu vết Thành công so với Dấu vết Thất bại, chúng ta có thể phân loại chúng thành ba loại.

Các Lỗi “Không Tử vong” (Vô hại)

Trong cả ba mô hình, một số chế độ lỗi xuất hiện thường xuyên ngay cả trong các lần chạy cuối cùng cũng thành công. Đây thường là những trục trặc về cấu trúc chứ không phải là lỗi thiết bị đầu cuối.

• FM-1.3 Lặp lại Bước: Chế độ này có mặt trong hơn 90% các lần chạy thành công của Kimi-K2. Trong lĩnh vực SRE, việc lặp lại thường là cần thiết. Một tác nhân có thể truy vấn cùng một chỉ số nhiều lần để xác minh xem một dịch vụ có đang ổn định hay không hoặc liệu một bản sửa lỗi có có hiệu lực hay không. Gemini-3-Flash thực sự cho thấy sự lặp lại ít hơn trong các dấu vết lỗi của nó, cho thấy rằng nó đôi khi thất bại vì nó không lặp lại đủ.
• FM-1.1 Không tuân thủ Đặc tả Nhiệm vụ: Các tác nhân thường đi chệch khỏi định dạng công cụ nghiêm ngặt hoặc các hướng dẫn tuần tự nhưng vẫn xác định được nguyên nhân gốc rễ chính xác.

Sự tách biệt này là nơi MAST chứng tỏ giá trị của nó. Nó cho phép chúng ta bỏ qua các lỗi vô hại như lặp lại, thường xảy ra trong quá trình khắc phục sự cố, và thay vào đó tập trung vào các lỗi tử vong đã làm hỏng một lần chạy.

Các Lỗi “Tử vong”

Một số hành vi phân biệt mạnh mẽ giữa thành công và thất bại. Khi các chế độ này xuất hiện, xác suất kết quả thành công giảm mạnh. Ví dụ nổi bật nhất là FM-3.3 (Xác minh không Chính xác). Chế độ này cho thấy mức tăng 52% lỗi trong các dấu vết Gemini-3-Flash bị lỗi so với các dấu vết thành công của nó. Các chế độ lỗi nổi bật khác là 1.5 (Không Nhận thức được Điều kiện Chấm dứt) và 2.6 (Sai lệch Suy luận-Hành động).

Nếu những điều này xảy ra, lần chạy có thể đã chết; hướng dẫn các chuyên gia phát triển các chiến lược quản lý ngữ cảnh mạnh mẽ trên các tác nhân trong hệ thống và nhiều lượt tương tác.

Nghiên cứu tình huống: Gemini-3-Flash (Quyết đoán nhưng Tự tin quá mức)

Gemini-3-Flash rất hiệu quả, nhưng điểm nghẽn chính của nó là xu hướng giả định thành công mà không có bằng chứng nghiêm ngặt. Dấu hiệu lỗi của nó bị chi phối bởi sự chênh lệch lớn về lỗi xác minh. Nó thường xác định đúng các tín hiệu nhưng kết thúc trước khi đối chiếu chúng với sự thật cơ bản. Để khắc phục điều này, các nhà phát triển nên triển khai một cổng xác minh bên ngoài. Bằng cách yêu cầu bằng chứng dựa trên công cụ như xóa cảnh báo hoặc ngưỡng chỉ số lành mạnh trước khi cho phép tác nhân thoát, chúng ta có thể giảm thiểu sự tự tin thái quá cố hữu của mô hình này.

• Khắc phục: Để cải thiện Gemini-3-Flash trên ITBench, việc kỹ thuật lời nhắc sẽ không giúp ích nhiều. Đặc biệt, các thí nghiệm chúng tôi trình bày trong bài báo NeurIPS 2025 của chúng tôi cho thấy rằng với các biện pháp can thiệp thủ công như kỹ thuật lời nhắc cho các lỗi liên quan đến bộ nhớ, chúng ta chỉ có thể cải thiện hiệu suất lên tới khoảng 15,6%, trong khi trong một bài đăng trên blog trước đó về MAST, chúng tôi đã chỉ ra rằng bằng cách giới thiệu các tác nhân mới như một Tác nhân Tóm tắt để nhắc nhở các tác nhân khác về những gì đang diễn ra và liên tục bổ sung trạng thái của chúng (khắc phục FM-1.4) hoặc bằng cách giới thiệu các cơ chế quản lý ngữ cảnh (chẳng hạn như Máy trạng thái chặt chẽ hơn để thực thi việc chấm dứt để khắc phục FM-1.5), chúng ta có thể cải thiện hiệu suất lên tới 53% vì chúng giải quyết các vấn đề cơ bản hơn với hệ thống.

Nghiên cứu tình huống: Kimi-K2 (Khủng hoảng Chấm dứt)

Mặc dù sự nhầm lẫn về việc chấm dứt (FM-3.1 và FM-1.5) là chế độ lỗi phổ biến nhất đối với Kimi-K2, các quỹ đạo lỗi của nó được xác định bởi Sai lệch Hành động-Suy luận (FM-2.6), có mặt trong 92% lỗi của nó.

• Khoảng cách Thực thi: Mặc dù các phần suy luận nội bộ của nó thường chính xác, nhưng nó gặp sự cố phổ biến 92% với FM-2.6 (Sai lệch Hành động-Suy luận). Nó thường xác định bước tiếp theo chính xác nhưng sau đó thực hiện một lệnh dư thừa hoặc không liên quan.
• Cạm bẫy Meta-Vòng lặp: Khoảng 25% dấu vết lỗi liên quan đến FM-2.3 (Lạc đề Nhiệm vụ). Khi một lệnh công cụ trả về lỗi nhỏ, tác nhân thường từ bỏ sự cố chính để bước vào một chu kỳ gỡ lỗi các tập lệnh điều tra của chính nó.

Kimi-K2 là một ví dụ điển hình về một mô hình suy nghĩ quá nhiều, chuỗi suy luận của nó thường quá dài nhưng có thể gặp lỗi trong quá trình thực thi.

Nghiên cứu tình huống: GPT-OSS-120B

GPT-OSS-120B thể hiện hồ sơ lỗi không ổn định nhất trong nhóm. Mô hình này thể hiện trung bình 5,3 chế độ lỗi riêng biệt trên mỗi dấu vết lỗi, cho thấy sự bất lực cơ bản trong việc duy trì trạng thái nội bộ.

• Mất Lịch sử Hội thoại (FM-1.4): Đây là lỗi tử vong duy nhất đối với mô hình 120B. Nó mất lịch sử hội thoại trong 24% dấu vết, trong khi Gemini-3-Flash không gặp lỗi bộ nhớ và Kimi-K2 chỉ 7%. Khi các dấu vết SRE ngày càng dài, GPT-OSS-120B thực sự “quên” các cảnh báo mà nó ban đầu đang phân loại, dẫn đến sự lạc đề hoàn toàn của nhiệm vụ.
• Ngắt kết nối Suy luận (FM-2.6): Một con số đáng kinh ngạc 94% dấu vết cho thấy sự tách rời giữa suy luận và hành động. Nó có khả năng gấp gần 3 lần Gemini (31%) để mô tả một kế hoạch chính xác nhưng sau đó lại thực thi một lệnh hoàn toàn không liên quan hoặc dư thừa.

Một cách đọc các biểu đồ khác (và hữu ích hơn): “tử vong” so với “không tử vong”

Tóm lại, MAST cho phép bạn chia các chế độ lỗi thành hai nhóm:

Có thể phục hồi / cấu trúc (xuất hiện ngay cả trong các dấu vết thành công)

Đây là những lỗi không gây tử vong và hệ thống có thể phục hồi để hoàn thành nhiệm vụ thành công.

• FM-1.3 Lặp lại bước
• FM-3.3 Xác minh không chính xác (sự khác biệt quan trọng: hệ thống có xác minh; nó chỉ xác minh kém)
• FM-2.6 Sai lệch suy luận-hành động (thường có mặt, nhưng không phải lúc nào cũng quyết định)

Tử vong / quyết định (gắn chặt mạnh mẽ với các dấu vết bị lỗi)

Đây là những lỗi mà hệ thống thường không thể phục hồi.

• FM-1.5 Không nhận thức được điều kiện chấm dứt
• FM-3.1 Chấm dứt sớm
• FM-1.4 Mất lịch sử hội thoại
• FM-2.3 Lạc đề nhiệm vụ (hiếm nhưng cực kỳ chẩn đoán khi nó xuất hiện)
• FM-2.2 Không yêu cầu làm rõ (đặc biệt đối với các chế độ Granite/Llama)

Đây là phần “hiểu biết phong phú hơn”: hai mô hình có thể có cùng tỷ lệ thành công trên một phần nhỏ, nhưng lại thất bại vì những lý do hoàn toàn khác nhau - đòi hỏi các bản sửa lỗi khác nhau.

Kết luận

MAST là một công cụ kiểm tra các dấu vết hệ thống tác nhân để xác định các loại lỗi chi tiết hỗ trợ phát triển và gỡ lỗi hệ thống. Trong bài đăng này, chúng tôi chỉ ra rằng bằng cách áp dụng MAST cho ITBench, chúng tôi chuyển từ các quan sát chung (“Các mô hình mở gặp khó khăn”) sang một lộ trình kỹ thuật cụ thể giúp cải thiện hiệu suất của các hệ thống tác nhân dựa vào các mô hình này, ví dụ:

1. Đối với Gemini-3-Flash: Lỗi xác minh (FM-3.3) là lỗi tử vong phổ biến nhất đối với các mô hình phẫu thuật. Không bao giờ cho phép tác nhân tự kết thúc; yêu cầu bằng chứng được điều chỉnh bằng công cụ (ví dụ: xóa cảnh báo của AlertManager hoặc thay đổi trạng thái K8s) trước khi một lần chạy được coi là thành công.
2. Đối với Kimi-K2: Sử dụng một máy trạng thái xác định để khắc phục sự vật lộn thường xuyên của mô hình trong việc nhận ra việc hoàn thành nhiệm vụ. Chuỗi suy luận của mô hình này có thể quá dài và gặp khó khăn trong việc chấm dứt, vì vậy nó có thể được hưởng lợi đáng kể từ việc kiểm soát chặt chẽ hơn về thời điểm kết thúc.
3. Đối với GPT-oss-120b: Sự sụp đổ hệ thống xảy ra khi các sự không khớp suy luận nhỏ (FM-2.6) làm ảnh hưởng đến lịch sử nhiệm vụ. Triển khai vệ sinh ngữ cảnh tích cực và phát hiện lỗi sớm để đảm bảo rằng các sự không khớp nhỏ không chồng chéo thành sự lạc đề hoàn toàn.

• Bài báo IT-Bench: https://arxiv.org/pdf/2502.05352
• Mã IT-Bench: https://github.com/itbench-hub/ITBench
• Bài báo MAST: https://arxiv.org/abs/2503.13657
• Mã MAST: https://github.com/multi-agent-systems-failure-taxonomy/MAST
• MAST-Data: 🤗 MAST-Data (1600+ Dấu vết)

Link bài viết gốc

• Tags:
• Ai
• 18 February 2026
• Huggingface.co