n8n AI Agent स्वतःच्या VPS वर कसा तयार करावा

n8n AI agent म्हणजे काय आणि तो chain पेक्षा कसा वेगळा आहे

n8n AI agent हा त्याला जोडलेल्या sub-nodes असलेला एक AI Agent node असतो: एक chat model, एक किंवा अधिक tools आणि ऐच्छिक memory. तुम्ही plain language मध्ये उद्दिष्ट सांगता. त्यानंतर उत्तर देता येईपर्यंत model कोणते tools कोणत्या क्रमाने call करायचे ते ठरवतो. खालील सर्व माहिती या एका संकल्पनेभोवतीच्या configuration विषयी आहे.

Chain याच्या उलट पद्धतीने काम करते. Basic LLM Chain मध्ये तुम्ही steps ठरवता आणि model केवळ text भरतो. Agent मध्ये model steps ठरवतो. त्यामुळे तोच प्रश्न आज एक model call आणि उद्या नऊ model calls वापरू शकतो. या एकाच फरकामुळे या guide मधील प्रत्येक setting ठरते.

या माहितीमध्ये n8n तुमच्या नियंत्रणातील machine वर HTTPS मागे आधीपासून चालू आहे असे गृहीत धरले आहे. तसे नसल्यास प्रत्यक्ष certificate सह Docker वर n8n self-host करा येथून सुरुवात करा, कारण तुम्ही साठवणार असलेल्या API key साठी त्या guide मध्ये आवश्यक असलेला 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

या guide मधील नावे July 2026 मधील n8n current stable शी जुळतात. version 1.82.0 पासून प्रत्येक AI Agent node Tools Agent म्हणून चालतो. त्यामुळे जुना agent-type dropdown आता उपलब्ध नाही.

पायरी 1: ट्रिगर निवडा

संवादी एजंटसाठी Chat Trigger नोड जोडा. तुम्ही तयार करत असताना Make Chat Publicly Available बंद ठेवा, त्यामुळे फक्त एडिटरच्या चॅट पॅनेलमधूनच त्याच्यापर्यंत पोहोचता येईल. एजंट पूर्ण झाल्यावर आणि प्रमाणीकरणाची पद्धत ठरवल्यावर ते चालू करा.

Chat Trigger एजंटला chatInput नावाचे फील्ड देते. हे नाव पायरी 3 मध्ये महत्त्वाचे आहे. हे नाव चुकीचे देणे ही सुरुवातीच्या अपयशाची सर्वात सामान्य कारणे आहे.

स्वयंचलित एजंटसाठी त्याऐवजी Schedule Trigger किंवा Webhook नोड वापरा. यापैकी कोणतेही chatInput तयार करत नाही. त्यामुळे प्रॉम्प्ट तुम्हालाच लिहावा लागेल.

पायरी 2: मॉडेल क्रेडेन्शियल

कॅनव्हासवर AI Agent नोड ठेवा. n8n त्याखाली रिकामा Chat Model कनेक्टर लगेच दाखवते. तेथे Anthropic Chat Model सब-नोड जोडा.

platform.claude.com वरील Anthropic Console मध्ये Settings आणि त्यानंतर API Keys येथे क्रेडेन्शियल तयार करा. की फक्त एकदाच दाखवली जाते. API वापरासाठी प्रति टोकन शुल्क आकारले जाते. हे शुल्क कोणत्याही Claude.ai subscription पासून स्वतंत्र असते. त्यामुळे पहिला रन करण्यापूर्वी खात्यावर billing सेट केलेले असणे आवश्यक आहे.

मॉडेल प्रत्येक एजंटसाठी निवडा, संपूर्ण कंपनीसाठी नाही. एखादी माहिती शोधून ती कळवणारा एक-tool एजंट Haiku वर सहज चालतो. July 2026 नुसार त्याचे शुल्क प्रति दशलक्ष input tokens साठी $1 आणि प्रति दशलक्ष output tokens साठी $5 आहे. एजंटकडे अनेक tools असतील आणि त्यांना वापरण्याची योजना करावी लागणार असेल, तर Sonnet वापरा. तुम्ही टाळू इच्छित असलेली समस्या म्हणजे स्वस्त मॉडेलने चुकीच्या tool ला चार वेळा कॉल करणे. योग्य tool ला एकदाच कॉल करणाऱ्या महाग मॉडेलपेक्षा त्याचा खर्च जास्त होऊ शकतो.

सब-नोडच्या options मध्ये Maximum Number of Tokens सेट करा. यामुळे मॉडेलने तयार केलेल्या प्रत्येक response ची लांबी मर्यादित होते. हे मोठ्या default मूल्यावर ठेवले असल्यास, एका गोंधळलेल्या रनमधून खूप मोठे उत्तर तयार होऊ शकते आणि त्यासाठी शुल्क आकारले जाऊ शकते.

