मुख्य सामग्री पर जाएं
OpenClaw इनबाउंड संदेशों को सेशन समाधान, क्यूइंग, स्ट्रीमिंग, टूल निष्पादन, और रीजनिंग दृश्यता की पाइपलाइन के ज़रिए संभालता है। यह पेज इनबाउंड संदेश से जवाब तक का पथ दिखाता है।

​
संदेश प्रवाह (उच्च स्तर)

Inbound message
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)
मुख्य नियंत्रण कॉन्फ़िगरेशन में होते हैं:
  • messages.* प्रीफ़िक्स, क्यूइंग, और समूह व्यवहार के लिए।
  • agents.defaults.* ब्लॉक स्ट्रीमिंग और चंकिंग डिफ़ॉल्ट्स के लिए।
  • चैनल ओवरराइड (channels.whatsapp.*, channels.telegram.*, आदि) कैप्स और स्ट्रीमिंग टॉगल के लिए।
पूरे स्कीमा के लिए कॉन्फ़िगरेशन देखें।

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

रीकनेक्ट के बाद चैनल वही संदेश दोबारा डिलीवर कर सकते हैं। OpenClaw चैनल/अकाउंट/पीयर/सेशन/मैसेज id से keyed एक कम अवधि वाला कैश रखता है ताकि डुप्लिकेट डिलीवरी कोई दूसरा एजेंट रन शुरू न करें।

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

उसी भेजने वाले से तेज़ी से आए लगातार संदेशों को messages.inbound के ज़रिए एक ही एजेंट टर्न में बैच किया जा सकता है। डिबाउंसिंग प्रति चैनल + बातचीत के दायरे में होती है और reply threading/IDs के लिए सबसे हालिया संदेश का उपयोग करती है। कॉन्फ़िगरेशन (ग्लोबल डिफ़ॉल्ट + प्रति-चैनल ओवरराइड): 
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
नोट्स:
  • डिबाउंस केवल टेक्स्ट-ओनली संदेशों पर लागू होता है; मीडिया/अटैचमेंट तुरंत फ्लश हो जाते हैं।
  • कंट्रोल कमांड डिबाउंसिंग को बायपास करते हैं ताकि वे अलग रहें। जो चैनल same-sender DM coalescing में स्पष्ट रूप से opt in करते हैं, वे DM कमांड को debounce window के अंदर रख सकते हैं ताकि split-send payload उसी एजेंट टर्न में जुड़ सके।

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

सेशन Gateway के स्वामित्व में होते हैं, क्लाइंट के नहीं।
  • डायरेक्ट चैट एजेंट मुख्य सेशन key में सिमट जाते हैं।
  • समूह/चैनल को अपनी सेशन keys मिलती हैं।
  • सेशन store और transcripts Gateway host पर रहते हैं।
कई डिवाइस/चैनल एक ही सेशन पर मैप हो सकते हैं, लेकिन history हर क्लाइंट पर पूरी तरह सिंक नहीं होती। सुझाव: लंबे संवादों के लिए एक primary device का उपयोग करें ताकि context अलग-अलग न हो। Control UI और TUI हमेशा Gateway-backed session transcript दिखाते हैं, इसलिए वे source of truth हैं। विवरण: सेशन प्रबंधन।

​
टूल परिणाम metadata

टूल परिणाम content मॉडल-दृश्य परिणाम है। टूल परिणाम details UI rendering, diagnostics, media delivery, और Plugins के लिए runtime metadata है। OpenClaw इस सीमा को स्पष्ट रखता है:
  • toolResult.details को provider replay और compaction input से पहले हटा दिया जाता है।
  • Persisted session transcripts केवल bounded details रखते हैं; बहुत बड़े metadata को persistedDetailsTruncated: true चिह्नित compact summary से बदल दिया जाता है।
  • Plugins और tools को वह text जिसे model को पढ़ना चाहिए content में रखना चाहिए, केवल details में नहीं।

​
इनबाउंड bodies और history context

OpenClaw prompt body को command body से अलग करता है:
  • BodyForAgent: वर्तमान संदेश के लिए primary model-facing text। चैनल Plugins को इसे भेजने वाले के वर्तमान prompt-bearing text पर केंद्रित रखना चाहिए।
  • Body: legacy prompt fallback। इसमें channel envelopes और optional history wrappers शामिल हो सकते हैं, लेकिन current channels को BodyForAgent उपलब्ध होने पर primary model input के रूप में इस पर निर्भर नहीं रहना चाहिए।
  • CommandBody: directive/command parsing के लिए raw user text।
  • RawBody: CommandBody का legacy alias (compatibility के लिए रखा गया)।
जब कोई चैनल history देता है, तो वह shared wrapper का उपयोग करता है:
  • [Chat messages since your last reply - for context]
  • [Current message - respond to this]
