உங்கள் VPS-ல் n8n AI agent உருவாக்குவது எப்படி

n8n AI agent என்றால் என்ன, அது chain-இலிருந்து எவ்வாறு வேறுபடுகிறது

n8n AI agent என்பது, அதனுடன் sub-nodes இணைக்கப்பட்டுள்ள ஒரே AI Agent node ஆகும்: ஒரு chat model, ஒன்று அல்லது அதற்கு மேற்பட்ட tools, மேலும் விருப்பத்திற்குரிய memory. நீங்கள் ஒரு இலக்கை இயல்பான மொழியில் குறிப்பிடுகிறீர்கள். பின்னர் பதிலளிக்க முடியும் வரை எந்த tools-ஐ எந்த வரிசையில் அழைக்க வேண்டும் என்பதை model தீர்மானிக்கிறது. கீழே உள்ள அனைத்தும் அந்த ஒரே கருத்தைச் சுற்றியுள்ள configuration ஆகும்.

chain இதற்கு மாறாக செயல்படுகிறது. Basic LLM Chain-இல் நீங்கள் படிகளைத் தீர்மானிக்கிறீர்கள்; model உரையை மட்டும் நிரப்புகிறது. agent-இல் படிகளை model தீர்மானிக்கிறது. ஆகவே அதே கேள்விக்கு இன்று ஒரு model call தேவைப்படலாம்; நாளை ஒன்பது model calls தேவைப்படலாம். இந்த ஒரு வேறுபாடே இந்த வழிகாட்டியில் உள்ள ஒவ்வொரு setting-ஐயும் தீர்மானிக்கிறது.

நீங்கள் கட்டுப்படுத்தும் machine-இல் n8n ஏற்கனவே HTTPS-க்கு பின்னால் இயங்குகிறது என்று இது கருதுகிறது. அவ்வாறு இல்லையெனில், உண்மையான certificate உடன் Docker-இல் n8n-ஐ self-host செய்வது என்பதிலிருந்து தொடங்குங்கள். ஏனெனில் நீங்கள் சேமிக்கவிருக்கும் API key-க்கு, அந்த வழிகாட்டி வலியுறுத்தும் encryption-key backup தேவைப்படுகிறது. agent அல்லாத patterns, webhook summarizers மற்றும் scheduled classifiers ஆகியவற்றுக்கு Claude மற்றும் n8n workflow patterns என்பதைப் பார்க்கவும்.

இங்கு உள்ள field name-களை நம்புவதற்கு முன் உங்கள் version-ஐச் சரிபார்க்கவும். n8n, AI nodes-ஐ அடிக்கடி மாற்றுகிறது.

docker compose exec n8n n8n --version

இந்த வழிகாட்டியில் உள்ள பெயர்கள் July 2026 நிலவரப்படி n8n current stable-க்கு ஏற்ப உள்ளன. version 1.82.0 முதல், ஒவ்வொரு AI Agent node-மும் Tools Agent ஆக இயங்குகிறது. எனவே பழைய agent-type dropdown இனி இல்லை.

படி 1: trigger-ஐத் தேர்ந்தெடுக்கவும்

Conversational agent-க்கு Chat Trigger node-ஐச் சேர்க்கவும். நீங்கள் உருவாக்கிக் கொண்டிருக்கும் போது Make Chat Publicly Available விருப்பத்தை முடக்கி வைக்கவும். இதனால் editor-ன் chat panel மட்டுமே அதை அணுக முடியும். Agent தயாரானதும், authentication முறையைத் தீர்மானித்த பிறகு அதை இயக்கவும்.

Chat Trigger agent-க்கு chatInput என்ற field-ஐ வழங்குகிறது. படி 3-ல் அந்தப் பெயர் முக்கியமானது. அந்தப் பெயரைத் தவறாக அமைப்பதே தொடக்கத்தில் ஏற்படும் மிகவும் பொதுவான பிழையாகும்.

தானியக்கமாக இயங்கும் agent-க்கு அதற்குப் பதிலாக Schedule Trigger அல்லது Webhook node-ஐப் பயன்படுத்தவும். இவற்றில் எதுவும் chatInput-ஐ உருவாக்காது. எனவே prompt-ஐ நீங்களே எழுத வேண்டும்.

படி 2: model credential

Canvas-ல் AI Agent node-ஐ வைக்கவும். n8n உடனடியாக அதன் கீழே காலியான Chat Model connector-ஐக் காட்டும். அங்கு Anthropic Chat Model sub-node-ஐ இணைக்கவும்.

