Lan truyền lỗi trong hệ thống đa agent

Những điều bạn cần biết

Lan truyền lỗi (error propagation) quyết định một hệ thống đa agent có phục hồi một cách suôn sẻ hay thất bại trong im lặng. Khi một subagent gặp phải sự cố — timeout, lỗi quyền truy cập, một truy vấn không hợp lệ — cách thông tin về sự cố đó truyền ngược về bộ điều phối (coordinator) sẽ quyết định độ tin cậy của hệ thống. Đề thi kiểm tra sự hiểu biết của bạn về ngữ cảnh lỗi có cấu trúc, hai anti-pattern quan trọng, và sự phân biệt mà hầu hết các nhà phát triển thường nhầm lẫn: lỗi truy cập so với kết quả rỗng hợp lệ.

Ngữ cảnh lỗi có cấu trúc

Khi một subagent thất bại, nó phải trả về ngữ cảnh lỗi có cấu trúc để bộ điều phối có thể đưa ra quyết định phục hồi thông minh. Ngữ cảnh này phải bao gồm bốn yếu tố:

1. Loại lỗi. Phân loại sự cố: tạm thời (timeout, giới hạn tần suất — có thể thành công khi thử lại), xác thực (đầu vào sai — cần sửa truy vấn), nghiệp vụ (vi phạm quy tắc — cần leo thang hoặc tìm phương án khác), hoặc quyền truy cập (bị từ chối truy cập — không thể thử lại nếu không thay đổi quyền hạn).

2. Đã thử làm gì. Truy vấn cụ thể, các tham số đã dùng, và hệ thống mục tiêu. "Đã tìm kiếm trong cơ sở dữ liệu học thuật với từ khóa 'chính sách năng lượng tái tạo' trong khoảng thời gian 2022-2024" là thông tin hữu ích để hành động. "Tìm kiếm thất bại" thì không.

3. Kết quả từng phần thu thập được trước khi thất bại. Nếu subagent đã lấy được ba trong số năm nguồn trước khi bị timeout, ba kết quả đó vẫn có giá trị. Việc vứt bỏ chúng chỉ vì toàn bộ thao tác thất bại là lãng phí.

4. Các phương án thay thế khả thi. Subagent hiểu rõ lĩnh vực của nó. Nếu một cơ sở dữ liệu học thuật đang gặp sự cố, nó có thể đề xuất thử một cơ sở dữ liệu khác, mở rộng từ khóa tìm kiếm, hoặc kiểm tra kết quả đã lưu cache. Những gợi ý này giúp bộ điều phối quyết định chiến lược phục hồi.

jsonCopy

{
  "status": "partial_failure",
  "failureType": "transient",
  "attemptedAction": {
    "tool": "search_academic_db",
    "query": "renewable energy policy",
    "dateRange": "2022-2024"
  },
  "partialResults": [
    {
      "title": "EU Renewable Energy Directive 2023",
      "source": "EUR-Lex",
      "retrieved": true
    }
  ],
  "alternativeApproaches": [
    "Retry with narrower date range (2023-2024)",
    "Search alternative database: government_publications",
    "Use cached results from previous research session"
  ]
}

Cấu trúc này cung cấp cho bộ điều phối mọi thứ nó cần để quyết định: thử lại cùng một truy vấn, thử một phương án khác, tiếp tục với kết quả từng phần, hoặc leo thang.

Hai anti-pattern

Đề thi kiểm tra hai điều này một cách trực tiếp. Cả hai đều thảm khốc theo những cách khác nhau:

Che giấu trong im lặng: trả về kết quả rỗng nhưng đánh dấu là thành công. Đây là anti-pattern tệ nhất. Subagent gặp phải timeout nhưng trả về { "results": [], "status": "success" }. Bộ điều phối tin rằng cuộc tìm kiếm đã chạy và không tìm thấy gì. Nó sẽ không thử lại, không thử phương án khác, và sẽ tạo ra một bản tổng hợp âm thầm bỏ sót toàn bộ một lĩnh vực nghiên cứu. Đầu ra cuối cùng trông có vẻ đầy đủ nhưng lại thiếu nội dung quan trọng.

Việc che giấu trong im lặng đặc biệt nguy hiểm vì nó vô hình. Đầu ra trông có vẻ đúng — nó chỉ có những lỗ hổng mà không ai có thể phát hiện được. Trong bối cảnh hỗ trợ khách hàng, điều này có thể có nghĩa là agent báo cáo "không tìm thấy đơn hàng" trong khi hệ thống tra cứu đơn hàng thực ra đang gặp sự cố, khiến agent nói với khách hàng rằng họ không có tài khoản.

