# aiagentdevelopment.info — पूरा पाठ

> इस भाषा की हर गाइड का पूरा पाठ, ताकि कोई उत्तर-इंजन एक ही अनुरोध में पूरा कैटलॉग पढ़ सके। यहाँ ऐसा कुछ नहीं जो दिखने वाले पेजों पर न हो।

## ऐसा एजेंट विकास रोडमैप जो सचमुच प्रोडक्शन तक पहुँचे
https://aiagentdevelopment.info/hi/guides/agent-vikas-roadmap
2026-08-05 को अपडेट · लागत और बिज़नेस

- लिखित निकास-परीक्षाओं वाले चार चरण: दायरा, प्रोटोटाइप, मज़बूती, लॉन्च।
- मज़बूती सबसे लंबा और सबसे कम बजट वाला चरण है।
- सीमित लॉन्च कीजिए और कैलेंडर नहीं, आँकड़ों पर बढ़ाइए।
- लॉन्च के बाद यह सेवा है: मालिक, बढ़ता मूल्यांकन, पुनः-योग्यता।

एजेंट प्रोजेक्टों की विफलता का ढर्रा तकनीकी नहीं है। तीसरे सप्ताह में अच्छा प्रोटोटाइप, फिर तीन महीने बिना दिशा सुधार, फिर चुपचाप रद्द — क्योंकि कोई नहीं कह सका कि यह तैयार है या नहीं।

यह रोडमैप इसे निकास-परीक्षाओं से ठीक करता है। हर चरण की एक शर्त होती है जो चरण शुरू होने से पहले लिखी जाती है और या तो पूरी होती है या नहीं। कोई चरण अपनी परीक्षा पास न करे तो या तो ठोस कमी ठीक कीजिए या रुक जाइए।

### चरण 1 — दायरा (1–2 सप्ताह)
काम को ऐसे वाक्य में लिखिए जिसे समीक्षक सही या ग़लत कह सके। टूल और उनके आर्ग्युमेंट स्कीमा सूचीबद्ध कीजिए। तय कीजिए कौन-सी कार्रवाइयाँ अपरिवर्तनीय हैं और इंसान के पीछे रहेंगी। बीस असली उदाहरण जुटाइए।
निकास-परीक्षा: जो सहकर्मी बैठकों में नहीं थी, वह brief पढ़कर पाँच उदाहरण रन सही अंकित कर सके।

### चरण 2 — प्रोटोटाइप (2–3 सप्ताह)
सबसे छोटा लूप बनाइए जो टेस्ट परिवेश के असली टूल से काम करे। हो सके तो अभी framework का फ़ैसला नहीं; हाथ से लिखा लूप सिखाता है कि असल में क्या चाहिए। अपने बीस मामले चलाइए और prompt से पहले टूल डिज़ाइन ठीक कीजिए।
निकास-परीक्षा: बीस में से 60% अंत-से-अंत पास हों और हर विफलता के आगे पहचाना गया कारण लिखा हो।

### चरण 3 — मज़बूती (3–5 सप्ताह)
असली काम का अधिकांश यहीं है और कम-बजट प्रोजेक्ट यहीं मरते हैं। अंतिम उपयोगकर्ता पहचान पर अनुमतियाँ, अपरिवर्तनीय पर दरवाज़े, आर्ग्युमेंट जाँच, पढ़ी जा सकने वाली ट्रेस, कुछ व्यवहार मीट्रिक वाली निगरानी, पचास मामलों तक बढ़ा मूल्यांकन सेट और गिरावट मोड।
- हर टूल कॉल पर सर्वर की ओर अनुमति जाँच।
- हर अपरिवर्तनीय कार्रवाई के आगे निर्णय-तैयार संदर्भ वाला इंसानी दरवाज़ा।
- कदम और ख़र्च सीमाएँ, साथ में दोहराव पहचान।
- हर कॉल पर रन पहचानकर्ता वाली ट्रेस और जान-बूझकर तय अवधारण।
- मूल्यांकन सेट में विरोधी मामले, किसी और टेस्ट की तरह चलाए गए।
निकास-परीक्षा: मूल्यांकन सेट पर 85%, मना-करने वाले उपसमूह पर 100% और कोई खुला सुरक्षा निष्कर्ष नहीं।

### चरण 4 — लॉन्च (2 सप्ताह, फिर लगातार)
सीमित दर्शकों से शुरू कीजिए — एक टीम, एक ग्राहक वर्ग या ट्रैफ़िक का एक प्रतिशत। रोज़ रन पढ़िए। एस्केलेशन रास्ता दिखता और स्टाफ़ वाला रखिए। जब आँकड़े लगातार दो हफ़्ते टिकें तब बढ़ाइए, कैलेंडर देखकर नहीं।
| 1 | केवल आंतरिक टीम | ट्रेस, स्पष्ट विफलताएँ, टूल त्रुटियाँ |
| 2 | असली ट्रैफ़िक का 5% | एस्केलेशन दर, सफलता दर |
| 3–4 | 25% | प्रति कार्य लागत, व्यस्त समय विलंब |
| 5+ | आँकड़े टिकें तो पूरा | बहाव, नई श्रेणियाँ |

### लॉन्च के बाद क्या होता है
एजेंट सेवा है, प्रोजेक्ट नहीं। कोई उसका मालिक होता है, मूल्यांकन सेट असली ट्रैफ़िक से बढ़ता है, प्रोवाइडर के हटाने पर मॉडल संस्करण पुनः-योग्य होते हैं, और सबूत जमा होते ही इंसानी दरवाज़े चुनकर हटाए जाते हैं।

Q: तीन दिन में चले डेमो के लिए बारह सप्ताह लंबे लगते हैं।
A: डेमो सचमुच चला। बाक़ी नौ सप्ताह अनुमतियाँ, मूल्यांकन, निगरानी और विफलता-रास्ते हैं। इन्हें छोड़ना काम हटाता नहीं, घटना के बाद खिसका देता है।

Q: क्या चरण एक-दूसरे पर चढ़ सकते हैं?
A: मज़बूती प्रोटोटाइप के दौरान शुरू हो सकती है, और अनुमतियों के लिए होनी चाहिए। मज़बूती परीक्षा पास हुए बिना लॉन्च शुरू मत कीजिए।

Q: अगर प्रोटोटाइप परीक्षा में फ़ेल हो?
A: लिखे कारण देखिए। टूल डिज़ाइन और डेटा पहुँच हो तो ठीक कीजिए। काम ऐसा विवेक माँगे जिसे कोई परिभाषित न कर सके तो रुक जाइए।

## उद्योग के हिसाब से AI एजेंट उपयोग: जो सचमुच चल रहा है
https://aiagentdevelopment.info/hi/guides/udyog-ke-hisab-se-upyog
2026-08-05 को अपडेट · लागत और बिज़नेस

- एजेंट वहाँ टिकते हैं जहाँ काम संकीर्ण है, रिकॉर्ड सिस्टम है और जोखिम वाला कदम सुरक्षित है।
- आंतरिक मिलान, छँटाई और मसौदा सबसे भरोसेमंद पहली जीतें हैं।
- प्रोजेक्ट API, परिभाषा या मालिक की कमी से अटकते हैं, मॉडल की सीमा से नहीं।
- नियमन वाले क्षेत्रों में मसौदे से शुरू कीजिए और सबूत के साथ स्वायत्तता बढ़ाइए।

उपयोग-सूचियाँ अक्सर इच्छा-सूची जैसी पढ़ी जाती हैं। यह सूची उससे बनी है जो प्रोडक्शन तक पहुँचता और वहाँ टिकता है — मार्केटिंग के सुझाव से बहुत छोटी और ज़्यादा दोहराव वाली सूची।

पैटर्न क्षेत्रों में एक-सा है। पूरा-होने की स्पष्ट परिभाषा वाला संकीर्ण काम, असली रिकॉर्ड सिस्टम पर दो-तीन टूल, और जो पलट न सके उसके आगे एक इंसान।

### क्षेत्र के हिसाब से क्या चलता है
| ई-कॉमर्स | ऑर्डर स्थिति, वापसी पात्रता, पता बदलना | ऑर्डर खोज, नीति, पता अपडेट | सीमा से ऊपर रिफ़ंड |
| SaaS सपोर्ट | खाता संदर्भ के साथ पहले स्तर की छँटाई | खाता खोज, दस्तावेज़, टिकट | प्लान बदलाव, क्रेडिट |
| वित्त संचालन | चालान और क्रय आदेश मिलाना | ERP पठन, दस्तावेज़ पार्स, चिह्न | हर भुगतान |
| स्वास्थ्य प्रशासन | अपॉइंटमेंट और रिमाइंडर | कैलेंडर, रोगी रिकॉर्ड पठन | हर नैदानिक बात |
| भर्ती | स्पष्ट मानदंडों पर छँटाई, समय तय करना | ATS पठन, कैलेंडर, ईमेल मसौदा | अस्वीकृति और प्रस्ताव |
| लॉजिस्टिक्स | देरी पर अपवाद प्रबंधन | ट्रैकिंग, कैरियर API, सूचना | मुआवज़ा प्रस्ताव |

### वे आंतरिक एजेंट जिन पर कोई नहीं लिखता
सबसे भरोसेमंद जीतें बेरौनक़ और आंतरिक हैं: दो असहमत सिस्टम मिलाना, दोहराई जाने वाली रिपोर्ट का पहला मसौदा लिखना, आने वाले अनुरोध सही क़तार में सही संदर्भ के साथ भेजना, और नीति के सवालों का स्रोत सहित जवाब देना। ये चलते हैं क्योंकि पूरा-होने की परिभाषा साफ़ है और ग़लतियाँ सस्ती व दिखने वाली हैं।

### हर क्षेत्र में प्रोजेक्ट कहाँ अटकते हैं
- API वाला रिकॉर्ड सिस्टम नहीं — एजेंट के पैरों के नीचे ठोस ज़मीन नहीं।
- सही नतीजे की साझा परिभाषा नहीं, इसलिए कोई अंक नहीं दे सकता।
- विवेक-भारी काम और शून्य जोखिम-भूख: सब कुछ दरवाज़े से गुज़रता है और मूल्य ग़ायब।
- स्वामित्व अस्पष्ट: बनाया नवाचार ने, ज़रूरत संचालन को, ऑन-कॉल कोई नहीं।

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

### नियमन वाले क्षेत्र: धीमे, बंद नहीं
वित्त, स्वास्थ्य और सार्वजनिक क्षेत्र एजेंट चला सकते हैं; बस वे मसौदे की ओर से शुरू करते हैं। जो एजेंट मामला जोड़े, स्रोत दे और इंसान को निर्णय-तैयार सारांश सौंपे, वह स्वचालित निर्णय के जोखिम बिना अधिकांश समय बचाता है।

Q: किस क्षेत्र में सबसे साफ़ जीतें हैं?
A: ई-कॉमर्स और SaaS सपोर्ट, क्योंकि काम उच्च हैसियत के हैं, सिस्टम की API ठीक हैं और अधिकतर कार्रवाइयाँ पलटने योग्य हैं।

Q: क्या छोटे कारोबार के लिए उपयोगी हैं?
A: हाँ, आमतौर पर आंतरिक रूप में: छँटाई, मसौदा, मिलान। बाधा वही है: डेटा केवल शीट और इनबॉक्स में हो तो पहले पहुँच ठीक कीजिए।

Q: बनाने से पहले मूल्य कैसे आँकें?
A: हैसियत गिनिए, आज इंसान का समय मापिए और वह हिस्सा आँकिए जो एजेंट बिना मदद पूरा करेगा। उस हिस्से में रूढ़िवादी रहिए।

## ख़ुद को धोखा दिए बिना AI एजेंट का ROI मापना
https://aiagentdevelopment.info/hi/guides/agent-roi-mapna
2026-08-05 को अपडेट · लागत और बिज़नेस

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

एजेंट के अधिकांश ROI आँकड़े ध्यान से पढ़ने पर नहीं टिकते, और कारण लगभग हमेशा वही है: आधार बाद में बनाया गया और ग़लतियाँ हिसाब से बाहर रहीं।

ईमानदार आँकड़ा पाना कठिन नहीं, पर यह लॉन्च से पहले शुरू होना चाहिए। लिखिए कि आज क्या ख़र्च होता है, उन्हीं इकाइयों में जिनका बाद में उपयोग करेंगे। बाक़ी सब इसी एक अनुशासन से निकलता है।

### पहले आधार लिखिए
- हैसियत: यह काम हफ़्ते में कितनी बार होता है?
- निपटान समय: इंसान को कितना लगता है — याद से नहीं, नमूने से मापा गया?
- करने वालों की पूरी लागत प्रति घंटा।
- आज की गुणवत्ता: त्रुटि या दोबारा-काम की दर, क्योंकि तुलना इसी से होगी।
- प्रतीक्षा समय: माँगने वाला आज कितना इंतज़ार करता है, अगर यह मायने रखता है।
बाद में बनाया आधार हमेशा प्रोजेक्ट के पक्ष में झुकता है, और समीक्षक यह जानते हैं।

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

### सूत्र और वह हिस्सा जो लोग छोड़ देते हैं
वार्षिक लाभ = बिना इंसान पूरे कार्य × प्रति कार्य बचे मिनट × प्रति मिनट पूरी लागत — घटा एजेंट से हुई ग़लतियों की लागत, घटा उसने जो समीक्षा समय बनाया। यही घटाव ईमानदार हिस्सा है। जो एजेंट 70% पूरा करे पर हर आउटपुट जँचवाए, उसने निपटान नहीं, समीक्षा समय बचाया है।
ग़लती की लागत मोटे तौर पर भी स्पष्ट आँकिए: सुधार का समय, सद्भावना और दिए गए क्रेडिट।

### असली पर बिल में न दिखने वाले लाभ
कुछ मूल्य लागत मॉडल में कभी नहीं दिखता। रात तीन बजे तेज़ जवाब। संगति — कौन ड्यूटी पर है इससे स्वतंत्र वही जवाब। यह लिखित निशान कि कुछ क्यों तय हुआ, जो नियमन वाले परिवेश में बहुत क़ीमती है। इन्हें गढ़ी हुई मुद्रा में बदलने के बजाय अलग और ईमानदारी से बताइए।

### जब ईमानदार जवाब ना है
कभी-कभी गणित रुकने को कहता है, और यही कहना इस अभ्यास का सबसे मूल्यवान काम है। कम हैसियत वाले काम शायद ही निर्माण की भरपाई करते हैं। जिन कामों का आउटपुट वैसे भी जाँचना है, वे केवल समीक्षा बचाते हैं। और जहाँ ग़लतियाँ महँगी हैं, वहाँ ऊँची सटीकता पर भी रिटर्न ऋणात्मक हो सकता है।

Q: पहले एजेंट के लिए यथार्थवादी पूर्णता दर?
A: अच्छी तरह दायरा तय, उच्च हैसियत वाले काम का साठ से अस्सी प्रतिशत, बाक़ी एस्केलेट। आपका डेटा देखे बिना पंचानबे का वादा बेंचमार्क बता रहा है।

Q: भरपाई में कितना समय?
A: अच्छी तरह चुने आंतरिक काम पर, रखरखाव सहित आमतौर पर छह से बारह महीने। मॉडल छह हफ़्ते दिखाए तो जाँचिए कि ग़लती लागत और समीक्षा समय शामिल हैं या नहीं।

