AI एजंटचे प्रकार: reflex, goal, utility आणि learning

AI एजंटचे प्रकार

AI एजंटचे प्रकार एका वर्गीकरणातून येतात: simple reflex, model-based reflex, goal-based, utility-based आणि learning agents. प्रत्येक नाव एका गोष्टीचे वर्णन करते: एजंटला किती माहिती लक्षात राहते आणि कृती करण्यापूर्वी तो किती पुढचे नियोजन करतो. आणखी दोन संज्ञा, multi-agent आणि hierarchical, अनेक एजंट एकत्र कसे जोडले जातात हे सांगतात; त्यांपैकी एखादा एजंट निर्णय कसा घेतो हे नाही.

तुम्ही वापरलेल्या प्रत्येक model पेक्षा ही यादी जुनी आहे. ती मानक AI पाठ्यपुस्तकातून आली आहे. Large language models आल्यावरही ती टिकून राहिली, कारण ती तुमच्या डिझाइनसाठी अजूनही निर्णायक असलेला प्रश्न विचारते: कृती करण्यापूर्वी या घटकाला काय माहिती असणे आवश्यक आहे? एजंट कुठे संपतो आणि chat assistant कुठे सुरू होतो हे तुम्ही अजून ठरवत असाल, तर आधी AI agent आणि तो चालवत असलेल्या LLM मधील फरक वाचा. हे पृष्ठ त्या टप्प्यानंतर सुरू होते.

साधे reflex agents: एक condition, एक action

साधा reflex agent सध्याच्या input ला action शी जोडतो आणि यापूर्वीच्या कोणत्याही गोष्टीची memory ठेवत नाही. तापमान 25 पेक्षा जास्त असल्यास fan सुरू करा. हीच संपूर्ण यंत्रणा आहे.

तुम्ही असा agent जवळजवळ नक्कीच वापरला असेल. एखादा webhook n8n workflow सुरू करतो, तो form submission वाचतो आणि database मध्ये एक row लिहितो, तर तो साधा reflex agent आहे. त्या row साठी category निवडण्याचे काम मध्ये language model करत असला तरी तो agent साधाच राहतो. त्याने एक तासापूर्वी काय केले असे विचारल्यास तो सांगू शकत नाही, कारण ते उत्तर साठवणारी कोणतीही memory नव्हती.

हा प्रकार लोकांच्या अपेक्षेपेक्षा अधिक वेळा योग्य ठरतो. तो चालवणे स्वस्त असते आणि त्याचे failure स्पष्टपणे समजते: condition जुळली किंवा जुळली नाही. काम खरोखरच "X आल्यावर Y करा" असे असल्यास memory मुळे चुकण्याचे मार्ग वाढतात, पण कोणताही फायदा होत नाही. webhook-triggered n8n agent हा taxonomy मधील याच प्रकाराचा user interface असलेला नमुना आहे.

योग्य action इतिहासावर अवलंबून असल्यास तो लगेच अपयशी ठरतो. thread state नसलेला reply bot तिसऱ्या message वर स्वतःशीच विरोधाभास निर्माण करेल, कारण पहिली दोन messages त्याच्या input चा भागच नव्हती.

घटनांदरम्यान स्थिती टिकवून ठेवणारे model-based reflex agents

model-based reflex agent आपल्या environment चे अंतर्गत चित्र ठेवतो आणि नवीन input मिळाल्यावर ते चित्र अद्ययावत करतो. येथे "model" म्हणजे जगाचे model; neural network नव्हे. सध्याच्या अर्थापेक्षा हा शब्द सुमारे चाळीस वर्षे जुना आहे आणि पहिल्यांदा वाचताना तो जवळजवळ सर्वांनाच गोंधळात टाकतो.

वीस मिनिटे motion आढळले नाही तर lights बंद करणारा home automation rule model-based असतो. तसे असणे आवश्यक आहे. "आत्ता motion नाही" आणि "21:40 पासून motion नाही" हे simple reflex agent साठी एकच input आहेत. त्यामुळे त्यांच्यातील फरक फक्त साठवलेली stateच दाखवू शकते.

