---
read_when:
    - इनबाउंड संदेशों के उत्तरों में बदलने की प्रक्रिया की व्याख्या करना
    - सत्रों, कतारबद्ध करने के मोड या स्ट्रीमिंग व्यवहार को स्पष्ट करना
    - रीज़निंग की दृश्यता और उपयोग संबंधी प्रभावों का दस्तावेज़ीकरण
summary: संदेश प्रवाह, सत्र, कतारबद्धता और तर्क की दृश्यता
title: संदेश
x-i18n:
    generated_at: "2026-07-27T17:49:06Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: e42bed834e9a57fb8a248c8654b75ea9977928582f68a83859cf6c16ed0b6bf5
    source_path: concepts/messages.md
    workflow: 16
---

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

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

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

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

पूरी स्कीमा के लिए [कॉन्फ़िगरेशन](/hi/gateway/configuration) देखें।

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

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

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

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

```json5
{
  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-समर्थित सेशन ट्रांसक्रिप्ट दिखाते हैं, इसलिए वही सत्य का स्रोत हैं।

विवरण: [सेशन प्रबंधन](/hi/concepts/session)।

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

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

| फ़ील्ड             | उद्देश्य                                                                                                     |
| ----------------- | ----------------------------------------------------------------------------------------------------------- |
| `BodyForAgent`    | वर्तमान टर्न के लिए मॉडल-सामना करने वाला टेक्स्ट। सेट न होने पर `CommandBody` / `RawBody` / `Body` पर फ़ॉलबैक करता है।        |
| `BodyForCommands` | डायरेक्टिव/कमांड पार्सिंग के लिए उपयोग होने वाला साफ़ टेक्स्ट। सेट न होने पर `CommandBody` / `RawBody` / `Body` पर फ़ॉलबैक करता है। |
| `CommandBody`     | पुरानी मध्यवर्ती बॉडी; `BodyForCommands` को प्राथमिकता दें।                                                         |
| `RawBody`         | `CommandBody` के लिए अप्रचलित उपनाम।                                                                         |
| `Body`            | पुरानी प्रॉम्प्ट बॉडी; इसमें चैनल एनवेलप और इतिहास रैपर शामिल हो सकते हैं।                                     |

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

- `[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` मोड नियंत्रित करता है:

| मोड              | व्यवहार                                            |
| ----------------- | --------------------------------------------------- |
| `steer` (डिफ़ॉल्ट) | सक्रिय रन में नया प्रॉम्प्ट इंजेक्ट करें।          |
| `followup`        | सक्रिय रन समाप्त होने के बाद संदेश चलाएँ।      |
| `collect`         | संगत संदेशों को बाद के एक टर्न में बैच करें।      |
| `interrupt`       | सक्रिय रन को अबॉर्ट करें, फिर सबसे नया प्रॉम्प्ट शुरू करें। |

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

विवरण: [कमांड कतार](/hi/concepts/queue) और [स्टीयरिंग कतार](/hi/concepts/queue-steering)।

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

चैनल 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"` न हो।

विवरण: [स्ट्रीमिंग + खंडन](/hi/concepts/streaming)।

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

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

विवरण: [थिंकिंग + रीजनिंग डायरेक्टिव](/hi/tools/thinking) और [टोकन उपयोग](/hi/reference/token-use)।

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

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

विवरण: [कॉन्फ़िगरेशन](/hi/gateway/config-agents#messages) और चैनल दस्तावेज़।

## मौन उत्तर

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

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

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

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

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

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

## संबंधित

- [संदेश जीवनचक्र रीफ़ैक्टर](/hi/concepts/message-lifecycle-refactor) - टिकाऊ प्रेषण और प्राप्ति डिज़ाइन का लक्ष्य
- [स्ट्रीमिंग](/hi/concepts/streaming) - रीयल-टाइम संदेश डिलीवरी
- [पुनः प्रयास](/hi/concepts/retry) - संदेश डिलीवरी के पुनः प्रयास का व्यवहार
- [कतार](/hi/concepts/queue) - संदेश प्रसंस्करण कतार
- [चैनल](/hi/channels) - संदेश प्लेटफ़ॉर्म एकीकरण