Các chế độ lỗi và gỡ lỗi trong hệ thống AI multi-agent

Hệ thống multi-agent của bạn hoạt động tốt trong giai đoạn thử nghiệm. Bạn triển khai nó. Nó bị lỗi trong môi trường sản xuất. Chào mừng bạn đến với phần khó khăn nhất của kỹ thuật tạo hệ thống multi-agent.

🔄 Tóm tắt nhanh: Trong Bài học 6, bạn đã thấy rằng chất lượng hệ thống không bằng tổng chất lượng của các agent — những lỗi phối hợp ẩn giấu giữa các agent. Bây giờ, bạn sẽ học cách tìm và khắc phục chúng một cách có hệ thống bằng cách sử dụng framework MAST.

Tại sao gỡ lỗi multi-agent lại khó khăn?

Gỡ lỗi truyền thống giả định tính xác định. Bạn đặt điểm dừng, kiểm tra trạng thái, từng bước thực thi code. Nhưng hệ thống multi-agent không xác định. Cùng một lệnh tạo ra các kết quả khác nhau. Sự thay đổi nhỏ của agent A lan truyền qua các agent B, C và D. Đến khi bạn thấy kết quả cuối cùng bị lỗi, nguyên nhân gốc rễ đã bị che khuất.

Nghiên cứu từ UC Berkeley cho thấy 36,94% lỗi multi-agent đến từ các vấn đề phối hợp và 21,30% từ những lỗ hổng xác minh. Điều đó có nghĩa là hơn một nửa số lỗi xảy ra giữa các agent, chứ không phải bên trong chúng.

Bạn không thể gỡ lỗi bằng cách xem xét từng agent riêng lẻ. Bạn cần theo dõi luồng hoạt động.

Framework MAST

MAST cung cấp cho bạn một cách có hệ thống để phân loại và chẩn đoán lỗi:

M — Misalignment (Sự không đồng nhất)

Định nghĩa: Các agent có mục tiêu, ưu tiên hoặc cách hiểu nhiệm vụ mâu thuẫn nhau.

Triệu chứng: Các agent mâu thuẫn với nhau. Kết quả cuối cùng không khớp với ý định ban đầu. Một agent làm hỏng công việc của agent khác.

Ví dụ: Research Agent của bạn phát hiện ra rằng sản phẩm X có những lỗ hổng bảo mật nghiêm trọng. Marketing Agent của bạn, được hướng dẫn "trình bày sản phẩm một cách tích cực", lại hạ thấp các lỗ hổng trong báo cáo. Cả hai agent đều đang làm công việc của mình — nhưng mục tiêu của chúng mâu thuẫn.

Khắc phục: Đồng bộ hướng dẫn của agent với một mục tiêu chung. Thêm thứ tự ưu tiên: "Độ chính xác được ưu tiên hơn so với việc trình bày tích cực". Sử dụng một agent kiểm tra tính nhất quán giữa các đầu ra.

A — Ambiguity (Sự mơ hồ)

Định nghĩa: Hướng dẫn, đầu vào hoặc đầu ra quá mơ hồ khiến các agent hiểu chúng khác nhau.

Triệu chứng: Kết quả khác nhau rất nhiều giữa các lần chạy. Các agent tạo ra những định dạng đầu ra không mong muốn. Các agent xử lý sau không thể phân tích đầu ra xử lý trước.

Ví dụ: Bạn yêu cầu Analysis Agent "đánh giá các đối thủ cạnh tranh." Điều đó có nghĩa là giá cả? Tính năng? Thị phần? Đánh giá của khách hàng? Tất cả những điều trên? Các lần chạy khác nhau sẽ tạo ra các cách diễn giải khác nhau.

Khắc phục: Hãy cụ thể hơn. "Đánh giá các đối thủ cạnh tranh trên 4 khía cạnh này: Giá cả (chi phí hàng tháng), tính năng (liệt kê 5 tính năng hàng đầu), thị phần (% nếu có), xếp hạng của khách hàng (trên thang điểm 5)." Sự mơ hồ đầu vào → đầu ra không chính xác.

✅ Kiểm tra nhanh: Prompt hệ thống là "Viết một bài phân tích kỹ lưỡng". Agent A viết 3.000 từ. Agent B viết 200 từ. Cả hai đều nghĩ rằng chúng đã làm đúng yêu cầu của bạn. Đây thuộc loại MAST nào?

Đáp án: Sự mơ hồ. "Kỹ lưỡng" có nghĩa khác nhau đối với các agent khác nhau. Khắc phục bằng cách cụ thể hóa: "Viết một bài phân tích từ 500-800 từ bao gồm giá cả, tính năng và vị trí thị trường". Định lượng kỳ vọng bất cứ khi nào có thể.

S — Specification Errors (Lỗi đặc tả)

Định nghĩa: Schema đầu ra, định dạng hoặc yêu cầu nội dung không đầy đủ hoặc không chính xác.