non-direct chats (groups/channels/rooms) के लिए, current message body में sender label prefix किया जाता है (history entries के लिए इस्तेमाल होने वाली same style)। इससे real-time और queued/history messages एजेंट prompt में consistent रहते हैं। History buffers pending-only होते हैं: इनमें वे group messages शामिल होते हैं जिन्होंने run trigger नहीं किया (उदाहरण के लिए, mention-gated messages) और session transcript में पहले से मौजूद messages exclude होते हैं। Directive stripping केवल current message section पर लागू होती है ताकि history intact रहे। History wrap करने वाले channels को CommandBody (या RawBody) को original message text पर set करना चाहिए और Body को combined prompt के रूप में रखना चाहिए। Structured history, reply, forwarded, और channel metadata prompt assembly के दौरान user-role untrusted context blocks के रूप में render किए जाते हैं। History buffers messages.groupChat.historyLimit (global default) और per-channel overrides जैसे channels.slack.historyLimit या channels.telegram.accounts.<id>.historyLimit (0 set करने पर disable) के ज़रिए configurable हैं।

​
क्यूइंग और followups

अगर कोई run पहले से active है, तो inbound messages default रूप से current run में steer किए जाते हैं। messages.queue चुनता है कि active-run messages steer हों, बाद के लिए queue हों, एक later turn में collect हों, या active run को interrupt करें।
  • messages.queue (और messages.queue.byChannel) के ज़रिए configure करें।
  • Default mode steer है, Codex steering batches और followup/collect queues के लिए 500ms debounce के साथ।
  • Modes: steer, followup, collect, और interrupt।
विवरण: Command queue और Steering queue।

​
चैनल run ownership

चैनल Plugins session queue में message enter होने से पहले ordering preserve कर सकते हैं, input debounce कर सकते हैं, और transport backpressure apply कर सकते हैं। उन्हें agent turn के चारों ओर अलग timeout impose नहीं करना चाहिए। जब message किसी session पर route हो जाता है, तो long-running work session, tool, और runtime lifecycle से governed होता है ताकि सभी channels slow turns को consistently report और recover करें।

​
स्ट्रीमिंग, चंकिंग, और बैचिंग

Block streaming partial replies भेजती है जैसे-जैसे model text blocks produce करता है। Chunking channel text limits का सम्मान करती है और fenced code को split करने से बचती है। मुख्य settings:
  • agents.defaults.blockStreamingDefault (on|off, default off)
  • agents.defaults.blockStreamingBreak (text_end|message_end)
  • agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
  • agents.defaults.blockStreamingCoalesce (idle-based batching)
  • agents.defaults.humanDelay (block replies के बीच human-like pause)
  • चैनल overrides: *.blockStreaming और *.blockStreamingCoalesce (non-Telegram channels को explicit *.blockStreaming: true चाहिए)
विवरण: स्ट्रीमिंग + चंकिंग।

​
रीजनिंग दृश्यता और tokens

OpenClaw model reasoning को expose या hide कर सकता है:
  • /reasoning on|off|stream दृश्यता नियंत्रित करता है।
  • Reasoning content, model द्वारा produce होने पर, token usage में फिर भी count होता है।
  • Telegram transient draft bubble में reasoning stream support करता है जिसे final delivery के बाद delete कर दिया जाता है; persistent reasoning output के लिए /reasoning on का उपयोग करें।
विवरण: Thinking + reasoning directives और Token use।

​
प्रीफ़िक्स, threading, और replies

Outbound message formatting messages में centralized है:
  • messages.responsePrefix, channels.<channel>.responsePrefix, और channels.<channel>.accounts.<id>.responsePrefix (outbound prefix cascade), साथ ही channels.whatsapp.messagePrefix (WhatsApp inbound prefix)
  • replyToMode और per-channel defaults के ज़रिए reply threading
विवरण: कॉन्फ़िगरेशन और channel docs।

​
silent replies

सटीक silent token NO_REPLY / no_reply का अर्थ है “user-visible reply deliver न करें”। जब किसी turn में pending tool media भी हो, जैसे generated TTS audio, OpenClaw silent text को strip करता है लेकिन media attachment फिर भी deliver करता है। OpenClaw इस behavior को conversation type के आधार पर resolve करता है:
  • Direct conversations को कभी NO_REPLY prompt guidance नहीं मिलती। अगर कोई direct run गलती से bare silent token return करता है, तो OpenClaw उसे rewrite या deliver करने के बजाय suppress करता है।
  • Groups/channels default रूप से केवल automatic group replies के लिए silence allow करते हैं। message_tool visible-reply mode में, silence का अर्थ है कि model message(action=send) call नहीं करता।
  • Internal orchestration default रूप से silence allow करता है।
OpenClaw non-direct chats में generic internal runner failures के लिए भी silent replies का उपयोग करता है, ताकि groups/channels को gateway error boilerplate न दिखे। Missing auth, rate-limit, या overload notices जैसी user-facing recovery copy वाली classified failures फिर भी deliver की जा सकती हैं। Direct chats default रूप से compact failure copy दिखाते हैं; raw runner details केवल /verbose full enabled होने पर दिखते हैं। Defaults agents.defaults.silentReply के अंतर्गत रहते हैं; surfaces.<id>.silentReply प्रति surface group/internal policy को override कर सकता है। Bare silent replies सभी surfaces पर drop कर दी जाती हैं, ताकि parent sessions fallback chatter में sentinel text rewrite करने के बजाय शांत रहें।

​
संबंधित