آموزش n8n: از نصب تا ایجنت چندمرحله‌ای#
آموزش n8n یعنی ساختن سیستم‌های اتوماسیونی که در محیط production دوام می‌آورند، نه دوی نمایشی. فاصله‌ی یک workflow ساده تا یک ایجنت هوش مصنوعی (AI Agent) چندمرحله‌ای، سه نقطه‌ی شکست دارد: درک Expression System، مدیریت state در ایجنت‌ها و طراحی Error Workflow. این راهنمای n8n فارسی دقیقاً همان سه نقطه را پوشش میدهد، نه happy path را.
n8n چیست و چه تفاوتی با Zapier و Make دارد؟#
n8n یک موتور اجرای اتوماسیون low-code متن‌باز با معماری node-based و بیش از ۴۰۰ integration بومی (طبق مستندات رسمی n8n) است که برخلاف Zapier و Make، امکان اجرای کد JavaScript درون Node، self-hosting کامل و ساخت ایجنت هوش مصنوعی چندمرحله‌ای را فراهم می‌کند.
معماری node-based و مفهوم Trigger، Node و Expression#
هر workflow در n8n از سه عنصر ساخته میشود: Trigger (نود شروع‌کننده که workflow را فعال می‌کند)، Action Node (نودی که کار انجام میدهد) و Expression (عبارت‌هایی که داده را بین نودها تبدیل و مسیردهی میکنند). تفاوت اصلی با Zapier در همین Expression System است؛ در n8n شما میتوانید داخل هر نود، منطق شرطی و تبدیل داده بنویسید بدون اینکه workflow را بشکنید.
نودهای n8n به‌صورت بصری روی canvas چیده میشوند و هر اتصال بین دو نود، یک stream داده‌ای است. این دادهها JSONمانند هستند و هر فیلد قابل‌دسترسی با syntax ساده‌ای مثل {{ $json.fieldName }} است. همین انعطاف، n8n را از ابزارهای no-code صرف جدا می‌کند.
مقایسه‌ی فنی n8n، Zapier و Make از نظر انعطاف، مقیاس‌پذیری و مدل لایسنس#
n8n، Zapier و Make هر سه اتوماسیون میکنند، اما مدل فکری‌شان کاملاً متفاوت است. Zapier ساده‌ترین مدل را دارد: هر task یک action است و محدودیت اصلی در تعداد task ماهانه است. Make (سابقاً Integromat) انعطاف بیشتری دارد و router و iterator داخلی دارد، اما همچنان SaaS-only است. n8n هر دو را با self-hosting و امکان اجرای کد سفارشی کنار می‌زند.
| معیار | n8n | Zapier | Make |
|---|---|---|---|
| مدل اجرا | Self-hosted یا Cloud | SaaS فقط | SaaS فقط |
| Self-hosting | بله، با Docker | خیر | خیر |
| پشتیبانی از کد | Code Node با JavaScript | محدود (Code by Zapier) | محدود (Function) |
| ایجنت AI | بومی با Chat Model و Tool Node | AI Actions جداگانه | AI Modules |
| مقیاس‌پذیری | Queue Mode + worker pool | وابسته به پلن | وابسته به پلن |
| لایسنس | fair-code (متن‌باز محدود) | مالکیتی | مالکیتی |
چرا توصیف n8n بهعنوان «Zapier رایگان» گمراه‌کننده است#
«Zapier رایگان» صدا زدنِ n8n، دو اشتباه فاحش دارد. اول، n8n ابزار no-code نیست؛ low-code است. برای workflowهای هوشمند باید JavaScript در Code Node بلد باشید. دوم، مدل لایسنس fair-code اجازهی فروش n8n بهعنوان SaaS را نمی‌دهد؛ یعنی نمی‌توانید n8n را بردارید و بهعنوان محصول به مشتری بفروشید. برای استفادهی داخلی و backend ایجنت مشکلی نیست، اما اگر بیزینس‌مدل شما فروش خودِ ابزار است، این محدودیت حیاتی است.
در پروژههای واقعی که اعضای کامیونیتی n8n گزارش کرده‌اند، تیم‌هایی که n8n را با Zapier اشتباه گرفته‌اند، در هفته‌ی دوم به Code Node و Expression System گیر کرده‌اند. یادگیری n8n بدون آشنایی مقدماتی با JavaScript، مثل یادگیری Photoshop بدون درک لایه‌هاست؛ ممکن است ولی دردناک.
نصب n8n با Docker: گام‌به‌گام روی VPS#
برای محیط production، نصب n8n با Docker Compose روی VPS تنها روش توصیه‌شده است؛ npm فقط برای توسعه‌ی محلی و تست سریع مناسب است و در سرور واقعی دردسر dependency، scaling و به‌روزرسانی ایجاد می‌کند.
پیش‌نیازها: انتخاب VPS، Docker Engine و Docker Compose#
حداقل مشخصات VPS برای اجرای n8n با یک PostgreSQL: 2 CPU، 4 GB RAM و 40 GB SSD. اگر Queue Mode فعال باشد و چند worker داشته باشید، RAM بیشتر نیاز دارید. Docker Engine نسخه‌ی 20+ و Docker Compose V2 (به‌صورت پلاگین) پیش‌نیازهای نرم‌افزاری هستند.
نوشتن فایل docker-compose.yml با PostgreSQL و Redis#
ساختار استاندارد شامل سه سرویس است: n8n خود، PostgreSQL برای ذخیره‌ی workflowها و execution data، و Redis برای Queue Mode. SQLite که n8n به‌صورت پیش‌فرض استفاده می‌کند، فقط برای یک کاربر و بدون concurrency مناسب است. به‌محض اینکه دو نفر همزمان workflow اجرا کنند یا Queue Mode فعال شود، SQLite گلوگاه میشود.
- خرید VPS با حداقل مشخصات ذکرشده و نصب OS لینوکسی (Ubuntu 22.04 LTS رایجترین انتخاب است)
- نصب Docker Engine و Docker Compose Plugin با اسکریپت رسمی
get.docker.com - نوشتن فایل
docker-compose.ymlشامل سه سرویس n8n، postgres و redis با volumeهای مجزا - اجرای
docker compose up -dو بررسی لاگ‌ها باdocker compose logs -f n8n - کانفیگ Nginx بهعنوان reverse proxy روی پورت 443 با SSL
- فعال‌سازی HTTPS با Let's Encrypt یا گواهی‌نامه‌ی موجود
فعال‌سازی Queue Mode برای چند worker#
Queue Mode در n8n با متغیر محیطی EXECUTIONS_MODE=queue فعال میشود. در این حالت، یک نود main workflow را مدیریت می‌کند و workerهای جداگانه execution را انجام می‌دهند. Redis بهعنوان message broker بین main و workerها عمل می‌کند. برای شروع با یک worker کافی است؛ هر worker اضافی، throughput را تقریباً خطی بالا می‌برد تا زمانی که CPU یا I/O database گلوگاه شود.
نکته‌ی عملی: در فایل compose، حتماً volume برای PostgreSQL تعریف کنید. اگر volume نداشته باشید، با هر restart دیتابیس پاک میشود و تمام workflowها و execution history از بین می‌روند. این اشتباه در پروژههای واقعی بارها تکرار شده است.
مفاهیم پایه و اولین اتوماسیون عملی: از Webhook تا Google Sheets#
اولین workflow قابل‌اجرای n8n ترکیبی از چهار Node است: Webhook Trigger، HTTP Request Node، Code Node برای تبدیل داده و Google Sheets Node برای ثبت ردیف. درک Expression System قبل از ساخت workflow پیچیده، از گیرکردن در مرحلهی دوم نجات میدهد.
ساخت workflow چهارنودی: Webhook → HTTP Request → Code → Google Sheets#
سناریوی عملی: یک فرم وب‌سایت دادهی کاربر را به n8n می‌فرستد. n8n آن داده را به یک API خارجی (مثلاً CRM) ارسال می‌کند، پاسخ را parse می‌کند و خلاصه‌ای در Google Sheets ثبت می‌کند.
نود اول، Webhook Trigger است. path دلخواه تعریف میکنید و HTTP method را POST می‌گذارید. نود دوم، HTTP Request است؛ URL مقصد، headers و body را از دادهی webhook با Expression پر میکنید. نود سوم، Code Node است؛ اینجا JavaScript ساده برای تبدیل یا فیلتر داده می‌نویسید. نود چهارم، Google Sheets است؛ credential را کانفیگ میکنید و mapping ستون‌ها را مشخص میکنید.
n8n Expression System چیست و چطور کار می‌کند#
Expression در n8n یک template literal است که با {{ }} نوشته میشود. داخل این براکت‌ها، به دادهی نودهای قبلی دسترسی دارید. مثلاً {{ $json.email }} مقدار فیلد email از ورودی فعلی را برمی‌گرداند. اگر بخواهید به خروجی نود قبلی اشاره کنید، از {{ $('Node Name').item.json.field }} استفاده میکنید.
مفهوم item در n8n حیاتی است. هر نود یک آرایه از itemها دریافت و تولید می‌کند. اگر HTTP Request پنج پاسخ برگرداند، نود بعدی پنج بار اجرا میشود (مگر اینکه aggregate کنید). این رفتار default باعث میشود workflowها بدون حلقه‌ی صریح، روی چند رکورد کار کنند.
کی از Code Node استفاده کنیم و کی از Expression؟#
قاعده‌ی ساده: اگر تبدیل داده با یک یا دو خط Expression قابل‌حل است، Code Node نکشید. Code Node برای زمانی است که منطق شرطی، حلقه یا تبدیل ساختاری نیاز دارید. اشتباه رایج تازه‌کارها: نوشتن Code Node برای یک تبدیل ساده که با {{ $json.name.toUpperCase() }} در Expression حل می‌شد. هزینه‌ی پنهان این کار، خوانایی کمتر workflow و debug سخت‌تر است.
مفهوم Sub-workflow (workflow فرعی که از workflow اصلی صدا زده میشود) برای سازمان‌دهی ضروری است. وقتی workflow شما 15+ نود دارد، منطق را به Sub-workflowهای مجزا بشکنید. هر Sub-workflow یک ورودی مشخص و یک خروجی مشخص دارد. این کار debug را از «ردیابی 15 نود در یک صفحه» به «بررسی 3 نود در هر صفحه» تبدیل می‌کند.
چطور با n8n ایجنت هوش مصنوعی بسازم؟#
ایجنت هوش مصنوعی در n8n با ترکیب چهار Node ساخته میشود: Chat Model Node (اتصال به OpenAI یا Anthropic)، Memory Node (حفظ context)، Tool Node (دعوت از ابزار خارجی) و در سناریوهای پیشرفته‌تر RAG (Retrieval-Augmented Generation) با اتصال به Vector Database.
معماری ایجنت ساده: Chat Model + Memory + Tool#
نود اصلی، AI Agent Node است. داخل آن، Chat Model را انتخاب میکنید (OpenAI GPT-4o، Anthropic Claude و غیره)، Memory Node را وصل میکنید و Tool Nodeها را تعریف میکنید. Tool Node هر چیزی می‌تواند باشد: یک HTTP Request که به API داخلی شما وصل میشود، یک Code Node که محاسبات انجام میدهد، یا حتی یک Sub-workflow کامل.
ایجنت در هر مرحله تصمیم می‌گیرد کدام tool را صدا بزند، خروجی را بخواند و ادامه دهد یا پاسخ نهایی را بدهد. این رفتار loop-based است و تعداد iterations با متغیر maxIterations محدود میشود. مقدار پیش‌فرض معمولاً 10 است؛ در سناریوهای واقعی، 5 تا 8 کافی است.
ساخت RAG با n8n: اتصال به Pinecone یا ChromaDB#
برای ایجنتی که به دانش سازمانی دسترسی دارد، RAG لازم است. در n8n، Vector Store Node (پشتیبانی از Pinecone، ChromaDB، Supabase Vector و غیره) بهعنوان Tool Node به ایجنت وصل میشود. ایجنت query را به vector store می‌فرستد، نتایج را می‌گیرد و در پاسخ استفاده می‌کند.
چرا Memory Node به‌تنهایی کافی نیست و چه‌زمانی به Redis یا database خارجی نیاز دارید#
Memory Node در n8n به‌صورت default در حافظه‌ی RAM process نگه‌داشته میشود. یعنی اگر container ریست شود، context از بین می‌رود. برای ایجنت‌هایی که باید بین sessionها state حفظ کنند، از Postgres Memory یا Redis Memory استفاده کنید. در سناریوی چندایجنتی، هر ایجنت ممکن است به state مشترک نیاز داشته باشد؛ اینجا database خارجی ضروری است.
الگوی Agent as a Service: n8n بهعنوان backend و Telegram/WhatsApp Bot بهعنوان frontend#
رایجترین الگوی عملیاتی: n8n ایجنت را اجرا می‌کند و یک Telegram Bot Node یا WhatsApp Business API Node بهعنوان رابط کاربری عمل می‌کند. کاربر پیام می‌فرستد، webhook n8n را فعال می‌کند، ایجنت پردازش می‌کند و پاسخ برمی‌گردد. این معماری، n8n را به backend ایجنت تبدیل می‌کند بدون نیاز به نوشتن API server جداگانه.
معماری چندایجنتی (Multi-Agent) با Sub-workflow الگوی پیشرفته‌تر است: یک ایجنت orchestrator وظایف را به ایجنت‌های تخصصی تقسیم می‌کند. مثلاً ایجنت اول intent را تشخیص میدهد، ایجنت دوم research انجام میدهد، ایجنت سوم پاسخ را compose می‌کند. هر ایجنت یک Sub-workflow مجزا است و orchestrator با HTTP Request یا Execute Workflow Node آن‌ها را صدا می‌زند.
رایجترین اشتباهات و نحوه‌ی دیباگ workflow در n8n#
در پروژههای واقعی، بزرگ‌ترین bottleneck n8n نه performance بلکه debug کردن workflowهای تو‌در‌تو (nested) است. Execution Log فیلترشده، Binary Data viewer و Error Workflow سه ابزار اصلی تشخیص و رفع خطا هستند.
اشتباهات رایج تازه‌کارها: نادیده گرفتن error handling، اعتماد به happy path#
تازه‌کارها workflow را طوری می‌سازند که فرض کنند همه‌چیز درست کار می‌کند. در production، APIها timeout می‌دهند، دادههای unexpected می‌آیند و network قطع میشود. بدون Error Workflow، یک شکست ساده یعنی دادهی از دست رفته و هیچ‌کس متوجه نمی‌شود.
دیباگ گام‌به‌گام: Execution Log، تست دستی Node و Breakpoint#
در Execution Log، هر نود جداگانه قابل‌بازدید است. روی نود کلیک کنید و input/output JSON را ببینید. اگر دادهی ورودی نود بعدی خالی یا unexpected است، مشکل در نود قبلی است. تست دستی: روی یک نود راست‌کلیک کنید و «Execute Node» بزنید تا فقط آن نود با دادهی فعلی اجرا شود. این کار، چرخه‌ی debug را از «اجرای کل workflow» به «اجرای یک نود» کاهش میدهد.
نکته‌ی عملی: در workflowهای nested، Execution Log را با فیلتر workflow ID جدا کنید. در غیر این صورت، ردیابی execution در میان ده‌ها workflow عملاً غیرممکن میشود. این الگو در پروژههای تیمی که اعضای کامیونیتی گزارش داده‌اند، بارها تکرار شده است.
طراحی Error Workflow: ارسال alert به Slack یا Telegram هنگام شکست#
هر workflow اصلی باید یک Error Workflow موازی داشته باشد. در تنظیمات workflow، Error Workflow را مشخص میکنید. این workflow فقط وقتی اجرا میشود که workflow اصلی fail کند. داخل Error Workflow، نود Slack یا Telegram را قرار دهید تا پیام alert شامل نام workflow، خطا و execution ID بفرستد.
مدیریت Retry و Binary Data در workflowهای HTTP سنگین#
HTTP Request Node گزینهی retry دارد. تعداد retry و delay بین آن‌ها را تنظیم کنید. برای Binary Data (فایل، تصویر، PDF)، توجه داشته باشید که n8n این دادهها را در RAM نگه می‌دارد. اگر فایل بزرگ پردازش میکنید، حجم RAM سرور را بررسی کنید؛ در غیر این صورت OOM kill می‌شوید.
هزینه‌ی واقعی self-hosting در مقابل n8n Cloud#
مقایسه‌ی هزینه‌ی n8n Cloud با self-hosting بدون محاسبه‌ی TCO (Total Cost of Ownership) شامل VPS، مانیتورینگ، بکاپ و زمان نگهداری ناعادلانه است؛ برای حجم کم، Cloud منطقی‌تر است و برای دادهی حساس یا مقیاس بالا، self-hosting.
تحلیل TCO: VPS + مانیتورینگ + بکاپ + زمان نگهداری#
هزینه‌ی ظاهری self-hosting فقط VPS نیست. بکاپ منظم PostgreSQL، مانیتورینگ uptime، آپدیت Docker image، مدیریت SSL و رفع مشکل network همگی زمان و هزینه دارند. یک فریلنسر با درآمد ساعتی قابل‌توجه، اگر هفته‌ای دو ساعت صرف نگهداری n8n کند، هزینه‌ی پنهان سنگینی متحمل میشود — و این فقط شروع ماجراست.
لایسنس fair-code و محدودیت‌های استفادهی تجاری#
لایسنس fair-code اجازهی self-hosting و استفادهی داخلی میدهد. فروش n8n بهعنوان SaaS (یعنی ارائه‌ی خودِ n8n به مشتری بهعنوان محصول) محدودیت دارد. برای استفادهی تجاری بهعنوان backend ایجنت یا اتوماسیون داخلی، معمولاً مشکلی نیست؛ اما حتماً متن لایسنس را راستیآزمایی کنید. این موضوع نیازمند بررسی دقیق‌تر با توجه به مدل بیزینس شماست.
چه‌وقتی n8n Cloud انتخاب درست است و چه‌وقتی self-hosting#
| سناریو | توصیه | دلیل |
|---|---|---|
| فریلنسر با 1-5 workflow | n8n Cloud | هزینه‌ی نگهداری صفر، تمرکز روی ساخت |
| تیم 5 نفره با دادهی حساس | Self-hosting | کنترل کامل داده، GDPR compliance |
| سازمان 50+ نفر با SLA سخت | Self-hosting + DevOps | مقیاس‌پذیری، uptime، governance |
نکته‌ی مهم: قیمت‌های n8n Cloud به‌صورت دوره‌ای تغییر میکنند. قبل از تصمیم، قیمت روز را از صفحه‌ی pricing رسمی بررسی کنید. عدد ثابت در این مقاله نمی‌دهم چون نیازمند راستیآزمایی لحظه‌ای است.
آیا n8n برای کار تیمی و مقیاس سازمانی مناسب است؟#
n8n با فعال‌سازی Queue Mode و معماری worker pool، از حجم‌های پایین تا متوسط سازمانی مقیاس‌پذیر است؛ اما برای سازمان‌های بزرگ با صدها workflow همزمان، نیاز به طراحی معماری اختصاصی و مانیتورینگ پیشرفته دارد.
Queue Mode در n8n: چه‌وقتی Single Mode کافی است و چه‌وقتی لازم نیست#
Single Mode برای محیط توسعه و workflowهای سبک کافی است. به‌محض اینکه چند کاربر همزمان workflow اجرا کنند یا executionها سنگین شوند (HTTP با payload بزرگ، Code Node با حلقه‌های طولانی)، Single Mode گلوگاه میشود. Queue Mode با جدا کردن main process از execution workers، این مشکل را حل می‌کند.
مقایسه‌ی فنی Queue Mode با worker pool سنتی#
Queue Mode n8n یک message broker (Redis) بین main و workers قرار میدهد. main workflow را schedule می‌کند و job را در queue می‌گذارد. workerها job را برمی‌دارند، execution را انجام می‌دهند و نتیجه را برمی‌گردانند. این الگو، مشابه Bull یا Celery در اکوسیستم Node.js و Python است. تفاوت اصلی: n8n خودِ orchestration را مدیریت می‌کند و شما فقط تعداد worker را تنظیم میکنید.
کار تیمی: دسترسی چند‌کاربره، نقش‌ها و اشتراک‌گذاری workflow#
در n8n Enterprise، RBAC (Role-Based Access Control) وجود دارد. در نسخه‌ی self-hosted رایگان، اشتراک‌گذاری workflow محدودتر است. تیمهای 10+ نفره معمولاً به Enterprise یا معماری custom نیاز دارند.
بزرگ‌ترین چالش سازمانی: governance و version control روی workflowها#
تجربه‌ی میدانی: در تیمهای بزرگ، مشکل اصلی نه performance بلکه مدیریت تغییرات روی workflowهای مشترک است. دو نفر همزمان یک workflow را ویرایش میکنند، یکی publish می‌کند و دیگری بازنویسی می‌کند. راه‌حل: workflowها را به‌صورت JSON export کنید و در Git version control بگذارید. n8n API برای programmatic deploy وجود دارد؛ از آن استفاده کنید.
نتیجه‌ی عملی: n8n ابزاری است که فاصله‌ی بین اتوماسیون ساده و ایجنت هوش مصنوعی چندمرحله‌ای را با یک معماری منسجم پر می‌کند، به‌شرطی که Expression System، Error Handling و معماری Queue Mode را جدی بگیرید. اگر می‌خواهید این مسیر را با ساختار مشخص و پشتیبانی تیمی طی کنید، دوره‌ی ساخت Ai Agent با N8N در کامیونیتی N8N اسکول، از نصب تا ایجنت چندمرحله‌ای را جلسه‌به‌جلسه پوشش میدهد.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.