AI agent வகைகள்: முழுமையான விளக்கம் மற்றும் வழிகாட்டி

AI agent-களின் வகைகள்

AI agent-களின் வகைகள் ஒரு குறிப்பிட்ட வகைப்பாட்டியலில் (taxonomy) இருந்து வருகின்றன: simple reflex, model-based reflex, goal-based, utility-based, மற்றும் learning agents. ஒவ்வொரு பெயரும் ஒரு விஷயத்தை விவரிக்கிறது: அந்த agent எவ்வளவு தகவல்களை நினைவில் கொள்கிறது மற்றும் செயல்படுவதற்கு முன்பு எவ்வளவு தூரம் திட்டமிடுகிறது என்பதுதான் அது. multi-agent மற்றும் hierarchical ஆகிய இரண்டு கூடுதல் சொற்கள், ஒரு தனி agent எவ்வாறு முடிவெடுக்கிறது என்பதை விட, பல agent-கள் எவ்வாறு ஒன்றோடொன்று இணைக்கப்பட்டுள்ளன என்பதை விவரிக்கின்றன.

இந்த பட்டியல் நீங்கள் பயன்படுத்திய எந்தவொரு model-ஐ விடவும் பழமையானது. இது AI-க்கான தரப்படுத்தப்பட்ட பாடப்புத்தகத்திலிருந்து வந்தது. இது இன்றும் உங்கள் வடிவமைப்பைத் தீர்மானிக்கும் கேள்வியைக் கேட்பதால், large language models-ன் வருகைக்குப் பிறகும் நிலைத்திருக்கிறது: ஒரு காரியத்தைச் செய்வதற்கு முன்பு இந்த agent-க்கு என்ன தெரிய வேண்டும்? ஒரு agent எங்கு முடிகிறது மற்றும் ஒரு chat assistant எங்கு தொடங்குகிறது என்பதை நீங்கள் இன்னும் கண்டறிய முயல்கிறீர்கள் என்றால், முதலில் AI agent-க்கும் அது இயங்கும் LLM-க்கும் உள்ள வேறுபாடு என்பதைப் படிக்கவும். இந்தப் பக்கம் அந்த எல்லைக்கு அப்பால் தொடங்குகிறது.

எளிய ரிஃப்ளெக்ஸ் ஏஜெண்டுகள்: ஒரு நிபந்தனை, ஒரு செயல்

ஒரு எளிய ரிஃப்ளெக்ஸ் ஏஜெண்ட் தற்போதைய உள்ளீட்டை (input) ஒரு செயலுடன் இணைக்கிறது, ஆனால் முன்னதாக நடந்த எதையும் நினைவில் கொள்வதில்லை. வெப்பநிலை 25-க்கு மேல் இருந்தால், விசிறியை ஆன் செய்யவும். இதுவே அதன் முழுமையான செயல்பாட்டு முறை.

நீங்கள் நிச்சயமாக இதுபோன்ற ஒன்றை இயக்கியிருப்பீர்கள். ஒரு webhook மூலம் n8n workflow-ஐத் தூண்டுவது, படிவத் தரவை (form submission) வாசித்து அதை ஒரு database-ல் பதிவு செய்வது போன்றவை எளிய ரிஃப்ளெக்ஸ் ஏஜெண்டுகளே. இடையில் ஒரு language model அந்தத் தரவை வகைப்படுத்தினாலும், அது எளிய ஏஜெண்டாகவே நீடிக்கிறது. ஒரு மணி நேரத்திற்கு முன்பு அது என்ன செய்தது என்று கேட்டால், அதற்குப் பதில் தெரியாது; ஏனெனில் அந்தத் தகவலை அது சேமித்து வைக்கவில்லை.

