Bỏ qua để đến nội dung

5.3 Error Propagation in Multi-Agent Systems

Error propagation quyết định một hệ thống multi-agent phục hồi êm ái hay hỏng âm thầm. Khi một subagent gặp sự cố — timeout, lỗi phân quyền, truy vấn không hợp lệ — cách thông tin sự cố đó chảy ngược về coordinator sẽ định đoạt độ tin cậy của cả hệ thống. Đề thi kiểm tra bạn hiểu về structured error context, hai anti-pattern quan trọng, và điểm phân biệt mà hầu hết developer làm sai: access failure so với valid empty result.

Khi một subagent thất bại, nó phải trả về structured error context đủ để coordinator ra quyết định phục hồi thông minh. Context này phải có bốn thành phần:

1. Loại sự cố. Phân loại: transient (timeout, rate limit — retry có thể thành công), validation (input sai — sửa truy vấn), business (vi phạm quy tắc — escalate hoặc tìm phương án khác), hoặc permission (từ chối truy cập — không retry được nếu không đổi phân quyền).

2. Đã thử làm gì. Truy vấn cụ thể, tham số đã dùng, hệ thống đích. “Searched academic database for ‘renewable energy policy’ with date range 2022-2024” là thông tin dùng được. “Search failed” thì không.

3. Partial result thu được trước khi hỏng. Nếu subagent lấy được ba trong năm nguồn rồi mới timeout thì ba kết quả đó vẫn có giá trị. Vứt đi chỉ vì thao tác tổng thể thất bại là lãng phí.

4. Các hướng thay thế khả dĩ. Subagent hiểu miền của nó. Nếu một academic database đang chết, nó có thể gợi ý thử database khác, nới rộng từ khoá tìm kiếm, hoặc kiểm tra kết quả đã cache. Những gợi ý này giúp coordinator chọn chiến lược phục hồi.

{
"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 cho coordinator mọi thứ cần để quyết định: retry cùng truy vấn, thử hướng khác, đi tiếp với partial result, hay escalate.

Đề thi hỏi thẳng hai thứ này. Cả hai đều tai hại, theo hai kiểu khác nhau:

Silent suppression: trả về kết quả rỗng và đánh dấu là thành công. Đây là anti-pattern tệ nhất. Subagent gặp timeout nhưng trả về { "results": [], "status": "success" }. Coordinator tin rằng đã tìm kiếm và không thấy gì. Nó sẽ không retry, không thử hướng khác, và cho ra bản tổng hợp âm thầm bỏ trống cả một mảng nghiên cứu. Output cuối trông vẫn đầy đủ. Nhưng nó thiếu nội dung quan trọng.

Silent suppression đặc biệt nguy hiểm vì nó vô hình. Output trông đúng — chỉ là có những lỗ hổng không ai phát hiện được. Trong bối cảnh hỗ trợ khách hàng, nó có thể khiến agent báo “không tìm thấy đơn hàng nào” trong khi thực ra hệ thống tra cứu đơn đang chết, dẫn tới việc agent nói với khách là họ không có tài khoản.

Workflow termination: giết cả pipeline chỉ vì một lỗi. Một subagent timeout và cả pipeline nghiên cứu sập. Bốn subagent còn lại đã chạy xong nhưng kết quả bị vứt hết. Đây là phản ứng không tương xứng, phí công đã làm và không để lại đường phục hồi nào.

Điểm cân bằng đúng là structured error propagation: subagent hỏng báo cáo chuyện gì đã xảy ra, coordinator đánh giá mức thiệt hại, và hệ thống đi tiếp với partial result hoặc phục hồi có trọng điểm.

Phân biệt này rất quan trọng và đề thi hỏi trực tiếp:

Access failure: tool không tiếp cận được nguồn dữ liệu. Timeout, lỗi kết nối, từ chối quyền. Truy vấn chưa hề chạy. Cần cân nhắc retry với tham số cũ hoặc đã chỉnh.

Valid empty result: tool tiếp cận được nguồn và đã chạy truy vấn. Nó không tìm thấy kết quả nào khớp. Đó CHÍNH LÀ câu trả lời. Không cần retry vì hệ thống đã chạy đúng — đơn giản là không có kết quả nào cho truy vấn này.

Lẫn lộn hai thứ này dẫn tới hai vấn đề:

  • Coi access failure là valid empty result nghĩa là bạn không bao giờ retry lúc đáng lẽ phải retry.
  • Coi valid empty result là access failure nghĩa là bạn phí thời gian retry một truy vấn mà lần nào cũng sẽ rỗng.
# 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
}

Khi synthesis agent gộp findings từ nhiều subagent, output nên ghi rõ mảng chủ đề nào có đủ dữ liệu và mảng nào còn lỗ hổng. Nếu một subagent không lấy được nguồn về địa nhiệt, bản tổng hợp nên nói:

