इसकी कल्पना कीजिए।
आप एक एजेंट को पाँच टूल और एक निर्देश देते हैं।
आपकी रिफंड प्रक्रिया पूरी तरह सही चल सकती है।
फिर, कन्फर्मेशन ईमेल फेल हो जाता है।
एजेंट पूरा सिक्वेंस फिर से शुरू कर देता है, एक ऐसा एक्शन दोहराता है जो पहले ही सफल हो चुका है।
नतीजा? दोहरा रिफंड।
प्रोटोटाइप ने शानदार काम किया। प्रोडक्शन सिस्टम ने नहीं किया।
समस्या प्रॉम्प्ट की नहीं है।
समस्या यह है कि मॉडल से ऐसी प्रक्रिया चलाने को कहा जा रहा है जिसे उसे शुरू से चलाना ही नहीं चाहिए!
LLM को लगातार रूटिंग, शेड्यूलिंग और एरर मैनेजमेंट के लिए मजबूर किया जा रहा है।
ये ऐसे काम हैं जिन्हें सामान्य सॉफ्टवेयर पहले से ही पूरी निश्चितता के साथ संभाल लेता है।
फिर भी, हम AI से दो विरोधाभासी काम करवा रहे हैं:
- दुनिया को पढ़ना: अप्रत्याशित, असंरचित डेटा को समझना
- प्रक्रिया चलाना: घटनाओं के एक कठोर, पूर्व-परिभाषित क्रम को संचालित करना
पहला वह क्षेत्र है जहाँ AI चमकता है। दूसरा वह क्षेत्र है जहाँ पारंपरिक कोड की जगह है।
जब अगला कदम पहले से ज्ञात हो, तो मॉडल को उसका अनुमान नहीं लगाना चाहिए।
एक अकेले स्वायत्त एजेंट की कल्पना कीजिए जिसे पाँच टूल और एक बड़ा निर्देश दिया गया है:
→ खरीदारी का इतिहास प्राप्त करें
→ रिफंड नीति जाँचें
→ पात्र होने पर रिफंड जारी करें
→ ईमेल भेजें
→ फिर टिकट बंद करें
इसे अंजाम देने के लिए, एजेंट को क्रम याद रखना होगा, हर टूल के नतीजे की जाँच करनी होगी, और अनुमान लगाना होगा कि आगे क्या करना है।
अगर पैसा भेजे जाने के बाद कन्फर्मेशन ईमेल फेल हो जाता है, तो मॉडल सुरक्षित एक्ज़ीक्यूशन स्टेट से आगे बढ़ने के बजाय अपने कॉन्टेक्स्ट विंडो से वर्कफ़्लो को फिर से बनाने की कोशिश करता है।
नतीजा वही दोहरा रिफंड होता है जिसका हमने पहले ज़िक्र किया था।
ADK 2.0 कैसे अराजकता में व्यवस्था लाता है
Google का ADK 2.0 एक बिल्कुल नया दृष्टिकोण अपनाकर इस समस्या को हल करता है।
यह पूर्वानुमानित क्रियाओं को फिर से ठोस वर्कफ़्लो चरणों में बदल देता है, और AI को केवल वहीं शामिल करता है जहाँ व्याख्या की वास्तव में ज़रूरत होती है:
[रिफंड वर्कफ़्लो ग्राफ़ - स्रोत: "हमने ADK 2.0 क्यों बनाया"]
ऊपर दिए गए उदाहरण में, खरीदारी का इतिहास प्राप्त करना, रिफंड जारी करना और टिकट बंद करना सामान्य सॉफ्टवेयर क्रियाएँ हैं।
शिकायत का विश्लेषण करना और एक व्यक्तिगत कन्फर्मेशन संदेश तैयार करना AI को सौंप दिया जाता है।
परिणाम एक शानदार हाइब्रिड है: निश्चित निष्पादन के साथ केंद्रित तर्कशक्ति का संयोजन।
लेकिन आप सोच रहे होंगे: क्या यह सिर्फ़ कठोर ऑटोमेशन की वापसी नहीं है?
क्या हम उन्हीं वर्कफ़्लो को हार्ड-कोड कर रहे हैं जिन्हें एजेंटों को बदलना था?
खैर, ऐसा बिल्कुल नहीं है।
वर्कफ़्लो उन सीमाओं को परिभाषित करता है जो पहले से ज्ञात हैं।
एजेंट अब भी उन हिस्सों को संभालते हैं जिनमें व्याख्या, भाषा या निर्णय की ज़रूरत होती है।
लक्ष्य लचीलापन हटाना नहीं है, बल्कि मॉडल को हर बार एक ही निष्पादन पथ को फिर से खोजने के लिए मजबूर करना बंद करना है।
उन अनावश्यक मॉडल निर्णयों को खत्म करके, यह आर्किटेक्चर पूरा हिसाब-किताब बदल देता है।
वही रिफंड वर्कफ़्लो। वही मॉडल।
लेकिन ADK 2.0 के साथ, टोकन 5,152 से घटकर 2,265 हो गए, और लेटेंसी 7.2s से गिरकर 5.7s हो गई 🔥
[स्रोत: "हमने ADK 2.0 क्यों बनाया"]
यह संरचना एक प्राकृतिक फ़िल्टर की तरह काम करती है जो टोकन उपयोग को आधा कर देती है।
पूरा इतिहास पास करने के बजाय, एजेंट केवल वही देखते हैं जिसकी उन्हें ज़रूरत होती है (उदाहरण के लिए, पॉलिसी एजेंट केवल शिकायत देखता है)।
लाभ तुरंत दिखते हैं:
- कम प्रॉम्प्ट शोर और बेहतर प्राइवेसी
- पूरी तरह नियंत्रित निष्पादन
- फेल-सेफ: मॉडल गलत निर्णय ले सकता है, लेकिन वह कभी अपना खुद का रास्ता नहीं बना सकता
फ्रंटएंड को भी सीमाओं की ज़रूरत है: A2UI आपके UI को नियंत्रण में कैसे रखता है
यह बहुत अच्छा है। रिफंड वर्कफ़्लो अब नियंत्रण में है।
ADK 2.0 ने रास्ता तय कर दिया और एजेंट को अपना खुद का क्रम बनाने से रोक दिया।
लेकिन उपयोगकर्ता को अभी भी एजेंट के आउटपुट को देखने और उस पर कार्य करने का एक सुरक्षित तरीका चाहिए।
दूसरे शब्दों में, फ्रंटएंड को भी सीमाओं की ज़रूरत है!
कल्पना कीजिए कि अब हर स्वीकृत रिफंड के लिए सुपरवाइज़र के हस्ताक्षर आवश्यक हैं।
एजेंट को सिर्फ़ यह टेक्स्ट जनरेट नहीं कर देना चाहिए:
“यह रिफंड स्वीकृत है।”
उसे एक संरचित कार्ड दिखाना होगा जिसमें शामिल हो:
- राशि
- ट्रांज़ैक्शन
- पॉलिसी का कारण
- स्पष्ट 'Approve/Reject' बटन
यही वह जगह है जहाँ Google का A2UI आगे आता है!
A2UI के साथ, एजेंट एक्ज़ीक्यूटेबल फ्रंटएंड कोड के बजाय एक डिक्लेरेटिव JSON पेलोड लौटाता है।
होस्ट उस पेलोड को मान्य करता है और केवल अपने कैटलॉग द्वारा समर्थित कंपोनेंट्स को रेंडर करता है।
एजेंट तय करता है कि कौन सी जानकारी दिखाई जाए, और ऐप नियंत्रित करता है कि वह कैसे रेंडर हो।
👇 नीचे A2UI द्वारा रेंडर किए गए कार्ड के उदाहरण दिए गए हैं, जो आपको A2UI द्वारा संभव UI कंपोज़िशन की विस्तृत विविधता दिखाते हैं:
Google का A2UI-over-MCP Recipe Studio डेमो इस आर्किटेक्चर को व्यवहार में दिखाता है:
स्रोत: Google Developers Blog.
👆 आप देख सकते हैं कि एक स्थिर चयन फ़ॉर्म MCP Resource के माध्यम से प्रदान किया जाता है, जबकि एक गतिशील रूप से जनरेट किया गया रेसिपी कार्ड MCP Tool के माध्यम से लौटाया जाता है।
A2UI दोनों को होस्ट एप्लिकेशन के भीतर नेटिव रूप से रेंडर करता है।
समानता देख रहे हैं?
- ADK 2.0 बैकएंड पर एजेंट जो कर सकता है उसे सीमित करता है
- A2UI फ्रंटएंड पर उसके द्वारा बनाई जा सकने वाली चीज़ों को सीमित करता है
दोनों मामलों में, मॉडल के पास तर्क करने की गुंजाइश होती है, लेकिन केवल उन्हीं सीमाओं के भीतर जो एप्लिकेशन ने परिभाषित की हैं।
ऊपर चर्चा किए गए रिफंड उदाहरण पर वापस आते हुए, एक सामान्य रिफंड के लिए केवल एक साधारण अनुमोदन कार्ड की ज़रूरत हो सकती है।
लेकिन अपवादों, अटैचमेंट या आंशिक भुगतान वाले विवादित मामले के लिए एक समृद्ध अनुभव की आवश्यकता हो सकती है।
यहीं पर एक MCP App आगे आकर जटिल इंटरैक्शन के लिए एक सीमित कार्यक्षेत्र प्रदान कर सकता है:
→ ADK नियंत्रित करता है कि क्या हो सकता है
→ A2UI नतीजे को दृश्यमान और एक्शनेबल बनाता है
→ MCP Apps जटिल कार्यक्षेत्रों को संभालते हैं
और जानने को उत्सुक हैं?
ADK 2.0, A2UI और Google Cloud के व्यापक एजेंट प्लेटफ़ॉर्म को एक्सप्लोर करने के लिए यहाँ वह सब कुछ है जो आपको चाहिए:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
@googlecloud के साथ इस प्रोजेक्ट पर साझेदारी करना सौभाग्य की बात थी! 🤝
अगर आप LLM, AI एजेंट और वर्कफ़्लो की नवीनतम जानकारी से अपडेट रहना चाहते हैं, तो दैनिक इनसाइट्स के लिए आप मुझे @datachaz पर फॉलो कर सकते हैं।
