Azure AI Foundry Threads

Azure AI Foundry में AI एजेंट बनाते समय आप सिर्फ़ एक बड़ा मॉडल शुरू नहीं करते। आप उसे एक प्रबंधित रनटाइम में चलाते हैं, जहाँ हर प्रासंगिक क्रिया, संदेश, टूल कॉल और run step लॉग और ट्रैस किया जाता है। यही रिकॉर्ड एजेंट को एक अनुशासित, ऑडिट-योग्य और एंटरप्राइज़-तैयार सिस्टम बनाता है।

इस लेख में हम देखेंगे कि एजेंट किन तीन हिस्सों से बनता है, Threads, Runs और Run Steps मिलकर कौन सा "पेपर ट्रेल" बनाते हैं, और टूल्स व सुरक्षा कैसे काम करते हैं।

Azure AI Foundry एजेंट क्या है: मॉडल, निर्देश और टूल्स

Foundry में एजेंट सेट अप करना चैट विंडो खोलने जैसा नहीं है। यह एक फ़ील्ड कैप्टन तैनात करने जैसा है, जो ऑटो-कम्प्लीट टाइप करने वाला इंटर्न नहीं बल्कि एक तय डिज़ाइन पर मिशन चलाने वाला लीडर है। यह डिज़ाइन तीन हिस्सों पर टिका है।

• मॉडल: एजेंट का मस्तिष्क। यह तर्क और भाषा संभालता है, इंसानी शब्द समझता है और जवाब लिखता है।
• निर्देश (Instructions): मिशन के आदेश। ये मस्तिष्क को भटकने से रोकते हैं और उसे उन नतीजों से जोड़ते हैं जो आपको वास्तव में चाहिए।
• टूल्स: एजेंट के औज़ार, जैसे कोड निष्पादन, सर्च कनेक्टर, रिपोर्टिंग, API या कोई भी थर्ड-पार्टी सिस्टम।

इस तिकड़ी के बिना न दोहराने योग्य नतीजे मिलते हैं, न ऑडिट की क्षमता। बस बिना रिकॉर्ड की बातचीत रह जाती है। मॉडल को कैप्टन का प्रशिक्षण समझें, निर्देश को मिशन की ब्रीफ़िंग और टूल्स को उसके उपकरण। उदाहरण के लिए, Code Interpreter विश्लेषण चलाने का साधन है, जबकि SharePoint या कस्टम MCP कनेक्टर प्लान में लाइव डेटा पहुँचाते हैं। तीनों साथ हों तो एजेंट अपनी मर्ज़ी से कुछ नहीं करता, वह लॉग और चेकपॉइंट के साथ मिशन निष्पादित करता है।

सामान्य चैट API से अंतर

ज़्यादातर चैट API में आपको सिर्फ़ मॉडल और प्रॉम्प्ट मिलता है। टूल्स और निर्देशों की कोई औपचारिक व्यवस्था नहीं होती। Foundry Agent Service यह सुनिश्चित करती है कि तीनों हिस्से मौजूद हों। साथ ही आप एक ही मॉडल से बँधे नहीं रहते। Foundry कैटलॉग में जटिल तर्क के लिए GPT-4, हल्के कामों के लिए कोई छोटा मॉडल, या Mistral और DeepSeek जैसे विकल्प चुने जा सकते हैं। मिशन के हिसाब से मॉडल बदलने की यह लचीलापन ही इसे अनुभवी कमांडर जैसा बनाती है।

Threads: एजेंट की स्थायी बातचीत और ऑडिट लॉग

Azure AI Foundry में Thread कोई साधारण चैट विंडो नहीं है जो बंद करते ही गायब हो जाए। यह एक स्थायी बातचीत सत्र है, जिसमें आपके, एजेंट के और मल्टी-एजेंट सेटअप में किसी दूसरे एजेंट के बीच हर आदान-प्रदान संग्रहीत होता है। चैट खत्म होने के बाद भी उसे देखा जा सकता है।

Thread सिर्फ़ स्थिर ट्रांसक्रिप्ट भी नहीं है। यह एक संरचित कंटेनर है। इससे एजेंट के पास बातचीत की निरंतरता रहती है और संगठन के पास समीक्षा-योग्य स्थायी रिकॉर्ड, यानी एजेंट के लिए continuity और संगठन के लिए governance।

Thread में क्या-क्या दर्ज होता है

