एजेंटिक डिजाइन पैटर्न्स पर नई पुस्तक AI एजेंट्स की समझ को बदल देती है

लेखक：यानहुआ

एंटोनियो गुल्ली गूगल के इंजीनियरिंग डायरेक्टर हैं। उन्होंने एक 453 पृष्ठों की पुस्तक लिखी है, जिसमें AI एजेंट विकास को 21 डिजाइन पैटर्न में विभाजित किया गया है।

लेकिन यह एक पुस्तक समीक्षा नहीं है। मेरा इस पुस्तक को पढ़ने का उद्देश्य बहुत विशिष्ट है: मैंने Harness Engineering लिखा है, Clawdbot के जाल में फंसने के अनुभव लिखे हैं, "AI एजेंट जादू नहीं हैं" वाला लेख लिखा है जिसमें Token जलाने से लेकर वास्तविक रूप से उपयोगी बनने तक के सात परिवर्तनों का वर्णन किया है, हर बार लिखने के बाद एक ऐसा प्रश्न बाकी रह जाता है जिसका मैंने पूरी तरह से उत्तर नहीं दिया: क्या इन सबके पीछे कोई ऐसी पुन:उपयोगयोग्य नींव की तर्कशास्त्र है?

This book gave me the answers, and deeper than I thought.

आप जो लिख रहे हैं, वह शायद एजेंट नहीं है

प्रोलॉग में किताब का सबसे कठोर निर्णय छिपा हुआ है।

अधिकांश लोग जिस "AI" का उपयोग कर रहे हैं, वह केवल Level 0 है: बिना टूल के, बिना स्मृति के, बिना कार्रवाई के खुला LLM। आप उससे पूछते हैं कि 2025 की ओस्कर की सर्वश्रेष्ठ फिल्म कौन सी है, तो वह अनुमान लगाता है। पुस्तक में स्पष्ट रूप से कहा गया है: Level 0 की चीजें, Agent नहीं होतीं।

ऊपर की ओर जाना ही असली Agent है:

• स्तर 1: उपकरण उपयोगकर्ता

  एजेंट अब उपकरणों का उपयोग शुरू कर रहा है: खोज, API, डेटाबेस। लेकिन यह केवल “इंटरफ़ेस कॉल करने में सक्षम” ही नहीं है, बल्कि यह स्वयं निर्णय लेता है कि कब कॉल करना है, क्या कॉल करना है, और परिणाम का उपयोग कैसे करना है। पुस्तक में एक विशिष्ट उदाहरण दिया गया है: उपयोगकर्ता पूछता है “हाल ही में कोई नया शो है?”, एजेंट स्वयं समझता है कि यह जानकारी प्रशिक्षण डेटा में नहीं है, और स्वयं खोज उपकरण को कॉल करता है, फिर परिणाम को संश्लेषित करता है। महत्वपूर्ण कदम “स्वयं समझना” है। यहाँ मनुष्य उसे “तुम खोजो” नहीं कहते, बल्कि यह स्वयं निर्णय लेता है कि खोजने की आवश्यकता है। यह निर्णय लेने की क्षमता, Level 1 की सीमा है।

• स्तर 2: रणनीतिक विचारक

  दो चीजें और जुड़ गईं: योजना और Context Engineering। पुस्तक में Context Engineering को इस प्रकार परिभाषित किया गया है: जानकारी का ढेर नहीं, बल्कि सावधानी से चयन, कटौती और संदर्भ का पैकेजिंग। उदाहरण बहुत अच्छा है: उपयोगकर्ता दो स्थानों के बीच कॉफीशॉप ढूंढ रहा है। एजेंट पहले मैपिंग टूल को कॉल करके कई डेटा प्राप्त करता है, फिर स्वयं निर्णय लेता है कि “अगला कदम केवल सड़क के नाम ही चाहिए,” और मैपिंग आउटपुट को एक संक्षिप्त सूची में काट देता है, जिसे फिर स्थानीय खोज टूल को प्रदान किया जाता है। प्रत्येक कदम पर सूचना के शोर को कम किया जा रहा है।

  एक वाक्य था जिसे मैंने कई बार पढ़ा: "AI को उच्चतम सटीकता प्राप्त करने के लिए, इसे छोटा, केंद्रित और प्रभावी संदर्भ देना आवश्यक है।" Context Engineering यही काम करता है।

  इस स्तर पर, एजेंट अपने आप को पुनर्विचार कर सकता है। काम पूरा करने के बाद खुद एक बार समीक्षा करता है, समस्याओं को पहचानता है और खुद सुधारता है। मैं बाद में इसे विस्तार से समझाऊंगा।

