चैनल और रूटिंग

OpenClaw उत्तरों को उसी चैनल पर वापस भेजता है जहाँ से संदेश आया था। मॉडल चैनल नहीं चुनता; रूटिंग नियतात्मक होती है और होस्ट कॉन्फ़िगरेशन द्वारा नियंत्रित होती है। डिफ़ॉल्ट DM दायरे में, हर चैनल के सीधे संदेश एजेंट के मुख्य सत्र में एकत्रित होते हैं।

प्रमुख शब्द

• चैनल: discord, googlechat, imessage, irc, line, signal, slack, telegram, या whatsapp जैसा कोई बंडल किया गया चैनल Plugin, साथ ही इंस्टॉल किए गए Plugin चैनल। webchat आंतरिक WebChat UI चैनल है और कॉन्फ़िगर करने योग्य आउटबाउंड चैनल नहीं है।
• AccountId: प्रत्येक चैनल का खाता इंस्टेंस (जहाँ समर्थित हो)।
• वैकल्पिक चैनल डिफ़ॉल्ट खाता: channels.<channel>.defaultAccount यह चुनता है कि जब कोई आउटबाउंड पथ accountId निर्दिष्ट नहीं करता, तब किस खाते का उपयोग किया जाए।
  • बहु-खाता सेटअप में, दो या अधिक खाते कॉन्फ़िगर होने पर एक स्पष्ट डिफ़ॉल्ट (defaultAccount या default नामक खाता) सेट करें। इसके बिना, फ़ॉलबैक रूटिंग पहले सामान्यीकृत खाता ID को चुन सकती है।
• AgentId: एक पृथक कार्यक्षेत्र + सत्र भंडार ("मस्तिष्क")।
• SessionKey: संदर्भ संग्रहीत करने और समवर्तीता नियंत्रित करने के लिए प्रयुक्त बकेट कुंजी।

आउटबाउंड लक्ष्य उपसर्ग

स्पष्ट आउटबाउंड लक्ष्यों में प्रदाता उपसर्ग शामिल हो सकता है, जैसे telegram:123 या tg:123। कोर उस उपसर्ग को चैनल-चयन संकेत केवल तभी मानता है, जब चयनित चैनल last हो या अन्यथा अनसुलझा हो, और केवल तभी जब लोड किया गया Plugin उस उपसर्ग की घोषणा करता हो। यदि कॉलर ने पहले ही कोई स्पष्ट चैनल चुना है, तो प्रदाता उपसर्ग का उस चैनल से मेल खाना आवश्यक है; telegram:123 पर WhatsApp डिलीवरी जैसे क्रॉस-चैनल संयोजन Plugin-विशिष्ट लक्ष्य सामान्यीकरण से पहले विफल हो जाते हैं।

channel:<id>, user:<id>, room:<id>, thread:<id>, imessage:<handle>, और sms:<number> जैसे लक्ष्य-प्रकार और सेवा उपसर्ग चयनित चैनल के व्याकरण के भीतर रहते हैं। वे स्वयं प्रदाता का चयन नहीं करते।

सत्र कुंजी के प्रारूप (उदाहरण)

सीधे संदेश डिफ़ॉल्ट रूप से एजेंट के मुख्य सत्र में समाहित हो जाते हैं:

• agent:<agentId>:<mainKey> (डिफ़ॉल्ट: agent:main:main)

session.dmScope DM समेकन को नियंत्रित करता है: main (डिफ़ॉल्ट) एक मुख्य सत्र साझा करता है, जबकि per-peer, per-channel-peer, और per-account-channel-peer DM को अलग-अलग सत्रों में रखते हैं। कोई रूट बाइंडिंग bindings[].session.dmScope के माध्यम से अपने मेल खाने वाले पीयर के लिए दायरे को ओवरराइड कर सकती है।

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

समूह और चैनल प्रत्येक चैनल के अनुसार पृथक रहते हैं:

• समूह: agent:<agentId>:<channel>:group:<id>
• चैनल/रूम: agent:<agentId>:<channel>:channel:<id>

थ्रेड:

• Slack/Discord थ्रेड आधार कुंजी में :thread:<threadId> जोड़ते हैं।
• Telegram फ़ोरम विषय समूह कुंजी में :topic:<topicId> समाहित करते हैं।

उदाहरण:

• agent:main:telegram:group:-1001234567890:topic:42
• agent:main:discord:channel:123456:thread:987654

मुख्य DM रूट पिनिंग

जब session.dmScope, main होता है, तब सीधे संदेश एक मुख्य सत्र साझा कर सकते हैं। सत्र के lastRoute को गैर-स्वामी DM द्वारा ओवरराइट होने से रोकने के लिए, इन सभी शर्तों के सत्य होने पर OpenClaw allowFrom से पिन किए गए स्वामी का अनुमान लगाता है:

• allowFrom में ठीक एक गैर-वाइल्डकार्ड प्रविष्टि है।
• प्रविष्टि को उस चैनल के लिए किसी ठोस प्रेषक ID में सामान्यीकृत किया जा सकता है।
• इनबाउंड DM प्रेषक उस पिन किए गए स्वामी से मेल नहीं खाता।

मेल न खाने की उस स्थिति में, OpenClaw फिर भी इनबाउंड सत्र मेटाडेटा रिकॉर्ड करता है, लेकिन मुख्य सत्र के lastRoute को अपडेट नहीं करता।

संरक्षित इनबाउंड रिकॉर्डिंग