மக்கள் எதிர்பார்ப்பதை விட இத்தகைய ஏஜெண்டுகள் பெரும்பாலும் சரியாகச் செயல்படுகின்றன. இவற்றை இயக்குவது மலிவானது, மேலும் இவற்றின் தோல்வியைக் கண்டறிவது எளிது: நிபந்தனை பொருந்தியதா அல்லது இல்லையா என்பது மட்டுமே விஷயம். "X வரும்போது, Y-ஐச் செய்" என்பதே வேலையாக இருக்கும்போது, நினைவகத்தைச் சேர்ப்பது தவறுகளுக்கு வழிவகுக்குமே தவிர, எந்தப் பயனும் தராது. webhook மூலம் தூண்டப்படும் n8n ஏஜெண்ட் என்பது இந்த வகைப்பாட்டின் ஒரு பகுதியாகும், இது ஒரு பயனர் இடைமுகத்தைக் (user interface) கொண்டுள்ளது.

சரியான செயல் என்பது வரலாற்றைச் சார்ந்து இருக்கும்போது, இந்த ஏஜெண்ட் தோல்வியடைகிறது. thread state இல்லாத ஒரு reply bot, மூன்றாவது செய்தியில் முரண்பாடான பதிலைத் தரும். ஏனெனில், முதல் இரண்டு செய்திகளும் அதன் உள்ளீட்டின் ஒரு பகுதியாக இருக்கவில்லை.

Model-based reflex agents: நிகழ்வுகளுக்கு இடையே நிலையைப் பராமரித்தல்

Model-based reflex agent என்பது தனது சூழலைப் பற்றிய ஒரு அகநிலை பிம்பத்தை (internal picture) வைத்திருக்கும்; புதிய உள்ளீடுகள் வரும்போது அந்த பிம்பத்தைப் புதுப்பித்துக் கொள்ளும். இங்கு "model" என்பது உலகத்தைப் பற்றிய ஒரு மாதிரியைக் குறிக்கிறதே தவிர, neural network-ஐ அல்ல. இந்தச் சொல் தற்போதைய பயன்பாட்டிற்கு நாற்பது ஆண்டுகளுக்கு முன்பே உருவானது, எனவே இதைப் படிக்கும் பலருக்கும் ஆரம்பத்தில் குழப்பம் ஏற்படலாம்.

இருபது நிமிடங்கள் அசைவு ஏதும் இல்லை என்றால் விளக்குகளை அணைக்கும் ஒரு home automation விதி, model-based வகையைச் சேர்ந்தது. அது அவ்வாறுதான் இருக்க வேண்டும். ஒரு எளிய reflex agent-க்கு "தற்போது அசைவு இல்லை" என்பதும், "21:40 முதல் அசைவு இல்லை" என்பதும் ஒரே மாதிரியான உள்ளீடுகளே. எனவே, சேமிக்கப்பட்ட நிலை (stored state) மட்டுமே அவற்றுக்கு இடையேயான வேறுபாட்டை உணர்த்தும்.

LLM பதிப்பில், பின்னால் ஒரு memory store கொண்ட எந்தவொரு agent-ம் இதையே செய்கிறது: ஒரு தொடர்ச்சியான உரையாடல் சுருக்கம் அல்லது ஒவ்வொரு முறை இயங்கும்போதும் agent படிக்கும் ஒரு plain markdown கோப்பு. A local memory service for an agent என்பது அந்த யோசனையின் தொகுக்கப்பட்ட வடிவம். அதன் செயல்முறை மாறுவதில்லை. அந்த நிகழ்வை உருவாக்கியதை விட, உலகத்தைப் பற்றிய agent-ன் பிம்பம் நீண்ட காலம் நிலைத்திருக்கும்.

நிலைத்தன்மைக்கு (state) ஒரு விலை உண்டு. ஒரு பழைய தகவல், தகவல் இல்லாததை விட மோசமானது. ஏனெனில், agent அந்தத் தகவலை முழு நம்பிக்கையுடன், எந்த எச்சரிக்கையும் இன்றி செயல்படுத்துகிறது. நீங்கள் சேமிக்கும் எதற்கும் காலாவதியாகும் வசதி அல்லது மீண்டும் சரிபார்க்கும் வசதி இருக்க வேண்டும்; இல்லையெனில், மார்ச் மாதமே decommission செய்யப்பட்ட ஒரு server-ஐப் பற்றி agent தொடர்ந்து சிந்தித்துக் கொண்டிருக்கும்.