Triệu chứng: Các agent trả về dữ liệu sai định dạng. Thiếu các trường bắt buộc. Kiểu dữ liệu không nhất quán (chuỗi so với số).

Ví dụ: Schema của bạn nói rằng Research Agent nên trả về {"competitors": [...]} nhưng đôi khi agent trả về {"results": [...]} hoặc gói tất cả trong {"data": {"competitors": [...]}}. Agent tiếp theo tìm kiếm đối thủ cạnh tranh ở cấp cao nhất và không tìm thấy gì.

Khắc phục: Schema rõ ràng với các ví dụ trong prompt hệ thống của agent. Thêm xác thực giữa các agent — kiểm tra xem các trường bắt buộc có tồn tại và kiểu dữ liệu có khớp trước khi chuyển tiếp đầu ra. Phiên bản hóa schema của bạn để các thay đổi là có chủ đích.

T — Termination Gaps (Khoảng trống kết thúc)

Định nghĩa: Hệ thống không biết khi nào cần dừng lại — các agent liên tục thử lại, những cuộc hội thoại bị lặp lại, hoặc thiếu ngưỡng chất lượng.

Triệu chứng: Sử dụng token vượt quá mức cho phép. Các agent bị kẹt trong vòng lặp. Hệ thống không bao giờ tạo ra kết quả cuối cùng. Chi phí tăng đột biến ngoài dự kiến.

Ví dụ: Editor Agent của bạn liên tục gửi bản nháp trở lại cho Writer Agent để "sửa đổi thêm một lần nữa". Writer thực hiện một thay đổi nhỏ. Editor yêu cầu sửa đổi thêm. Điều này tiếp diễn trong 15 vòng cho đến khi bạn đạt đến ngân sách API của mình.

Khắc phục: Điều kiện kết thúc rõ ràng cho mỗi vòng lặp:

• Số lần thử lại tối đa (3 lần thử lại sau đó tăng dần)
• Thời gian chờ (tối đa 30 giây cho mỗi agent)
• Ngưỡng chất lượng (nếu điểm > 0.8, dừng sửa đổi)
• Ngân sách token (tối đa 5.000 token/agent cho mỗi tác vụ)

✅ Kiểm tra nhanh: Các Editor Agent và Writer Agent của bạn trao đổi qua lại 12 lần trước khi tạo ra kết quả. Bản nháp cuối cùng chỉ tốt hơn một chút so với bản sửa đổi thứ ba. Khắc phục như thế nào?

Đáp án: Đây là khoảng trống chấm dứt. Đặt tối đa 3 vòng sửa đổi và thêm ngưỡng chất lượng — "Nếu bản sửa đổi cải thiện điểm chất lượng dưới 5%, hãy chấp nhận phiên bản hiện tại". Hiệu quả giảm dần sẽ xuất hiện nhanh chóng. Hầu hết giá trị đến từ 2-3 lần lặp đầu tiên.

Chiến lược gỡ lỗi

Chiến lược 1: Ghi nhật ký có cấu trúc ở mỗi lần chuyển giao

Ghi nhật ký mọi thứ mà các agent chuyển cho nhau:

Nơi dán: Mở ChatGPT (chat.openai.com), Claude (claude.ai) hoặc Gemini (gemini.google.com) và bắt đầu một cuộc trò chuyện mới.

📋 Cách sao chép prompt này: Nhấp vào bất kỳ đâu bên trong khối màu xám, nhấn Cmd+A rồi Cmd+C (Mac) hoặc Ctrl+A rồi Ctrl+C (Windows). Hoặc sử dụng biểu tượng sao chép xuất hiện.

{
  "handoff_id": "h_001",
  "from_agent": "researcher",
  "to_agent": "writer",
  "timestamp": "2026-03-13T10:05:23Z",
  "token_count": 1247,
  "output_valid": true,
  "schema_version": "1.2"
}

✏️ ​​Cách điền thông tin của bạn: Thay thế mỗi [] và trình giữ chỗ trong ngoặc bằng thông tin cụ thể từ tình huống thực tế của bạn. Thông tin đầu vào mơ hồ sẽ dẫn đến kết quả đầu ra mơ hồ — hãy cụ thể hơn.

👀 Những gì bạn sẽ thấy: Trong vòng vài giây, AI sẽ trả về một phản hồi có cấu trúc dựa trên prompt ở trên. Hãy đọc kỹ và coi đó là bản nháp, không phải câu trả lời cuối cùng.

📌 Nên làm gì với kết quả đầu ra: Lưu phản hồi vào một file Notes. Chọn gợi ý có hiệu quả cao nhất và thực hiện nó trong tuần này — đừng cố gắng làm tất cả cùng một lúc.