• स्तर 3: बहु-एजेंट सहयोग

  पुस्तक की स्थिति स्पष्ट है: एक सुपर एजेंट बनाने के बारे में हमेशा सोचते रहें। वास्तविक और विश्वसनीय दृष्टिकोण टीम बनाने की तरह है—प्रोजेक्ट मैनेजर एजेंट + शोधकर्ता एजेंट + डिजाइनर एजेंट + कॉपीराइटर एजेंट। पुस्तक में एक नया उत्पाद लॉन्च का उदाहरण दिया गया है: एक “प्रोजेक्ट मैनेजर एजेंट” समग्र समन्वय करता है और “बाजार अनुसंधान एजेंट”, “उत्पाद डिजाइन एजेंट”, “मार्केटिंग एजेंट” को कार्य सौंपता है। मुख्य बात संचार है: एजेंट कैसे डेटा साझा करते हैं, स्थिति कैसे समन्वयित करते हैं, और संघर्ष कैसे सुलझाते हैं। इस अध्याय में छह प्रकार की संचार टोपोलॉजी दी गई हैं, सबसे सरल एकल एजेंट से लेकर सबसे लचीली कस्टम मिक्स तक, और प्रत्येक के लिए किस परिदृश्य में उपयोग किया जाना चाहिए, इसकी स्पष्ट व्याख्या की गई है।

इन चार स्तरों को देखकर, मुझे अचानक समझ आया कि लोग अक्सर “मेरा Agent अच्छा नहीं है” क्यों कहते हैं। मॉडल कोई समस्या नहीं है, समस्या यह है कि आप इसे एक चैटबॉट की तरह इस्तेमाल कर रहे हैं, जिससे यह स्तर 1 तक नहीं पहुँच पा रहा है।

Context Engineering: पुस्तक में सबसे कम मूल्यांकित अवधारणा

मैंने हैरन इंजीनियरिंग पर एक लेख लिखा था, जिसमें कहा गया था कि ट्रैक का डिज़ाइन इंजन के अश्वशक्ति से अधिक महत्वपूर्ण होता है। इस पुस्तक को पढ़ने के बाद मुझे एहसास हुआ कि कॉन्टेक्स्ट इंजीनियरिंग प्रॉम्प्ट स्तर पर हैरन इंजीनियरिंग का प्रतिबिंब है।

पारंपरिक Prompt Engineering केवल “आप कैसे पूछते हैं” पर ध्यान केंद्रित करता है। इस पुस्तक में Context Engineering “पूछने से पहले, Agent के सामने क्या है” पर ध्यान केंद्रित करता है। इसमें चार स्तरों की जानकारी शामिल है:

1. पहला स्तर, सिस्टम प्रॉम्प्ट। यह परिभाषित करता है कि एजेंट कौन है, किस टोन में है, और क्या सीमाएँ हैं। अधिकांश लोग केवल इस स्तर को ही लिखते हैं।

2. द्वितीय स्तर, बाहरी डेटा। RAG द्वारा प्राप्त दस्तावेज, उपकरण कॉल के उत्तर, रीयल-टाइम API डेटा। यह वह स्थान है जहां अधिकांश लोग फंस जाते हैं: वे जानते हैं कि डेटा देना है, लेकिन यह नहीं जानते कि मॉडल को डूबने से कैसे बचा जाए।

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

