Phản Hồi Lỗi Có Cấu Trúc

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

Khi một MCP tool thất bại, phản hồi lỗi mà nó trả về quyết định liệu agent có thể phục hồi một cách thông minh hay chỉ hành động mù quáng. Các thông báo lỗi chung chung như "Operation failed" (Thao tác thất bại) vô dụng đối với một LLM — chúng không cung cấp tín hiệu nào về việc đã xảy ra chuyện gì, có nên thử lại hay không, hay nên đi theo hướng thay thế nào.

MCP protocol cung cấp cờ isError dành riêng cho việc báo lỗi tool về cho agent. Việc đặt cờ này báo cho model biết rằng việc thực thi tool đã thất bại, cho phép nó suy luận về cách phục hồi thay vì coi văn bản lỗi như một kết quả thành công bình thường.

Bốn Loại Lỗi

Mọi lỗi tool đều rơi vào một trong bốn loại. Mỗi loại đòi hỏi một chiến lược phục hồi khác nhau, và agent cần metadata có cấu trúc để phân biệt chúng.

1. Lỗi tạm thời (Transient Errors) Timeout, dịch vụ không khả dụng, giới hạn tốc độ (rate limit). Hệ thống bên dưới tạm thời không thể truy cập được nhưng bản thân yêu cầu là hợp lệ. Cách phục hồi: thử lại sau một khoảng chờ ngắn.

jsonCopy

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "Service temporarily unavailable"
  }],
  "errorCategory": "transient",
  "isRetryable": true,
  "description": "The order database is experiencing high load. The request is valid and should succeed on retry."
}

2. Lỗi xác thực (Validation Errors) Định dạng đầu vào không hợp lệ, thiếu trường bắt buộc, giá trị nằm ngoài phạm vi cho phép. Bản thân yêu cầu bị sai định dạng. Cách phục hồi: sửa đầu vào rồi thử lại.

jsonCopy

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "Invalid order ID format"
  }],
  "errorCategory": "validation",
  "isRetryable": true,
  "description": "Order ID must be in format #NNNNN (e.g. #12345). Received: 'order-abc'. Please reformat and retry."
}

3. Lỗi nghiệp vụ (Business Errors) Vi phạm chính sách, vượt giới hạn, xung đột quy tắc nghiệp vụ. Yêu cầu về mặt kỹ thuật là hợp lệ nhưng vi phạm một ràng buộc nghiệp vụ. Cách phục hồi: KHÔNG thử lại — cùng một yêu cầu sẽ luôn thất bại. Agent cần một quy trình làm việc thay thế.

jsonCopy

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "Refund exceeds policy limit"
  }],
  "errorCategory": "business",
  "isRetryable": false,
  "description": "Refund amount of £750 exceeds the £500 automatic refund limit. This requires manager approval. Please escalate to a human agent with the refund details."
}

Lưu ý cờ isRetryable: false. Điều này rất quan trọng. Lỗi nghiệp vụ không bao giờ được giải quyết bằng cách thử lại. Agent phải đi theo một hướng hoàn toàn khác — thường là leo thang (escalation) hoặc một quy trình làm việc thay thế. Việc bao gồm một lời giải thích thân thiện với khách hàng giúp agent giao tiếp phù hợp.

4. Lỗi quyền truy cập (Permission Errors) Truy cập bị từ chối, thiếu thông tin xác thực, thất bại về ủy quyền. Tool không thể thực thi vì bên gọi thiếu quyền cần thiết. Cách phục hồi: leo thang hoặc sử dụng thông tin xác thực khác.

jsonCopy

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "Access denied"
  }],
  "errorCategory": "permission",
  "isRetryable": false,
  "description": "The current service account does not have permission to access financial records. Escalate to a senior agent with financial system access."
}

isRetryable Thực Sự Báo Hiệu Điều Gì