LLM संदर्भातील आवृत्ती म्हणजे मागे memory store असलेला कोणताही agent. उदाहरणार्थ, rolling conversation summary किंवा agent प्रत्येक run च्या सुरुवातीला वाचत असलेली साधी markdown file. agent साठी स्थानिक memory service हीच कल्पना एका पॅकेजमध्ये देते. Mechanism बदलत नाही. Agent चे जगाबद्दलचे चित्र ते निर्माण करणाऱ्या event नंतरही टिकते.

State ची किंमत असते. जुनी झालेली fact ही कोणतीही fact नसण्यापेक्षा वाईट असते, कारण agent कोणतीही warning न देता आणि पूर्ण confidence ने तिच्यावर action घेतो. तुम्ही साठवलेल्या प्रत्येक गोष्टीला expire होण्याची किंवा पुन्हा तपासली जाण्याची पद्धत असणे आवश्यक आहे. अन्यथा agent March मध्ये decommission केलेल्या server बद्दल reasoning करत राहील.

तपासता येणाऱ्या स्थितीकडे नियोजन करणारे goal-based agents

goal-based agent ला लक्ष्य स्थिती दिली जाते. ती स्थिती गाठण्यासाठी आवश्यक कृतींचा क्रम तो शोधतो. त्याला शेवटी कोणत्या स्थितीत पोहोचायचे आहे यापासून तो मागे विचार करतो. त्यामुळे मार्ग आधीच लिहिलेला नसतो.

तुम्ही स्वतः चालवू शकता असे coding agent हे याचे सर्वात स्पष्ट उदाहरण आहे. "अयशस्वी test यशस्वी करा" यात कोणत्याही files किंवा पायऱ्या नमूद केलेल्या नसतात. agent test वाचतो, plan तयार करतो, काहीतरी संपादित करतो, test चालवतो, error वाचतो आणि पुन्हा प्रयत्न करतो. हा loop तो प्रत्यक्ष चालवू शकणाऱ्या तपासणीवर संपतो. म्हणून ही सूचना कार्य करते, पण "हा code सुधारित करा" कार्य करत नाही. agent ज्या goal चे मूल्यमापन करू शकतो, ते goal agent गाठू शकतो. ज्या goal चे मूल्यमापन करता येत नाही, ते खर्चासह अंतहीन loop बनते. तुमच्या स्वतःच्या VPS वर coding agent चालवणे हा loop तुमच्या laptop वर भार न टाकता सतत चालू ठेवता येईल अशा ठिकाणी नेते.

खर्च या भागात निर्माण होतो. प्रत्येक planning step म्हणजे आतापर्यंतचा history घेऊन होणारा आणखी एक model call. त्यामुळे दहा पायऱ्यांचे task हे एका पायरीच्या task च्या दहापट किमतीचे नसते; त्याहून अधिक खर्च येतो. महत्त्वाचे engineering म्हणजे loop ची रचना आणि तो थांबवणारी condition. याच विषयाला loop engineering वाहिलेले आहे.

एकापेक्षा अधिक चांगल्या उत्तरांमधून निवड करणारे utility-आधारित agents

Goal binary असतो. Utility हा score असतो. Utility-आधारित agent समोर अनेक स्वीकारार्ह outcomes असतात आणि तुम्ही लिहिलेल्या function नुसार सर्वाधिक score असलेला outcome तो निवडतो.

Working day सुरू होण्यापूर्वी पूर्ण होणे आवश्यक असलेले, पण uplink वर अतिभार न टाकणारे backup job ही utility समस्या आहे. येथे एकच योग्य उत्तर नसते; trade-off असतो. कोणत्या request साठी कोणते model वापरायचे हे ठरवताना price आणि answer quality यांचा ताळमेळ साधणारा router देखील याच प्रकारचा असतो.