இலக்கு சார்ந்த முகவர்கள் (Goal-based agents): நீங்கள் சரிபார்க்கக்கூடிய நிலையை நோக்கிய திட்டமிடல்

இலக்கு சார்ந்த முகவர் (goal-based agent) ஒரு இலக்கு நிலையைப் பெற்று, அதை அடைவதற்கான செயல்பாட்டு வரிசையைத் தேடுகிறது. இது அடைய வேண்டிய இடத்திலிருந்து பின்னோக்கிச் செயல்படுவதால், அதற்கான பாதை முன்கூட்டியே எழுதப்படுவதில்லை.

ஒரு கோடிங் முகவர் (coding agent) நீங்களே இயக்கிப் பார்க்கக்கூடிய மிகத் தெளிவான உதாரணம். "தோல்வியடையும் சோதனையை வெற்றி பெறச் செய்" (Make the failing test pass) என்ற கட்டளையில் எந்தக் கோப்புகளோ அல்லது படிகளோ குறிப்பிடப்படவில்லை. முகவர் சோதனையைப் படித்து, ஒரு திட்டத்தை உருவாக்கி, ஏதோ ஒன்றை மாற்றியமைத்து, சோதனையை இயக்கி, பிழையைப் படித்து, மீண்டும் முயற்சிக்கிறது. இந்தச் சுழற்சி (loop) அது உண்மையில் செயல்படுத்தக்கூடிய ஒரு சரிபார்ப்புடன் முடிவடைகிறது; இதனால்தான் அந்த அறிவுறுத்தல் வேலை செய்கிறது, ஆனால் "இந்தக் குறியீட்டை மேம்படுத்து" (improve this code) என்பது வேலை செய்வதில்லை. முகவரால் மதிப்பீடு செய்யக்கூடிய இலக்கு, அந்த முகவரால் அடையக்கூடிய இலக்காகும். மதிப்பீடு செய்ய முடியாத ஒரு இலக்கு, கட்டணத்துடன் கூடிய முடிவற்ற சுழற்சியாக மாறிவிடும். உங்கள் சொந்த VPS-ல் கோடிங் முகவரை இயக்குதல் அந்தச் சுழற்சியை உங்கள் மடிக்கணினியை ஆக்கிரமிக்காமல் இயங்கக்கூடிய இடத்தில் வைக்கிறது.

செலவு இந்த வரிசையில் உள்ளது. ஒவ்வொரு திட்டமிடல் படியும் இதுவரை நடந்த வரலாற்றைச் சுமந்து செல்லும் மற்றொரு model call ஆகும். எனவே, பத்து படிகளைக் கொண்ட ஒரு பணி, ஒரு படியின் விலையை விட பத்து மடங்கு அதிகம்; அதைவிடவும் அதிகமாக இருக்கும். சுழற்சியின் வடிவம் மற்றும் அதை நிறுத்தும் நிபந்தனை ஆகியவற்றின் வடிவமைப்பே மிக முக்கியமானது. இதுவே loop engineering-ன் பொருளாகும்.

பயன்பாட்டு அடிப்படையிலான முகவர்கள் (Utility-based agents): பல சிறந்த விடைகளுக்கு இடையே தேர்ந்தெடுத்தல்

இலக்கு என்பது இரும (binary) தன்மையுடையது. பயன்பாடு (Utility) என்பது ஒரு மதிப்பெண் ஆகும். பயன்பாட்டு அடிப்படையிலான முகவர், ஏற்றுக்கொள்ளக்கூடிய பல முடிவுகளை எதிர்கொண்டு, நீங்கள் எழுதிய செயல்பாட்டின் கீழ் அதிக மதிப்பெண் பெறும் ஒன்றை மட்டும் தேர்ந்தெடுக்கிறது.

வேலை நாள் தொடங்குவதற்கு முன்பே, uplink-ஐ முழுமையாகப் பயன்படுத்தாமல் (saturate செய்யாமல்) முடிக்க வேண்டிய ஒரு backup பணி என்பது ஒரு பயன்பாட்டுச் சிக்கலாகும். இதில் ஒரே ஒரு சரியான விடை என்று எதுவுமில்லை, ஒரு சமரசம் (trade-off) மட்டுமே உள்ளது. எந்த மாதிரியான (model) கோரிக்கையை எந்த மாதிரி கையாள வேண்டும் என்று தீர்மானிக்கும் ஒரு router, விலையையும் விடையின் தரத்தையும் ஒப்பிட்டுப் பார்ப்பதும் இதே போன்ற அமைப்பைக் கொண்டதுதான்.

