deploying-scalable-agents

Microsoft Foundry के साथ स्केलेबल एजेंट्स को डिप्लॉय करना

Lesson 16 – Deploying Scalable Agents के लिए साथ ही कौशल। इसका उपयोग एक शिक्षार्थी को एक एजेंट को प्रोटोटाइप से स्केलेबल, ऑब्ज़र्वेबल प्रोडक्शन डिप्लॉयमेंट में ले जाने में मदद करने के लिए करें। हर सिफारिश को पाठ सामग्री और चलाने योग्य नोटबुक पर आधारित रखें; Foundry APIs का आविष्कार न करें।

ट्रिगर

इस कौशल को सक्रिय करें जब किसी शिक्षार्थी को:

• Microsoft Foundry पर एक एजेंट को होस्टेड एजेंट के रूप में डिप्लॉय करना हो और उसे संस्करणित/ऑब्ज़र्वेबल बनाना हो।
• क्लाइंट-होस्टेड, होस्टेड-एजेंट, और एजेंट-वर्कफ़्लो डिप्लॉयमेंट पैटर्न के बीच चयन करना हो।
• मॉडल राउटिंग, रिस्पॉन्स कैशिंग, या बाउंडेड कंकरेन्सी जोड़ना हो ताकि विलंब और लागत को नियंत्रित किया जा सके।
• एक मूल्यांकन गेट जोड़ना ताकि खराब एजेंट संस्करण शिप न हो सके।
• उच्च जोखिम वाली क्रियाओं के लिए ह्यूमन-इन-द-लूप स्वीकृति चरण जोड़ना।
• प्रोडक्शन ऑब्ज़रवेबिलिटी के लिए एजेंट में OpenTelemetry ट्रेसिंग जोड़ना।
• डिप्लॉय किए गए एजेंट का स्मोक-टेस्ट करना एक तेज पोस्ट-डिप्लॉय गेट के रूप में।

मुख्य मानसिक मॉडल

एक प्रोडक्शन एजेंट ज्यादातर मॉडल के आसपास परिचालन कंकाल होता है (~80%), न कि मॉडल स्वयं। हर सिफारिश को इन चिंताओं में से किसी एक से जोड़ें:

चिंता	प्रोटोटाइप → प्रोडक्शन
होस्टिंग	नोटबुक → संस्करणित होस्टेड सेवा
पहचान	आपका az login → प्रबंधित पहचान + स्कोप्ड RBAC
स्थिति	इन-मेमोरी → बाहरी तंतु/मेमोरी स्टोर
विफलता	ट्रेसबैक → पुनः प्रयास, फॉलबैक, अलर्ट
लागत	"कुछ सेंट" → ट्रैक, रूट, कैश, बजट किया गया
गुणवत्ता	आँखों से देखना → स्वचालित मूल्यांकन गेट
विश्वास	आपकी स्वीकृति → नीति + ह्यूमन-इन-द-लूप

डिप्लॉयमेंट पैटर्न (एक चुनें, या संयोजन करें)

1. क्लाइंट-होस्टेड — तर्क चक्र आपके प्रोसेस में चलता है। अधिकतम नियंत्रण; आप स्केलिंग/स्थिति के मालिक हैं।
2. होस्टेड एजेंट (Foundry एजेंट सेवा) — Foundry चक्र होस्ट करता है, तंतु संग्रहीत करता है, RBAC/सामग्री सुरक्षा लागू करता है, एजेंट को पोर्टल में दिखाता है। कम नियंत्रण, बहुत कम परिचालन क्षेत्र।
3. एजेंट वर्कफ़्लो — कई एजेंट/उपकरण एक ग्राफ में संयोजित, शाखा बनाना, अनुमोदन नोड, और टिकाऊ चेकपॉइंट के साथ।

जीवनचक्र (एजेंट को भेजने वाला चक्र)

create → version → evaluate (gate) → deploy hosted → observe online → collect failures → repeat. ऑफ़लाइन मूल्यांकन एक गेट है, सोच-समझ कर नहीं — एक संस्करण तब तक शिप नहीं होता जब तक वह सीमा को पार न कर ले। ऑनलाइन ऑब्ज़रवेबिलिटी वास्तविक विफलताओं को वापस ऑफ़लाइन परीक्षण सेट में फ़ीड करता है।