Q: अगर एजेंट केवल मसौदा लिखे तो मूल्य कैसे गिनें?
A: ख़ाली पन्ने से मंज़ूर आउटपुट तक का समय पहले और बाद में मापिए। मसौदा लिखने वाले एजेंट जोखिम के छोटे हिस्से में अधिकांश बचत देते हैं।

## AI एजेंट डेवलपर रखना: क्या देखें और कैसे परखें
https://aiagentdevelopment.info/hi/guides/agent-developer-hiring
2026-08-05 को अपडेट · लागत और बिज़नेस

- Prompt विशेषज्ञ नहीं, विफलता-रूपों में सोचने वाले सिस्टम इंजीनियर रखिए।
- एक brief से छाँटिए: स्कीमा, रुकने की शर्तें, दस मामले, इंसानी दरवाज़े।
- Framework ज्ञान सफलता का सबसे कमज़ोर संकेत है।
- हर आपूर्तिकर्ता से prompts, स्कीमा, मूल्यांकन और ट्रेस की सुपुर्दगी माँगिए।

पदनाम नया है, कौशल नहीं। जो लोग प्रोडक्शन में टिकने वाले एजेंट बनाते हैं, वे सामान्य मज़बूत इंजीनियर हैं जिन्होंने ऐसे घटक के साथ काम करना सीखा है जो तेज़, सक्षम और कभी-कभी आत्मविश्वास से ग़लत होता है।

यह नज़रिया भर्ती को बहुत आसान कर देता है। आप prompt विशेषज्ञ नहीं ढूँढ रहे। आप ऐसा व्यक्ति ढूँढ रहे हैं जो सहज रूप से पूछे कि टूल कुछ न लौटाए तो क्या होगा।

### क्या मायने रखता है, क्रम में
- API और इंटीग्रेशन इंजीनियरिंग: अधिकांश काम आपके सिस्टम से ठीक बात करना है।
- टेस्ट की प्रवृत्ति: मॉडल से पहले मूल्यांकन पूछते हैं।
- विफलता-रूपों में सोच: ख़ाली नतीजे, अनुमतियाँ, समय-समाप्ति, आंशिक सफलता।
- सुरक्षा चेतना: न्यूनतम विशेषाधिकार, injection, ऑडिट, दरवाज़े।
- लागत चेतना: बिना देखे बता सकते हैं टोकन कहाँ जाते हैं।
- मॉडल से परिचय: उपयोगी, हफ़्तों में सीखा जा सकता है।
- Framework ज्ञान: सबसे कम ज़रूरी और सबसे ज़्यादा विज्ञापित।

### नब्बे मिनट का कारगर अभ्यास
एक छोटा brief दीजिए: ऐसा एजेंट जो ऑर्डर के सवाल सँभाले और पाँच हज़ार रुपये से कम पर रिफ़ंड कर सके। स्कीमा सहित टूल सूची, रुकने की शर्तें, दस मूल्यांकन मामले और इंसानी दरवाज़े के पीछे क्या रहेगा — यह माँगिए। आप कोड नहीं देख रहे। आप देख रहे हैं कि `refund_order(order_id)` परिभाषित होता है या `update_order(order_id, fields)`।
मज़बूत उम्मीदवार पहले पाँच मिनट में अनुमतियों और किनारे के मामलों पर सवाल पूछते हैं। यही पूरी प्रक्रिया का सबसे भरोसेमंद संकेत है।

### अनुभव को उत्साह से अलग करने वाले सवाल
| बदलाव से फ़ायदा हुआ, कैसे जानेंगे? | हाथ से जाँचते हैं | तय मूल्यांकन सेट, पहले और बाद |
| टूल कुछ न लौटाए तो? | फिर कोशिश | स्पष्ट ख़ाली नतीजा जिस पर एजेंट अमल कर सके |
| Injection कैसे रोकेंगे? | मॉडल से कहेंगे अनदेखा करे | न्यूनतम विशेषाधिकार, पृथक्करण, दरवाज़े |
| पिछला एजेंट धीमा क्यों था? | मॉडल धीमा था | छह क्रमिक कॉल; दो समानांतर कीं, संदर्भ काटा |
| मॉडल कैसे चुनते हैं? | सबसे अच्छा | कदम के हिसाब से, अपने मामलों पर मापकर |

### एजेंसी, फ़्रीलांसर या इन-हाउस
एजेंसी समय-सीमा वाले पहले निर्माण के लिए ठीक है: आप ऐसी टीम ख़रीदते हैं जो सामान्य ग़लतियाँ कर चुकी है — और आपको मूल्यांकन सेट व टूल स्कीमा की सुपुर्दगी शर्त रखनी चाहिए। इन-हाउस तब सही है जब एजेंट उत्पाद का हिस्सा बने। आम विफलता है बिना हस्तांतरण की एजेंसी परियोजना।

### दोनों ओर के ख़तरे के संकेत
- मूल्यांकन मद के बिना प्रस्ताव।
- आपका डेटा देखे बिना सटीकता पर आत्मविश्वास।
- टूल सूची लिखे बिना framework सिफ़ारिश।
- अनुमतियों या अंतिम उपयोगकर्ता पर कोई सवाल नहीं।
- अंत में prompts, स्कीमा और मामले सौंपने में हिचक।

Q: क्या ML इंजीनियर चाहिए?
A: आमतौर पर नहीं। यह काम मॉडल API के विरुद्ध सिस्टम इंजीनियरिंग है। ML विशेषज्ञता फ़ाइन-ट्यूनिंग या गंभीर retrieval अनुकूलन में चाहिए।

Q: टीम कितनी बड़ी हो?
A: दो इंजीनियर और अंशकालिक क्षेत्र-विशेषज्ञ अधिकतर पहले प्रोजेक्ट के लिए काफ़ी हैं। विशेषज्ञ वैकल्पिक नहीं — वे मूल्यांकन मामले देते हैं।

Q: एजेंसी क्या सौंपे?
A: रिपॉज़िटरी, prompts, टूल स्कीमा, नतीजों सहित मूल्यांकन सेट, पिछले महीने की ट्रेस, निगरानी डैशबोर्ड और ज्ञात विफलताओं का नोट।

## AI एजेंट विकास लागत: असली आँकड़े और उनके कारण
https://aiagentdevelopment.info/hi/guides/agent-vikas-lagat
2026-08-05 को अपडेट · लागत और बिज़नेस

- आंतरिक एजेंट आमतौर पर $8k–$45k; ग्राहक-सामना $35k–$150k।
- घंटों में इंटीग्रेशन, मूल्यांकन और अनुमतियाँ हावी — prompt सबसे छोटी मद।
- चलाने की लागत सामान्यतः मामूली है और नियमित काम से आधी हो जाती है।
- रखरखाव के लिए सालाना निर्माण लागत का 15–25% रखिए और मालिक तय कीजिए।

कोई भी वेब पेज से आपके प्रोजेक्ट का दाम नहीं बता सकता, पर दायरे रहस्य भी नहीं हैं, और अनुमान का ढाँचा हमारे किए और देखे प्रोजेक्टों में उल्लेखनीय रूप से एक जैसा रहा है।

तीन आँकड़े चाहिए: बनाना, चलाना, बनाए रखना। टीमें पहले पर कड़ी मोलभाव करती हैं, दूसरे की चिंता करती हैं और तीसरा पूरी तरह भूल जाती हैं — इसीलिए इतने एजेंट लॉन्च के आठ महीने बाद चुपचाप टूटे मिलते हैं।

### दायरे के हिसाब से निर्माण लागत
| आंतरिक सहायक, 2–3 केवल-पढ़ने टूल | $8,000–$20,000 | लूप, टूल, retrieval, छोटा eval सेट |
| लिखने की अनुमति वाला आंतरिक एजेंट | $20,000–$45,000 | ऊपर के साथ अनुमतियाँ, ऑडिट, मंज़ूरी दरवाज़े |
| ग्राहक-सामना सपोर्ट एजेंट | $35,000–$90,000 | ऊपर के साथ एस्केलेशन, लहजा, निगरानी, लोड |
| उत्पाद के भीतर एजेंट | $60,000–$150,000+ | ऊपर के साथ UI, बहु-किरायेदारी, SLA, संस्करण |
| केवल अवधारणा प्रमाण | $5,000–$12,000 | एक रास्ता, अनुमति नहीं, भेजने लायक नहीं |

### घंटे असल में कहाँ जाते हैं
वितरण उन्हें चौंकाता है जो मॉडल को ही प्रोजेक्ट मानते हैं। मोटे तौर पर: इंटीग्रेशन और टूल परत 30%, मूल्यांकन और पुनरावृत्ति 20%, अनुमतियाँ-ऑडिट-सुरक्षा 15%, निगरानी और संचालन उपकरण 10%, prompt और retrieval 15%, और एजेंट लूप स्वयं लगभग 10%। Prompt इंजीनियरिंग सबसे छोटी मद है — इसीलिए मुख्यतः उसी से बना प्रस्ताव चेतावनी है।
प्रस्ताव में मूल्यांकन की मद न हो तो आप डेमो ख़रीद रहे हैं।

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

### भूली जाने वाली मद: रखरखाव
- मॉडल हटना: साल में एक-दो बार नए संस्करण पर पुनः-योग्यता।
- API बहाव: आपके टूल जिन सिस्टमों को बुलाते हैं वे बिना पूछे बदलते हैं।
- Retrieval रखरखाव: दस्तावेज़ बदलते हैं और बासी इंडेक्स न होने से बुरा है।
- मूल्यांकन वृद्धि: नए उपयोगकर्ता नई विफलता श्रेणियाँ लाते हैं।
- स्वामित्व: एजेंट कुछ अजीब करे तो किसी को ज़िम्मेदार होना चाहिए।
सालाना निर्माण लागत का 15–25% रखिए। एजेंट ख़त्म होने वाला प्रोजेक्ट नहीं, चलती सेवा है।

### तुलनीय प्रस्ताव कैसे पाएँ
हर आपूर्तिकर्ता से वही पाँच चीज़ें माँगिए और आँकड़े तुलनीय हो जाएँगे: आर्ग्युमेंट स्कीमा सहित टूल सूची; मूल्यांकन सेट कौन बनाएगा और कितने मामलों का; कौन-सी कार्रवाइयाँ इंसानी मंज़ूरी के पीछे; कौन-सी निगरानी दी जाएगी; और रखरखाव अनुबंध क्या ढँकता है।

Q: एक ही brief पर प्रस्ताव इतने अलग क्यों?
A: क्योंकि brief उतना ठोस नहीं होता जितना लगता है। अनुमतियाँ, मूल्यांकन, निगरानी और रखरखाव वाला प्रस्ताव अलग उत्पाद है।

Q: क्या हम छोटे से शुरू कर सकते हैं?
A: हाँ। एक संकीर्ण काम, दो केवल-पढ़ने टूल और बीस मूल्यांकन मामले — यह अक्सर $8,000–$15,000 है और बताता है कि बड़ा काम फ़ंड करने लायक़ है या नहीं।

Q: क्या घर में बनाना सस्ता है?
A: नक़दी में सस्ता, समय में महँगा, और तभी जब कोई अनुभवी उसे अपनाए।

## AI एजेंट को स्केल करना: विलंब, समवर्तीता और दर सीमाएँ
https://aiagentdevelopment.info/hi/guides/agent-scaling
2026-08-04 को अपडेट · प्रोडक्शन और ऑपरेशन

- अड़चन प्रोवाइडर कोटा है, आपके सर्वर नहीं।
- इंटरैक्टिव और पृष्ठभूमि ट्रैफ़िक अलग कीजिए और दूसरे को क़तार में डालिए।
- स्ट्रीम कीजिए, असली प्रगति दिखाइए और सीमाओं पर उपयोगी आंशिक नतीजे दीजिए।
- घटना मजबूर करे उससे पहले स्विच के पीछे गिरावट मोड बनाइए।

पहला ट्रैफ़िक उछाल हर टीम को यही सिखाता है। आपके सर्वर लगभग ख़ाली हैं, डेटाबेस ठीक है और सब धीमा है — क्योंकि हर अनुरोध कोटा वाले प्रोवाइडर को कई सेकंड की कई कॉल है, और कोटा को इससे मतलब नहीं कि आपने कितने कंटेनर चलाए।

इसलिए एजेंट स्केलिंग ज़्यादातर क़तार सिद्धांत और अपेक्षा प्रबंधन है, थोड़ी क्षमता योजना भी। अच्छी ख़बर: तकनीकें जानी-पहचानी हैं और किसी में एजेंट दोबारा लिखना नहीं पड़ता।

### तीन में से कौन-सी सीमा लगी है, जानिए
| प्रोवाइडर से 429 | प्रति मिनट अनुरोध या टोकन | क़तार, बैकऑफ़, कुंजी/क्षेत्र में बाँटना |
| धीमा पर बिना त्रुटि | प्रति रन क्रमिक कॉल | स्वतंत्र कदम समानांतर; लूप छोटा |
| मेमोरी या कनेक्शन ख़त्म | आपकी अपनी सेवा | सामान्य क्षमता काम |
| केवल व्यस्त समय धीमा | साझा कोटा प्रतिस्पर्धा | प्राथमिकता क़तार; कम मूल्य टालिए |

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

### इंतज़ार को ईमानदारी से छोटा कीजिए
- जवाब बनते ही स्ट्रीम कीजिए, आख़िरी टोकन के बाद नहीं।
- मौजूदा कदम सादे शब्दों में दिखाइए: `आपका ऑर्डर देखा जा रहा है`।
- सीमा पर उपयोगी आंशिक नतीजा लौटाइए और बताइए क्या छूटा।
- जो रोकता नहीं उसे क्रिटिकल पथ से हटाइए और बाद में दीजिए।
विलंब की अनुभूति इंजीनियरिंग जितनी ही उत्पाद समस्या है। दिखती प्रगति वाले पाँच सेकंड ख़ाली स्क्रीन के तीन सेकंड को हरा देते हैं।

### गिरावट मोड ज़रूरत से पहले बनाइए
पहले से तय कीजिए कि प्रोवाइडर धीमा, कोटा-पार या बंद होने पर एजेंट क्या करेगा — और इसे शांति से बनाइए। एक समझदार सीढ़ी: पूरा एजेंट, फिर सस्ता या वैकल्पिक मॉडल, फिर बिना टूल केवल retrieval जवाब, फिर ईमानदार माफ़ी और इंसान को सौंपना। इसे ऐसे स्विच के पीछे रखिए जिसे ऑन-कॉल सेकंडों में पलट सके।

### दो आँकड़ों से क्षमता योजना
प्रति पूर्ण कार्य मॉडल कॉल और प्रति पूर्ण कार्य टोकन। इन्हें व्यस्त समय के प्रति मिनट कार्यों से गुणा कीजिए, कोटा से तुलना कीजिए, और लॉन्च के दौरान नहीं, पहले पता चल जाएगा कि सीमा बढ़वानी है या नहीं।

Q: कई प्रोवाइडर खाते या क्षेत्र?
A: असली स्केल या लचीलेपन के लिए हाँ। इसे एक आंतरिक इंटरफ़ेस के पीछे कीजिए और प्रति मार्ग मॉडल संस्करण पिन कीजिए।

Q: इंटरैक्टिव विलंब स्वीकार्य कैसे रखें?
A: कदम सख़्ती से सीमित कीजिए, सरल कदम तेज़ मॉडल पर, स्वतंत्र कॉल समानांतर और आउटपुट स्ट्रीम।

Q: ट्रैफ़िक बढ़ने पर पहले क्या टूटता है?
A: लगभग हमेशा प्रोवाइडर की दर सीमाएँ, फिर आपके सबसे व्यस्त टूल की आंतरिक API।