இதற்கான அல்காரிதத்தை உருவாக்குவது கடினமான பகுதி அல்ல. நேர்மையான பயன்பாட்டுச் செயல்பாட்டை (utility function) எழுதுவதுதான் கடினம். செலவை மட்டும் அடிப்படையாகக் கொண்டு மதிப்பெண் வழங்கினால், ஒவ்வொரு கோரிக்கைக்கும் மலிவான மாதிரியையே நீங்கள் பெறுவீர்கள்; இதில் விலையுயர்ந்த மாதிரி தேவைப்பட்ட கோரிக்கையும் அடங்கும். நீங்கள் எதை அளவிடுகிறீர்களோ, அதைத்தான் இந்த அமைப்பு மேம்படுத்தும். ஆனால், எளிதாக அளவிட முடியும் என்பதற்காகவே ஒரு காரணியைத் தேர்ந்தெடுத்தால், அதுவே ஒரு சிக்கலாகிவிடும்.

கற்றல் முகவர்கள் (Learning agents): பெரும்பாலானோர் தங்களிடம் ஏற்கனவே இருப்பதாகக் கருதும் வகை

ஒரு கற்றல் முகவர், கடந்த கால முடிவுகளின் பின்னூட்டத்தைக் கொண்டு தனது நடத்தையை மாற்றிக்கொள்கிறது. இதற்கு விளைவை மதிப்பிடும் ஒரு கருவியும், அதற்கேற்ப கொள்கையை (policy) மாற்றும் ஒரு அமைப்பும் தேவை.

சுயமாக இயங்கும் (self-hosted) மிகச் சில அமைப்புகள் மட்டுமே இந்தத் தகுதிக்கு உட்பட்டவை. கடந்த வாரம் எழுதிய குறிப்புகளைப் படிக்கும் ஒரு முகவர், நினைவகக் கோப்பைக் கொண்ட ஒரு model-based முகவர் மட்டுமே. அதன் weights மாறாமல் இருக்கும். அதன் கொள்கையும் மாறாமல் இருக்கும். தகவலை மீட்டெடுப்பது (retrieval) என்பது கற்றல் அல்ல; இதற்கான நடைமுறை வேறுபாடு முக்கியமானது: நினைவகத்தை அடிப்படையாகக் கொண்ட ஒரு அமைப்பு, அதன் நினைவகத்தில் மாற்றம் செய்யப்படாதவரை அதே தவறைத் தொடர்ந்து செய்துகொண்டே இருக்கும். ஆனால், ஒரு கற்றல் அமைப்பு அந்தத் தவறைத் தவிர்க்க வேண்டும்.

உங்களுக்குக் கற்றல் திறன் தேவைப்பட்டால், முதலில் மதிப்பீட்டு முறையை (evaluation) உருவாக்குங்கள். மதிப்பெண் வழங்கப்பட்ட ஒரு சோதனைத் தொகுப்பு (scored test set), அதில் நீங்கள் செய்யும் மாற்றத்தைச் சோதித்தல், அந்த மாற்றத்தைத் தக்கவைப்பதா அல்லது நீக்குவதா என்ற முடிவு - இவை அனைத்தும் ஒரு மூடிய சுழற்சியாகும் (closed loop). இதில் நீங்களே கற்றல் காரணியாகச் செயல்படுகிறீர்கள். இது கேட்பதற்கு மெதுவாகத் தோன்றினாலும், தற்போது சுயமாக இயங்கும் அமைப்புகளில் செயல்படக்கூடிய ஒரே வழிமுறை இதுதான். மதிப்பீட்டு அமைப்பைச் சுயமாக இயக்குதல் (Self-hosting an eval harness) என்பதிலிருந்து இதற்கான தொடக்கம் அமைகிறது.