स्केलिंग और लागत नियंत्रण (प्राथमिकता के अनुसार)

1. मॉडल को उचित आकार दें — सबसे छोटा मॉडल उपयोग करें जो मूल्यांकन गेट पास करता हो।
2. जटिलता के अनुसार मार्गदर्शन करें — सरल अनुरोधों के लिए छोटा/तेज़ मॉडल, वास्तविक तर्क के लिए बड़ा मॉडल (DIY वर्गीकर्ता या Foundry मॉडल राउटर)।
3. कैश करें — लगभग समान अनुरोधों को बिना मॉडल कॉल के पूरा करें।
4. स्टेटलेस डिज़ाइन + सीमित समवर्तीता — स्थिति बाहरी करें; पुनः प्रयास के साथ बैकऑफ़ लगाएं।

प्रमुख पैटर्न पुनरुत्पादित करने के लिए

शिक्षार्थी को नोटबुक से इनकी ओर निर्देशित करें: 16-python-agent-framework.ipynb:

• अनुरोध हैंडलर: कैश → जटिलता के अनुसार मार्गदर्शन → ट्रेस स्पैन → चलाएँ → कैश।
• मूल्यांकन गेट: एक ऑफ़लाइन परीक्षण सेट का स्कोर करें; pass_rate >= threshold लौटाएं और केवल सत्य होने पर डिप्लॉय करें।
• मानव स्वीकृति: जैसे बड़े रिफंड के लिए @tool(approval_mode="always_require")।
• ट्रेसिंग: हर अनुरोध को tracer.start_as_current_span(...) में लपेटें और routed.model, customer.id जैसे गुण सेट करें।

डिप्लॉय किए गए एजेंट का स्मोक-टेस्ट

डिप्लॉय के बाद, सत्यापित करें कि एंडपॉइंट वास्तव में जवाब देता है (एक हरा डिप्लॉय अभी भी निष्क्रिय हो सकता है)। AI स्मोक टेस्ट का उपयोग करें .github/workflows/smoke-test.yml के माध्यम से और tests/ में कैटलॉग के साथ। रनर प्रत्येक प्रॉम्प्ट को POST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responses पर POST करता है और उत्तर पाठ पर पुष्टि करता है। पहचान को Foundry परियोजना स्कोप पर Azure AI User भूमिका चाहिए; टोकन ऑडियंस https://ai.azure.com/ होना चाहिए।

मूल्यांकन** (प्रमोशन से पहले शिप करने के लिए पर्याप्त अच्छा) → ऑनलाइन मूल्यांकन (वह जंगली में कैसा कर रहा है, लगातार)।

• प्रोडक्शन में MCP: हर MCP सर्वर को अविश्वसनीय सीमा के रूप में देखें — संस्करण पिन करें, उसकी पहचान सीमित करें, आउटपुट सत्यापित करें, दर सीमा लगाएं, कभी सीक्रेट्स प्रकट न करें।

• पूरे पाठ्यक्रम में उपयोग किए गए कैनोनिकल FoundryChatClient(...) + provider.as_agent(...) पैटर्न को प्राथमिकता दें।

• जिन लाइव-Azure परिणामों की आपने पुष्टि नहीं की है, उनका वादा न करें; तैनाती की पुष्टि करने के लिए स्मोक-टेस्ट वर्कफ़्लो की सिफारिश करें।

• मूल्यांकन और लागत सलाह को एक साथ रखें: मूल्यांकन गुणवत्ता का आधार निर्धारित करता है, रूटिंग/कैशिंग लागत को उस आधार के करीब रखती है।

---

<!-- CO-OP TRANSLATOR DISCLAIMER START --> अस्वीकरण: इस दस्तावेज़ का अनुवाद AI अनुवाद सेवा Co-op Translator का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं। <!-- CO-OP TRANSLATOR DISCLAIMER END -->