AI agents कैसे सीखें: शून्य से शुरुआत करने की गाइड

छह चरणों में मार्ग

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

एक AI agent एक language model के चारों ओर बना लूप है जिसे टूल्स का उपयोग करने की अनुमति होती है। यह वाक्य ही पूरा विषय है। इसके बाद की हर चीज़ इस बारे में विवरण है कि लूप में क्या जाता है, टूल्स किन चीज़ों को छू सकते हैं, और जब लूप गलत हो जाए तो उसे कैसे रोकें। यदि आप किसी और को लूप समझा सकते हैं, तो आपने इसे सीख लिया है। यदि आप केवल frameworks के नाम ले सकते हैं, तो आपने नहीं सीखा है।

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

स्टेज 1 से पहले आपको वास्तव में क्या चाहिए

आवश्यकताओं की ईमानदार सूची छोटी है, और अधिकांश कोर्स पेजों के सुझाव से भी कम है।

• आप 50 लाइन की स्क्रिप्ट के स्तर पर Python या TypeScript पढ़ और लिख सकते हैं।
• आप Linux shell में सहज हैं: पैकेज इंस्टॉल करना, फाइल एडिट करना, लॉग पढ़ना।
• आपके पास किसी hosted model के लिए API key है, या ऐसी मशीन है जो local model चला सकती है।

पूरी सूची बस इतनी ही है। आपको machine learning थ्योरी की आवश्यकता नहीं है, और आपको कोई मॉडल ट्रेन करने की जरूरत नहीं है। एजेंट के काम में gradients या training data जैसा कुछ भी शामिल नहीं है। Graphics card तभी मायने रखता है जब आप मॉडल को स्वयं चलाने का निर्णय लेते हैं, जो कि एक अलग कौशल है जिसे आप बाद में hosting Ollama on a VPS to self host an LLM से सीख सकते हैं।

लोग जिस चीज को कम आंकते हैं, वह shell वाला हिस्सा है। एजेंट permissions, paths, environment variables और चुपचाप बंद हो जाने वाली processes के कारण विफल होते हैं। यदि PATH के बारे में कोई stack trace या file mode आपको टर्मिनल बंद करने पर मजबूर करता है, तो पहले एक सप्ताहांत Linux की बुनियादी बातों पर बिताएं। यह बाद में आपका एक महीना बचाएगा।

चरण 1: एजेंट क्या है, और क्या नहीं है

एक API कॉल और बिना किसी लूप के शुरुआत करें। एक प्रॉम्प्ट भेजें, उत्तर प्रिंट करें, और रिस्पॉन्स में टोकन काउंट देखें। अब आप लागत की इकाई और लेटेंसी की इकाई को समझ गए हैं।

फिर tool use सीखें। पूरे क्षेत्र में यही एकमात्र वास्तव में नया विचार है। आप model के लिए किसी function को उसके नाम, description और उसके inputs के लिए JSON (JavaScript object notation) schema के रूप में describe करते हैं। model स्वयं कुछ नहीं चलाता। वह एक structured request के साथ जवाब देता है: इन arguments के साथ run_command को call करें। आपका code function चलाता है, उसके output को message के रूप में वापस भेजता है और model से फिर पूछता है। model ऐसा planner है जो text पढ़ता और text लिखता है। आपके पक्ष का code ही वह हिस्सा है जिसके पास वास्तविक execution क्षमता है। Designs की तुलना शुरू करने पर इस exchange के आपके पक्ष वाले code का एक नाम होता है: यह agent harness है—ऐसा loop, tools और permissions, जो उस model के चारों ओर wrapped होते हैं और जिनमें स्वयं कोई permissions नहीं होतीं।

एक चैटबॉट एक उत्तर के बाद समाप्त हो जाता है। एक एजेंट उस एक्सचेंज को तब तक दोहराता है जब तक कि मॉडल टूल मांगना बंद न कर दे। यह पुनरावृत्ति ही पूरा अंतर है, और यही कारण है कि विफलता के तरीके (failure modes) भी अलग होते हैं। एक चैटबॉट एक बार गलत उत्तर देता है। एक एजेंट किसी के ध्यान देने से पहले कई बार गलत उत्तर पर कार्य करता है।

चरण 2: लूप को स्वयं लिखें, एक बार