Multi-agent மற்றும் hierarchical அமைப்புகள்: வகைகள் அல்ல, ஏற்பாடுகள்

இவை ஆறாவது மற்றும் ஏழாவது வகை அல்ல. இவை agents எவ்வாறு அமைக்கப்படுகின்றன என்பதை விவரிக்கின்றன.

ஒரு multi-agent அமைப்பு, queue அல்லது git repository போன்ற பகிரப்பட்ட சூழலில் ஒரே நேரத்தில் பல agents-ஐ இயக்குகிறது. சூழல் பகிரப்படுவதால், அவற்றுக்கிடையே மோதல் ஏற்படுகிறது. ஒரே கோப்பை இரண்டு agents திருத்துவது பொதுவான தோல்வியாகும்; இதற்கு lock அல்லது work queue மூலம் தீர்வு காணலாம். எந்தவொரு prompt-உம் இதைத் தீர்க்காது.

ஒரு hierarchical அமைப்பு, பணியாளர்களுக்கு மேலே ஒரு supervisor-ஐ வைக்கிறது. அந்த supervisor ஒரு பணியைப் பிரித்து, அதன் பகுதிகளை வழங்கி, திரும்ப வரும் முடிவுகளை ஒருங்கிணைக்கிறது. மக்கள் வேலையைப் பிரிக்கும் முறைக்கு இது ஒத்துப்போவதால், இது பிரபலமாக உள்ளது. ஆனால், ஒவ்வொரு அறிக்கையைப் படிக்கும்போதும் supervisor-ன் context வளர்வதால், இது அதிக செலவு பிடிக்கும் முறையாகிறது. A multi-agent harness அந்த இணைப்பை நடைமுறையில் காட்டுகிறது.

பெரும்பாலும் வேலை செய்யும் நான்கு agents-ஐ விட, சரியாக வேலை செய்யும் ஒரு agent சிறந்தது.

ஒவ்வொரு handoff-உம் தகவல்கள் இழக்கப்படக்கூடிய ஒரு இடமாகும். ஒரு loop-உடன் தொடங்குங்கள். எந்தப் படிநிலை தடையாக (bottleneck) உள்ளது என்று உங்களால் பெயரிட முடிந்தால் மட்டுமே அதை இரண்டாகப் பிரியுங்கள்.

ஏன் கிட்டத்தட்ட அனைத்து நிஜ உலக அமைப்புகளும் கலப்பினமாக (hybrid) உள்ளன

நீங்கள் நீங்களே இயக்கும் ஒரு deployment agent-ஐக் கருத்தில் கொள்ளுங்கள். ஒரு webhook அதைத் தொடங்குகிறது, இது reflex வகையைச் சார்ந்தது. இது தற்போதைய release நிலையை வாசிக்கிறது, இது model-based வகையைச் சார்ந்தது. இது இயங்கும் பதிப்பிலிருந்து இலக்கு பதிப்பிற்குச் செல்வதற்கான படிகளைத் திட்டமிடுகிறது, இது goal-based வகையைச் சார்ந்தது. இது தற்போதைய சுமையிலிருந்து rollout காலத்தைத் தேர்ந்தெடுக்கிறது, இது utility-based வகையைச் சார்ந்தது. இது தனது சொந்தக் கொள்கையை ஒருபோதும் மாற்றியமைப்பதில்லை, எனவே இது கற்றல் (learning) திறன் கொண்டதல்ல.

ஒரே அமைப்பு, ஒரே நேரத்தில் வகைப்பாட்டின் (taxonomy) நான்கு வரிசைகளையும் கொண்டுள்ளது. இந்த வகைப்பாடு ஒரு முடிக்கப்பட்ட தயாரிப்பிற்கான பெயராக இல்லாமல், ஒரு வடிவமைப்பு சரிபார்ப்புப் பட்டியலாக (design checklist) தனது பயனை நிரூபிக்கிறது. அமைப்பு சரியாகச் செயல்படாதபோது, எந்த அடுக்கு (layer) தவறானது என்று கேட்பதே பயனுள்ள கேள்வியாகும். தவறான நிகழ்வில் தூண்டப்பட்ட (trigger) ஒரு செயல், காலாவதியான ஒரு நிலை (state), ஒருபோதும் நிறைவேற முடியாத இலக்கு சரிபார்ப்பு (goal check), மற்றும் தவறான முடிவிற்கு வெகுமதி அளிக்கும் ஒரு மதிப்பீடு (score) ஆகிய நான்கும் நான்கு வெவ்வேறு பிழைகள், அவற்றுக்கு நான்கு வெவ்வேறு தீர்வுகள் தேவை.