4. चौथा स्तर, फीडबैक लूप। प्रत्येक आउटपुट के बाद, एजेंट स्वचालित रूप से गुणवत्ता का मूल्यांकन करता है और अगले संदर्भ रणनीति को समायोजित करता है। पुस्तक इसे "स्वचालित संदर्भ अनुकूलन" कहती है, और Google का Vertex AI Prompt Optimizer इस विचार का इंजीनियरिंग वास्तुकला है।

जब मैं यहाँ तक पढ़ रहा था, तो मुझे याद आया कि मैंने पहले “AI एजेंट जादू नहीं हैं” नामक लेख लिखा था, जिसमें एक अनुभव था कि “आपके एजेंट को नियमों की आवश्यकता होती है, और काफी सारे नियमों की।” अब पीछे मुड़कर देखूँ, तो ये नियम मूल रूप से Context Engineering के हाथ से बनाए गए संस्करण थे, जिन्हें इस पुस्तक में प्रणालीगत ढंग से सुव्यवस्थित किया गया है।

रिफ्लेक्शन: दो एजेंट वास्तव में एक से बेहतर हैं

यह पुस्तक का सबसे व्यावहारिक रूप से उपयोगी पैटर्न है।

रिफ्लेक्शन का मूल सिद्धांत सरल है: एजेंट काम पूरा करने के बाद खुद उसकी समीक्षा करता है और समस्याओं को खुद ठीक करता है। लेकिन इसे लागू करने का तरीका महत्वपूर्ण है। पुस्तक में स्पष्ट रूप से कहा गया है: Producer और Critic को दो अलग-अलग एजेंट्स का उपयोग करना चाहिए, जिन्हें अलग-अलग system prompt दिए जाएँ। एक ही persona अपने ही काम की समीक्षा करने पर अवश्य ही अंधेरे क्षेत्रों में रहेगा। अगर आप एक ही LLM को पहले कोड लिखने और फिर अपने द्वारा लिखे गए कोड की समीक्षा करने के लिए कहें, तो यह अधिकांशतः "बहुत अच्छा है" कहेगा।

The book provides a complete code example.

• Producer का prompt है “आप एक Python डेवलपर हैं, एक फैक्टोरियल गणना करने वाला फ़ंक्शन लिखें, जो सीमा स्थितियों और अपवादों को संभाले”。

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

• फिर एक for लूप है: Producer कोड लिखता है → Critic समीक्षा करता है → Producer टिप्पणियों के आधार पर बदलता है → Critic फिर से समीक्षा करता है → जब तक Critic कहता है CODE_IS_PERFECT या अधिकतम इटरेशन सीमा तक पहुँच जाता है।

यह इतना सरल है। लेकिन पुस्तक एक ऐसी लागत की ओर ध्यान आकर्षित करती है जिसे अक्सर नज़रअंदाज़ किया जाता है: प्रत्येक रिफ्लेक्शन चक्र एक नया LLM कॉल होता है, और जितनी अधिक बार इटरेशन होती हैं, उतनी ही अधिक लागत होती है। इसके अलावा, जैसे-जैसे संवाद इतिहास बढ़ता है, संदर्भ विंडो पिछले संस्करणों और आलोचनाओं से भर जाती है, जिससे वास्तविक उपलब्ध निष्कर्षण स्थान संकुचित होता जाता है। इसलिए, रिफ्लेक्शन का सर्वोत्तम प्रथा है: एक उचित अधिकतम इटरेशन सीमा निर्धारित करें (पुस्तक में 3 का उपयोग किया गया है), और जब Critic संतुष्ट हो जाए, तो रुक जाएँ, परफेक्शन की प्रतीक्षा मत करें।

इसका उपयोग केवल कोड लिखने तक सीमित नहीं है। लेख लिखना, योजना बनाना, दस्तावेज़ सारांशित करना, तर्कसंगत प्रश्नों का हल निकालना — Producer-Critic मॉडल इन सभी के लिए लागू होता है। पुस्तक में सात अनुप्रयोगों की सूची है, जिनका मूल तर्क एक समान है: पहले उत्पादन, फिर समीक्षा, और फिर सुधार।

Multi-Agent जितना अधिक जटिल होता है, उतना बेहतर नहीं होता