किसी फ्रेमवर्क से शुरुआत न करें। लगभग तीस लाइन का Python कोड लिखें ताकि इसकी संरचना आपकी समझ में रहे।

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/agent
source ~/agent/bin/activate
pip install anthropic
export ANTHROPIC_API_KEY=your-key-here

import subprocess
import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "run_command",
    "description": "Run a read only shell command and return its output.",
    "input_schema": {
        "type": "object",
        "properties": {"command": {"type": "string"}},
        "required": ["command"],
    },
}]

messages = [{"role": "user", "content": "How much disk space is free here?"}]

while True:
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=4096,
        tools=tools,
        messages=messages,
    )
    if response.stop_reason != "tool_use":
        break
    messages.append({"role": "assistant", "content": response.content})
    results = []
    for block in response.content:
        if block.type == "tool_use":
            done = subprocess.run(
                block.input["command"], shell=True,
                capture_output=True, text=True, timeout=10,
            )
            results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": done.stdout or done.stderr,
            })
    messages.append({"role": "user", "content": results})

print(next(b.text for b in response.content if b.type == "text"))

इसे python3 agent.py के साथ चलाएं। एक सफल रन आपके फाइलसिस्टम और उनकी खाली जगह का नाम बताने वाला एक पैराग्राफ प्रिंट करेगा, क्योंकि मॉडल ने df -h के लिए अनुरोध किया था, आपके कोड ने इसे चलाया, और दूसरे पास ने उस टेबल को एक वाक्य में बदल दिया। यदि यह कुछ भी प्रिंट नहीं करता है, तो टेक्स्ट ब्लॉक आने से पहले ही लूप समाप्त हो गया। लूप के अंदर print(response.stop_reason) जोड़ें और मानों को बदलते हुए देखें।

अब इसे जानबूझकर तोड़ें। tool_use_id लाइन को हटा दें और त्रुटि को पढ़ें, क्योंकि बिना मैचिंग ID वाले टूल परिणाम को API द्वारा अस्वीकार कर दिया जाता है और यह शुरुआती लोगों के लिए सबसे आम बग है। एक ऐसा प्रश्न पूछें जिसके लिए दो कमांड की आवश्यकता हो और लूप को दो बार चलते हुए देखें। कुछ असंभव पूछें और देखें कि क्या यह हार मान लेता है या हमेशा के लिए चलता रहता है।

इस उदाहरण के बारे में एक चेतावनी। यह shell=True के साथ मॉडल आउटपुट को सीधे शेल में भेजता है, जो एक ऐसी स्क्रैच मशीन पर स्वीकार्य है जिसे आप फिर से बना सकते हैं, लेकिन बाकी हर जगह यह गलत है। चरण 6 इसे ठीक करता है। लूप के अंतर्गत अवधारणाओं को अपने VPS पर अपना AI एजेंट बनाना में अधिक विस्तार से कवर किया गया है।

चरण 3: वे टूल्स जो एजेंट के पास पहले से नहीं थे

आपका run_command टूल काम करता है, लेकिन एक वास्तविक एजेंट को ऐसे टूल्स की आवश्यकता होती है जो सिस्टम की सीमाओं से बाहर पहुँच सकें: जैसे कि टिकट सिस्टम, डेटाबेस या रिपॉजिटरी। प्रत्येक एजेंट के लिए, प्रत्येक सर्विस हेतु एक विशेष रैपर (wrapper) लिखना स्केलेबल नहीं है।

Model Context Protocol (MCP) वह समाधान है जिसे इंडस्ट्री ने अपनाया है। एक MCP सर्वर एक मानक ट्रांसपोर्ट के माध्यम से टूल्स का एक सेट एक्सपोज़ करता है, और कोई भी MCP-सक्षम एजेंट बिना किसी कस्टम ग्लू कोड के इसका उपयोग कर सकता है। रेफरेंस फाइलसिस्टम सर्वर केवल एक कमांड है:

npx -y @modelcontextprotocol/server-filesystem /home/you/projects

