AI agents के मुख्य प्रकार और उनकी कार्यप्रणाली

AI agents के प्रकार

AI agents के प्रकार एक ही वर्गीकरण (taxonomy) से आते हैं: simple reflex, model-based reflex, goal-based, utility-based, और learning agents। प्रत्येक नाम एक ही बात बताता है: agent को कितनी चीजें याद रहती हैं और वह कार्य करने से पहले कितनी दूर की योजना बनाता है। दो अन्य शब्द, multi-agent और hierarchical, यह बताते हैं कि कई agents आपस में कैसे जुड़े होते हैं, न कि यह कि उनमें से कोई एक निर्णय कैसे लेता है।

यह सूची आपके द्वारा उपयोग किए गए किसी भी model से पुरानी है। यह मानक AI पाठ्यपुस्तक से ली गई है, और यह large language models के आने के बाद भी प्रासंगिक बनी हुई है क्योंकि यह उस प्रश्न को पूछती है जो अभी भी आपके डिज़ाइन को निर्धारित करता है: कार्य करने से पहले इस चीज़ को क्या जानने की आवश्यकता है? यदि आप अभी भी यह तय कर रहे हैं कि एक agent कहाँ समाप्त होता है और एक chat assistant कहाँ से शुरू होता है, तो पहले AI agent और उस LLM जिस पर वह चलता है, के बीच का अंतर पढ़ें। यह पृष्ठ उस रेखा के बाद शुरू होता है।

Simple reflex agents: एक शर्त, एक क्रिया

एक simple reflex agent वर्तमान इनपुट को एक क्रिया से जोड़ता है और पिछली किसी भी चीज़ की मेमोरी नहीं रखता है। यदि तापमान 25 से ऊपर है, तो पंखा चालू करें। यही पूरी कार्यप्रणाली है।

आपने निश्चित रूप से इसे चलाया होगा। एक webhook जो n8n workflow को ट्रिगर करता है, जो फॉर्म सबमिशन को पढ़ता है और डेटाबेस में एक पंक्ति लिखता है, एक simple reflex agent है। यह तब भी एक ही रहता है जब बीच में कोई language model उस पंक्ति के लिए श्रेणी चुन रहा हो। इससे पूछें कि उसने एक घंटे पहले क्या किया था और यह आपको नहीं बता पाएगा, क्योंकि किसी ने भी उत्तर को सुरक्षित नहीं रखा था।

यह प्रकार लोगों की अपेक्षा से अधिक बार सही साबित होता है। इसे चलाना सस्ता है, और इसकी विफलता स्पष्ट है: शर्त पूरी हुई, या नहीं हुई। जब काम वास्तव में "जब X आए, तो Y करें" होता है, तो मेमोरी गलत होने के नए तरीके जोड़ती है और कुछ भी हासिल नहीं होता है। A webhook-triggered n8n agent वर्गीकरण की इस श्रेणी का एक उदाहरण है जिसके ऊपर एक user interface है।

यह उस क्षण विफल हो जाता है जब सही क्रिया इतिहास पर निर्भर करती है। बिना thread state वाला एक reply bot तीसरे संदेश पर खुद का खंडन करेगा, क्योंकि पहले दो संदेश कभी भी इसके इनपुट का हिस्सा नहीं थे।

Model-based reflex agents: state को events के बीच बनाए रखना

एक model-based reflex agent अपने environment की एक आंतरिक तस्वीर रखता है और नया input आने पर उस तस्वीर को update करता है। यहाँ "model" शब्द का अर्थ world model है, न कि neural network। यह शब्द अपने वर्तमान अर्थ से लगभग चालीस साल पुराना है, और पहली बार पढ़ने पर यह लगभग सभी को भ्रमित करता है।

एक home automation rule जो motion न होने पर बीस मिनट बाद लाइट बंद कर देता है, वह model-based होता है। उसे ऐसा होना ही पड़ता है। "अभी कोई motion नहीं" और "21:40 से कोई motion नहीं" एक simple reflex agent के लिए समान input हैं, इसलिए केवल stored state ही उन्हें अलग पहचान पाता है।