platform.claude.com தளத்தில் உள்ள Anthropic Console-ல், Settings-ஐத் திறந்து பின்னர் API Keys பகுதிக்குச் செல்லவும். அங்கிருந்து credential-ஐ உருவாக்கவும். key ஒருமுறை மட்டுமே காட்டப்படும். API பயன்பாட்டுக்குக் token அடிப்படையில் கட்டணம் விதிக்கப்படும். இது எந்த Claude.ai subscription-இலிருந்தும் தனித்த கட்டணமாகும். எனவே முதல் run-க்கு முன் account-ல் billing அமைக்கப்பட்டிருக்க வேண்டும்.

Model-ஐ நிறுவனம் முழுவதற்காக அல்ல, ஒவ்வொரு agent-க்காகத் தேர்ந்தெடுக்கவும். ஏதேனும் ஒன்றைத் தேடி அதன் முடிவைத் தெரிவிக்கும் ஒரு கருவி மட்டுமே கொண்ட agent, Haiku-ல் நன்றாக இயங்கும். July 2026 நிலவரப்படி, அதன் விலை 1 million input tokens-க்கு $1 மற்றும் 1 million output tokens-க்கு $5 எனக் குறிப்பிடப்பட்டுள்ளது. Agent-ல் பல tools இருந்து, அவற்றை அடிப்படையாகக் கொண்டு திட்டமிட வேண்டிய நிலை ஏற்பட்டால், Sonnet-க்கு மாற்றவும். நீங்கள் தவிர்க்க வேண்டிய தோல்வி நிலை இதுதான்: குறைந்த விலை model தவறான tool-ஐ நான்கு முறை அழைக்கிறது. சரியான tool-ஐ ஒருமுறை அழைக்கும் விலையுயர்ந்த model-ஐவிட இது அதிகச் செலவாகும்.

Sub-node-ன் options-ல் Maximum Number of Tokens-ஐ அமைக்கவும். Model உருவாக்கும் ஒவ்வொரு response-ன் நீளத்திற்கும் இது வரம்பு விதிக்கும். இதை பெரிய default மதிப்பிலேயே விட்டால், குழப்பமான ஒரு run மிக நீளமான பதிலை உருவாக்கி, அதற்கான கட்டணத்தை உங்களிடம் வசூலிக்கலாம்.

n8n docs-ல் குறிப்பிடப்படும், அனைவரையும் பாதிக்கும் ஒரு முக்கிய வரம்பு உள்ளது: sub-node-க்குள் உள்ள expressions எப்போதும் first input item-ஐ அடிப்படையாகக் கொண்டே resolve ஆகும்; ஒவ்வொரு item-க்கும் தனித்தனியாக resolve ஆகாது. ஒவ்வொரு item-க்கும் உரிய expressions-ஐ root node-ன் prompt fields-ல் வைக்கவும்.

படி 3: agent பெறும் prompt

AI Agent node-ஐத் திறக்கவும். Prompt parameter-க்கு இரண்டு அமைப்புகள் உள்ளன.

• Take from previous node automatically என்பது chatInput என்ற பெயருடைய incoming field-ஐ எதிர்பார்க்கிறது. Chat Trigger-க்கு பின்னால் இது சரியான தேர்வாகும்.
• Define below என்பது Prompt (User Message) field-ஐக் காட்டுகிறது. இதில் static text அல்லது expression-ஐ எழுதலாம். Schedule Trigger அல்லது Webhook node-க்கு பின்னால் இது சரியான தேர்வாகும்.

முன்புறத்தில் Webhook node இருந்தால், POST body $json.body-ன் கீழ் வரும். எனவே prompt field இவ்வாறு தோன்றும்.

Check the current status of {{ $json.body.service }} and tell me
whether it is up. If it is down, say for how long. No preamble.

படி 4: agent-க்கு ஒரு tool வழங்கவும்

Tool sub-node இல்லாத AI Agent node இயங்க மறுக்கும். முதலில் ஒரு tool-ஐ இணைக்கவும். பாதியாக configure செய்யப்பட்ட நான்கு tools-களைவிட, சரியாக இயங்கும் ஒரு tool அதிகத் தகவலை வழங்கும்.

