Bước thất bại. Agent tiếp tục.

Tại sao dễ bị bỏ qua

Build thất bại, nhưng agent đã chuyển sang viết tóm tắt. Nó có phục hồi không, hay một lỗi quan trọng đã biến mất giữa hai bước? Hành động tiếp theo thường là nơi nên bắt đầu xem xét hữu ích.

Trong một phiên bận rộn, một lỗi có thể cuộn qua ngay trước một lần gọi công cụ khác. Agent có thể có chiến lược phục hồi hợp lệ. Hoặc nó có thể tiếp tục mà không xử lý lỗi. Dù thế nào, bạn cần chuỗi xung quanh để quyết định.

ClawMetry phát hiện gì

ClawMetry gắn cờ kết quả công cụ thất bại được tiếp nối bởi hoạt động tiếp tục mà không có lần thử lại hay xác nhận được nhận diện. Nó tạo ra kết quả phát hiện sai lệch hành động thông tin. Mức độ nghiêm trọng thấp hơn đó quan trọng: đây là lời nhắc để kiểm tra quá trình chuyển đổi, không phải phán quyết về ý định của agent.

Sự khác biệt thay đổi kết quả phát hiện

Ví dụ được kiểm tra thất bại một shell build rồi gọi một công cụ khác. Nó phát ra một kết quả phát hiện thông tin. Một thất bại được tiếp nối bởi lần gọi khác đến cùng công cụ được coi là thử lại và im lặng với detector này.

{
  "kind": "action_discrepancy",
  "severity": "info",
  "evidence": {
    "failed_tool": "Bash",
    "continued_as": "tool_call"
  }
}

Những gì cần kiểm tra tiếp theo

So sánh bước thất bại với những gì theo sau. Hành động mới có phải là đường phục hồi không? Lỗi có được xác nhận ở nơi khác không? Trước khi dựa vào báo cáo hoàn thành, hãy xác minh kết quả cơ bản mà thao tác thất bại được cho là tạo ra.

1. Kiểm tra kết quả thất bại
2. Kiểm tra đường phục hồi
3. Xác minh kết quả được tuyên bố