## AI एजेंट सुरक्षा: सुरक्षा-रेखाएँ, अनुमतियाँ और prompt injection
https://aiagentdevelopment.info/hi/guides/agent-suraksha-aur-guardrails
2026-08-04 को अपडेट · प्रोडक्शन और ऑपरेशन

- एजेंट को ऐसी सहकर्मी मानिए जिसे अजनबी बहला सकते हैं।
- Injection वास्तुशिल्पीय है: न्यूनतम विशेषाधिकार, पृथक्करण, मंज़ूरी, ऑडिट।
- अंतिम उपयोगकर्ता की पहचान पर, सर्वर की ओर, हर कॉल पर अनुमति दीजिए।
- विरोधी मामले मूल्यांकन में रखिए और हर मॉडल बदलाव पर दोबारा चलाइए।

एजेंट का सुरक्षा मॉडल तब आसान हो जाता है जब आप उसे कोड की तरह नहीं, बल्कि एक मददगार, तेज़, न थकने वाली सहकर्मी की तरह देखें जिसे कोई अजनबी बातों में ला सकता है।

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

### वह ख़तरा जिसे prompt से हल नहीं कर सकते
Prompt injection यानी ऐसे निर्देश जो एजेंट द्वारा पढ़ी सामग्री में छिपे हों — टिकट, वेब पेज, PDF, टूल विवरण। मॉडल यह भरोसे से अलग नहीं कर सकता कि क्या डेटा है और क्या निर्देश, और `दस्तावेज़ के निर्देश अनदेखा करो` जैसा कोई वाक्य यह खाई नहीं भरता। इसलिए बचाव वास्तुशिल्पीय होना चाहिए।
मान लीजिए हर लाई गई सामग्री उसने लिखी है जो आपके एजेंट से ग़लत काम कराना चाहता है। ऐसा बनाइए कि यह केवल झुँझलाहट रहे।

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

### कार्रवाई के प्रकार से नुक़सान का दायरा
| अपना रिकॉर्ड पढ़ना | — | अनुमति जाँच |
| जवाब का मसौदा | हाँ | कुछ नहीं चाहिए |
| स्थिति फ़ील्ड अपडेट | आमतौर पर | ऑडिट और दर सीमा |
| बाहरी संदेश भेजना | नहीं | इंसानी मंज़ूरी |
| रिफ़ंड या भुगतान | नहीं | मंज़ूरी, राशि सीमा |
| डेटा हटाना | नहीं | मंज़ूरी, केवल सॉफ़्ट डिलीट |

### डेटा संभालना, साफ़ शब्दों में
लॉन्च से पहले तय कीजिए कि मॉडल प्रोवाइडर को क्या भेजा जा सकता है, और इसे नीति दस्तावेज़ में नहीं, कोड में लागू कीजिए — सीमा पर ढकना, फ़ील्ड की अनुमति-सूची और एक टेस्ट जो साबित करे कि बैंक नंबर वाला रिकॉर्ड कभी बाहर नहीं जाता।

### हमलावर की तरह और नियमित रूप से परखिए
मूल्यांकन सेट में विरोधी मामले रखिए और उन्हें किसी और टेस्ट की तरह चलाइए: ऐसा टिकट जिसमें आंतरिक दस्तावेज़ ईमेल करने का निर्देश हो; ऐसा दस्तावेज़ जो दावा करे कि उपयोगकर्ता प्रशासक है। जो रन ऐसी कार्रवाई पर ख़त्म हो जो नहीं होनी चाहिए थी, वह विफल टेस्ट है।

Q: क्या बेहतर prompt से injection हल होगा?
A: नहीं। निर्देश दर घटाते हैं, ख़त्म नहीं करते, क्योंकि मॉडल डेटा और निर्देश भरोसे से अलग नहीं कर सकता।

Q: क्या एजेंट सर्विस अकाउंट इस्तेमाल करे?
A: केवल सचमुच सार्वजनिक डेटा के लिए। उपयोगकर्ता-विशिष्ट हर चीज़ में पहचान अनुमति जाँच तक पहुँचनी चाहिए।

Q: इंसानी दरवाज़े के पीछे क्या रखें?
A: जो पलट न सके, जो ग्राहक को दिखे, जो राशि सीमा से ऊपर हो और जिसमें एजेंट अनिश्चित हो। ज़्यादा दरवाज़ों से शुरू कीजिए।

## प्रोडक्शन में एजेंट की निगरानी: क्या दर्ज करें, किस पर अलर्ट
https://aiagentdevelopment.info/hi/guides/production-mein-agent-nigrani
2026-08-04 को अपडेट · प्रोडक्शन और ऑपरेशन

- हर रन ट्रेस कीजिए: संदर्भ, कॉल, संस्करण, रुकने का कारण, बाद के सुधार।
- छह व्यवहार मीट्रिक देखिए; सफलता और इंसानी दख़ल सबसे अहम।
- बदलाव की दर पर अलर्ट कीजिए और हर अलर्ट के साथ ट्रेस दीजिए।
- हर दिन असली रन का नमूना पढ़िए।

पारंपरिक सेवा तब स्वस्थ है जब वह तेज़ जवाब दे और त्रुटि न फेंके। एजेंट दोनों करते हुए भी पूरी तरह ग़लत हो सकता है — हर अनुरोध दो सेकंड में और हर एक मार्च में वापस ली गई नीति का हवाला देते हुए।

इसलिए एजेंट निगरानी अलग अनुशासन है। यह दो चीज़ों पर टिकी है: हर रन की ऐसी ट्रेस जिससे जो हुआ वह दोबारा बनाया जा सके, और थोड़े व्यवहार मीट्रिक जिनकी हलचल का अर्थ हो। बाक़ी सजावट है।

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

### छह मीट्रिक जो सचमुच हिलती हैं
| सफलता दर | लगातार गिरावट | मॉडल बदला, डेटा बहाव, API बदला |
| प्रति रन कदम | धीरे बढ़ते | टूल त्रुटियाँ दोहराई जा रहीं; retrieval बिगड़ा |
| प्रति टूल त्रुटि दर | एक टूल पर उछाल | ऊपर का सिस्टम टूटा — एजेंट नहीं |
| इंसानी दख़ल दर | बढ़त | भरोसा गिर रहा या नई श्रेणी |
| बेबुनियाद दावे | कोई भी बढ़त | Retrieval चुपचाप विफल |
| प्रति कार्य लागत | हैसियत स्थिर पर बढ़त | संदर्भ फूला या रीट्राई बढ़े |

### केवल त्रुटि नहीं, व्यवहार पर अलर्ट
एजेंट शायद ही शोर के साथ विफल होता है। वह धीरे बिगड़ता है: थोड़े और कदम, थोड़ी और रीट्राई, थोड़े और एस्केलेशन — और एक सुबह वह बासी दस्तावेज़ों से जवाब दे रहा होता है। निरपेक्ष सीमा नहीं, चलती खिड़की में बदलाव की दर पर अलर्ट कीजिए। हर अलर्ट के साथ एक प्रतिनिधि रन की ट्रेस जोड़िए।

### हर दिन असली रन पढ़िए
कोई डैशबोर्ड पढ़ने की जगह नहीं लेता। रोज़ कुछ रन चुनिए — कुछ सफल, हर एस्केलेशन, सीमा छूने वाला हर रन — और पूरा पढ़िए। प्रोडक्शन में मिली हर गंभीर समस्या मीट्रिक से पहले ट्रेस में दिखी थी। पढ़ने वाला बदलते रहिए।
जो चौंकाए उसे उसी दिन मूल्यांकन सेट में जोड़िए। यही आदत निगरानी को सुधार में बदलती है।

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

Q: पूरी ट्रेस कितने समय रखें?
A: डीबग और ऑडिट के लिए जितनी चाहिए — पूरे संदर्भों के लिए आमतौर पर 30–90 दिन, जबकि मीट्रिक और सारांश बहुत लंबे। यह जान-बूझकर तय कीजिए।

Q: सबसे मूल्यवान अलर्ट कौन-सा?
A: एस्केलेशन या इंसानी सुधार में बढ़त। बहाव का सबसे शुरुआती ईमानदार संकेत, और इसे लेबलिंग नहीं चाहिए।

Q: क्या विशेष ऑब्ज़र्वेबिलिटी टूल चाहिए?
A: शुरू में नहीं। क्वेरी करने योग्य ट्रेस तालिका अधिकांश ज़रूरत पूरी करती है।

## गुणवत्ता बिगाड़े बिना एजेंट की लागत घटाना
https://aiagentdevelopment.info/hi/guides/agent-lagat-kam-karna
2026-08-04 को अपडेट · प्रोडक्शन और ऑपरेशन

- अनुकूलन से पहले काम-प्रकार के हिसाब से प्रति पूर्ण कार्य लागत मापिए।
- जिस संदर्भ की अब ज़रूरत नहीं, वही आमतौर पर सबसे बड़ा मद है।
- कम विवेक वाले कदम एक-एक कर और मूल्यांकन के साथ नीचे भेजिए।
- प्रति रन ख़र्च सीमित कीजिए और सीमा छूने पर अलर्ट कीजिए।

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

नीचे का तरीक़ा उबाऊ और असरदार है: पहले मापिए, फिर लाभ के क्रम में चार बदलाव लागू कीजिए और तब तय कीजिए कि समस्या बची भी है या नहीं। ज़्यादातर टीमें दूसरे बदलाव के बाद रुक जाती हैं।

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

### चार बदलाव, लाभ के क्रम में
| संदर्भ काटिए: इस्तेमाल दस्तावेज़ हटाइए, इतिहास संपीड़ित कीजिए | 20–40% | कम, अगर लक्ष्य स्थिर रहे |
| सस्ते कदम छोटे मॉडल पर भेजिए | 20–40% | प्रति कदम मूल्यांकन के साथ कम |
| स्थिर prompt उपसर्ग कैश कीजिए | दोहराव ट्रैफ़िक पर 10–30% | कम |
| कदम घटाइए: बेहतर टूल, कम रीट्राई | 10–25% | मध्यम — टूल पर काम चाहिए |

### बिल ही संदर्भ है
हर मोड़ जमा संदर्भ दोबारा भेजता है, इसलिए आठ कदम का रन वही दस्तावेज़ आठ बार चुका सकता है। तीन आदतें अधिकांश ठीक कर देती हैं: जिस कदम को पैराग्राफ़ चाहिए थे वह पूरा होते ही उन्हें हटाइए; पुराने मोड़ छोटी तथ्य-नोट में संपीड़ित कीजिए; और टूल नतीजे उन्हीं फ़ील्ड तक काटिए जो एजेंट इस्तेमाल करता है।

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

### जो नहीं करना चाहिए
जवाबों को आधार देने वाला retrieval मत काटिए — जब किसी को सुधार करना पड़े तो हैलुसिनेशन टोकन से कहीं महँगा है। एक कॉल बचाने के लिए अपरिवर्तनीय कार्रवाइयों पर समीक्षक चक्र मत हटाइए। और prompt शब्दों की सूक्ष्म-अनुकूलन के पीछे मत भागिए।

Q: क्या कैशिंग सार्थक है?
A: अगर आपके रन लंबा स्थिर उपसर्ग साझा करते हैं — सिस्टम निर्देश, टूल परिभाषाएँ, नीति टेक्स्ट — तो हाँ, और यह सबसे सस्ती जीतों में है।

Q: क्या बचत के लिए फ़ाइन-ट्यून करें?
A: केवल ऐसे उच्च-हैसियत, संकीर्ण और स्थिर कदम के लिए जहाँ छोटा ट्यून मॉडल बड़े की बराबरी करे। कम हैसियत पर राउटिंग और संदर्भ-कटौती बेहतर हैं।

Q: एक भारी रन को कैसे रोकें?
A: प्रति रन कदम और ख़र्च सीमित कीजिए, दोहराई गई समान कॉल पहचानिए और आंशिक नतीजे के साथ रुकिए। सीमा छूने वाले रन पर अलर्ट रखिए।

## AI एजेंट का परीक्षण: ऐसा मूल्यांकन सेट जो अपनी क़ीमत निकाले
https://aiagentdevelopment.info/hi/guides/agent-testing-aur-mulyankan
2026-08-04 को अपडेट · प्रोडक्शन और ऑपरेशन

- आपके पचास मामले किसी भी बेंचमार्क से बेहतर बताते हैं कि बदलाव से फ़ायदा हुआ या नहीं।
- नतीजे और प्रभाव अंकित कीजिए, ठीक-ठीक प्रतिलेख कभी नहीं।
- अस्पष्ट इनपुट, मना-करने वाले मामले और ख़ाली नतीजे जान-बूझकर ढँकिए।
- हर prompt, टूल, मॉडल या retrieval बदलाव पर दोबारा चलाइए।

जो एजेंट लॉन्च होते हैं और जो पायलट में सड़ते हैं, उनके बीच का सवाल सरल है: आपको कैसे पता कि कल के बदलाव ने चीज़ें बेहतर कीं? जवाब न हो तो हर prompt बदलाव एक जुआ है और हर रिग्रेशन ग्राहक खोजता है।

मूल्यांकन सेट यही जवाब है, और इसके लिए प्लेटफ़ॉर्म नहीं चाहिए। एक फ़ाइल में पचास मामले, उन्हें चलाने वाली एक स्क्रिप्ट और प्रति मामला एक अंकन नियम — यह किसी लीडरबोर्ड से ज़्यादा बताते हैं, क्योंकि ये आपके मामले हैं।

### एक मामला कैसा दिखता है
मामला यानी एक इनपुट, दुनिया की शुरुआती स्थिति और एक जाँचने योग्य अपेक्षा। अपेक्षा लगभग कभी ठीक-ठीक टेक्स्ट नहीं होती — एजेंट कई शब्दों में सही हो सकता है। इसके बजाय नतीजे को अंक दीजिए: क्या उसने ऑर्डर 4471 के साथ रिफ़ंड टूल बुलाया; क्या अंतिम जवाब में सही तारीख़ है; क्या उसने ठीक ही मना करके सवाल पूछा।
हर मामले को चाहिए स्थिति उसी के साथ रखिए। जो टेस्ट लाइव डेटा के कारण केवल मंगलवार को पास हो, वह टेस्ट नहीं है।

### पचास मामले और वे कहाँ से आते हैं
| लॉग से आम असली अनुरोध | 20 | रोज़मर्रा का रास्ता बचाता है |
| ज्ञात पुरानी विफलताएँ | 10 | रिग्रेशन लौटने से रोकता है |
| अस्पष्ट इनपुट | 8 | पूछना चाहिए, अनुमान नहीं |
| मना करने वाले मामले | 6 | दायरे से बाहर, बिना अनुमति, असुरक्षित |
| ख़ाली या टूटे टूल नतीजे | 6 | सबसे आम असली घटना |

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

### समय के साथ चार आँकड़े
- पूरे सेट पर सफलता दर और अलग से मना-करने वाले उपसमूह पर।
- बेबुनियाद दावों की दर — ऐसे जवाब जिनके तथ्य प्रमाणों में नहीं।
- प्रति रन लागत और विलंब का माध्यक और 95वाँ प्रतिशतक।
- इंसानी दख़ल दर: कितनी बार किसी को आना पड़ा और क्यों।