Thread की प्रविष्टियाँ संदेशों से बनती हैं, और संदेश सिर्फ़ सादा text नहीं होता। उसमें image, spreadsheet file या generate किया गया code block भी हो सकता है। हर संदेश पर time stamp होता है और उस पर user या assistant की भूमिका का label लगा होता है। इसलिए Thread जाँचते समय आप सिर्फ़ यह नहीं देखते कि क्या कहा गया, बल्कि यह भी कि किसने, कब और किस तरह की सामग्री के साथ कहा।

कल्पना करें कि एक अनुपालन अधिकारी रिकॉर्ड खोलता है। उसे उपयोगकर्ता का सटीक अनुरोध, एजेंट का बनाया चार्ट और दोनों घटनाओं का समय एक जगह दिख जाता है। यह सिर्फ़ याददाश्त नहीं, पूरा बही-खाता है। गेमिंग की भाषा में कहें तो Thread किसी Dungeons & Dragons अभियान की नोटबुक जैसा है, जहाँ Dungeon Master लिखता है कि कौन से रोल सफल रहे और क्या लूट मिली। लॉग न हो तो खिलाड़ी भूले हुए ब्योरों पर बहस करते रहते हैं। लॉग हो तो बहस खत्म हो जाती है, क्योंकि घटनाएँ दर्ज हैं।

ऑडिट, अनुपालन और डिबगिंग में Threads

नियामक और अनुपालन टीमें Thread खोलकर तुरंत पूरा क्रम देख सकती हैं: उपयोगकर्ता का अनुरोध, एजेंट की प्रतिक्रिया, कौन से उपकरण शामिल थे और यह सब कब हुआ। डेवलपर्स के लिए वही रिकॉर्ड डिबग मोड का काम करता है। अगर एजेंट ने गलत कोड बनाया, तो आप Thread में उस बिंदु तक पीछे जा सकते हैं जहाँ सवाल पूछा गया था और देख सकते हैं कि वह वहाँ तक कैसे पहुँचा।

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

Runs और Run Steps: हर कदम का रिकॉर्ड

Thread बातचीत का बैकलॉग, आदेश और संदर्भ रखता है। Run वह ट्रिगर है जो एजेंट को सक्रिय करता है ताकि वह उस संदर्भ को लेकर काम निष्पादित करे। Thread याद रखता है, Run काम करता है। मान लीजिए Thread में लिखा है, "CSV का विश्लेषण करें और एक line graph बनाएँ।" Run वह क्षण है जब एजेंट इस अनुरोध को अपने मॉडल, निर्देशों और टूल्स से प्रोसेस करता है। वह डेटा ला सकता है, गणना कर सकता है और artifact बनाने के लिए Code Interpreter को कॉल कर सकता है। टेबलटॉप RPG की भाषा में Thread मेज़ के चारों ओर जुटी पार्टी है और Run वह initiative roll है जो लड़ाई शुरू करता है।

Run कोई ब्लैक बॉक्स नहीं

Foundry में Runs निगरानी और स्थिति-ट्रैकिंग वाले निष्पादन हैं। आप आम तौर पर कतारबद्ध, प्रगति में, कार्रवाई की आवश्यकता, पूर्ण या विफल जैसी स्थितियाँ देखते हैं। SDK samples अक्सर इन स्थितियों को एक लूप में poll करते हैं। इससे पता चलता है कि क्या हुआ और यह भी कि कब हो रहा है।

पर एक बड़ी चिंता बचती है: निष्पादन के अंदर वास्तव में क्या हुआ? जवाब ठीक दिख सकता है, लेकिन ब्योरे के बिना यह कहना मुश्किल है कि एजेंट ने बाहरी API को कॉल किया, कोड लिखा या सिर्फ़ text बनाया। एंटरप्राइज़ में यह अस्पष्टता खतरनाक है। यह शतरंज के उस खेल में बीच में पहुँचने जैसा है जहाँ कोई कहे, "भरोसा रखिए, सही चालें चली गई थीं।"

Run Steps: शतरंज के नोटेशन जैसा लॉग

Run Steps इसी अस्पष्टता को हटाते हैं। हर Run क्रमवार रिकॉर्ड होता है: कौन से मॉडल आउटपुट बने, कौन से टूल इस्तेमाल हुए, कौन सी क्रियाएँ हुईं और कौन से संदेश तैयार हुए। यह AI के लिए शतरंज नोटेशन जैसा है, जहाँ चालें क्रम से लिखी होती हैं। यहाँ क्रम कुछ ऐसा हो सकता है: फ़ाइल लाना, कोड इंटरप्रेटर में निष्पादित करना, ग्राफ़ artifact लौटाना।

