Skip to main content
OpenClaw समूह-सक्षम चैनलों में समान समूह नियम लागू करता है, जिनमें Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp और Zalo शामिल हैं। हमेशा सक्रिय रहने वाले उन रूम के लिए, जिन्हें एजेंट द्वारा स्पष्ट रूप से दृश्यमान संदेश भेजे जाने तक शांत संदर्भ प्रदान करना चाहिए, परिवेशी रूम इवेंट देखें।

शुरुआती परिचय (2 मिनट)

OpenClaw आपके अपने मैसेजिंग खातों पर “रहता” है। कोई अलग WhatsApp बॉट उपयोगकर्ता नहीं होता: यदि आप किसी समूह में हैं, तो OpenClaw उस समूह को देख सकता है और वहाँ जवाब दे सकता है। डिफ़ॉल्ट व्यवहार:
  • समूह प्रतिबंधित होते हैं (groupPolicy: "allowlist"); समूह के प्रेषकों को अनुमति-सूची में जोड़े जाने तक ब्लॉक किया जाता है।
  • जब तक आप किसी समूह के लिए उल्लेख गेटिंग अक्षम नहीं करते, जवाबों के लिए उल्लेख आवश्यक होता है।
  • अंतिम जवाब का टेक्स्ट रूम में अपने-आप पोस्ट होता है (visibleReplies: "automatic")।
अर्थात: अनुमति-सूची में शामिल प्रेषक OpenClaw का उल्लेख करके उसे ट्रिगर कर सकते हैं।
संक्षेप में
  • DM एक्सेस को *.allowFrom नियंत्रित करता है।
  • समूह एक्सेस को *.groupPolicy + अनुमति-सूचियाँ (*.groups, *.groupAllowFrom) नियंत्रित करती हैं।
  • जवाब ट्रिगर करना उल्लेख गेटिंग (requireMention, /activation) द्वारा नियंत्रित होता है।
त्वरित प्रवाह (समूह संदेश के साथ क्या होता है):

दृश्यमान जवाब

सामान्य समूह/चैनल अनुरोधों के लिए, 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 का उपयोग करें। विस्तृत स्थिति प्रत्येक सेशन के लिए अलग होती है और प्रत्यक्ष चैट, समूहों, चैनलों तथा फ़ोरम विषयों में समान रूप से काम करती है। उल्लेख-रहित हमेशा सक्रिय समूह वार्तालाप को उपयोगकर्ता अनुरोधों के बजाय शांत रूम संदर्भ के रूप में सबमिट करने के लिए परिवेशी रूम इवेंट का उपयोग करें:
डिफ़ॉल्ट unmentionedInbound: "user_request" है। उल्लेखित संदेश, कमांड, निरस्तीकरण अनुरोध और DM उपयोगकर्ता अनुरोध ही रहते हैं। समूह/चैनल अनुरोधों के दृश्यमान आउटपुट को संदेश टूल के माध्यम से भेजना आवश्यक बनाने के लिए:
प्रत्येक स्रोत चैट के लिए इसे आवश्यक बनाने हेतु:
फ़ाइल सहेजे जाने के बाद Gateway, messages कॉन्फ़िगरेशन परिवर्तनों को रीस्टार्ट के बिना अपना लेता है। केवल तभी रीस्टार्ट करें जब कॉन्फ़िगरेशन रीलोड अक्षम हो (gateway.reload.mode: "off")। कमांड टर्न visibleReplies: "message_tool" को बायपास करते हैं और हमेशा दृश्यमान रूप से जवाब देते हैं: नेटिव स्लैश कमांड (Discord, Telegram और नेटिव कमांड समर्थन वाले अन्य इंटरफ़ेस) तथा अधिकृत टेक्स्ट /... कमांड, दोनों अपना जवाब स्रोत चैट में पोस्ट करते हैं। समूहों में अनधिकृत टेक्स्ट /... टर्न केवल-संदेश-टूल बने रहते हैं; सामान्य चैट टर्न कॉन्फ़िगर किए गए डिफ़ॉल्ट का पालन करते हैं।

