சொந்த VPS-ல் n8n AI Agent உருவாக்குவது எப்படி?

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

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

Chain இதற்கு நேர்மாறாகச் செயல்படுகிறது. ஒரு Basic LLM Chain-ல் நீங்களே படிகளைத் தீர்மானிக்கிறீர்கள், model வெறும் உரையை மட்டுமே நிரப்புகிறது. Agent-ல் model-தான் படிகளைத் தீர்மானிக்கிறது, எனவே ஒரே கேள்விக்கு இன்று ஒரு முறை model-ஐ அழைக்க வேண்டியிருக்கலாம், நாளை ஒன்பது முறை அழைக்க வேண்டியிருக்கலாம். இந்த ஒரு சிறிய வேறுபாடே இந்த வழிகாட்டியில் உள்ள ஒவ்வொரு அமைப்பையும் தீர்மானிக்கிறது.

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

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

docker compose exec n8n n8n --version

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

படி 1: தூண்டுதலைத் (trigger) தேர்ந்தெடுத்தல்

ஒரு உரையாடல் முகவருக்கு (conversational agent), Chat Trigger முனையைச் சேர்க்கவும். நீங்கள் உருவாக்கும்போது Make Chat Publicly Available என்பதை அணைத்து வைக்கவும், அப்போதுதான் எடிட்டரின் chat panel மூலம் மட்டுமே அதை அணுக முடியும். முகவர் தயாராகி, அங்கீகாரத்தை (authentication) முடிவு செய்த பிறகு அதை இயக்கவும்.

Chat Trigger முகவருக்கு chatInput என்ற புலத்தை (field) வழங்குகிறது. அந்தப் பெயர் படி 3-ல் முக்கியமானது, அதைத் தவறாகக் குறிப்பிடுவதுதான் முதல் தோல்விக்கு மிகப்பொதுவான காரணமாகும்.

கண்காணிப்பாளர் இல்லாத முகவருக்கு (unattended agent), அதற்குப் பதிலாக Schedule Trigger அல்லது Webhook முனையைப் பயன்படுத்தவும். இவை இரண்டுமே 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 சந்தாவிலிருந்து வேறுபட்டது. எனவே, முதல்முறை இயக்கும் முன்பே கணக்கில் billing அமைக்கப்பட்டிருப்பதை உறுதி செய்யவும்.

நிறுவனத்திற்கு ஒன்றாக அல்லாமல், ஒவ்வொரு agent-க்கும் தனித்தனியாக model-ஐத் தேர்வு செய்யவும். ஒரு தகவலைத் தேடித் தரும் ஒற்றை-கருவி (one-tool) agent-க்கு Haiku போதுமானது. ஜூலை 2026 நிலவரப்படி, இதன் விலை 1 மில்லியன் input tokens-க்கு $1 மற்றும் 1 மில்லியன் output tokens-க்கு $5 ஆகும். Agent பல கருவிகளைக் கொண்டு திட்டமிட வேண்டிய சூழல் ஏற்பட்டால், Sonnet-க்கு மாறவும். மலிவான model-ஐப் பயன்படுத்தி தவறான கருவியை நான்கு முறை அழைப்பதை விட, விலையுயர்ந்த model-ஐப் பயன்படுத்தி சரியான கருவியை ஒருமுறை அழைப்பதே சிறந்தது; இதுவே தேவையற்ற செலவைத் தவிர்க்க உதவும் வழி.

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

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

படி 3: ஏஜென்ட் பெறும் prompt

AI Agent நோடைத் திறக்கவும். Prompt பாராமீட்டரில் இரண்டு அமைப்புகள் உள்ளன.

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

முன்பக்கத்தில் ஒரு Webhook நோடு இருக்கும்போது, POST body ஆனது $json.body-ன் கீழ் அமையும். எனவே, prompt புலம் பின்வருமாறு அமையும்.

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: ஏஜெண்டிற்கு ஒரு கருவியை வழங்குதல்

கருவி (tool) துணை-நோட் இல்லாத AI Agent நோட் இயங்க மறுக்கும். ஒரு கருவியுடன் தொடங்குங்கள், ஏனெனில் சரியாகச் செயல்படும் ஒரு கருவி, சரியாக அமைக்கப்படாத நான்கு கருவிகளை விட அதிக விஷயங்களைக் கற்றுக்கொடுக்கும்.

ஏஜெண்டின் Tool இணைப்பில் ஒரு HTTP Request நோடை இணைக்கவும். சாதாரண HTTP Request நோடை அமைப்பது போலவே இதையும் அமைக்கவும், பின்னர் அந்த endpoint-ஐ முதலில் ஒரு shell மூலம் சோதிக்கவும்.

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

