Tools के साथ prompt agent बनाएँ

Prompt agent वह agent है जिसे आप अपना server code चलाए बिना सेटिंग्स से बनाते हैं। Foundry Agent Service में यह Foundry model catalog का model, लिखे हुए instructions, optional tools, और user के natural language prompts एक साथ जोड़ता है। Model अब भी text लिखता है, लेकिन tools से वह आपके data से तथ्य निकाल सकता है या वे काम कर सकता है जो आपका application करता है।

अवधारणा 6 में file search और Azure AI Search से अपने दस्तावेज़ों पर आधारित जवाब देखा। यह अवधारणा आगे का हिस्सा जोड़ती है: काम के हिसाब से tools जोड़ना, model कब tool कॉल करे यह नियंत्रित करना, परीक्षण योग्य versions सहेजना, और हर turn का व्यवहार जाँचना। Prompt agent Microsoft Foundry portal में या SDK / REST API से बना और update किया जा सकता है। Hosted agent में आप container में अपना code deploy करते हैं; prompt agent में service वही model और tools चलाती है जो आपने configure किए।

Agent बनाने से पहले Foundry project में एक model deploy होना चाहिए। Microsoft Foundry portal की welcome screen से project endpoint कॉपी करें। यह https://<resource-name>.services.ai.azure.com/api/projects/<project-name> जैसा दिखता है और code से project तक पहुँचने के लिए इस्तेमाल होता है।

• Agent के लिए नाम चुनें। Portal में नाम देने के बाद उसे बदला नहीं जा सकता। Code में versions बनने के बाद agent को name और version से पहचानते हैं।
• Model deployment और instructions सेट करें — tone, scope, और कौन-सा tool कब इस्तेमाल हो।
• Agent बनाएँ (उदाहरण: SDK में create_version)। Service id, name, और version number लौटाती है।
• Conversation खोलें, user input भेजें, agent का जवाब पढ़ें। Multi-turn chat में एक ही conversation में history रहती है, इसलिए follow-up पहले के संदर्भ का इस्तेमाल कर सकते हैं।
• ज़रूरत बदलने पर agent update या delete कर सकते हैं; हर सहेजी गई configuration milestone नई version बननी चाहिए, पुरानी overwrite नहीं।
• SDK samples locally चलाते समय पहले Azure CLI से साइन इन करें (az login) ताकि DefaultAzureCredential आपके project में authenticate कर सके।

Prompt-agent quickstart भी यही flow दिखाता है: model और instructions के साथ agent बनाना, उस agent से OpenAI client जोड़ना, conversation बनाना, और पहले सवाल व उसी conversation में follow-up के लिए responses.create कॉल करना।

Tools agent को model के training data से आगे ले जाते हैं। सिर्फ़ वही tools जोड़ें जो scenario में चाहिए। हर tool के साथ नया व्यवहार, latency, और देखनी लागत जुड़ती है। Agent instructions में बताएँ हर tool किस लिए है और कब उसे चुनना है। अगर दो tools overlap करें तो साधा नियम लिखें (उदाहरण: custom API से पहले upload की policies के लिए file search)। Tool fail हो या खाली result आए तो agent को अनुमान न लगाकर समस्या बताकर स्पष्ट सवाल पूछने को कहें।

• File search और Azure AI Search आपके नियंत्रण वाले दस्तावेज़ों से text निकालते हैं। तब इस्तेमाल करें जब जवाब general knowledge नहीं, आपकी सामग्री पर आधारित हो।
• Code interpreter sandbox में Python चलाता है ताकि agent files का विश्लेषण, math, और charts बना सके।
• Function calling से model आपके application में function चलाने को कह सकता है, फिर परिणाम के साथ बातचीत जारी रखता है।
• Tool के साथ agent सहेजने से पहले tool पूरी तरह configure हो (connections, authentication, या ज़रूरी uploaded files)। Configure किया tool दूसरे agents पर भी लगाया जा सकता है।

Function calling SDK या REST API में एक दोहराने वाला pattern follow करता है। पहले हर function tool (name, parameters, उद्देश्य) describe करें और agent पर register करें। User prompt भेजने पर model final text की जगह function_call item लौटा सकता है। आपका application matching function चलाता है, फिर उसी call id के साथ function_call_output भेजता है। Agent उस output से natural language में जवाब पूरा करता है।