• डेवलपर्स के लिए: run steps के बिना आप सिर्फ़ अंतिम उत्तर देखते हैं और अंदाज़ा लगाते हैं कि खोज गलत थी या गणना में चूक हुई। steps के साथ आप टाइमलाइन स्क्रॉल करके चूक पकड़ सकते हैं। डिबगिंग अंदाज़े से फ़ोरेंसिक जाँच बन जाती है।
• अनुपालन टीमों के लिए: जब ऑडिटर पूछें कि यह सारांश कैसे बना, तो आपको मॉडल के तर्क को शब्दों में समझाना नहीं पड़ता। आपके पास सबूत होते हैं: टूल कॉल, इंटरप्रेटर का कदम, तैयार artifact और हर चीज़ का time stamp। इस तरह स्पष्टीकरण governance में बदल जाता है।
• रोज़मर्रा के कामों के लिए: run steps दोहराने योग्य पैटर्न बनाते हैं। वर्कफ़्लो दोबारा चलाना हो तो वही क्रम अपनाया जा सकता है, और किसी नतीजे पर सवाल उठे तो उसे फिर से चलाया जा सकता है।

इस तरह एजेंट लाइफ़साइकल पूरा होता है: Threads में डायरी, Run में सक्रियता और Run Steps में हर कदम का लॉग। यह तीनों मिलकर तात्कालिक AI को जवाबदेह टीममेट बना देते हैं, जिसके कार्यों को आप ट्रैस, टेस्ट और डिफ़ेंड कर सकते हैं।

Tools: बिल्ट-इन, OpenAPI, MCP और Entra सुरक्षा

टूल्स एजेंट को बातचीत से काम तक ले जाते हैं। दस्तावेज़ की जाँच या गणना का तरीका बताने के बजाय एजेंट वह काम करके आउटपुट लौटा सकता है। Foundry क्षमता की तीन श्रेणियाँ देता है।

1. बिल्ट-इन टूल्स: Code Interpreter, Bing Search, SharePoint और Microsoft Fabric कनेक्टर्स तथा Azure AI Search। इनसे एजेंट डेटा का विश्लेषण कर सकता है, फ़ाइलें प्रोसेस कर सकता है, एंटरप्राइज़ कंटेंट खोज सकता है और बिना कस्टम glue के चार्ट व रिपोर्ट बना सकता है।
2. कस्टम टूल्स: आप Open API specs या Model Context Protocol (MCP) से अपने टूल रजिस्टर कर सकते हैं। MCP को AI टूल्स के लिए USB-C की तरह समझा जा सकता है। Remote MCP server से जुड़ते समय हर बार नया wrapper लिखने के बजाय सिस्टम टूल डिस्कवरी, वर्जनिंग और इन्वोकेशन अपने-आप संभालता है। जब दर्जनों सिस्टम जोड़ने हों, तो यह इंटीग्रेशन का बोझ काफ़ी घटाता है।
3. Observable टूल्स: हर टूल कॉल step level पर पहचान, input, output और time stamp के साथ लॉग होती है। आप देख सकते हैं कि वास्तव में क्या invoke हुआ, पुष्टि कर सकते हैं कि उचित अनुमतियों का पालन हुआ और स्थायी रिकॉर्ड रख सकते हैं।

Quick Start डेमो और Logic Apps

डेमो में आप Thread में संदेश के रूप में एक CSV फ़ाइल अपलोड करते हैं। एजेंट अपने Run Steps में Code Interpreter को कॉल करता है, फ़ाइल प्रोसेस करता है और चार्ट बनाता है। वह artifact संलग्न छवि के रूप में लौटता है और सीधे Thread log में दिखता है। आपने कोई parser या visualization कोड नहीं लिखा। आपने निर्देश दिया, एजेंट ने टूल चुना और निष्पादित किया। यह SDK samples में दस्तावेज़ित व्यवहार है।

टूल्स को Logic Apps से भी जोड़ा जा सकता है, जिससे एजेंट मौजूदा SaaS और on-premises कनेक्टर्स तक पहुँच सकता है। ERP या ITSM प्लेटफ़ॉर्म के लिए adapter दोबारा कोड करने के बजाय आप वही कनेक्टर्स configure करते हैं जो संगठन पहले से चला रहा है।

Microsoft Entra और अनुमतियाँ