n8n docs मधील एक महत्त्वाची सूचना लक्षात ठेवा: सब-नोडमधील expressions नेहमी first input item च्या संदर्भात resolve होतात; ते प्रत्येक item साठी स्वतंत्रपणे resolve होत नाहीत. प्रत्येक item साठीची expressions root node च्या prompt fields मध्ये ठेवा.

पायरी 3: एजंटला मिळणारा prompt

AI Agent node उघडा. Prompt parameter मध्ये दोन settings आहेत.

• 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: एजंटला एक साधन द्या

कोणतेही tool sub-node नसलेला AI Agent node चालण्यास नकार देतो. सुरुवातीला एकच साधन जोडा. अर्धवट कॉन्फिगर केलेल्या चार साधनांपेक्षा कार्यरत एक साधन अधिक उपयुक्त माहिती देते.

एजंटच्या Tool connector ला HTTP Request node जोडा. सामान्य HTTP Request node प्रमाणेच त्याचे कॉन्फिगरेशन करा. त्यानंतर shell मधून त्या endpoint ची प्रथम चाचणी घ्या.

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

त्या curl command मुळे error किंवा HTML login page परत आल्यास agent देखील अयशस्वी होईल. त्यावेळी समस्या model मध्ये आहे असे दिसेल, परंतु प्रत्यक्षात ती URL किंवा authentication ची समस्या असेल. ती node मध्ये नव्हे, तर shell मध्ये दुरुस्त करा.

tool मधील Description field तुमच्या सहकाऱ्यांसाठी documentation नाही. हे tool संबंधित आहे की नाही, हे ठरवताना model वाचत असलेली ही एकमेव माहिती आहे. काय परत येते, हे स्पष्टपणे लिहा: "एका monitored service ची सध्याची up किंवा down स्थिती आणि downtime duration 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 हा hint आहे, विद्यमान data चा reference नाही. $fromAI('service') कुठूनही service नावाचे field वाचत नाही. ते model ला "एक value तयार करा आणि तिला service असे नाव द्या" असे सांगते. त्यानंतर model conversation, input data आणि इतर tool results तपासून योग्य value शोधते. Chat workflow मध्ये ते user ला थेट विचारू शकते.

पायरी 5: मेमरी आणि एजंट का विसरतो

मेमरी सब-नोड नसल्यास प्रत्येक संदेशाची सुरुवात शून्यापासून होते. अलीकडील संभाषण जतन करण्यासाठी Simple Memory सब-नोड जोडा.

यामध्ये दोन पॅरामीटर असतात. Session Key वरून हे कोणते संभाषण आहे ते ठरते. त्यामुळे वेगवेगळ्या की असलेल्या दोन वापरकर्त्यांचा इतिहास स्वतंत्र राहतो. Context Window Length म्हणजे प्रॉम्प्टमध्ये मागील किती परस्परसंवाद पुन्हा समाविष्ट करायचे ते.

Context Window Length हे गुणवत्तेइतकेच खर्चाचेही नियंत्रण आहे. कारण जतन केलेला प्रत्येक टर्न नंतरच्या प्रत्येक कॉलमध्ये इनपुट टोकन म्हणून पुन्हा पाठवला जातो. गप्पिष्ट एजंटसाठी 20 ची विंडो असल्यास, सुरुवातीचे तेच संदेश तुम्ही 20 वेळा पुन्हा पाठवण्याचा खर्च करता.

n8n queue mode मध्ये चालत असताना, सक्रिय production workflow मध्ये Simple Memory कार्य करत नाही. याचे कारण इतिहास workflow च्या स्वतःच्या डेटामध्ये राहतो, shared store मध्ये नाही. queue-mode instance वर त्याऐवजी Postgres Chat Memory सब-नोड वापरा आणि मुख्य प्रक्रिया तसेच workers दोन्ही पोहोचू शकतील अशा database कडे तो निर्देशित करा.

पायरी 6: System Message

एजंटचे Options उघडा आणि System Message जोडा. येथे कार्याचे वर्णन लिहा. या कार्यप्रवाहात याचा सर्वाधिक प्रभाव पडतो.

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" या सूचनेचे येथे महत्त्वाचे कार्य आहे. ही सूचना नसल्यास, उत्तर आधीच माहीत असल्याचे समजणारे मॉडेल tool वापरणे टाळेल आणि स्मरणशक्तीवर आधारित उत्तर देईल. तुमच्या पायाभूत सुविधांमध्ये बदल होताच असे उत्तर आत्मविश्वासाने चुकीचे ठरेल.

एजंट लूपमध्ये का अडकतो आणि ते कशामुळे थांबते

Options मध्ये Max Iterations देखील आहे. त्याची डीफॉल्ट किंमत 10 आहे. एक iteration म्हणजे एक model call आणि context मध्ये परत दिलेला एक tool result. त्यामुळे एक agent run म्हणजे एक API call नसतो. त्यात जास्तीत जास्त दहा API calls असू शकतात आणि प्रत्येक call मध्ये वाढत जाणारा संपूर्ण conversation input म्हणून समाविष्ट असतो.