### पाइपलाइन में और लॉन्च के बाद भी
prompt, टूल, मॉडल संस्करण या retrieval कॉन्फ़िगरेशन में किसी भी बदलाव पर सेट चलाइए — व्यवहार बदलने वाली केवल यही चार चीज़ें हैं। लॉन्च के बाद असली ट्रैफ़िक से नमूना लेते रहिए: रोज़ कुछ रन हाथ से अंकित कीजिए और जो चौंकाए उसे सेट में जोड़िए। जो सेट बढ़ना बंद कर दे, वह एक तिमाही में आपके उपयोगकर्ताओं का प्रतिनिधित्व करना बंद कर देता है।

Q: शुरू करने के लिए कितने मामले?
A: पचास असली रिग्रेशन पकड़ते हैं और कुछ दिनों में लिखे जाते हैं। बीस शुरू करने के लिए काफ़ी हैं। संख्या से ज़्यादा ज़रूरी है असहज श्रेणियाँ ढँकना।

Q: क्या मॉडल से अंकन करा सकते हैं?
A: हाँ, सावधानी से। स्पष्ट मानदंड दीजिए, सूची छोटी रखिए और नियमित रूप से हाथ से नमूना जाँचिए। अंकन-मॉडल खिसकते हैं।

Q: क्या मूल्यांकन तैनाती रोके?
A: सुरक्षा-महत्वपूर्ण उपसमूह पर रोके — मना-करने वाले मामले और अपरिवर्तनीय सब कुछ। सामान्य गुणवत्ता में रुझान देखिए और गिरावट पर इंसानी निर्णय माँगिए।

## मल्टी-एजेंट सिस्टम: कई एजेंट एक से कब बेहतर
https://aiagentdevelopment.info/hi/guides/multi-agent-system
2026-08-04 को अपडेट · एजेंट बनाना

- कई एजेंट केवल स्वतंत्र, अलग-औज़ार वाले और धीमे उप-कार्यों के लिए।
- संरचित वस्तुएँ भेजिए और पूरे अनुरोध के लिए एक रन पहचानकर्ता रखिए।
- लागत पूरे सिस्टम पर सीमित कीजिए, प्रति एजेंट नहीं।
- नतीजों के साथ हस्तांतरण भी मापिए।

मल्टी-एजेंट आरेख इस क्षेत्र की सबसे लुभावनी चीज़ हैं। पदनाम वाले डिब्बे, बीच में तीर, ऊपर एक समन्वयक — यह संगठन-चार्ट जैसा दिखता है, और संगठन-चार्ट प्रगति का एहसास देते हैं।

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

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

### टोपोलॉजी और उनकी लागत
| सुपरवाइज़र | एक एजेंट विशेषज्ञों को सौंपता है | N+1 लूप | सुपरवाइज़र ग़लत भेजता है |
| पाइपलाइन | तय हस्तांतरण, विशेषज्ञ चरण | पूर्वानुमेय | एक चरण चुपचाप बिगड़ता है |
| समानांतर फैलाव | वही काम, कई दृष्टि, विलय | सबसे ऊँची | विलय अड़चन बनता है |
| बहस या समीक्षक | एक सुझाता, दूसरा चुनौती देता | प्रति आदान-प्रदान 2× | बिना अंतर्दृष्टि सहमति |
| ब्लैकबोर्ड | साझा स्थिति, सब पढ़ते-लिखते | अप्रत्याशित | रेस और चक्कर |

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

### वह मूल्यांकन समस्या जिसकी कोई योजना नहीं बनाता
एक एजेंट में आप नतीजे मापते हैं। कई में हस्तांतरण भी मापने होंगे, क्योंकि हर एजेंट सही व्यवहार करते हुए भी सिस्टम ग़लत जवाब दे सकता है — राउटर ने ग़लत चुना या विलय ने ज़रूरी आधा गिरा दिया। दोनों स्तरों पर मूल्यांकन बनाइए।

### एक उदाहरण जो सार्थक है
प्रतिस्पर्धी शोध सचमुच फिट बैठता है: दस कंपनियों की सार्वजनिक जानकारी जुटाना। उप-कार्य स्वतंत्र हैं, हर एक धीमा है और विलय सीधा जोड़ है। दस समानांतर एजेंट एक के समय में पूरा करते हैं। इसकी तुलना एक ग्राहक सवाल वाले सपोर्ट एजेंट से कीजिए: वहाँ कदम क्रम में एक-दूसरे पर निर्भर हैं।

Q: क्या सुपरवाइज़र सटीकता बढ़ाता है?
A: तभी जब राउटिंग सही हो। 95% विशेषज्ञों के आगे 90% सुपरवाइज़र अंत-से-अंत लगभग 85% देता है।

Q: क्या एजेंट बहस लागत के लायक़ है?
A: कभी-कभी, सचमुच विवादित निर्णयों में जहाँ समीक्षक को जाँचने के लिए प्रमाण दे सकें। तथ्यात्मक खोज में यह ज़्यादातर सहमति देती है, दोगुनी क़ीमत पर।

Q: मल्टी-एजेंट विफलता कैसे डीबग करें?
A: हर कॉल पर साझा पहचानकर्ता, प्रति एजेंट संग्रहित इनपुट-आउटपुट और क्रम में हस्तांतरण दिखाने वाले दृश्य से।

## एजेंट के लिए RAG: संदर्भ में डूबे बिना जवाब को आधार देना
https://aiagentdevelopment.info/hi/guides/agent-ke-liye-rag
2026-08-04 को अपडेट · एजेंट बनाना

- Retrieval को एजेंट द्वारा बुलाया जाने वाला टूल बनाइए, हर अनुरोध का पहला कदम नहीं।
- संरचना पर टुकड़े कीजिए, टुकड़े स्वतंत्र रखिए, शीर्षक और पहचानकर्ता जोड़िए।
- असली ट्रैफ़िक पर कीवर्ड + वेक्टर मिश्रण अकेले किसी से बेहतर है।
- स्रोत अनिवार्य कीजिए और ईमानदार ख़ाली नतीजे की अनुमति दीजिए।

Retrieval-augmented generation को आमतौर पर एक पाइपलाइन की तरह पेश किया जाता है: सवाल एम्बेड करो, शीर्ष टुकड़े लाओ, चिपकाओ, बनाओ। यह प्रश्नोत्तर बॉक्स के लिए ठीक है। एजेंट के भीतर यह ग़लत रूप है, क्योंकि एजेंट को तब तक पता नहीं होता कि उसे क्या चाहिए जब तक वह एक कदम न ले ले।

काम करने वाला संस्करण retrieval को उस टूल की तरह देखता है जिसे एजेंट तब बुलाता है जब उसे प्रमाण चाहिए — कभी अलग सवालों के साथ दो बार, कभी बिल्कुल नहीं। यही एक बदलाव बहुत सारा अप्रासंगिक संदर्भ हटाता है।

### Retrieval प्रस्तावना नहीं, टूल है
खोज को सामान्य टूल की तरह खोलिए: सवाल का आर्ग्युमेंट और छोटा संरचित रिटर्न — कुछ पैराग्राफ़, हर एक पहचानकर्ता और स्रोत के साथ। एजेंट तय करता है कब बुलाए, लौटा देखकर सवाल सुधार सकता है और जवाब संरचित डेटा हो तो दूसरा टूल बुला सकता है।
एजेंट के लिखे सवाल दर्ज कीजिए। आपके उपयोगकर्ता असल में क्या पूछते हैं, इसका सबसे ईमानदार विवरण वही है।

### एम्बेडिंग मॉडल से ज़्यादा मायने रखते चंकिंग निर्णय
- तय अक्षर संख्या नहीं, संरचना पर बाँटिए — शीर्षक, अनुभाग, सूची आइटम।
- हर टुकड़ा अपने आप में समझ में आए: `यह भी ज़रूरी है` से शुरू होता टुकड़ा बेकार है।
- हर टुकड़े के साथ दस्तावेज़ शीर्षक और अनुभाग शीर्षक जोड़िए।
- हर टुकड़े के साथ पहचानकर्ता और URL रखिए ताकि जवाब स्रोत दिखा सके।
- कम, बड़े और अर्थपूर्ण टुकड़े बेहतर; ओवरलैप ख़राब सीमाओं का पैबंद है।

### असली संग्रहों पर मिश्रित खोज शुद्ध वेक्टर को हराती है
| अवधारणात्मक सवाल | मज़बूत | कमज़ोर | वेक्टर |
| सटीक कोड या त्रुटि टेक्स्ट | कमज़ोर | मज़बूत | कीवर्ड |
| दुर्लभ नाम | मिश्रित | मज़बूत | कीवर्ड |
| दोबारा कहे नीति सवाल | मज़बूत | कमज़ोर | वेक्टर |
| कुल असली ट्रैफ़िक | मिश्रित | मिश्रित | दोनों, मिलाकर पुनःक्रमित |

### स्रोत दिलवाइए और विफल होने दीजिए
भरोसे का अधिकांश काम दो शर्तें करती हैं। पहली, retrieval से आया हर दावा अपने पैराग्राफ़ का पहचानकर्ता रखता है और आपका इंटरफ़ेस उसे लिंक बनाता है। दूसरी, खोज कुछ न लौटा सके और एजेंट को सिखाया जाए कि `यह हमारे दस्तावेज़ों में नहीं मिला` सही नतीजा है। जो एजेंट खोज में विफल नहीं हो सकता, वह गढ़ेगा।

### इंडेक्स को ईमानदार रखना
Retrieval गुणवत्ता चुपचाप गिरती है। दस्तावेज़ बदलते हैं, अनुभाग हटते हैं और इंडेक्स वही परोसता रहता है जो उसने आख़िरी बार देखा। नियमित पुनः-इंडेक्स कीजिए, हटे स्रोत वाले टुकड़े मिटाइए और ज्ञात सही पैराग्राफ़ वाले सवालों का छोटा सेट रखिए।

Q: क्या एजेंट हमेशा जवाब से पहले खोजे?
A: नहीं। हर अनुरोध पर खोज विलंब बर्बाद करती है और उन सवालों में संदर्भ भरती है जिन्हें प्रमाण चाहिए ही नहीं।

Q: कितने पैराग्राफ़ लौटाएँ?
A: तीन से छह अच्छे चुने पैराग्राफ़ बीस से बेहतर हैं। ज़्यादा टेक्स्ट ध्यान बाँटता है और लागत बढ़ाता है।

Q: अगर retrieval कुछ काम का न लौटाए?
A: यह समर्थित नतीजा होना चाहिए। स्पष्ट ख़ाली नतीजा लौटाइए और एजेंट को कहने दीजिए कि नहीं मिला और अगला कदम सुझाइए।

## AI एजेंट में स्मृति: क्या रखें, क्या संपीड़ित करें, क्या फेंकें
https://aiagentdevelopment.info/hi/guides/agent-mein-smriti
2026-08-04 को अपडेट · एजेंट बनाना

- मॉडल की स्मृति नहीं; एजेंट के पास वही है जो आप दोबारा जोड़ते हैं।
- चार परतें: स्थिर लक्ष्य, हालिया मोड़, संपीड़ित तथ्य, ताज़ा लाया ज्ञान।
- कहानी नहीं, जाँचने योग्य तथ्यों में और केवल एक सीमा पर संपीड़ित कीजिए।
- टिकाऊ स्मृति को स्रोत, समाप्ति और सुधार का रास्ता चाहिए।

भाषा मॉडल कॉल में स्मृति नहीं होती। हर मोड़ एक नया अनुरोध है और मॉडल केवल वही जानता है जो आपने इस बार जोड़ा। जिसे लोग "एजेंट भूल गया" या "लंबे रन में बिगड़ गया" कहते हैं, वह आपके कोड का लिया गया निर्णय है कि क्या साथ ले जाना है।

यह मान लेने पर स्मृति डिज़ाइन एक परिचित इंजीनियरिंग समस्या बन जाती है: क्या हमेशा प्रासंगिक है, क्या हाल में प्रासंगिक है, क्या संक्षेप हो सकता है और क्या संग्रह करने के बजाय ताज़ा लाना चाहिए।

### चार परतें
| स्थिर | लक्ष्य, शर्तें, उपयोगकर्ता पहचान, नीति | कभी नहीं | 200–500 टोकन |
| हालिया | अंतिम मोड़ ज्यों के त्यों, नतीजों सहित | चलती खिड़की | 2–5 मोड़ |
| संपीड़ित | पुराने मोड़ छोटी तथ्य-नोट में | बढ़ने पर दोबारा लिखी | 500 टोकन से कम |
| लाया गया | इस कदम के लिए खींचे दस्तावेज़ | उपयोग के बाद हटाए | प्रति कदम |

### गद्य नहीं, तथ्य संपीड़ित कीजिए
आम ग़लती पुराने मोड़ों को कहानी की तरह संक्षेप करना है — ग्राहक ने ऑर्डर पूछा और एजेंट ने देखा। यह पढ़ने में अच्छा है और किसी काम का नहीं। उन तथ्यों तक संपीड़ित कीजिए जो आगे चाहिए हो सकते हैं: ऑर्डर 4471, स्थिति भेजा गया, रिफ़ंड माँगा गया, नीति 30 दिन, अभी रिफ़ंड नहीं।
हर मोड़ पर नहीं, एक सीमा पर संपीड़ित कीजिए। संक्षेप का संक्षेप करने से ब्यौरे चुपचाप ग़ायब होते हैं।

### लाना स्मृति नहीं है
ज्ञान-आधार से खींचे दस्तावेज़ उसी कदम के हैं जिसे उनकी ज़रूरत थी। उसके बाद उन्हें संदर्भ में रखना फूले हुए, महँगे और भटके रन तक का सबसे तेज़ रास्ता है। लाइए, इस्तेमाल कीजिए, स्रोत दीजिए, हटाइए।

### सत्रों के बीच टिकाऊ स्मृति
लंबे चलने वाले एजेंट किसी उपयोगकर्ता या खाते के बारे में सचमुच उपयोगी तथ्य जमा करते हैं: पसंद, पिछले निर्णय, न बदलने वाली शर्तें। इन्हें जान-बूझकर, एक छोटे संरचित रिकॉर्ड में स्पष्ट लेखन-कदम के साथ रखिए। तीन नियम इसे स्वस्थ रखते हैं: केवल वे तथ्य लिखिए जिन पर भविष्य का रन अमल करेगा, स्रोत दर्ज कीजिए और हर तथ्य को समाप्ति तिथि दीजिए।
- जान-बूझकर लिखिए — टूल कॉल के रूप में, दुष्प्रभाव के रूप में नहीं।
- हर तथ्य के साथ स्रोत और तारीख रखिए।
- आकार सीमित कीजिए और अप्रयुक्त को समाप्त कीजिए।
- उपयोगकर्ता को दिखाइए और सुधारने दीजिए।

### लक्षण और कारण
| शुरुआती शर्त भूलता है | शर्त स्थिर नहीं थी, इतिहास के साथ छँट गई |
| कुछ कदम बाद गुणवत्ता गिरती है | संदर्भ पुराने आउटपुट से पतला |
| पूरा हुआ कदम दोहराता है | नतीजा बिना समापन-चिह्न संपीड़ित |
| रन लंबा होते ही लागत बढ़ती है | लाए दस्तावेज़ जमा हो रहे हैं |
| पुरानी बात आत्मविश्वास से कहता है | टिकाऊ स्मृति में समाप्ति और स्रोत नहीं |

Q: कितना इतिहास ज्यों का त्यों रखें?
A: तीन से पाँच मोड़ अधिकांश तर्क ढँक लेते हैं और संदर्भ पर हावी नहीं होते। नतीजे उनकी कॉल से जुड़े रहें और पुराना संरचित तथ्यों में संपीड़ित हो।