इस अध्याय में मुझे सबसे अच्छा लगा वह छह संचार टोपोलॉजी आरेख। बहुत से लोग तुरंत जटिल चीजें करने लगते हैं, लेकिन वास्तव में अधिकांश परिदृश्यों के लिए केवल तीन ही पर्याप्त हैं:

1. एकल एजेंट (स्वतंत्र निष्पादन): कार्य को अन्य से निर्भर नहीं होने वाले उप-समस्याओं में विभाजित किया जा सकता है, जहां प्रत्येक एजेंट अपना काम स्वयं पूरा करता है। सरल, आसानी से रखरखाव योग्य।

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

3. सुपरवाइजर (केंद्रीय नियोजन): एक सुपरवाइजर एजेंट कई वर्कर एजेंट्स को प्रबंधित करता है। कार्य आवंटित करता है, परिणाम एकत्रित करता है, और संघर्षों का समाधान करता है। स्पष्ट पदानुक्रम, आसान प्रबंधन। लेकिन सुपरवाइजर एकल विफलता बिंदु और प्रदर्शन की बॉटलनेक है।

अन्य तीन (Supervisor-as-Tool, हायरार्किकल, कस्टम मिक्स्ड) पहले तीन के विकास और संयोजन हैं। पुस्तक में स्पष्ट रूप से कहा गया है: आपको जिस टॉपोलॉजी की आवश्यकता है, वह आपके कार्य की जटिलता पर निर्भर करती है। जितना अधिक आप कार्य को छोटे-छोटे भागों में विभाजित करते हैं, उतना ही अधिक संचार लागत बढ़ती है, और एक निश्चित सीमा के बाद, Supervisor मॉडल हायरार्किकल मॉडल की तुलना में अधिक कुशल होता है।

मेरा अनुभव है कि बहुत से लोग Multi-Agent बनाते समय 80% समय संचार प्रोटोकॉल पर खर्च कर देते हैं, और एक अधिक मूलभूत प्रश्न पूछना भूल जाते हैं: क्या इस कार्य के लिए वास्तव में कई Agent की आवश्यकता है? पुस्तक में स्पष्ट रूप से लिखा गया है कि Level 2 का एकल Agent + Reflection अक्सर पर्याप्त होता है। Level 3 केवल उन परिदृश्यों के लिए तैयार किया गया है जहाँ एकल Agent वास्तव में असमर्थ है।

मेमोरी तीन स्तरीय मॉडल, मैं पहले से ही इसे महसूस कर रहा था लेकिन इसका नाम नहीं दे पाया था

मैंने इस अध्याय के साथ सबसे अधिक सहमति व्यक्त की, क्योंकि मैंने Obsidian + Claude पर उन दो लेखों को लिखते समय एक प्रश्न पर गहराई से सोचा: एजेंट की स्मृति को कैसे स्तरबद्ध किया जाए?

पुस्तक में उत्तर दिया गया है:

1. सेशन (सेशन लेयर): वर्तमान संवाद का संदर्भ विंडो, यह सबसे छोटी स्मृति है, जो संवाद के अंत में समाप्त हो जाती है। लंबे संदर्भ मॉडल केवल इस विंडो को बढ़ाते हैं, लेकिन मूल रूप से यह अस्थायी ही रहता है, और प्रत्येक निष्पादन में पूरे विंडो को प्रोसेस करना पड़ता है, जो महंगा और धीमा होता है।

2. स्टेट (अवस्था स्तर): वर्तमान कार्य के दौरान अस्थायी डेटा। उदाहरण के लिए, “वर्तमान में कौन सा कार्य किया जा रहा है”, “कितना पूरा हो चुका है”, “मध्यवर्ती रूप से कौन से डेटा उत्पन्न हुए हैं”。 सत्र से लंबा, लेकिन कार्य समाप्त होने पर साफ़ कर दिया जाता है; पुस्तक में Google ADK के स्टेट मैकेनिज़म का पूर्ण उदाहरण दिया गया है।