HTTP Request node-ஐ agent-ன் Tool connector-க்கு இணைக்கவும். வழக்கமான HTTP Request node-ஐ configure செய்வது போலவே இதையும் configure செய்யவும். பின்னர் அந்த endpoint-ஐ முதலில் shell-இலிருந்து சோதிக்கவும்.

curl -s -H 'Accept: application/json' \
  https://status.example.com/api/status/database | head -c 400

அந்த curl error அல்லது HTML login page-ஐத் திருப்பி அளித்தால், agent-மும் தோல்வியடையும். அப்போது உண்மையில் URL அல்லது authentication பிரச்சினையாக இருந்தாலும், தோல்வி model பிரச்சினை போலத் தோன்றும். இதை node-இல் அல்ல, shell-இல் சரிசெய்யவும்.

Tool-ன் Description field உங்கள் சக ஊழியர்களுக்கான documentation அல்ல. இந்த tool பொருத்தமானதா என்பதை model தீர்மானிக்கும்போது படிக்கும் ஒரே தகவல் இதுதான். திரும்ப வரும் முடிவைத் தெளிவாகக் கூறும் எளிய வாக்கியமாக எழுதவும்: "ஒரு கண்காணிக்கப்படும் service-ன் தற்போதைய up அல்லது down நிலையும், downtime கால அளவும் JSON ஆகத் திருப்பி அளிக்கிறது."

Request-ன் ஒரு பகுதியை model நிரப்பச் செய்ய $fromAI() expression-ஐப் பயன்படுத்தவும். இது AI Agent node-க்கு இணைக்கப்பட்ட tools-இல் மட்டுமே செயல்படும். Code tool-இல் இது செயல்படாது.

{{ $fromAI('service', 'The name of the service to look up', 'string') }}

Arguments key, அதன் பின்னர் விருப்பத்தேர்வான description, type மற்றும் defaultValue ஆகும். key-யில் 1 முதல் 64 characters வரை இருக்க வேண்டும். அதில் letters, digits, underscores மற்றும் hyphens மட்டுமே பயன்படுத்தலாம். type என்பது string, number, boolean அல்லது json ஆகியவற்றில் ஒன்றாக இருக்க வேண்டும். இதன் default மதிப்பு string ஆகும். முழுமையான call இதுபோல் இருக்கும்.

{{ $fromAI('limit', 'How many records to return', 'number', 20) }}

key என்பது ஒரு குறிப்பு மட்டுமே; ஏற்கனவே உள்ள data-வைச் சுட்டும் reference அல்ல. $fromAI('service') எங்கிருந்தும் service என்ற field-ஐப் படிக்காது. அது model-க்கு "ஒரு value-ஐ உருவாக்கி, அதற்கு service என்று பெயரிடு" என்று தெரிவிக்கிறது. பின்னர் model conversation, input data மற்றும் பிற tool results ஆகியவற்றில் ஒன்றைத் தேடுகிறது. chat workflow-இல் அது user-ஐ நேரடியாகக் கேட்கலாம்.

படி 5: நினைவகம் மற்றும் agent ஏன் மறந்துவிடுகிறது

Memory sub-node இல்லையெனில், ஒவ்வொரு message-உம் எதுவும் இல்லாத நிலையிலிருந்து தொடங்கும். சமீபத்திய conversation-ஐ வைத்திருக்க Simple Memory sub-node-ஐ இணைக்கவும்.

இதில் இரண்டு parameters உள்ளன. Session Key எந்த conversation என்பதைத் தீர்மானிக்கிறது. எனவே வெவ்வேறு keys கொண்ட இரண்டு users-க்கு தனித்தனி histories கிடைக்கும். Context Window Length என்பது prompt-இல் மீண்டும் சேர்க்கப்படும் முந்தைய interactions-ன் எண்ணிக்கையாகும்.

Context Window Length, quality-ஐ மட்டும் அல்லாமல் cost-ஐயும் கட்டுப்படுத்துகிறது. நினைவில் வைக்கப்படும் ஒவ்வொரு turn-உம் பின்னர் செய்யப்படும் ஒவ்வொரு call-இலும் input tokens ஆக மீண்டும் அனுப்பப்படும். Chatty agent-இல் window 20 என அமைத்தால், தொடக்க messages-க்காக 20 முறை பணம் செலுத்த வேண்டியிருக்கும்.