Q: क्या स्मृति के लिए वेक्टर डेटाबेस चाहिए?
A: दस्तावेज़ लाने के लिए अक्सर हाँ। एक रन की चालू स्थिति के लिए नहीं — वह आपके भंडार में एक छोटा संरचित वस्तु है।

Q: टिकाऊ स्मृति बासी होने से कैसे रोकें?
A: हर तथ्य को स्रोत, तारीख और समाप्ति दीजिए और ताज़ा लाए डेटा को प्राथमिकता दिलाइए। रिकॉर्ड उपयोगकर्ता को दिखाइए।

## Tool calling: ऐसे टूल बनाना जिन्हें एजेंट सही इस्तेमाल करे
https://aiagentdevelopment.info/hi/guides/agent-ke-liye-tool-calling
2026-08-04 को अपडेट · एजेंट बनाना

- अधिकतर विफलताएँ prompt नहीं, टूल डिज़ाइन की होती हैं।
- एक टूल एक काम; गद्य नहीं, प्रकार से सीमित कीजिए।
- त्रुटियाँ छोटे निर्देश की तरह लिखिए; ख़ाली नतीजा वैध मानिए।
- हर आर्ग्युमेंट जाँचिए और पहचानकर्ता उपयोगकर्ता की दृष्टि से हल कीजिए।

एजेंट ग़लत व्यवहार करे तो पहली प्रवृत्ति prompt दोबारा लिखने की होती है। हमारे अनुभव में शायद एक-तिहाई बार prompt ही कारण होता है; बाक़ी बार टूल किसी प्रोग्राम के लिए बने होते हैं, उस पाठक के लिए नहीं जिसे नाम और विवरण से अनुमान लगाना है कि फ़ंक्शन करता क्या है।

टूल ही एजेंट की दुनिया को प्रभावित करने की पूरी क्षमता हैं, और उनकी परिभाषाएँ शब्दशः मॉडल के संदर्भ का हिस्सा हैं। उन्हें अच्छा बनाना prompt ट्यूनिंग से सस्ता और कहीं ज़्यादा टिकाऊ है, क्योंकि अच्छा टूल व्यवहार माँगता नहीं, सीमित करता है।

### सात नियम जो अधिकतर ग़लत कॉल रोकते हैं
- एक टूल, एक काम। मोड वाले `manage_order` से `search_orders` और `refund_order` बेहतर हैं।
- गद्य नहीं, प्रकार। Enum, सीमाएँ और स्वरूप वह करते हैं जो विवरण कभी नहीं करेगा।
- ऐसे नाम जो बताएँ क्या होगा। `send_email_to_customer` स्पष्ट है, `notify` नहीं।
- त्रुटियाँ निर्देश की तरह: क्या ग़लत था और आगे क्या करें, एक छोटे वाक्य में।
- ख़ाली नतीजा भी नतीजा है। स्पष्ट नहीं-मिला अपवाद से बेहतर है।
- प्रभाव वाली हर चीज़ पर निष्क्रियता कुंजी, ताकि रीट्राई दोहरा न दे।
- छोटे रिटर्न। ज़रूरी फ़ील्ड तक काटिए; 40 KB JSON भ्रम ख़रीदता है।

### पहले और बाद
| `query(sql)` | असीमित शक्ति, बिना ऑडिट | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | मॉडल स्वरूप गढ़ता है | `date: string, स्वरूप YYYY-MM-DD` |
| `HTTP 500` | कोई कार्रवाई नहीं सुझाता | `ऑर्डर सेवा अनुपलब्ध। उपयोगकर्ता से बाद में कहें।` |
| पूरा रिकॉर्ड लौटाता है | संदर्भ भरता, ध्यान बाँटता | छह नामित फ़ील्ड लौटाता है |
| `update_status(id, status)` | कोई भी स्थिति, कोई भी रिकॉर्ड | अनुमति जाँच वाला `cancel_order(id)` |

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

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

### टूल एजेंट से अलग टेस्ट कीजिए
हर टूल के अपने टेस्ट: वैध कॉल, अवैध आर्ग्युमेंट, अनुमति अस्वीकृत, ख़ाली नतीजा, समय-समाप्ति। फिर एजेंट को नक़ली टूल परत पर टेस्ट कीजिए ताकि ये स्थितियाँ जान-बूझकर बनाई जा सकें। हमने जितनी प्रोडक्शन घटनाएँ देखीं, लगभग सब इसी स्तर पर आसानी से दोहराई जा सकीं।

Q: कितने टूल ज़्यादा हैं?
A: एक लूप में लगभग दस से ऊपर चयन सटीकता गिरने लगती है और विवरण संदर्भ भरने लगते हैं। ज़्यादा चाहिए तो संकीर्ण राउटर के पीछे समूह बनाइए।

Q: क्या टूल कच्चा API जवाब लौटाएँ?
A: नहीं। ज़रूरी फ़ील्ड वाला छोटा, स्थिर रूप लौटाइए। कच्चे जवाब संदर्भ बर्बाद करते हैं और आपके व्यवहार को किसी और के API संस्करण से बाँध देते हैं।

Q: आर्ग्युमेंट गढ़ना कैसे रोकें?
A: सीमित करके: मुक्त टेक्स्ट की जगह enum, स्पष्ट स्वरूप और ऐसे पहचानकर्ता जिन्हें हल होना ही चाहिए। फिर जाँचिए और साफ़ इनकार दीजिए।

## AI एजेंट आर्किटेक्चर: वे पैटर्न जो प्रोडक्शन में टिकते हैं
https://aiagentdevelopment.info/hi/guides/agent-architecture-patterns
2026-08-04 को अपडेट · एजेंट बनाना

- डिफ़ॉल्ट: स्पष्ट रुकने की शर्तों और सीधी ट्रेस वाला सीमित लूप।
- टूल गेटवे — जाँच, अनुमति, दर सीमा, ऑडिट — सबसे मूल्यवान घटक है।
- योजनाकार–निष्पादक दिखता इरादा देता है; समीक्षक कम बेबुनियाद दावे।
- स्मृति परतों में: लक्ष्य, हालिया मोड़, संपीड़ित तथ्य, ताज़ा लाया ज्ञान।

आर्किटेक्चर की चर्चा अक्सर ग़लत सिरे से शुरू होती है: अवधारणाओं के नाम वाले डिब्बों का आरेख। उपयोगी संस्करण उस विफलता से शुरू होता है जिसे आप रोकना चाहते हैं, क्योंकि नीचे का हर पैटर्न एक ख़ास बुरी दोपहर रोकने के लिए है।

ये छह वही हैं जिन तक हम बार-बार लौटते हैं। ये आपस में जुड़ते हैं: प्रोडक्शन का एक सामान्य एजेंट टूल गेटवे, दो स्मृति परतों और एक इंसानी दरवाज़े वाला सीमित लूप होता है — और समीक्षक चक्र केवल वहीं जहाँ ग़लत नतीजे की क़ीमत एक और कॉल को जायज़ ठहराए।

### 1. सीमित लूप
आधार स्थिति और आपका डिफ़ॉल्ट। छोटे टूल सेट पर एक लूप, स्पष्ट रुकने की शर्तों के साथ: कदम सीमा, ख़र्च सीमा, दोहराव पहचान और घड़ी सीमा। इसका गुण है सीधी ट्रेस जिसे ऊपर से नीचे पढ़ा जा सके। बाक़ी सब इसमें जोड़ हैं, इसके विकल्प नहीं।
अगर आप अपने एजेंट को निकास-सूची वाले लूप के रूप में नहीं बना सकते, तो अभी आर्किटेक्चर नहीं, महत्वाकांक्षी prompt है।

### 2. योजनाकार–निष्पादक और पुनर्योजना
पाँच से ज़्यादा कदम वाले कामों में पहले क्रमांकित योजना माँगिए, कदम चलाइए और विफलता पर बासी योजना पर चलते रहने के बजाय दोबारा योजना बनाइए। लाभ सटीकता नहीं — यह है कि इंसान कार्रवाई से पहले इरादा देख लेता है, जिससे मंज़ूरी और डीबगिंग दोनों संभव होती हैं।

### 3. समीक्षक चक्र
दूसरा मॉडल कॉल मसौदे या प्रस्तावित कार्रवाई को लक्ष्य और लाए गए प्रमाणों के सामने जाँचता है और एक बार वापस भेज सकता है। यह आत्मविश्वासी पर बेबुनियाद आउटपुट का बड़ा हिस्सा पकड़ता है। वहाँ लगाइए जहाँ ग़लत नतीजा महँगा हो और एक अतिरिक्त कॉल सस्ती।
| सीमित लूप | 0 | ट्रेस-सुविधा, लागत नियंत्रण | कभी नहीं — यही आधार है |
| योजनाकार–निष्पादक | 1–2 | दिखता इरादा, जाँच-योग्यता | पाँच कदम से कम काम |
| समीक्षक चक्र | प्रति जाँचा आउटपुट 1 | कम बेबुनियाद दावे | सस्ते, पलटने योग्य आउटपुट |
| टूल गेटवे | 0 | अनुमति, ऑडिट, दर सीमा | केवल प्रोटोटाइप में |
| परतदार स्मृति | 0–1 | लंबे संदर्भ में प्रासंगिकता | छोटे एकल रन |
| इंसानी दरवाज़ा | 0 | अपरिवर्तनीय सुरक्षित रहता है | अगर कुछ अपरिवर्तनीय न हो |

### 4. टूल गेटवे
एजेंट को अपने सिस्टम सीधे कॉल मत करने दीजिए। हर टूल के आगे एक परत रखिए जो चार काम करे: स्कीमा के विरुद्ध आर्ग्युमेंट जाँचे, देखे कि यह अंतिम उपयोगकर्ता इस रिकॉर्ड को छू सकता है या नहीं, दर सीमा लगाए और रन पहचानकर्ता के साथ ऑडिट पंक्ति लिखे। यह पूरे सिस्टम का सबसे मूल्यवान इन्फ़्रा टुकड़ा है और यह साधारण कोड है — हफ़्तों नहीं, दिनों का।

### 5. परतदार स्मृति
एक अविभेदित बातचीत इतिहास ही सबसे आम वजह है कि एजेंट रन बढ़ने के साथ बिगड़ता है। अलग कीजिए: लक्ष्य और शर्तें, जो कभी नहीं छँटतीं; हालिया मोड़ ज्यों के त्यों; पुराने मोड़ छोटी तथ्यात्मक नोट में; और लाया गया ज्ञान, प्रति कदम ताज़ा और कभी संचित नहीं।

### 6. इंसानी दरवाज़ा
हर अपरिवर्तनीय कार्रवाई एक स्पष्ट मंज़ूरी के पीछे रहती है, इतने संदर्भ के साथ कि इंसान सेकंडों में तय कर सके: क्या होगा, किस रिकॉर्ड पर, एजेंट इसे सही क्यों मानता है और मना करने पर वह क्या करेगा। दरवाज़ा सीमा नहीं, उत्पाद विशेषता है।

Q: क्या छहों पैटर्न चाहिए?
A: नहीं। सीमित लूप और टूल गेटवे से शुरू कीजिए; असली सिस्टम छूने वाली किसी भी चीज़ के लिए ये लगभग अनिवार्य हैं। इंसानी दरवाज़ा तब जब कोई अपरिवर्तनीय कार्रवाई आए।

Q: क्या समीक्षक चक्र सचमुच सटीकता बढ़ाता है?
A: जहाँ मॉडल संभावित पर बेबुनियाद जवाब दे सकता है, वहाँ स्पष्ट रूप से हाँ — ख़ासकर जब समीक्षक को प्रमाण देकर दावे जाँचने को कहा जाए।

Q: टूल गेटवे कहाँ रहे?
A: आपकी अपनी सेवा में, एजेंट और सिस्टम के बीच, जिसमें अंतिम उपयोगकर्ता की पहचान बहती हो। framework के भीतर हो तो अगले बदलाव पर दोबारा लिखना पड़ेगा।

## No-code प्लेटफ़ॉर्म या कस्टम निर्माण: एक ईमानदार तुलना
https://aiagentdevelopment.info/hi/guides/no-code-ya-custom-agent
2026-08-04 को अपडेट · Framework और मॉडल

- प्लेटफ़ॉर्म और कस्टम प्रतिद्वंद्वी नहीं, चरण हैं।
- प्रति-उपयोगकर्ता अनुमतियाँ, उत्पाद स्वामित्व और हैसियत कस्टम की ओर धकेलते हैं।
- प्रवाह प्लेटफ़ॉर्म पर साबित कीजिए, फिर केवल हक़ कमाने वाले हिस्से दोबारा बनाइए।
- Prompts, परिभाषाएँ और लॉग पहले दिन से निर्यात कीजिए।

No-code बनाम कस्टम की बहस अक्सर उन लोगों के बीच होती है जिनके पास बेचने को कुछ है। दोनों बनाकर हमारी राय ज़्यादा सादी और ज़्यादा उपयोगी है: ये प्रतिद्वंद्वी नहीं, चरण हैं — और ग़लती यह है कि सबूत जितना कहते हैं उससे ज़्यादा देर एक ही चरण में रहा जाए।

प्लेटफ़ॉर्म यह पता करने का सबसे सस्ता रास्ता है कि आपके काम को असल में क्या चाहिए। कस्टम वह तरीक़ा है जिससे यह जानने के बाद आप अनुमतियों, इकाई लागत और उत्पाद सतह का नियंत्रण लेते हैं।

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

### जल्दी निर्णय देने वाले चार सवाल
- क्या एजेंट को आंतरिक डेटा पर प्रति-उपयोगकर्ता अनुमति चाहिए? हाँ तो लगभग हमेशा कस्टम।
- क्या एजेंट उसका हिस्सा है जो आप बेचते हैं? हाँ तो कस्टम।
- महीने में कुछ हज़ार से ज़्यादा काम? प्रति-रन क़ीमत का गणित पहले कीजिए।
- क्या अपना मूल्यांकन सेट और ऑडिट ट्रेल चाहिए? पहले देखिए प्लेटफ़ॉर्म क्या निर्यात करता है।

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

### कस्टम की असली लागत
कस्टम केवल लूप नहीं है। यह टाइप और त्रुटि-अनुबंध वाली टूल परत, अनुमति जाँच, मूल्यांकन सेट, पढ़ी जा सकने वाली ट्रेस, तैनाती का रास्ता और वह मालिक है जो मॉडल प्रोवाइडर के संस्करण हटाने पर सँभाले। ग्राहक-सामना एजेंट के लिए दो से चार महीने का हमारा अनुमान यहीं से आता है।

### प्लेटफ़ॉर्म छोड़ने के संकेत
- आप सुविधाओं की जगह कनेक्टर के जुगाड़ लिख रहे हैं।
- प्रति-रन लागत बैठक में पूछी जाने वाली मद बन गई है।
- सुरक्षा समीक्षा रुकी है और प्लेटफ़ॉर्म जवाब नहीं दे सकता।
- आप एक व्यवहार बदलना चाहते हैं और बिल्डर में कह नहीं सकते।
- एजेंट ग्राहक अनुभव का हिस्सा है और आप उसे ठीक से टेस्ट नहीं कर सकते।

Q: क्या no-code स्थायी जवाब हो सकता है?
A: हाँ, आंतरिक, मानक, मध्यम हैसियत और कम जोखिम वाले कामों के लिए। बहुत सी उपयोगी ऑटोमेशन को कभी कोड प्रोजेक्ट नहीं बनना चाहिए।