எந்த வகை எந்தப் பணிக்கு ஏற்றது

• நிலையான தூண்டுதல், நிலையான பதில், வரலாறு தேவையில்லை: simple reflex.
• சரியான பதில் முன்னதாக நடந்தவற்றைப் பொறுத்தது: model-based reflex.
• இறுதி நிலையைச் சரிபார்க்க முடியும், ஆனால் பாதை முன்கூட்டியே தெரியவில்லை: goal-based.
• பல ஏற்புடைய முடிவுகள் மற்றும் அவற்றுக்கிடையே ஒரு சமரசம் தேவைப்படுகிறது: utility-based.
• காலப்போக்கில் முடிவுகள் மேம்பட வேண்டும்: ஒரு eval loop-ஐ உருவாக்குங்கள், மேலும் நீங்களே கற்றல் அங்கமாக (learning component) இருப்பதை ஏற்றுக்கொள்ளுங்கள்.

இந்த முகவர்களை (agents) நீங்களே ஹோஸ்ட் செய்ய முடியுமா, அதன் செலவு என்ன?

ஆம், இதற்கான செலவு இரண்டு பகுதிகளாகப் பிரியும். Orchestration செலவு குறைவு. ஒரு n8n instance அல்லது Python-ல் இயங்கும் agent loop தனது பெரும்பாலான நேரத்தை network அழைப்புகளுக்காகக் காத்திருப்பதிலேயே செலவிடுகிறது, எனவே 2 vCPU மற்றும் 4 GB RAM இதற்குப் போதுமானது. செலவு என்பது model-ஐப் பொறுத்தே அமைகிறது.

முகவர் ஒரு hosted API-ஐ அழைத்தால், server-க்கு மிகக் குறைந்த வளங்களே தேவைப்படும், மேலும் கட்டணம் tokens-ன் எண்ணிக்கையைப் பொறுத்து அமையும். இலக்கை அடிப்படையாகக் கொண்ட முகவருக்கு, நீங்கள் அனுமதிக்கும் planning steps-ன் எண்ணிக்கையைப் பொறுத்து செலவு கூடும், எனவே loop-க்கு ஒரு வரம்பை (cap) நிர்ணயிக்கவும்.

நீங்கள் சொந்த hardware-ல் model-ஐ இயக்கினால், எதை இயக்க முடியும் என்பதை RAM தீர்மானிக்கிறது. ஆகஸ்ட் 2026 நிலவரப்படி, 4-bit quantised weights-க்கான பொதுவான கோப்பு அளவுகள் கீழே கொடுக்கப்பட்டுள்ளன. அவற்றுடன் மொத்த RAM தேவைக்கான மதிப்பீடும் உள்ளது, ஏனெனில் 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 எடையைக் கொண்டிருக்கும், மேலும் 10 GB RAM கொண்ட ஒரு கணினியில் அது swapping இன்றி இயங்கும். அதே quantisation-ல் ஒரு 70B model 43 GB எடையைக் கொண்டிருக்கும், அதற்கு சுமார் 64 GB RAM தேவைப்படும். இந்த எண்கள் எதைக் குறிப்பிடவில்லை என்பதைக் கவனியுங்கள்: வேகம். GPU இல்லாத ஒரு VPS-ல், 4-bit அளவில் ஒரு 8B model வினாடிக்கு ஒற்றை இலக்க tokens-ஐ மட்டுமே உருவாக்கும். இரவு முழுவதும் queue-ல் வேலை செய்யும் முகவருக்கு இது போதுமானது, ஆனால் பயனர் காத்திருக்கும் எந்தவொரு பணிக்கும் இது மிகவும் மெதுவாக இருக்கும். Batch வேலைகளுக்கு local inference-ஐப் பயன்படுத்துங்கள், interactive பணிகளுக்கு GPU அல்லது API-ஐப் பயன்படுத்துங்கள். சுயமாக ஹோஸ்ட் செய்யக்கூடிய AI முகவர்களின் பட்டியல் எந்தெந்தத் திட்டங்கள் disk இடத்திற்குத் தகுதியானவை என்பதை விளக்குகிறது, மேலும் 2026-ல் முகவர்களுக்கான கற்றல் பாதை எதை, எந்த வரிசையில் கற்க வேண்டும் என்பதை விவரிக்கிறது.