LLM version कोई भी ऐसा agent है जिसके पीछे memory store हो: जैसे कि एक rolling conversation summary, या एक plain markdown file जिसे agent हर run की शुरुआत में पढ़ता है। Agent के लिए एक local memory service इसी विचार का एक रूप है। mechanism नहीं बदलता है। agent की world की तस्वीर उस event से अधिक समय तक जीवित रहती है जिसने उसे बनाया था।

State की एक कीमत होती है। एक पुराना (stale) तथ्य न होने से भी बुरा है, क्योंकि agent उस पर पूरे भरोसे के साथ और बिना किसी चेतावनी के काम करता है। आप जो कुछ भी store करते हैं, उसे expire करने या फिर से check करने का एक तरीका होना चाहिए, अन्यथा agent उस server के बारे में तर्क करता रहेगा जिसे आपने March में decommission कर दिया था।

लक्ष्य-आधारित एजेंट्स: उस स्थिति की ओर योजना बनाना जिसे आप जांच सकें

एक लक्ष्य-आधारित एजेंट को एक लक्ष्य स्थिति (target state) प्राप्त होती है और वह वहां तक पहुँचने के लिए क्रियाओं के अनुक्रम (sequence of actions) की खोज करता है। यह उस स्थान से पीछे की ओर काम करता है जहाँ इसे समाप्त होना है, इसलिए रास्ता पहले से लिखा नहीं होता है।

एक कोडिंग एजेंट सबसे स्पष्ट उदाहरण है जिसे आप स्वयं चला सकते हैं। "असफल टेस्ट को पास कराएं" (Make the failing test pass) निर्देश में किसी फाइल या चरण का नाम नहीं होता है। एजेंट टेस्ट को पढ़ता है, एक योजना बनाता है, कुछ बदलाव करता है, टेस्ट चलाता है, त्रुटि को पढ़ता है और फिर से प्रयास करता है। यह लूप एक ऐसे चेक पर समाप्त होता है जिसे वह वास्तव में निष्पादित कर सकता है, यही कारण है कि वह निर्देश काम करता है और "इस कोड को बेहतर बनाएं" (improve this code) काम नहीं करता है। एक लक्ष्य जिसे एजेंट स्वयं मूल्यांकित कर सकता है, वही लक्ष्य है जिसे एजेंट प्राप्त कर सकता है। एक लक्ष्य जिसे वह मूल्यांकित नहीं कर सकता, वह एक अंतहीन लूप बन जाता है जिसके साथ एक बिल भी जुड़ा होता है। अपने स्वयं के VPS पर कोडिंग एजेंट चलाना उस लूप को ऐसी जगह रखता है जहाँ वह आपके लैपटॉप को व्यस्त किए बिना काम कर सकता है।

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

Utility-based agents: कई अच्छे विकल्पों में से चुनाव

लक्ष्य (goal) बाइनरी होता है। यूटिलिटी (utility) एक स्कोर है। एक utility-based agent कई स्वीकार्य परिणामों का सामना करता है और उस परिणाम को चुनता है जिसे आपने लिखे गए फंक्शन के तहत सबसे अधिक स्कोर मिलता है।

एक बैकअप जॉब जिसे कार्य दिवस शुरू होने से पहले पूरा करना है और साथ ही uplink को saturate भी नहीं करना है, वह एक यूटिलिटी समस्या है। इसका कोई एक सही उत्तर नहीं है, केवल एक trade-off है। एक राउटर जो यह तय करता है कि कौन सा मॉडल किस request को संभालेगा, और जो कीमत बनाम उत्तर की गुणवत्ता को तौलता है, उसका स्वरूप भी यही है।

एल्गोरिदम कठिन हिस्सा नहीं है। एक ईमानदार यूटिलिटी फंक्शन लिखना कठिन है। यदि आप केवल लागत (cost) पर स्कोर करते हैं, तो आपको हर request पर सबसे सस्ता मॉडल मिलेगा, जिसमें वह एक request भी शामिल है जिसे महंगे मॉडल की आवश्यकता थी। सिस्टम ठीक उसी चीज़ को ऑप्टिमाइज़ करता है जिसे आपने मापा है, जो तब एक समस्या बन जाती है जब आपने जिस चीज़ को मापा है, उसे केवल इसलिए चुना गया था क्योंकि उसे मापना आसान था।