n8n queue mode-இல் இயங்கும்போது, active production workflow-இல் Simple Memory செயல்படாது. ஏனெனில் history, shared store-இல் அல்லாமல் workflow-ன் சொந்த data-வில் சேமிக்கப்படுகிறது. Queue-mode instance-இல், அதற்குப் பதிலாக Postgres Chat Memory sub-node-ஐப் பயன்படுத்தவும். Main process மற்றும் workers இரண்டும் அணுகக்கூடிய database-ஐ அதனுடன் இணைக்கவும்.

படி 6: System Message

agent-இன் Options-ஐத் திறந்து, ஒரு System Message-ஐச் சேர்க்கவும். வேலை விவரம் இங்கே இடம்பெறும். Workflow-இல் அதிக தாக்கத்தை ஏற்படுத்தும் உரையும் இதுவாகும்.

You are an infrastructure status assistant. Always call the status
tool before answering a question about whether something is running.
Never guess. If the tool returns an error, say so and stop.

"Always call the status tool before answering" என்ற விதி இங்கே முக்கியப் பணியைச் செய்கிறது. இது இல்லாவிட்டால், பதில் ஏற்கனவே தெரியும் என்று கருதும் model, tool-ஐத் தவிர்த்து நினைவிலிருந்து பதிலளிக்கும். உங்கள் infrastructure மாறியவுடன் அந்தப் பதில் நம்பிக்கையுடன் வழங்கப்படும் தவறான பதிலாகிவிடும்.

agent ஏன் loop ஆகிறது, அதை எது நிறுத்துகிறது

Options பிரிவில் Max Iterations என்பதும் உள்ளது. இதன் இயல்புநிலை மதிப்பு 10. ஒரு iteration என்பது ஒரு model call மற்றும் context-க்கு மீண்டும் வழங்கப்படும் ஒரு tool result ஆகியவற்றைக் கொண்டது. எனவே, ஒரு agent run என்பது ஒரே API call அல்ல. அது அதிகபட்சம் 10 API calls ஆகும். ஒவ்வொரு call-லும் முழுமையாக வளர்ந்த conversation input ஆக எடுத்துக்கொள்ளப்படுகிறது.

அதன் மதிப்பைக் குறைக்கவும். பெரும்பாலான ஒற்றை-tool agents இரண்டு iterations-க்குள் முடிவடையும். 3 அல்லது 4 turns என்ற வரம்பு, கட்டுப்பாடின்றி தொடரும் loop-ஐ execution list-ல் காணக்கூடிய தெளிவான failure-ஆக மாற்றும்.

நீங்கள் debugging செய்யும் போது Return Intermediate Steps என்பதை இயக்கவும். அப்போது இறுதி output-ல் agent வழியில் செய்த tool calls-ம் சேரும். இதன் மூலம் “model tool-ஐ அழைக்கவே இல்லை” என்பதையும் “tool பயனுள்ள எதையும் return செய்யவில்லை” என்பதையும் வேறுபடுத்தலாம். Production-க்கு செல்லும் முன் இதை மீண்டும் அணைக்கவும். இல்லையெனில் அந்த steps end user-க்கு தேவையற்ற தகவலாக இருக்கும்.

Shell-லிருந்து ஒரு run நடைபெறுவதை monitor செய்யவும்.

docker compose logs -f n8n

கவனிக்கப்படாத agent அமைதியாக அதிகச் செலவு செய்வதைத் தடுப்பது

Chat Trigger-க்கு பின்னால் இயங்கும் agent-இல் ஒரு மனிதர் இருப்பார். பதில் தவறாகத் தெரிந்தால் அந்த மனிதர் agent-ஐ நிறுத்துவார். Schedule Trigger-க்கு பின்னால் இயங்கும் agent-ஐ யாரும் கண்காணிக்கமாட்டார்கள். இதற்கான முழுமையான விளக்கம் எப்போதும் இயங்கும் VPS-இல் AI agent செலவுக் கட்டுப்பாடு-இல் உள்ளது. இங்கு நான்கு அமைப்புகள் பெரும்பாலான பணிகளைச் செய்கின்றன.