வகைப்பாடு (taxonomy) எங்கு பயனற்றுப் போகிறது

இது கருவிகள் அல்லது அனுமதிகள் (permissions) பற்றி எதையும் கூறுவதில்லை. பாடப்புத்தகங்களில் உள்ள முகவர்கள் (agents) உணர்கின்றன மற்றும் செயல்படுகின்றன. அந்த அத்தியாயத்தை எழுதிய எவரும், ஒரு முகவர் production API token-ஐ வைத்திருப்பது குறித்து கவலைப்படவில்லை. shell access கொண்ட ஒரு இலக்கு சார்ந்த முகவரும் (goal-based agent), read-only database இணைப்பு மட்டும் கொண்ட ஒரு முகவரும் அட்டவணையின் ஒரே வரிசையில் அமர்கின்றனர், ஆனால் அவர்கள் முற்றிலும் மாறுபட்ட அபாயங்களைக் கொண்டுள்ளனர். ஒரு முகவர் எவ்வளவு புத்திசாலித்தனமாக இருக்க வேண்டும் என்று முடிவெடுப்பதற்கு முன், அது எவற்றை அணுகலாம் என்று முடிவெடுங்கள். அதற்கு ஒரு credential-ஐ வழங்கும் முன் AI முகவரிடமிருந்து ரகசியங்களை எவ்வாறு பாதுகாப்பது என்பதைப் படியுங்கள்.

ஒரு படிநிலை (step) தோல்வியடையும் போது என்ன நடக்கும் என்பது பற்றியும் இது எதையும் கூறுவதில்லை. உண்மையான முகவர்கள் தங்கள் இயக்க நேரத்தின் பெரும்பகுதியை பிழைகளைக் கையாளுவதிலேயே செலவிடுகின்றன: ஒரு rate limit, அல்லது மாதிரி (model) எதிர்பாராத ஒன்றை வழங்கிய ஒரு கருவி. அந்த code தான் உங்கள் system பயன்படுத்தக்கூடியதா என்பதைத் தீர்மானிக்கிறது, வகைப்பாட்டின் எந்த வரிசையும் அதை விவரிக்கவில்லை.

FAQ

AI agents-ன் ஐந்து வகைகள் யாவை?

Simple reflex, model-based reflex, goal-based, utility-based, மற்றும் learning agents. ஒரு agent செயல்படுவதற்கு முன்பு அதற்கு எவ்வளவு அறிவு உள்ளது என்பதைப் பொறுத்து இவை வரிசைப்படுத்தப்பட்டுள்ளன. ஒரு Simple reflex agent தற்போதைய உள்ளீட்டை (input) மட்டுமே கவனிக்கும். ஒரு Model-based agent தனது சூழலைப் பற்றிய நிலையை (state) நினைவில் வைத்திருக்கும். ஒரு Goal-based agent ஒரு இலக்கு நிலையை நோக்கித் திட்டமிடும். ஒரு Utility-based agent பல ஏற்றுக்கொள்ளக்கூடிய முடிவுகளை மதிப்பிட்டு, அதில் சிறந்ததைத் தேர்ந்தெடுக்கும். ஒரு Learning agent பின்னூட்டத்தின் (feedback) அடிப்படையில் தனது கொள்கையை மாற்றிக்கொள்ளும்; சுய-வழங்கல் (self-hosted) அமைப்புகளில் இது பெரும்பாலும் பயன்படுத்தப்படுவதில்லை.

