آموزش n8n یعنی یادگیری دو معماری جداگانه: ورکفلوی خطی که از trigger تا action ثابت حرکت میکند، و ایجنت (Agent) غیرخطی که LLM در لحظه تصمیم می‌گیرد مسیر بعدی چیست. اکثر آموزش‌های فارسی این دو را یکی جا می‌زنند؛ درحالی‌که انتخاب معماری اشتباه، هزینه‌ی نگهداری فرسایشی می‌سازد. در ادامه، یک ورکفلوی تأیید لید را با هر دو معماری می‌سازیم تا تفاوت در عمل روشن شود.
n8n چیست و چطور کار میکند؟#
n8n یک ابزار اتوماسیون نود-محور (Node-Based) است: هر نود یک عملیات مشخص انجام میدهد، نودها با خطوط اتصال به هم وصل می‌شوند، و خروجی JSON هر نود به ورودی نود بعدی تزریق میشود. جریان داده از trigger تا action نهایی، کاملاً در بصری‌سازی قابل ردیابی است.
معماری نود-محور: هر نود یک وظیفه، هر اتصال یک جریان داده#
این معماری چیزی بین کدنویسی و کلیک‌کردن است. نه واقعاً no-code محسوب میشود، نه code-first. اگر انتظار دارید n8n مثل Zapier فقط با کشیدن‌وداشتن کار کند، در اولین نود Code یا HTTP Request گیر می‌کنید.
در عمل، شما یک بوم سفید دارید. نودها را می‌چینید، بینشان خط می‌کشید و جریان داده را تعریف می‌کنید. هر نود یک ورودی JSON دارد و یک خروجی JSON تولید میکند. اتصال بین نودها صرفاً یعنی خروجی نود قبلی به ورودی نود بعدی تزریق شود. همین.
انواع نود: Trigger، Action، Logic و Code#
نودهای n8n در چهار دسته قرار می‌گیرند:
- Trigger: نقطه شروع ورکفلو. مثلاً Webhook، Schedule یا Gmail Trigger.
- Action: عملیات خارجی. مثلاً ارسال ایمیل، ثبت رکورد در CRM یا فراخوانی API.
- Logic: کنترل جریان. نودهای IF، Switch، Merge و Loop.
- Code: اجرای JavaScript یا Python دستی برای تبدیل داده.
مستندات رسمی n8n صدها نود آماده فهرست کرده است. اگر نود سفارشی لازم باشد، میتوانید با TypeScript نود جدید بسازید و به پکیج اضافه کنید.
n8n یا Make و Zapier؟ مقایسه‌ای که «رایگان» را از «open-source» جدا میکند#
n8n را «Zapier رایگان» صدا زدن هم از نظر مجوز نادرست است و هم از نظر عملکرد. مجوز n8n از نوع fair-code است، نه MIT یا Apache. یعنی استفاده داخلی آزاد است اما فروش n8n به‌عنوان سرویس SaaS ممنوع. علاوه بر این، قابلیت کدنویسی و ایجنت‌سازی با LangChain در n8n وجود دارد که Zapier و Make ندارند.
جدول مقایسه: n8n، Make، Zapier و Activepieces#
| ابزار | معماری | مجوز | کدنویسی | ایجنت |
|---|---|---|---|---|
| n8n | نود-محور | fair-code | Code Node + نود سفارشی | LangChain Agent بومی |
| Make | بصری ماژولار | مالتی‌تننت | Function محدود | AI Module (غیربومی) |
| Zapier | خطی ساده | SaaS | Code Step محدود | AI Actions (سطحی) |
| Activepieces | نود-محور | MIT | Code Step | ندارد |
مجوز fair-code دقیقاً چه می‌گوید#
fair-code سه اجازه میدهد: استفاده شخصی، استفاده داخلی در سازمان، و تغییر کد برای نیاز خودتان. سه چیز را ممنوع میکند: فروش n8n به‌عنوان SaaS، فروش n8n به‌عنوان محصول white-label، و بسته‌بندی مجدد n8n برای فروش.
اگر می‌خواهید اتوماسیون‌تان را به مشتری بفروشید، این مجوز مشکل‌ساز است. دقیقاً در همین نقطه‌ای که برخی آموزش‌های فارسی n8n را «رایگان» معرفی می‌کنند و بعد کاربر در مرحله‌ی مونیتایز با دیوار مجوز برخورد میکند.
چه کسی باید کدام را انتخاب کند#
الگوی مشاهده‌شده در کامیونیتی: تیمهای غیرفنی با Zapier راحت‌ترند چون منحنی یادگیری کوتاه‌تری دارد. تیمهای فنی‌میان که می‌خواهند کنترل روی داده و کد داشته باشند، n8n انتخاب می‌کنند. Make برای اتوماسیون‌های بصری پیچیده با شاخه‌های متعدد مناسب است. Activepieces اگر MIT بودن برایتان حیاتی است گزینه‌ی منطقی‌تر است، هرچند اکوسیستم نودهایش کوچک‌تر است.
اما یک هشدار: اگر الان Zapier استفاده می‌کنید و می‌خواهید به n8n مهاجرت کنید، هزینه‌ی پنهان این مهاجرت، بازنویسی تمام ورک‌فلوهاست. Zapier و n8n نودهای یکسانی ندارند؛ حتی وقتی منطق کار یکی است.
ایجنت هوش مصنوعی با n8n: وقتی ورکفلو خودش تصمیم می‌گیرد#
ایجنت هوش مصنوعی (AI Agent) در n8n با نود LangChain ساخته میشود. برخلاف ورکفلوی خطی، ایجنت مسیر اجرا را در لحظه و بر اساس ورودی تعیین میکند. LLM به‌عنوان مغز تصمیم‌گیرنده عمل میکند و ابزارها (Tools) را خودش انتخاب و صدا می‌زند.
تفاوت معماری: ورکفلوی خطی در مقابل ایجنت غیرخطی#
در ورکفلوی خطی، شما از قبل می‌دانید نود بعدی چیست. trigger فعال میشود، action اول اجرا میشود، action دوم اجرا میشود. مسیر ثابت است.
در ایجنت غیرخطی، LLM ورودی را می‌خواند، تصمیم می‌گیرد کدام tool را صدا بزند، نتیجه را ارزیابی میکند و دوباره تصمیم می‌گیرد. مسیر از پیش تعریف‌شده نیست. این یعنی انعطاف بیشتر، ولی هزینه‌ی debugging بالاتر و پیش‌بینی‌ناپذیری در رفتار.
ورکفلوی عملی: تأیید لید با ایجنت#
این ورکفلو را گام‌به‌گام بسازید:
- Webhook Trigger: لید از فرم سایت یا landing page دریافت میشود. داده شامل نام، ایمیل، بودجه و شرح نیاز است.
- LangChain Agent: ایجنت با prompt مشخص کیفیت لید را ارزیابی میکند. خروجی: hot، warm یا cold.
- IF: اگر hot بود، نود بعدی اجرا میشود. اگر cold بود، ورکفلو متوقف میشود.
- HTTP Request: لید در CRM ثبت میشود (مثلاً HubSpot یا Airtable).
- Gmail: اعلان به تیم فروش ارسال میشود.
کل این ورکفلو 5 نود است. الگوی تکرارشونده در پروژههای کامیونیتی نشان میدهد بهترین اتوماسیون‌ها یک trigger دارند و خروجی‌شان یک تصمیم است، نه زنجیره‌ی نودی بی‌پایان.
چه زمانی ایجنت لازم است و چه زمانی IF ساده کافی است#
اگر ورودی‌تان ساختار ثابت دارد و تصمیم فقط یک شرط ساده است (بودجه > X)، IF کافی است. ایجنت وقتی لازم است که ورودی ساختار ثابت ندارد یا تصمیم نیازمند تفسیر زبان طبیعی است. مثلاً «آیا این ایمیل لید واقعی است یا اسپم؟» — این را IF نمی‌تواند پاسخ دهد، ولی ایجنت می‌تواند.
برای درک عمیق‌تر تفاوت معماری، مقاله‌ی ایجنت هوش مصنوعی چیست را بخوانید.
پیش‌نیازها و منحنی یادگیری: n8n بدون کدنویسی نیست#
برای اتوماسیون‌های ساده، n8n واقعاً بدون کدنویسی است. اما برای ایجنت‌ها و ورکفلوهای پیچیده به درک JSON، HTTP Request و گاهی JavaScript نیاز دارید. منحنی یادگیری بین «کلیک‌کردن» و «مهندسی‌کردن» قرار دارد.
پیش‌نیازهای فنی#
سه مهارت پایه لازم است:
- درک ساختار JSON — چون تمام داده‌ها بین نودها به شکل JSON منتقل می‌شوند.
- آشنایی با مفاهیم HTTP Method (GET، POST، PUT) و REST API.
- توانایی خواندن خطاهای ساده در Log Viewer.
الگوی مشاهده‌شده در کامیونیتی: کسانی که پیش‌نیاز API را ندارند، دقیقاً در نود HTTP Request گیر می‌کنند و ساعت‌ها وقت صرف می‌کنند تا بفهمند body را کجا بگذارند. مقاله‌ی آموزش API این شکاف را پر میکند.
زمان تخمینی یادگیری#
اولین ورکفلوی ساده (Webhook → Gmail) در چند ساعت قابل ساخت است. ایجنت کاربردی که واقعاً در تولید استفاده شود، 1 تا 2 هفته زمان می‌برد چون باید prompt را تنظیم کنید، toolها را تست کنید و edge caseها را بپوشانید.
Docker و Node.js: چه زمانی لازم است و چه زمانی نه#
اگر از n8n Cloud استفاده می‌کنید، Docker لازم نیست. Docker فقط برای Self-Hosting مورد نیاز است. حتی در حالت self-host هم میتوانید از نودهای آماده بدون نوشتن کد استفاده کنید؛ فقط اگر بخواهید نود سفارشی بسازید، Node.js و TypeScript لازم میشود.
خودمیزبانی یا n8n Cloud؟ هزینه‌ی پنهانِ نگهداری#
خودمیزبانی n8n روی سرور شخصی رایگان به‌نظر می‌رسد. اما زمان آپدیت امنیتی، بکاپ، مانیتورینگ و مدیریت secrets هزینه‌ی پنهانی می‌سازد. الگوی تکرارشونده در پروژههای کامیونیتی نشان میدهد کاربران بعد چند ماه از self-host به Cloud مهاجرت می‌کنند.
n8n Cloud: مدل قیمت‌گذاری#
n8n Cloud بر اساس تعداد execution قیمت‌گذاری میشود. هر بار که ورکفلو اجرا شود، یک execution حساب میشود. برای تیم‌هایی که حجم execution پایین دارند، مدل Cloud ساده و قابل پیش‌بینی است. برای حجم بالا، self-host اقتصادی‌تر میشود.
Self-Hosting: چک‌لیست واقعی نگهداری#
اگر self-host انتخاب کردید، این کارها بهصورت مستمر روی دوش شماست:
- آپدیت امنیتی n8n و Docker image.
- بکاپ منظم دیتابیس (PostgreSQL یا SQLite).
- مدیریت secrets و environment variables.
- مانیتورینگ uptime و لاگ‌ها.
- پیکربندی reverse proxy و SSL.
مقاله‌ی خودمیزبانی سرور جزئیات فنی این چک‌لیست را پوشش میدهد.
تصمیم‌گیری: چه زمانی self-host منطقی است#
self-host وقتی منطقی است که: حساسیت داده دارید (اطلاعات مالی یا پزشکی)، حجم execution بالایی دارید و هزینه‌ی Cloud سرسام‌آور میشود، یا می‌خواهید n8n را در شبکه داخلی بدون دسترسی به اینترنت اجرا کنید. در غیر این صورت، Cloud ساده‌تر است.
اشتباهات رایج: Code Node و زنجیره‌های نودیِ بی‌پایان#
دو اشتباه پرهزینه در n8n: اول، نوشتن Code Node به‌جای ترکیب نودهای آماده؛ دوم، ساخت زنجیره‌های 15 نودی که فقط نگهداری‌شان مشکل‌ساز است. هر دو نشانه‌ی معماری اشتباه‌اند، نه پیچیدگی واقعی مسئله.
دام Code Node#
مشاهده‌ی میدانی در پروژههای کامیونیتی: کاربرانی که Code Node نوشته‌اند، بعداً متوجه شده‌اند نودهای آماده کافی بوده. بخش عمده‌ای از نیازها با ترکیب HTTP Request + IF + Merge قابل حل است. Code Node فقط وقتی منطقی است که تبدیل داده پیچیده‌ای لازم باشد که هیچ نود آماده‌ای پوششش نمی‌دهد.
زنجیره‌ی نودی طولانی: نشانه‌ی معماری اشتباه#
اگر ورکفلو شما 15 نود دارد و هر بار که ورودی تغییر میکند باید IFهای بیشتری اضافه کنید، احتمالاً ایجنت ساده همان کار را با 5 نود میکند. زنجیره‌ی نودی طولانی یعنی شما دارید تصمیم‌گیری را بهصورت دستی کدگذاری می‌کنید؛ درحالی‌که ایجنت دقیقاً برای همین ساخته شده.
اشتباه سوم: نادیده گرفتن Error Handling#
نودهای بدون Branch خطا، ورکفلو را در اولین خطای API متوقف می‌کنند. هر نود HTTP Request یا Action خارجی باید یک Error Branch داشته باشد که خطا را لاگ کند و ادامه‌ی ورکفلو را مشخص کند.
چه زمانی n8n انتخاب غلط است؟#
n8n برای اتوماسیون‌های بسیار ساده (زیر 3 نود)، تیم‌هایی که فقط با Google Sheets کار می‌کنند، و موارد نیازمند compliance سخت‌گیرانه انتخاب مناسبی نیست. در این حالت‌ها ابزارهای ساده‌تر یا سرویسهای تخصصی‌تر بهترند.
اتوماسیون‌های زیر 3 نود#
اگر فقط می‌خواهید فرم → ایمیل بفرستد، IFTTT یا فرم‌های آماده کافی‌اند. n8n برای این کار بیش‌ازحد است. الگوی مشاهده‌شده: پروژه‌هایی که n8n را برای ارسال ایمیل از فرم استفاده کردند، بعداً به ابزار ساده‌تر مهاجرت کردند.
تیمهای غیرفنیِ مطلق#
اگر هیچ‌کس در تیم شما JSON نمی‌خواند و HTTP Method نمی‌شناسد، Zapier یا Make با منحنی یادگیری کوتاه‌تر گزینه‌ی عملی‌تری هستند. مقاله‌ی اتوماسیون بازاریابی ابزارهای ساده‌تر را معرفی میکند.
نیازهای compliance#
اگر داده‌ی پزشکی (HIPAA) یا مالی با استانداردهای خاص دارید، باید سازگاری n8n Cloud را با آن استانداردها جداگانه بررسی کنید. این موضوع نیازمند راستی‌آزمایی با مستندات رسمی هر سرویس است.
جمع‌بندی و قدم بعدی#
n8n ابزاری قدرتمند است، ولی قدرتش از دو معماری جداگانه‌اش می‌آید: ورکفلوی خطی برای کارهای تکراری با مسیر مشخص، و ایجنت غیرخطی برای کارهایی که نیازمند تصمیم‌گیری در لحظه‌اند. اشتباه رایج این است که هر دو را با هم یکی بگیرید و زنجیره‌ی نودی بسازید جایی که ایجنت لازم است، یا برعکس.
اگر می‌خواهید این دو معماری را در پروژه‌ی واقعی تمرین کنید و از n8n درآمد بسازید، دوره‌ی «ساخت Ai Agent با N8N» در کامیونیتی اسکول 51 جلسه و 41 ساعت محتوای عملی دارد. اگر هنوز در مرحله‌ی «آیا اصلاً n8n به درد من می‌خورد؟» هستید، چالش رایگان «تبدیل ایده به پول با Ai» نشان میدهد ایده‌ی یک نفر چطور به محصول و درآمد رسید.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.