हे कसे दुर्लक्षित राहते
Build अयशस्वी होते. एजंट पुन्हा प्रयत्न करतो. पुन्हा अयशस्वी होतो. प्रत्येक retry अधिक output जोडतो, पण मूळ समस्या अजूनही आहे. जर तुम्ही फक्त सेशन सक्रिय आहे का ते तपासत असाल, तर वारंवार होणारी failure चुकू शकते.
एजंट बदल तयार करत असताना shell tool वारंवार error परत करत आहे अशी कल्पना करा. कारण missing dependency, invalid command किंवा अनुपलब्ध access असू शकते. उपयुक्त प्रश्न हा आहे की कोणता tool वारंवार अयशस्वी होत आहे, आणि किती वेळा.
ClawMetry काय ओळखते
ClawMetry event window मध्ये एकाच tool ला attributed errors मोजते. Count लागू उंबरठ्याहून जास्त झाल्यावर repeated tool failure warning उठवते. Finding मध्ये tool चे नाव, failure count आणि वापरलेला उंबरठा असतो.
Finding बदलवणारा फरक
Trigger करणारे उदाहरण
Bash कडून 4 errors
Warning finding
शांत तुलना
Bash कडून 1 error
या detector साठी कोणतेही finding नाही.
तपासलेल्या उदाहरणात, चार अयशस्वी shell results warning देतात. एकच failure उंबरठ्याखाली राहते. हे identical-call loop पेक्षा वेगळे आहे: commands बदलू शकतात तर तोच tool errors परत करत राहतो.
Detector result तपासा
{
"kind": "repeated_tool_failure",
"severity": "warning",
"evidence": {
"tool": "Bash",
"failures": 4,
"threshold": 3,
"threshold_source": "static"
}
}उदाहरण कसे तपासले गेले
ही उदाहरणे लेखी event data किंवा disposable configuration files सह प्रकाशित detector चे मूल्यांकन करतात. व्हिडिओ त्या वर्तनांचे उदाहरण देतात. ते live एजंट्स किंवा product interface चे रेकॉर्डिंग नाहीत. उदाहरणांमधील कोणताही command execute केला गेला नाही.
परिणाम या inputs साठी वर्तन स्थापित करतो. तो runtime ingestion, प्रतिबंध किंवा खरी तडजोड स्थापित करत नाही. Pinned source contract तपासा.
पुढे काय तपासायचे
अयशस्वी results उघडा आणि समान कारण शोधा. Environment किंवा access समस्या दुरुस्त करा, किंवा retries जमा होऊ देण्यापूर्वी एजंट टास्क संकुचित करा. नंतर पुढील tool result प्रत्यक्षात यशस्वी होतो का ते सत्यापित करा.
- Error results वाचा
- समान कारण दुरुस्त करा
- पुढील परिणाम सत्यापित करा
हा signal काय स्थापित करतो
हा reliability signal आहे. तो मूळ कारण निदान करत नाही किंवा एजंटवर हल्ला होत आहे हे सिद्ध करत नाही.