उप-एजेंट्स

उप-एजेंट किसी मौजूदा एजेंट रन से शुरू किए गए पृष्ठभूमि एजेंट रन होते हैं। हर एक अपने स्वयं के सेशन (agent:<agentId>:subagent:<uuid>) में चलता है और, पूरा होने पर, अपना परिणाम अनुरोधकर्ता के चैट चैनल पर वापस घोषित करता है। हर उप-एजेंट रन को एक पृष्ठभूमि कार्य के रूप में ट्रैक किया जाता है।

लक्ष्य:

• मुख्य रन को अवरुद्ध किए बिना शोध, लंबे कार्यों और धीमे टूल कार्य को समानांतर रूप से चलाना।
• उप-एजेंट को डिफ़ॉल्ट रूप से पृथक रखना (सेशन पृथक्करण, वैकल्पिक सैंडबॉक्सिंग)।
• टूल सतह का दुरुपयोग कठिन बनाए रखना: उप-एजेंट को डिफ़ॉल्ट रूप से सेशन या संदेश टूल नहीं मिलते।
• ऑर्केस्ट्रेटर पैटर्न के लिए कॉन्फ़िगर करने योग्य नेस्टिंग गहराई का समर्थन करना।

स्लैश कमांड

/subagents वर्तमान सेशन के उप-एजेंट रन का निरीक्षण करता है:

/subagents list/subagents log <id|#> [limit] [tools]/subagents info <id|#>

/subagents info रन मेटाडेटा (स्थिति, टाइमस्टैम्प, सेशन आईडी, ट्रांसक्रिप्ट पथ, क्लीनअप) दिखाता है। /subagents log किसी रन के हाल के चैट टर्न प्रिंट करता है; टूल-कॉल/परिणाम संदेश शामिल करने के लिए tools टोकन जोड़ें (डिफ़ॉल्ट रूप से छोड़े जाते हैं)। किसी एजेंट टर्न के भीतर से सीमित, सुरक्षा-फ़िल्टर किया हुआ रिकॉल दृश्य पाने के लिए sessions_history का उपयोग करें, या कच्ची पूर्ण ट्रांसक्रिप्ट के लिए डिस्क पर ट्रांसक्रिप्ट पथ का निरीक्षण करें।

Control UI में, हाल के चाइल्ड रन वाले पैरेंट सेशन की साइडबार पंक्ति को विस्तृत किया जा सकता है। नेस्टेड पंक्तियाँ चाइल्ड की स्थिति और रनटाइम दिखाती हैं, और किसी एक को चुनने पर पैरेंट पदानुक्रम बनाए रखते हुए उस चाइल्ड की चैट खुलती है।

थ्रेड बाइंडिंग नियंत्रण

ये कमांड स्थायी थ्रेड बाइंडिंग वाले चैनलों पर काम करते हैं। नीचे थ्रेड का समर्थन करने वाले चैनल देखें।

/focus <subagent-label|session-key|session-id|session-label>/unfocus/agents/session idle <duration|off>/session max-age <duration|off>

शुरू करने का व्यवहार

एजेंट sessions_spawn टूल से पृष्ठभूमि उप-एजेंट शुरू करते हैं। पूर्णताएँ आंतरिक पैरेंट-सेशन इवेंट के रूप में लौटती हैं; पैरेंट/अनुरोधकर्ता एजेंट तय करता है कि उपयोगकर्ता को दिखाई देने वाला अपडेट आवश्यक है या नहीं।

कॉन्टेक्स्ट मोड

नेटिव उप-एजेंट पृथक रूप से शुरू होते हैं, जब तक कि कॉलर स्पष्ट रूप से वर्तमान ट्रांसक्रिप्ट को फ़ोर्क करने के लिए न कहे।

fork का उपयोग सीमित रूप से करें। यह कॉन्टेक्स्ट-संवेदनशील डेलिगेशन के लिए है, स्पष्ट कार्य प्रॉम्प्ट लिखने का विकल्प नहीं।

टूल: sessions_spawn

वैश्विक subagent लेन पर deliver: false के साथ एक उप-एजेंट रन शुरू करता है, फिर घोषणा चरण चलाता है और घोषणा उत्तर अनुरोधकर्ता के चैट चैनल पर पोस्ट करता है।

