संदेश

इनबाउंड संदेश रूटिंग, डीडुप्लिकेशन/डीबाउंस, एजेंट रन और आउटबाउंड डिलीवरी से होकर गुजरते हैं:

इनबाउंड संदेश  -> रूटिंग/बाइंडिंग -> सेशन कुंजी  -> डीडुप्लिकेशन + डीबाउंस  -> कतार (यदि कोई रन पहले से सक्रिय है)  -> एजेंट रन (स्ट्रीमिंग + टूल)  -> आउटबाउंड उत्तर (चैनल सीमाएँ + खंडन)

मुख्य कॉन्फ़िगरेशन सतहें:

• messages.* प्रीफ़िक्स, कतारबद्ध करने, इनबाउंड डीबाउंस और समूह व्यवहार के लिए।
• agents.defaults.* ब्लॉक स्ट्रीमिंग, खंडन और मौन-उत्तर डिफ़ॉल्ट के लिए।
• प्रति-चैनल सीमाओं और स्ट्रीमिंग टॉगल के लिए चैनल ओवरराइड (channels.telegram.*, channels.whatsapp.*, आदि)।

पूरी स्कीमा के लिए कॉन्फ़िगरेशन देखें।

इनबाउंड डीडुप्लिकेशन

दोबारा कनेक्ट होने के बाद चैनल उसी संदेश को फिर से डिलीवर कर सकते हैं। OpenClaw एजेंट स्कोप, चैनल रूट (चैनल + पीयर + खाता + थ्रेड) और संदेश आईडी के आधार पर कुंजीकृत इन-मेमोरी कैश रखता है, ताकि दोबारा डिलीवर किया गया संदेश दूसरा एजेंट रन ट्रिगर न करे। कैश प्रविष्टि 20 मिनट बाद या 5000 प्रविष्टियाँ ट्रैक होते ही, जो भी पहले हो, समाप्त हो जाती है।

इनबाउंड डीबाउंसिंग

एक ही प्रेषक के लगातार तेज़ी से आने वाले टेक्स्ट संदेशों को messages.inbound के माध्यम से एक एजेंट टर्न में बैच किया जा सकता है। डीबाउंसिंग का स्कोप प्रति चैनल + वार्तालाप होता है और उत्तर थ्रेडिंग/आईडी के लिए सबसे हाल के संदेश का उपयोग होता है।

{  messages: {    inbound: {      debounceMs: 2000,      byChannel: {        discord: 1500,        slack: 1500,        whatsapp: 5000,      },    },  },}

• डीबाउंस केवल टेक्स्ट संदेशों पर लागू होता है; मीडिया/अटैचमेंट तुरंत फ़्लश होते हैं।
• नियंत्रण कमांड (स्टॉप/अबॉर्ट/स्टेटस, आदि) डीबाउंसिंग को बायपास करते हैं, इसलिए वे तुरंत डिस्पैच होते हैं।
• डिफ़ॉल्ट रूप से अक्षम: messages.inbound.debounceMs का कोई अंतर्निहित डिफ़ॉल्ट नहीं है, इसलिए डीबाउंसिंग आपके इसे सेट करने के बाद ही सक्रिय होती है (वैश्विक रूप से या प्रति चैनल)।
• iMessage भी इसी सामान्य डीबाउंस नीति का पालन करता है। imsg 0.13.1 और उसके बाद के संस्करण Apple URL-प्रीव्यू के विभाजित प्रेषणों को OpenClaw द्वारा प्राप्त किए जाने से पहले एकत्रित कर देते हैं, इसलिए iMessage-विशिष्ट डीबाउंस सेटिंग की आवश्यकता नहीं है।

सेशन और डिवाइस

सेशन का स्वामित्व Gateway के पास होता है, क्लाइंट के पास नहीं।

• प्रत्यक्ष चैट एजेंट की मुख्य सेशन कुंजी में समाहित हो जाती हैं।
• समूहों/चैनलों को अपनी अलग सेशन कुंजियाँ मिलती हैं।
• सेशन स्टोर और ट्रांसक्रिप्ट Gateway होस्ट पर रहते हैं।

कई डिवाइस/चैनल एक ही सेशन से मैप हो सकते हैं, लेकिन इतिहास प्रत्येक क्लाइंट पर पूरी तरह वापस सिंक नहीं होता। अलग-अलग संदर्भ बनने से बचने के लिए लंबी बातचीत हेतु एक प्राथमिक डिवाइस का उपयोग करें। Control UI और TUI हमेशा Gateway-समर्थित सेशन ट्रांसक्रिप्ट दिखाते हैं, इसलिए वही सत्य का स्रोत हैं।

विवरण: सेशन प्रबंधन।

प्रॉम्प्ट बॉडी और इतिहास संदर्भ

चैनल Plugin इनबाउंड संदर्भ में प्राथमिकता के उच्चतम से न्यूनतम क्रम में कई टेक्स्ट फ़ील्ड भरते हैं:

जब कोई चैनल इतिहास प्रदान करता है, तो वह उसे इनके साथ रैप करता है:

• [Chat messages since your last reply - for context]
• [Current message - respond to this]