Chấm dứt luồng công việc: giết chết toàn bộ pipeline chỉ vì một lỗi duy nhất. Một subagent bị timeout và toàn bộ pipeline nghiên cứu sập theo. Bốn subagent còn lại đã hoàn thành thành công, nhưng kết quả của chúng bị vứt bỏ. Đây là một phản ứng không tương xứng, lãng phí công việc đã hoàn thành và không cung cấp lối phục hồi nào.

Điểm cân bằng đúng đắn là lan truyền lỗi có cấu trúc: subagent thất bại báo cáo những gì đã xảy ra, bộ điều phối đánh giá thiệt hại, và hệ thống tiếp tục với kết quả từng phần hoặc phục hồi có mục tiêu.

Lỗi truy cập so với kết quả rỗng hợp lệ

Sự phân biệt này rất quan trọng và đề thi kiểm tra nó một cách trực tiếp:

Lỗi truy cập: Tool không thể tiếp cận nguồn dữ liệu. Một timeout, một lỗi kết nối, một từ chối quyền truy cập. Cuộc tìm kiếm chưa thực sự chạy. Hãy cân nhắc thử lại với cùng tham số hoặc tham số đã điều chỉnh.

Kết quả rỗng hợp lệ: Tool đã tiếp cận được nguồn và thực thi truy vấn. Nó không tìm thấy kết quả khớp nào. Đây CHÍNH LÀ câu trả lời. Không cần thử lại vì hệ thống đã hoạt động đúng — chỉ đơn giản là không có kết quả nào cho truy vấn này.

Nhầm lẫn hai điều này dẫn đến hai vấn đề:

• Coi lỗi truy cập là kết quả rỗng hợp lệ nghĩa là bạn sẽ không bao giờ thử lại khi lẽ ra nên thử.
• Coi kết quả rỗng hợp lệ là lỗi truy cập nghĩa là bạn lãng phí thời gian thử lại một truy vấn mà lúc nào cũng sẽ trả về không có gì.

pythonCopy

# Access failure — consider retry
{
    "status": "error",
    "failureType": "transient",
    "message": "Connection timeout after 30s",
    "shouldRetry": True
}
 
# Valid empty result — no retry needed
{
    "status": "success",
    "results": [],
    "message": "Query executed successfully. No matching records found.",
    "shouldRetry": False
}

Chú thích mức độ bao phủ

Khi một agent tổng hợp kết hợp các phát hiện từ nhiều subagent, đầu ra nên ghi chú lĩnh vực chủ đề nào được hỗ trợ đầy đủ và lĩnh vực nào còn thiếu sót. Nếu một subagent không lấy được các nguồn về năng lượng địa nhiệt, bản tổng hợp nên ghi rõ:

"Phần về năng lượng địa nhiệt bị hạn chế do không thể truy cập tạp chí học thuật trong quá trình nghiên cứu."

Điều này tốt hơn nhiều so với việc âm thầm bỏ qua chủ đề đó. Chú thích mức độ bao phủ cho người đọc biết báo cáo bao quát đầy đủ điều gì và có những hạn chế đã biết ở đâu. Không có chúng, một lỗ hổng trong bản tổng hợp trông giống như chủ đề đó không liên quan, thay vì thực tế là nguồn dữ liệu không khả dụng.

Phục hồi cục bộ đối với lỗi tạm thời

Subagent nên triển khai phục hồi cục bộ đối với các lỗi tạm thời — logic thử lại, nguồn dự phòng, phản hồi ở mức suy giảm — trước khi lan truyền lỗi lên bộ điều phối. Chỉ lan truyền các lỗi mà subagent không thể tự giải quyết cục bộ. Khi lan truyền, luôn bao gồm những gì đã thử và bất kỳ kết quả từng phần nào đã thu thập được.

Điều này giảm bớt độ phức tạp cho bộ điều phối. Bộ điều phối không cần phải quản lý logic thử lại cho mọi lỗi tạm thời có thể xảy ra ở mọi subagent. Mỗi subagent tự xử lý các lỗi tạm thời của mình và chỉ leo thang những lỗi kéo dài.

Bẫy thi

Tình huống luyện tập

Không tìm thấy câu hỏi luyện tập "q-5-3-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Domain 5, Task Statement 5.3 — Anthropic
• Anthropic Multi-Agent Patterns — Anthropic