उपलब्धता कॉलर की प्रभावी टूल नीति पर निर्भर करती है। अंतर्निर्मित coding और messaging प्रोफ़ाइल में sessions_spawn, sessions_yield, और subagents शामिल हैं; minimal में नहीं। full हर टूल की अनुमति देता है। ऐसे कस्टम संकरे प्रोफ़ाइल वाले एजेंट के लिए, जिसे फिर भी कार्य डेलिगेट करना चाहिए, उन टूल को tools.alsoAllow से जोड़ें या ऊपर दिए गए प्रोफ़ाइल में से किसी एक का उपयोग करें। चैनल/समूह, प्रोवाइडर, सैंडबॉक्स और प्रति-एजेंट अनुमति/अस्वीकृति नीतियाँ प्रोफ़ाइल चरण के बाद भी टूल को हटा सकती हैं। प्रभावी टूल सूची की पुष्टि करने के लिए उसी सेशन से /tools का उपयोग करें।

डिफ़ॉल्ट:

• मॉडल: नेटिव उप-एजेंट कॉलर का मॉडल इनहेरिट करते हैं, जब तक कि आप agents.defaults.subagents.model (या प्रति-एजेंट agents.entries.*.subagents.model) सेट न करें। उपलब्ध होने पर ACP रनटाइम स्पॉन भी उसी कॉन्फ़िगर किए गए उप-एजेंट मॉडल का उपयोग करते हैं; अन्यथा ACP हार्नेस अपना डिफ़ॉल्ट बनाए रखता है। स्पष्ट sessions_spawn.model को फिर भी प्राथमिकता मिलती है।
• सोच-विचार: नेटिव उप-एजेंट कॉलर की सेटिंग इनहेरिट करते हैं, जब तक कि आप agents.defaults.subagents.thinking (या प्रति-एजेंट agents.entries.*.subagents.thinking) सेट न करें। ACP रनटाइम स्पॉन भी चुने गए मॉडल के लिए agents.defaults.models["provider/model"].params.thinking लागू करते हैं। स्पष्ट sessions_spawn.thinking को फिर भी प्राथमिकता मिलती है।
• रन टाइमआउट: सेट होने पर OpenClaw agents.defaults.subagents.runTimeoutSeconds का उपयोग करता है; अन्यथा यह 0 (कोई टाइमआउट नहीं) का सहारा लेता है। sessions_spawn प्रति-कॉल टाइमआउट ओवरराइड स्वीकार नहीं करता।
• प्रोसेस जीवनकाल: अलग किया गया OpenClaw उप-एजेंट अपना स्वयं का रन जीवनचक्र रखता है। किसी बाहरी CLI बैकएंड के भीतर बनाया गया पृष्ठभूमि कार्य अलग होता है: वह पैरेंट CLI सबप्रोसेस साझा करता है और यदि पैरेंट agents.defaults.timeoutSeconds पर पहुँचता है तो रुक जाता है।
• कार्य डिलीवरी: नेटिव उप-एजेंट को डेलिगेट किया गया कार्य उनके पहले दृश्यमान [Subagent Task] संदेश में मिलता है। उप-एजेंट सिस्टम प्रॉम्प्ट रनटाइम नियम और रूटिंग कॉन्टेक्स्ट रखता है, कार्य की कोई छिपी हुई प्रतिलिपि नहीं।

स्वीकृत नेटिव उप-एजेंट स्पॉन के टूल परिणाम में समाधान किया गया चाइल्ड मॉडल मेटाडेटा शामिल होता है: resolvedModel में लागू मॉडल रेफ़ होता है और जब रेफ़ में प्रोवाइडर प्रीफ़िक्स हो, तो resolvedProvider में वह प्रीफ़िक्स होता है।

डेलिगेशन प्रॉम्प्ट मोड

agents.defaults.subagents.delegationMode केवल प्रॉम्प्ट मार्गदर्शन नियंत्रित करता है; यह टूल नीति नहीं बदलता या डेलिगेशन लागू नहीं करता।

• suggest (डिफ़ॉल्ट): बड़े या धीमे कार्यों के लिए उप-एजेंट का उपयोग करने का मानक प्रॉम्प्ट संकेत बनाए रखें।
• prefer: मुख्य एजेंट को प्रतिक्रियाशील बने रहने और प्रत्यक्ष उत्तर से अधिक जटिल किसी भी कार्य को sessions_spawn के माध्यम से डेलिगेट करने के लिए कहें।

प्रति-एजेंट ओवरराइड: agents.entries.*.subagents.delegationMode।

{  agents: {    defaults: {      subagents: {        delegationMode: "prefer",        maxConcurrent: 4,      },    },    list: [      {        id: "coordinator",        subagents: { delegationMode: "prefer" },      },    ],  },}

टूल पैरामीटर