அந்த curl கட்டளை ஒரு பிழையையோ அல்லது HTML login பக்கத்தையோ காட்டினால், ஏஜெண்டும் தோல்வியடையும். இது URL அல்லது அங்கீகாரப் (authentication) பிரச்சினை என்றாலும், பார்ப்பதற்கு ஏஜெண்ட் மாடல் பிரச்சினை போலத் தோன்றும். இதை நோடில் சரிசெய்யாமல், shell-லிலேயே சரிசெய்யவும்.

கருவியின் Description புலம் உங்கள் சக ஊழியர்களுக்கான ஆவணப்படுத்தல் அல்ல. ஒரு கருவி பொருத்தமானதா என்பதைத் தீர்மானிக்க மாடல் படிக்கும் ஒரே விஷயம் இதுதான். என்ன பதில் கிடைக்கும் என்பதைத் தெளிவாகக் குறிப்பிடவும்: "Returns the current up or down state and the downtime duration for one monitored service, as JSON."

மாடல் கோரிக்கையின் ஒரு பகுதியை நிரப்ப அனுமதிக்க, $fromAI() expression-ஐப் பயன்படுத்தவும். இது AI Agent நோடுடன் இணைக்கப்பட்ட கருவிகளில் மட்டுமே செயல்படும், Code கருவியில் இது செயல்படாது.

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

இதன் ஆர்குமெண்ட்கள் key, பின்னர் விருப்பத்தேர்வாக description, type மற்றும் defaultValue ஆகும். கீ (key) 1 முதல் 64 எழுத்துகள் வரை இருக்க வேண்டும், இதில் எழுத்துகள், எண்கள், அடிக்கோடுகள் (underscores) மற்றும் ஹைபன்களைப் பயன்படுத்தலாம். வகை (type) என்பது string, number, boolean அல்லது json ஆகியவற்றில் ஒன்றாக இருக்க வேண்டும், மேலும் இது இயல்பாக string என அமையும். முழுமையான அழைப்பு கீழே உள்ளவாறு இருக்கும்.

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

இந்த கீ என்பது ஒரு குறிப்பு மட்டுமே, ஏற்கனவே உள்ள தரவிற்கான இணைப்பு அல்ல. $fromAI('service') என்பது எங்கிருந்தும் service என்ற புலத்தைப் படிப்பதில்லை. இது மாடலிடம் "ஒரு மதிப்பை உருவாக்கி அதற்கு service என்று பெயரிடு" என்று கூறுகிறது. மாடல் உரையாடல், உள்ளீட்டுத் தரவு மற்றும் பிற கருவி முடிவுகளைப் பார்த்து ஒரு மதிப்பைத் தேடும். ஒரு chat workflow-ல், அது பயனரிடமே இதைக் கேட்கக்கூடும்.

Web search என்பது பொதுவாகச் சேர்க்கப்படும் இரண்டாவது கருவியாகும். இதுவும் மற்றொரு HTTP endpoint என்பதால், நீங்கள் இந்த நோடை கட்டண search API-க்கு பதிலாக உங்கள் சொந்த SearXNG instance-க்கு இணைக்கலாம். ஆனால், அது கொண்டுவரும் ஒவ்வொரு பக்கத்தையும் நம்பகத்தன்மையற்ற உரையாகக் கருதி, உங்கள் prompt-க்குள் கையாள வேண்டும்.

படி 5: memory, மற்றும் agent ஏன் தகவல்களை மறக்கிறது

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

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

Context Window Length என்பது தரத்தை மட்டுமல்ல, செலவையும் தீர்மானிக்கும் காரணியாகும். ஏனெனில், நினைவில் கொள்ளப்பட்ட ஒவ்வொரு உரையாடலும் அடுத்தடுத்த அழைப்புகளின் போது input tokens-ஆக மீண்டும் அனுப்பப்படும். அதிக உரையாடல் கொண்ட agent-ல் 20 என்ற window அளவு இருந்தால், ஆரம்பத்தில் அனுப்பப்பட்ட அதே செய்திகளுக்கு நீங்கள் இருபது முறை கட்டணம் செலுத்த வேண்டியிருக்கும்.

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

படி 6: System Message