संदर्भ दृश्यता और अनुमति-सूचियाँ

समूह सुरक्षा में दो अलग-अलग नियंत्रण शामिल होते हैं:
  • ट्रिगर प्राधिकरण: एजेंट को कौन ट्रिगर कर सकता है (groupPolicy, groups, groupAllowFrom, चैनल-विशिष्ट अनुमति-सूचियाँ)।
  • संदर्भ दृश्यता: मॉडल में कौन-सा पूरक संदर्भ डाला जाता है (जवाब/उद्धरण टेक्स्ट, थ्रेड इतिहास, फ़ॉरवर्ड किया गया मेटाडेटा)।
डिफ़ॉल्ट रूप से OpenClaw संदर्भ को प्राप्त रूप में ही रखता है: अनुमति-सूचियाँ तय करती हैं कि कार्रवाइयाँ कौन ट्रिगर कर सकता है, न कि मॉडल को कौन-से उद्धृत या ऐतिहासिक अंश दिखाई देते हैं। पूरक संदर्भ को भी फ़िल्टर करने के लिए contextVisibility सेट करें: इसे प्रत्येक चैनल (channels.<channel>.contextVisibility), प्रत्येक खाते (channels.<channel>.accounts.<accountId>.contextVisibility) या वैश्विक रूप से (channels.defaults.contextVisibility) सेट करें। पूरक संदर्भ प्राप्त करने वाले चैनल (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp) इनबाउंड संदर्भ बनाते समय यह नीति लागू करते हैं; अज्ञात नीति संयोजन सुरक्षित रूप से विफल होते हैं और संदर्भ को छोड़ देते हैं। ये मोड केवल चैनल द्वारा दिए गए पूरक संदर्भ को फ़िल्टर करते हैं। टूल नीति और केवल-स्वामी टूल सूची अब भी वर्तमान टर्न के मूल अनुरोधकर्ता के आधार पर चुनी जाती हैं, न कि प्रॉम्प्ट में दर्शाए गए प्रत्येक प्रेषक के आधार पर। अनुरोधकर्ता-स्कोप वाले नियंत्रण और प्रॉम्प्ट संदर्भ देखें। समूह संदेश प्रवाह यदि आप चाहते हैं… पुनः उपयोग योग्य प्रेषक अनुमति-सूचियों के लिए एक्सेस समूह देखें।

सेशन कुंजियाँ

  • समूह सेशन agent:<agentId>:<channel>:group:<id> सेशन कुंजियों का उपयोग करते हैं (रूम/चैनल agent:<agentId>:<channel>:channel:<id> का उपयोग करते हैं)।
  • Telegram फ़ोरम विषय समूह आईडी में :topic:<threadId> जोड़ते हैं, ताकि प्रत्येक विषय का अपना सेशन हो।
  • प्रत्यक्ष चैट मुख्य सेशन का उपयोग करती हैं (या यदि session.dmScope कॉन्फ़िगर किया गया है, तो प्रत्येक प्रेषक के लिए अलग सेशन)।
  • Heartbeats कॉन्फ़िगर किए गए Heartbeat सेशन में चलते हैं (डिफ़ॉल्ट: एजेंट का मुख्य सेशन); समूह सेशन अपने Heartbeats नहीं चलाते।

पैटर्न: निजी DM + सार्वजनिक समूह (एक एजेंट)

हाँ — यदि आपका “निजी” ट्रैफ़िक DM है और आपका “सार्वजनिक” ट्रैफ़िक समूह है, तो यह अच्छी तरह काम करता है। कारण: एकल-एजेंट मोड में, DM सामान्यतः मुख्य सेशन कुंजी (agent:main:main) में पहुँचते हैं, जबकि समूह हमेशा गैर-मुख्य सेशन कुंजियों (agent:main:<channel>:group:<id>) का उपयोग करते हैं। यदि आप mode: "non-main" के साथ सैंडबॉक्सिंग सक्षम करते हैं, तो वे समूह सेशन कॉन्फ़िगर किए गए सैंडबॉक्स बैकएंड में चलते हैं, जबकि आपका मुख्य DM सेशन होस्ट पर रहता है। यदि आप कोई बैकएंड नहीं चुनते, तो Docker डिफ़ॉल्ट बैकएंड होता है। इससे आपको एजेंट का एक “मस्तिष्क” (साझा वर्कस्पेस + मेमोरी), लेकिन निष्पादन की दो स्थितियाँ मिलती हैं:
  • DM: पूर्ण टूल (होस्ट)
  • समूह: सैंडबॉक्स + प्रतिबंधित टूल