चैनल Plugin किसी इनबाउंड सत्र रिकॉर्ड को createIfMissing: false के रूप में चिह्नित कर सकते हैं, जब किसी संरक्षित पथ को नया OpenClaw सत्र नहीं बनाना चाहिए। उस मोड में, OpenClaw किसी मौजूदा सत्र के लिए मेटाडेटा और lastRoute अपडेट कर सकता है, लेकिन केवल संदेश देखे जाने के कारण रूट-मात्र सत्र प्रविष्टि नहीं बनाता।

रूटिंग नियम (एजेंट कैसे चुना जाता है)

रूटिंग प्रत्येक इनबाउंड संदेश के लिए एक एजेंट चुनती है:

1. सटीक पीयर मिलान (bindings के साथ peer.kind + peer.id)।
2. पैरेंट पीयर मिलान (थ्रेड इनहेरिटेंस)।
3. पीयर वाइल्डकार्ड मिलान (किसी पीयर प्रकार के लिए peer.id: "*")।
4. गिल्ड + भूमिकाओं का मिलान (Discord), guildId + roles के माध्यम से।
5. गिल्ड मिलान (Discord), guildId के माध्यम से।
6. टीम मिलान (Slack), teamId के माध्यम से।
7. खाता मिलान (चैनल पर accountId)।
8. चैनल मिलान (उस चैनल पर कोई भी खाता, accountId: "*")।
9. डिफ़ॉल्ट एजेंट (agents.entries.*.default, अन्यथा सूची की पहली प्रविष्टि, और फ़ॉलबैक के रूप में main)।

जब किसी बाइंडिंग में कई मिलान फ़ील्ड (peer, guildId, teamId, roles) शामिल हों, तो उस बाइंडिंग के लागू होने के लिए दिए गए सभी फ़ील्ड का मेल खाना आवश्यक है।

मेल खाने वाला एजेंट निर्धारित करता है कि किस कार्यक्षेत्र और सत्र भंडार का उपयोग किया जाए।

प्रसारण समूह (कई एजेंट चलाएँ)

प्रसारण समूह आपको एक ही पीयर के लिए कई एजेंट चलाने देते हैं जब OpenClaw सामान्यतः उत्तर देता (उदाहरण के लिए: WhatsApp समूहों में, उल्लेख/सक्रियण गेटिंग के बाद)।

कॉन्फ़िगरेशन:

{  broadcast: {    strategy: "parallel",    "120363403215116621@g.us": ["alfred", "baerbel"],    "+15555550123": ["support", "logger"],  },}

देखें: प्रसारण समूह।

कॉन्फ़िगरेशन का अवलोकन

• agents.entries: नामित एजेंट परिभाषाएँ (कार्यस्थान, मॉडल आदि)।
• bindings: इनबाउंड चैनलों/खातों/पीयर को एजेंटों से मैप करें।

उदाहरण:

{  agents: {    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],  },  bindings: [    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },  ],}

सत्र भंडारण

रनटाइम सत्र पंक्तियाँ स्थिति निर्देशिका के अंतर्गत प्रत्येक एजेंट के SQLite डेटाबेस में रहती हैं (डिफ़ॉल्ट ~/.openclaw):

• ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

पुराने इंस्टॉलेशन में लीगेसी ट्रांसक्रिप्ट JSONL फ़ाइलें और ~/.openclaw/agents/<agentId>/sessions/ के अंतर्गत sessions.json पंक्ति भंडार हो सकता है। Gateway स्टार्टअप और openclaw doctor --fix सक्रिय लीगेसी पंक्तियों/हिस्ट्री को स्वचालित रूप से SQLite में इम्पोर्ट करते हैं। जब आपको स्पष्ट माइग्रेशन प्रमाण चाहिए, तब openclaw doctor --session-sqlite inspect --session-sqlite-all-agents और Doctor सत्यापन क्रम का उपयोग करें। माइग्रेशन और ऑफ़लाइन-रखरखाव कार्यप्रवाहों के लिए आप अब भी session.store तथा {agentId} टेम्प्लेटिंग के माध्यम से लीगेसी भंडार पथ चुन सकते हैं।

Gateway और ACP सत्र खोज डिफ़ॉल्ट agents/ रूट और टेम्प्लेट किए गए session.store रूट के अंतर्गत डिस्क-समर्थित एजेंट भंडारों को भी स्कैन करती है। खोजे गए भंडारों को उस समाधान किए गए एजेंट रूट के भीतर रहना और नियमित लीगेसी sessions.json फ़ाइल का उपयोग करना आवश्यक है। सिमलिंक और रूट से बाहर के पथ अनदेखे किए जाते हैं।

WebChat व्यवहार

WebChat चयनित एजेंट से जुड़ता है और डिफ़ॉल्ट रूप से एजेंट के मुख्य सत्र का उपयोग करता है। इस कारण, WebChat आपको उस एजेंट के लिए विभिन्न चैनलों का संदर्भ एक ही स्थान पर देखने देता है।

उत्तर संदर्भ

इनबाउंड उत्तरों में शामिल हैं:

• उपलब्ध होने पर ReplyToId, ReplyToBody, और ReplyToSender।
• उद्धृत संदर्भ को Body में [Replying to ...] ब्लॉक के रूप में जोड़ा जाता है।

यह सभी चैनलों में एकसमान है।

संबंधित

• समूह
• प्रसारण समूह
• पेयरिंग