3. मेमोरी (पर्सिस्टेंट लेयर): सत्रों और कार्यों के बीच लंबे समय तक की याददाश्त। उपयोगकर्ता प्राथमिकताएँ, सीखे गए अनुभव, महत्वपूर्ण ऐतिहासिक निर्णय, डेटाबेस या वेक्टर लाइब्रेरी में संग्रहीत, अर्थ-आधारित खोज। पुस्तक में एक महत्वपूर्ण बिंदु पर जोर दिया गया है: मेमोरी केवल संग्रहित करना ही नहीं, बल्कि “क्या संग्रहित करें, कब संग्रहित करें, कैसे खोजें” की पूरी रणनीति को डिज़ाइन करना है। बहुत अधिक संग्रहित करने से शोर बढ़ता है, बहुत कम संग्रहित करने से पर्याप्त नहीं होता।

मैंने Clawdbot के बारे में मेरे पिछले लेख में "स्टेटस फाइल" और "वर्कस्पेस डॉक्यूमेंट" का उल्लेख किया था, जो मूल रूप से स्टेट लेयर और मेमोरी लेयर को हाथ से बना रहा था, और किताब ने इसे एक संरचना में ढाल दिया।

पाँच मान्यताएँ, पाँचवीं सबसे अतिशयोक्तिपूर्ण

पुस्तक के अंत में एजेंट के भविष्य के बारे में पाँच अनुमान दिए गए हैं, जिनमें पहले चार अभी भी तर्कसंगत अनुमान की सीमा में हैं: सामान्य एजेंट कोड लिखने से लेकर प्रोजेक्ट मैनेज करने तक, गहन व्यक्तिगतकृत एजेंट आपकी आवश्यकताओं को सक्रिय रूप से पहचानता है, शरीरिक बुद्धिमत्ता स्क्रीन से बाहर भौतिक दुनिया में आती है, और एजेंट स्वतंत्र आर्थिक इकाई बन जाता है।

पांचवां मुझे हैरान कर गया: डिफॉर्म मल्टी-एजेंट।

आप केवल लक्ष्य घोषित करते हैं, जैसे "एक लक्ज़री कॉफी की ई-कॉमर्स व्यवसाय शुरू करें।" सिस्टम स्वयं निर्णय लेता है: पहले "बाजार अनुसंधान एजेंट" और "ब्रांड एजेंट" बनाएं। एक चक्र डेटा चलाने के बाद, सिस्टम स्वयं निर्णय लेता है कि ब्रांड एजेंट की आवश्यकता नहीं है, और इसे तीन नए एजेंट में विभाजित करता है: "लोगो डिज़ाइन एजेंट", "वेबसाइट बनाने वाला एजेंट", "सप्लाई चेन एजेंट"। यदि वेबसाइट बनाने वाला एजेंट बॉटलनेक बन जाता है, तो सिस्टम स्वयं तीन समानांतर एजेंट स्थापित करता है जो अलग-अलग पेजों पर काम करते हैं। पूरी प्रक्रिया में, सिस्टम प्रत्येक एजेंट के प्रॉम्प्ट को स्वचालित रूप से सुधारता रहता है और टीम संरचना को लगातार पुनर्गठित करता है।

पुस्तक इसे "लक्ष्य-आधारित, स्व-रूपांतरित बहु-एजेंट प्रणाली" कहती है। यह आपके द्वारा लिखे गए योजना का निष्पादन नहीं कर रही है, बल्कि यह स्वयं योजना बना रही है, स्वयं योजना को समायोजित कर रही है, और स्वयं कार्यान्वयन टीम को पुनर्गठित कर रही है।

यह मुझे कारपथी के ऑटोरिसर्च की याद दिलाता है: एक program.md लिखें, जिसमें लक्ष्य, मापदंड और सीमाएँ परिभाषित हों, और "शुरू" करें। मनुष्य चक्र के बाहर होते हैं। लेकिन यह पुस्तक आगे बढ़ जाती है: एजेंट टीम का गठन और पुनर्गठन भी प्रणाली खुद तय करती है। मनुष्य केवल "क्या चाहिए" घोषित करते हैं।