“Section on geothermal energy is limited due to unavailable journal access during research.”

Cách này tốt hơn hẳn việc âm thầm bỏ qua chủ đề. Coverage annotation cho người đọc biết báo cáo bao phủ đầy đủ chỗ nào và hạn chế nằm ở đâu. Không có nó, một lỗ hổng trong bản tổng hợp trông như thể chủ đề đó không liên quan, chứ không phải nguồn không truy cập được.

Subagent nên tự phục hồi tại chỗ với lỗi transient — retry, nguồn dự phòng, phản hồi suy giảm — trước khi đẩy lỗi lên coordinator. Chỉ propagate những lỗi subagent không tự giải quyết được. Khi propagate, luôn kèm theo đã thử gì và mọi partial result đã thu được.

Cách này giảm độ phức tạp cho coordinator. Coordinator không cần quản lý logic retry cho mọi lỗi transient khả dĩ của mọi subagent. Mỗi subagent tự lo lỗi transient của mình và chỉ đẩy lên những lỗi dai dẳng.

Một web search subagent trong hệ thống nghiên cứu multi-agent bị timeout khi tìm hiểu một chủ đề phức tạp. Bạn cần thiết kế cách thông tin sự cố này chảy về coordinator. Hướng nào giúp phục hồi thông minh nhất?

  • A. Trả về structured error context gồm loại sự cố, truy vấn đã thử, partial result và các hướng thay thế khả dĩ
  • B. Cài retry tự động với exponential backoff, chỉ trả về trạng thái chung chung ‘search unavailable’ sau khi hết lượt retry
  • C. Bắt timeout rồi trả về tập kết quả rỗng gắn nhãn thành công, để phần còn lại của workflow cứ chạy tiếp bất kể sự cố
  • D. Đẩy exception timeout lên handler cấp cao nhất để chấm dứt toàn bộ workflow nghiên cứu ngay, vứt bỏ mọi thứ
Đáp án & giải thích

Đúng: A

  • A — Cho coordinator mọi thứ cần để quyết định: retry với truy vấn đã chỉnh, thử hướng khác, hay đi tiếp với partial result.
  • B — Trạng thái chung chung giấu mất bối cảnh giá trị khỏi coordinator, chặn việc ra quyết định phục hồi có căn cứ ngay cả sau khi retry thất bại.
  • C — Silent suppression chặn mọi phục hồi. Coordinator tin rằng tìm kiếm thành công và không thấy gì, nên sẽ không thử phương án khác.
  • D — Workflow termination vứt bỏ partial result của các subagent khác có thể đã chạy xong.

Năm câu trắc nghiệm theo format đề thi về Error Propagation in Multi-Agent Systems. Chọn đáp án trước, rồi mở phần giải thích.

Một web search subagent trong hệ thống nghiên cứu multi-agent bị timeout khi tìm hiểu một chủ đề. Bạn cần thiết kế cách thông tin sự cố này chảy về coordinator. Hướng nào giúp phục hồi thông minh nhất?

  • A. Đẩy exception timeout lên handler cấp cao nhất để chấm dứt toàn bộ workflow nghiên cứu
  • B. Cài retry tự động với exponential backoff, chỉ trả về trạng thái chung chung ‘search unavailable’ sau khi hết lượt retry
  • C. Bắt timeout rồi trả về tập kết quả rỗng gắn nhãn thành công
  • D. Trả về structured error context gồm loại sự cố, truy vấn đã thử, partial result và các hướng thay thế khả dĩ
Đáp án & giải thích

Đúng: D

  • A sai vì: workflow termination vứt bỏ partial result của các subagent khác đã chạy xong.
  • B sai vì: ‘search unavailable’ chung chung giấu mất truy vấn, partial result và phương án thay thế khỏi coordinator, chặn phục hồi có căn cứ ngay cả sau khi retry thất bại.
  • C sai vì: đây là silent suppression — anti-pattern tệ nhất. Coordinator tin rằng tìm kiếm thành công và không thấy gì, nên sẽ không bao giờ thử phương án khác.
  • D đúng vì: structured error context cho coordinator mọi thứ cần: loại sự cố (transient), đã thử gì, partial result thu được, và các hướng có thể thử tiếp.

Một subagent tra database tìm đơn hàng của khách và trả về không kết quả nào. Code của subagent bắt mọi exception và trả về {results: [], status: ‘success’}. Thực tế database đang chập chờn kết nối. Kiểu hỏng này gọi là gì?

  • A. Graceful degradation
  • B. Silent suppression
  • C. Workflow termination
  • D. Defensive programming
Đáp án & giải thích

