آموزش n8n در وب‌سایت‌های فارسی معمولاً با جمله‌ی «بدون کدنویسی اتوماسیون بساز» شروع میشود و همان‌جا تمام میشود. n8n برای جریان کاری (Workflow) ساده واقعاً بدون کد کار میکند، اما از سطح Expressionهای چندشرطی، Function Node و مدیریت خطا به دانش پایه‌ی JavaScript نیاز دارد. این راهنما همان مرزها را نشان می‌دهد.
n8n چیست و معماری Node-based آن چگونه کار میکند؟#
n8n یک ابزار اتوماسیون مبتنی بر گره (Node-based) است که Jan Oberhauser در برلین بنیان گذاشت و با مجوز Fair-Code منتشر میشود. هر Node یک عملیات اتمی انجام می‌دهد و Connectionها داده‌ی JSON را بین آن‌ها منتقل می‌کنند. معماری سه‌لایه است: Trigger Node رویداد را می‌گیرد، Action Node پردازش را انجام می‌دهد و Output Node نتیجه را ذخیره یا ارسال میکند.
تفاوت بنیادین با معماری اسکریپتی اینجاست: در n8n هر Node یک تابع مستقل با ورودی و خروجی مشخص دارد. در LangChain (فریم‌ورک ساخت ایجنت با پایتون) زنجیره‌ای از توابع درون یک Runtime اجرا می‌شوند و مدیریت state درون کد انجام می‌گیرد. در عمل یعنی در n8n هر مرحله را جداگانه تست میکنید؛ در LangChain باید کل Chain را اجرا کنید.
Expression Engine n8n اجازه می‌دهد با syntax شبیه JavaScript به خروجی Node قبلی دسترسی پیدا کنید. مثلاً {{ $json.message.text }} متن پیام Telegram را برمی‌دارد. منطق ساده می‌سازید — اما همین syntax وقتی چندشرطی میشود، عملاً JavaScript است. و این دقیقاً همان نقطه‌ای است که اکثر آموزش‌ها سکوت می‌کنند.
Self-hosted یا n8n Cloud؟ تحلیل هزینه‌ی پنهان که آموزش‌ها نمی‌گویند#
Self-hosting n8n روی کاغذ رایگان است، اما هزینه‌ی واقعی شامل سرور، مانیتورینگ، آپدیت امنیتی، بکاپ و زمان DevOps است که در مجموع می‌تواند از قیمت n8n Cloud بیشتر تمام شود. مگر اینکه تیم فنی داشته باشید.
پیش‌نیازهای فنی Self-hosting: آشنایی با Docker Compose (ابزار اجرای کانتینرهای چندتایی)، Node.js و REST API. اگر این سه را بلد نیستید، Self-hosting بهجای صرفهجویی، یک پروژهی نیمهکاره میسازد.
هزینه‌های پنهان Self-hosting:
- سرور VPS: حداقل سروری با RAM کافی (2 گیگابایت برای محیط توسعه، بیشتر برای Production) برای اجرای n8n + دیتابیس
- SSL و دامنه: گواهی امنیتی و DNS برای دسترسی HTTPS به Webhookها
- مانیتورینگ: بررسی uptime، مصرف منابع و لاگ‌ها — بدون این، قطعی سرویس را تا شکایت مشتری متوجه نمی‌شوید
- آپدیت n8n: هر نسخه‌ی جدید می‌تواند تغییر شکست‌دهنده (Breaking Change) داشته باشد؛ آپدیت بدون تست در محیط آزمایشی (Staging) یعنی ریسک خرابی محیط عملیاتی (Production)
- بکاپ دیتابیس: Workflowها، Credentials و Execution Logها همه در دیتابیس ذخیره می‌شوند
- مدیریت Webhook در تغییر IP: اگر IP سرور عوض شود، تمام Webhookهای ثبت‌شده در سرویس‌های خارجی باید آپدیت شوند
الگوی تکرارشونده از پروژه‌های اعضای کامیونیتی: تیم‌های بدون DevOps که Self-hosting انتخاب کردند، بعد از چند ماه به Cloud مهاجرت کردند. دلیل اصلی، زمان صرف‌شده برای نگهداری بود، نه هزینه‌ی سرور. یک نفر باید مسئول آپدیت، بکاپ و رفع خطا باشد — و این نفر معمولاً گران‌تر از اشتراک Cloud تمام میشود.
Cloud مقرون‌به‌صرفه‌تر است وقتی تیم کوچک زیر 5 نفر بدون سرور اختصاصی دارید. Self-hosting منطقی است وقتی داده‌ی حساس نباید از سرور خارج شود و تیم فنی در‌دسترس دارید.
ساخت اولین Workflow: از Telegram Bot تا ذخیره در Supabase#
یک Workflow واقعی شامل ترتیب مشخصی از Nodeهاست: Telegram Trigger پیام را دریافت میکند، Set Node فیلدها را نرمال‌سازی میکند، HTTP Request داده را به API می‌فرستد و Supabase Node نتیجه را ذخیره میکند. این زنجیره برای کسی که با n8n آشناست، در حدود 30 دقیقه قابل ساخت است.
گام‌به‌گام:
- ساخت Telegram Trigger: یک Bot در BotFather بسازید، Token را در n8n وارد کنید و Trigger را روی «Message Received» تنظیم کنید
- اضافه‌کردن Set Node: فیلدهای پیام و نام کاربر را از ساختار JSON خام استخراج و نام‌گذاری مجدد کنید
- HTTP Request: داده‌ی نرمال‌شده را به API دلخواه (مثلاً یک Endpoint داخلی) بفرستید
- Supabase Insert: نتیجه یا داده‌ی اولیه را در یک جدول Supabase ذخیره کنید
- فعال‌سازی Workflow: Toggle را روشن کنید و یک پیام تستی بفرستید
نکته‌ی عملی: اولین بار که Trigger را فعال میکنید، n8n یک Test Execution میسازد. این را با Production Execution اشتباه نگیرید. Test Execution فقط در محیط ویرایشگر اجرا میشود؛ تا Workflow فعال نباشد، هیچ پیام واقعی‌ای پردازش نمی‌شود.
اشتباه رایج: فراموشکردن صفحه‌بندی (Pagination) در HTTP Request وقتی API پاسخ چندصفحه‌ای برمی‌گرداند. اگر API شما 100 رکورد در هر صفحه برمی‌گرداند و شما 500 رکورد دارید، بدون تنظیم Pagination فقط 100 رکورد اول را می‌گیرید و بقیه گم می‌شوند.
چطور با n8n ایجنت هوش مصنوعی بسازم؟ معماری واقعی AI Agent Node#
AI Agent Node در n8n از الگوی ReAct (Reason + Act) استفاده میکند: ایجنت ابتدا فکر میکند، سپس یک Tool Node صدا می‌زند، نتیجه را می‌خواند و دوباره تصمیم می‌گیرد. Tool Node دقیقاً نقش فراخوانی تابع (Function Calling) را بازی میکند. ایجنت هوش مصنوعی (AI Agent) در n8n یک بسته‌ی چهارجزئی است: LLM، System Prompt، Tool Nodes و Memory Module.
ساختار AI Agent Node — LLM + System Prompt + Tool Nodes + Memory#
یک LLM (مدل زبانی بزرگ) تصمیم می‌گیرد، یک System Prompt رفتار ایجنت را تعریف میکند، چند Tool Node گره‌های ابزاری‌اند که ایجنت آن‌ها را صدا می‌زند، و یک Memory Module تاریخچه‌ی مکالمه را نگه می‌دارد. بدون Memory، ایجنت هر بار از صفر شروع میکند و به مکالمات قبلی ارجاع نمی‌دهد.
اتصال به Ollama برای مدل محلی و Pinecone برای Vector Store#
برای استفاده از مدل محلی (بدون هزینه‌ی API خارجی)، n8n به Ollama متصل میشود. Ollama یک Runtime سبک برای اجرای مدل‌های زبانی روی سرور خودتان است. برای پایگاه داده‌ی برداری (Vector Store) می‌توانید از Pinecone، Qdrant یا حتی Supabase Vector استفاده کنید. انتخاب بین این‌ها به حجم داده و نیاز به جستجوی فازی (Fuzzy Search) بستگی دارد.
الگوی تکرارشونده‌ی شکست در پروژه‌های واقعی: بزرگ‌ترین مشکل نه ساخت ایجنت، بلکه مدیریت پنجره‌ی زمینه (Context Window) و محدودیت توکن در ایجنت‌های چندابزاری است. وقتی 5 Tool Node دارید و هر کدام پاسخ طولانی برمی‌گرداند، ایجنت در دور سوم از Token Limit عبور میکند و پاسخ ناقص یا خطا می‌دهد.
راه‌حل عملی: محدودکردن تعداد Tool Calls در هر Execution + خلاصه‌سازی خروجی Tool با Function Node قبل از بازگشت به ایجنت. بهجای اینکه خروجی خام Web Search (مثلاً 3000 توکن) مستقیم به ایجنت برگردد، یک Function Node آن را به 200 توکن خلاصه میکند.
مثال Workflow مشخص: Telegram Trigger → AI Agent Node (با Tools: Web Search + Supabase Query) → Slack Notification. ایجنت پیام کاربر را می‌گیرد، تصمیم می‌گیرد که باید جستجوی وب کند یا دیتابیس را بپرسد، نتیجه را می‌خواند و پاسخ نهایی را در کانال Slack ارسال میکند.
n8n در برابر Zapier، Make و LangChain: مقایسه‌ی واقعی نه سطحی#
n8n برای Orchestration بصری و اتصال سریع ابزارها ساخته شده، LangChain برای کنترل دقیق‌تر Prompt Engineering و Memory Management — این دو مکمل‌اند نه رقیب. Zapier ساده‌تر ولی گران‌تر است و Make انعطاف میانی دارد. مقایسه‌ی سطحی «n8n رایگان است، Zapier پولی است» بدون ذکر هزینه‌ی پنهان Self-hosting و محدودیت Fair-Code، گمراه‌کننده است.
| معیار | n8n | Zapier | Make | LangChain |
|---|---|---|---|---|
| مدل قیمت | Self-hosted رایگان / Cloud اشتراکی | اشتراک ماهانه بر اساس Task | اشتراک بر اساس Operation | کتابخانه‌ی رایگان (هزینه‌ی API جدا) |
| نیاز به کدنویسی | پایه‌ی JavaScript برای سناریوهای پیچیده | تقریباً صفر | کم تا متوسط | پایتون ضروری |
| محدودیت Execution | Self-hosted: محدود به منابع سرور | سقف Task ماهانه در هر پلن | سقف Operation ماهانه | محدودیتی ندارد (فقط هزینه‌ی API) |
| مدیریت داده‌ی حساس | Self-hosted: داده روی سرور خودتان | داده روی سرورهای Zapier | داده روی سرورهای Make | بسته به Deployment شما |
| اکوسیستم AI | AI Agent Node بصری | AI Actions محدود | AI Modules در حال توسعه | کامل‌ترین ابزار ایجنت‌سازی |
مهاجرت از Zapier به n8n زمان‌بر است چون هر Workflow باید از صفر بازسازی شود. Zapier هیچ ابزار Export/Import به n8n ندارد. اگر 50 Workflow در Zapier دارید، انتظار 50 بار ساخت مجدد را داشته باشید.
چه‌زمانی LangChain بهتر است؟ نیاز به Custom Memory، RAG (تولید متن با بازیابی — Retrieval-Augmented Generation) پیچیده با Chunking سفارشی، و ارزیابی (Evaluation) ایجنت. در این موارد، کنترل کدنویسی‌شده بر پرامپت و حافظه، از بصری‌سازی n8n دقیق‌تر است.
مدیریت خطا و ریکانسی: الگویی که آموزش‌های رایگان نمی‌دهند#
در محیط واقعی، نمایش فقط مسیر موفقیت (Happy Path) کافی نیست؛ الگوی صحیح شامل Error Workflow (جریان کاری جداگانه برای مدیریت خطا) + Retry Strategy (استراتژی تلاش مجدد) با Backoff تصاعدی + Notification Node برای اطلاع‌رسانی است. بدون این سه، اولین قطعی سرویس، کل سیستم شما را بیسروصدا از کار می‌اندازد.
Error Workflow — ساخت Workflow مستقل برای خطاها#
Error Workflow یک Workflow کاملاً جداگانه است که فقط خطاهای Workflowهای دیگر را دریافت و پردازش میکند. در تنظیمات هر Workflow اصلی، می‌توانید یک Error Workflow مشخص را تعریف کنید. وقتی Nodeای خطا می‌دهد، n8n اطلاعات خطا (Node نام، پیام، Input، Output) را به Error Workflow پاس می‌دهد. در آنجا می‌توانید خطا را لاگ کنید، به Slack بفرستید یا حتی تلاش مجدد منطقی انجام دهید.
Retry Strategy — تنظیم تلاش مجدد و Backoff#
در تنظیمات هر Node، می‌توانید تعداد تلاش مجدد و فاصله‌ی بین تلاش‌ها را مشخص کنید. الگوی عملی: HTTP Request با Retry 3 بار و Backoff 5 ثانیه‌ای. یعنی اگر درخواست اول شکست خورد، 5 ثانیه صبر میکند و دوباره تلاش میکند. در صورت شکست نهایی، خطا به Error Workflow ارسال میشود.
اشتباه رایج: Loop بیپایان وقتی خروجی یک Node به ورودی خودش وصل میشود بدون شرط توقف. n8n هیچ مکانیزم خودکار برای تشخیص Cycle ندارد. اگر Loop طراحی میکنید، حتماً یک IF Node با شرط خروج بگذارید.
چه‌زمانی n8n انتخاب درستی نیست؟#
n8n برای سناریوهای رویدادمحور (Event-Driven) با تأخیر (Latency) زیر 100 میلی‌ثانیه، حجم بالای Webhook (هزاران Event در دقیقه)، و تیم‌های بدون هیچ دانش فنی حتی در حد Docker مناسب نیست. در این موارد ابزارهای دیگر یا معماری متفاوت لازم است.
محدودیت Latency: n8n Workflow را به‌صورت ترتیبی (Sequential) اجرا میکند؛ هر Node یک HTTP Request جداگانه است و Overhead شبکه جمع میشود. اگر به پاسخ زیر 100 میلی‌ثانیه نیاز دارید، n8n ابزار مناسبی نیست.
محدودیت حجم: Self-hosted n8n روی یک سرور محدودیت همزمانی Execution دارد؛ برای Event Streaming واقعی، ابزارهایی مثل Apache Kafka + Worker سفارشی مناسب‌ترند.
محدودیت تیم: اگر هیچ‌کس در تیم Docker، REST API یا JavaScript نمی‌داند، Cloud هم حل‌کننده نیست چون دیباگ کردن خطاها دانش فنی می‌خواهد. n8n Cloud نگهداری سرور را حذف میکند، نه نیاز به فهم خطا را.
محدودیت GDPR و داده‌ی حساس: n8n Cloud داده را روی سرورهای اروپایی پردازش میکند؛ اگر سازمان شما داده را از کشور خارج نمی‌کند، Self-hosting اجباری است.
معماری Fair-Code و پیامدهای تجاری آن#
n8n با مجوز Fair-Code منتشر میشود، نه MIT یا Apache؛ یعنی کد منبع باز است و می‌توانید Self-host کنید، اما نمی‌توانید n8n را بهعنوان SaaS برند سفید (White-label) بفروشید بدون اجازه‌ی تجاری. این محدودیت در اکثر آموزش‌های فارسی ذکر نمی‌شود — و پیامدش، تصمیمات تجاری غلط در مقیاس بزرگ است.
تفاوت Fair-Code با Open-Source: کد خوانا و قابل تغییر است، اما استفادهی تجاری مستقیم (فروش بهعنوان محصول خودتان) نیازمند Sublicense (مجوز فرعی) از شرکت n8n است. استفادهی داخلی و Self-host کاملاً آزاد است.
پیامد عملی: اگر می‌خواهید با n8n به مشتریان اتوماسیون بفروشید، می‌توانید بهعنوان Service (مشاوره و پیاده‌سازی) عمل کنید، نه بهعنوان Product. یعنی n8n را برای مشتری نصب و پیکربندی کنید، اما آن را با برند خودتان بهعنوان نرم‌افزار خودتان بفروشید — این ممنوع است.
مقایسه‌ی کوتاه با MIT و Apache: در MIT هر استفاده‌ای آزاد است؛ در Fair-Code، استفادهی داخلی و Self-host آزاد است اما فروش مجدد محدود. Jan Oberhauser بنیان‌گذار این مدل را برای پایداری مالی پروژه بدون تبدیل‌شدن به شرکت بسته طراحی کرده — یک تصمیم آگاهانه، نه یک نقص.
آموزش n8n اگر فقط Happy Path و بدون ذکر هزینه‌های واقعی Self-hosting، محدودیت Fair-Code و چالش Token Limit در ایجنت‌ها باشد، یک تبلیغ است نه آموزش. این راهنما مرزهای واقعی ابزار را نشان داد تا تصمیم‌گیری‌تان بر اساس واقعیت باشد، نه ادعای بازاریابی.
اگر می‌خواهید ایجنت با n8n بسازید و از همان ابتدا با چالش‌های واقعی Token Limit، Error Handling و معماری ReAct آشنا شوید، دوره‌ی «ساخت AI Agent با n8n» در کامیونیتی n8n School دقیقاً همین مسیر را طی میکند.
دیدگاه‌ها
برای گذاشتن دیدگاه وارد شو
دیدگاه‌ها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.