isRetryable trả lời một câu hỏi: có con đường nào dẫn đến thành công thông qua việc thử lại hay không? Nó không hứa hẹn rằng cùng một yêu cầu sẽ thành công mà không thay đổi gì. Hai loại lỗi cùng có isRetryable: true nhưng cần cách phục hồi khác nhau. Một lỗi tạm thời được thử lại y nguyên một khi hệ thống phục hồi. Một lỗi xác thực chỉ được thử lại sau khi agent sửa đầu vào, định dạng lại order-abc thành #12345. Lỗi nghiệp vụ và lỗi quyền truy cập có isRetryable: false vì lý do ngược lại: không việc thử lại nào có ích. Một quy tắc nghiệp vụ chặn đứng yêu cầu, và một lỗi quyền truy cập cần một chủ thể khác, một tài khoản có quyền truy cập phù hợp, chứ không phải một lệnh gọi được viết lại. Hãy đọc cờ này như "một lần thử lại có thể có tác dụng hay không", sau đó đọc errorCategory để biết cách: gửi lại, tự sửa, leo thang, hay đi theo hướng thay thế.

Lỗi Truy Cập So Với Kết Quả Rỗng Hợp Lệ

Sự phân biệt này là một trong những khái niệm quan trọng nhất trong toàn bộ lĩnh vực này, và kỳ thi kiểm tra nó trực tiếp.

Lỗi truy cập: Tool không thể tiếp cận nguồn dữ liệu. Đã xảy ra timeout, xác thực thất bại, hoặc dịch vụ bị gián đoạn. Dữ liệu có thể tồn tại, nhưng tool không thể kiểm tra được. Agent cần quyết định liệu có nên thử lại hay không.

Kết quả rỗng hợp lệ: Tool đã truy vấn thành công nguồn dữ liệu và không tìm thấy kết quả khớp. Truy vấn đã thực thi đúng — đơn giản là không có dữ liệu nào khớp với tiêu chí. Agent KHÔNG nên thử lại. Câu trả lời là "không tìm thấy kết quả nào."

Nhầm lẫn hai điều này phá vỡ hoàn toàn logic phục hồi. Hãy xem xét tình huống này:

Một tool trả về một mảng rỗng sau khi tra cứu khách hàng. Agent thử lại 3 lần, sau đó leo thang lên con người. Phân tích cho thấy tài khoản của khách hàng đơn giản là không tồn tại.

Tool đã thành công. Nó đã truy vấn cơ sở dữ liệu, không tìm thấy khách hàng khớp, và trả về đúng một kết quả rỗng. Nhưng vì phản hồi không phân biệt giữa "tôi không thể tiếp cận cơ sở dữ liệu" và "tôi đã tiếp cận cơ sở dữ liệu và không tìm thấy gì", agent xử lý cả hai theo cùng một cách — như một thất bại đáng để thử lại.

Cách khắc phục: hãy cấu trúc các phản hồi tool của bạn sao cho một truy vấn thành công không có kết quả trông khác biệt về căn bản so với một truy vấn thất bại.

jsonCopy

// Valid empty result — NOT an error
{
  "isError": false,
  "content": [{
    "type": "text",
    "text": "No customer found matching email 'john@example.com'. The query executed successfully but returned no matches."
  }],
  "resultCount": 0
}
 
// Access failure — IS an error
{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "Could not reach customer database"
  }],
  "errorCategory": "transient",
  "isRetryable": true,
  "description": "Connection to the customer database timed out after 5 seconds. The query did not execute."
}

Lan Truyền Lỗi Trong Hệ Thống Đa Agent

Trong các kiến trúc đa agent, việc xử lý lỗi tuân theo nguyên tắc phục hồi cục bộ với lan truyền có chọn lọc:

1. Subagent triển khai phục hồi cục bộ cho các thất bại tạm thời. Nếu một tìm kiếm web bị timeout, subagent tìm kiếm thử lại trước khi làm phiền coordinator.
2. Chỉ lan truyền các lỗi không thể giải quyết cục bộ. Nếu tất cả các lần thử lại đều thất bại, subagent báo cáo thất bại lên trên.
3. Bao gồm kết quả một phần và những gì đã được thử. Coordinator cần ngữ cảnh: "Tôi đã tìm kiếm thành công 3 trong số 5 nguồn. Nguồn 4 và 5 bị timeout. Đây là kết quả một phần từ 3 nguồn thành công."

Điều này ngăn chặn hai anti-pattern: âm thầm che giấu lỗi (trả về kết quả rỗng như thể là thành công) và chấm dứt toàn bộ quy trình làm việc chỉ vì một thất bại duy nhất. Cả hai đều phá hủy khả năng của coordinator trong việc đưa ra các quyết định thông minh.

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-2-2-001".

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

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.2 — Anthropic
• MCP Specification — Tool Results — Model Context Protocol
• Building Effective Agents — Anthropic — Anthropic