visible: true के साथ, model, cwd, और समान-एजेंट context: "fork" समर्थित हैं। सैंडबॉक्स किया गया लक्ष्य cwd को उस एजेंट के वर्कस्पेस तक सीमित करता है। थ्रेड बाइंडिंग, mode, चिंतन ओवरराइड, lightContext, attachments, और attachAs इस पथ पर उपलब्ध नहीं हैं क्योंकि दृश्यमान सत्र sessions.create के माध्यम से बनाए गए स्थायी डैशबोर्ड सत्र होते हैं। यदि अनुरोधकर्ता को स्वयं विरासत में मिली टूल अनुमत-सूची या निषेध-सूची के साथ स्पॉन किया गया था, तो दृश्यमान स्पॉन अस्वीकार कर दिया जाता है; यह प्रतिबंध स्पॉन के समय निर्धारित होता है और इसका कोई कॉन्फ़िग ओवरराइड नहीं है। सत्र सूचीकरण और संबोधन tools.sessions.visibility का पालन करते हैं; डिफ़ॉल्ट tree स्कोप वर्तमान सत्र और उसके अपने स्पॉन उप-वृक्ष को कवर करता है। चेकआउट नामकरण, सेटअप, क्लीनअप और पुनर्स्थापना व्यवहार के लिए प्रबंधित वर्कट्री देखें।

कार्य नाम और लक्ष्य निर्धारण

taskName ऑर्केस्ट्रेशन के लिए मॉडल-सामना करने वाला हैंडल है, सत्र कुंजी नहीं। जब किसी समन्वयक को बाद में उस चाइल्ड का निरीक्षण करना पड़ सकता है, तो review_subagents, linux_validation, या docs_update जैसे स्थिर चाइल्ड नामों के लिए इसका उपयोग करें।

लक्ष्य समाधान सटीक taskName मिलान और असंदिग्ध उपसर्ग स्वीकार करता है। मिलान उसी सक्रिय/हालिया लक्ष्य विंडो तक सीमित है जिसका उपयोग क्रमांकित /subagents लक्ष्य करते हैं, इसलिए कोई पुराना पूर्ण हुआ चाइल्ड पुनः उपयोग किए गए हैंडल को संदिग्ध नहीं बनाता। यदि दो सक्रिय या हालिया चाइल्ड समान taskName साझा करते हैं, तो लक्ष्य संदिग्ध है; इसके बजाय सूची अनुक्रमणिका, सत्र कुंजी, या रन आईडी का उपयोग करें।

आरक्षित लक्ष्य last और all, taskName के मान्य मान नहीं हैं क्योंकि उनके नियंत्रण संबंधी अर्थ पहले से हैं।

टूल: sessions_yield

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

sessions_yield प्रतीक्षा की मूल क्रिया है। केवल चाइल्ड पूर्णता का पता लगाने के लिए इसे subagents, sessions_list, sessions_history, शेल sleep, या प्रक्रिया पोलिंग के पोलिंग लूप से न बदलें।

sessions_yield का उपयोग केवल तभी करें जब सत्र की प्रभावी टूल सूची में यह शामिल हो। कुछ न्यूनतम या कस्टम टूल प्रोफ़ाइल sessions_spawn और subagents को sessions_yield के बिना उपलब्ध करा सकती हैं; उस स्थिति में, पूर्णता की प्रतीक्षा के लिए कोई पोलिंग लूप न गढ़ें।

जब सक्रिय चाइल्ड मौजूद होते हैं, तो OpenClaw सामान्य टर्न में रनटाइम द्वारा जनरेट किया गया एक संक्षिप्त Active Subagents प्रॉम्प्ट ब्लॉक इंजेक्ट करता है, ताकि अनुरोधकर्ता वर्तमान चाइल्ड सत्र, रन आईडी, स्थितियाँ, लेबल, कार्य और taskName उपनाम बिना पोलिंग के देख सके। उस ब्लॉक में कार्य और लेबल फ़ील्ड निर्देशों के रूप में नहीं, बल्कि डेटा के रूप में उद्धृत होते हैं, क्योंकि वे उपयोगकर्ता/मॉडल द्वारा दिए गए स्पॉन आर्ग्युमेंट से उत्पन्न हो सकते हैं।

टूल: subagents

अनुरोधकर्ता सत्र वृक्ष के स्वामित्व वाले स्पॉन किए गए उप-एजेंट रन और पृष्ठभूमि-कार्य रिकॉर्ड सूचीबद्ध करता है। कार्य पंक्तियाँ नेटिव उप-एजेंट, ACP रन, Gateway CLI/मीडिया कार्य और Cron निष्पादन कवर करती हैं। इसका स्कोप वर्तमान अनुरोधकर्ता तक सीमित है; कोई चाइल्ड केवल अपने नियंत्रित चाइल्ड देख सकता है।

