Detector libraryRepeated tool failure

Repeated tool failure

वही tool। एक और विफलता।

वह विफल चरण खोजें जिसे retries दबाती रहती हैं।

समस्या देखें। finding समझें।

अंग्रेज़ी नैरेशन, कैप्शन सहित।

यह कैसे नज़रअंदाज़ हो जाता है

Build विफल होती है। एजेंट फिर कोशिश करता है। फिर विफल होती है। हर retry में अधिक output आता है, लेकिन मूल समस्या अभी भी वहीं है। अगर आप केवल यह देखें कि सेशन active है, तो बार-बार दोहराई जाने वाली विफलता छूट सकती है।

मान लें एक एजेंट change तैयार कर रहा है जबकि उसका shell tool बार-बार error लौटा रहा है। कारण कोई missing dependency, invalid command या अनुपलब्ध access हो सकता है। उपयोगी सवाल यह है कि कौन सा tool बार-बार विफल हो रहा है, और कितनी बार।

ClawMetry क्या डिटेक्ट करता है

ClawMetry event window में एक ही tool को attributed errors गिनता है। जब count applicable threshold पार करे, तो repeated tool failure warning उठाता है। Finding में tool का नाम, failure count और उपयोग किया गया threshold शामिल है।

वह अंतर जो finding बदल देता है

Trigger करने वाला उदाहरण

Bash से 4 errors

Warning finding

शांत तुलना

Bash से 1 error

इस detector के लिए कोई finding नहीं।

जांचे गए उदाहरण में चार विफल shell results warning उत्पन्न करते हैं। एकल विफलता threshold से नीचे रहती है। यह identical-call loop से अलग है: commands बदल सकते हैं जबकि वही tool errors लौटाता रहे।

Detector result की जांच करें
{
  "kind": "repeated_tool_failure",
  "severity": "warning",
  "evidence": {
    "tool": "Bash",
    "failures": 4,
    "threshold": 3,
    "threshold_source": "static"
  }
}
Inputs और पूरे results डाउनलोड करें (JSON)
उदाहरण कैसे जांचा गया

ये उदाहरण published detector को authored event data या disposable configuration files के साथ evaluate करते हैं। वीडियो उन behaviors को दर्शाते हैं। ये live agents या product interface की recordings नहीं हैं। उदाहरणों में कोई command execute नहीं किया गया।

परिणाम इन inputs के लिए व्यवहार स्थापित करता है। यह runtime ingestion, prevention या वास्तविक compromise स्थापित नहीं करता। Pinned source contract की जांच करें.

आगे क्या जांचें

विफल results खोलें और साझा कारण खोजें। Environment या access समस्या ठीक करें, या retries जमा होने से पहले एजेंट टास्क सीमित करें। फिर verify करें कि अगला tool result वास्तव में सफल होता है।

  1. Error results पढ़ें
  2. साझा कारण ठीक करें
  3. अगला परिणाम verify करें

यह signal क्या स्थापित करता है

यह एक reliability signal है। यह root cause diagnose नहीं करता और न ही यह साबित करता है कि एजेंट पर हमला हो रहा है।

महत्वपूर्ण क्षण दिखते रहें।

एजेंट गतिविधि फॉलो करें, findings जांचें और तय करें कि किस पर ध्यान देना है।