یہ کیسے نظرانداز ہو جاتا ہے
build ناکام ہوتی ہے۔ ایجنٹ دوبارہ کوشش کرتا ہے۔ پھر ناکام ہوتی ہے۔ ہر retry مزید output شامل کرتی ہے، لیکن بنیادی مسئلہ موجود ہے۔ اگر آپ صرف دیکھتے ہیں کہ سیشن فعال ہے یا نہیں، تو بار بار دہرائی جانے والی ناکامی چھوٹ سکتی ہے۔
ایک ایجنٹ کا تصور کریں جو تبدیلی تیار کرتے ہوئے shell tool سے بار بار error لے رہا ہے۔ وجہ کوئی غائب dependency، غلط command یا ناقابل رسائی access ہو سکتی ہے۔ مفید سوال یہ ہے کہ کون سا tool بار بار ناکام ہو رہا ہے، اور کتنی بار۔
ClawMetry کیا detect کرتا ہے
ClawMetry event window میں ایک ہی tool سے منسوب errors گنتا ہے۔ جب تعداد متعلقہ حد سے گزرے، یہ repeated tool failure وارننگ جاری کرتا ہے۔ finding میں tool، ناکامی کی تعداد اور استعمال شدہ حد درج ہوتی ہے۔
وہ فرق جو finding بدل دیتا ہے
trigger کرنے والی مثال
Bash سے 4 errors
وارننگ finding
خاموش موازنہ
Bash سے 1 error
اس detector کے لیے کوئی finding نہیں۔
جانچی گئی مثال میں، چار ناکام shell نتائج وارننگ پیدا کرتے ہیں۔ ایک ناکامی حد سے نیچے رہتی ہے۔ یہ identical-call loop سے مختلف ہے: commands بدل سکتے ہیں جبکہ ایک ہی tool errors دیتا رہتا ہے۔
detector نتیجہ جانچیں
{
"kind": "repeated_tool_failure",
"severity": "warning",
"evidence": {
"tool": "Bash",
"failures": 4,
"threshold": 3,
"threshold_source": "static"
}
}مثال کو کیسے جانچا گیا
یہ مثالیں تیار کردہ event data یا قابل استعمال configuration files کے ساتھ شائع شدہ detector کا جائزہ لیتی ہیں۔ ویڈیوز ان رویوں کو واضح کرتی ہیں۔ یہ لائیو ایجنٹس یا پروڈکٹ interface کی ریکارڈنگ نہیں ہیں۔ مثالوں میں کوئی command execute نہیں کی گئی۔
نتیجہ ان inputs کے لیے رویہ قائم کرتا ہے۔ یہ runtime ingestion، روک تھام یا حقیقی خطرے کو ثابت نہیں کرتا۔ pinned source contract جانچیں.
آگے کیا چیک کریں
ناکام نتائج کھولیں اور مشترکہ وجہ تلاش کریں۔ ماحول یا access کا مسئلہ ٹھیک کریں، یا retries جمع ہونے سے پہلے ایجنٹ task محدود کریں۔ پھر verify کریں کہ اگلا tool نتیجہ واقعی کامیاب ہے۔
- error نتائج پڑھیں
- مشترکہ وجہ ٹھیک کریں
- اگلا نتیجہ verify کریں
یہ signal کیا ثابت کرتا ہے
یہ ایک reliability signal ہے۔ یہ بنیادی وجہ تشخیص نہیں کرتا اور نہ ہی ثابت کرتا ہے کہ ایجنٹ پر حملہ ہو رہا ہے۔