माँग पर स्थिति और डीबगिंग के लिए subagents का उपयोग करें। पूर्णता घटनाओं की प्रतीक्षा के लिए sessions_yield का उपयोग करें।

किसी कार्य को रोकने के लिए action: "list" द्वारा लौटाए गए taskId के साथ action: "cancel" का उपयोग करें। रद्दीकरण नियंत्रित सत्र वृक्ष तक सीमित है; कोई लीफ़ उप-एजेंट किसी अन्य सत्र के स्वामित्व वाला कार्य रद्द नहीं कर सकता।

थ्रेड-बाउंड सत्र

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

थ्रेड का समर्थन करने वाले चैनल

जब कोई चैनल वार्तालाप बाइंडिंग अडैप्टर पंजीकृत करता है, तो वह स्थायी थ्रेड-बाउंड उप-एजेंट सत्रों (sessions_spawn के साथ thread: true) का समर्थन करता है। इस समर्थन वाले बंडल चैनल: Discord, iMessage, Matrix, और Telegram। Discord और Matrix में डिफ़ॉल्ट रूप से चाइल्ड थ्रेड बनाया जाता है; Telegram और iMessage में डिफ़ॉल्ट रूप से वर्तमान वार्तालाप को बाइंड किया जाता है। सक्षमता, टाइमआउट और spawnSessions के लिए प्रति-चैनल threadBindings कॉन्फ़िग कुंजियों का उपयोग करें।

त्वरित प्रवाह

मैन्युअल नियंत्रण

कॉन्फ़िग स्विच

• वैश्विक डिफ़ॉल्ट: session.threadBindings.enabled, session.threadBindings.idleHours, session.threadBindings.maxAgeHours।
• चैनल ओवरराइड और स्पॉन ऑटो-बाइंड कुंजियाँ अडैप्टर-विशिष्ट हैं। ऊपर थ्रेड का समर्थन करने वाले चैनल देखें।

वर्तमान अडैप्टर विवरण के लिए कॉन्फ़िगरेशन संदर्भ और स्लैश कमांड देखें।

अनुमत-सूची

यदि अनुरोधकर्ता सत्र सैंडबॉक्स में है, तो sessions_spawn उन लक्ष्यों को अस्वीकार करता है जो सैंडबॉक्स के बाहर चलेंगे।

खोज

वर्तमान में किन agent ids को sessions_spawn के लिए अनुमति है, यह देखने के लिए agents_list का उपयोग करें। प्रतिक्रिया में सूचीबद्ध प्रत्येक agent का प्रभावी model और अंतर्निहित runtime metadata शामिल होता है, ताकि कॉलर OpenClaw, Codex app-server और अन्य कॉन्फ़िगर किए गए native runtimes के बीच अंतर कर सकें।

allowAgents प्रविष्टियों को agents.entries.* में कॉन्फ़िगर किए गए agent ids की ओर संकेत करना चाहिए। ["*"] का अर्थ है कोई भी कॉन्फ़िगर किया गया लक्ष्य agent और अनुरोधकर्ता। यदि किसी agent का config हटा दिया जाता है, लेकिन उसका id allowAgents में बना रहता है, तो sessions_spawn उस id को अस्वीकार करता है और agents_list उसे छोड़ देता है। पुराने हो चुके allowlist प्रविष्टियों को साफ़ करने के लिए openclaw doctor --fix चलाएँ, या जब लक्ष्य को डिफ़ॉल्ट्स इनहेरिट करते हुए spawn करने योग्य रखना हो, तब एक न्यूनतम agents.entries.* प्रविष्टि जोड़ें।

स्वचालित आर्काइव

• Sub-agent सत्र agents.defaults.subagents.archiveAfterMinutes (डिफ़ॉल्ट 60) के बाद स्वचालित रूप से आर्काइव किए जाते हैं।
• आर्काइव sessions.delete का उपयोग करता है और ट्रांसक्रिप्ट का नाम बदलकर *.deleted.<timestamp> करता है (उसी फ़ोल्डर में)।
• cleanup: "delete" घोषणा के तुरंत बाद आर्काइव करता है (नाम बदलकर ट्रांसक्रिप्ट को फिर भी बनाए रखता है)।
• स्वचालित आर्काइव सर्वोत्तम-प्रयास पर आधारित है; Gateway के पुनः आरंभ होने पर लंबित टाइमर खो जाते हैं।
• कॉन्फ़िगर किए गए रन टाइमआउट स्वचालित रूप से आर्काइव नहीं करते; वे केवल रन रोकते हैं। सत्र स्वचालित आर्काइव होने तक बना रहता है।
• स्वचालित आर्काइव depth-1 और depth-2 सत्रों पर समान रूप से लागू होता है।
• ब्राउज़र क्लीनअप, आर्काइव क्लीनअप से अलग है: रन समाप्त होने पर ट्रैक किए गए ब्राउज़र टैब/प्रोसेस सर्वोत्तम-प्रयास के आधार पर बंद किए जाते हैं, भले ही ट्रांसक्रिप्ट/सत्र रिकॉर्ड रखा गया हो।