Algorithm हा कठीण भाग नाही. प्रामाणिक utility function लिहिणे हा कठीण भाग आहे. फक्त cost वर score दिल्यास प्रत्येक request साठी सर्वात स्वस्त model निवडला जाईल, त्या एका request साठीही ज्याला महाग model आवश्यक होते. System तुम्ही नेमके जे मोजले आहे तेच optimise करते. मोजण्यासाठी सोपे होते म्हणून एखादी गोष्ट निवडली असेल, तर ही समस्या ठरते.

शिकणारे agents: बहुतेक लोकांकडे आधीपासून आहे असे गृहीत धरतात तो प्रकार

शिकणारा agent मागील परिणामांवरील feedback नुसार स्वतःचे वर्तन बदलतो. त्यासाठी परिणामांचे मूल्यांकन करणारी एक यंत्रणा आणि त्यानुसार policy बदलणारी दुसरी यंत्रणा आवश्यक असते.

फारच थोड्या self-hosted systems या व्याख्येत बसतात. मागील आठवड्यात त्याने लिहिलेल्या notes वाचणारा agent हा memory file असलेला model-based agent आहे. त्याचे weights समान असतात. त्याची policy समान असते. Retrieval म्हणजे learning नाही. हा फरक व्यावहारिक आहे: memory-based system मध्ये memory कोणी संपादित करेपर्यंत तीच चूक पुन्हा पुन्हा होते, तर learning system ने ती चूक पुन्हा करणे थांबवणे अपेक्षित असते.

तुम्हाला learning भाग हवा असल्यास, प्रथम evaluation तयार करा. Scored test set, त्यावर तुमच्या बदलाची एक run आणि तो बदल ठेवायचा की discard करायचा याचा निर्णय मिळून closed loop तयार होतो. या loop मध्ये learning component तुम्ही स्वतः असता. हे ऐकायला वाटते त्यापेक्षा धीमे आहे आणि self-hosted components वर आज कार्यरत असलेली हीच एकमेव आवृत्ती आहे. eval harness स्वतः host करणे याची सुरुवात इथून होते.

बहु-एजंट आणि श्रेणीबद्ध प्रणाली: प्रकार नव्हे, मांडणी

हे सहावे आणि सातवे प्रकार नाहीत. ते एजंटची मांडणी कशी केली आहे हे स्पष्ट करतात.

बहु-एजंट प्रणाली सामायिक environment मध्ये एकाच वेळी अनेक एजंट चालवते. उदाहरणार्थ, queue किंवा git repository हे असे environment असू शकते. Environment सामायिक असल्यामुळे एजंट त्यात एकमेकांच्या कामात अडथळा आणू शकतात. दोन एजंट एकाच file मध्ये बदल करणे ही नेहमीची failure स्थिती आहे. यावर lock किंवा work queue हा उपाय आहे. कोणताही prompt ही समस्या सोडवू शकत नाही.

श्रेणीबद्ध प्रणालीमध्ये workers च्या वर एक supervisor असतो. Supervisor task चे विभाजन करतो, त्याचे भाग workers ना देतो आणि परत आलेले परिणाम एकत्र करतो. कामाचे विभाजन करण्याच्या मानवी पद्धतीशी ती जुळत असल्यामुळे ही रचना लोकप्रिय आहे. मात्र supervisor ने वाचलेल्या प्रत्येक report सोबत त्याचा context वाढत असल्यामुळे ती खर्चिक ठरते. बहु-एजंट harness प्रत्यक्ष wiring कशी केली जाते हे दाखवते.

बहुतांश वेळा काम करणाऱ्या चार एजंटांपेक्षा एक एजंट सातत्याने काम करणारा चांगला.

प्रत्येक handoff मध्ये माहिती गहाळ होण्याची शक्यता असते. एका loop पासून सुरुवात करा. अडथळा निर्माण करणारी step नेमकी कोणती आहे हे सांगता येईल, तेव्हाच loop चे विभाजन करा.

जवळजवळ प्रत्येक वास्तविक प्रणाली hybrid का असते