इसके लिए Node इंस्टॉल होना आवश्यक है, और डायरेक्टरी आर्ग्युमेंट वह एकमात्र पाथ है जिसे सर्वर एक्सेस करेगा। यह सुरक्षा मॉडल का एक छोटा रूप है: सर्वर सीमा तय करता है, न कि मॉडल। एक क्लाइंट को इसकी ओर पॉइंट करें और आपका एजेंट फाइल रीडिंग और राइटिंग की क्षमता प्राप्त कर लेगा जिसे आपने स्वयं नहीं लिखा है। इन्हें सही तरीके से, एक सर्विस अकाउंट के तहत और ट्रांसपोर्ट विकल्पों के साथ चलाने के बारे में AI कोडिंग एजेंटों के लिए VPS पर MCP सर्वर चलाना में बताया गया है। एक दूसरे सर्वर के लिए जो स्क्रैच डायरेक्टरी के बजाय वास्तविक डेटा की ओर पॉइंट करता है, self hosting openGym, एक वर्कआउट ट्रैकर एक रीड-ओनली सर्वर प्रदान करता है, ताकि आप एजेंट को कुछ भी ऐसा दिए बिना जिसे वह खराब कर सके, अपने ट्रेनिंग इतिहास के बारे में प्रश्न पूछने का अभ्यास कर सकें।

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

चरण 4: मेमोरी, जो मुख्य रूप से केवल फाइलें हैं

शुरुआती लोग यहाँ vector database का उपयोग करने की कोशिश करते हैं। ऐसा न करें, कम से कम अभी तो नहीं।

एक agent के पास कॉल के बीच कोई मेमोरी नहीं होती है। आप हर बार पूरी बातचीत फिर से भेजते हैं, यही कारण है कि एक लंबा session छोटे session की तुलना में प्रति टर्न अधिक महंगा होता है। इसलिए मेमोरी दो समस्याओं में विभाजित हो जाती है। पहली यह है कि अभी context window में क्या फिट बैठता है, जिसे आप सारांशित करके, पुराने tool output को ट्रिम करके, और अपने prompt के स्थिर prefix को कैश करके प्रबंधित करते हैं ताकि आप इसके लिए कीमत का एक छोटा हिस्सा ही चुकाएं। दूसरी समस्या यह है कि रीस्टार्ट के बाद क्या बचता है, जो कि स्टोरेज है।

दूसरी समस्या के लिए, एक साधारण markdown फाइल जिसे agent पढ़ और लिख सके, लगभग हर पहले प्रोजेक्ट के लिए vector database से बेहतर है। इसे एक फाइल दें, इसे फॉर्मेट बताएं, और इसे शुरू करने से पहले उस फाइल को पढ़ने और कुछ नया सीखने पर उसे अपडेट करने के लिए कहें। आपको अधिकांश लाभ मिल जाते हैं, और आप फाइल खोलकर देख सकते हैं कि आपका agent क्या मानता है। जब नोट्स context window में फिट होना बंद हो जाएं, केवल तभी embeddings और retrieval का उपयोग करें, उससे पहले नहीं।

चरण 5: लूप ही उत्पाद है

अब तक आप एक ऐसा एजेंट बना चुके हैं जो आपके देखते हुए काम करता है। चरण 5 इसे तब काम करने योग्य बनाना है जब आप उसे न देख रहे हों।

चार प्रश्न यह तय करते हैं कि क्या एक unattended एजेंट को अकेला छोड़ना सुरक्षित है। इसे क्या trigger करता है, ताकि यह व्यर्थ न चले। यह किस सीमा (boundary) के भीतर काम करता है, ताकि गलती का प्रभाव सीमित रहे। परिणाम को कैसे verify किया जाता है, क्योंकि जो एजेंट अपना होमवर्क खुद जांचता है, वह हमेशा पास हो जाता है। कौन सा बजट इसे रोकता है, tokens में या wall clock समय में। इन चारों को सोच-समझकर डिजाइन करना ही वह अनुशासन है जिसका वर्णन loop engineering, और वह परिभाषा क्या कवर करती है में किया गया है।

अभ्यास: अपने चरण 2 वाले एजेंट को लें, उसे चार या पांच चरणों वाला कोई कार्य दें, और एक सख्त iteration cap जोड़ें। फिर उस cap को हटा दें और देखें कि एक unbounded लूप आपके token बिल का क्या हाल करता है। इसे एक बार छोटे बजट पर करें ताकि आप कभी भी गलती से इसे बड़े बजट पर न कर बैठें।

चरण 6: सुरक्षा, सीक्रेट्स और लागत

यह चरण वैकल्पिक नहीं है। यह अंत में इसलिए है क्योंकि जब तक आप कुछ कार्यशील नहीं बना लेते, तब तक आप जोखिम को महसूस नहीं कर सकते।