नेस्टेड sub-agents

डिफ़ॉल्ट रूप से, sub-agents अपने स्वयं के sub-agents को spawn नहीं कर सकते (maxSpawnDepth: 1)। नेस्टिंग का एक स्तर सक्षम करने के लिए maxSpawnDepth: 2 सेट करें — orchestrator पैटर्न: मुख्य → orchestrator sub-agent → worker sub-sub-agents।

{  agents: {    defaults: {      subagents: {        maxSpawnDepth: 2, // sub-agents को children spawn करने दें (डिफ़ॉल्ट: 1, सीमा 1-5)        maxChildrenPerAgent: 5, // प्रति agent सत्र अधिकतम सक्रिय children (डिफ़ॉल्ट: 5, सीमा 1-20)        maxConcurrent: 8, // वैश्विक concurrency lane सीमा (डिफ़ॉल्ट: 8)        runTimeoutSeconds: 900, // sessions_spawn के लिए डिफ़ॉल्ट टाइमआउट (0 = कोई टाइमआउट नहीं)        announceTimeoutMs: 120000, // प्रति-कॉल Gateway घोषणा टाइमआउट      },    },  },}

गहराई के स्तर

घोषणा शृंखला

परिणाम शृंखला में ऊपर की ओर प्रवाहित होते हैं:

1. Depth-2 worker समाप्त होता है → अपने parent (depth-1 orchestrator) को घोषणा करता है।
2. Depth-1 orchestrator घोषणा प्राप्त करता है, परिणामों का संश्लेषण करता है, समाप्त होता है → मुख्य को घोषणा करता है।
3. मुख्य agent घोषणा प्राप्त करता है और उपयोगकर्ता तक पहुँचाता है।

प्रत्येक स्तर केवल अपने प्रत्यक्ष children की घोषणाएँ देखता है।

गहराई के अनुसार टूल नीति

• spawn किए जाने पर child अनुरोधकर्ता की प्रभावी sender policy को कैप्चर करता है। Senderless child runs और प्रमाणित operator resumes उस snapshot को बनाए रखते हैं, भले ही toolsBySender बाद में बदल जाए; वर्तमान वैश्विक, agent, provider, sandbox और sub-agent प्रतिबंध फिर भी लागू होते हैं। इसके बजाय child को लक्षित करने वाला नया external channel turn वर्तमान sender policy को फिर से resolve करता है।
• spawn के समय भूमिका और नियंत्रण का दायरा सत्र metadata में लिखा जाता है। यह flat या restore की गई session keys को गलती से orchestrator विशेषाधिकार दोबारा प्राप्त करने से रोकता है।
• Depth 1 (orchestrator, जब maxSpawnDepth >= 2): इसे sessions_spawn, subagents, sessions_list, sessions_history मिलते हैं, ताकि यह children spawn कर सके और उनकी स्थिति जाँच सके। अन्य session/system tools अस्वीकृत रहते हैं।
• Depth 1 (लीफ़, जब maxSpawnDepth == 1): कोई session tools नहीं (वर्तमान डिफ़ॉल्ट व्यवहार)।
• Depth 2 (लीफ़ worker): कोई session tools नहीं — depth 2 पर sessions_spawn हमेशा अस्वीकृत रहता है। आगे children spawn नहीं कर सकता।

प्रति-agent spawn सीमा

प्रत्येक agent सत्र (किसी भी गहराई पर) में एक समय में अधिकतम maxChildrenPerAgent (डिफ़ॉल्ट 5) सक्रिय children हो सकते हैं। यह किसी एक orchestrator से अनियंत्रित fan-out को रोकता है।

कैस्केड स्टॉप

depth-1 orchestrator को रोकने पर उसके सभी depth-2 children स्वतः रुक जाते हैं:

• मुख्य चैट में /stop सभी depth-1 agents को रोकता है और यह रोक उनके depth-2 children तक कैस्केड होती है।

प्रमाणीकरण

Sub-agent प्रमाणीकरण agent id के आधार पर resolve होता है, सत्र प्रकार के आधार पर नहीं:

• Sub-agent सत्र कुंजी agent:<agentId>:subagent:<uuid> है।
• प्रमाणीकरण स्टोर उस agent के agentDir से लोड किया जाता है।
• मुख्य agent की प्रमाणीकरण प्रोफ़ाइलें fallback के रूप में मर्ज की जाती हैं; टकराव होने पर agent प्रोफ़ाइलें मुख्य प्रोफ़ाइलों को ओवरराइड करती हैं।

मर्ज योगात्मक है, इसलिए मुख्य प्रोफ़ाइलें हमेशा fallback के रूप में उपलब्ध रहती हैं। प्रति-agent पूरी तरह पृथक प्रमाणीकरण अभी समर्थित नहीं है।

घोषणा

Sub-agents एक घोषणा चरण के माध्यम से रिपोर्ट करते हैं:

• घोषणा चरण sub-agent सत्र के भीतर चलता है (अनुरोधकर्ता सत्र में नहीं)।
• यदि sub-agent ठीक ANNOUNCE_SKIP उत्तर देता है, तो कुछ भी पोस्ट नहीं किया जाता।
• यदि नवीनतम assistant टेक्स्ट सटीक silent token NO_REPLY / no_reply है, तो घोषणा आउटपुट दबा दिया जाता है, भले ही पहले दृश्यमान प्रगति मौजूद रही हो।

डिलीवरी अनुरोधकर्ता की गहराई पर निर्भर करती है:

• शीर्ष-स्तरीय अनुरोधकर्ता सत्र बाहरी डिलीवरी (deliver=true) के साथ एक अनुवर्ती agent कॉल का उपयोग करते हैं।
• नेस्टेड अनुरोधकर्ता subagent सत्र एक आंतरिक अनुवर्ती इंजेक्शन (deliver=false) प्राप्त करते हैं, ताकि orchestrator सत्र के भीतर child परिणामों का संश्लेषण कर सके।
• यदि नेस्टेड अनुरोधकर्ता subagent सत्र समाप्त हो चुका हो, तो उपलब्ध होने पर OpenClaw उस सत्र के अनुरोधकर्ता पर fallback करता है।

शीर्ष-स्तरीय अनुरोधकर्ता सत्रों के लिए, completion-mode प्रत्यक्ष डिलीवरी पहले किसी भी बाउंड conversation/thread route और hook override को resolve करती है, फिर अनुरोधकर्ता सत्र के संग्रहीत route से अनुपस्थित channel-target फ़ील्ड भरती है। इससे completions सही chat/topic पर बनी रहती हैं, भले ही completion origin केवल channel की पहचान करता हो।

नेस्टेड completion findings बनाते समय child completion aggregation वर्तमान अनुरोधकर्ता रन तक सीमित रहती है, जिससे पहले के पुराने रन के child outputs वर्तमान घोषणा में लीक नहीं होते। Channel adapters पर उपलब्ध होने पर घोषणा उत्तर thread/topic routing को बनाए रखते हैं।

घोषणा संदर्भ

घोषणा संदर्भ को एक स्थिर आंतरिक इवेंट ब्लॉक में सामान्यीकृत किया जाता है:

अंतिम विफल रन कैप्चर किए गए उत्तर टेक्स्ट को दोबारा चलाए बिना विफलता स्थिति रिपोर्ट करते हैं। Tool/toolResult आउटपुट को child परिणाम टेक्स्ट में प्रोत्साहित नहीं किया जाता।

आँकड़े पंक्ति

घोषणा payloads के अंत में एक आँकड़े पंक्ति शामिल होती है (wrap होने पर भी):

• Runtime (उदा. runtime 5m12s)।
• Token उपयोग (इनपुट/आउटपुट/कुल)।
• model pricing कॉन्फ़िगर होने पर अनुमानित लागत (models.providers.*.models[].cost)।
• sessionKey, sessionId और ट्रांसक्रिप्ट पथ, ताकि मुख्य agent sessions_history के माध्यम से इतिहास प्राप्त कर सके या डिस्क पर फ़ाइल जाँच सके।

आंतरिक metadata केवल orchestration के लिए है; उपयोगकर्ता को दिखाए जाने वाले उत्तरों को सामान्य assistant शैली में दोबारा लिखा जाना चाहिए।

sessions_history को प्राथमिकता क्यों दें

sessions_history किसी agent turn के भीतर से child का ट्रांसक्रिप्ट पढ़ने के लिए अधिक सुरक्षित orchestration पथ है:

• सामान्य-उद्देश्य लॉग redaction अक्षम होने पर भी credential/token जैसे टेक्स्ट को छिपाता है।
• लंबे टेक्स्ट ब्लॉक को छोटा करता है (प्रति ब्लॉक 4000 वर्ण) और thinking signatures, reasoning replay payloads तथा inline image data हटा देता है।
• 80 KB प्रतिक्रिया सीमा लागू करता है; बहुत बड़ी पंक्तियों को [sessions_history omitted: message too large] से बदल दिया जाता है।
• मौजूद होने पर पुराने ट्रांसक्रिप्ट विंडो में पीछे की ओर पेज करने के लिए nextOffset का उपयोग करें।
• sessions_history message text से reasoning tags, <relevant-memories> scaffolding या tool-call XML को नहीं हटाता — यह केवल redacted और आकार-सीमित रूप में, कच्चे ट्रांसक्रिप्ट स्वरूप के निकट structured content blocks लौटाता है। /subagents log अधिक व्यापक prose sanitizer लागू करता है (reasoning tags, memory scaffolding और tool-call XML हटाता है), क्योंकि यह structured blocks के बजाय साधारण chat lines render करता है।
• जब पूर्ण byte-for-byte ट्रांसक्रिप्ट की आवश्यकता हो, तब डिस्क पर मौजूद कच्चे ट्रांसक्रिप्ट का निरीक्षण fallback है।

टूल नीति

Sub-agents पहले parent या लक्ष्य agent वाली समान प्रोफ़ाइल और tool-policy पाइपलाइन का उपयोग करते हैं। उसके बाद OpenClaw sub-agent प्रतिबंध परत लागू करता है।

Sub-agents गहराई या भूमिका की परवाह किए बिना हमेशा gateway, agents_list, session_status और cron खो देते हैं (सिस्टम-स्तरीय/इंटरैक्टिव tools या ऐसे tools जिनका समन्वय मुख्य agent को करना चाहिए)। लीफ़ sub-agents (डिफ़ॉल्ट depth-1 व्यवहार और हमेशा depth 2 पर) इसके अतिरिक्त subagents, sessions_list, sessions_history और sessions_spawn खो देते हैं। Sub-agents को कभी message tool नहीं मिलता — इसे spawn के समय अक्षम किया जाता है, इस deny list द्वारा फ़िल्टर नहीं किया जाता — और sessions_send अस्वीकृत ही रहता है, ताकि sub-agents केवल घोषणा शृंखला के माध्यम से संचार करें।

sessions_history यहाँ भी सीमित, sanitized recall दृश्य बना रहता है — यह कच्चा ट्रांसक्रिप्ट डंप नहीं है।

जब maxSpawnDepth >= 2, तब depth-1 orchestrator sub-agents को अतिरिक्त रूप से sessions_spawn, subagents, sessions_list और sessions_history मिलते हैं, ताकि वे अपने children प्रबंधित कर सकें।

config के माध्यम से ओवरराइड

{  agents: {    defaults: {      subagents: {        maxConcurrent: 1,      },    },  },  tools: {    subagents: {      tools: {        // निषेध को प्राथमिकता मिलती है        deny: ["gateway", "cron"],        // यदि अनुमति सेट है, तो केवल अनुमत टूल उपलब्ध होते हैं (निषेध को फिर भी प्राथमिकता मिलती है)        // allow: ["read", "exec", "process"]      },    },  },}

tools.subagents.tools.allow अंतिम केवल-अनुमति फ़िल्टर है। यह पहले से निर्धारित टूल सेट को सीमित कर सकता है, लेकिन tools.profile द्वारा हटाए गए टूल को वापस नहीं जोड़ सकता। उदाहरण के लिए, tools.profile: "coding" में web_search/web_fetch शामिल हैं, लेकिन browser टूल नहीं। कोडिंग-प्रोफ़ाइल उप-एजेंटों को ब्राउज़र स्वचालन का उपयोग करने देने के लिए, प्रोफ़ाइल चरण में ब्राउज़र जोड़ें:

{  tools: {    profile: "coding",    alsoAllow: ["browser"],  },}

जब केवल एक एजेंट को ब्राउज़र स्वचालन मिलना चाहिए, तब प्रति-एजेंट agents.entries.*.tools.alsoAllow: ["browser"] का उपयोग करें।

समवर्ती निष्पादन

उप-एजेंट एक समर्पित इन-प्रोसेस क्यू लेन का उपयोग करते हैं:

• लेन का नाम: subagent
• समवर्ती निष्पादन: agents.defaults.subagents.maxConcurrent (डिफ़ॉल्ट 8)

सक्रियता और पुनर्प्राप्ति

OpenClaw, endedAt की अनुपस्थिति को इस बात का स्थायी प्रमाण नहीं मानता कि कोई उप-एजेंट अभी भी सक्रिय है। बासी रन विंडो से पुराने समाप्त न हुए रन (2 घंटे, या कॉन्फ़िगर किया गया रन टाइमआउट और एक छोटी अतिरिक्त अवधि, इनमें से जो भी अधिक हो) /subagents list, स्थिति सारांशों, वंशज पूर्णता गेटिंग और प्रति-सत्र समवर्ती निष्पादन जाँचों में सक्रिय/लंबित के रूप में गिने जाना बंद कर देते हैं।

Gateway पुनः आरंभ होने के बाद, पुनर्स्थापित किए गए बासी और समाप्त न हुए रन हटा दिए जाते हैं, जब तक कि उनका चाइल्ड सत्र abortedLastRun: true के रूप में चिह्नित न हो। पुनः आरंभ के कारण निरस्त हुए रन उप-एजेंट अनाथ पुनर्प्राप्ति प्रवाह के लिए पंजीकृत रहते हैं: बासी रन बिना पुनः शुरू किए अंतिम रूप दिए जाते हैं, जबकि नए चाइल्ड सत्रों को निरस्त मार्कर हटाए जाने से पहले एक कृत्रिम पुनः आरंभ संदेश मिलता है।

स्वचालित पुनः आरंभ पुनर्प्राप्ति प्रत्येक चाइल्ड सत्र के लिए सीमित है। यदि उसी उप-एजेंट चाइल्ड को तीव्र पुनः-अटकाव विंडो के भीतर बार-बार अनाथ पुनर्प्राप्ति के लिए स्वीकार किया जाता है, तो OpenClaw उस सत्र पर एक पुनर्प्राप्ति टूम्बस्टोन सहेजता है और बाद के पुनः आरंभों पर उसे स्वचालित रूप से फिर शुरू करना बंद कर देता है। कार्य रिकॉर्ड का मिलान करने के लिए openclaw tasks maintenance --apply चलाएँ, या टूम्बस्टोन वाले सत्रों पर बासी निरस्त पुनर्प्राप्ति फ़्लैग साफ़ करने के लिए openclaw doctor --fix चलाएँ।

रोकना

• अनुरोधकर्ता चैट में /stop भेजने से अनुरोधकर्ता सत्र निरस्त हो जाता है और उससे स्पॉन हुए सभी सक्रिय उप-एजेंट रन रुक जाते हैं; यह प्रक्रिया नेस्टेड चिल्ड्रन तक क्रमिक रूप से लागू होती है।

सीमाएँ

• उप-एजेंट घोषणा सर्वोत्तम-प्रयास के आधार पर होती है। यदि Gateway पुनः आरंभ होता है, तो लंबित "वापस घोषणा" कार्य खो जाता है।
• उप-एजेंट अब भी उसी Gateway प्रोसेस के संसाधन साझा करते हैं; maxConcurrent को सुरक्षा वाल्व मानें।
• sessions_spawn हमेशा नॉन-ब्लॉकिंग होता है: यह तुरंत { status: "accepted", runId, childSessionKey } लौटाता है।
• उप-एजेंट संदर्भ केवल AGENTS.md और TOOLS.md इंजेक्ट करता है (SOUL.md, IDENTITY.md, USER.md, MEMORY.md, HEARTBEAT.md, या BOOTSTRAP.md नहीं)। Codex-नेटिव उप-एजेंट भी इसी सीमा का पालन करते हैं: TOOLS.md इनहेरिट किए गए Codex थ्रेड निर्देशों में बना रहता है, जबकि केवल-पैरेंट पर्सोना, पहचान और उपयोगकर्ता फ़ाइलें टर्न-स्कोप्ड सहयोग निर्देशों के रूप में इंजेक्ट की जाती हैं, ताकि चिल्ड्रन उन्हें क्लोन न करें।
• अधिकतम नेस्टिंग गहराई 5 है (maxSpawnDepth सीमा: 1-5)। अधिकांश उपयोग स्थितियों के लिए गहराई 2 अनुशंसित है।
• maxChildrenPerAgent प्रति सत्र सक्रिय चिल्ड्रन की सीमा निर्धारित करता है (डिफ़ॉल्ट 5, सीमा 1-20)।

संबंधित

• सत्र टूल और स्थिति परिवर्तन
• ACP एजेंट
• एजेंट प्रेषण
• पृष्ठभूमि कार्य
• बहु-एजेंट सैंडबॉक्स टूल