तुम्ही स्वतः चालवू शकता अशा deployment agent चा विचार करा. Webhook त्याला सुरू करतो; ही reflex-आधारित क्रिया आहे. तो सध्याची release state वाचतो; हे model-based आहे. तो चालू version पासून target version पर्यंतच्या पायऱ्यांचे नियोजन करतो; हे goal-based आहे. तो सध्याच्या load वरून rollout window निवडतो; हे utility-based आहे. तो स्वतःची policy कधीही संपादित करत नाही; त्यामुळे तो learning-based नाही.

एकाच प्रणालीमध्ये taxonomy मधील चार rows एकाच वेळी वापरल्या जातात. त्यामुळे taxonomy चे खरे महत्त्व अंतिम product ला label देण्यात नसून design checklist म्हणून वापरण्यात आहे. प्रणाली चुकीचे वर्तन करत असेल, तर कोणता layer चुकीचा आहे हा उपयुक्त प्रश्न ठरतो. चुकीच्या event वर trigger होणे, stale state, कधीही pass न होणारी goal check आणि चुकीच्या outcome ला reward देणारा score हे चार वेगवेगळे bugs आहेत. त्यांचे fixes देखील चार वेगवेगळे असतात.

कोणत्या कामासाठी कोणता प्रकार योग्य आहे

• Trigger निश्चित आहे, response निश्चित आहे आणि पूर्वीचा इतिहास आवश्यक नाही: simple reflex.
• योग्य response पूर्वी काय घडले यावर अवलंबून असतो: model-based reflex.
• अंतिम स्थिती तपासता येते, परंतु तिथे पोहोचण्याचा मार्ग आधीच माहीत नसतो: 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 केल्यास server ला जवळजवळ कोणत्याही विशेष संसाधनांची गरज नसते आणि bill tokens च्या संख्येनुसार वाढतो. Goal-based agent साठी याचा अर्थ तुम्ही अनुमती दिलेल्या planning steps च्या संख्येनुसार खर्च वाढतो. त्यामुळे loop ला मर्यादा घाला.

Model स्वतःच्या hardware वर चालवल्यास, तुम्ही प्रत्यक्षात काय चालवू शकता हे RAM ठरवते. खालील आकडे August 2026 पर्यंत प्रकाशित झालेल्या 4-bit quantised weights च्या typical file sizes दाखवतात. त्याशेजारी एकूण 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 साठी weights सुमारे 4.9 GB असतात. 10 GB RAM असलेला box तो swapping शिवाय चालवतो. त्याच quantisation वरील 70B model साठी weights 43 GB असतात आणि सुमारे 64 GB RAM आवश्यक असते. या आकड्यांमध्ये एक गोष्ट समाविष्ट नाही: speed. GPU नसलेल्या VPS वर 4-bit मधील 8B model प्रति सेकंद single-digit tokens तयार करतो. रात्रभर queue मधील काम करणाऱ्या agent साठी ते पुरेसे असते. मात्र एखादी व्यक्ती उत्तराची वाट पाहत असेल, तर ते त्रासदायकपणे धीमे ठरते. Local inference batch work साठी ठेवा. Interactive भागांसाठी GPU किंवा API वापरा. स्वतः host करता येणाऱ्या AI agents ची shortlist मध्ये disk space देण्यास योग्य projects कोणते आहेत हे सांगितले आहे. 2026 मध्ये agents शिकण्यासाठीचा अभ्यासक्रम कोणत्या क्रमाने काय शिकावे हे सांगतो.

टॅक्सोनॉमी कुठे अपुरी ठरते