Q: क्या कस्टम हमेशा ज़्यादा सटीक है?
A: नहीं। सटीकता टूल डिज़ाइन, आधार और मूल्यांकन से आती है, जो प्लेटफ़ॉर्म पर भी संभव है। कस्टम नियंत्रण और अर्थशास्त्र देता है।

Q: सबसे बड़ी छिपी लागत?
A: रखरखाव। मॉडल हटते हैं, API बदलते हैं, मूल्यांकन दोबारा चलाना पड़ता है। सालाना निर्माण लागत का 15–25% रखिए और एक मालिक तय कीजिए।

## Model Context Protocol: बनाने वालों के लिए व्याख्या
https://aiagentdevelopment.info/hi/guides/model-context-protocol-samjhein
2026-08-04 को अपडेट · Framework और मॉडल

- MCP एजेंट क्लाइंट और सर्वर के बीच टूल खोज व आह्वान मानकीकृत करता है।
- प्रमाणीकरण, अनुमति और मंज़ूरी आपके पास रहती है।
- संकीर्ण क्षमताएँ लपेटिए और अनुमतियाँ सर्वर में, हर कॉल पर लागू कीजिए।
- तीसरे पक्ष के सर्वर ऐसी निर्भरताएँ हैं जिनके विवरण आपके संदर्भ में घुसते हैं।

एक से ज़्यादा एजेंट बनाने वाली हर टीम वही अडैप्टर दो बार लिखती है: सिस्टम से जुड़ो, बताओ वह क्या कर सकता है, और वे क्षमताएँ मॉडल को उस रूप में दो जो आज का क्लाइंट चाहता है। Model Context Protocol इसी दोहराव को रोकने के लिए है — एजेंट क्लाइंट और टूल सर्वर के बीच इंटरफ़ेस मानकीकृत करके।

यह सचमुच उपयोगी है और उत्साह से संकीर्ण भी। MCP बताता है कि क्षमताएँ कैसे घोषित और बुलाई जाती हैं। यह नहीं बताता कि किसे बुलाने की अनुमति है — और इन दोनों को मिलाना ही सुरक्षा घटनाओं का स्रोत है।

### प्रोटोकॉल क्या मानकीकृत करता है
- खोज: सर्वर क्लाइंट को अपने टूल और संसाधन स्कीमा सहित बताता है।
- आह्वान: क्लाइंट टाइप किए आर्ग्युमेंट से टूल बुलाता है और संरचित नतीजा पाता है।
- संसाधन: केवल-पढ़ने वाली सामग्री जिसे क्लाइंट माँगने पर संदर्भ में लाता है।
- परिवहन: साझा प्रारूप ताकि अलग लोगों के लिखे क्लाइंट और सर्वर आपस में चलें।

### जो वह जान-बूझकर नहीं करता
MCP आपके उपयोगकर्ताओं को प्रमाणित नहीं करता, तय नहीं करता कि कौन कौन-से रिकॉर्ड पढ़ सकता है, और यह भी नहीं कि किसी कार्रवाई को मंज़ूरी चाहिए या नहीं। यह सब आपका है और सर्वर की ओर रहना चाहिए — विनम्रता से अनुमति माँगता क्लाइंट अनुमति-प्रणाली नहीं है। सबसे आम वास्तु-दोष है `run_query` जैसा चौड़ा टूल MCP पर खोल देना और prompt से उम्मीद रखना।
हर MCP टूल को ऐसे देखिए मानो कोई भ्रमित या बहकाया कॉलर उसे सबसे बुरे संभव आर्ग्युमेंट से बुलाएगा।

### आज कहाँ फ़ायदा है
| एक आंतरिक सिस्टम, कई एजेंट क्लाइंट | ऊँचा — सर्वर एक बार लिखिए |
| स्थानीय संदर्भ पढ़ते डेस्कटॉप असिस्टेंट | ऊँचा — पारिस्थितिकी इसी पर बनी |
| तीन अपने टूल वाला एक एजेंट | कम — सीधा फ़ंक्शन कॉल सरल है |
| आपके नियंत्रण से बाहर तीसरे पक्ष के टूल | मध्यम — सुविधाजनक, पर सर्वर जाँचिए |

### सुरक्षित रूप से अपनाने का तरीक़ा
- सामान्य शक्ति नहीं, संकीर्ण क्षमता लपेटिए: `sql(query)` नहीं, `get_order(id)`।
- अनुमति सर्वर के भीतर, हर कॉल पर और अंतिम उपयोगकर्ता की पहचान से लागू कीजिए।
- छोटी, ईमानदार त्रुटियाँ लौटाइए — `नहीं मिला`, `अनुमति नहीं`।
- हर आह्वान आर्ग्युमेंट और पहचान सहित दर्ज कीजिए; यही आपका ऑडिट ट्रेल है।
- जिन सर्वरों पर निर्भर हैं उन्हें समीक्षित संस्करण पर पिन कीजिए।

### आपूर्ति-शृंखला का सवाल
तीसरे पक्ष का MCP सर्वर वह कोड है जो आपके एजेंट को टूल बताता है और वे आर्ग्युमेंट पाता है जो आपका एजेंट भेजने का निर्णय करता है। टूल विवरण मॉडल के संदर्भ का हिस्सा हैं, इसलिए दुर्भावनापूर्ण या लापरवाह विवरण व्यवहार बदल सकता है। अपनाने से पहले सर्वर पढ़िए और अविश्वसनीय सर्वर संवेदनशील पहुँच वाले क्लाइंट से दूर रखिए।

Q: क्या एजेंट बनाने के लिए MCP ज़रूरी है?
A: नहीं। कुछ अपने टूल वाले एक एजेंट के लिए सीधा फ़ंक्शन कॉल सरल है। MCP तब फ़ायदा देता है जब वही क्षमता कई क्लाइंट से चाहिए।

Q: क्या MCP डिफ़ॉल्ट रूप से सुरक्षित है?
A: यह परिवहन और खोज का मानक है, सुरक्षा मॉडल नहीं। प्रमाणीकरण, उपयोगकर्ता-आधारित अनुमति और मंज़ूरी दरवाज़े आप सर्वर पर लागू करते हैं।

Q: क्या MCP सर्वर इंजेक्शन का रास्ता बन सकते हैं?
A: हाँ — संदर्भ में जाते टूल विवरण से भी और लौटी सामग्री से भी। सर्वर आउटपुट को अविश्वसनीय मानिए और दायरा संकीर्ण रखिए।

## अपने एजेंट के लिए मॉडल चुनना: क्षमता, विलंब और लागत
https://aiagentdevelopment.info/hi/guides/agent-ke-liye-model-chunna
2026-08-04 को अपडेट · Framework और मॉडल

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

लोग पूछते हैं कि एजेंटों के लिए सबसे अच्छा मॉडल कौन-सा है। जो सवाल अच्छा सिस्टम बनाता है वह है: इस कदम के लिए, हमारे डेटा पर, हमारे विलंब बजट में सबसे अच्छा मॉडल कौन-सा है — और जवाब आमतौर पर एक से ज़्यादा होता है।

एक एजेंट रन एकरूप नहीं होता। अगली कार्रवाई तय करने में तर्क चाहिए। लौटे दस्तावेज़ से तीन फ़ील्ड निकालने में नहीं। उपयोगकर्ता के लिए नतीजा संक्षेप करने में भी नहीं। सबको एक ही ख़रीद निर्णय मानना ही वह तरीक़ा है जिससे टीमें JSON दोबारा सजाने के लिए सबसे ऊँची क़ीमत चुकाती हैं।

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

### बेंचमार्क शॉर्टलिस्ट बनाते हैं, निर्णय नहीं
सार्वजनिक बेंचमार्क बताते हैं कि कौन-से मॉडल संभव हैं। वे यह नहीं बताते कि आपके स्कीमा, आपके दस्तावेज़ रूप और आपके कठिन ग्राहकों को कौन सँभालेगा। अपने लॉग से तीस असली मामले बनाइए — वे पाँच भी जो शर्मिंदा करते हैं — और शॉर्टलिस्ट उन पर चलाइए।
ऐसे मामले भी रखिए जहाँ सही व्यवहार मना करना या सवाल पूछना है। मॉडल यह जानने में ज़्यादा अलग होते हैं कि कब रुकना है।

### तीन सचमुच बाँधने वाली सीमाएँ
- विलंब की न्यूनतम सीमा: हर कॉल की अपनी है और एजेंट कई करता है। पूरा रन मापिए।
- संरचित आउटपुट की विश्वसनीयता: 97% वैध आर्ग्युमेंट तीन कॉल वाले हर दसवें रन को तोड़ देते हैं।
- संदर्भ व्यवहार: लंबा संदर्भ महँगा है और ध्यान कमज़ोर करता है; असली लंबाई पर मापिए।

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

### बंद होने की योजना पहले से
मॉडल संस्करण प्रोवाइडर के कैलेंडर पर हटते हैं। दो आदतें इसे मामूली बना देती हैं: चलायमान उपनाम की जगह स्पष्ट संस्करण पिन कीजिए, और मूल्यांकन सेट को एक कमांड से चलने लायक रखिए ताकि पुनः-योग्यता एक दोपहर हो, प्रोजेक्ट नहीं।

Q: क्या हर जगह सबसे बड़ा मॉडल?
A: तभी अगर आपने मापा नहीं। निर्णय कदम को अक्सर फ़ायदा होता है; निष्कर्षण, वर्गीकरण और स्वरूपण को कम ही। कदम-वार बाँटना सबसे आसान लागत-कटौती है।

Q: क्या ओपन-वेट मॉडल काम करते हैं?
A: सख़्त स्कीमा वाले संकीर्ण कदमों पर अक्सर हाँ, और हैसियत पर अर्थशास्त्र आकर्षक है। खुले-अंत नियोजन में उन्हें ज़्यादा ढाँचा चाहिए।

Q: मॉडल चुनाव कितनी बार दोबारा देखें?
A: जब भी अपनाने लायक संस्करण आए, वरना लगभग हर दो तिमाही। यह तभी टिकाऊ है जब मूल्यांकन एक कमांड हो।

## एजेंट ऑर्केस्ट्रेशन: कब ज़रूरी है और कब बोझ
https://aiagentdevelopment.info/hi/guides/agent-orchestration-kab-chahiye
2026-08-04 को अपडेट · Framework और मॉडल

- ऑर्केस्ट्रेशन टिकाऊपन, निष्क्रियता, शाखाएँ और पुनःआरंभ ख़रीदता है।
- पूछिए कि आधा-विफल रन दोहराने की क़ीमत क्या है।
- क़तार, स्थिति पंक्ति और निष्क्रियता कुंजियाँ अधिकांश लाभ सस्ते में देती हैं।
- Prompts और स्कीमा प्रवाह परिभाषाओं से बाहर रखें।

ऑर्केस्ट्रेशन लाइब्रेरियाँ एक असली समस्या हल करती हैं: ऐसा रन जो मिनटों चलता है, कई सिस्टम छूता है और प्रक्रिया पुनः आरंभ होने पर पहले किए भुगतान को दोहराए बिना बचना चाहिए। यह असली है और हाथ से हल करना अप्रिय।

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

### ऑर्केस्ट्रेशन असल में क्या देता है
- टिकाऊ स्थिति: रन डिप्लॉय, क्रैश या स्केल-डाउन झेल जाता है।
- निष्क्रिय-दोहराव योग्य कदम: दोबारा चला कदम पहले हो चुका प्रभाव नहीं दोहराता।
- शाखाएँ और संगम: असली नियंत्रण प्रवाह, उसे बताने वाला prompt नहीं।
- पुनःआरंभ: चार घंटे बाद आने वाली इंसानी मंज़ूरी के लिए ठहराव।
- निर्माण से ही अवलोकनीयता: हर कदम स्थिति वाला वस्तु है।

### निर्णायक परीक्षण
एक सवाल: अगर यह रन आधे में मर जाए, तो दोबारा शुरू करने की क़ीमत क्या होगी? अगर कुछ पैसे और कुछ सेकंड, तो दोबारा शुरू कीजिए — आपको टिकाऊपन नहीं, रीट्राई चाहिए। अगर दोहरा रिफ़ंड, ग्राहक को दूसरा ईमेल या किसी व्यक्ति के बीस मिनट, तो आपको टिकाऊ और निष्क्रिय-दोहराव योग्य कदम चाहिए।
अधिकतर टीमें अपना जवाब तब जानती हैं जब पहली बार कोई डिप्लॉय रन के बीच आता है। पहले तय करना सस्ता है।

### जटिलता कहाँ दिखती है
| स्थानीय विकास | फ़ाइल चलाइए | साथ में वर्कर और स्थिति भंडार |
| डीबगिंग | एक सीधी ट्रेस | रन इतिहास में कदम जोड़िए |
| रन के बीच डिप्लॉय | रन मर जाता है | रन जारी रहता है |
| इंसानी मंज़ूरी | बेढंगा; अक्सर नया अनुरोध | प्रथम-श्रेणी ठहराव और पुनःआरंभ |
| कदम 3 के बग की क़ीमत | सब दोबारा | केवल कदम 3 दोबारा |

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

### अगर अपनाते हैं
- एजेंट तर्क — prompts, स्कीमा, रुकने के नियम — प्रवाह परिभाषाओं से बाहर रखें।
- हर कदम निष्क्रिय-दोहराव योग्य बनाइए, चाहे framework ठीक-एक-बार का वादा करे।
- कुल लागत ऑर्केस्ट्रेशन परत पर सीमित कीजिए, केवल लूप में नहीं।
- ट्रेस ऐसे प्रारूप में निर्यात कीजिए जिसे वेंडर कंसोल के बिना पढ़ सकें।

Q: क्या सरल चैट-शैली एजेंट के लिए ऑर्केस्ट्रेशन ले सकते हैं?
A: ले सकते हैं और चलेगा, पर रोज़ स्थानीय विकास की रगड़ और अप्रत्यक्ष डीबगिंग की क़ीमत चुकाएँगे उस लाभ के लिए जिसका दावा कम ही करेंगे।

Q: क्या मैसेज क़तार काफ़ी है?
A: अक्सर हाँ। क़तार, प्रति रन स्थिति पंक्ति और निष्क्रियता कुंजियाँ आम विफलताएँ ढँक देती हैं। असली शाखाएँ, संगम या घंटों के ठहराव चाहिए तब ऊपर बढ़िए।

Q: वितरित रन डीबग करने योग्य कैसे रखें?
A: हर लॉग पंक्ति, कॉल और बाहर जाने वाले अनुरोध पर स्थिर रन पहचानकर्ता, और हर कदम पर भेजा गया सटीक संदर्भ संग्रहित करके।

## एजेंट framework चुनना: असल में क्या मायने रखता है
https://aiagentdevelopment.info/hi/guides/agent-framework-kaise-chunein
2026-08-04 को अपडेट · Framework और मॉडल

- रैंकिंग जल्दी पुरानी होती है; उपयुक्तता तय करने वाले सवाल नहीं।
- तीन सौदे: प्रोवाइडर SDK, ऑर्केस्ट्रेशन लाइब्रेरी, प्रबंधित प्लेटफ़ॉर्म।
- Prompts, स्कीमा, मूल्यांकन और ट्रेस प्रारूप अपने रिपॉज़िटरी में रखें।
- वही छोटा एजेंट दो बार बनाइए और डीबग-सुविधा मापिए, सटीकता नहीं।