• model sub-node-இல் Maximum Number of Tokens-க்கு வரம்பு அமைக்கவும். இதனால் எந்த ஒரு response-உம் அளவுக்கு அதிகமாக நீளாது.
• பணியை முடிக்கத் தேவையான குறைந்தபட்ச எண்ணிக்கையாக Max Iterations-ஐ அமைக்கவும்.
• tool responses-ஐச் சிறியதாக வைத்திருக்கவும். 4,000 வரிகள் கொண்ட JSON blob-ஐத் திருப்பி வழங்கும் tool, அதன் முழு உள்ளடக்கத்தையும் அடுத்த model call-இல் சேர்க்கும். அதே run-இல் நடைபெறும் அதன் பிந்தைய ஒவ்வொரு call-இலும் அந்த உள்ளடக்கம் சேர்க்கப்படும்.
• agent-க்கு schedule உண்மையில் தேவையா என்று சரிபார்க்கவும். ஒவ்வொரு ஐந்து நிமிடங்களுக்கும் இயங்கும் job, ஒரு நாளில் 288 முறை தொடங்கும். ஒரு run-க்கான செலவு எவ்வளவோ, அதைப் பெருக்க வேண்டிய எண்ணிக்கை இதுவாகும்.

நீங்கள் மாற்றங்களைச் செய்யும் போது workflow-ஐ deactivate செய்யவும். Schedule Trigger கொண்ட active workflow, n8n சேமித்துள்ள version-ஐ அடிப்படையாகக் கொண்டு தொடர்ந்து இயங்கும். அது உங்கள் திரையில் காணப்படும் version ஆக இருப்பது எப்போதும் உறுதி இல்லை.

FAQ

எனது AI Agent node ஏன் இயக்கப்பட மறுக்கிறது?

AI Agent node-க்கு chat model sub-node மற்றும் குறைந்தது ஒரு tool sub-node தேவை. model உள்ளது, ஆனால் tool இல்லை என்றால், எந்த API call-ஐயும் செய்வதற்கு முன்பே node தோல்வியடையும். ஒரு tool-ஐ, அது மிகவும் எளிமையானதாக இருந்தாலும், இணைத்து மீண்டும் இயக்கவும்.

agent பதிலளிக்கிறது, ஆனால் எனது tool-ஐ ஒருபோதும் அழைப்பதில்லை. என்ன தவறு?

பெரும்பாலும் காரணம் tool-ன் Description field ஆகும். model, அந்த descriptions-ஐப் படித்தே tools-ஐத் தேர்ந்தெடுக்கிறது. ஆகவே, "HTTP Request" போன்ற description, tool எப்போது பொருந்தும் என்பதை model-க்கு தெரிவிக்காது. எந்தத் தரவு திரும்ப வருகிறது, எந்தச் சூழலில் அது பயனுள்ளதாக இருக்கும் என்பதைக் குறிப்பிடும் வகையில் description-ஐ மாற்றவும். பின்னர், பதிலளிப்பதற்கு முன் அந்த tool-ஐ அழைக்குமாறு agent-க்கு அறிவுறுத்தும் ஒரு வரியை System Message-இல் சேர்க்கவும்.

ஒவ்வொரு run-இலும் அதே கேள்விக்கான செலவு ஏன் மாறுகிறது?

model எத்தனை steps பயன்படுத்த வேண்டும் என்பதைத் தேர்ந்தெடுப்பதால் இது நிகழ்கிறது. ஒவ்வொரு iteration-இலும், முந்தைய tool output உட்பட, அதுவரையிலான முழு conversation மீண்டும் அனுப்பப்படுகிறது. ஆகவே, நான்கு iterations எடுக்கும் run-ன் செலவு, ஒரே call-ன் செலவை நான்கு மடங்கு செய்ததைவிட அதிகமாக இருக்கும். Max Iterations இதற்கான உச்சவரம்பை நிர்ணயிக்கிறது. Return Intermediate Steps, குறிப்பிட்ட run உண்மையில் எத்தனை steps பயன்படுத்தியது என்பதைக் காட்டுகிறது.

எனது memory editor-இல் செயல்படுகிறது, ஆனால் production-இல் செயல்படவில்லை. என்ன மாறியது?

instance queue mode-இல் இயங்குகிறதா என்பதைச் சரிபார்க்கவும். Simple Memory, history-ஐ workflow-ன் சொந்த execution data-வில் சேமிக்கிறது. தனி worker process-க்கு ஒப்படைக்கப்பட்ட பிறகு அந்தத் தரவு நிலைத்திருக்காது. எனவே active production workflow அதன் history-ஐ இழக்கும். அதற்குப் பதிலாக Postgres Chat Memory sub-node-ஐப் பயன்படுத்தவும். இது ஒவ்வொரு worker-மும் பகிர்ந்து பயன்படுத்தும் database-ல் history-ஐச் சேமிக்கிறது.