गैर-प्रत्यक्ष चैट (समूह/चैनल/रूम) के लिए वर्तमान संदेश बॉडी के आगे प्रेषक लेबल लगाया जाता है, जो इतिहास प्रविष्टियों में प्रयुक्त शैली से मेल खाता है। डायरेक्टिव हटाना केवल वर्तमान-संदेश अनुभाग पर लागू होता है, इसलिए इतिहास अक्षुण्ण रहता है। इतिहास को रैप करने वाले चैनलों को मूल संदेश टेक्स्ट पर BodyForCommands (या पुराना CommandBody / RawBody) सेट करना चाहिए और संयुक्त प्रॉम्प्ट के रूप में Body रखना चाहिए।

इतिहास बफ़र केवल लंबित संदेशों के लिए होते हैं: उनमें वे समूह संदेश शामिल होते हैं जिन्होंने रन ट्रिगर नहीं किया (उदाहरण के लिए, उल्लेख-प्रतिबंधित संदेश), और सेशन ट्रांसक्रिप्ट में पहले से मौजूद संदेश शामिल नहीं होते। संरचित इतिहास, उत्तर, अग्रेषित और चैनल मेटाडेटा प्रॉम्प्ट संयोजन के दौरान अविश्वसनीय उपयोगकर्ता-भूमिका संदर्भ ब्लॉक के रूप में रेंडर होते हैं।

इतिहास का आकार messages.groupChat.historyLimit (वैश्विक डिफ़ॉल्ट) या channels.slack.historyLimit और channels.telegram.accounts.<id>.historyLimit जैसे प्रति-चैनल ओवरराइड से कॉन्फ़िगर करें (अक्षम करने के लिए 0 सेट करें)।

टूल परिणाम मेटाडेटा

टूल परिणाम का content मॉडल को दिखाई देने वाला परिणाम है; details UI रेंडरिंग, निदान, मीडिया डिलीवरी और Plugin के लिए रनटाइम मेटाडेटा है।

• toolResult.details को प्रोवाइडर रीप्ले और Compaction इनपुट से पहले हटा दिया जाता है।
• स्थायी सेशन ट्रांसक्रिप्ट केवल सीमित details रखते हैं; बहुत बड़े मेटाडेटा को persistedDetailsTruncated: true चिह्नित संक्षिप्त सारांश से बदल दिया जाता है।
• Plugin और टूल को मॉडल द्वारा पढ़े जाने के लिए आवश्यक टेक्स्ट content में रखना चाहिए, केवल details में नहीं।

कतारबद्ध करना और फ़ॉलोअप

जब कोई रन पहले से सक्रिय होता है, तो इनबाउंड संदेश डिफ़ॉल्ट रूप से उसी में निर्देशित किए जाते हैं। messages.queue मोड नियंत्रित करता है:

कतार स्टीयर, फ़ॉलोअप और कलेक्ट बैचिंग के लिए अंतर्निहित 500ms डीबाउंस का उपयोग करती है। messages.queue.cap का डिफ़ॉल्ट 20 कतारबद्ध संदेश है और messages.queue.drop का डिफ़ॉल्ट summarize है (old और new भी उपलब्ध हैं)। messages.queue.byChannel और messages.queue.debounceMsByChannel के माध्यम से प्रति-चैनल ओवरराइड कॉन्फ़िगर करें।

विवरण: कमांड कतार और स्टीयरिंग कतार।

चैनल रन स्वामित्व

चैनल Plugin क्रम बनाए रख सकते हैं, इनपुट डीबाउंस कर सकते हैं और संदेश के सेशन कतार में प्रवेश करने से पहले ट्रांसपोर्ट बैकप्रेशर लागू कर सकते हैं। उन्हें एजेंट टर्न के चारों ओर अलग टाइमआउट लागू नहीं करना चाहिए। संदेश को किसी सेशन पर रूट किए जाने के बाद, सेशन, टूल और रनटाइम जीवनचक्र लंबे समय तक चलने वाले कार्य को नियंत्रित करते हैं, ताकि सभी चैनल धीमे टर्न की रिपोर्टिंग और उनसे पुनर्प्राप्ति एकसमान ढंग से करें।

स्ट्रीमिंग, खंडन और बैचिंग

ब्लॉक स्ट्रीमिंग मॉडल द्वारा टेक्स्ट ब्लॉक उत्पन्न करते समय आंशिक उत्तर भेजती है; खंडन चैनल की टेक्स्ट सीमाओं का पालन करता है और फ़ेंस किए गए कोड को विभाजित करने से बचता है।

• agents.defaults.blockStreamingDefault (on|off, डिफ़ॉल्ट off)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (निष्क्रियता-आधारित बैचिंग)
• agents.defaults.humanDelay (ब्लॉक उत्तरों के बीच मानव-जैसा विराम)
• चैनल ओवरराइड: बंडल किए गए चैनलों पर *.streaming.block.enabled और *.streaming.block.coalesce; पुराने फ़्लैट कुंजियों को openclaw doctor --fix द्वारा माइग्रेट किया जाता है। Telegram सहित प्रत्येक चैनल पर ब्लॉक स्ट्रीमिंग तब तक बंद रहती है, जब तक उसे स्पष्ट रूप से सक्षम न किया जाए। QQ Bot अपवाद है: इसमें streaming.block कुंजियाँ नहीं होतीं और यह ब्लॉक उत्तरों को स्ट्रीम करता है, जब तक channels.qqbot.streaming.mode का मान "off" न हो।