Learning agents: वह प्रकार जिसे ज्यादातर लोग मानते हैं कि उनके पास पहले से है

एक learning agent पिछले परिणामों से मिली प्रतिक्रिया के आधार पर अपने व्यवहार को बदलता है। इसे एक ऐसी चीज़ की आवश्यकता होती है जो परिणाम का मूल्यांकन करे और एक ऐसी चीज़ जो प्रतिक्रिया में policy को बदल सके।

बहुत कम self-hosted systems इस श्रेणी में आते हैं। एक agent जो पिछले सप्ताह लिखे गए अपने नोट्स को पढ़ता है, वह memory file वाला एक model-based agent है। इसके weights समान रहते हैं। इसकी policy समान रहती है। Retrieval (जानकारी प्राप्त करना) learning नहीं है, और यह अंतर व्यावहारिक है: एक memory-based system हमेशा के लिए गलती दोहराता रहता है जब तक कि कोई memory को edit न करे, जबकि एक learning system से यह अपेक्षा की जाती है कि वह गलती करना बंद कर दे।

यदि आप learning वाला हिस्सा चाहते हैं, तो पहले evaluation (मूल्यांकन) तैयार करें। एक scored test set, उसके विरुद्ध आपके बदलाव का एक run, और बदलाव को रखने या हटाने का निर्णय एक closed loop है जिसमें आप स्वयं learning component हैं। यह सुनने में जितना लगता है उससे कहीं अधिक धीमा है, और यही एकमात्र संस्करण है जो आज self-hosted भागों पर काम करता है। Self-hosting an eval harness वह जगह है जहाँ से इसकी शुरुआत होती है।

Multi-agent और hierarchical systems: व्यवस्थाएं, प्रकार नहीं

ये छठा और सातवां प्रकार नहीं हैं। ये बताते हैं कि agents को कैसे व्यवस्थित किया जाता है।

एक multi-agent system एक साझा वातावरण, जैसे कि queue या git repository के भीतर एक साथ कई agents चलाता है। वातावरण साझा होने के कारण, वे आपस में टकराते हैं। एक ही file को edit करने वाले दो agents एक सामान्य विफलता (failure) है, और इसका समाधान lock या work queue है। कोई भी prompt इसे हल नहीं करता।

एक hierarchical system workers के ऊपर एक supervisor रखता है। supervisor कार्य को विभाजित करता है, भागों को सौंपता है, और वापस आने वाले परिणामों को merge करता है। यह लोकप्रिय है क्योंकि यह लोगों द्वारा काम बांटने के तरीके से मेल खाता है, और यह महंगा है क्योंकि हर report पढ़ने के साथ supervisor का context बढ़ता जाता है। A multi-agent harness व्यवहार में उस wiring को दर्शाता है।

एक agent जो काम करता है, वह चार ऐसे agents से बेहतर है जो ज्यादातर काम करते हैं।

हर handoff जानकारी खोने का एक स्थान है। एक loop से शुरुआत करें। इसे केवल तभी विभाजित करें जब आप उस चरण का नाम बता सकें जो bottleneck है।

लगभग हर वास्तविक सिस्टम हाइब्रिड क्यों होता है

एक ऐसे deployment agent पर विचार करें जिसे आप स्वयं चलाते हैं। एक webhook इसे शुरू करता है, जो reflex है। यह वर्तमान release state को पढ़ता है, जो model-based है। यह चल रहे version से target version तक के चरणों की योजना बनाता है, जो goal-based है। यह वर्तमान load के आधार पर rollout window चुनता है, जो utility-based है। यह कभी भी अपनी policy को edit नहीं करता है, इसलिए यह learning नहीं है।