Agent को हमेशा अपने स्वयं के unprivileged user के रूप में चलाएं। इसे कभी भी root के रूप में या अपने व्यक्तिगत account से न चलाएं, ताकि किसी भी गड़बड़ी का प्रभाव पूरी मशीन के बजाय केवल एक directory तक सीमित रहे। Credentials को model की पहुँच से दूर रखें, क्योंकि context window में मौजूद कोई भी जानकारी tool call के माध्यम से बाहर भेजी जा सकती है। इसका समाधान keeping secrets out of your AI agents में बताए अनुसार helper के पीछे short-lived tokens का उपयोग करना है। खर्च पर एक सख्त सीमा (hard ceiling) निर्धारित करें, क्योंकि बिना निगरानी के चलने वाला loop हर iteration के लिए बिल बनाता है। खर्च को नियंत्रित रखने वाली सीमाएं और batching के बारे में AI agent cost control on an always on VPS में विस्तार से बताया गया है।

यदि आपका agent आपके द्वारा लिखे गए script के बजाय किसी harness के अंदर चलता है, तो इस चरण का कुछ हिस्सा code के बजाय configuration का होता है। the DeepSeek Harness plugins worth installing में budget caps, tool permission rules और injection scanning के माध्यम से काफी हद तक यही सुरक्षा प्रदान की जाती है।

लागत के लिए एक ठोस संख्या का ध्यान रखना आवश्यक है। जुलाई 2026 तक, Claude Opus 5 का शुल्क प्रति दस लाख input tokens के लिए $5 और प्रति दस लाख output tokens के लिए $25 है। एक बातूनी agent जो बढ़ती हुई बातचीत को बार-बार भेजता है, वह एक ही कार्य में कुछ लाख tokens खर्च कर सकता है। Prompt caching और नियमित कार्यों के लिए छोटे model का उपयोग करना, किसी भी prompt tweak की तुलना में गणित को कहीं अधिक बदल देता है।

Prompt injection भी इसी श्रेणी में आता है। यदि आपका agent कोई web page, issue tracker या inbox पढ़ता है, तो उस text को लिखने वाला व्यक्ति आपके agent को निर्देश भी दे रहा होता है। Web search आमतौर पर वह tool है जो सबसे पहले यह द्वार खोलता है, और pointing an agent at your own SearXNG instance में इसके wiring और injection surface को एक साथ दिखाया गया है। इसका बचाव कोई चतुर system prompt नहीं है। इसका बचाव 'सीमा' (boundary) है, क्योंकि जिस agent के पास repository delete करने की अनुमति नहीं है, उसे ऐसा करने के लिए राजी नहीं किया जा सकता।

आपको किस पाठ्यक्रम का पालन करना चाहिए?

छह अलग-अलग पाठ्यक्रमों को थोड़ा-थोड़ा देखने के बजाय, एक पाठ्यक्रम चुनें और उसे पूरा करें। Microsoft ai-agents-for-beginners रिपॉजिटरी सबसे पूर्ण मुफ्त संसाधन है। यह अठारह पाठों का एक कोर्स है, जिसे जुलाई 2026 तक 70,000 से अधिक स्टार्स मिल चुके हैं, और यह ऊपर बताए गए चरणों के साथ सटीक रूप से मेल खाता है। ट्रेंडिंग एजेंट रिपॉजिटरी की सूची यह देखने के लिए उपयोगी है कि क्या उपलब्ध है, लेकिन पाठ्यक्रम के रूप में यह कम प्रभावी है, क्योंकि स्टार्स के आधार पर क्रमबद्ध सूची लोकप्रियता दर्शाती है, न कि सीखने का सही क्रम।

जब आप अभ्यास के लिए कोई वास्तविक प्रोजेक्ट चुनना चाहें, तो एक कोडिंग एजेंट सबसे अच्छा शुरुआती लक्ष्य है: इसमें फीडबैक तुरंत मिलता है, टूल्स स्पष्ट होते हैं, और गलतियों को सुधारना आसान होता है। VPS पर कोडिंग AI एजेंट चलाना इस प्रक्रिया को शुरू से अंत तक समझाता है। यदि आप शून्य से निर्माण करने के बजाय कार्यशील सिस्टम का अध्ययन करना पसंद करते हैं, तो सबसे अच्छे self hosted AI agents में की गई तुलना यह दिखाती है कि कैसे कई प्रोजेक्ट्स एक ही लूप को अलग-अलग तरीकों से हल करते हैं।