यात साधने किंवा परवानग्यांबद्दल काहीही सांगितलेले नाही. पाठ्यपुस्तकातील agents आकलन करतात आणि कृती करतात. तो अध्याय लिहिणाऱ्या कोणालाही production API token असलेल्या agent ची चिंता नव्हती. shell access असलेला goal-based agent आणि read-only database connection असलेला goal-based agent तक्त्याच्या एकाच ओळीत येतात; परंतु त्यांच्यामुळे निर्माण होणारा धोका पूर्णपणे वेगळा असतो. agent ने किती हुशारीने काम करावे हे ठरवण्यापूर्वी तो कोणत्या संसाधनांना स्पर्श करू शकतो हे ठरवा. तसेच त्याला credential देण्यापूर्वी AI agent पासून secrets कसे दूर ठेवायचे हे वाचा.

एखादी पायरी अयशस्वी झाल्यावर काय होते, याबद्दलही यात काहीही सांगितलेले नाही. वास्तविक agents त्यांच्या runtime पैकी बहुतांश वेळ errors हाताळण्यात घालवतात: rate limit किंवा model ला अपेक्षित नसलेली माहिती परत करणारे tool. तुमची system वापरण्यायोग्य आहे की नाही हे code ठरवते. टॅक्सोनॉमीमधील कोणतीही ओळ याचे वर्णन करत नाही.

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 अनेक स्वीकारार्ह परिणामांचे मूल्यांकन करून सर्वाधिक गुण मिळालेला परिणाम निवडतो. Learning agent feedback वरून स्वतःचे policy बदलतो; प्रत्यक्षात जवळजवळ कोणतेही self-hosted setup असे करत नाही.

साध्या automation साठी मी कोणता प्रकारचा AI agent वापरावा?

Simple reflex agent वापरा. प्रत्यक्षात याचा अर्थ fixed sequence सुरू करणारा webhook किंवा schedule असा होतो. योग्य response फक्त नुकत्याच आलेल्या input वर अवलंबून असेल, तर memory मुळे failure modes वाढतात आणि कोणतीही अतिरिक्त क्षमता मिळत नाही. मागील घडामोडी माहीत असणे आवश्यक असलेला एखादा decision तुम्ही स्पष्टपणे सांगू शकता, त्या टप्प्यावर model-based design वापरा.

मी माझे स्वतःचे AI agents VPS वर चालवू शकतो का?

होय. Orchestration layer हलका असल्यामुळे 2 vCPU आणि 4 GB RAM असलेला VPS workflow engine किंवा agent loop सहज चालवतो. खरा निर्णय model कुठे चालवायचा हा असतो. Hosted API वापरल्यास server लहान राहतो आणि खर्च tokens वर होतो. Local model साठी त्याच्या parameter count च्या प्रमाणात RAM आवश्यक असते. GPU नसल्यास तो प्रति सेकंद single-digit tokens निर्माण करतो. त्यामुळे तो chat window पेक्षा queued batch work साठी अधिक योग्य ठरतो.

Large language model स्वतःहून AI agent असतो का?

नाही. Model input text चे output text मध्ये रूपांतर करतो आणि त्यानंतर थांबतो. त्याला जगावर कृती करता येईल आणि त्याचा परिणाम पुन्हा input म्हणून देता येईल अशा loop मध्ये गुंडाळले, तेव्हा तो agent बनतो. यासाठी तो call करू शकेल अशी tools आणि loop कधी थांबवायचा हे सांगणारी condition आवश्यक असते. Wrapper हाच agent असतो. Model हा त्यातील एक component असतो.

मला multi-agent system आवश्यक आहे का?

सहसा नाही. अनेक tools असलेला एकच loop बहुतेक कामांसाठी पुरेसा असतो आणि त्याचे debugging करणे खूप सोपे असते. एखाद्या task चे भाग खरोखर स्वतंत्र असतील आणि एकाच वेळी चालू शकत असतील, किंवा एखाद्या भागासाठी वेगळा model आवश्यक असेल, तेव्हा multiple agents उपयुक्त ठरतात. मात्र coordination ची किंमत मोजावी लागते: shared state आणि प्रत्येक worker चा report वाचल्यामुळे वाढत जाणारा context असलेला supervisor. दुसरा agent तेव्हाच जोडा, जेव्हा धीमा असलेला step तुम्ही स्पष्टपणे दाखवू शकता.