• Function tools सही parameter schema और descriptions के साथ define करें।
• Agent बनाएँ या update करें ताकि वे tools attached हों।
• User message responses.create से भेजें (चाहें तो conversation id के साथ)।
• अगर response output में function_call items हों तो अपना code चलाएँ और परिणाम इकट्ठा करें।
• function_call_output items के साथ फिर responses.create कॉल करें ताकि model अंतिम जवाब दे सके।

Run बनने के दस मिनट बाद expire हो जाता है। Expire होने से पहले tool outputs submit करें। Function tools वाले agents Microsoft Foundry portal में चला सकते हैं, लेकिन portal agent पर function definitions जोड़ने, हटाने या update करने का support नहीं करता; function tools SDK या REST API से configure करें। Tool arguments और tool outputs को untrusted input मानें, side effects से पहले values जाँचें, और secrets tool output में न लौटाएँ। Code interpreter model tokens के अलावा अलग session charges लेता है; हर active conversation अपना session बना सकती है — session lifetime और idle limits Code Interpreter documentation में दिए हैं।

tool_choice setting यह तय करती है कि model किसी turn पर tools कितनी निश्चित रूप से इस्तेमाल करे। इसे जान-बूझकर सेट करें, खासकर opening turns या ऐसे पल जहाँ tool चलना या न चलना user को जवाब सुनने या देखने से पहले ज़रूरी है।

• none तब जब agent सिर्फ़ instructions से जवाब दे (उदाहरण: छोटा greeting)।
• auto ज़्यादातर flexible chat के लिए जहाँ model ज़रूरत पड़ने पर tool चुनता है।
• required तब जब किसी turn में जवाब पूरा होने से पहले tool चलना ज़रूरी हो।
• अगर agent expected tool skip करे तो जाँचें tool attached है, model और region support करते हैं, और traces में tool call बना या नहीं।

Prompt-based agent का हर सहेजा गया version अपरिवर्तनीय होता है। Configuration बदलने के लिए नया version सहेजें और पुराने रखें ताकि setup, chat output, या definition की तुलना कर सकें और ज़रूरत हो तो rollback कर सकें। Agent playground में unsaved बदलाव आज़मा सकते हैं, लेकिन portal छोड़ने पर unsaved काम खो जाता है, और पूरी conversation history, monitoring, evaluations के लिए saved version चाहिए।

• Tool या instructions में बड़े बदलाव के बाद draft पर भरोसा न करके version सहेजें।
• Tracing (preview) से जाँचें कौन-से tools चले, input / output देखें, model और tool steps पर latency पहचानें।
• यह मानकर न चलें कि portal ने function tools configure कर दिए; function calling SDK या REST tests में verify करें।
• Conversation पूरा हो सके इसलिए दस मिनट के run window के अंदर function outputs लौटाएँ।
• Model deployment और region को tool support से मिलाएँ; model या region में से किसी एक में support न हो तो tool fail हो सकता है।

Structured inputs (instructions या tool resources में handlebar placeholders) से कुछ tool settings runtime पर बदल सकते हैं, ताकि हर variant के लिए नया version बनाए बिना एक agent version अलग file lists या instruction text serve करे। Secrets structured input values के रूप में न भेजें — logs या traces में capture हो सकते हैं।

कल्पना करें ऑनलाइन shop के लिए support assistant। Instructions कहती हैं refund से पहले return policy text देखो, order id मिले तभी order lookup करो, shipping dates अनुमान से मत बताओ। Upload policy PDFs पर file search, order database के खिलाफ get_order_status function tool (आपका app implement करे), और ज़रूरत हो तो line items spreadsheet के लिए code interpreter। Playground में version 1 सहेजें, ज्ञात policy सवालों से citations देखें, फिर order 88231 पूछें और tracing से पुष्टि करें get_order_status expected arguments के साथ चला, उसके बाद विनम्र summary आया। व्यवहार स्थिर हो तो अवधारणा 8 कुछ manual chats पर अनुमान न लगाकर evaluations से quality measure और improve करने की बात करती है।

• पहला prompt agent और multi-turn chat के लिए चरण-दर-चरण setup। Quickstart: Create a prompt agent
• Function tools define करना, function_call output handle करना, और दस मिनट की run limit troubleshoot करना। Use function calling with Microsoft Foundry agents
• Sandboxed Python, session charges, और analysis / charts के लिए file upload patterns। Code Interpreter tool for Microsoft Foundry agents
• Instructions, tool_choice, सुरक्षा practices, और regional support checks। Tool best practices for Microsoft Foundry Agent Service