नाम से framework की रैंकिंग करने वाला हर लेख इंडेक्स होने से पहले पुराना हो जाता है। इस क्षेत्र की लाइब्रेरियाँ हर कुछ रिलीज़ में अपने मूल अमूर्तन दोबारा लिखती हैं, और आज तुलना में सबसे आगे दिखने वाली आपके लॉन्च तक बदल चुकी हो सकती है।

इसलिए यह गाइड कुछ अधिक टिकाऊ करती है: वे आठ सवाल गिनाती है जो तय करते हैं कि छह महीने बाद भी आप अपने चुनाव से ख़ुश रहेंगे या नहीं, और बताती है कि हर उत्तर की क़ीमत क्या है।

### आठ सवाल, महत्व के क्रम में
- क्या मैं लूप पढ़ सकता हूँ? जिस फ़ाइल में मॉडल आउटपुट टूल कॉल बनता है, वह न मिले तो बुरा रन डीबग नहीं होगा।
- टूल विफलता पर क्या होता है — वह मुझ तक आती है या अलग prompt के साथ अदृश्य रूप से दोहराई जाती है?
- क्या मेरा prompt framework का prompt है? जो सिस्टम टेक्स्ट आपने नहीं लिखा, वह ऑडिट में चौंकाएगा।
- स्थिति सहेजी और फिर से शुरू की जा सकती है, या क्रैश रन खो देता है?
- टूल कैसे परिभाषित होते हैं और क्या वे परिभाषाएँ बाहर पुनः उपयोग हो सकती हैं?
- अपग्रेड की कहानी क्या है — पिछली दो रिलीज़ में मूल अमूर्तन का नाम बदला?
- क्या framework बदले बिना मॉडल बदल सकता हूँ?
- कोल्ड स्टार्ट और हर मोड़ में यह कितना जोड़ता है?

### तीन श्रेणियाँ, तीन अलग सौदे
| प्रोवाइडर SDK और अपना लूप | पूरी दृश्यता, कम निर्भरताएँ | रीट्राई, स्थिति, स्थायित्व आप लिखते हैं | एक एजेंट, कम टूल, ज़्यादा डीबगिंग |
| ऑर्केस्ट्रेशन लाइब्रेरी | टिकाऊ स्थिति, शाखाएँ, रीट्राई, पुनःआरंभ | कुछ दृश्यता; अपग्रेड की हलचल | लंबे या बहु-चरणीय प्रवाह |
| प्रबंधित प्लेटफ़ॉर्म | होस्टिंग, ट्रेसिंग, मूल्यांकन, UI | पोर्टेबिलिटी; प्रति सीट या रन शुल्क | छोटी टीम, मानक काम, तेज़ प्रमाण |

### जो आपका रहना चाहिए, वह ख़ुद लिखिए
चाहे कुछ भी चुनें, चार चीज़ें आपके अपने रिपॉज़िटरी में ऐसे रूप में रहनी चाहिए जिसका मालिक कोई framework न हो: prompts, टूल परिभाषाएँ और उनके JSON स्कीमा, मूल्यांकन सेट और ट्रेस प्रारूप। यही वे चीज़ें हैं जिन्हें ठीक करने में असली मेहनत लगी। सादे डेटा और पतले अडैप्टर के रूप में हों तो framework बदलना एक दिन का काम है; डेकोरेटर और वंशानुक्रम के रूप में हों तो दोबारा लिखना।

### वह परीक्षण जो कोई नहीं करता
तय करने से पहले वही छोटा एजेंट दो बार बनाइए: एक बार अपनी पसंद से, एक बार प्रोवाइडर SDK और हाथ से लिखे लूप से। वही तीन टूल, वही दस टेस्ट। आप सटीकता नहीं माप रहे — वह समान रहेगी। आप माप रहे हैं कि कितना समय लगा, ट्रेस कितनी पठनीय है और सातवाँ मामला क्यों विफल हुआ यह पता करना कितना आसान था।
हाथ से लिखा संस्करण रखिए। जब यह साबित करना हो कि कोई विचित्रता आपके prompt से आई या framework से, तब वही आपका संदर्भ बनेगा।

### संकेत कि आप अपने चुनाव से आगे निकल चुके हैं
- आप अपने कोड से ज़्यादा framework का स्रोत पढ़ते हैं।
- किसी व्यवहार के लिए पैच या फ़ोर्क बनाए रखते हैं।
- नाम बदलने के कारण अपग्रेड टलते हैं और आप दो बड़े संस्करण पीछे हैं।
- आधा prompt इंजेक्ट किए टेक्स्ट को काटने के लिए है।
- ट्रेसिंग के लिए अपना एक्सपोर्टर चाहिए क्योंकि अंतर्निहित आर्ग्युमेंट छिपाता है।

Q: पहले एजेंट के लिए framework चाहिए?
A: नहीं। तीन टूल वाला पहला एजेंट एक लूप, स्कीमा सूची और रुकने की शर्त है। एक बार हाथ से बनाना सिखाता है कि framework आपके लिए क्या करता।

Q: क्या प्रबंधित प्लेटफ़ॉर्म जाल है?
A: नहीं, अगर prompts, स्कीमा और मूल्यांकन पोर्टेबल रखें। जोखिम प्लेटफ़ॉर्म नहीं, यह है कि आपकी बौद्धिक पूँजी केवल वहीं कॉन्फ़िगरेशन के रूप में बचे।

Q: सटीकता पर framework का कितना असर?
A: सोचे से बहुत कम। सटीकता टूल डिज़ाइन, आधार और मूल्यांकन से आती है। Framework विकास गति, डीबगिंग और संचालन सुविधाओं को प्रभावित करते हैं।

## कब AI एजेंट न लें (और उसकी जगह क्या बनाएँ)
https://aiagentdevelopment.info/hi/guides/kab-ai-agent-na-lein
2026-08-04 को अपडेट · एजेंट की बुनियाद

- तय क्रम को एजेंट नहीं, मॉडल-कदम वाली पाइपलाइन चाहिए।
- गणित, ठीक मिलान और सेकंड-से-कम विलंब — तीनों ग़लत मेल हैं।
- मूल्यांकन सेट के बिना बदलाव का फ़ायदा पता नहीं चलेगा: पहले बीस उदाहरण।
- अपरिवर्तनीय, ऊँचे मूल्य की कार्रवाइयाँ इंसानी दरवाज़े के पीछे; एजेंट मसौदा लिखे।

हम एजेंट बनाकर कमाते हैं, और यह पन्ना ठीक इसीलिए है। किसी टीम का इस तकनीक पर भरोसा तोड़ने का सबसे तेज़ रास्ता है ऐसे काम पर एजेंट लगाना जिसे उसकी ज़रूरत नहीं थी, उसे 94% सही होते देखना जहाँ स्क्रिप्ट 100% सही थी, और अगली तिमाही उसका बचाव करते बिताना।

नीचे वे छह स्थितियाँ हैं जहाँ हम मना करते हैं, और उनकी जगह क्या सुझाते हैं। इनमें से कोई भी मॉडल की क्षमता पर टिप्पणी नहीं है; ये उन जगहों की बात हैं जहाँ अनिश्चितता लाभ नहीं, लागत है।

### 1. कदम कभी नहीं बदलते
अगर क्रम तय है — फ़ाइल लाओ, कॉलम जाँचो, बदलो, लोड करो, सूचित करो — तो अगला कदम तय करने के लिए किसी की ज़रूरत नहीं, क्योंकि कोई तय कर ही नहीं रहा। पाइपलाइन लिखिए। अगर किसी एक कदम में विवेक चाहिए, जैसे मुक्त-पाठ फ़ील्ड का वर्गीकरण, तो उसी कदम के लिए मॉडल बुलाइए और बाकी नियतात्मक रखिए।
यही सबसे आम ज़रूरत से ज़्यादा निर्माण है। पाइपलाइन के भीतर मॉडल कॉल एजेंट से कमतर नहीं — वही सही चीज़ है।

### 2. काम गणित या ठीक मिलान का है
जोड़, मिलान, कर, प्रकाशित सीमाओं वाले पात्रता नियम: इनके सही उत्तर और मौजूदा कार्यान्वयन हैं। मॉडल गणना बहुत सुंदर समझा सकता है और फिर भी कभी-कभी ग़लत हो सकता है, और वित्त में कभी-कभी विपत्ति है। कोड में गणना कीजिए, फिर मॉडल से समझवाइए।

### 3. एक सेकंड से कम का विलंब बजट
जो एजेंट योजना बनाकर दो टूल बुलाकर जवाब देता है, वह भरोसे से एक सेकंड में नहीं कर पाएगा, क्योंकि हर मॉडल कॉल की अपनी न्यूनतम देरी है। चेकआउट, टाइप-करते-समय खोज या कॉल राउटिंग में काम को क्रिटिकल पथ से हटाइए या क्लासिफ़ायर और लुकअप लगाइए।

### 4. सही रन कैसा दिखता है, कोई नहीं बता सकता
अगर टीम काम के सही ढंग से हुए बीस उदाहरण नहीं दे सकती, तो आपके पास मूल्यांकन सेट नहीं है — और उसके बिना यह जानने का कोई तरीक़ा नहीं कि बदलाव से फ़ायदा हुआ। पहले उदाहरण बनाइए। अक्सर लिखते ही पता चलता है कि यह असल में तीन काम हैं।
बीस लेबल किए उदाहरण जान-बूझकर नीची सीमा है। न पहुँच पाना बताता है कि काम अभी समझा ही नहीं गया।

### 5. हर कार्रवाई अपरिवर्तनीय और ऊँचे मूल्य की है
बैंक ट्रांसफ़र, अनुबंध पर हस्ताक्षर, प्रोडक्शन में डिलीट। आप इनके आगे एजेंट रख सकते हैं — ऐसे मसौदाकार के रूप में जो मामला जोड़कर इंसान को सौंपे। जो नहीं करना चाहिए वह है स्वायत्त लूप को अपरिवर्तनीय चीज़ पर बिना निगरानी लिखने की अनुमति देना।

### 6. जिस डेटा की ज़रूरत है वह पहुँच में नहीं
एजेंट उतना ही सक्षम है जितने उसके टूल, और टूल उतने ही जितनी आपकी API। अगर जानकारी बिना रीड API वाले सिस्टम में या तीन लोगों द्वारा हाथ से संपादित शीट में है, तो एजेंट अनुमान लगाने तक सिमट जाएगा। पहले पहुँच ठीक कीजिए। यह काम बेरौनक़ है और अधिकांश मूल्य वहीं है।

Q: तो एजेंट स्पष्ट रूप से सही औज़ार कब है?
A: जब अगला कदम सचमुच पिछले के नतीजे पर निर्भर हो, जब कई टूल ऐसे क्रम में चाहिए हों जिसे पहले से तय न किया जा सके, और जब आज कोई इंसान यही काम देखकर और तय करके करता हो।

Q: हमने तय पाइपलाइन के लिए पहले ही एजेंट बना लिया। हटाएँ?
A: ज़रूरी नहीं — पहले मापिए। भरोसेमंद है और लागत ठीक है तो रहने दीजिए। तब बदलिए जब कोई ठोस तकलीफ़ बता सकें।

Q: क्या एजेंट किसी नियतात्मक सिस्टम का हिस्सा हो सकता है?
A: हाँ, और अक्सर यही सबसे अच्छा डिज़ाइन है। रीढ़ नियतात्मक रखिए और एजेंट को एक सीमित क्षेत्र दीजिए जहाँ विवेक चाहिए।

## AI एजेंट के प्रकार: पाँच रूप जो लगभग सब कुछ ढँकते हैं
https://aiagentdevelopment.info/hi/guides/ai-agent-ke-prakar
2026-07-28 को अपडेट · एजेंट की बुनियाद

- पाँच रूप: उत्तरदाता, एकल लूप, योजनाकार–निष्पादक, राउटर, सहयोगी एजेंट।
- हर ऊपरी पायदान क्षमता के बदले ट्रेस-सुविधा और लागत ख़र्च करता है।
- प्रोडक्शन के अधिकतर एजेंट तीन से छह टूल वाले एकल लूप हैं।
- ऊपर तभी चढ़ें जब ट्रेस सरल रूप की संरचनात्मक विफलता साबित करे।

अकादमिक वर्गीकरण — रिफ़्लेक्स, मॉडल-आधारित, लक्ष्य-आधारित, उपयोगिता-आधारित — परीक्षाओं में काम आते हैं और सोमवार को क्या बनाना है, यह तय करने में लगभग नहीं। व्यवहार में मायने रखता है नियंत्रण प्रवाह का रूप, क्योंकि वही लागत, विलंब और डीबग करने की कठिनाई तय करता है।

पाँच रूप हमारे बनाए या समीक्षित लगभग हर एजेंट को ढँक लेते हैं। ये एक जटिलता की सीढ़ी बनाते हैं, और सबसे आम महँगी ग़लती ज़रूरत से दो पायदान ऊपर से शुरू करना है।

### पाँच रूप, सस्ते से कठिन तक
| टूल-सहित उत्तरदाता | एक कॉल, शायद एक टूल | खोज, संवर्धन, वर्गीकरण | मुश्किल से एजेंट; ठीक है |
| एकल-लूप एजेंट | मॉडल छोटे टूल सेट पर घूमता है | सपोर्ट, शोध, त्रयाज | लंबे कामों में भटकाव |
| योजनाकार–निष्पादक | योजना, निष्पादन, विफलता पर पुनर्योजना | बहु-चरणीय संचालन, माइग्रेशन | तीसरे कदम के बाद बासी योजना |
| राउटर और विशेषज्ञ | राउटर संकीर्ण उप-एजेंट चुनता है | भिन्न कौशल वाले बड़े क्षेत्र | राउटिंग त्रुटियाँ जुड़ती जाती हैं |
| सहयोगी एजेंट | कई एजेंट नतीजे साझा करते हैं | सचमुच समानांतर शोध या समीक्षा | लागत, विलंब, न ट्रेस होने वाली विफलताएँ |

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

### कौन-सा पायदान चाहिए
- एक खोज और एक निर्णय: टूल-सहित उत्तरदाता।
- टूल कम हों और क्रम बदलता हो: एक लूप।
- इंसान पहले चेकलिस्ट लिखता: योजनाकार–निष्पादक।
- काम अलग-अलग विशेषज्ञताओं में बँटता हो: राउटर।
- दो उप-कार्य सचमुच स्वतंत्र और दोनों धीमे: सहयोग सार्थक हो सकता है।

### विशेषज्ञ का जाल
राउटर आरेख में साफ़-सुथरे दिखते हैं और किनारों पर ख़राब व्यवहार करते हैं। राउटर केवल अनुरोध देखता है, यह नहीं कि विशेषज्ञ क्या पाते — उसे अंदाज़ा लगाना पड़ता है। दो उपाय काम आते हैं: विशेषज्ञ को `मेरा क्षेत्र नहीं` लौटाने दें और एक बार दोबारा राउट करें, और विशेषज्ञों की संख्या इतनी कम रखें कि राउटर prompt हर एक को एक स्पष्ट वाक्य में बता सके।
राउटिंग सटीकता अलग से मापें। 95% सटीक विशेषज्ञों के आगे 90% राउटर अंत-से-अंत 85% देता है।

### रूप और लागत, ईमानदारी से
लागत आरेख के संकेत से तेज़ बढ़ती है। एकल लूप कुछ मॉडल कॉल लेता है। योजनाकार–निष्पादक एक योजना कॉल और अक्सर एक पुनर्योजना जोड़ता है। राउटर कुछ भी उपयोगी होने से पहले एक कॉल जोड़ता है। सहयोगी एजेंट गुणा करते हैं। यह ऊँचे रूपों से बचने का कारण नहीं, बल्कि उन तक जान-बूझकर और आँकड़े सामने रखकर पहुँचने का कारण है।

