मुख्य सामग्री पर जाएं

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

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

​
मुख्य शब्द

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

​
आउटबाउंड लक्ष्य प्रीफ़िक्स

स्पष्ट आउटबाउंड लक्ष्यों में प्रदाता प्रीफ़िक्स शामिल हो सकता है, जैसे telegram:123 या tg:123। कोर उस प्रीफ़िक्स को चैनल-चयन संकेत के रूप में केवल तब मानता है जब चयनित चैनल last हो या अन्यथा अनसुलझा हो, और केवल तब जब लोड किया गया Plugin उस प्रीफ़िक्स का विज्ञापन करता हो। यदि कॉलर ने पहले से स्पष्ट चैनल चुना है, तो प्रदाता प्रीफ़िक्स को उसी चैनल से मेल खाना चाहिए; WhatsApp डिलीवरी को telegram:123 जैसे क्रॉस-चैनल संयोजन Plugin-विशिष्ट लक्ष्य सामान्यीकरण से पहले विफल हो जाते हैं। लक्ष्य-प्रकार और सेवा प्रीफ़िक्स जैसे channel:<id>, user:<id>, room:<id>, thread:<id>, imessage:<handle>, और sms:<number> चयनित चैनल के व्याकरण के भीतर ही रहते हैं। वे स्वयं प्रदाता का चयन नहीं करते।

​
सत्र कुंजी आकार (उदाहरण)

प्रत्यक्ष संदेश डिफ़ॉल्ट रूप से एजेंट के मुख्य सत्र में सिमट जाते हैं:
  • agent:<agentId>:<mainKey> (डिफ़ॉल्ट: agent:main:main)
भले ही प्रत्यक्ष-संदेश वार्तालाप इतिहास मुख्य सत्र के साथ साझा हो, सैंडबॉक्स और टूल नीति बाहरी 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 को अपडेट करना छोड़ देता है।

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

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

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

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

​
ब्रॉडकास्ट समूह (कई एजेंट चलाएँ)

ब्रॉडकास्ट समूह आपको उसी पीयर के लिए कई एजेंट चलाने देते हैं जब OpenClaw सामान्यतः जवाब देता (उदाहरण के लिए: WhatsApp समूहों में, मेंशन/एक्टिवेशन गेटिंग के बाद)। कॉन्फ़िगरेशन: 
{
  broadcast: {
    strategy: "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}
देखें: ब्रॉडकास्ट समूह।

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

  • agents.list: नामित एजेंट परिभाषाएँ (वर्कस्पेस, मॉडल, आदि)।
  • 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" },
  ],
}

​
सत्र संग्रहण

सत्र स्टोर स्टेट डायरेक्टरी के अंतर्गत रहते हैं (डिफ़ॉल्ट ~/.openclaw):
  • ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • JSONL ट्रांसक्रिप्ट स्टोर के साथ रहते हैं
आप session.store और {agentId} टेम्पलेटिंग के ज़रिए स्टोर पथ ओवरराइड कर सकते हैं। Gateway और ACP सत्र खोज डिफ़ॉल्ट agents/ रूट के अंतर्गत और टेम्पलेटेड session.store रूट के अंतर्गत डिस्क-समर्थित एजेंट स्टोर भी स्कैन करती है। खोजे गए स्टोर उस हल किए गए एजेंट रूट के भीतर ही रहने चाहिए और नियमित sessions.json फ़ाइल का उपयोग करना चाहिए। सिमलिंक और रूट से बाहर के पथ अनदेखे किए जाते हैं।

​
WebChat व्यवहार

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

​
जवाब संदर्भ

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

​
संबंधित