एक ही सिस्टम, एक ही समय में taxonomy की चार पंक्तियों का उपयोग करता है। यह taxonomy तैयार उत्पाद के लेबल के रूप में नहीं, बल्कि एक design checklist के रूप में अपनी सार्थकता सिद्ध करती है। जब सिस्टम गलत व्यवहार करता है, तो उपयोगी प्रश्न यह होता है कि कौन सी परत गलत है। गलत event पर trigger होना, state का पुराना हो जाना, goal check का कभी पूरा न हो पाना, और score का गलत परिणाम देना—ये चार अलग-अलग bugs हैं जिनके चार अलग-अलग समाधान हैं।

कौन सा प्रकार किस कार्य के लिए उपयुक्त है

• Fixed trigger, fixed response, इतिहास की आवश्यकता नहीं: simple reflex।
• सही response इस पर निर्भर करता है कि पहले क्या हुआ था: model-based reflex।
• अंतिम स्थिति (end state) की जाँच की जा सकती है लेकिन रास्ता पहले से ज्ञात नहीं है: goal-based।
• कई स्वीकार्य परिणाम जिनमें उनके बीच वास्तविक trade-off शामिल है: utility-based।
• आपको समय के साथ बेहतर परिणामों की आवश्यकता है: एक eval loop बनाएँ, और यह स्वीकार करें कि आप स्वयं learning component हैं।

क्या आप इन agents को स्वयं host कर सकते हैं, और इसका खर्च क्या है?

हाँ, और खर्च दो भागों में बँटा है। Orchestration सस्ता है। एक n8n instance या Python में एक agent loop अपना अधिकांश समय network calls की प्रतीक्षा में बिताता है, इसलिए 2 vCPU और 4 GB RAM इसके लिए पर्याप्त है। खर्च मुख्य रूप से model पर होता है।

यदि agent किसी hosted API को call करता है, तो सर्वर को लगभग किसी संसाधन की आवश्यकता नहीं होती और बिल tokens के आधार पर बढ़ता है। एक goal-based agent के लिए इसका अर्थ है कि खर्च इस बात पर निर्भर करता है कि आप कितने planning steps की अनुमति देते हैं, इसलिए loop पर सीमा (cap) लगाएँ।

यदि आप model को अपने hardware पर चलाते हैं, तो RAM यह तय करती है कि आप क्या चला सकते हैं। नीचे दिए गए आंकड़े अगस्त 2026 तक 4-bit quantised weights के लिए सामान्यतः प्रकाशित फ़ाइल आकार हैं, साथ ही कुल RAM के लिए एक planning figure भी दी गई है, क्योंकि context window और runtime दोनों को weights के अलावा अतिरिक्त जगह की आवश्यकता होती है।

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit पर एक 8B model लगभग 4.9 GB weights का होता है, और 10 GB RAM वाला एक सिस्टम इसे बिना swapping के चला सकता है। उसी quantisation पर एक 70B model 43 GB weights का होता है और इसके लिए लगभग 64 GB RAM की आवश्यकता होती है। ध्यान दें कि ये संख्याएँ क्या नहीं बताती हैं: गति। बिना GPU वाले VPS पर, 4-bit पर एक 8B model प्रति सेकंड single-digit tokens ही उत्पन्न करता है। यह रात भर queue में काम करने वाले agent के लिए ठीक है, लेकिन किसी ऐसे काम के लिए कष्टदायक है जिसका इंतज़ार कोई व्यक्ति कर रहा हो। Local inference को batch work के लिए रखें, और interactive कार्यों के लिए GPU या API का उपयोग करें। Self-hostable AI agents की संक्षिप्त सूची उन projects को कवर करती है जो disk space के योग्य हैं, और 2026 में agents के लिए अध्ययन मार्ग यह बताता है कि क्या और किस क्रम में सीखना चाहिए।

जहाँ वर्गीकरण (taxonomy) मदद करना बंद कर देता है