Q: क्या मल्टी-एजेंट सिस्टम एक एजेंट से बेहतर हैं?
A: तभी जब उप-कार्य सचमुच स्वतंत्र हों और हर एक को अलग टूल या मॉडल स्तर चाहिए। वरना आपने विलंब, टोकन और मुश्किल से ट्रेस होने वाली विफलता सतह ख़रीदी है।

Q: प्रोडक्शन में सबसे आम रूप कौन-सा है?
A: तीन से छह टूल वाला एकल-लूप एजेंट, जिसमें न पलटने वाली कार्रवाइयों पर इंसानी दरवाज़ा हो।

Q: पायदान कब बढ़ाएँ?
A: जब आपके पास ऐसी असली विफलता की ट्रेस हो जिसे सरल रूप संरचनात्मक रूप से हल नहीं कर सकता — एक बार की चूक नहीं, पूरी श्रेणी।

## AI एजेंट कैसे काम करते हैं: लूप, कदम दर कदम
https://aiagentdevelopment.info/hi/guides/ai-agent-kaise-kaam-karte-hain
2026-07-28 को अपडेट · एजेंट की बुनियाद

- एक मोड़: संदर्भ बनाओ, तय करो, जाँचो, चलाओ, दर्ज करो, रुकने की शर्तें देखो।
- मॉडल केवल वही देखता है जो आप वापस रखते हैं — अजीब व्यवहार अक्सर छँटाई से आता है।
- टूल त्रुटियाँ अमल करने लायक निर्देश की तरह लिखें।
- ट्रेस मुख्य डीबगिंग औज़ार है; दूसरी सुविधा से पहले बनाएँ।

डेमो में एजेंट जादू लगते हैं और प्रोडक्शन में प्लंबिंग। वजह यह है कि दिलचस्प हिस्सा मॉडल का आउटपुट नहीं, उसे खपाने वाला लूप है — और वह लूप एक बैठक में पढ़ लेने लायक छोटा है।

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

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

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

### योजना: स्पष्ट या स्वतःस्फूर्त
दो सम्मानजनक तरीके हैं। स्वतःस्फूर्त योजना बिना योजना-दस्तावेज़ के एक-एक कदम चुनती है — सरल, मज़बूत, लंबे कामों में भटकने वाली। स्पष्ट योजना पहले क्रमांकित योजना माँगती है, फिर कदम चलाती है और किसी कदम के विफल होने पर ही दोबारा योजना बनाती है। स्पष्ट योजना जाँचने और उपयोगकर्ता को दिखाने में आसान है, पर तीसरे कदम पर हक़ीक़त हटते ही भंगुर हो जाती है।

### रुकना: वह हिस्सा जो डेमो कभी नहीं दिखाते
| कदम सीमा | 8–15 टूल कॉल | आंशिक काम व्याख्या सहित लौटाएँ |
| ख़र्च सीमा | प्रति रन तय लागत | रुकें और समीक्षा के लिए दर्ज करें |
| घड़ी | इंटरैक्टिव में 30–120 सेकंड | जो पता है उसके साथ सौंपें |
| दोहराव पहचान | वही कॉल और आर्ग्युमेंट दो बार | दूसरी शाखा पर ज़ोर दें या रुकें |
| इंसानी दरवाज़ा | हर न पलटने वाली कार्रवाई | रोकें और मंज़ूरी माँगें |

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

Q: रुकने से पहले एजेंट कितने कदम ले?
A: इंटरैक्टिव कामों में आठ से बारह टूल कॉल की सीमा लगभग हर वैध स्थिति ढँक लेती है; उससे ज़्यादा माँगने वाला रन अक्सर अटका होता है। बैच काम ऊपर जा सकते हैं, पर साथ में ख़र्च सीमा रखें।

Q: पहले योजना या कदम-दर-कदम निर्णय?
A: छोटे काम कदम-दर-कदम ठीक चलते हैं। जब कोई काम नियमित रूप से पाँच कदम पार करे, स्पष्ट योजना रन को जाँचने योग्य बनाती है और प्रगति दिखाने देती है; विफलता पर दोबारा योजना बनाएँ।

Q: मेरा एजेंट वही विफल कॉल क्यों दोहराता है?
A: लगभग हमेशा इसलिए कि त्रुटि संदेश में अमल करने लायक कुछ नहीं होता। छोटे, स्पष्ट संदेश लौटाएँ और दोहराव पहचान जोड़ें।

## AI एजेंट या चैटबॉट: आपकी समस्या को असल में क्या चाहिए
https://aiagentdevelopment.info/hi/guides/ai-agent-ya-chatbot
2026-07-21 को अपडेट · एजेंट की बुनियाद

- चैटबॉट जवाब देते हैं; एजेंट बातचीत के बाहर सिस्टम बदलते हैं।
- यह अंतर बजट, टेस्टिंग और मंज़ूरी का दायरा तय करता है।
- सफल रचनाएँ अक्सर मिश्रित होती हैं: retrieval जवाब और दो-तीन चुने हुए टूल।
- उपयोगकर्ता चैटबॉट से जो माँगते और नहीं पाते, वही आपका टूल रोडमैप है।

एजेंट माँगने वाली ज़्यादातर टीमें असल में चैटबॉट बताती हैं, और चैटबॉट माँगने वाली कई टीमें एजेंट। लेबल मायने रखता है क्योंकि टेक्स्ट बॉक्स से आगे इन दोनों में लगभग कुछ भी साझा नहीं: अलग विफलताएँ, अलग टेस्ट, अलग मंज़ूरियाँ, अलग लागत वक्र।

सीमा-रेखा सरल है। क्या सॉफ़्टवेयर को बातचीत के बाहर कुछ बदलना है? नहीं — वह समझाता है, संक्षेप देता है, मसौदा बनाता है, जानकारी लाता है — तो आपको चैटबॉट चाहिए, संभवतः retrieval के साथ, और आप कुछ हफ़्तों में लाइव होंगे। हाँ — वह बुकिंग करता है, रिफ़ंड देता है, अपडेट करता है, भेजता है — तो आपको एजेंट चाहिए और महीनों में योजना बनानी होगी, क्योंकि असली काम अनुमतियों और रिकवरी रास्तों में है, जवाबों में नहीं।

### ईमानदार तुलना
| क्या बनाता है | पढ़ने के लिए टेक्स्ट | सिस्टम में बदलाव, साथ में टेक्स्ट |
| सबसे बुरी वास्तविक विफलता | ग़लत जवाब जिस पर कोई अमल कर ले | पहले ही हो चुकी ग़लत कार्रवाई |
| टेस्टिंग | प्रश्न सेट पर जवाब की गुणवत्ता | पूरी कोशिश में नतीजे की सत्यता |
| सामान्य निर्माण समय | 2–6 सप्ताह | प्रोडक्शन तक 2–4 महीने |
| मंज़ूरी किसकी | कंटेंट और सपोर्ट | साथ में सुरक्षा, डेटा और सिस्टम मालिक |
| चालू लागत | टोकन और कंटेंट रखरखाव | इंटीग्रेशन बहाव और eval रखरखाव |

### संकेत कि आपको चैटबॉट चाहिए
- उपयोगी आउटपुट कोई व्याख्या, सारांश या मसौदा है जिसे इंसान देखेगा।
- आपका ज्ञान आपकी प्रक्रियाओं से ज़्यादा बार बदलता है।
- ऐसी कोई API नहीं जिसमें सॉफ़्टवेयर को लिखने देना आपको सहज लगे।
- मूल्य यह है कि आसान टिकट इंसान तक कम पहुँचें।

### संकेत कि आपको एजेंट चाहिए
- जवाब पढ़ने वाला फिर किसी और सिस्टम में पाँच क्लिक करता है।
- अगला कदम जानने के लिए पहले कुछ देखना पड़ता है।
- सफलता का मतलब पूरा हुआ लेन-देन है, संतुष्ट पाठक नहीं।
- कोई इंसान पहले से चेकलिस्ट पर चलता है और वह चेकलिस्ट शाखाओं में बँटती है।

### वह मिश्रण जो अक्सर जीतता है
असली उपयोगकर्ताओं से टकराकर जो बचता है वह शायद ही कभी शुद्ध होता है: ऐसा चैटबॉट जो दो-तीन सावधानी से चुने टूल कॉल कर सके, और हर न पलटने वाली चीज़ के आगे इंसानी दरवाज़ा हो। retrieval आधारित जवाबों से तेज़ मूल्य मिलता है और आप ठीक वही कार्रवाइयाँ जोड़ते हैं जो सबसे ज़्यादा क्लिक हटाती हैं।
पहले चैटबॉट को मापें: लोग जो माँगते हैं और वह नहीं कर पाता, उसे लॉग करें। वही लॉग आपका टूल रोडमैप है, कल्पना से नहीं माँग से क्रमित।

### सिर्फ़ कोड नहीं, टीम भी बदलती है
एजेंट ज़िम्मेदारी बदल देता है। ग़लत चैटबॉट जवाब कंटेंट की समस्या है। ग़लत एजेंट कार्रवाई एक ऑपरेशनल घटना है और उस सिस्टम के मालिक की है जिसे उसने छुआ — और वह टीम ठीक ही ऑडिट ट्रेल, पलटने का रास्ता और प्रति घंटा कितना ग़लत हो सकता है, उसकी सीमा माँगेगी। इन बातचीतों को शुरुआत में बजट करें।

Q: क्या बाद में चैटबॉट को एजेंट बना सकते हैं?
A: हाँ, और यही आमतौर पर सबसे सस्ता रास्ता है। retrieval परत, लॉगिंग और prompt संपत्तियों को जवाब लूप से अलग रखें, फिर मंज़ूरी दरवाज़े के साथ एक-एक टूल जोड़ें।

Q: क्या चैटबॉट हमेशा सस्ता है?
A: प्रति अनुरोध लगभग हमेशा हाँ, क्योंकि एजेंट कई मॉडल कॉल करता है। प्रति नतीजा अक्सर नहीं: अगर एजेंट ऐसा काम पूरा करता है जिसमें आठ मिनट स्टाफ़ समय लगता, तो अतिरिक्त टोकन मामूली हैं।

Q: नियमन वाले कारोबार में कौन ज़्यादा जोखिम भरा है?
A: स्पष्ट रूप से एजेंट, क्योंकि वह कार्रवाई करता है। इसका मतलब यह नहीं कि उसे छोड़ दें — मतलब यह कि मंज़ूरी दरवाज़े, ऑडिट लॉग और पलटने के रास्ते निर्माण का हिस्सा हैं, बाद का चरण नहीं।

## AI एजेंट क्या है? बनाने वालों के लिए काम की परिभाषा
https://aiagentdevelopment.info/hi/guides/ai-agent-kya-hai
2026-07-21 को अपडेट · एजेंट की बुनियाद

- AI एजेंट तय करता है, असली टूल से काम करता है, नतीजा देखता है और फिर तय करता है।
- इंजीनियरिंग लूप और टूल अनुबंधों में है; मॉडल उसका एक घटक भर है।
- तय क्रम वर्कफ़्लो हैं — सस्ते, अधिक पूर्वानुमेय और अक्सर सही उत्तर।
- स्वायत्तता प्रति कार्रवाई है: केवल मसौदा, केवल पलटने योग्य, सैंडबॉक्स या बिना रोक।

"एजेंट" शब्द को इतना खींचा जा चुका है कि इसमें एक अच्छे नाम वाला prompt भी आ जाता है और अपनी ऑन-कॉल रोटा वाला वितरित सिस्टम भी। यह शब्दावली की नहीं, बजट की समस्या है: टीमें एक चीज़ मंज़ूर करती हैं और उन्हें दूसरी मिलती है।

काम का दायरा तय करते समय हम यह परिभाषा इस्तेमाल करते हैं, और यह जान-बूझकर संकीर्ण है। AI एजेंट वह सॉफ़्टवेयर है जिसमें एक भाषा मॉडल अगला कदम चुनता है, उसे उठाने के लिए असली टूल कॉल करता है, जो लौटे उसे पढ़ता है और फिर चुनता है — जब तक लक्ष्य पूरा न हो या कोई सीमा उसे रोक न दे। अगर आपके सिस्टम में कुछ भी टूल कॉल नहीं करता, तो आपके पास बहुत अच्छा टेक्स्ट जेनरेटर है। अगर कदमों का क्रम पहले से तय है, तो आपके पास एक वर्कफ़्लो है जिसकी किसी एक डिब्बी में मॉडल बैठा है। दोनों ठीक हैं। किसी को एजेंट का बजट नहीं चाहिए।

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

### एजेंट को किन चीज़ों से अलग करता है
| चैटबॉट | कोई नहीं — पूछा गया उत्तर देता है | नहीं | ग़लत या गढ़ा हुआ जवाब |
| LLM वाले वर्कफ़्लो | डेवलपर, पहले से | हाँ, तय क्रम में | प्रवाह से बाहर की इनपुट पर टूटता है |
| एजेंट | मॉडल, चलते समय | हाँ, चलते समय चुनकर | भटकता है, चक्कर काटता है, ख़राब डेटा पर काम करता है |
| मल्टी-एजेंट सिस्टम | कई मॉडल और एक समन्वयक | हाँ | यही सब, पर ट्रेस करना कठिन |

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

### स्वायत्तता स्विच नहीं, डायल है
असली डिज़ाइन निर्णय यह नहीं कि एजेंट लें या नहीं, बल्कि कितनी ढील दें। व्यवहार में चार पायदान हैं और सफल परियोजनाएँ डेमो के सुझाव से बाईं ओर शुरू होती हैं: एजेंट मसौदा लिखे, इंसान भेजे; एजेंट पलटने योग्य चीज़ों पर काम करे और न पलटने वालों के लिए पूछे; एजेंट सैंडबॉक्स में ख़र्च सीमा के साथ स्वतंत्र रहे; एजेंट प्रोडक्शन में स्वतंत्र रहे। दाईं ओर हर कदम मूल्य और नुक़सान के दायरे — दोनों को गुणा करता है।

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

Q: क्या चैटबॉट AI एजेंट है?
A: इस परिभाषा से नहीं। चैटबॉट बातचीत के भीतर जवाब देता है; एजेंट बातचीत के बाहर सिस्टम में कार्रवाई करता है। जो सपोर्ट बॉट आपका ऑर्डर डेटाबेस पढ़े, रिफ़ंड करे और ग्राहक को ईमेल भेजे, वह एजेंट है — श्रेणी उसकी कार्रवाइयों ने बदली, बोलने ने नहीं।

Q: क्या एजेंट का स्वायत्त होना ज़रूरी है?
A: उसे अपना अगला कदम चुनना चाहिए, जो निगरानी के बिना काम करने जैसा नहीं है। पाँच कदम की योजना बनाकर चार पूरे करने और पाँचवें पर मंज़ूरी माँगने वाला अब भी एजेंट है। स्वायत्तता हर कार्रवाई पर अलग सेटिंग है।

Q: क्या framework ज़रूरी है?
A: नहीं। सबसे छोटा उपयोगी एजेंट एक लूप, टूल परिभाषाओं की सूची और एक रुकने की शर्त है — शायद सौ पंक्तियाँ। Framework तब जगह कमाते हैं जब टिकाऊ स्थिति, शाखाओं वाला प्रवाह या कई एजेंटों का तालमेल चाहिए।