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

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

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

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

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

संवादात्मक 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: मॉडेल 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 सेट करणे आवश्यक आहे.

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

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

n8n docs मधील एक महत्त्वाची सूचना लक्षात ठेवा: sub-node मधील expressions नेहमी पहिल्या input item च्या संदर्भात resolve होतात; प्रत्येक item साठी स्वतंत्रपणे नाही. प्रत्येक 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 उपनोड नसलेला 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 मिळत असल्यास एजंटही अपयशी ठरेल. ही अडचण प्रत्यक्षात URL किंवा authentication ची असताना ती model ची समस्या असल्यासारखी दिसेल. node मध्ये नव्हे, तर shell मध्येच ती दुरुस्त करा.

Tool मधील Description field तुमच्या सहकाऱ्यांसाठीचे documentation नाही. हे टूल संबंधित आहे की नाही हे ठरवताना 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, त्यानंतर optional description, type आणि defaultValue असे असतात. Key मध्ये letters, digits, underscores आणि hyphens वापरून 1 ते 64 characters असणे आवश्यक आहे. Type string, number, boolean किंवा json पैकी एक असतो. त्याची default value 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 ला विचारू शकते.

Web search हे नेहमी वापरले जाणारे दुसरे tool आहे. ते आणखी एक HTTP endpoint असल्यामुळे, paid search API ऐवजी तुम्ही याच node ला तुमच्या स्वतःच्या SearXNG instance कडे निर्देशित करू शकता. मात्र ते परत आणणारे प्रत्येक page आता तुमच्या prompt मधील untrusted text म्हणून हाताळा.

पायरी 5: memory आणि agent विसरण्याचे कारण

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

यामध्ये दोन parameters असतात. Session Key कोणते संभाषण आहे हे ठरवते. त्यामुळे वेगवेगळ्या keys असलेल्या दोन users चा history स्वतंत्र राहतो. Context Window Length prompt मध्ये मागील किती interactions पुन्हा समाविष्ट करायचे हे ठरवते.

Context Window Length हे quality प्रमाणेच cost देखील नियंत्रित करते. कारण लक्षात ठेवलेला प्रत्येक turn पुढील प्रत्येक call वेळी input tokens म्हणून पुन्हा पाठवला जातो. chatty agent साठी window 20 असल्यास, सुरुवातीचे तेच messages वीस वेळा पाठवण्याचा खर्च होतो.

n8n queue mode मध्ये चालत असल्यास, active production workflow मध्ये Simple Memory काम करत नाही. कारण history shared store ऐवजी workflow च्या स्वतःच्या data मध्ये साठवला जातो. queue-mode instance वर Postgres Chat Memory sub-node वापरा. तो अशा database कडे निर्देशित करा ज्यापर्यंत main process आणि workers दोन्ही पोहोचू शकतात.

पायरी 6: सिस्टम संदेश

एजंटचे 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.

"उत्तर देण्यापूर्वी नेहमी status tool ला call करा" हा निर्देश प्रत्यक्षात महत्त्वाचे काम करतो. हा निर्देश नसल्यास, उत्तर आधीच माहीत असल्याचे समजणारे model tool वगळून memory मधून उत्तर देईल. त्यामुळे तुमच्या infrastructure मध्ये बदल होताच ते उत्तर आत्मविश्वासाने चुकीचे ठरेल.

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

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

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

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

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

docker compose logs -f n8n

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

Chat Trigger मागे असलेल्या agent मध्ये मनुष्य सहभागी असतो आणि उत्तर चुकीचे वाटल्यास तो agent थांबवतो. Schedule Trigger मागे असलेल्या agent वर लक्ष ठेवणारे कोणीही नसते. येथे तुम्ही licence spend ऐवजी model spend चे निरीक्षण करत आहात, कारण agent, tool आणि memory nodes हे सर्व free self-hosted edition मध्ये कार्य करतात आणि ज्या features साठी paid key आवश्यक असते, ती बहुतेक team आणि governance संबंधी असतात. याचा सविस्तर आढावा always-on VPS वरील AI agent cost control मध्ये दिला आहे. येथे मुख्य काम चार settings करतात.

• 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 चा खर्च कितीही असो, तो आकडा 288 ने गुणावा.

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

FAQ

माझा AI Agent node execute का होत नाही?

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

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

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

प्रत्येक run मध्ये त्याच प्रश्नासाठी वेगवेगळा खर्च का येतो?

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

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

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