बातचीत के बीच याद रखना
व्यक्तिगत या पूर्णतः विश्वसनीय एजेंट के लिए, उसकी अन्य निजी बातचीत में सीमित रिकॉल को प्रति-एजेंट एक सेटिंग से सक्षम करें:session.dmScope अनसेट या
"main" होना चाहिए, और कोई भी बाइंडिंग session.dmScope को ओवरराइड नहीं कर सकती। कॉन्फ़िगर किया गया कोई भी
DM पृथक्करण इसे डिफ़ॉल्ट रूप से बंद कर देता है। स्पष्ट true या false हमेशा प्रभावी होता है। सक्षम होने पर,
OpenClaw उस एजेंट के सत्र ट्रांसक्रिप्ट इंडेक्स करता है और योग्य निजी उत्तरों से पहले Active
Memory पुनर्प्राप्ति पास चलाता है। यह पास
उसी एजेंट की अन्य निजी बातचीत से प्रासंगिक ट्रांसक्रिप्ट अंश पढ़ सकता है।
जिस बातचीत का पहले से उत्तर दिया जा रहा है, उसे इसमें शामिल नहीं किया जाता।
गोपनीयता सीमा निश्चित है:
- निजी प्रत्यक्ष और स्थायी स्पष्ट UI बातचीत एक-दूसरे को याद कर सकती हैं
- समूह और चैनल न तो रिकॉल स्रोत हैं, न ही रिकॉल गंतव्य
- किसी अन्य एजेंट के ट्रांसक्रिप्ट कभी योग्य नहीं होते
- पर्याप्त बातचीत मेटाडेटा के बिना अज्ञात या संग्रहीत ट्रांसक्रिप्ट अस्वीकार कर दिए जाते हैं
tools.sessions.visibility को विस्तृत नहीं करता, या व्यापक sessions_* टूल एक्सेस प्रदान नहीं करता। साझा
वर्कस्पेस मेमोरी (MEMORY.md और memory/*.md) अपना मौजूदा व्यवहार बनाए रखती है।
Active Memory सक्षम रहना आवश्यक है। पुनर्प्राप्ति योग्य उत्तरों में एक सीमित अवरोधक चरण जोड़ती है;
टाइमआउट, अनुपलब्ध खोज और खाली परिणाम—सभी स्थितियों में उत्तर
याद किए गए ट्रांसक्रिप्ट संदर्भ के बिना जारी रहता है। OpenClaw का अंतर्निहित मेमोरी
प्रदाता builtin और QMD दोनों बैकएंड के साथ इस संरक्षित ट्रांसक्रिप्ट-रिकॉल पथ का
समर्थन करता है। अन्य मेमोरी प्रदाता अपना रिकॉल व्यवहार बनाए रखते हैं, लेकिन उन्हें
निजी ट्रांसक्रिप्ट प्राधिकरण स्वचालित रूप से नहीं मिलता। openclaw doctor
असमर्थित प्रदाता या अनुपलब्ध memory_search टूल की सूचना देता है।
उन्नत Active Memory का त्वरित आरंभ
उन्नत सुरक्षित डिफ़ॉल्ट के लिए इसेopenclaw.json में पेस्ट करें: Plugin चालू, दायरा
main तक सीमित, केवल प्रत्यक्ष-संदेश सत्र, मॉडल सत्र से इनहेरिट किया गया।
plugins.entries.* (active-memory.config सहित) पुनरारंभ की आवश्यकता न वाली
कॉन्फ़िग श्रेणी में है:
Gateway Plugin रनटाइम को स्वचालित रूप से पुनः लोड करता है और मैन्युअल पुनरारंभ की
आवश्यकता नहीं होती। फिर भी यदि आप पूर्ण पुनरारंभ बाध्य करना चाहते हैं, तो चलाएँ:
plugins.entries.active-memory.enabled: truePlugin को चालू करता हैconfig.agents: ["main"]केवलmainएजेंट को शामिल करता हैconfig.allowedChatTypes: ["direct"]इसका दायरा प्रत्यक्ष-संदेश सत्रों तक सीमित करता है (समूहों/चैनलों को स्पष्ट रूप से शामिल करें)config.model(वैकल्पिक) एक समर्पित रिकॉल मॉडल निर्धारित करता है; अनसेट होने पर वर्तमान सत्र मॉडल इनहेरिट होता हैconfig.modelFallbackका उपयोग केवल तब होता है, जब कोई स्पष्ट या इनहेरिट किया गया मॉडल रिज़ॉल्व नहीं होताconfig.fastModeमुख्य एजेंट को बदले बिना रिकॉल के लिए तेज़ मोड को वैकल्पिक रूप से ओवरराइड करता हैconfig.promptStyle: "balanced",recentमोड के लिए डिफ़ॉल्ट है- Active Memory अभी भी केवल योग्य इंटरैक्टिव स्थायी चैट सत्रों के लिए चलता है (यह कब चलता है देखें)
यह कैसे काम करता है
अवरोधक उप-एजेंट केवल कॉन्फ़िगर किए गए मेमोरी रिकॉल टूल कॉल कर सकता है ( मेमोरी टूल देखें)। यदि क्वेरी और उपलब्ध मेमोरी के बीच संबंध कमज़ोर है, तो यहNONE लौटाता है और मुख्य उत्तर
अतिरिक्त संदर्भ के बिना आगे बढ़ता है।
Active Memory एक संवादात्मक संवर्धन सुविधा है, न कि पूरे प्लेटफ़ॉर्म पर लागू
अनुमान सुविधा:
इसका उपयोग तब करें, जब सत्र स्थायी और उपयोगकर्ता-सामना वाला हो, एजेंट के पास
खोजने योग्य सार्थक दीर्घकालिक मेमोरी हो, और निरंतरता/वैयक्तिकरण
कच्ची प्रॉम्प्ट नियतता से अधिक महत्वपूर्ण हों: स्थिर प्राथमिकताएँ, बार-बार दोहराई जाने वाली आदतें,
और ऐसा दीर्घकालिक संदर्भ जिसे स्वाभाविक रूप से सामने आना चाहिए। यह
ऑटोमेशन, आंतरिक वर्कर, एकल-प्रयास API कार्यों या ऐसी किसी भी जगह के लिए उपयुक्त नहीं है
जहाँ छिपा हुआ वैयक्तिकरण आश्चर्यजनक लगे।
यह कब चलता है
Active Memory के दो सक्रियण पथ हैं:- बातचीत के बीच याद रखना उन एजेंटों को स्वचालित रूप से लक्षित करता है, जिनकी
प्रभावी
memory.search.rememberAcrossConversationsसेटिंग सक्षम है, लेकिन केवल निजी प्रत्यक्ष या स्थायी स्पष्ट UI बातचीत के लिए। - उन्नत Active Memory उन एजेंट ID को लक्षित करता है जो
plugins.entries.active-memory.config.agentsमें सूचीबद्ध हैं और Plugin के चैट प्रकार तथा चैट ID नियंत्रण लागू करता है।
/active-memory off उस
बातचीत के लिए दोनों पथों को रोक देता है। यदि कोई भी शर्त पूरी नहीं होती, तो उस चरण के लिए Active Memory
नहीं चलता और मुख्य उत्तर अप्रभावित रहता है।
सत्र प्रकार
config.allowedChatTypes नियंत्रित करता है कि किस प्रकार की बातचीत
उन्नत Active Memory पथ चला सकती है। यह बातचीत के बीच याद रखने का दायरा विस्तृत नहीं कर सकता:
उन्नत Active Memory को समूहों या चैनलों में अनुमति मिलने पर भी
यह उत्पाद सेटिंग केवल निजी रहती है। डिफ़ॉल्ट:
direct, group, channel, explicit (अपारदर्शी सत्र ID वाले पोर्टल-शैली सत्र,
उदाहरण के लिए agent:main:explicit:portal-123)।
प्रत्यक्ष-संदेश सत्र डिफ़ॉल्ट रूप से चलते हैं; समूह, चैनल और स्पष्ट सत्रों को
शामिल करना आवश्यक है:
config.allowedChatIds और config.deniedChatIds जोड़ें:
allowedChatIdsरिज़ॉल्व की गई बातचीत ID की अनुमति-सूची है। जब यह खाली न हो, तो Active Memory केवल उन सत्रों के लिए चलता है जिनकी बातचीत ID सूची में है—यह प्रत्यक्ष संदेशों सहित हर अनुमत चैट प्रकार को एक साथ सीमित करता है। केवल समूहों को सीमित रखते हुए सभी प्रत्यक्ष संदेश बनाए रखने के लिए, प्रत्यक्ष पीयर ID को भीallowedChatIdsमें जोड़ें, याallowedChatTypesको उस समूह/चैनल रोलआउट तक सीमित रखें जिसका आप परीक्षण कर रहे हैं।deniedChatIdsएक निषेध-सूची है, जो हमेशाallowedChatTypesऔरallowedChatIdsपर प्रभावी होती है।
chat_id/open_id, Telegram चैट ID, Slack चैनल ID)। मिलान
केस-असंवेदी है। यदि allowedChatIds खाली नहीं है और OpenClaw सत्र के लिए
बातचीत ID रिज़ॉल्व नहीं कर सकता, तो Active Memory अनुमान लगाने के बजाय उस चरण को
छोड़ देता है।
सत्र टॉगल
कॉन्फ़िग संपादित किए बिना वर्तमान चैट सत्र के लिए Active Memory को रोकें या फिर से शुरू करें:plugins.entries.active-memory.config.enabled, किसी एजेंट की
memory.search.rememberAcrossConversations सेटिंग या अन्य वैश्विक
कॉन्फ़िगरेशन को नहीं बदलता।
इसके बजाय सभी सत्रों के लिए रोकने/फिर से शुरू करने हेतु वैश्विक रूप का उपयोग करें (
स्वामी या operator.admin आवश्यक है):
plugins.entries.active-memory.config.enabled लिखता है, लेकिन
plugins.entries.active-memory.enabled को चालू रखता है, ताकि बाद में Active Memory को फिर से चालू करने के लिए
कमांड उपलब्ध रहे।
इसे कैसे देखें
डिफ़ॉल्ट रूप से, Active Memory एक छिपा हुआ अविश्वसनीय प्रॉम्प्ट उपसर्ग इंजेक्ट करता है, जो सामान्य उत्तर में नहीं दिखाया जाता। अपने इच्छित आउटपुट से मेल खाने वाले सत्र टॉगल चालू करें:/verbose onएक स्थिति पंक्ति जोड़ता है:🧩 Active Memory: status=ok elapsed=842ms query=recent summary=34 chars/trace onएक डीबग सारांश जोड़ता है:🔎 Active Memory Debug: Lemon pepper wings with blue cheese.
/trace raw के साथ, ट्रेस किया गया Model Input (User Role) ब्लॉक कच्चा
छिपा हुआ उपसर्ग दिखाता है:
क्वेरी मोड
config.queryMode नियंत्रित करता है कि अवरोधक उप-एजेंट कितनी बातचीत
देखता है। वह सबसे छोटा मोड चुनें जो फ़ॉलो-अप का अच्छी तरह उत्तर दे सके; संदर्भ आकार बढ़ने पर
timeoutMs को message से recent और फिर full तक बढ़ाएँ।
- संदेश
- हालिया
- पूर्ण
केवल नवीनतम उपयोगकर्ता संदेश भेजा जाता है।इसका उपयोग तब करें, जब आपको सबसे तेज़ व्यवहार, स्थिर
प्राथमिकता रिकॉल की ओर सबसे मज़बूत झुकाव चाहिए और फ़ॉलो-अप चरणों को संवादात्मक
संदर्भ की आवश्यकता न हो।
config.timeoutMs के लिए लगभग 3000-5000 ms से शुरू करें।प्रॉम्प्ट शैलियाँ
config.promptStyle नियंत्रित करता है कि सब-एजेंट स्मृति लौटाने के बारे में कितना तत्पर या सख्त है:
जब
config.promptStyle सेट न हो, तो डिफ़ॉल्ट मैपिंग:
config.promptStyle हमेशा इस मैपिंग को ओवरराइड करता है।
मॉडल फ़ॉलबैक नीति
यदिconfig.model सेट न हो, तो Active Memory इस क्रम में मॉडल निर्धारित करता है:
config.modelFallbackPolicy पुराने कॉन्फ़िगरेशन के लिए रखा गया एक अप्रचलित संगतता फ़ील्ड है;
यह अब रनटाइम व्यवहार नहीं बदलता — modelFallback ऊपर दी गई शृंखला में
सख्ती से अंतिम विकल्प है, ऐसा रनटाइम फ़ेलओवर नहीं जो निर्धारित मॉडल में त्रुटि आने पर
किसी अन्य मॉडल को प्रतिस्थापित कर दे।
गति संबंधी सुझाव
config.model को सेट न रखना (सेशन मॉडल को इनहेरिट करना) सबसे सुरक्षित
डिफ़ॉल्ट है: यह आपकी मौजूदा प्रोवाइडर, प्रमाणीकरण और मॉडल प्राथमिकताओं का अनुसरण करता है। कम
विलंबता के लिए इसके बजाय एक समर्पित तेज़ मॉडल का उपयोग करें — स्मरण की गुणवत्ता महत्वपूर्ण है,
लेकिन यहाँ मुख्य उत्तर पथ की तुलना में विलंबता अधिक महत्वपूर्ण है, और टूल
सतह सीमित है (केवल स्मृति स्मरण टूल)।
अच्छे तेज़-मॉडल विकल्प:
cerebras/gpt-oss-120b, एक समर्पित कम-विलंबता स्मरण मॉडलgoogle/gemini-3-flash, आपके प्राथमिक चैट मॉडल को बदले बिना एक कम-विलंबता फ़ॉलबैक- आपका सामान्य सेशन मॉडल,
config.modelको सेट न रखकर
Cerebras सेटअप
chat/completions पहुँच है
— केवल /v1/models दृश्यता इसकी गारंटी नहीं देती।
स्मृति टूल
config.toolsAllow उन ठोस टूल नामों को सेट करता है जिन्हें ब्लॉकिंग सब-एजेंट
उन्नत Active Memory के लिए कॉल कर सकता है। डिफ़ॉल्ट मौजूदा स्मृति प्रोवाइडर पर निर्भर करते हैं:
यदि कॉन्फ़िगर किए गए टूल में से कोई भी उपलब्ध न हो, या सब-एजेंट रन विफल हो जाए,
तो Active Memory उस टर्न के लिए स्मरण छोड़ देता है और मुख्य उत्तर
स्मृति संदर्भ के बिना जारी रहता है। कस्टम स्मरण टूल के लिए, मॉडल को दिखाई देने वाला
गैर-रिक्त टूल आउटपुट स्मरण प्रमाण माना जाता है, जब तक कि संरचित परिणाम फ़ील्ड
स्पष्ट रूप से रिक्त परिणाम या विफलता की सूचना न दें।
toolsAllow केवल ठोस स्मृति टूल नाम स्वीकार करता है: वाइल्डकार्ड, group:*
प्रविष्टियाँ और मुख्य एजेंट टूल (read, exec, message, web_search, तथा
इसी तरह के अन्य) छिपे हुए सब-एजेंट के शुरू होने से पहले चुपचाप फ़िल्टर कर दिए जाते हैं।
अंतर्निहित स्मृति
स्पष्टtoolsAllow की आवश्यकता नहीं:
LanceDB स्मृति
LanceDB को इंस्टॉल और कॉन्फ़िगर करने के बाद, Active Memory स्वचालित रूप सेmemory_recall का उपयोग करता है; स्पष्ट toolsAllow की आवश्यकता नहीं:
memory.search.rememberAcrossConversations, memory_recall के माध्यम से निजी सेशन
ट्रांसक्रिप्ट प्रदर्शित नहीं करता। जब LanceDB सक्रिय स्मृति प्रोवाइडर हो, तो LanceDB के स्वतः-स्मरण या ऊपर दिए गए उन्नत
कॉन्फ़िगरेशन का उपयोग करें।
Lossless Claw
Lossless Claw अपने स्मरण टूल वाला एक बाहरी संदर्भ-इंजन Plugin (openclaw plugins install @martian-engineering/lossless-claw) है। पहले इसे
संदर्भ इंजन के रूप में सेट अप करें; संदर्भ इंजन देखें। फिर
Active Memory को इसके टूल पर इंगित करें:
toolsAllow में lcm_expand न जोड़ें; Lossless Claw इसे
प्रत्यायोजित विस्तार के लिए निम्न-स्तरीय टूल के रूप में उपयोग करता है, जो शीर्ष-स्तरीय
Active Memory सब-एजेंट के लिए नहीं है। Lossless Claw मौजूदा स्मृति प्रोवाइडर को
बदले बिना संदर्भ संयोजन को बदलता है। rememberAcrossConversations का भी उपयोग करते समय
memory_search को toolsAllow में बनाए रखें; केवल LCM वाली टूल सूची
उन्नत Active Memory के लिए मान्य रहती है, लेकिन उत्पाद के ट्रांसक्रिप्ट-स्मरण
पथ को अक्षम कर देती है।
उन्नत वैकल्पिक उपाय
अनुशंसित सेटअप का हिस्सा नहीं हैं।config.thinking सब-एजेंट के चिंतन स्तर को ओवरराइड करता है (डिफ़ॉल्ट "off",
क्योंकि Active Memory उत्तर पथ में चलता है और अतिरिक्त चिंतन समय सीधे
उपयोगकर्ता को दिखाई देने वाली विलंबता बढ़ाता है):
config.fastMode केवल ब्लॉकिंग स्मृति सब-एजेंट के लिए तेज़ मोड को ओवरराइड करता है।
true, false, या "auto" का उपयोग करें; सामान्य
एजेंट, सेशन और मॉडल डिफ़ॉल्ट इनहेरिट करने के लिए इसे सेट न रखें। "auto" स्मरण मॉडल की कॉन्फ़िगर की गई
fastAutoOnSeconds सीमा का उपयोग करता है:
config.promptAppend डिफ़ॉल्ट प्रॉम्प्ट के बाद
और बातचीत के संदर्भ से पहले ऑपरेटर निर्देश जोड़ता है — जब किसी गैर-मुख्य स्मृति Plugin को
विशिष्ट टूल क्रम या क्वेरी संरचना की आवश्यकता हो, तो इसे कस्टम toolsAllow के साथ जोड़ें:
config.promptOverride डिफ़ॉल्ट प्रॉम्प्ट को पूरी तरह बदल देता है (बातचीत का
संदर्भ फिर भी बाद में जोड़ा जाता है)। जब तक किसी अलग स्मरण अनुबंध का जानबूझकर
परीक्षण न किया जा रहा हो, इसकी अनुशंसा नहीं की जाती — डिफ़ॉल्ट प्रॉम्प्ट को
मुख्य मॉडल के लिए या तो NONE या संक्षिप्त उपयोगकर्ता-तथ्य संदर्भ लौटाने के लिए अनुकूलित किया गया है:
ट्रांसक्रिप्ट स्थायित्व
ब्लॉकिंग सब-एजेंट रन कॉल के दौरान एक वास्तविकsession.jsonl ट्रांसक्रिप्ट बनाते हैं।
डिफ़ॉल्ट रूप से इसे एक अस्थायी डायरेक्टरी में लिखा जाता है और रन समाप्त होने के
तुरंत बाद हटा दिया जाता है।
डीबगिंग के लिए इन ट्रांसक्रिप्ट को डिस्क पर बनाए रखने हेतु:
config.transcriptDir से बदलें। इसका उपयोग
सावधानी से करें: व्यस्त सेशन में ट्रांसक्रिप्ट तेज़ी से जमा हो सकते हैं, full क्वेरी
मोड बातचीत के बहुत से संदर्भ की प्रतिलिपि बनाता है, और इन ट्रांसक्रिप्ट में
छिपा हुआ प्रॉम्प्ट संदर्भ तथा स्मरण की गई यादें होती हैं।
कॉन्फ़िगरेशन
सभी Active Memory कॉन्फ़िगरेशनplugins.entries.active-memory के अंतर्गत रहते हैं।
उपयोगी ट्यूनिंग फ़ील्ड:
अनुशंसित सेटअप
recent से शुरू करें:
/verbose on और डीबग सारांश के लिए /trace on
का उपयोग करें — दोनों मुख्य उत्तर के बाद फ़ॉलो-अप के रूप में भेजे जाते हैं,
पहले नहीं। फिर कम विलंबता के लिए message पर जाएँ, या यदि अतिरिक्त संदर्भ
धीमे उप-एजेंट रन के योग्य है, तो full पर जाएँ।
कोल्ड-स्टार्ट छूट
v2026.5.2 से पहले Plugin कोल्ड स्टार्ट के दौरानtimeoutMs को चुपचाप अतिरिक्त 30000
ms तक बढ़ा देता था, ताकि मॉडल वार्म-अप, एम्बेडिंग इंडेक्स लोड और पहला
रिकॉल एक बड़ा बजट साझा कर सकें। v2026.5.2 ने उस छूट को स्पष्ट
setupGraceTimeoutMs कॉन्फ़िगरेशन के पीछे स्थानांतरित कर दिया: जब तक आप इसे चुनकर सक्षम नहीं करते, अब डिफ़ॉल्ट रूप से timeoutMs ही रिकॉल-कार्य
बजट है। ब्लॉकिंग हुक उस बजट को
दो निश्चित चरणों में लपेटता है: रिकॉल शुरू होने से पहले सत्र/कॉन्फ़िगरेशन प्रीफ़्लाइट के लिए अधिकतम 1500 ms,
फिर रिकॉल कार्य रुकने के बाद निरस्तीकरण निपटान और ट्रांसक्रिप्ट
पुनर्प्राप्ति के लिए अलग निश्चित 1500 ms। इनमें से कोई भी छूट मॉडल या टूल
निष्पादन को नहीं बढ़ाती।
यदि आपने v2026.4.x से अपग्रेड किया है और पुराने
implicit-grace परिवेश के लिए timeoutMs को समायोजित किया था (अनुशंसित आरंभिक timeoutMs: 15000 इसका एक
उदाहरण है), तो v5.2 से पहले के प्रभावी
बजट को पुनर्स्थापित करने के लिए setupGraceTimeoutMs: 30000 सेट करें:
timeoutMs + setupGraceTimeoutMs + 3000 ms है (
कॉन्फ़िगर किया गया रिकॉल-कार्य बजट, साथ में अधिकतम 1500 ms प्रीफ़्लाइट, और एक निश्चित
1500 ms पोस्ट-रिकॉल पूर्णता भत्ता)। एम्बेडेड रिकॉल रनर
उसी प्रभावी टाइमआउट बजट का उपयोग करता है, इसलिए setupGraceTimeoutMs बाहरी
प्रॉम्प्ट-बिल्ड वॉचडॉग और आंतरिक ब्लॉकिंग रिकॉल रन, दोनों को कवर करता है।
संसाधन-सीमित gateways के लिए, जहाँ कोल्ड-स्टार्ट विलंबता एक स्वीकार्य
समझौता है, कम मान (5000-15000 ms) भी काम करते हैं — इसका समझौता यह है कि
gateway पुनः आरंभ होने के बाद सबसे पहले रिकॉल के खाली लौटने की संभावना अधिक होती है,
जबकि वार्म-अप पूरा हो रहा होता है।
डीबगिंग
यदि Active Memory वहाँ दिखाई नहीं दे रही है जहाँ आप अपेक्षा करते हैं:- पुष्टि करें कि Plugin
plugins.entries.active-memory.enabledके अंतर्गत सक्षम है। - बातचीतों के बीच Remember के लिए पुष्टि करें कि एजेंट की प्रभावी
memory.search.rememberAcrossConversationsसेटिंग सक्षम है, यह सत्यापित करने के लिएopenclaw doctorचलाएँ कि वर्तमान मेमोरी प्रदाता संरक्षित ट्रांसक्रिप्ट रिकॉल का समर्थन करता है, और स्पष्ट रूप से कॉन्फ़िगर किए जाने पर पुष्टि करें किconfig.toolsAllowमेंmemory_searchशामिल है। उन्नत Active Memory के लिए पुष्टि करें कि एजेंट IDconfig.agentsमें सूचीबद्ध है। - पुष्टि करें कि आप किसी योग्य इंटरैक्टिव स्थायी बातचीत के माध्यम से परीक्षण कर रहे हैं।
- याद रखें कि समूह और चैनल कभी भी बातचीत-पार ट्रांसक्रिप्ट रिकॉल का उपयोग नहीं करते।
config.logging: trueचालू करें और gateway लॉग देखें।- यह सत्यापित करें कि मेमोरी खोज स्वयं
openclaw status --deepके साथ काम करती है।
maxSummaryChars को अधिक सख्त करें। यदि Active Memory बहुत
धीमी है, तो queryMode घटाएँ, timeoutMs घटाएँ, या हाल के टर्न की संख्या और
प्रति-टर्न वर्ण सीमाएँ कम करें।
सामान्य समस्याएँ
उन्नत Active Memory कॉन्फ़िगर किए गए मेमोरी Plugin की रिकॉल पाइपलाइन पर चलती है, इसलिए रिकॉल से जुड़े अधिकांश अप्रत्याशित परिणाम एम्बेडिंग-प्रदाता की समस्याएँ होते हैं, न कि active-memory की बग। डिफ़ॉल्टmemory-core पथ memory_search और
memory_get का उपयोग करता है; memory-lancedb स्लॉट memory_recall का उपयोग करता है। यदि आप किसी अन्य
मेमोरी Plugin का उपयोग करते हैं, तो पुष्टि करें कि config.toolsAllow उन टूल के नाम देता है जिन्हें वह Plugin वास्तव में
पंजीकृत करता है। बातचीतों के बीच Remember का दायरा अधिक सीमित है: वर्तमान मेमोरी
प्रदाता को OpenClaw के संरक्षित समान-एजेंट/निजी-सत्र रिकॉल
पथ का समर्थन करना आवश्यक है।
एम्बेडिंग प्रदाता बदल गया या उसने काम करना बंद कर दिया
एम्बेडिंग प्रदाता बदल गया या उसने काम करना बंद कर दिया
यदि
memory.search.provider सेट नहीं है, तो OpenClaw OpenAI एम्बेडिंग का उपयोग करता है। Bedrock, DeepInfra, Gemini, GitHub
Copilot, LM Studio, local, Mistral, Ollama, Voyage, या OpenAI-संगत
एम्बेडिंग के लिए memory.search.provider को स्पष्ट रूप से सेट करें। यदि कॉन्फ़िगर किया गया प्रदाता नहीं चल सकता, तो memory_search
केवल-शाब्दिक पुनर्प्राप्ति तक सीमित हो सकता है; प्रदाता पहले ही
चुने जाने के बाद होने वाली रनटाइम विफलताओं में स्वचालित फ़ॉलबैक नहीं होता।वैकल्पिक memory.search.fallback केवल तभी सेट करें जब आप जानबूझकर
एकल फ़ॉलबैक चाहते हों। प्रदाताओं और उदाहरणों की पूरी
सूची के लिए मेमोरी खोज देखें।रिकॉल धीमा, खाली या असंगत लगता है
रिकॉल धीमा, खाली या असंगत लगता है
- सत्र में Plugin-स्वामित्व वाला Active Memory डीबग
सारांश दिखाने के लिए
/trace onचालू करें। - प्रत्येक उत्तर के बाद
🧩 Active Memory: ...स्थिति पंक्ति भी देखने के लिए/verbose onचालू करें। - gateway लॉग में
active-memory: ... start|done,memory sync failed (search-bootstrap), या प्रदाता एम्बेडिंग त्रुटियाँ देखें। - मेमोरी-खोज बैकएंड और
इंडेक्स की स्थिति का निरीक्षण करने के लिए
openclaw status --deepचलाएँ। - यदि आप
ollamaका उपयोग करते हैं, तो पुष्टि करें कि एम्बेडिंग मॉडल इंस्टॉल है (ollama list)।
gateway पुनः आरंभ होने के बाद पहला रिकॉल `status=timeout` लौटाता है
gateway पुनः आरंभ होने के बाद पहला रिकॉल `status=timeout` लौटाता है
v2026.5.2 और उसके बाद के संस्करणों में, यदि कोल्ड-स्टार्ट सेटअप (मॉडल वार्म-अप + एम्बेडिंग
इंडेक्स लोड) पहला रिकॉल चलने तक पूरा नहीं हुआ है, तो रन
कॉन्फ़िगर किए गए
timeoutMs बजट तक पहुँच सकता है और खाली आउटपुट के साथ status=timeout
लौटा सकता है। gateway लॉग पुनः आरंभ होने के बाद पहले योग्य उत्तर के आसपास active-memory timeout after Nms
दिखाते हैं।अनुशंसित setupGraceTimeoutMs मान के लिए अनुशंसित सेटअप के अंतर्गत
कोल्ड-स्टार्ट अनुग्रह देखें।