ही संख्या कमी करा. बहुतेक single-tool agents दोन iterations मध्ये पूर्ण होतात. 3 किंवा 4 turns ची मर्यादा अनियंत्रित loop ला execution list मध्ये दिसणाऱ्या स्पष्ट failure मध्ये बदलते.

तुम्ही debugging करत असताना Return Intermediate Steps सुरू करा. त्यानंतर final output मध्ये agent ने प्रक्रियेदरम्यान केलेले tool calls समाविष्ट होतात. यामुळे "model ने tool कधीच call केले नाही" आणि "tool ने उपयुक्त काहीही परत केले नाही" यांतील फरक समजतो. go live करण्यापूर्वी ते पुन्हा बंद करा, कारण end user साठी हे steps अनावश्यक माहिती असतात.

shell मधून run होताना त्याचे निरीक्षण करा.

docker compose logs -f n8n

देखरेखीशिवाय चालणाऱ्या agent कडून शांतपणे जास्त खर्च होऊ नये याची खात्री

Chat Trigger मागे असलेल्या agent मध्ये मानवी देखरेख असते. उत्तर चुकीचे दिसल्यास ती व्यक्ती agent थांबवते. Schedule Trigger मागे असलेल्या agent वर कोणीही लक्ष ठेवत नाही. याचे संपूर्ण विवेचन नेहमी सुरू असलेल्या VPS वरील AI agent खर्च नियंत्रण येथे आहे. येथे चार सेटिंग्जमुळे बहुतेक काम होते.

• model sub-node वर Maximum Number of Tokens ची कमाल मर्यादा ठेवा. त्यामुळे एकही प्रतिसाद अनावश्यकपणे लांबणार नाही.
• कार्य पूर्ण करण्यासाठी आवश्यक असलेली सर्वात कमी संख्या Max Iterations मध्ये सेट करा.
• tool चे प्रतिसाद लहान ठेवा. 4,000 ओळींचा JSON blob परत करणारे tool त्यातील सर्व माहिती पुढील model call मध्ये पाठवते. त्याच run मधील त्यानंतरच्या प्रत्येक call मध्येही ती माहिती जाते.
• agent ला schedule ची खरोखर आवश्यकता आहे का, हे तपासा. दर पाच मिनिटांनी चालणारे job दिवसातून 288 वेळा सुरू होते. एका run चा खर्च जितका असेल, तितक्याने 288 गुणाकार करायचा आहे.

तुम्ही पुनरावृत्तीने बदल करत असताना workflow deactivate करा. Active workflow Schedule Trigger सह n8n ने जतन केलेल्या version विरुद्ध चालत राहतो. ती version तुमच्या स्क्रीनवर दिसणाऱ्या version सारखी असेलच असे नाही.

FAQ

माझा AI Agent node execute होण्यास नकार का देतो?

AI Agent node साठी chat model sub-node आणि किमान एक tool sub-node आवश्यक आहे. Model असलेला पण tool नसलेला node कोणताही API call करण्यापूर्वीच अयशस्वी होतो. एक tool जोडा, तो अगदी साधा असला तरी चालेल, आणि पुन्हा चालवा.

Agent उत्तर देतो, पण माझ्या tool ला कधीही call करत नाही. काय चुकीचे आहे?

बहुतेक वेळा कारण tool चे Description field असते. Model त्या descriptions वाचून tools निवडतो. त्यामुळे "HTTP Request" सारखे description tool कधी वापरायचे हे सांगत नाही. त्यातून कोणता data परत येतो आणि कोणत्या परिस्थितीत तो उपयुक्त आहे हे स्पष्ट होईल असे description पुन्हा लिहा. त्यानंतर agent ने उत्तर देण्यापूर्वी तो tool call करावा, अशी सूचना System Message मध्ये जोडा.

प्रत्येक run मध्ये तोच प्रश्न वेगवेगळी किंमत का निर्माण करतो?

कारण steps ची संख्या model निवडतो. प्रत्येक iteration मध्ये आतापर्यंतचे संपूर्ण conversation पुन्हा पाठवले जाते. त्यात मागील tool output चाही समावेश असतो. त्यामुळे चार iterations घेणाऱ्या run ची किंमत एका call च्या चारपटपेक्षा खूप जास्त असते. Max Iterations ही त्याची कमाल मर्यादा आहे. Return Intermediate Steps मुळे एखाद्या run मध्ये प्रत्यक्षात किती steps वापरले गेले ते दिसते.

Editor मध्ये memory काम करते, पण production मध्ये काम करत नाही. काय बदलले?

Instance queue mode मध्ये चालते का ते तपासा. Simple Memory इतिहास workflow च्या स्वतःच्या execution data मध्ये साठवते. हा data वेगळ्या worker process कडे सोपवल्यानंतर टिकत नाही. त्यामुळे active production workflow मधील इतिहास नष्ट होतो. त्याऐवजी Postgres Chat Memory sub-node वापरा. तो प्रत्येक worker ला उपलब्ध असलेल्या database मध्ये इतिहास ठेवतो.