Antigravity के एजेंट एक लेयर्ड आर्किटेक्चर पर बने हैं, जो रियल-टाइम परसेप्शन, पर्सिस्टेंट मेमोरी और टूल कॉलिंग को जोड़ता है, ताकि जटिल काम बिना मानवीय हस्तक्षेप के पूरे हो सकें। यह लेख हर लेयर को तोड़कर समझाता है, प्लानिंग इंजन से लेकर मल्टी-एजेंट कोऑर्डिनेशन तक, और दिखाता है कि असल इंटेलिजेंस कहाँ से आती है और इसमें इमेज जनरेशन कहाँ फिट होती है।
Antigravity ने वह बनाया है जिस पर ज़्यादातर AI कंपनियाँ सिर्फ़ बात करती हैं: ऐसे एजेंट जो सचमुच काम पूरे करते हैं। ये वे चैटबॉट नहीं हैं जो सवालों का जवाब देते हैं, और न ही वे कोपायलट हैं जो अगले प्रॉम्प्ट का इंतज़ार करते हैं। ये ऐसे सॉफ़्टवेयर हैं जो प्लान बनाते हैं, टूल कॉल करते हैं, अपने आउटपुट की जाँच करते हैं और काम खत्म करते हैं। यह समझने के लिए कि ये एजेंट कैसे काम करते हैं, नीचे के आर्किटेक्चर को देखना होगा, और वह मार्केटिंग के दावों से कहीं कम रहस्यमय है।
Antigravity एक AI इंफ़्रास्ट्रक्चर कंपनी है जो ऑटोनॉमस एजेंट सिस्टम पर केंद्रित है। इनका मुख्य प्रोडक्ट एक ऐसा प्लेटफ़ॉर्म है जहाँ डेवलपर ऐसे एजेंट डिप्लॉय करते हैं जो वेब ब्राउज़ कर सकते हैं, कोड लिख और चला सकते हैं, फ़ाइलें मैनेज कर सकते हैं, बाहरी APIs कॉल कर सकते हैं, और एक ही एक्ज़िक्यूशन एनवायरनमेंट में दूसरे एजेंटों के साथ कोऑर्डिनेट कर सकते हैं।
इनके तरीके को जो अलग बनाता है वह है टास्क स्तर पर भरोसेमंदी, न कि केवल रिस्पॉन्स स्तर पर। ज़्यादातर LLM एक ही आउटपुट की क्वालिटी को ऑप्टिमाइज़ करते हैं। Antigravity का सिस्टम पूरे हुए टास्क की क्वालिटी को ऑप्टिमाइज़ करता है, और यह एक बुनियादी रूप से अलग समस्या है।
"किसी मैसेज का जवाब देने" से "टास्क पूरा करने" तक का बदलाव सिस्टम के डिज़ाइन को पूरी तरह बदल देता है। चैट इंटरफ़ेस में एक ही लूप होता है: इनपुट अंदर, आउटपुट बाहर। एजेंट सिस्टम में कई लूप होते हैं, ब्रांचिंग फ़ैसले होते हैं, एरर स्टेट होते हैं, रिट्राई होते हैं, और कई स्पेशलाइज़्ड कंपोनेंट्स के बीच कोऑर्डिनेशन होता है।
Antigravity इस जटिलता के लिए शुरू से ही डिज़ाइन करता है, इसीलिए इसके एजेंट चैटबॉट से ज़्यादा सॉफ़्टवेयर सिस्टम की तरह व्यवहार करते हैं।
सबसे ऊपर के स्तर पर, Antigravity का एजेंट एक लूप है। वह एक उद्देश्य (objective) लेता है, प्लान बनाता है, स्टेप्स चलाता है, नतीजों को देखता है और प्लान को तब तक अपडेट करता है जब तक टास्क पूरा न हो जाए या कोई पक्की सीमा न आ जाए। यह क्लासिक ReAct (Reason + Act) पैटर्न है, जिसे पर्सिस्टेंट मेमोरी, टूल रजिस्ट्री और मल्टी-एजेंट रूटिंग के साथ बढ़ाया गया है।
लेयर्स इस तरह बँटती हैं:
| परत | काम | मुख्य घटक |
|---|---|---|
| परसेप्शन | इनपुट लेता है, संदर्भ को पार्स करता है | कॉन्टेक्स्ट विंडो + एम्बेडिंग्स |
| प्लानिंग | लक्ष्यों को चरणों में तोड़ता है | LLM रीज़निंग + स्क्रैचपैड |
| एक्शन | टूल्स को कॉल करता है, कोड लिखता है | टूल रजिस्ट्री + फ़ंक्शन कॉल्स |
| मेमोरी | स्टेट को सेव और रिट्रीव करता है | शॉर्ट-टर्म + लॉन्ग-टर्म स्टोर्स |
| ऑब्ज़र्वेशन | आउटपुट का मूल्यांकन करता है | सेल्फ़-क्रिटीक + वैलिडेशन |
| कोऑर्डिनेशन | दूसरे एजेंट्स तक रूट करता है | ऑर्केस्ट्रेटर लेयर |
हर लेयर का एक अलग काम है। किसी एक लेयर में विफलता का मतलब यह नहीं कि पूरी पाइपलाइन टूट जाए, क्योंकि हर जोड़ पर फ़ॉलबैक मैकेनिज़्म मौजूद हैं।
कोई एजेंट कुछ करने से पहले उसे समझना होता है कि उससे क्या माँगा गया है। परसेप्शन लेयर आने वाले निर्देश को ग्रहण करती है और उसे एजेंट की मेमोरी स्टोर्स से मिले संबंधित कॉन्टेक्स्ट से समृद्ध करती है।
यह सिर्फ़ "प्रॉम्प्ट पढ़ना" नहीं है। परसेप्शन लेयर:
एक अच्छी तरह डिज़ाइन की गई परसेप्शन लेयर एजेंट की सबसे आम विफलता को रोकती है: गलत समझे गए निर्देश पर 20 स्टेप्स तक काम करते रहना, गलती पकड़ में आने से पहले।
एक बार एजेंट टास्क समझ लेता है, तो प्लानिंग इंजन उसे सब-टास्क के एक संरचित क्रम में तोड़ देता है। यहीं LLM की रीज़निंग क्षमता सबसे ज़्यादा काम करती है।
प्लानर टास्क की जटिलता के हिसाब से दो मोड में काम करता है:
सीक्वेंशियल प्लानिंग: सरल, रैखिक टास्क के लिए, एजेंट एक स्टेप-बाय-स्टेप चेकलिस्ट बनाता है और हर आइटम को क्रम से चलाता है। फ़ाइल ऑर्गनाइज़ेशन, डेटा एक्सट्रैक्शन, रिपोर्ट जनरेशन, ये सब इसी पैटर्न में फ़िट होते हैं।
हाइरार्किकल प्लानिंग: जटिल, मल्टी-स्टेप उद्देश्यों के लिए, एजेंट एक हाई-लेवल प्लान बनाता है और फिर हर ब्रांच के लिए सब-प्लान बनाता है। "प्रतिस्पर्धियों पर रिसर्च करें, तुलना तालिका बनाएँ और सारांश ईमेल का ड्राफ़्ट लिखें" जैसा टास्क सौंपे गए सब-टास्क के एक ट्री में बदल जाता है।
प्लानिंग लूप के भीतर, एजेंट एक स्क्रैचपैड रखता है: एक चलता हुआ आंतरिक मोनोलॉग जो अंतिम आउटपुट से अलग होता है। स्क्रैचपैड वह जगह है जहाँ एजेंट बीच के स्टेप्स निकालता है, लॉजिक जाँचता है और किसी एक्शन को करने से पहले खुद को सुधारता है।
यह Antigravity के सबसे महत्वपूर्ण डिज़ाइन फ़ैसलों में से एक है। स्क्रैचपैड के बिना एजेंट को एक ही फ़ॉरवर्ड पास में रीज़न करना पड़ता है, जो नाज़ुक है। स्क्रैचपैड के साथ वह एक्ज़िक्यूशन के बीच में अपनी सोच बदल सकता है, बिना आउटपुट को गंदा किए या टूल कॉल्स को उलझाए।
💡 स्क्रैचपैड को डेवलपर के व्हाइटबोर्ड की तरह समझें: उसमें गड़बड़ी होती है, चीज़ें काटी जाती हैं, लेकिन अंतिम आउटपुट साफ़ और सोच-समझकर बनाया गया होता है।
एक्शन के बिना प्लानिंग बेकार है। Antigravity के एजेंट एक टूल रजिस्ट्री के ज़रिए काम करते हैं, जो कॉल किए जा सकने वाले फ़ंक्शन्स की एक संरचित सूची है, जिसमें परिभाषित स्कीमा, अपेक्षित इनपुट और आउटपुट फ़ॉर्मेट होते हैं।
टूल्स कई श्रेणियों में आते हैं:
जब एजेंट कोई टूल इस्तेमाल करने का फ़ैसला करता है, तो वह सिर्फ़ "फ़ंक्शन कॉल" नहीं करता। वह स्पष्ट पैरामीटर्स के साथ एक टूल कॉल ऑब्जेक्ट बनाता है, उसे टूल स्कीमा के खिलाफ़ वैलिडेट करता है, उसे भेजता है, और फिर अगला स्टेप तय करने से पहले लौटे नतीजे को पार्स करता है। पूरी प्रक्रिया लॉग की जाती है और ऑडिट की जा सकती है।
इन शब्दों को अक्सर एक-दूसरे की जगह इस्तेमाल किया जाता है। फ़ंक्शन कॉलिंग मूल क्षमता है: LLM ऐसा स्ट्रक्चर्ड JSON आउटपुट कर सकता है जो किसी फ़ंक्शन सिग्नेचर से मेल खाता हो। टूल यूज़ ऊपर की परत का सिस्टम है: वह इंफ़्रास्ट्रक्चर जो उस JSON को प्राप्त करता है, असल में फ़ंक्शन चलाता है और नतीजा एजेंट के कॉन्टेक्स्ट में वापस डालता है। Antigravity दोनों परतों को संभालता है।
मेमोरी ही एक वन-शॉट एजेंट को उस एजेंट से अलग करती है जो अपने खुद के एक्ज़िक्यूशन इतिहास से सचमुच सीखता है।
Antigravity की मेमोरी प्रणाली में दो अलग स्टोर्स हैं:
कॉन्टेक्स्ट विंडो एक ही रन के लिए एजेंट की वर्किंग मेमोरी है। एजेंट जो कुछ भी अभी जानता है, मूल निर्देश, प्लान, टूल आउटपुट, स्क्रैचपैड नोट्स, सब एक्ज़िक्यूशन के दौरान यहीं रहते हैं।
कॉन्टेक्स्ट विंडोज़ की सीमाएँ टोकन में तय होती हैं। यह तय करना कि विंडो में क्या रहेगा और क्या समरी होगा या बाहर भेजा जाएगा, एक असली इंजीनियरिंग चुनौती है। Antigravity डायनामिक कॉन्टेक्स्ट कंप्रेशन का इस्तेमाल करता है: कॉन्टेक्स्ट भरने के साथ पुराना, कम प्राथमिकता वाला कंटेंट समरी हो जाता है, जबकि हाल का और उच्च-प्रासंगिकता वाला कंटेंट पूरी डिटेल में रखा जाता है।
रन के बीच, एजेंट्स को जानकारी सहेजनी होती है और बाद में उसे वापस लाना होता है। Antigravity इन चीज़ों का मेल इस्तेमाल करता है:
जब कोई नया टास्क शुरू होता है, तो परसेप्शन लेयर तीनों स्टोर्स से क्वेरी करती है और सबसे प्रासंगिक कंटेंट को शुरुआती कॉन्टेक्स्ट विंडो में डालती है। एजेंट खाली शुरुआत नहीं करता, बल्कि संबंधित इतिहास के साथ "गर्म" शुरुआत करता है।
हर टूल कॉल के बाद, एजेंट एक ऑब्ज़र्वेशन स्टेप चलाता है: वह आउटपुट को उसकी अपेक्षा से मिलाकर जाँचता है। यहीं सेल्फ़-करेक्शन होता है।
ऑब्ज़र्वेशन लॉजिक ये जाँचता है:
यह लूप, Plan, Act, Observe, Repeat, हर Antigravity एजेंट की धड़कन है। इटरेशन की संख्या तय नहीं होती; यह तब तक चलता है जब तक काम पूरा न हो या कोई कॉन्फ़िगर्ड सेफ़्टी लिमिट उसे रोक न दे।
लूप शक्तिशाली है, पर कुछ खास विफलता स्थितियों में नाज़ुक है। सबसे आम ये हैं:
💡 सबसे अच्छे एजेंट सुरक्षित तरीके से विफल होते हैं। जब Antigravity का सिस्टम किसी पक्की सीमा पर पहुँचता है, तो वह चुपचाप फ़ेल नहीं होता, बल्कि आखिरी ज्ञात स्टेट के साथ एक स्ट्रक्चर्ड एरर लौटाता है।
अकेले एजेंट की सीमाएँ होती हैं। कुछ टास्क बहुत व्यापक हैं, बहुत लंबे हैं, या इतनी सारी स्पेशलाइज़्ड क्षमताएँ चाहते हैं कि एक एक्ज़िक्यूशन कॉन्टेक्स्ट में न समाएँ। यहीं मल्टी-एजेंट सिस्टम्स काम आते हैं।
Antigravity एक हाइरार्किकल कोऑर्डिनेशन मॉडल इस्तेमाल करता है:
एक ऑर्केस्ट्रेटर एजेंट सबसे ऊपरी स्तर पर बैठता है। वह हाई-लेवल उद्देश्य लेता है, उसे सबटास्क्स में तोड़ता है, और हर सबटास्क को उस खास काम के लिए सही टूल्स और कॉन्टेक्स्ट वाले स्पेशलाइज़्ड सबएजेंट को सौंपता है।
"हमारी वेबसाइट का SEO ऑडिट करें और प्राथमिकता वाली फ़िक्स सूची लिखें" जैसे टास्क के लिए, ऑर्केस्ट्रेटर काम को इन में बाँटता है:
हर सबएजेंट स्वतंत्र रूप से चलता है। ऑर्केस्ट्रेटर उनके आउटपुट इकट्ठा करता है, टकराव सुलझाता है, और अंतिम नतीजा जोड़ता है।
कोऑर्डिनेशन के लिए साझा स्टेट चाहिए। किसी टास्क के सभी एजेंट एक टास्क कॉन्टेक्स्ट स्टोर तक पहुँच रखते हैं: एक स्कोप्ड ऑब्जेक्ट जिसमें मूल उद्देश्य, मौजूदा प्रगति, बीच के आउटपुट और यूज़र द्वारा तय की गई कोई भी शर्त होती है।
जब कोई एजेंट अपना सबटास्क पूरा करता है, तो वह अपना आउटपुट साझा कॉन्टेक्स्ट में लिखता है और ऑर्केस्ट्रेटर को संकेत देता है। हैंडऑफ़ स्पष्ट होते हैं, निहित नहीं, यानी एजेंट्स के बीच जानकारी सौंपते समय कोई डेटा नहीं खोता।
आर्किटेक्चर दिलचस्प है, पर व्यवहार में यह कैसा दिखता है? Antigravity के एजेंट कई असली श्रेणियों में टास्क संभालते हैं:
| टास्क का प्रकार | उदाहरण | शामिल एजेंट्स |
|---|---|---|
| रिसर्च | 20 वेबसाइटों से प्रतिस्पर्धियों की कीमतें इकट्ठा करना | क्रॉलर + एनालिस्ट |
| कंटेंट | कीवर्ड ब्रीफ़ से ब्लॉग पोस्ट लिखना | प्लानर + राइटर + एडिटर |
| डेटा वर्क | CSV साफ़ करना और चार्ट बनाना | कोड एक्ज़ीक्यूटर + फ़ॉर्मेटर |
| ऑटोमेशन | किसी साइट पर नज़र रखना और बदलावों पर अलर्ट भेजना | मॉनिटर + नोटिफ़ायर |
| क्रिएटिव | इमेज प्रॉम्प्ट्स बनाना और विज़ुअल्स तैयार करना | राइटर + इमेज एजेंट |
क्रिएटिव वर्कफ़्लो खास दिलचस्प है। इमेज जनरेट करने वाला एजेंट प्रॉम्प्ट्स बस रैंडम तरीके से नहीं गढ़ता। वह ब्रीफ़ के आधार पर स्टाइल, सब्जेक्ट और कंपोज़िशन पर रीज़न करता है, फिर स्ट्रक्चर्ड पैरामीटर्स के साथ एक इमेज जनरेशन टूल कॉल करता है। नतीजा कॉन्टेक्स्ट में वापस डाला जाता है, ब्रीफ़ से मिलाकर जाँचा जाता है, और ज़रूरत हो तो सुधारा जाता है।
जब कोई Antigravity एजेंट क्रिएटिव काम संभालता है, तो वह आमतौर पर बाहरी इमेज जनरेशन APIs से जुड़ता है। PicassoIA पर उपलब्ध वही मॉडल इन विज़ुअल आउटपुट को चलाते हैं।
विज़ुअल कंटेंट के लिए एक एजेंट पाइपलाइन इन्हें कॉल कर सकती है:
एजेंट टास्क के संदर्भ, बजट की सीमाओं और क्वालिटी की ज़रूरतों के आधार पर सही मॉडल चुनता है। वह हमेशा सबसे शक्तिशाली मॉडल नहीं चुनता; वह उस खास स्टेप के लिए सही मॉडल चुनता है।
यह बात ज़्यादातर लोग नज़रअंदाज़ कर देते हैं: जब एजेंट इमेज प्रॉम्प्ट लिखता है, तो वह वही रीज़निंग लूप लगाता है जो वह बाकी हर चीज़ के लिए इस्तेमाल करता है। वह एक प्रॉम्प्ट का ड्राफ़्ट बनाता है, उसे इमेज मॉडल को भेजता है, इमेज URL पाता है, आउटपुट को ब्रीफ़ से मिलाकर जाँचता है (कभी-कभी विज़न मॉडल से नतीजा "देखकर"), और अगर आउटपुट अपेक्षा से मेल नहीं खाता तो प्रॉम्प्ट को सुधारता है।
यह ऑटोपायलट पर प्रॉम्प्ट इंजीनियरिंग है, और इसीलिए AI एजेंट वर्कफ़्लो हाथ से एक-बार के प्रॉम्प्टिंग की तुलना में लगातार बेहतर क्रिएटिव आउटपुट देते हैं।
💡 एजेंट सिर्फ़ प्रॉम्प्ट नहीं लिख रहा। वह उन्हें टेस्ट करता है, नतीजों को देखता है और एक संरचित लूप में उन्हें बेहतर बनाता है, ठीक उसी तरह जैसे एक कुशल मानवीय प्रॉम्प्ट इंजीनियर करेगा, बस बिना हाथ से दोहराने की मेहनत के।
कोई गंभीर एजेंट प्लेटफ़ॉर्म बिना कंट्रोल्स के नहीं आता। Antigravity कई कंट्रोल लागू करता है:
इससे Antigravity का सिस्टम प्रोडक्शन एनवायरनमेंट के लिए उपयुक्त बनता है, जहाँ जवाबदेही मायने रखती है, न कि सिर्फ़ रिसर्च डेमो।
Antigravity का आर्किटेक्चर दिखाता है कि सबसे शक्तिशाली AI सिस्टम एकल मॉडल नहीं होते। वे स्पेशलाइज़्ड क्षमताओं की पाइपलाइन होते हैं, जिनमें हर एक अपना एक काम अच्छे से करता है, और एक रीज़निंग लेयर उन्हें कोऑर्डिनेट करती है जो जानती है कि कब क्या कॉल करना है।
PicassoIA पर इमेज मॉडल भी इसी सिद्धांत पर काम करते हैं। PicassoIA Image, Flux Redux Dev और GPT Image 1 खास तौर पर बनाए गए टूल्स हैं, जो लोग इन्हें इरादे और संरचना के साथ प्रॉम्प्ट करते हैं, उनके हाथों में ये प्रोफ़ेशनल फ़ोटोग्राफ़ी और इलस्ट्रेशन को टक्कर देने वाले नतीजे देते हैं।
इस सोच का फ़ायदा उठाने के लिए आपको एजेंट सिस्टम की ज़रूरत नहीं है। एक साफ़ ब्रीफ़ से शुरू करें, अपने आउटपुट प्रकार के लिए सही मॉडल चुनें, और Antigravity के आर्किटेक्चर में बसी ऑब्ज़र्वेशन सोच का इस्तेमाल करते हुए अपने प्रॉम्प्ट्स को बेहतर बनाएँ। जो सिद्धांत AI एजेंट्स को प्रभावी बनाते हैं, यानी संरचित सोच, सही टूल्स और एक फ़ीडबैक लूप, वही अकेले AI इमेज जनरेशन को भी प्रभावी बनाते हैं।
PicassoIA पर अभी आज़माएँ और देखें कि एक अच्छी तरह संरचित प्रॉम्प्ट पहली बार में कैसा नतीजा देता है।
अपनी भाषा चुनें