विवरण: स्ट्रीमिंग + खंडन।

रीजनिंग की दृश्यता और टोकन

• /reasoning on|off|stream दृश्यता नियंत्रित करता है।
• जब मॉडल रीजनिंग सामग्री उत्पन्न करता है, तब भी वह टोकन उपयोग में गिनी जाती है।
• Telegram रीजनिंग को एक अस्थायी ड्राफ़्ट बबल में स्ट्रीम करने का समर्थन करता है, जिसे अंतिम डिलीवरी के बाद हटा दिया जाता है; स्थायी रीजनिंग आउटपुट के लिए /reasoning on का उपयोग करें।

विवरण: थिंकिंग + रीजनिंग डायरेक्टिव और टोकन उपयोग।

प्रीफ़िक्स, थ्रेडिंग और उत्तर

• आउटबाउंड प्रीफ़िक्स channels.<channel>.responsePrefix और channels.<channel>.accounts.<id>.responsePrefix पर रहते हैं। खाता मानों को प्राथमिकता मिलती है। जब वे कैनोनिकल फ़ील्ड सेट नहीं होते, तब Doctor वैश्विक फ़ॉलबैक को कॉन्फ़िगर किए गए चैनल ब्लॉक में कॉपी करता है; messages.responsePrefix अंतर्निहित और कस्टम चैनलों के लिए फ़ॉलबैक बना रहता है।
• replyToMode और प्रति-चैनल डिफ़ॉल्ट के माध्यम से उत्तर थ्रेडिंग।

विवरण: कॉन्फ़िगरेशन और चैनल दस्तावेज़।

मौन उत्तर

मौन टोकन NO_REPLY (केस-असंवेदी, इसलिए no_reply भी मेल खाता है) का अर्थ है "उपयोगकर्ता को दिखाई देने वाला उत्तर डिलीवर न करें।" जब किसी टर्न में लंबित टूल मीडिया भी होता है, जैसे उत्पन्न TTS ऑडियो, तब OpenClaw मौन टेक्स्ट हटा देता है लेकिन मीडिया अटैचमेंट फिर भी डिलीवर करता है।

मौन नीति वार्तालाप प्रकार के अनुसार निर्धारित होती है:

• प्रत्यक्ष वार्तालापों को कभी भी NO_REPLY प्रॉम्प्ट मार्गदर्शन नहीं मिलता। यदि कोई प्रत्यक्ष रन गलती से केवल मौन टोकन लौटाता है, तो OpenClaw उसे फिर से लिखने या डिलीवर करने के बजाय दबा देता है।
• समूहों/चैनलों में डिफ़ॉल्ट रूप से मौन की अनुमति होती है। message_tool दृश्य-उत्तर मोड में मौन का अर्थ है कि मॉडल message(action=send) को कॉल नहीं करता।
• आंतरिक ऑर्केस्ट्रेशन में डिफ़ॉल्ट रूप से मौन की अनुमति होती है।

डिफ़ॉल्ट agents.defaults.silentReply के अंतर्गत रहते हैं; surfaces.<id>.silentReply प्रति सतह समूह/आंतरिक नीति को ओवरराइड कर सकता है।

OpenClaw गैर-प्रत्यक्ष चैट में सामान्य आंतरिक रनर विफलताओं के लिए भी मौन उत्तरों का उपयोग करता है, ताकि समूहों/चैनलों को Gateway त्रुटि का मानक टेक्स्ट न दिखे। उपयोगकर्ता-सामना करने वाली पुनर्प्राप्ति सूचना वाली वर्गीकृत विफलताएँ, जैसे अनुपलब्ध प्रमाणीकरण, दर-सीमा या ओवरलोड सूचनाएँ, फिर भी डिलीवर की जा सकती हैं। प्रत्यक्ष चैट डिफ़ॉल्ट रूप से संक्षिप्त विफलता टेक्स्ट दिखाती हैं; कच्चे रनर विवरण केवल /verbose full सक्षम होने पर दिखाई देते हैं।

केवल मौन उत्तर सभी सतहों पर हटा दिए जाते हैं, इसलिए पैरेंट सेशन सेंटिनल टेक्स्ट को फ़ॉलबैक बातचीत में फिर से लिखने के बजाय शांत रहते हैं।

संबंधित

• संदेश जीवनचक्र रीफ़ैक्टर - टिकाऊ प्रेषण और प्राप्ति डिज़ाइन का लक्ष्य
• स्ट्रीमिंग - रीयल-टाइम संदेश डिलीवरी
• पुनः प्रयास - संदेश डिलीवरी के पुनः प्रयास का व्यवहार
• कतार - संदेश प्रसंस्करण कतार
• चैनल - संदेश प्लेटफ़ॉर्म एकीकरण