तीन ऐसी चीजें जो आप तुरंत कर सकते हैं

इस किताब को पढ़ने के बाद, मेरे पास तीन तुरंत कार्यान्वयन करने योग्य कार्रवाइयाँ हैं:

• सबसे पहले, अपने वर्तमान Agent के साथ एक Critic जोड़ें। चाहे आप Claude Code, CrewAI या अपना खुद का फ्रेमवर्क उपयोग कर रहे हों, अपने वर्तमान workflow के अंत में एक चरण जोड़ें: एक अलग system prompt के साथ दूसरे Agent को पिछले चरण के आउटपुट की समीक्षा करने के लिए भेजें। कोड जनरेशन के साथ कोड रिव्यू, लेखन के साथ तथ्यात्मक जांच, योजना निर्माण के साथ संभाव्यता मूल्यांकन। एक अतिरिक्त LLM कॉल होगी, लेकिन गुणवत्ता में दोगुनी वृद्धि होती है। पुस्तक में दिया गया Producer-Critic मॉडल प्लग-एंड-प्ले है।

• दूसरा, केवल प्रॉम्प्ट इंजीनियरिंग ही नहीं, बल्कि कॉन्टेक्स्ट इंजीनियरिंग शुरू करें। अपने एजेंट के लिए लिखे गए निर्देश फ़ाइल को वापस देखें। अगर इसमें केवल "आपको क्या करना है" के नियम हैं, और "आप अभी किस परिवेश का सामना कर रहे हैं" का कॉन्टेक्स्ट कम है, तो उसे जोड़ें। एजेंट को बताएं कि वह किस प्रोजेक्ट में है, पहले क्या निर्णय लिए गए हैं, और उपयोगकर्ता की प्राथमिकताएँ क्या हैं। पुस्तक का कॉन्टेक्स्ट इंजीनियरिंग वाला अध्याय और आपका AGENTS.md एक ही बात के दो व्यक्तीकरण हैं।

• तीसरा, Multi-Agent पर जल्दी न जाएँ। अपने एकल Agent को Level 2 तक पहुँचाएँ: उपकरण, Reflection और Memory के साथ। पुस्तक में बार-बार जोर दिया गया है कि Level 2 का एकल Agent, Producer-Critic और Context Engineering के साथ, अधिकांश वास्तविक परिदृश्यों को कवर कर सकता है। Level 3 केवल वास्तविक बहु-क्षेत्रीय, बहु-चरणीय और समानांतर विभाजन की आवश्यकता वाले कार्यों के लिए है। अधिकांश लोगों की समस्या इतनी अधिक Agent नहीं है, बल्कि एक Agent को सही से समायोजित न किए जाने की है।

यह पुस्तक 453 पृष्ठों की है, Springer 2025 द्वारा प्रकाशित। कोड उदाहरण LangChain/LangGraph, Google ADK, CrewAI, OpenAI API को कवर करते हैं। प्रस्तावना Google Cloud AI के VP द्वारा लिखी गई है, और एक Goldman Sachs CIO का अनुशंसा पत्र भी है, जो अप्रत्याशित रूप से अच्छा है।

लेकिन मैं इसकी सिफारिश इसलिए करता हूँ क्योंकि यह “व्यापक” नहीं है। आप इसे पढ़ने के बाद एक बात समझ जाएंगे: आपने पिछले छह महीनों में Agent पर जिन समस्याओं को अनुभव किया है, उन सभी को किसी ने पहले ही पैटर्न के रूप में तैयार कर दिया है। आपको Reflection फिर से बनाने की जरूरत नहीं है, आपको Memory को कैसे स्तरबद्ध करें इसका अनुमान लगाने की जरूरत नहीं है, और आपको Multi-Agent के लिए कौन सा संचार टोपोलॉजी इस्तेमाल करें इसे ट्राय करने की जरूरत नहीं है।

किसी ने आपके लिए मानचित्र बना दिया है, अब बस चलना है।

क्या आप AI एजेंट का उपयोग विकास के लिए कर रहे हैं? आपका वर्तमान एजेंट किस लेवल पर है?