⚠️ Nếu kết quả không ổn: Nếu các gợi ý có vẻ chung chung, hãy dán nội dung này: "Hãy cụ thể hơn với ngữ cảnh thực tế của tôi. Bỏ những lời khuyên chung chung." Nếu nó bỏ qua các chi tiết quan trọng bạn đã cung cấp, hãy hỏi: "Bạn đã bỏ sót [X] trong ngữ cảnh của tôi — hãy thực hiện lại với điều đó làm ràng buộc chính".

Khi có lỗi xảy ra, hãy truy ngược lại các bước chuyển giao từ kết quả đầu ra không chính xác. Bước chuyển giao đầu tiên mà output_valid là false — hoặc nơi kết quả đầu ra không khớp với những gì agent tiếp theo mong đợi — chính là nguyên nhân gốc rễ.

Chiến lược 2: Phát lại các lần chạy thất bại

Lưu lại toàn bộ dữ liệu đầu vào/đầu ra cho mỗi agent trong mỗi lần chạy. Khi xảy ra lỗi, hãy phát lại lần chạy từng bước:

1. Lấy đầu vào của agent 1. Chạy thủ công. Kết quả đầu ra có đúng không?
2. Lấy đầu vào thực tế của agent 2 (từ lần chạy thất bại). Chạy thủ công. Kết quả đầu ra có đúng không?
3. Tiếp tục cho đến khi bạn tìm thấy agent tạo ra kết quả đầu ra sai — hoặc bước chuyển giao làm mất thông tin.

Chiến lược 3: Kiểm thử Canary

Trước khi triển khai các thay đổi cho toàn bộ hệ thống, hãy chạy phiên bản mới song song với phiên bản cũ. So sánh kết quả đầu ra:

1. Cả hai phiên bản có tạo ra cùng một kết quả không?
2. Chúng khác nhau ở đâu?
3. Phiên bản mới thực sự tốt hơn hay chỉ khác biệt?

Điều này giúp phát hiện các lỗi hồi quy trước khi chúng được đưa vào sản xuất. Chạy 50-100 trường hợp thử nghiệm thông qua cả hai phiên bản và so sánh.

Chiến lược 4: Kiểm tra tách biệt

Kiểm tra từng agent trong điều kiện hoàn toàn tách biệt với đầu vào được kiểm soát:

• Agent A có tạo ra đầu ra chính xác cho 20 đầu vào khác nhau không?
• Agent B có xử lý tất cả các định dạng đầu ra mà agent A có thể tạo ra không?
• Liệu quá trình xác thực schema chuyển giao có phát hiện dữ liệu bị lỗi định dạng không?

Nếu các agent vượt qua kiểm tra tách biệt nhưng lại thất bại khi hoạt động như một hệ thống, vấn đề nằm ở sự phối hợp — chứ không phải ở những agent.

✅ Kiểm tra nhanh: Bạn đã khoanh vùng lỗi vào đâu đó giữa agent 3 và agent 5 trong một quy trình gồm 7 agent. Bước gỡ lỗi tiếp theo của bạn là gì?

Câu trả lời: Phát lại lần chạy bị lỗi cho các agent 3, 4 và 5 một cách tách biệt. Lấy dữ liệu đầu vào thực tế của agent 3 từ lần chạy bị lỗi và chạy lại thủ công. Kiểm tra đầu ra của nó. Cung cấp đầu ra đó cho agent 4 thủ công. Kiểm tra. Tiếp tục cho đến khi bạn tìm thấy chính xác agent hoặc quá trình chuyển giao nơi xảy ra lỗi. Mục tiêu là thu hẹp từ "ở đâu đó trong các agent 3-5" xuống "agent 4 tạo ra JSON bị lỗi định dạng".

Phòng ngừa tốt hơn là phát hiện

Cách gỡ lỗi tốt nhất là ngăn ngừa lỗi ngay từ đầu:

Các nhóm đầu tư vào phòng ngừa sẽ tiết kiệm được 80% thời gian gỡ lỗi trong môi trường sản xuất. 30 phút bạn dành để viết schema và xác thực đúng cách sẽ tiết kiệm được nhiều ngày tìm kiếm các lỗi khó hiểu.

Những điểm chính cần ghi nhớ

• Framework MAST phân loại các lỗi: Sai lệch, Mơ hồ, Lỗi đặc tả, Khoảng trống kết thúc
• 36,94% lỗi đến từ các vấn đề phối hợp giữa những agent, chứ không phải bên trong chúng
• Ghi nhật ký có cấu trúc ở mỗi lần chuyển giao là công cụ gỡ lỗi quan trọng nhất
• Phát lại các lần chạy thất bại từng bước để tìm ra điểm lỗi chính xác
• Kiểm tra tách biệt từng agent giúp phát hiện các lỗi riêng lẻ; kiểm thử hệ thống giúp phát hiện các lỗi phối hợp
• Phòng ngừa tốt hơn phát hiện — schema, hợp đồng, điều kiện kết thúc và kiểm thử canary