--- read_when: - ग्रुप चैट के व्यवहार या उल्लेख गेटिंग को बदलना - mentionPatterns को विशिष्ट समूह वार्तालापों तक सीमित करना sidebarTitle: Groups summary: विभिन्न प्लेटफ़ॉर्म पर समूह चैट का व्यवहार (Discord/iMessage/Matrix/Microsoft Teams/QQBot/Signal/Slack/Telegram/WhatsApp/Zalo) title: समूह x-i18n: generated_at: "2026-07-27T17:23:57Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 146378f0fc31e129b6504df6778ab8633c048cd4d02af02a5e6da1bfef640d3f source_path: channels/groups.md workflow: 16 --- OpenClaw समूह-सक्षम चैनलों में समान समूह नियम लागू करता है, जिनमें Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp और Zalo शामिल हैं। हमेशा सक्रिय रहने वाले उन रूम के लिए, जिन्हें एजेंट द्वारा स्पष्ट रूप से दृश्यमान संदेश भेजे जाने तक शांत संदर्भ प्रदान करना चाहिए, [परिवेशी रूम इवेंट](/hi/channels/ambient-room-events) देखें। ## शुरुआती परिचय (2 मिनट) OpenClaw आपके अपने मैसेजिंग खातों पर "रहता" है। कोई अलग WhatsApp बॉट उपयोगकर्ता नहीं होता: यदि **आप** किसी समूह में हैं, तो OpenClaw उस समूह को देख सकता है और वहाँ जवाब दे सकता है। डिफ़ॉल्ट व्यवहार: - समूह प्रतिबंधित होते हैं (`groupPolicy: "allowlist"`); समूह के प्रेषकों को अनुमति-सूची में जोड़े जाने तक ब्लॉक किया जाता है। - जब तक आप किसी समूह के लिए उल्लेख गेटिंग अक्षम नहीं करते, जवाबों के लिए उल्लेख आवश्यक होता है। - अंतिम जवाब का टेक्स्ट रूम में अपने-आप पोस्ट होता है (`visibleReplies: "automatic"`)। अर्थात: अनुमति-सूची में शामिल प्रेषक OpenClaw का उल्लेख करके उसे ट्रिगर कर सकते हैं। **संक्षेप में** - **DM एक्सेस** को `*.allowFrom` नियंत्रित करता है। - **समूह एक्सेस** को `*.groupPolicy` + अनुमति-सूचियाँ (`*.groups`, `*.groupAllowFrom`) नियंत्रित करती हैं। - **जवाब ट्रिगर करना** उल्लेख गेटिंग (`requireMention`, `/activation`) द्वारा नियंत्रित होता है। त्वरित प्रवाह (समूह संदेश के साथ क्या होता है): ```text groupPolicy? disabled -> छोड़ें groupPolicy? allowlist -> समूह अनुमत है? नहीं -> छोड़ें requireMention? yes -> उल्लेख किया गया? नहीं -> केवल संदर्भ के लिए संग्रहीत करें उल्लेख/जवाब/कमांड/DM -> उपयोगकर्ता अनुरोध हमेशा सक्रिय समूह की बातचीत -> उपयोगकर्ता अनुरोध, या कॉन्फ़िगर होने पर रूम इवेंट ``` ## दृश्यमान जवाब सामान्य समूह/चैनल अनुरोधों के लिए, OpenClaw डिफ़ॉल्ट रूप से `messages.groupChat.visibleReplies: "automatic"` का उपयोग करता है: अंतिम सहायक टेक्स्ट दृश्यमान जवाब के रूप में रूम में पोस्ट होता है। जब किसी साझा रूम में एजेंट को `message(action=send)` कॉल करके यह तय करने देना हो कि कब बोलना है, तब `messages.groupChat.visibleReplies: "message_tool"` का उपयोग करें। यह टूल का विश्वसनीय रूप से उपयोग करने वाले मॉडल (उदाहरण के लिए GPT-5.6 Sol) के साथ सबसे अच्छा काम करता है। यदि मॉडल टूल का उपयोग करना चूक जाता है और सार्थक अंतिम टेक्स्ट लौटाता है, तो OpenClaw उस टेक्स्ट को रूम में पोस्ट करने के बजाय निजी रखता है। उन मॉडल या रनटाइम के लिए `"automatic"` का उपयोग करें जो केवल-टूल डिलीवरी का विश्वसनीय रूप से पालन नहीं करते: सामान्य अंतिम टेक्स्ट सीधे रूम में पोस्ट होता है और एजेंट अब भी उन फ़ाइलों, इमेज या अन्य अटैचमेंट के लिए `message(action=send)` कॉल कर सकता है जिन्हें अंतिम टेक्स्ट के साथ नहीं भेजा जा सकता। यदि सक्रिय टूल नीति के अंतर्गत संदेश टूल उपलब्ध नहीं है, तो OpenClaw जवाब को चुपचाप दबाने के बजाय स्वचालित दृश्यमान जवाबों पर वापस जाता है। `openclaw doctor` इस असंगति के बारे में चेतावनी देता है। प्रत्यक्ष चैट और किसी भी अन्य स्रोत इवेंट के लिए, `messages.visibleReplies: "message_tool"` समान केवल-टूल व्यवहार को वैश्विक रूप से लागू करता है; `messages.groupChat.visibleReplies` समूह/चैनल रूम के लिए अधिक विशिष्ट ओवरराइड बना रहता है। आंतरिक WebChat के प्रत्यक्ष टर्न डिफ़ॉल्ट रूप से स्वचालित अंतिम-जवाब डिलीवरी का उपयोग करते हैं, ताकि Pi और Codex को समान दृश्यमान-जवाब अनुबंध मिले। केवल-टूल मोड, छिपकर देखने वाले मोड के अधिकांश टर्न के लिए मॉडल को `NO_REPLY` से जवाब देने के लिए बाध्य करने वाले पुराने पैटर्न की जगह लेता है। केवल-टूल मोड में प्रॉम्प्ट किसी `NO_REPLY` अनुबंध को परिभाषित नहीं करता; कुछ भी दृश्यमान न करने का अर्थ केवल संदेश टूल को कॉल न करना है। Plugin के स्वामित्व वाली वार्तालाप बाइंडिंग इसका अपवाद हैं। जब कोई Plugin किसी थ्रेड को बाइंड करके इनबाउंड टर्न पर दावा कर लेता है, तो Plugin द्वारा लौटाया गया जवाब दृश्यमान बाइंडिंग जवाब होता है; उसे `message(action=send)` की आवश्यकता नहीं होती। वह जवाब Plugin रनटाइम आउटपुट है, निजी मॉडल का अंतिम टेक्स्ट नहीं। प्रत्यक्ष समूह अनुरोधों के लिए टाइपिंग संकेतक अब भी भेजे जाते हैं। सक्षम होने पर परिवेशी हमेशा सक्रिय रूम इवेंट तब तक पूरी तरह शांत रहते हैं, जब तक एजेंट संदेश टूल को कॉल नहीं करता। सेशन डिफ़ॉल्ट रूप से विस्तृत टूल/प्रगति सारांशों को दबाते हैं। डीबगिंग के दौरान वर्तमान सेशन के लिए उन्हें दिखाने हेतु `/verbose on` (या `/verbose full`) और केवल-अंतिम-जवाब व्यवहार पर लौटने के लिए `/verbose off` का उपयोग करें। विस्तृत स्थिति प्रत्येक सेशन के लिए अलग होती है और प्रत्यक्ष चैट, समूहों, चैनलों तथा फ़ोरम विषयों में समान रूप से काम करती है। उल्लेख-रहित हमेशा सक्रिय समूह वार्तालाप को उपयोगकर्ता अनुरोधों के बजाय शांत रूम संदर्भ के रूप में सबमिट करने के लिए [परिवेशी रूम इवेंट](/hi/channels/ambient-room-events) का उपयोग करें: ```json5 { messages: { groupChat: { unmentionedInbound: "room_event", }, }, } ``` डिफ़ॉल्ट `unmentionedInbound: "user_request"` है। उल्लेखित संदेश, कमांड, निरस्तीकरण अनुरोध और DM उपयोगकर्ता अनुरोध ही रहते हैं। समूह/चैनल अनुरोधों के दृश्यमान आउटपुट को संदेश टूल के माध्यम से भेजना आवश्यक बनाने के लिए: ```json5 { messages: { groupChat: { visibleReplies: "message_tool", }, }, } ``` प्रत्येक स्रोत चैट के लिए इसे आवश्यक बनाने हेतु: ```json5 { messages: { visibleReplies: "message_tool", }, } ``` फ़ाइल सहेजे जाने के बाद Gateway, `messages` कॉन्फ़िगरेशन परिवर्तनों को रीस्टार्ट के बिना अपना लेता है। केवल तभी रीस्टार्ट करें जब कॉन्फ़िगरेशन रीलोड अक्षम हो (`gateway.reload.mode: "off"`)। कमांड टर्न `visibleReplies: "message_tool"` को बायपास करते हैं और हमेशा दृश्यमान रूप से जवाब देते हैं: नेटिव स्लैश कमांड (Discord, Telegram और नेटिव कमांड समर्थन वाले अन्य इंटरफ़ेस) तथा अधिकृत टेक्स्ट `/...` कमांड, दोनों अपना जवाब स्रोत चैट में पोस्ट करते हैं। समूहों में अनधिकृत टेक्स्ट `/...` टर्न केवल-संदेश-टूल बने रहते हैं; सामान्य चैट टर्न कॉन्फ़िगर किए गए डिफ़ॉल्ट का पालन करते हैं। ## संदर्भ दृश्यता और अनुमति-सूचियाँ समूह सुरक्षा में दो अलग-अलग नियंत्रण शामिल होते हैं: - **ट्रिगर प्राधिकरण**: एजेंट को कौन ट्रिगर कर सकता है (`groupPolicy`, `groups`, `groupAllowFrom`, चैनल-विशिष्ट अनुमति-सूचियाँ)। - **संदर्भ दृश्यता**: मॉडल में कौन-सा पूरक संदर्भ डाला जाता है (जवाब/उद्धरण टेक्स्ट, थ्रेड इतिहास, फ़ॉरवर्ड किया गया मेटाडेटा)। डिफ़ॉल्ट रूप से OpenClaw संदर्भ को प्राप्त रूप में ही रखता है: अनुमति-सूचियाँ तय करती हैं कि कार्रवाइयाँ कौन ट्रिगर कर सकता है, न कि मॉडल को कौन-से उद्धृत या ऐतिहासिक अंश दिखाई देते हैं। पूरक संदर्भ को भी फ़िल्टर करने के लिए `contextVisibility` सेट करें: | मोड | व्यवहार | | ------------------- | -------------------------------------------------------------------------------- | | `"all"` (डिफ़ॉल्ट) | पूरक संदर्भ को प्राप्त रूप में रखें। | | `"allowlist"` | केवल अनुमति-सूची में शामिल प्रेषकों का इतिहास/थ्रेड/उद्धरण/फ़ॉरवर्ड किया गया संदर्भ डालें। | | `"allowlist_quote"` | `allowlist`, साथ ही किसी भी प्रेषक के स्पष्ट रूप से उद्धृत/जवाब दिए गए संदेश को रखें। | इसे प्रत्येक चैनल (`channels..contextVisibility`), प्रत्येक खाते (`channels..accounts..contextVisibility`) या वैश्विक रूप से (`channels.defaults.contextVisibility`) सेट करें। पूरक संदर्भ प्राप्त करने वाले चैनल (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp) इनबाउंड संदर्भ बनाते समय यह नीति लागू करते हैं; अज्ञात नीति संयोजन सुरक्षित रूप से विफल होते हैं और संदर्भ को छोड़ देते हैं। ये मोड केवल चैनल द्वारा दिए गए पूरक संदर्भ को फ़िल्टर करते हैं। टूल नीति और केवल-स्वामी टूल सूची अब भी वर्तमान टर्न के मूल अनुरोधकर्ता के आधार पर चुनी जाती हैं, न कि प्रॉम्प्ट में दर्शाए गए प्रत्येक प्रेषक के आधार पर। [अनुरोधकर्ता-स्कोप वाले नियंत्रण और प्रॉम्प्ट संदर्भ](/hi/gateway/security#requester-scoped-controls-and-prompt-context) देखें। ![समूह संदेश प्रवाह](/images/groups-flow.svg) यदि आप चाहते हैं... | लक्ष्य | क्या सेट करें | | -------------------------------------------- | ---------------------------------------------------------- | | सभी समूहों को अनुमति दें, लेकिन केवल @उल्लेखों पर जवाब दें | `groups: { "*": { requireMention: true } }` | | समूह के सभी जवाब अक्षम करें | `groupPolicy: "disabled"` | | केवल विशिष्ट समूह | `groups: { "": { ... } }` (कोई `"*"` कुंजी नहीं) | | समूहों में केवल आप ट्रिगर कर सकें | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` | | सभी चैनलों में विश्वसनीय प्रेषकों के एक सेट का पुनः उपयोग करें | `groupAllowFrom: ["accessGroup:operators"]` | पुनः उपयोग योग्य प्रेषक अनुमति-सूचियों के लिए [एक्सेस समूह](/hi/channels/access-groups) देखें। ## सेशन कुंजियाँ - समूह सेशन `agent:::group:` सेशन कुंजियों का उपयोग करते हैं (रूम/चैनल `agent:::channel:` का उपयोग करते हैं)। - Telegram फ़ोरम विषय समूह आईडी में `:topic:` जोड़ते हैं, ताकि प्रत्येक विषय का अपना सेशन हो। - प्रत्यक्ष चैट मुख्य सेशन का उपयोग करती हैं (या यदि `session.dmScope` कॉन्फ़िगर किया गया है, तो प्रत्येक प्रेषक के लिए अलग सेशन)। - Heartbeats कॉन्फ़िगर किए गए Heartbeat सेशन में चलते हैं (डिफ़ॉल्ट: एजेंट का मुख्य सेशन); समूह सेशन अपने Heartbeats नहीं चलाते। ## पैटर्न: निजी DM + सार्वजनिक समूह (एक एजेंट) हाँ — यदि आपका "निजी" ट्रैफ़िक **DM** है और आपका "सार्वजनिक" ट्रैफ़िक **समूह** है, तो यह अच्छी तरह काम करता है। कारण: एकल-एजेंट मोड में, DM सामान्यतः **मुख्य** सेशन कुंजी (`agent:main:main`) में पहुँचते हैं, जबकि समूह हमेशा **गैर-मुख्य** सेशन कुंजियों (`agent:main::group:`) का उपयोग करते हैं। यदि आप `mode: "non-main"` के साथ सैंडबॉक्सिंग सक्षम करते हैं, तो वे समूह सेशन कॉन्फ़िगर किए गए सैंडबॉक्स बैकएंड में चलते हैं, जबकि आपका मुख्य DM सेशन होस्ट पर रहता है। यदि आप कोई बैकएंड नहीं चुनते, तो Docker डिफ़ॉल्ट बैकएंड होता है। इससे आपको एजेंट का एक "मस्तिष्क" (साझा वर्कस्पेस + मेमोरी), लेकिन निष्पादन की दो स्थितियाँ मिलती हैं: - **DM**: पूर्ण टूल (होस्ट) - **समूह**: सैंडबॉक्स + प्रतिबंधित टूल यदि आपको वास्तव में अलग-अलग वर्कस्पेस/व्यक्तित्व चाहिए ("निजी" और "सार्वजनिक" कभी मिश्रित नहीं होने चाहिए), तो दूसरे एजेंट + बाइंडिंग का उपयोग करें। [मल्टी-एजेंट रूटिंग](/hi/concepts/multi-agent) देखें। ```json5 { agents: { defaults: { sandbox: { mode: "non-main", // समूह/चैनल गैर-मुख्य हैं -> सैंडबॉक्स किए गए scope: "session", // सबसे मजबूत पृथक्करण (प्रत्येक समूह/चैनल के लिए एक कंटेनर) workspaceAccess: "none", }, }, }, tools: { sandbox: { tools: { // यदि allow रिक्त नहीं है, तो बाकी सब कुछ ब्लॉक होता है (deny की प्राथमिकता फिर भी रहती है)। allow: ["group:messaging", "group:sessions"], deny: ["group:runtime", "group:fs", "group:ui", "nodes", "cron", "gateway"], }, }, }, } ``` "होस्ट एक्सेस नहीं" के बजाय "समूह केवल फ़ोल्डर X देख सकते हैं" चाहिए? `workspaceAccess: "none"` बनाए रखें और केवल अनुमति-सूची वाले पाथ सैंडबॉक्स में माउंट करें: ```json5 { agents: { defaults: { sandbox: { mode: "non-main", scope: "session", workspaceAccess: "none", docker: { binds: [ // hostPath:containerPath:mode "/home/user/FriendsShared:/data:ro", ], }, }, }, }, } ``` संबंधित: - कॉन्फ़िगरेशन कुंजियाँ और डिफ़ॉल्ट: [Gateway कॉन्फ़िगरेशन](/hi/gateway/config-agents#agentsdefaultssandbox) - टूल के ब्लॉक होने का कारण डीबग करना: [सैंडबॉक्स बनाम टूल नीति बनाम उन्नत](/hi/gateway/sandbox-vs-tool-policy-vs-elevated) - बाइंड माउंट का विवरण: [सैंडबॉक्सिंग](/hi/gateway/sandboxing#custom-bind-mounts) ## प्रदर्शन लेबल - उपलब्ध होने पर UI लेबल `displayName` का उपयोग करते हैं, जिसे `:` के रूप में फ़ॉर्मैट किया जाता है। - `#room` रूम/चैनल के लिए आरक्षित है; समूह चैट `g-` का उपयोग करती हैं (लोअरकेस, रिक्त स्थान -> `-`, `#@+._-` बनाए रखें)। बहुत लंबी अपारदर्शी आईडी को UI में पूर्ण रूट आईडी उजागर करने के बजाय एक स्थिर टोकन में छोटा किया जाता है। ## समूह नीति प्रत्येक चैनल के लिए समूह/रूम संदेशों के प्रबंधन का तरीका नियंत्रित करें: ```json5 { channels: { whatsapp: { groupPolicy: "disabled", // "open" | "disabled" | "allowlist" groupAllowFrom: ["+15551234567"], }, telegram: { groupPolicy: "disabled", groupAllowFrom: ["123456789"], // संख्यात्मक Telegram उपयोगकर्ता आईडी (सेटअप @username को हल करता है) }, signal: { groupPolicy: "disabled", groupAllowFrom: ["+15551234567"], }, imessage: { groupPolicy: "disabled", groupAllowFrom: ["chat_id:123"], }, msteams: { groupPolicy: "disabled", groupAllowFrom: ["user@org.com"], }, discord: { groupPolicy: "allowlist", guilds: { GUILD_ID: { channels: { help: { enabled: true } } }, }, }, slack: { groupPolicy: "allowlist", channels: { "#general": { enabled: true } }, }, matrix: { groupPolicy: "allowlist", groupAllowFrom: ["@owner:example.org"], groups: { "!roomId:example.org": { enabled: true }, "#alias:example.org": { enabled: true }, }, }, }, } ``` | नीति | व्यवहार | | ------------- | --------------------------------------------------------------------- | | `"open"` | समूह अनुमति-सूचियों को दरकिनार करते हैं; उल्लेख-गेटिंग फिर भी लागू होती है। | | `"disabled"` | सभी समूह संदेशों को पूरी तरह अवरुद्ध करें। | | `"allowlist"` | केवल कॉन्फ़िगर की गई अनुमति-सूची से मेल खाने वाले समूहों/कक्षों को अनुमति दें। | - `groupPolicy` उल्लेख-गेटिंग (जिसके लिए @mentions आवश्यक हैं) से अलग है। - WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: `groupAllowFrom` का उपयोग करें (फ़ॉलबैक: स्पष्ट `allowFrom`)। - Signal: `groupAllowFrom` आने वाले Signal समूह आईडी या प्रेषक के फ़ोन/UUID में से किसी से भी मेल खा सकता है। - DM पेयरिंग अनुमोदन (`*-allowFrom` स्टोर प्रविष्टियाँ) केवल DM पहुँच पर लागू होते हैं; समूह प्रेषक प्राधिकरण समूह अनुमति-सूचियों में स्पष्ट रूप से निर्धारित रहता है। - Discord: अनुमति-सूची `channels.discord.guilds..channels` का उपयोग करती है। - Slack: अनुमति-सूची `channels.slack.channels` का उपयोग करती है। - Matrix: अनुमति-सूची `channels.matrix.groups` का उपयोग करती है। कक्ष आईडी (`!room:server`) या उपनाम (`#alias:server`) का उपयोग करें; कक्ष-नाम कुंजियाँ केवल `channels.matrix.dangerouslyAllowNameMatching: true` के साथ मेल खाती हैं, और अनसुलझी प्रविष्टियों को रनटाइम पर अनदेखा किया जाता है। प्रेषकों को प्रतिबंधित करने के लिए `channels.matrix.groupAllowFrom` का उपयोग करें; प्रति-कक्ष `users` अनुमति-सूचियाँ भी समर्थित हैं। - समूह DM अलग से नियंत्रित होते हैं (`channels.discord.dm.*`, `channels.slack.dm.*`: `groupEnabled`, `groupChannels`)। - Telegram: प्रेषक अनुमति-सूचियाँ केवल संख्यात्मक उपयोगकर्ता आईडी स्वीकार करती हैं (`"123456789"`; `telegram:`/`tg:` उपसर्गों को केस-असंवेदी ढंग से हटा दिया जाता है)। `@username` प्रविष्टियाँ रनटाइम पर मेल नहीं खातीं और चेतावनी लॉग करती हैं; सेटअप `@username` को आईडी में हल करता है। ऋणात्मक चैट आईडी प्रेषक अनुमति-सूचियों में नहीं, बल्कि `channels.telegram.groups` के अंतर्गत रखी जाती हैं। - डिफ़ॉल्ट `groupPolicy: "allowlist"` है; यदि आपकी समूह अनुमति-सूची खाली है, तो समूह संदेश अवरुद्ध कर दिए जाते हैं। - रनटाइम सुरक्षा: जब कोई प्रदाता ब्लॉक पूरी तरह अनुपस्थित होता है (`channels.` अनुपस्थित), तो समूह नीति `channels.defaults.groupPolicy` को इनहेरिट करने के बजाय सुरक्षित रूप से `allowlist` पर विफल होती है, और Gateway प्रत्येक खाते के लिए फ़ॉलबैक को एक बार लॉग करता है। त्वरित मानसिक मॉडल (समूह संदेशों के लिए मूल्यांकन क्रम): `groupPolicy` (open/disabled/allowlist)। समूह अनुमति-सूचियाँ (`*.groups`, `*.groupAllowFrom`, चैनल-विशिष्ट अनुमति-सूची)। उल्लेख-गेटिंग (`requireMention`, `/activation`)। ## उल्लेख-गेटिंग (डिफ़ॉल्ट) समूह संदेशों के लिए उल्लेख आवश्यक है, जब तक कि प्रति समूह इसे ओवरराइड न किया गया हो। डिफ़ॉल्ट प्रत्येक उपतंत्र के लिए `*.groups."*"` के अंतर्गत होते हैं। समर्थित अंतर्निहित उल्लेख तथ्य चैनल-विशिष्ट हैं: | तथ्य | वर्तमान अंतर्निर्मित उत्पादक | | ----------------------- | ---------------------------------------------------- | | बॉट को उत्तर | Discord, Microsoft Teams, QQBot, Slack, Telegram | | बॉट का उद्धरण | WhatsApp, Zalo personal | | बॉट थ्रेड में शामिल हुआ | Mattermost, Slack, Tlon | चैनल द्वारा प्रत्येक तथ्य उत्पन्न किए जाने पर वह डिफ़ॉल्ट रूप से सक्षम होता है। उस तथ्य को उल्लेख-गेटिंग दरकिनार करने से रोकने के लिए संबंधित `implicitMentions` फ़्लैग को `false` पर सेट करें; मूल स्पष्ट उल्लेख अप्रभावित रहते हैं। जो चैनल उस तथ्य को उत्पन्न नहीं करते, उन पर फ़्लैग का कोई प्रभाव नहीं होता। ```json5 { channels: { whatsapp: { groups: { "*": { requireMention: true }, "123@g.us": { requireMention: false }, }, }, telegram: { groups: { "*": { requireMention: true }, "123456789": { requireMention: false }, }, }, imessage: { groups: { "*": { requireMention: true }, "123": { requireMention: false }, }, }, }, agents: { entries: { main: { groupChat: { mentionPatterns: ["@openclaw", "openclaw", "\\+15555550123"], historyLimit: 50, }, }, }, }, } ``` ## कॉन्फ़िगर किए गए उल्लेख पैटर्न का दायरा कॉन्फ़िगर किए गए `mentionPatterns` रेगेक्स फ़ॉलबैक ट्रिगर हैं। उनका उपयोग तब करें जब प्लेटफ़ॉर्म मूल बॉट उल्लेख उपलब्ध नहीं कराता, या जब आप चाहते हैं कि `openclaw:` जैसा सामान्य टेक्स्ट उल्लेख माना जाए। मूल प्लेटफ़ॉर्म उल्लेख अलग होते हैं: जब Discord, Slack, Telegram, Matrix, Signal या कोई अन्य चैनल यह प्रमाणित कर सकता है कि संदेश में बॉट का स्पष्ट रूप से उल्लेख हुआ है, तब कॉन्फ़िगर किए गए रेगेक्स पैटर्न अस्वीकृत होने पर भी वह मूल उल्लेख ट्रिगर करता है। डिफ़ॉल्ट रूप से, कॉन्फ़िगर किए गए उल्लेख पैटर्न हर उस स्थान पर लागू होते हैं जहाँ चैनल प्रदाता और वार्तालाप तथ्यों को उल्लेख पहचान में भेजता है। व्यापक पैटर्न से एजेंट को प्रत्येक समूह में सक्रिय होने से रोकने के लिए, `channels..mentionPatterns` के साथ प्रति चैनल उनका दायरा निर्धारित करें। जब किसी चैनल के लिए रेगेक्स उल्लेख पैटर्न डिफ़ॉल्ट रूप से बंद होने चाहिए, तब `mode: "deny"` का उपयोग करें और फिर `allowIn` के साथ विशिष्ट कक्षों को शामिल करें: ```json5 { messages: { groupChat: { mentionPatterns: ["\\bopenclaw\\b", "\\bops bot\\b"], }, }, channels: { slack: { mentionPatterns: { mode: "deny", allowIn: ["C0123OPS"], }, }, }, } ``` जब रेगेक्स उल्लेख पैटर्न व्यापक रूप से लागू होने चाहिए, तब डिफ़ॉल्ट `mode: "allow"` का उपयोग करें (या `mode` को छोड़ दें), फिर `denyIn` के साथ शोरगुल वाले कक्षों में उन्हें बंद करें: ```json5 { messages: { groupChat: { mentionPatterns: ["\\bopenclaw\\b"], }, }, channels: { telegram: { mentionPatterns: { denyIn: ["-1001234567890", "-1001234567890:topic:42"], }, }, }, } ``` नीति समाधान: | फ़ील्ड | प्रभाव | | --------------- | --------------------------------------------------------------------------------------------------------------------- | | `mode: "allow"` | रेगेक्स उल्लेख पैटर्न तब तक सक्षम रहते हैं, जब तक वार्तालाप आईडी `denyIn` में न हो। यह डिफ़ॉल्ट है। | | `mode: "deny"` | रेगेक्स उल्लेख पैटर्न तब तक अक्षम रहते हैं, जब तक वार्तालाप आईडी `allowIn` में न हो। | | `allowIn` | वे वार्तालाप आईडी जहाँ अस्वीकार मोड में रेगेक्स उल्लेख पैटर्न सक्षम होते हैं। | | `denyIn` | वे वार्तालाप आईडी जहाँ रेगेक्स उल्लेख पैटर्न अक्षम होते हैं। यदि दोनों में समान आईडी शामिल हो, तो `denyIn`, `allowIn` पर प्राथमिकता लेता है। | वर्तमान में समर्थित दायरा-निर्धारित रेगेक्स नीति: | चैनल | `allowIn` / `denyIn` में उपयोग की जाने वाली आईडी | | -------- | ------------------------------------------------------------ | | Discord | Discord चैनल आईडी। | | Matrix | Matrix कक्ष आईडी। | | Slack | Slack चैनल आईडी। | | Telegram | समूह चैट आईडी, या फ़ोरम विषयों के लिए `chatId:topic:threadId`। | | WhatsApp | `123@g.us` जैसी WhatsApp वार्तालाप आईडी। | जब वह चैनल एकाधिक खातों का समर्थन करता है, तब खाता-स्तरीय चैनल कॉन्फ़िगरेशन `channels..accounts..mentionPatterns` के अंतर्गत वही नीति सेट कर सकते हैं। उस खाते के लिए खाता नीति शीर्ष-स्तरीय चैनल नीति पर प्राथमिकता लेती है। - `mentionPatterns` केस-असंवेदी सुरक्षित रेगेक्स पैटर्न हैं; अमान्य पैटर्न और असुरक्षित नेस्टेड-पुनरावृत्ति रूपों को चेतावनी के साथ अनदेखा किया जाता है। - पैटर्न प्राथमिकता: `agents.entries.*.groupChat.mentionPatterns` (जब एकाधिक एजेंट एक समूह साझा करते हैं तब उपयोगी) `messages.groupChat.mentionPatterns` को ओवरराइड करता है; जब दोनों में से कोई सेट न हो, तब पैटर्न एजेंट की पहचान के नाम/इमोजी से निकाले जाते हैं। - उल्लेख-गेटिंग केवल तभी लागू की जाती है जब उल्लेख पहचान संभव हो (मूल उल्लेख या `mentionPatterns` कॉन्फ़िगर किए गए हों)। - किसी समूह या प्रेषक को अनुमति-सूची में शामिल करने से उल्लेख-गेटिंग अक्षम नहीं होती; जब सभी संदेशों को ट्रिगर करना चाहिए, तब उस समूह के `requireMention` को `false` पर सेट करें। - स्वचालित समूह चैट प्रॉम्प्ट संदर्भ प्रत्येक टर्न पर हल किया गया मौन-उत्तर निर्देश साथ रखता है; कार्यस्थान फ़ाइलों को `NO_REPLY` कार्यविधि की नकल नहीं करनी चाहिए। - वे समूह जहाँ स्वचालित मौन उत्तरों की अनुमति है, साफ़ खाली या केवल-रीज़निंग मॉडल टर्न को `NO_REPLY` के समकक्ष मौन मानते हैं। प्रत्यक्ष चैट को कभी `NO_REPLY` मार्गदर्शन नहीं मिलता, और केवल-संदेश-टूल समूह उत्तर `message(action=send)` को कॉल न करके शांत रहते हैं। - परिवेशी सदैव-सक्रिय समूह वार्तालाप डिफ़ॉल्ट रूप से उपयोगकर्ता-अनुरोध सिमेंटिक्स का उपयोग करता है। इसके बजाय इसे शांत संदर्भ के रूप में सबमिट करने के लिए `messages.groupChat.unmentionedInbound: "room_event"` सेट करें। सेटअप उदाहरणों के लिए [परिवेशी कक्ष घटनाएँ](/hi/channels/ambient-room-events) देखें। - कक्ष घटनाएँ नकली उपयोगकर्ता अनुरोधों के रूप में संग्रहीत नहीं की जातीं, और बिना-संदेश-टूल वाली कक्ष घटनाओं का निजी सहायक टेक्स्ट चैट इतिहास के रूप में दोबारा नहीं चलाया जाता। - Discord के डिफ़ॉल्ट `channels.discord.guilds."*"` में होते हैं (प्रति गिल्ड/चैनल ओवरराइड किए जा सकते हैं)। - समूह इतिहास संदर्भ सभी चैनलों में एकसमान रूप से लपेटा जाता है। उल्लेख-गेटेड समूह लंबित छोड़े गए संदेश रखते हैं; सदैव-सक्रिय समूह भी हाल के संसाधित कक्ष संदेश रख सकते हैं, यदि चैनल इसका समर्थन करता हो। वैश्विक डिफ़ॉल्ट के लिए `messages.groupChat.historyLimit` और ओवरराइड के लिए `channels..historyLimit` (या `channels..accounts.*.historyLimit`) का उपयोग करें। अक्षम करने के लिए `0` सेट करें। ## समूह/चैनल टूल प्रतिबंध (वैकल्पिक) कुछ चैनल कॉन्फ़िगरेशन यह प्रतिबंधित करने का समर्थन करते हैं कि **किसी विशिष्ट समूह/कक्ष/चैनल के भीतर** कौन-से टूल उपलब्ध हैं। - `tools`: पूरे समूह के लिए टूल को अनुमति दें/अस्वीकार करें (`allow`, `alsoAllow`, `deny`; अस्वीकार को प्राथमिकता मिलती है)। - `toolsBySender`: समूह के भीतर प्रति-प्रेषक ओवरराइड। स्पष्ट कुंजी उपसर्गों का उपयोग करें: `channel::`, `id:`, `e164:`, `username:`, `name:`, और `"*"` वाइल्डकार्ड। चैनल आईडी प्रामाणिक OpenClaw चैनल आईडी का उपयोग करती हैं; `teams` जैसे उपनाम `msteams` में सामान्यीकृत होते हैं। पुराने उपसर्ग-रहित कुंजी रूप अभी भी स्वीकार किए जाते हैं, केवल `id:` के रूप में मिलाए जाते हैं, और एक अप्रचलन चेतावनी लॉग करते हैं। समाधान क्रम (सबसे विशिष्ट को प्राथमिकता): समूह/चैनल `toolsBySender` मिलान। समूह/चैनल `tools`। डिफ़ॉल्ट (`"*"`) `toolsBySender` मिलान। डिफ़ॉल्ट (`"*"`) `tools`। उदाहरण (Telegram): ```json5 { channels: { telegram: { groups: { "*": { tools: { deny: ["exec"] } }, "-1001234567890": { tools: { deny: ["exec", "read", "write"] }, toolsBySender: { "id:123456789": { alsoAllow: ["exec"] }, }, }, }, }, }, } ``` समूह/चैनल टूल प्रतिबंध वैश्विक/एजेंट टूल नीति के अतिरिक्त लागू होते हैं (अस्वीकृति को फिर भी प्राथमिकता मिलती है)। कुछ चैनल कक्षों/चैनलों के लिए अलग नेस्टिंग का उपयोग करते हैं (उदा., Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`)। ## समूह अनुमति-सूचियाँ जब `channels.whatsapp.groups`, `channels.telegram.groups`, या `channels.imessage.groups` कॉन्फ़िगर किया जाता है, तो कुंजियाँ समूह अनुमति-सूची के रूप में कार्य करती हैं। डिफ़ॉल्ट उल्लेख व्यवहार सेट रखते हुए सभी समूहों को अनुमति देने के लिए `"*"` का उपयोग करें। सामान्य भ्रम: DM पेयरिंग अनुमोदन, समूह प्राधिकरण के समान नहीं है। DM पेयरिंग का समर्थन करने वाले चैनलों के लिए, पेयरिंग स्टोर केवल DMs को अनलॉक करता है। समूह कमांड के लिए फिर भी `groupAllowFrom` जैसी कॉन्फ़िगरेशन अनुमति-सूचियों या उस चैनल के लिए दस्तावेज़ीकृत कॉन्फ़िगरेशन फ़ॉलबैक से स्पष्ट समूह प्रेषक प्राधिकरण आवश्यक है। सामान्य उद्देश्य (कॉपी/पेस्ट करें): ```json5 { channels: { whatsapp: { groupPolicy: "disabled" } }, } ``` ```json5 { channels: { whatsapp: { groups: { "123@g.us": { requireMention: true }, "456@g.us": { requireMention: false }, }, }, }, } ``` ```json5 { channels: { whatsapp: { groups: { "*": { requireMention: true } }, }, }, } ``` ```json5 { channels: { whatsapp: { groupPolicy: "allowlist", groupAllowFrom: ["+15551234567"], groups: { "*": { requireMention: true } }, }, }, } ``` ## सक्रियण (केवल स्वामी) समूह स्वामी एक स्वतंत्र संदेश से प्रत्येक समूह के सक्रियण को टॉगल कर सकते हैं: - `/activation mention` - `/activation always` `/activation` एक मुख्य स्वामी-प्रतिबंधित कमांड है और केवल समूह चैट में लागू होता है। स्वामी का अर्थ है कि प्रेषक `commands.ownerAllowFrom` से मेल खाता है; चैनल `allowFrom` सूचियाँ केवल सामान्य चैनल और कमांड पहुँच नियंत्रित करती हैं। जो चैनल संग्रहीत मोड का उपयोग करते हैं (Google Chat, QQBot, Telegram, WhatsApp), उनमें यह मोड उस समूह के `requireMention` को ओवरराइड करता है, और समूह सिस्टम-प्रॉम्प्ट परिचय हर जगह सक्रिय मोड दर्शाता है। ## संदर्भ फ़ील्ड समूह के इनबाउंड पेलोड ये सेट करते हैं: - `ChatType=group` - `GroupSubject` (यदि ज्ञात हो) - `GroupMembers` (यदि ज्ञात हो) - `WasMentioned` (उल्लेख गेटिंग का परिणाम) - Telegram फ़ोरम विषयों में `MessageThreadId` और `IsForum` भी शामिल होते हैं। एजेंट सिस्टम प्रॉम्प्ट में नए समूह सत्र के पहले टर्न पर (और `/activation` बदलने के बाद) समूह परिचय शामिल होता है। यह मॉडल को मनुष्य की तरह उत्तर देने, खाली पंक्तियाँ न्यूनतम रखने और सामान्य चैट रिक्ति का पालन करने तथा अक्षरशः `\n` अनुक्रम टाइप करने से बचने की याद दिलाता है। जिन चैनलों का घोषित तालिका मोड नेटिव या रॉ तालिकाओं को बनाए नहीं रखता, वे Markdown तालिकाओं को भी हतोत्साहित करते हैं। चैनल से प्राप्त समूह नाम और प्रतिभागी लेबल इनलाइन सिस्टम निर्देशों के रूप में नहीं, बल्कि फ़ेंस किए गए अविश्वसनीय मेटाडेटा के रूप में रेंडर होते हैं। ## iMessage की विशिष्टताएँ - रूटिंग या अनुमति-सूची बनाते समय `chat_id:` को प्राथमिकता दें। - चैट सूचीबद्ध करें: `imsg chats --limit 20`। - समूह उत्तर हमेशा उसी `chat_id` पर वापस जाते हैं। ## WhatsApp सिस्टम प्रॉम्प्ट समूह और प्रत्यक्ष प्रॉम्प्ट समाधान, वाइल्डकार्ड व्यवहार तथा खाता ओवरराइड अर्थविज्ञान सहित प्रामाणिक WhatsApp सिस्टम प्रॉम्प्ट नियमों के लिए [WhatsApp](/hi/channels/whatsapp#system-prompts) देखें। ## WhatsApp की विशिष्टताएँ केवल WhatsApp के व्यवहार (इतिहास अंतःक्षेपण, उल्लेख प्रबंधन विवरण) के लिए [समूह संदेश](/hi/channels/group-messages) देखें। ## संबंधित - [प्रसारण समूह](/hi/channels/broadcast-groups) - [चैनल रूटिंग](/hi/channels/channel-routing) - [समूह संदेश](/hi/channels/group-messages) - [पेयरिंग](/hi/channels/pairing)