Agent-ன் Options பகுதியைத் திறந்து, ஒரு System Message-ஐச் சேர்க்கவும். இதுவே அந்தப் பணியின் விவரங்கள் (job description) அமையும் இடமாகும்; பணிப்பாய்வில் (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.

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

ஏஜென்ட் ஏன் சுழற்சியில் (loop) சிக்கிக்கொள்கிறது மற்றும் அதைத் தடுப்பது எப்படி

Options பிரிவின் கீழ் Max Iterations என்ற அமைப்பு உள்ளது, இதன் இயல்புநிலை மதிப்பு 10 ஆகும். ஒரு iteration என்பது ஒரு model அழைப்பு மற்றும் அதற்குத் திரும்பக் கிடைக்கும் tool முடிவு ஆகியவற்றை உள்ளடக்கியது. எனவே, ஒரு ஏஜென்ட் இயக்கம் என்பது ஒற்றை API அழைப்பு அல்ல; அது பத்து அழைப்புகள் வரை செல்லலாம். ஒவ்வொரு முறையும் வளர்ந்து வரும் உரையாடல் முழுவதையும் உள்ளீடாக (input) எடுத்துக்கொள்ளும்.

இதன் மதிப்பை குறைக்கவும். பெரும்பாலான ஒற்றை-கருவி (single-tool) ஏஜென்ட்கள் இரண்டு iteration-களிலேயே முடிந்துவிடும். 3 அல்லது 4 என்ற வரம்பு, தேவையற்ற சுழற்சியைத் தடுத்து, execution பட்டியலில் தெளிவாகத் தெரியும் வகையில் தோல்வியடையச் செய்யும்.

நீங்கள் பிழைத்திருத்தம் (debugging) செய்யும்போது, Return Intermediate Steps என்பதை ஆன் செய்யவும். அப்போதுதான் ஏஜென்ட் மேற்கொண்ட tool அழைப்புகள் இறுதி வெளியீட்டில் (final output) இடம்பெறும். இதன் மூலமே "model கருவியை அழைக்கவே இல்லை" என்பதற்கும் "கருவி பயனுள்ள எதையும் வழங்கவில்லை" என்பதற்கும் உள்ள வித்தியாசத்தை அறிய முடியும். பயன்பாட்டிற்கு (live) கொண்டு செல்வதற்கு முன் இதை ஆஃப் செய்யவும், ஏனெனில் அந்த விவரங்கள் இறுதிப் பயனருக்குத் தேவையற்ற தகவல்களாக இருக்கும்.

shell மூலம் ஒரு இயக்கம் எவ்வாறு நடைபெறுகிறது என்பதைக் கவனிக்கவும்.

docker compose logs -f n8n

கண்காணிப்பற்ற agent தேவையற்ற செலவுகளைச் செய்வதைத் தடுத்தல்

Chat Trigger-க்கு பின்னால் இயங்கும் agent-ஐ ஒரு மனிதர் கண்காணிப்பார்; பதில் தவறாகத் தெரிந்தால் அவர் அதை நிறுத்துவார். Schedule Trigger-க்கு பின்னால் இயங்கும் agent-ஐ யாரும் கண்காணிப்பதில்லை. இங்கு நீங்கள் கண்காணிப்பது licence செலவை அல்ல, model பயன்பாட்டுச் செலவையே. காரணம், agent, tool மற்றும் memory nodes அனைத்தும் இலவச self-hosted edition-ல் இயங்குகின்றன; paid key தேவைப்படும் features பெரும்பாலும் team மற்றும் governance தொடர்பானவையே. இதற்கான முழுமையான விளக்கம் always-on VPS-ல் AI agent செலவைக் கட்டுப்படுத்துதல் பகுதியில் உள்ளது. இங்கு பெரும்பாலான கட்டுப்பாட்டை நான்கு settings வழங்குகின்றன.

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

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

FAQ

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

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

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

பெரும்பாலான நேரங்களில் இது tool-ன் Description புலத்தினால் ஏற்படுகிறது. அந்த விளக்கங்களைப் படித்தே model எந்த tool-ஐப் பயன்படுத்த வேண்டும் என்பதைத் தீர்மானிக்கிறது. எனவே, "HTTP Request" போன்ற விளக்கம், அந்த tool எப்போது பயன்படும் என்பதை அதற்கு உணர்த்தாது. எந்தத் தரவு திரும்பக் கிடைக்கும் மற்றும் எந்தச் சூழலில் அது பயனுள்ளதாக இருக்கும் என்பதை விளக்கி அதை மீண்டும் எழுதவும். பின்னர், பதிலளிக்கும் முன் அந்த tool-ஐ அழைக்குமாறு Agent-க்கு அறிவுறுத்தும் வரியை System Message-ல் சேர்க்கவும்.

ஒரே கேள்வி ஒவ்வொரு முறையும் ஏன் வெவ்வேறு செலவை ஏற்படுத்துகிறது?

ஏனெனில் model எத்தனை படிகள் (steps) தேவை என்பதைத் தீர்மானிக்கிறது. ஒவ்வொரு சுழற்சியும் (iteration) இதுவரை நடந்த முழு உரையாடலையும், முந்தைய tool வெளியீடுகளையும் சேர்த்து மீண்டும் அனுப்புகிறது. எனவே, நான்கு சுழற்சிகள் எடுக்கும் ஒரு இயக்கம், ஒருமுறை அழைப்பதை விட நான்கு மடங்குக்கும் மேலான செலவை ஏற்படுத்தும். Max Iterations என்பது அதற்கான உச்ச வரம்பாகும், மேலும் Return Intermediate Steps ஒரு குறிப்பிட்ட இயக்கம் எத்தனை படிகளைப் பயன்படுத்தியது என்பதைக் காட்டுகிறது.

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

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