यदि आपको वास्तव में अलग-अलग वर्कस्पेस/व्यक्तित्व चाहिए (“निजी” और “सार्वजनिक” कभी मिश्रित नहीं होने चाहिए), तो दूसरे एजेंट + बाइंडिंग का उपयोग करें। मल्टी-एजेंट रूटिंग देखें।
संबंधित:

प्रदर्शन लेबल

  • उपलब्ध होने पर UI लेबल displayName का उपयोग करते हैं, जिसे <channel>:<token> के रूप में फ़ॉर्मैट किया जाता है।
  • #room रूम/चैनल के लिए आरक्षित है; समूह चैट g-<slug> का उपयोग करती हैं (लोअरकेस, रिक्त स्थान -> -, #@+._- बनाए रखें)। बहुत लंबी अपारदर्शी आईडी को UI में पूर्ण रूट आईडी उजागर करने के बजाय एक स्थिर टोकन में छोटा किया जाता है।

समूह नीति

प्रत्येक चैनल के लिए समूह/रूम संदेशों के प्रबंधन का तरीका नियंत्रित करें:
  • groupPolicy उल्लेख-गेटिंग (जिसके लिए @mentions आवश्यक हैं) से अलग है।
  • WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: groupAllowFrom का उपयोग करें (फ़ॉलबैक: स्पष्ट allowFrom)।
  • Signal: groupAllowFrom आने वाले Signal समूह आईडी या प्रेषक के फ़ोन/UUID में से किसी से भी मेल खा सकता है।
  • DM पेयरिंग अनुमोदन (*-allowFrom स्टोर प्रविष्टियाँ) केवल DM पहुँच पर लागू होते हैं; समूह प्रेषक प्राधिकरण समूह अनुमति-सूचियों में स्पष्ट रूप से निर्धारित रहता है।
  • Discord: अनुमति-सूची channels.discord.guilds.<id>.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.<provider> अनुपस्थित), तो समूह नीति channels.defaults.groupPolicy को इनहेरिट करने के बजाय सुरक्षित रूप से allowlist पर विफल होती है, और Gateway प्रत्येक खाते के लिए फ़ॉलबैक को एक बार लॉग करता है।
त्वरित मानसिक मॉडल (समूह संदेशों के लिए मूल्यांकन क्रम):
1

groupPolicy

groupPolicy (open/disabled/allowlist)।
2

समूह अनुमति-सूचियाँ

समूह अनुमति-सूचियाँ (*.groups, *.groupAllowFrom, चैनल-विशिष्ट अनुमति-सूची)।
3

उल्लेख-गेटिंग

उल्लेख-गेटिंग (requireMention, /activation)।

उल्लेख-गेटिंग (डिफ़ॉल्ट)

समूह संदेशों के लिए उल्लेख आवश्यक है, जब तक कि प्रति समूह इसे ओवरराइड न किया गया हो। डिफ़ॉल्ट प्रत्येक उपतंत्र के लिए *.groups."*" के अंतर्गत होते हैं। समर्थित अंतर्निहित उल्लेख तथ्य चैनल-विशिष्ट हैं: चैनल द्वारा प्रत्येक तथ्य उत्पन्न किए जाने पर वह डिफ़ॉल्ट रूप से सक्षम होता है। उस तथ्य को उल्लेख-गेटिंग दरकिनार करने से रोकने के लिए संबंधित implicitMentions फ़्लैग को false पर सेट करें; मूल स्पष्ट उल्लेख अप्रभावित रहते हैं। जो चैनल उस तथ्य को उत्पन्न नहीं करते, उन पर फ़्लैग का कोई प्रभाव नहीं होता।