यह टूल्स या अनुमतियों (permissions) के बारे में कुछ नहीं कहता है। पाठ्यपुस्तक के एजेंट्स केवल देखते हैं और कार्य करते हैं। उस अध्याय को लिखने वाले किसी भी व्यक्ति को इस बात की चिंता नहीं थी कि कोई एजेंट प्रोडक्शन API टोकन रख सकता है। शेल एक्सेस वाला एक लक्ष्य-आधारित (goal-based) एजेंट और केवल रीड-ओनली डेटाबेस कनेक्शन वाला एक लक्ष्य-आधारित एजेंट तालिका की एक ही पंक्ति में आते हैं, जबकि उनका जोखिम पूरी तरह से अलग होता है। यह तय करने से पहले कि एजेंट कितना चतुर होना चाहिए, यह तय करें कि वह किन चीजों को छू सकता है, और उसे कोई क्रेडेंशियल देने से पहले AI एजेंट से सीक्रेट्स को कैसे सुरक्षित रखें पढ़ें।

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

FAQ

AI agents के पाँच प्रकार कौन से हैं?

Simple reflex, model-based reflex, goal-based, utility-based, और learning agents। इन्हें इस आधार पर क्रमबद्ध किया गया है कि कार्य करने से पहले agent को कितनी जानकारी होती है। एक simple reflex agent केवल वर्तमान input को देखता है। एक model-based agent अपने environment की स्थिति (state) को याद रखता है। एक goal-based agent लक्ष्य स्थिति (target state) की ओर योजना बनाता है। एक utility-based agent कई स्वीकार्य परिणामों को score देता है और सबसे बेहतर को चुनता है। एक learning agent feedback से अपनी policy बदलता है, जो कि लगभग कोई भी self-hosted setup वास्तव में नहीं करता है।

साधारण automation के लिए मुझे किस प्रकार के AI agent का उपयोग करना चाहिए?

एक simple reflex agent, जिसका व्यावहारिक अर्थ एक webhook या एक schedule है जो एक निश्चित sequence को trigger करता है। यदि सही प्रतिक्रिया केवल अभी प्राप्त हुए input पर निर्भर करती है, तो memory केवल विफलता के कारण बढ़ाती है, क्षमता नहीं। model-based design पर तब जाएँ जब आप कम से कम एक ऐसा निर्णय बता सकें जिसके लिए यह जानना आवश्यक हो कि पहले क्या हुआ था।

क्या मैं VPS पर अपने खुद के AI agents चला सकता हूँ?

हाँ। Orchestration layer हल्की होती है, इसलिए 2 vCPU और 4 GB RAM पर एक workflow engine या agent loop आराम से चल सकता है। वास्तविक निर्णय यह है कि model कहाँ चलता है। एक hosted API सर्वर को छोटा रखती है और लागत को tokens पर स्थानांतरित कर देती है। एक local model को अपने parameter count के अनुपात में RAM की आवश्यकता होती है, और GPU के बिना यह प्रति सेकंड कुछ ही tokens generate करता है, जो chat window के बजाय queued batch work के लिए उपयुक्त है।

क्या एक large language model अपने आप में एक AI agent है?

नहीं। एक model input text को output text में बदलता है और फिर रुक जाता है। यह तब agent बनता है जब कोई इसे एक ऐसे loop में लपेटता है जो दुनिया पर कार्य कर सके और परिणाम को वापस loop में भेज सके, जिसके लिए इसे tools की आवश्यकता होती है जिन्हें यह call कर सके और एक ऐसी condition की जो loop को बताए कि कब रुकना है। wrapper ही agent है। model इसके अंदर का केवल एक घटक है।

क्या मुझे multi-agent system की आवश्यकता है?

आमतौर पर नहीं। कई tools वाला एक single loop अधिकांश काम संभाल लेता है और इसे debug करना बहुत आसान है। multiple agents तब मदद करते हैं जब कार्य के हिस्से वास्तव में स्वतंत्र हों और एक ही समय पर चल सकें, या जब किसी हिस्से को अलग model की आवश्यकता हो। इसकी लागत coordination है: shared state, और एक supervisor जिसका context हर worker की रिपोर्ट पढ़ने के साथ बढ़ता जाता है। दूसरा agent तब जोड़ें जब आप उस चरण को इंगित कर सकें जो धीमा है।