इसमें कितना समय लगता है?

यदि आप पहले से प्रोग्रामिंग जानते हैं, तो चरण 1 और 2 एक शाम का काम है। चरण 3 एक सप्ताहांत (weekend) लेता है, जिसका अधिकांश समय प्रोटोकॉल के बजाय टूल के विवरण को समझने में व्यतीत होता है। चरण 4 और 5 में वास्तविक उपयोग के कुछ सप्ताह लगते हैं, क्योंकि आप केवल यह देखकर सीखते हैं कि आपका agent क्या भूलता है। चरण 6 कभी पूरी तरह समाप्त नहीं होता, क्योंकि आपके द्वारा दी गई प्रत्येक नई क्षमता इसे फिर से खोल देती है।

लगातार दो महीनों की शामें अधिकांश लोगों को एक कार्यशील, सीमित और उपयोगी agent बनाने में मदद करती हैं। जो लोग इसमें एक साल लगाते हैं, वे आमतौर पर वे होते हैं जो निर्माण करने के बजाय केवल पढ़ते रहते हैं।

FAQ

क्या AI agent बनाने के लिए मुझे machine learning आनी चाहिए?

नहीं। Agent बनाने का अर्थ है API के माध्यम से किसी model को call करना और उसके tool requests को वास्तविक functions से जोड़ना, जो कि सामान्य application programming है। आपको training, gradients या datasets को छूने की आवश्यकता नहीं होती। आपके agent के काम करने की क्षमता इस बात पर निर्भर करती है कि आप tools के लिए schema कैसे design करते हैं, error handling कैसे करते हैं और Linux permissions को कैसे प्रबंधित करते हैं। Machine learning theory केवल तब प्रासंगिक होती है जब आप किसी model को fine-tune करना चाहते हैं, जो कि अलग पूर्व-आवश्यकताओं वाला एक अलग कार्य है।

क्या मुझे LangChain या CrewAI जैसे framework से शुरुआत करनी चाहिए?

पहले एक raw loop लिखें, उसके बाद ही किसी framework को अपनाएं। एक framework stage 2 की तीस लाइनों को एक configuration object से बदल देता है, जो तब सुविधाजनक होता है जब आप जानते हैं कि उसने किसे प्रतिस्थापित किया है, लेकिन उससे पहले यह भ्रमित करने वाला हो सकता है। जब आपका agent गलत व्यवहार करता है, तो आपको सीधे message list और tool results के बारे में सोचना पड़ता है, और यदि आपने उन्हें पहले कभी नहीं देखा है तो यह बहुत कठिन होता है। अपने स्वयं के एक loop के बाद, एक framework तंत्र को छिपाने के बजाय आपका समय बचाता है।

AI agents सीखने में कितना खर्च आता है?

यदि आप सीमा तय करें, तो यह अधिकांश लोगों की अपेक्षा से कम है। एक hosted API key और एक छोटा VPS इन छह stages में सब कुछ कवर कर लेते हैं। वास्तविक जोखिम hourly rate नहीं है, बल्कि एक अनियंत्रित loop है जो आपके सोते समय हर iteration के लिए billing करता है। पहले दिन ही अपने API account पर एक सख्त spend limit सेट करें, अपने द्वारा लिखे गए हर loop में एक iteration cap जोड़ें, और routine steps के लिए सस्ते model का उपयोग करें। Model को स्थानीय रूप से चलाने से token का बिल खत्म हो जाता है और उसके स्थान पर hardware की आवश्यकता बढ़ जाती है।

AI agent और chatbot में क्या अंतर है?

Chatbot केवल एक बार उत्तर देता है। Agent एक चक्र को दोहराता है: model एक tool के लिए पूछता है, आपका code उसे चलाता है, परिणाम वापस जाता है, और model तय करता है कि आगे क्या करना है। वह पुनरावृत्ति ही है जो एक agent को कई चरणों वाले कार्य को पूरा करने देती है, और यही कारण है कि agents को ऐसी सीमाओं की आवश्यकता होती है जो chatbots को नहीं होतीं। Chatbot से मिला गलत उत्तर केवल एक खराब paragraph होता है। Agent से मिला गलत उत्तर एक खराब paragraph के साथ-साथ वह सब कुछ है जो उसने उस उत्तर के आधार पर किया।