कॉन्फ़िगर किए गए उल्लेख पैटर्न का दायरा

कॉन्फ़िगर किए गए mentionPatterns रेगेक्स फ़ॉलबैक ट्रिगर हैं। उनका उपयोग तब करें जब प्लेटफ़ॉर्म मूल बॉट उल्लेख उपलब्ध नहीं कराता, या जब आप चाहते हैं कि openclaw: जैसा सामान्य टेक्स्ट उल्लेख माना जाए। मूल प्लेटफ़ॉर्म उल्लेख अलग होते हैं: जब Discord, Slack, Telegram, Matrix, Signal या कोई अन्य चैनल यह प्रमाणित कर सकता है कि संदेश में बॉट का स्पष्ट रूप से उल्लेख हुआ है, तब कॉन्फ़िगर किए गए रेगेक्स पैटर्न अस्वीकृत होने पर भी वह मूल उल्लेख ट्रिगर करता है। डिफ़ॉल्ट रूप से, कॉन्फ़िगर किए गए उल्लेख पैटर्न हर उस स्थान पर लागू होते हैं जहाँ चैनल प्रदाता और वार्तालाप तथ्यों को उल्लेख पहचान में भेजता है। व्यापक पैटर्न से एजेंट को प्रत्येक समूह में सक्रिय होने से रोकने के लिए, channels.<channel>.mentionPatterns के साथ प्रति चैनल उनका दायरा निर्धारित करें। जब किसी चैनल के लिए रेगेक्स उल्लेख पैटर्न डिफ़ॉल्ट रूप से बंद होने चाहिए, तब mode: "deny" का उपयोग करें और फिर allowIn के साथ विशिष्ट कक्षों को शामिल करें:
जब रेगेक्स उल्लेख पैटर्न व्यापक रूप से लागू होने चाहिए, तब डिफ़ॉल्ट mode: "allow" का उपयोग करें (या mode को छोड़ दें), फिर denyIn के साथ शोरगुल वाले कक्षों में उन्हें बंद करें:
नीति समाधान: वर्तमान में समर्थित दायरा-निर्धारित रेगेक्स नीति: जब वह चैनल एकाधिक खातों का समर्थन करता है, तब खाता-स्तरीय चैनल कॉन्फ़िगरेशन channels.<channel>.accounts.<accountId>.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" सेट करें। सेटअप उदाहरणों के लिए परिवेशी कक्ष घटनाएँ देखें।
  • कक्ष घटनाएँ नकली उपयोगकर्ता अनुरोधों के रूप में संग्रहीत नहीं की जातीं, और बिना-संदेश-टूल वाली कक्ष घटनाओं का निजी सहायक टेक्स्ट चैट इतिहास के रूप में दोबारा नहीं चलाया जाता।
  • Discord के डिफ़ॉल्ट channels.discord.guilds."*" में होते हैं (प्रति गिल्ड/चैनल ओवरराइड किए जा सकते हैं)।
  • समूह इतिहास संदर्भ सभी चैनलों में एकसमान रूप से लपेटा जाता है। उल्लेख-गेटेड समूह लंबित छोड़े गए संदेश रखते हैं; सदैव-सक्रिय समूह भी हाल के संसाधित कक्ष संदेश रख सकते हैं, यदि चैनल इसका समर्थन करता हो। वैश्विक डिफ़ॉल्ट के लिए messages.groupChat.historyLimit और ओवरराइड के लिए channels.<channel>.historyLimit (या channels.<channel>.accounts.*.historyLimit) का उपयोग करें। अक्षम करने के लिए 0 सेट करें।

समूह/चैनल टूल प्रतिबंध (वैकल्पिक)