எளிய தானியங்கி (automation) பணிகளுக்கு நான் எந்த வகை AI agent-ஐப் பயன்படுத்த வேண்டும்?

Simple reflex agent-ஐப் பயன்படுத்தலாம். நடைமுறையில் இது ஒரு webhook அல்லது ஒரு குறிப்பிட்ட வரிசையைத் தூண்டும் schedule ஆகும். சரியான பதில் வந்த உள்ளீட்டை மட்டுமே சார்ந்திருந்தால், நினைவகத்தைச் சேர்ப்பது தோல்விக்கான வாய்ப்புகளை மட்டுமே அதிகரிக்கும், கூடுதல் திறனை வழங்காது. இதற்கு முன்பு என்ன நடந்தது என்பதைத் தெரிந்துகொள்ள வேண்டிய ஒரு முடிவை நீங்கள் எடுக்கும்போது, model-based வடிவமைப்பிற்கு மாறலாம்.

எனது சொந்த AI agents-ஐ VPS-ல் இயக்க முடியுமா?

ஆம். இதன் orchestration அடுக்கு மிகவும் இலகுவானது, எனவே 2 vCPU மற்றும் 4 GB RAM ஒரு workflow engine அல்லது agent loop-ஐச் சிறப்பாக இயக்கும். மாதிரி (model) எங்கே இயங்குகிறது என்பதே முக்கியமான முடிவு. Hosted API-ஐப் பயன்படுத்தினால் server-ன் சுமை குறையும், ஆனால் token-களுக்கான செலவு ஏற்படும். உள்ளூர் மாதிரிக்கு (local model) அதன் parameter எண்ணிக்கைக்கு ஏற்ப RAM தேவைப்படும். GPU இல்லையெனில், அது வினாடிக்கு மிகக் குறைந்த token-களையே உருவாக்கும்; இது chat window-க்கு பதிலாக, வரிசைப்படுத்தப்பட்ட batch பணிகளுக்கு ஏற்றது.

ஒரு Large language model தானாகவே ஒரு AI agent-ஆ?

இல்லை. ஒரு மாதிரி உள்ளீட்டு உரையை வெளியீட்டு உரையாக மாற்றிவிட்டு நின்றுவிடும். அதைச் சுற்றி ஒரு loop-ஐ அமைத்து, அது உலகத்தோடு தொடர்பு கொண்டு, அதன் முடிவுகளை மீண்டும் உள்ளீடாக வழங்கும்போதுதான் அது agent-ஆக மாறுகிறது. இதற்கு அது அழைக்கக்கூடிய கருவிகளும் (tools), loop எப்போது நிற்க வேண்டும் என்பதைக் கூறும் நிபந்தனையும் தேவை. அந்த wrapper-தான் agent. மாதிரி என்பது அதற்குள் இருக்கும் ஒரு கூறு மட்டுமே.

எனக்கு multi-agent அமைப்பு தேவையா?

பொதுவாகத் தேவையில்லை. பல கருவிகளைக் கொண்ட ஒரு ஒற்றை loop பெரும்பாலான வேலைகளைச் செய்துவிடும், மேலும் அதைப் பிழைதிருத்தம் (debug) செய்வதும் எளிது. ஒரு பணியின் பகுதிகள் முற்றிலும் சுதந்திரமாக இருந்து ஒரே நேரத்தில் இயங்க வேண்டியிருந்தாலோ, அல்லது ஒரு பகுதிக்கு வேறு ஒரு மாதிரி தேவைப்பட்டாலோ மட்டுமே பல agents உதவும். இதில் ஒருங்கிணைப்புச் சிக்கல் உள்ளது: பகிரப்பட்ட நிலை (shared state) மற்றும் ஒவ்வொரு பணியாளரின் அறிக்கையையும் வாசிக்கும்போது அதன் context வளரும் ஒரு மேற்பார்வையாளர் (supervisor) தேவைப்படுவார். ஒரு பணி மெதுவாக நடக்கும்போது, அந்த இடத்தைக் கண்டறிந்து இரண்டாவது agent-ஐச் சேர்க்கவும்.