tools.loopDetection के अंतर्गत कॉन्फ़िगर किया जाता है:
- लूप पहचान (
enabled) - डिफ़ॉल्ट रूप से अक्षम। दोहराए गए पैटर्न और अज्ञात-टूल पुनः प्रयासों के लिए हालिया टूल-कॉल इतिहास पर नज़र रखती है। - Compaction के बाद का सुरक्षा-उपाय - जब भी
enabledको स्पष्ट रूप सेfalseनहीं किया गया हो, तब सक्षम रहता है। प्रत्येक Compaction-पुनः प्रयास के बाद सक्रिय होता है और यदि एजेंट समय-सीमा के भीतर उसी(tool, args, result)त्रिक को दोहराता है, तो रन को निरस्त कर देता है।
tools.loopDetection.enabled: false सेट करें।
यह क्यों मौजूद है
- ऐसे दोहराव वाले अनुक्रमों का पता लगाना, जिनसे कोई प्रगति नहीं होती।
- उच्च-आवृत्ति वाले परिणाम-विहीन लूप का पता लगाना (वही टूल, वही इनपुट, बार-बार होने वाली त्रुटियाँ)।
- ज्ञात पोलिंग टूल के लिए विशिष्ट दोहराए गए कॉल पैटर्न का पता लगाना।
- कॉन्टेक्स्ट ओवरफ़्लो -> Compaction -> वही लूप चक्रों को अनिश्चित काल तक चलने देने के बजाय तोड़ना।
कॉन्फ़िगरेशन ब्लॉक
वैश्विक सेटिंग:agents.entries.*.tools.loopDetection पर):
फ़ील्ड का व्यवहार
exec के लिए, प्रगति-रहित हैशिंग स्थिर कमांड परिणामों (स्थिति,
निकास कोड, समय-समाप्ति फ़्लैग, आउटपुट) की तुलना करती है और अवधि, PID, सत्र ID और कार्यशील निर्देशिका जैसे
परिवर्तनशील रनटाइम मेटाडेटा को अनदेखा करती है। आउटबाउंड संदेश-प्रेषण
परिणामों को प्रत्येक कॉल के परिवर्तनशील ID (संदेश ID, फ़ाइल ID, टाइमस्टैम्प)
हटाकर हैश किया जाता है, ताकि एक “भेजा गया” परिणाम किसी दूसरे “भेजा गया”
परिणाम के समान न दिखे। जब रन ID उपलब्ध हो, तो इतिहास का मूल्यांकन केवल उसी रन के भीतर किया जाता है,
ताकि निर्धारित Heartbeat चक्र और नए रन पहले के रन से पुराने लूप की संख्या
प्राप्त न करें।
अनुशंसित सेटअप
- छोटे मॉडलों के लिए,
enabled: trueसेट करें। प्रमुख मॉडलों को हालिया-इतिहास पहचान की शायद ही कभी आवश्यकता होती है और वे मुख्य स्विच कोfalseपर छोड़कर भी Compaction के बाद के सुरक्षा-उपाय का लाभ उठा सकते हैं। - Compaction के बाद के सुरक्षा-उपाय सहित सब कुछ अक्षम करने के लिए,
tools.loopDetection.enabled: falseको स्पष्ट रूप से सेट करें।
Compaction के बाद का सुरक्षा-उपाय
कॉन्टेक्स्ट ओवरफ़्लो के बाद Compaction-पुनः प्रयास होने पर, रनर अगले कुछ टूल कॉल के लिए एक छोटी समय-सीमा वाला सुरक्षा-उपाय सक्रिय करता है। यदि एजेंट उस समय-सीमा के भीतर एक ही(toolName, argsHash, resultHash) त्रिक को पर्याप्त बार उत्पन्न करता है, तो सुरक्षा-उपाय यह निष्कर्ष निकालता है कि Compaction ने
लूप को नहीं तोड़ा और compaction_loop_persisted त्रुटि के साथ रन को निरस्त कर देता है।
सुरक्षा-उपाय मुख्य tools.loopDetection.enabled फ़्लैग द्वारा नियंत्रित होता है, लेकिन इसमें एक
विशेषता है: फ़्लैग सेट न होने या true होने पर यह सक्षम रहता है, और केवल तब
बंद होता है, जब फ़्लैग को स्पष्ट रूप से false किया गया हो। यह जानबूझकर किया गया है - यह सुरक्षा-उपाय
उन Compaction लूप से बाहर निकलने के लिए मौजूद है, जो अन्यथा असीमित टोकन खर्च करते रहते,
इसलिए बिना कॉन्फ़िगरेशन वाले उपयोगकर्ता को भी सुरक्षा मिलती है।
- परिणाम बदलते रहने पर सुरक्षा-उपाय कभी रन निरस्त नहीं करता; समय-सीमा में केवल बाइट-दर-बाइट समान परिणाम ही इसे ट्रिगर करते हैं।
- यह केवल Compaction-पुनः प्रयास के तुरंत बाद सक्रिय होता है, रन के अन्य बिंदुओं पर नहीं।
जब भी मुख्य फ़्लैग स्पष्ट रूप से
false नहीं होता, तब Compaction के बाद का सुरक्षा-उपाय चलता है, भले ही आपने कभी tools.loopDetection ब्लॉक न लिखा हो। सत्यापित करने के लिए, Compaction घटना के तुरंत बाद Gateway लॉग में post-compaction guard armed for N attempts खोजें।लॉग और अपेक्षित व्यवहार
जब किसी लूप का पता चलता है, तो OpenClaw एक लूप घटना लॉग करता है और गंभीरता के आधार पर अगले टूल चक्र के लिए चेतावनी देता है या उसे अवरुद्ध करता है, जिससे सामान्य टूल पहुँच बनाए रखते हुए टोकन के अनियंत्रित खर्च और अवरोधों से सुरक्षा मिलती है।- चेतावनियाँ पहले आती हैं।
- जब कोई पैटर्न चेतावनी सीमा के बाद भी बना रहता है, तो अवरोधन होता है।
- गंभीर सीमाएँ अगले टूल चक्र को अवरुद्ध करती हैं और रन रिकॉर्ड में लूप पहचान का स्पष्ट कारण दिखाती हैं।
- Compaction के बाद का सुरक्षा-उपाय आपत्तिजनक टूल और समान कॉल की संख्या बताते हुए
compaction_loop_persistedत्रुटियाँ उत्पन्न करता है।
संबंधित
निष्पादन स्वीकृतियाँ
शेल निष्पादन के लिए अनुमति/अस्वीकृति नीति।
चिंतन स्तर
तर्क प्रयास के स्तर और प्रदाता-नीति की परस्पर क्रिया।
उप-एजेंट
अनियंत्रित व्यवहार को सीमित करने के लिए पृथक एजेंट उत्पन्न करना।
कॉन्फ़िगरेशन संदर्भ
संपूर्ण
tools.loopDetection स्कीमा और विलय की अर्थवत्ता।