SharePoint या Fabric जैसे एंटरप्राइज़ सिस्टम से जुड़ते समय टूल्स Microsoft Entra द्वारा मध्यस्थ authentication का उपयोग करते हैं। यानी जिस फ़ाइल को पढ़ने की अनुमति आपके पास कल नहीं थी, एजेंट आज जादू से उसे नहीं पढ़ पाएगा। पहचान और अनुमतियाँ बरकरार रहती हैं, जो अनुपालन टीमों की मंज़ूरी पाने का एक भरोसेमंद तरीका है। हर कॉल ट्रेस हो सकती है कि किसने invoke की, क्या एक्सेस हुआ और क्या लौटा।

बिना लॉग के जोखिम: आम गलतियाँ और स्टोलपत्थर

अगर Threads, Runs और Run Steps जैसी व्यवस्था न हो, तो एंटरप्राइज़ में ये समस्याएँ सामने आती हैं।

• असंगत आउटपुट: एक बार का सारांश कुछ कहता है, दूसरी बार का उसका खंडन कर देता है।
• ट्रेसेबिलिटी का अभाव: कोई लॉग यह नहीं बताता कि उत्तर कैसे तैयार हुआ, इसलिए डिबगिंग सिर्फ़ अंदाज़ा बनकर रह जाती है।
• भरोसे की कमी: डेवलपर्स तर्क की श्रृंखला दोबारा नहीं देख पाते, और यह उपयोग में विश्वास को चोट पहुँचाता है।
• स्क्रीनशॉट और याद पर निर्भरता: अनुपालन विभाग सबूत माँगे तो आपके पास सिर्फ़ मौखिक वादे बचते हैं।
• सिर्फ़ अंतिम उत्तर देखना: run steps देखे बिना आप नहीं जान सकते कि एजेंट ने API कॉल की, कोड लिखा या सिर्फ़ text बनाया।

Foundry में निर्देश अनिवार्य रूप से पालन किए जाने वाले नियम की तरह काम करते हैं। टूलसेट को उपयोग के मामले के आधार पर सीमित या विस्तारित किया जा सकता है। मॉडल को स्वतंत्र रूप से बदला जा सकता है, पर हमेशा उसी ढाँचे के भीतर जो जवाबदेही तय करता है।

व्यावहारिक takeaways

• एजेंट को तीन हिस्सों से डिज़ाइन करें: मॉडल, निर्देश और टूल्स। तीनों के बिना दोहराव और ऑडिट संभव नहीं।
• मिशन के अनुसार मॉडल चुनें: जटिल तर्क के लिए GPT-4, हल्के कामों के लिए छोटा मॉडल, या Mistral और DeepSeek जैसे विकल्प।
• Threads को स्थायी डायरी मानें। संदेश, फ़ाइलें, कोड ब्लॉक, भूमिका और time stamp सब वहाँ दर्ज रहते हैं।
• Run को ट्रिगर और Run Steps को क्रमवार सबूत की तरह इस्तेमाल करें, चाहे डिबगिंग हो या ऑडिट।
• बिल्ट-इन टूल्स से शुरू करें, फिर ज़रूरत पड़ने पर OpenAPI या MCP से कस्टम टूल जोड़ें।
• मौजूदा SaaS और on-premises सिस्टम के लिए Logic Apps के कनेक्टर्स configure करें, adapter दोबारा कोड करने के बजाय।
• Microsoft Entra authentication पर भरोसा रखें, ताकि पहचान और अनुमतियाँ हर कॉल में बनी रहें।
• पहला कदम: एक टेस्ट प्रोजेक्ट में बेसिक एजेंट बनाएँ, एक Thread चलाएँ और SDK (जैसे .NET) या पोर्टल में Run Steps जाँचें, ताकि पुष्टि हो कि आपके लॉग कहानी से मेल खाते हैं।

निष्कर्ष

Azure AI Foundry का मतलब सिर्फ़ मॉडल पर प्रॉम्प्ट फेंकना नहीं है। यह मस्तिष्क, नियम-पुस्तिका और टूलकिट के साथ एजेंट बनाने का दोहराने योग्य तरीका देता है, और उसकी हर क्रिया Threads, Runs और Run Steps में दर्ज होती है। इससे AI बातचीत का करिश्मा भर नहीं रहता, वह ऐसा सहयोगी बन जाता है जो आदेश मानता है, सही उपकरण इस्तेमाल करता है और पूरा रिकॉर्ड रखता है। टेक लीड्स और अनुपालन टीमों के लिए संदेश साफ़ है: .NET जैसे SDK के साथ आप पूरे जीवनचक्र पर नियंत्रण और दृश्यता रखते हुए दोहराने योग्य और ऑडिट-योग्य निष्पादन पा सकते हैं।