Microsoft Foundry Agent Service का quickstart Python के लिए लिखा गया है। यह Azure के जटिल ढांचे (plumbing) को इतने घने scaffolding के पीछे छिपा देता है कि आप यह जाने बिना ही ट्यूटोरियल पूरा कर सकते हैं कि वास्तव में कौन से रिसोर्स बनाए गए थे। यदि आप .NET पर काम करते हैं, तो आप एक नुकसान के साथ शुरुआत करते हैं: सैंपल गलत दिशा दिखाते हैं, पैकेज के नाम बिना किसी चेतावनी के बदल जाते हैं, और Azure AI Foundry से Microsoft Foundry में हालिया रीब्रांडिंग के कारण सर्च रिजल्ट्स में दस्तावेज़ों (documentation) के दो सेट आपस में प्रतिस्पर्धा कर रहे हैं।

मैंने हाल ही में C# में अपना पहला एजेंट बनाया है। एक बार जब आप शोर (noise) को हटा देते हैं और आवश्यक चरणों को preview-version के भ्रम से अलग कर लेते हैं, तो यह सर्विस अच्छी तरह काम करती है। यहाँ वह मैप है जो मैं चाहता था कि पहले दिन ही मेरे पास होता।

वे चार रिसोर्स जिनकी आपको वास्तव में आवश्यकता है

एक बेसिक Prompt Agent चलाने के लिए आपको दर्जनों Azure सेवाओं की आवश्यकता नहीं है। आपको ठीक चार चीजों की आवश्यकता है, और CLI उन्हें इस तरह से दृश्यमान (visible) बनाता है जैसा कि Python notebooks नहीं बनाते।

पहला, AIServices प्रकार का एक Foundry रिसोर्स। यह उन मॉडल्स के लिए पैरेंट कैपेसिटी (parent capacity) के रूप में कार्य करता है जिन्हें आप कॉल करेंगे। दूसरा, उस रिसोर्स के अंदर एक project। प्रोजेक्ट वह स्कोप है जहाँ आपके एजेंट डेफिनिशन, कन्वर्सेशन थ्रेड्स और डिप्लॉयमेंट सेटिंग्स रहती हैं। तीसरा, एक deployed model। एक सक्रिय डिप्लॉयमेंट के बिना, एजेंट के पास इनवोक (invoke) करने के लिए कोई एंडपॉइंट नहीं होता है। चौथा, आपकी अपनी पहचान के लिए एक role assignment ताकि SDK प्रोजेक्ट के साथ ऑथेंटिकेट (authenticate) कर सके।

बस इतना ही। कोई Kubernetes क्लस्टर नहीं, कोई कस्टम कंप्यूट नहीं, और कन्वर्सेशन हिस्ट्री के लिए कोई मैन्युअल रूप से मैनेज किया गया Redis कैश नहीं।

Prompt Agents बनाम Hosted Agents

Foundry आपको एजेंट चलाने के दो तरीके देता है। डिफ़ॉल्ट रूप से अधिक जटिल विकल्प को न चुनें।

Prompt Agents सरल रास्ता हैं। आप एक मॉडल चुनते हैं, सिस्टम निर्देश (system instructions) लिखते हैं, और Foundry आपके लिए एजेंट चलाता है। आपको कंप्यूट, कंटेनर्स या रूटिंग लॉजिक को मैनेज करने की आवश्यकता नहीं होती है। यह इंटरनल टूल्स, हेल्पडेस्क बॉट्स और दस्तावेज़ों पर सीधे प्रश्न-उत्तर (question-answering) के लिए उपयुक्त है।

Hosted Agents के लिए आपको एप्लिकेशन कोड लिखने, उसे कंटेनर के रूप में पैकेज करने और उसे Foundry से जोड़ने की आवश्यकता होती है। आप इस रास्ते को केवल तभी चुनते हैं जब आपको ऐसे कस्टम बिजनेस लॉजिक की आवश्यकता हो जिसे Foundry प्रॉम्प्ट्स और बिल्ट-इन टूल्स के माध्यम से व्यक्त नहीं कर सकता, जैसे कि नॉन-स्टैंडर्ड ऑथेंटिकेशन के साथ एक इंटरनल API को कॉल करना।

यह गाइड Prompt Agents पर केंद्रित है क्योंकि Docker फाइलों और ऑर्केस्ट्रेशन (orchestration) में निवेश करने से पहले यह जांचने का सबसे तेज़ तरीका है कि आपका .NET सेटअप सही है।

कमांड लाइन से सेटअप करना

CLI का उपयोग करने से आप प्रत्येक रिसोर्स को देखने के लिए मजबूर होते हैं, जो ठीक वही है जिसे Python quickstart छिपा देता है। East US 2 में एक रिसोर्स ग्रुप बनाएं। यहाँ रीजन (region) का चुनाव महत्वपूर्ण है। Foundry टूल सपोर्ट को असमान रूप से रोल आउट करता है, और East US 2 में वर्तमान में सबसे व्यापक सेट उपलब्ध है। यदि आप ऐसा रीजन चुनते हैं जिसमें code interpreter या file search टूल्स की कमी है, तो आपका एजेंट क्रिएशन कॉल unsupported capabilities के बारे में एक अस्पष्ट त्रुटि (opaque error) के साथ विफल हो जाएगा।

--allow-project-management फ्लैग के साथ Foundry रिसोर्स बनाएं। उस फ्लैग के बिना, रिसोर्स एक स्टैंडअलोन कॉग्निटिव सर्विसेज एंडपॉइंट बना रहेगा और उन प्रोजेक्ट-स्कोप वाले डिप्लॉयमेंट को स्वीकार नहीं करेगा जिनकी एजेंटों को आवश्यकता होती है। फिर प्रोजेक्ट बनाएं, अपना मॉडल डिप्लॉय करें, और खुद को Foundry User रोल असाइन करें।

डिस्प्ले नाम के बजाय स्टेबल रोल GUID का उपयोग करें:

53ca6127-db72-4b80-b1b0-d745d6d5456d

टेनेंट (tenant) के आधार पर रोल के नाम Azure Active Directory में अलग-अलग गति से प्रसारित होते हैं। कोई संगठन आज पोर्टल में Foundry User देख सकता है; दूसरा इसे कई दिनों तक नहीं देख पाएगा। GUID सीधे परिभाषा (definition) की ओर इशारा करता है और रोलआउट के दौरान विफल नहीं होगा। यह एक छोटा सा विवरण आपको 'permission-denied' त्रुटियों को डीबग करने में एक घंटा बचा सकता है, जो पॉलिसी की समस्या जैसी लगती हैं लेकिन वास्तव में लेबल-रिजॉल्यूशन (label-resolution) की समस्याएँ होती हैं।

गलत NuGet पैकेज से बचें

यहीं पर .NET डेवलपर्स अक्सर फंस जाते हैं। आप पुराने स्निपेट्स में Azure.AI.Projects.OpenAI के संदर्भ देखेंगे। वह पैकेज केवल preview के लिए है, और यह Azure.AI.Extensions.OpenAI के साथ ओवरलैप करता है। दोनों समान नेमस्पेस (namespaces) में एक्सटेंशन मेथड्स और टाइप्स को परिभाषित करते हैं। यदि आप उन्हें साथ-साथ इंस्टॉल करते हैं, तो आपका बिल्ड ambiguous reference errors के साथ टूट जाएगा जो