Đúng: B

  • A sai vì: graceful degradation là cung cấp chức năng thu hẹp nhưng vẫn thừa nhận giới hạn. Ở đây sự cố bị giấu hoàn toàn.
  • B đúng vì: silent suppression — trả về kết quả rỗng gắn nhãn thành công trong khi thao tác thực sự đã hỏng. Coordinator không thể phục hồi vì nó tin rằng tìm kiếm đã thành công.
  • C sai vì: workflow termination sẽ làm sập cả pipeline. Silent suppression vẫn chạy tiếp nhưng để lại lỗ hổng vô hình.
  • D sai vì: defensive programming phải có xử lý lỗi đàng hoàng. Che sự cố thành thành công là ngược lại hoàn toàn.

Một pipeline nghiên cứu có 5 subagent. Subagent thứ 3 hỏng vì timeout. Hệ thống chấm dứt toàn bộ pipeline. Cái giá chính của cách làm này là gì?

  • A. Timeout sẽ không được ghi log để debug
  • B. Người dùng sẽ nhận một thông báo lỗi vô ích
  • C. Partial result từ 4 subagent đã chạy xong bị mất
  • D. Subagent hỏng không thể khởi động lại độc lập
Đáp án & giải thích

Đúng: C

  • A sai vì: logging là chuyện riêng. Pipeline vẫn ghi log được dù có chấm dứt hay không.
  • B sai vì: thông báo lỗi tuỳ chỉnh được, bất kể chiến lược chấm dứt ra sao.
  • C đúng vì: workflow termination phí công đã làm. 4 subagent kia có thể đã cho ra partial result giá trị dùng được cho bản tổng hợp.
  • D sai vì: khởi động lại độc lập là khả thi khi có structured error propagation, nhưng đó là giải pháp chứ không phải cái giá của việc chấm dứt.

Một subagent tra một academic database và trả về không kết quả nào. Coordinator có nên retry lần tìm kiếm này không?

  • A. Còn tuỳ: không khớp gì thì khỏi retry, kết nối hỏng thì có
  • B. Có, luôn retry các lần tìm kiếm ra kết quả rỗng phòng khi kết nối chập chờn
  • C. Không, kết quả rỗng nghĩa là dữ liệu không tồn tại, retry chỉ phí thời gian
  • D. Có, nhưng chỉ với tham số tìm kiếm đã chỉnh để nới rộng truy vấn
Đáp án & giải thích

Đúng: A

  • A đúng vì: điểm phân biệt then chốt là access failure vs valid empty result. Access failure (không tiếp cận được nguồn) thì đáng retry. Valid empty result (tiếp cận được, không khớp gì) CHÍNH LÀ câu trả lời.
  • B sai vì: nếu truy vấn đã chạy thành công và thực sự không khớp gì, retry chỉ phí thời gian cho một truy vấn lần nào cũng rỗng.
  • C sai vì: kết quả rỗng do kết nối hỏng không giống kết quả rỗng từ một truy vấn thành công. Coordinator cần biết đó là trường hợp nào.
  • D sai vì: nới rộng truy vấn có thể hợp lý với access failure, nhưng nếu truy vấn gốc đã chạy và không thấy gì thì kết quả đó là hợp lệ.

Một synthesis agent gộp findings từ ba research subagent. Một subagent không lấy được bài báo khoa học về địa nhiệt. Báo cáo tổng hợp bao phủ kỹ điện mặt trời và điện gió nhưng không nhắc gì tới địa nhiệt. Cách làm đúng là gì?

  • A. Báo cáo như vậy là chấp nhận được — dữ liệu không có thì loại chủ đề đó ra
  • B. Hoãn báo cáo cho tới khi hoàn tất phần nghiên cứu địa nhiệt
  • C. Thêm coverage annotation ghi rõ phần địa nhiệt ở đây bị hạn chế
  • D. Ước lượng kết quả địa nhiệt dựa trên dữ liệu điện mặt trời và điện gió như một proxy hợp lý
Đáp án & giải thích

Đúng: C

  • A sai vì: âm thầm bỏ chủ đề làm lỗ hổng trở nên vô hình. Người đọc sẽ tưởng địa nhiệt không liên quan, chứ không biết là nguồn không truy cập được.
  • B sai vì: hoãn cả báo cáo vì một phần hỏng là không tương xứng, giống anti-pattern workflow termination.
  • C đúng vì: coverage annotation ghi rõ mảng nào còn lỗ hổng và vì sao. Sự minh bạch đó cho người đọc biết báo cáo bao phủ đầy đủ chỗ nào và hạn chế nằm ở đâu.
  • D sai vì: bịa findings dựa trên dữ liệu proxy tạo ra nội dung không đáng tin. Cách đúng là minh bạch về lỗ hổng.