कुछ चैनल कॉन्फ़िगरेशन यह प्रतिबंधित करने का समर्थन करते हैं कि किसी विशिष्ट समूह/कक्ष/चैनल के भीतर कौन-से टूल उपलब्ध हैं।
  • tools: पूरे समूह के लिए टूल को अनुमति दें/अस्वीकार करें (allow, alsoAllow, deny; अस्वीकार को प्राथमिकता मिलती है)।
  • toolsBySender: समूह के भीतर प्रति-प्रेषक ओवरराइड। स्पष्ट कुंजी उपसर्गों का उपयोग करें: channel:<channelId>:<senderId>, id:<senderId>, e164:<phone>, username:<handle>, name:<displayName>, और "*" वाइल्डकार्ड। चैनल आईडी प्रामाणिक OpenClaw चैनल आईडी का उपयोग करती हैं; teams जैसे उपनाम msteams में सामान्यीकृत होते हैं। पुराने उपसर्ग-रहित कुंजी रूप अभी भी स्वीकार किए जाते हैं, केवल id: के रूप में मिलाए जाते हैं, और एक अप्रचलन चेतावनी लॉग करते हैं।
समाधान क्रम (सबसे विशिष्ट को प्राथमिकता):
1

समूह toolsBySender

समूह/चैनल toolsBySender मिलान।
2

समूह tools

समूह/चैनल tools
3

डिफ़ॉल्ट toolsBySender

डिफ़ॉल्ट ("*") toolsBySender मिलान।
4

डिफ़ॉल्ट tools

डिफ़ॉल्ट ("*") tools
उदाहरण (Telegram):
समूह/चैनल टूल प्रतिबंध वैश्विक/एजेंट टूल नीति के अतिरिक्त लागू होते हैं (अस्वीकृति को फिर भी प्राथमिकता मिलती है)। कुछ चैनल कक्षों/चैनलों के लिए अलग नेस्टिंग का उपयोग करते हैं (उदा., Discord guilds.*.channels.*, Slack channels.*, Microsoft Teams teams.*.channels.*)।

समूह अनुमति-सूचियाँ

जब channels.whatsapp.groups, channels.telegram.groups, या channels.imessage.groups कॉन्फ़िगर किया जाता है, तो कुंजियाँ समूह अनुमति-सूची के रूप में कार्य करती हैं। डिफ़ॉल्ट उल्लेख व्यवहार सेट रखते हुए सभी समूहों को अनुमति देने के लिए "*" का उपयोग करें।
सामान्य भ्रम: DM पेयरिंग अनुमोदन, समूह प्राधिकरण के समान नहीं है। DM पेयरिंग का समर्थन करने वाले चैनलों के लिए, पेयरिंग स्टोर केवल DMs को अनलॉक करता है। समूह कमांड के लिए फिर भी groupAllowFrom जैसी कॉन्फ़िगरेशन अनुमति-सूचियों या उस चैनल के लिए दस्तावेज़ीकृत कॉन्फ़िगरेशन फ़ॉलबैक से स्पष्ट समूह प्रेषक प्राधिकरण आवश्यक है।
सामान्य उद्देश्य (कॉपी/पेस्ट करें):

सक्रियण (केवल स्वामी)

समूह स्वामी एक स्वतंत्र संदेश से प्रत्येक समूह के सक्रियण को टॉगल कर सकते हैं:
  • /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:<id> को प्राथमिकता दें।
  • चैट सूचीबद्ध करें: imsg chats --limit 20
  • समूह उत्तर हमेशा उसी chat_id पर वापस जाते हैं।

WhatsApp सिस्टम प्रॉम्प्ट

समूह और प्रत्यक्ष प्रॉम्प्ट समाधान, वाइल्डकार्ड व्यवहार तथा खाता ओवरराइड अर्थविज्ञान सहित प्रामाणिक WhatsApp सिस्टम प्रॉम्प्ट नियमों के लिए WhatsApp देखें।

WhatsApp की विशिष्टताएँ

केवल WhatsApp के व्यवहार (इतिहास अंतःक्षेपण, उल्लेख प्रबंधन विवरण) के लिए समूह संदेश देखें।

संबंधित