उप-एजेंट (Subagents): कार्यों को विभाजित करके समानांतर में चलाना
📚 सीरीज नेविगेशन: पिछला लेख 20 · MCP के साथ टूल्स जोड़ना आपको Codex के साथ बाहरी टूल्स को जोड़ने की प्रक्रिया सिखाता है ताकि यह दस्तावेज़ों और क्लाउड सेवाओं तक पहुँच सके। यह लेख एक नया दृष्टिकोण प्रदान करता है—"टूल्स जोड़ने" के बजाय, यह आपको सिखाएगा कि कैसे आप कार्यों को विभाजित करके उन्हें समानांतर में चला सकते हैं: उप-एजेंट (Subagent) विशेष प्रकार के सहायक होते हैं जो स्वतंत्र मॉडल, निर्देशों और अनुमतियों के साथ काम करते हैं। ये एक साथ कई काम कर सकते हैं, और काम समाप्त होने पर मुख्य एजेंट को एक रिपोर्ट सौंपते हैं।
दोस्तों, आज हम Codex के सबसे आकर्षक और भ्रमित करने वाले फीचर्स में से एक—उप-एजेंट्स के बारे में बात करेंगे।
इसका नाम सुनने में काफी अच्छा लगता है, "मल्टी-एजेंट समानांतर काम", मानो आप अकेले एक पूरी टीम को निर्देशित कर रहे हों। जब मैंने शुरुआत में इसका उपयोग किया था, तो मुझे लगा कि प्रत्येक कार्य को पाँच-छह एजेंटों में बाँटकर चलाना ही "पेशेवर तरीका" है।
लेकिन सच कहें तो: Codex के उप-एजेंट अन्य उपकरणों से थोड़े अलग हैं, और इसमें एक नियम है जिसे समझना आवश्यक है—यह डिफ़ॉल्ट रूप से अपने आप काम को विभाजित नहीं करता। आधिकारिक तौर पर यह स्पष्ट है: Codex केवल तभी उप-एजेंट बनाता है जब आप स्पष्ट रूप से इसे ऐसा करने के लिए कहते हैं। यदि आप इसे समानांतर में काम करने के लिए नहीं कहते, तो यह अकेले ही पूरा काम करेगा। यह तय करता है कि इसका उपयोग कब और कैसे करना है।
इस लेख में हम न केवल यह देखेंगे कि उप-एजेंट्स को कैसे सक्रिय करें, कस्टम एजेंट कैसे लिखें और विभिन्न एजेंटों के लिए मॉडल कैसे चुनें, बल्कि यह भी समझेंगे कि: कौन से कार्य समानांतर में चलाने के योग्य हैं, और किन कार्यों को विभाजित करने से आपका कोटा और समय अनावश्यक रूप से व्यर्थ हो सकता है।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
- उप-एजेंट क्या हैं—जटिल कार्यों को कई विशेष एजेंटों में बाँटकर चलाना और उनके परिणामों को जोड़ना, तथा यह अकेले काम करने से कैसे अलग है।
- यह किन दो मुख्य समस्याओं को हल करता है: संदर्भ प्रदूषण (context pollution) और संदर्भ क्षय (context rot), और यह तय करना कि कब इसका उपयोग नहीं करना चाहिए।
- Codex के तीन इन-बिल्ट एजेंट (
default/worker/explorer) जिन्हें बिना किसी कॉन्फ़िगरेशन के सीधे उपयोग किया जा सकता है। - कस्टम एजेंट कैसे लिखें:
~/.codex/agents/या.codex/agents/निर्देशिका में एक TOML फ़ाइल बनाना और उसके तीन आवश्यक विकल्पों को समझना। - विभिन्न एजेंटों के लिए उपयुक्त मॉडल और "रीजनिंग तीव्रता" चुनना।
- एक व्यावहारिक अभ्यास: केवल पढ़ने (read-only) वाला एक सहायक एजेंट बनाना, उसे चलाना और परिणामों की जाँच करना।
⚠️ नीचे दी गई सभी विशिष्ट कमांड्स, कॉन्फ़िगरेशन विकल्प और डिफ़ॉल्ट मान Codex आधिकारिक दस्तावेज़ पर आधारित हैं; मॉडल के नाम (जैसे
gpt-5.5आदि) अपडेट के साथ बदल सकते हैं, इसलिए इन्हें अपनी स्थानीय स्थिति के अनुसार देखें।
01 पहले समझें: उप-एजेंट वास्तव में क्या हैं
निष्कर्ष यह है: उप-एजेंट Codex द्वारा अस्थायी रूप से बनाए जाने वाले विशेष एजेंट हैं—जो स्वतंत्र थ्रेड्स (threads) में काम करते हैं, और काम समाप्त होने पर जानकारी का सारांश मुख्य एजेंट को सौंपते हैं, ताकि बातचीत में अनावश्यक विवरण न भरें।
तुलना: एक बड़े केस को हल करने के लिए अलग-अलग जासूसों को भेजने से। आप मुख्य अधिकारी (मुख्य बातचीत) हैं और आपके पास एक जटिल केस है, जैसे "इस कोड परिवर्तन की सुरक्षा, प्रदर्शन और परीक्षण के दृष्टिकोण से समीक्षा करना"। ये तीनों कार्य स्वतंत्र हैं, इसलिए आपको स्वयं एक-एक करके इन्हें जाँचने की आवश्यकता नहीं है। आप तीन जासूस भेजते हैं: एक सुरक्षा खामियों की जाँच करता है, दूसरा प्रदर्शन की, और तीसरा परीक्षण की। तीनों एक साथ काम शुरू करते हैं। काम होने पर वे पूरे दस्तावेज़ आपके सामने रखने के बजाय एक संक्षिप्त रिपोर्ट सौंपते हैं: "सुरक्षा के लिहाज से X और Y पर जोखिम हैं"। आपको अंत में एक व्यवस्थित रिपोर्ट मिलती है।
इन जासूसों की कुछ चीज़ें स्वतंत्र होती हैं, जो आपकी मुख्य बातचीत को प्रभावित नहीं करतीं। आधिकारिक विवरण इस प्रकार हैं:
Subagent: एक विशिष्ट कार्य को करने के लिए Codex द्वारा बनाया गया एक सहायक एजेंट। Agent thread: किसी एजेंट की अपनी CLI बातचीत (thread), जिसे आप
/agentद्वारा देख और बदल सकते हैं।
एक उप-एजेंट में निम्नलिखित चीजें स्वतंत्र हो सकती हैं:
| आयाम | मुख्य थ्रेड (आपकी बातचीत) | उप-एजेंट (सहायक थ्रेड) |
|---|---|---|
| थ्रेड / संदर्भ (Context) | आपके और Codex के बीच की मुख्य बातचीत और इतिहास | इसका अपना स्वतंत्र context रहता है, जिससे विस्तृत विवरण मुख्य बातचीत में नहीं आते |
| मॉडल / रीजनिंग तीव्रता | मुख्य सत्र में उपयोग किया जाने वाला मॉडल | इसे अलग से निर्दिष्ट किया जा सकता है, जैसे सरल कार्य के लिए तेज़ मॉडल और कठिन कार्य के लिए भारी मॉडल |
| निर्देश (Instructions) | डिफ़ॉल्ट Codex व्यवहार | इसके लिए विशिष्ट निर्देश लिखे जा सकते हैं, जैसे "आपका काम केवल कोड देखना है, बदलना नहीं" |
| सैंडबॉक्स अनुमतियाँ | वर्तमान सत्र के सैंडबॉक्स नियम | यह मुख्य अनुमतियों का उपयोग करता है, लेकिन इसे विशिष्ट रूप से (जैसे रीड-ओनली) बदला जा सकता है |
उप-एजेंट की सबसे बड़ी विशेषता यह है: यह मुख्य बातचीत को अनावश्यक विवरणों से बचाता है। इसका उद्देश्य यह है कि मुख्य एजेंट आवश्यकताओं और निर्णयों पर ध्यान केंद्रित रख सके, और परीक्षण करने या लॉग्स देखने जैसे बड़े काम उप-एजेंट्स को सौंपे जा सकें, जो केवल सारांश प्रदान करते हैं, बड़े लॉग्स नहीं।
यह प्रक्रिया इस आरेख में दिखाई गई है:
यह आरेख दिखाता है कि मुख्य एजेंट कार्य को विभाजित करके उप-एजेंट्स को सौंपता है, जहाँ प्रत्येक उप-एजेंट अपने स्वतंत्र थ्रेड में काम करता है और मुख्य बातचीत को साफ रखता है, और अंत में केवल सारांश प्रदान करता है।
💡 संक्षेप में: उप-एजेंट स्वतंत्र थ्रेड्स, मॉडल्स और अनुमतियों के साथ काम करने वाले सहायक एजेंट हैं, जो समानांतर में काम करके सारांश मुख्य बातचीत को सौंपते हैं; इसका मुख्य उद्देश्य बातचीत को साफ रखना है।
02 यह किस समस्या को हल करता है, और निर्णय सीमा क्या है
अवधारणा को समझने के बाद, आइए इसके उद्देश्यों को समझें। यह मुख्यतः दो समस्याओं को हल करता है:
समस्या 1: संदर्भ प्रदूषण (context pollution)
तुलना: टेबल पर काम की फाइलों के बीच कचरा बिलों का मिल जाना। आपकी मुख्य बातचीत में काम की बातें—आवश्यकताएं, नियम और निर्णय—होती हैं। लेकिन यदि आप इसे "पूरे टेस्ट रन करने" के लिए कहते हैं, तो स्क्रीन पर सैकड़ों-हजारों लाइनों के लॉग आ जाते हैं, जो पूरी बातचीत को भर देते हैं। इससे काम की जानकारी खोजना कठिन हो जाता है। इसे संदर्भ प्रदूषण कहते हैं।
आधिकारिक विवरण:
Context pollution (संदर्भ प्रदूषण): महत्वपूर्ण जानकारी का अनावश्यक लॉग्स और विवरणों के नीचे दब जाना।
वास्तविक परिदृश्य: पिछले साल मैं एक थर्ड-पार्टी API पर काम कर रहा था और Codex बार-बार टेस्ट चलाकर बड़े JSON आउटपुट दिखा रहा था। कुछ समय बाद जब मुझे बुनियादी आवश्यकता देखनी थी, तो मुझे ऊपर जाने के लिए बीस से अधिक पेज स्क्रॉल करने पड़े। उस दिन मुझे समझ आया कि जिस काम में बहुत अधिक आउटपुट आता हो, उसे मुख्य बातचीत में नहीं करना चाहिए।
समस्या 2: संदर्भ क्षय (context rot)
तुलना: मीटिंग के लंबे समय तक चलने पर ध्यान भटकने से। मीटिंग के पहले घंटे में सभी काम की बात करते हैं; लेकिन तीसरे घंटे तक पहुँचते-पहुँचते अनावश्यक विवरण और बातें शुरू हो जाती हैं, जिससे निर्णय लेने की क्षमता कम हो जाती है। मॉडल के साथ भी ऐसा ही होता है—बातचीत जितनी लंबी और अनावश्यक विवरणों से भरी होगी, असंबंधित विवरणों के कारण मॉडल का प्रदर्शन उतना ही धीमा होता जाएगा।
आधिकारिक विवरण:
Context rot (संदर्भ क्षय): बातचीत में असंबंधित विवरणों के बढ़ने से मॉडल के प्रदर्शन का धीमा होना।
इन दोनों समस्याओं का समाधान यह है: अनावश्यक गतिविधियों को मुख्य बातचीत से बाहर रखकर उप-एजेंट्स को सौंपना, ताकि केवल सारांश ही प्राप्त हो सके। बड़े दस्तावेज़ों को पढ़ने के लिए भी Codex उन्हें विभाजित करके कई उप-एजेंट्स को सौंप सकता है, और मुख्य बातचीत में केवल सारांश प्राप्त होता है।
निर्णय सीमा: किन कार्यों को विभाजित नहीं करना चाहिए
यद्यपि यह उपयोगी है, लेकिन इसके लिए कोटा (tokens) खर्च होता है: प्रत्येक उप-एजेंट अपना मॉडल चलाता है और टूल्स का उपयोग करता है, जिससे उप-एजेंट वर्कफ़्लो में अधिक token खर्च होते हैं। जितने अधिक एजेंट होंगे, कोटा उतना ही अधिक खर्च होगा। इसके अलावा, समानांतर में फाइलें लिखना जोखिम भरा हो सकता है:
शुरुआत में, समानांतर एजेंटों का उपयोग पढ़ने (read) से संबंधित कार्यों (जैसे कोड खोजना, टेस्ट रन करना, दस्तावेज़ पढ़ना) के लिए करें। फाइलें लिखने (write) से संबंधित कार्यों में सावधानी बरतें क्योंकि एक साथ बदलाव करने पर कोड ओवरराइट होने का जोखिम रहता है।
निर्णय लेने के लिए इस तालिका को देखें:
| कार्य | क्या उप-एजेंट का उपयोग करना चाहिए? | कारण |
|---|---|---|
| कोड खोजना, टेस्ट रन करना, लॉग देखना, दस्तावेज़ पढ़ना (पढ़ने से संबंधित कार्य) | ✅ हाँ, विभाजित करें | अनावश्यक विवरणों को बातचीत से बाहर रखने के लिए यह सबसे उपयुक्त है |
| स्वतंत्र अनुसंधान (जैसे विभिन्न API की स्वतंत्र जाँच करना) | ✅ हाँ, विभाजित करें | समानांतर में चलने से काम तेज़ होता है |
| छोटे बदलाव जिन्हें आसानी से एक निर्देश में किया जा सकता है | ❌ नहीं | उप-एजेंट बनाने में अधिक token और समय लगेगा, जो आवश्यक नहीं है |
| एक साथ एक ही फ़ाइल में कई बदलाव करना | ⚠️ सावधानी बरतें | कोड ओवरराइट होने या एरर आने का जोखिम रहता है |
| क्रमिक कार्य (जहाँ पहले चरण के बाद ही दूसरा हो सकता है) | ⚠️ विभाजित न करें | इन्हें समानांतर में नहीं चलाया जा सकता |
मेरी आदत सरल है: छोटे और तात्कालिक सुधारों के लिए मैं कभी भी उप-एजेंट का उपयोग नहीं करता। इससे कोटा और समय बचता है।
💡 संक्षेप में: उप-एजेंट संदर्भ प्रदूषण और संदर्भ क्षय को रोकते हैं; लेकिन छोटे बदलावों, क्रमिक कार्यों या फाइलों में लिखने के लिए इनका उपयोग न करें ताकि कोटा व्यर्थ न हो।
निर्णय और काम की प्रक्रिया को इस आरेख से समझें:
यह आरेख दिखाता है कि पहले कार्य की प्रकृति जाँची जाती है, और उपयुक्त होने पर ही आपके कहने पर Codex उप-एजेंट्स बनाता है, और काम पूरा होने पर सारांश प्रस्तुत करता है।
03 तीन इन-बिल्ट एजेंट और उन्हें सक्रिय करना
कस्टम एजेंट लिखने से पहले यह जानना उपयोगी है कि Codex में तीन इन-बिल्ट एजेंट पहले से उपलब्ध होते हैं, जिन्हें आप बिना किसी कॉन्फ़िगरेशन के उपयोग कर सकते हैं।
इन-बिल्ट एजेंटों का विवरण:
| एजेंट | भूमिका | कार्य |
|---|---|---|
default | सामान्य कार्य | डिफ़ॉल्ट रोल |
worker | निष्पादन | कोड लिखना, बग ठीक करना (बदलाव करने वाले कार्य) |
explorer | पढ़ना / खोजना | कोड पढ़ना, रिसर्च करना, दस्तावेज़ देखना |
एजेंट उपलब्ध हैं, लेकिन इन्हें शुरू करने के लिए आपको निर्देश में स्पष्ट रूप से कहना होगा क्योंकि Codex स्वयं काम विभाजित नहीं करता।
निर्देश सामान्य भाषा में दिए जा सकते हैं, जैसे:
कृपया समानांतर उप-एजेंट्स का उपयोग करके इस ब्रांच की समीक्षा करें। एक एजेंट को सुरक्षा जोखिमों की जाँच करने, दूसरे को टेस्ट कवरेज देखने, और तीसरे को कोड गुणवत्ता देखने के लिए कहें। तीनों के परिणाम प्राप्त होने पर एक संयुक्त रिपोर्ट दिखाएं।तुलना: फिल्म डायरेक्टर द्वारा शूटिंग के आदेश से। जब तक आप नहीं कहेंगे, समानांतर कैमरे शुरू नहीं होंगे। आपका निर्देश ही स्टार्टअप की चाबी है।
काम शुरू होने पर Codex स्वयं उप-एजेंट्स को संभालता है, उनके परिणामों की प्रतीक्षा करता है, और अंत में आपको एक संयुक्त रिपोर्ट प्रस्तुत करता है।
⚠️ प्लेटफ़ॉर्म नोट: उप-एजेंट की गतिविधियां वर्तमान में Codex App और CLI पर दिखाई देती हैं, IDE एक्सटेंशन में इसकी दृश्यता जल्द ही उपलब्ध होगी। इसलिए CLI या App का उपयोग करें।
💡 संक्षेप में: तीन इन-बिल्ट एजेंट (
default/worker/explorer) उपलब्ध हैं; लेकिन इन्हें शुरू करने के लिए निर्देश में स्पष्ट रूप से "समानांतर उप-एजेंट्स का उपयोग करें" कहना आवश्यक है।
04 सक्रिय एजेंटों को प्रबंधित करना: /agent और निर्देश
जब समानांतर में काम चल रहा हो, तो आप उन्हें /agent द्वारा या निर्देश देकर प्रबंधित कर सकते हैं।
तरीका 1: /agent का उपयोग
CLI में /agent टाइप करके आप सक्रिय एजेंट थ्रेड्स के बीच स्विच कर सकते हैं और देख सकते हैं कि कौन सा एजेंट क्या कर रहा है।
/agentध्यान रखें कि यह नया एजेंट शुरू करने की कमांड नहीं है, बल्कि चल रहे एजेंटों की स्थिति देखने के लिए है।
तरीका 2: निर्देश देना
आप सीधे बातचीत में Codex को किसी चल रहे एजेंट को रोकने या काम समाप्त करने के लिए कह सकते हैं, जैसे "उस सर्च वाले एजेंट को अभी रोक दें"।
तुलना: कंट्रोल रूम से संदेश भेजने से। आप /agent द्वारा स्थिति देख सकते हैं, और सीधे बोलकर निर्देश दे सकते हैं। नियंत्रण हमेशा आपके पास रहता है।
अनुमोदन (Approval) संबंधी बात: CLI में काम करते समय, यदि किसी बैकग्राउंड एजेंट को अनुमोदन की आवश्यकता होती है, तो स्क्रीन पर पॉप-अप दिखाई देगा। आप o दबाकर उस एजेंट के थ्रेड में जा सकते हैं, संदर्भ देख सकते हैं, और अनुमोदन का निर्णय ले सकते हैं। नॉन-इंटरैक्टिव मोड (जैसे स्क्रिप्ट रन) में अनुमोदन की आवश्यकता होने पर कार्य सीधे विफल हो जाएगा।
💡 संक्षेप में: चल रहे एजेंटों को देखने के लिए
/agent(एकवचन) का उपयोग करें, या बातचीत में सीधे निर्देश दें; अनुमोदन के लिएoदबाकर संबंधित थ्रेड में जाया जा सकता है।
05 कस्टम एजेंट: TOML फ़ाइल लिखना और मॉडल सेट करना
यदि आपको अक्सर एक ही प्रकार के कार्य के लिए विशिष्ट नियमों की आवश्यकता होती है (जैसे सुरक्षा ऑडिट के लिए विशिष्ट निर्देश), तो आप एक कस्टम एजेंट बना सकते हैं।
कैसे बनाएं: संबंधित निर्देशिका में एक TOML फ़ाइल बनाएं, जहाँ प्रत्येक फ़ाइल एक एजेंट को परिभाषित करती है। स्थान विवरण:
| स्थान | प्रभाव | उपयोग |
|---|---|---|
~/.codex/agents/ | सभी प्रोजेक्ट्स पर | सामान्य उपयोग के लिए कस्टम एजेंट |
.codex/agents/ | केवल वर्तमान प्रोजेक्ट पर | प्रोजेक्ट विशिष्ट कस्टम एजेंट (Git द्वारा टीम के साथ साझा किया जा सकता है) |
तुलना: विशेष भूमिका के लिए फ़ाइल तैयार करने से। इन-बिल्ट एजेंट सामान्य भूमिकाओं के लिए हैं; जबकि आपकी TOML फ़ाइल एक विशिष्ट भूमिका (जैसे कोड समीक्षक) के लिए नियम, निर्देश और मॉडल सेट करती है।
एक कस्टम एजेंट TOML फ़ाइल का उदाहरण (तीन आवश्यक विकल्प):
name = "reviewer"
description = "PR समीक्षक जो कोड की सुरक्षा, शुद्धता और परीक्षण कवरेज की जाँच करता है।"
developer_instructions = """
एक कोड ओनर की तरह समीक्षा करें।
सुरक्षा, कोड गुणवत्ता, संभावित बग और टेस्ट कवरेज को प्राथमिकता दें।
"""विकल्पों का विवरण:
| विकल्प | आवश्यक | विवरण |
|---|---|---|
name | हाँ | एजेंट का नाम (Codex इसी नाम से इसे कॉल करेगा, फ़ाइल का नाम भी यही रखें) |
description | हाँ | यह समझाने के लिए कि इसका क्या उपयोग है |
developer_instructions | हाँ | एजेंट के लिए नियम और व्यवहार निर्देश |
nickname_candidates | नहीं | एक साथ कई एजेंट चलने पर पहचान के लिए वैकल्पिक उपनाम |
अन्य सेटिंग्स (जैसे model, model_reasoning_effort, sandbox_mode) न लिखने पर मुख्य सत्र से ली जाती हैं। यदि आप इन-बिल्ट नाम (जैसे explorer) का उपयोग करके कस्टम फ़ाइल बनाते हैं, तो आपकी फ़ाइल इन-बिल्ट नियमों को ओवरराइड करेगी।
विभिन्न एजेंटों के लिए उपयुक्त मॉडल चुनना
कस्टम एजेंट में आप प्रत्येक भूमिका के लिए उपयुक्त मॉडल सेट कर सकते हैं:
model: मॉडल का चुनाव। सामान्य कोडिंग, बड़ी फ़ाइलों की स्कैनिंग या साधारण कार्यों के लिए तेज़ और कम खर्चीले मॉडल (जैसेgpt-5.4-mini) का उपयोग करें; और जटिल तार्किक कार्यों या सुरक्षा समीक्षा के लिए मजबूत मॉडल (जैसेgpt-5.4याgpt-5.5) का उपयोग करें।model_reasoning_effort: रीजनिंग की तीव्रता।
| स्तर | उपयोग | प्रभाव |
|---|---|---|
high | जटिल तार्किक कार्यों, सुरक्षा और खामियों की जाँच के लिए | थोड़ा धीमा और अधिक token खर्च करने वाला, लेकिन परिणाम बेहतर होंगे |
medium | अधिकांश कार्यों के लिए सामान्य डिफ़ॉल्ट | संतुलित |
low | सरल और त्वरित कार्यों के लिए | सबसे तेज़ |
उदाहरण (फ़ाइल में लिखना):
# .codex/agents/explorer.toml
name = "pr_explorer"
description = "कोडिंग संदर्भों और फाइलों को खोजने के लिए रीड-ओनली एजेंट।"
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
आप एक रीड-ओनली कोड खोजी एजेंट हैं, बदलाव न करें।
1. उपयोगकर्ता द्वारा बताई गई फ़ाइलें पढ़ें।
2. कोड संरचना और टाइमआउट संबंधी विवरणों की जाँच करें।
3. केवल रिपोर्ट प्रस्तुत करें, कोड में बदलाव न करें।
"""यहाँ sandbox_mode = "read-only" का उपयोग करके हमने एजेंट की अनुमतियों को सीमित कर दिया है, जिससे यह चाहकर भी कोड बदल नहीं पाएगा।
⚠️ ध्यान रखें कि बातचीत के दौरान किए गए तात्कालिक परिवर्तन (जैसे
/permissionsया--yolo) उप-एजेंटों पर भी लागू होंगे, भले ही TOML फ़ाइल में कुछ और लिखा हो।
ग्लोबल स्तर पर config.toml में [agents] सेक्शन के तहत निम्नलिखित सेटिंग्स की जा सकती हैं:
| ग्लोबल विकल्प | विवरण | डिफ़ॉल्ट मान |
|---|---|---|
agents.max_threads | एक साथ चलने वाले अधिकतम उप-एजेंट्स की संख्या | डिफ़ॉल्ट 6 |
agents.max_depth | एजेंटों की गहराई (एजेंट के भीतर एजेंट बनाना) | डिफ़ॉल्ट 1 (अधिक गहराई की अनुमति नहीं) |
agents.job_max_runtime_seconds | बैच कार्यों के लिए टाइमआउट | डिफ़ॉल्ट 1800 सेकंड |
सुरक्षा और दक्षता के लिए max_depth को डिफ़ॉल्ट 1 पर ही रहने दें। गहराई बढ़ाने पर कोडिंग जटिलता और कोटा खर्च बहुत बढ़ सकता है।
💡 संक्षेप में: कस्टम एजेंट बनाने के लिए संबंधित निर्देशिका में TOML फ़ाइल बनाएं, जिसमें
name,descriptionऔरdeveloper_instructionsआवश्यक हैं; आप प्रत्येक भूमिका के लिए उपयुक्त मॉडल, रीजनिंग तीव्रता और सैंडबॉक्स नियम सेट कर सकते हैं।
06 अभ्यास: कस्टम रीड-ओनली एजेंट बनाना और चलाना
आइए एक कस्टम रीड-ओनली एजेंट बनाकर उसे चलाने का अभ्यास करें ताकि संदर्भ प्रदूषण को रोकने और अनुमतियों को सीमित करने की प्रक्रिया देखी जा सके।
हम एक "scout (खोजकर्ता)" एजेंट बनाएंगे, जिसका काम कोड को देखना और कमियों की पहचान करना होगा, लेकिन वह कोई बदलाव नहीं कर पाएगा (चूँकि वह read-only रहेगा)।
चरण 1: प्रोजेक्ट और एजेंट निर्देशिका बनाएं (Mac / Linux पर)
mkdir sub-demo
cd sub-demo
mkdir -p .codex/agentsअपेक्षित परिणाम: sub-demo के भीतर .codex/agents/ निर्देशिका बन जाएगी।
Windows पर PowerShell में:
mkdir sub-demo; cd sub-demo; mkdir .codex\agents -Forceचलाएं।
चरण 2: कस्टम एजेंट TOML फ़ाइल लिखें
sub-demo/.codex/agents/scout.toml फ़ाइल बनाएं और निम्नलिखित विवरण लिखें:
name = "scout"
description = "रीड-ओनली एजेंट जो कोड संरचना और कमियों की जाँच करता है, बदलाव नहीं करता।"
sandbox_mode = "read-only"
model_reasoning_effort = "low"
developer_instructions = """
आप एक रीड-ओनली कोड समीक्षा एजेंट हैं।
1. बताई गई फ़ाइल को पढ़ें।
2. कोड गुणवत्ता, नामकरण और त्रुटियों (errors) की सूची बनाएं।
3. सुधार के सुझाव दें, लेकिन फ़ाइल में कोई बदलाव न करें।
केवल सारांश प्रस्तुत करें, पूरा कोड न छापें।
"""यहाँ हमने मॉडल नहीं लिखा है, जिससे यह डिफ़ॉल्ट मॉडल का उपयोग करेगा; और sandbox_mode = "read-only" सुरक्षा सुनिश्चित करेगा।
चरण 3: जाँच के लिए एक उदाहरण फ़ाइल बनाएं
echo 'def f(a, b):
return a / b' > calc.pyइस कोड में फ़ंक्शन का नाम स्पष्ट नहीं है, और ज़ीरो डिवीज़न एरर की संभावना है—यह हमारे एजेंट की जाँच के लिए उपयुक्त है।
चरण 4: Codex शुरू करें और एजेंट चलाएं
codexसत्र में प्रवेश करने के बाद चलाएं (समानांतर उपयोग का स्पष्ट निर्देश दें):
कृपया scout उप-एजेंट को calc.py की जाँच करने के लिए कहें, और उसके नियमों के अनुसार रिपोर्ट प्राप्त करें।अपेक्षित परिणाम: Codex scout उप-एजेंट को सक्रिय करेगा (थ्रेड रन दिखाई देगा)। यह अपने स्वतंत्र थ्रेड में काम करेगा और मुख्य बातचीत में केवल सुधार के सुझावों की रिपोर्ट प्रस्तुत करेगा। यह कोड में कोई बदलाव नहीं करेगा।
चरण 5: फ़ाइल की जाँच करें कि कोई बदलाव तो नहीं हुआ
सत्र से बाहर आकर चलाएं:
cat calc.py(Windows पर type calc.py चलाएं)
अपेक्षित परिणाम: फ़ाइल वैसी ही रहेगी जैसी आपने बनाई थी—यह दर्शाता है कि रीड-ओनली नियम ने सुरक्षा सुनिश्चित की है।
इस प्रकार आपने कस्टम एजेंट बनाने और उसे स्वतंत्र थ्रेड में अनुमतियों के साथ चलाने की प्रक्रिया को समझ लिया है।
💡 संक्षेप में: अभ्यास के चरण हैं—TOML फ़ाइल लिखना → फ़ाइल बनाना → निर्देश देकर एजेंट सक्रिय करना → फ़ाइल की जाँच करके सुरक्षा सत्यापित करना।
07 बैच कार्यों के लिए CSV का उपयोग (प्रयोगात्मक)
⚠️ यह प्रयोगात्मक फ़ीचर है जो भविष्य में बदल सकता है।
यदि आपके पास कई समान कार्य हैं—जैसे कई फाइलों या पीआर की एक जैसी जाँच करना—तो आप spawn_agents_on_csv का उपयोग कर सकते हैं। यह एक CSV फ़ाइल पढ़ता है, प्रत्येक पंक्ति के लिए एक उप-एजेंट चलाता है, और अंत में परिणामों को जोड़कर दुबारा CSV में निर्यात (export) कर देता है।
इसका उपयोग कब करना चाहिए और कब नहीं:
| परिदृश्य | क्या CSV बैच का उपयोग करना चाहिए? | कारण |
|---|---|---|
| कई पीआर या फाइलों की एक जैसी जाँच | ✅ हाँ | समानांतर में चलने से गति तेज़ होगी |
| बड़ी संख्या में फाइलों का अनुवाद | ✅ हाँ | प्रत्येक पंक्ति स्वतंत्र है, इसलिए उपयुक्त है |
| क्रमिक कार्य (जहाँ क्रम महत्वपूर्ण है) | ❌ नहीं | समानांतर में क्रम की गारंटी नहीं होती |
| केवल कुछ ही फाइलों पर काम | ❌ नहीं | छोटे कार्यों के लिए सामान्य विधि ही सरल है |
| एक साथ एक ही फ़ाइल में लिखना | ⚠️ नहीं | ओवरराइट का जोखिम रहता है |
इसका विवरण और पैरामीटर आधिकारिक दस्तावेज़ों के अनुसार बदल सकते हैं।
08 सारांश
इस लेख में हमने Codex के उप-एजेंट (Subagents) फ़ीचर को विस्तार से समझा है—कि यह क्या है, कब उपयोग करना चाहिए और इसे कस्टम निर्देशों के साथ कैसे सेटअप किया जाता है।
मुख्य बिंदुओं का सारांश:
| विषय | विवरण |
|---|---|
| उप-एजेंट क्या हैं | स्वतंत्र थ्रेड्स, मॉडल्स और अनुमतियों वाले विशेष एजेंट जो काम पूरा करके सारांश मुख्य बातचीत को सौंपते हैं |
| समस्याओं का समाधान | संदर्भ प्रदूषण और संदर्भ क्षय को रोकना (लॉग्स को मुख्य बातचीत से बाहर रखना) |
| कब उपयोग नहीं करना | छोटे बदलावों, क्रमिक कार्यों या फाइलों में एक साथ लिखने के लिए |
| सक्रिय करना | आपको निर्देश में स्पष्ट कहना होगा, यह स्वचालित रूप से काम विभाजित नहीं करता |
| प्रकार | तीन इन-बिल्ट रोल; या TOML फ़ाइल द्वारा कस्टम एजेंट बनाना |
| मॉडल सेटिंग्स | model और model_reasoning_effort द्वारा रोल के अनुसार मॉडल चुनना |
अब आप यह कर सकते हैं: यह तय करना कि किस काम के लिए उप-एजेंट का उपयोग करना है; इन-बिल्ट भूमिकाओं का उपयोग करना; कस्टम नियमों, मॉडल और सुरक्षा सीमा (रीड-ओनली) के साथ कस्टम एजेंट बनाना; और सक्रिय थ्रेड्स को प्रबंधित करना। यह समझ आपको बड़े प्रोजेक्ट्स पर काम करने में मदद करती है।
याद रखें कि अंतिम नियंत्रण हमेशा आपके निर्देश पर ही निर्भर करता है।
अगला लेख 22 "Agent Skills 技能 (कौशल)"—अब तक हमने सुरक्षा नियम (AGENTS.md), टूल्स (MCP) और उप-एजेंट्स की बात की है। लेकिन यदि आपको कस्टम उप-एजेंट के लिए हर बार निर्देश लिखने पड़ते हैं, तो काम थकाऊ हो सकता है। क्या हो यदि इन निर्देशों को एक कौशल (Skill) के रूप में सहेज लिया जाए ताकि आवश्यकता होने पर इसे सीधे कॉल किया जा सके? अगले लेख में हम इसे विस्तार से समझेंगे।