Agentic AI Workflow چیست و چه فرقی با اتوماسیون معمولی دارد؟

در Workflow سنتی، مراحل از قبل مشخص‌اند: اگر فرم ثبت شد، ایمیل ارسال کن؛ اگر پرداخت موفق بود، سفارش را تایید کن. اما در Agentic AI یک مدل زبانی می‌تواند بر اساس هدف، Context و ابزارهای در دسترس تصمیم بگیرد که چه Actionهایی اجرا شوند.

برای مثال یک Agent پشتیبانی می‌تواند متن کاربر را تحلیل کند، نوع مشکل را تشخیص دهد، اطلاعات مشتری را از API ایرانی CRM دریافت کند، وضعیت پرداخت را از یک درگاه بررسی کند، مستندات داخلی را جست‌وجو کند و سپس تصمیم بگیرد پاسخ مستقیم بدهد یا Ticket را برای نیروی انسانی Escalate کند.

چرا سرور مجازی خارج برای Agentic AI جذاب است؟

بسیاری از Agentهای امروزی فقط به یک API متصل نیستند. یک Workflow ممکن است در یک اجرای واحد به مدل زبانی، Search API، سرویس Embedding، پایگاه داده خارجی، GitHub، Slack، Google Workspace یا چند سرویس SaaS دیگر متصل شود.

قرار دادن Workflow Engine روی یک VPS خارج می‌تواند مسیر ارتباط با این سرویس‌ها را ساده‌تر کند و یک IP ثابت خارجی در اختیار شما قرار دهد. مهم‌تر از آن، n8n به‌صورت Self-hosted روی همان سرور اجرا می‌شود و Workflow، Credentialها، Execution History و منطق تجاری تحت کنترل خودتان قرار می‌گیرد. n8n نیز رسماً امکان Deploy روی زیرساخت شخصی را ارائه می‌دهد.
وب‌سایت رسمی n8n

n8n Self-Hosted دقیقاً چه چیزی به ما می‌دهد؟

n8n یک Workflow Automation Platform است که در نسخه Self-hosted می‌تواند روی Docker، Docker Compose یا زیرساخت شخصی اجرا شود. در نسخه‌های فعلی، n8n علاوه بر Workflowهای کلاسیک، قابلیت AI Agent، اتصال به مدل‌های مختلف، MCP و RAG را نیز در اختیار کاربران قرار می‌دهد.

این نکته برای پروژه‌های ایرانی مهم است؛ زیرا اگر برای یک سرویس داخلی Node آماده وجود نداشته باشد، معمولاً می‌توان با HTTP Request Node مستقیماً API آن سرویس را فراخوانی کرد.

Agent در n8n چگونه کار می‌کند؟

در یک Workflow Agentic معمولاً چهار جزء اصلی دارید: مدل زبانی، Memory، Tool و Trigger. Tool می‌تواند هر Workflow، HTTP API، Database Query یا سرویس خارجی باشد.

یک اصلاح مهم: Make Self-hosted با n8n Self-hosted یکی نیست

در بسیاری از مقالات عبارت Make Self-hosted به شکلی استفاده می‌شود که تصور می‌شود می‌توان کل پلتفرم Make را مانند n8n روی یک VPS نصب کرد. در سرویس فعلی Make، این برداشت دقیق نیست.

طبق اطلاعات فعلی Make، سناریوهای اصلی روی زیرساخت Cloud این شرکت در AWS اجرا می‌شوند. قابلیت On-prem Agent در پلن Enterprise اجازه می‌دهد Make به API یا سرویس داخل شبکه خصوصی شما متصل شود، اما خود Make Scenario Engine به‌صورت معمول روی VPS شخصی شما نصب نمی‌شود.

اطلاعات رسمی:
Make On-prem Agent

چرا اتصال VPS خارج به APIهای ایرانی می‌تواند چالش‌برانگیز شود؟

این بخش همان جایی است که یک مقاله معمولی درباره n8n کافی نیست. وقتی Workflow شما خارج از ایران اجرا می‌شود اما قرار است به سرویس‌های داخلی متصل شود، مسیر شبکه اهمیت زیادی پیدا می‌کند.

بسته به Provider، ممکن است API ایرانی از IP خارجی بدون مشکل پاسخ دهد، IP ثابت را Whitelist کند یا به دلایل امنیتی و شبکه‌ای دسترسی برخی Locationها محدود باشد. بنابراین قبل از طراحی Production باید API موردنظر از همان VPS واقعی تست شود.

سه معماری برای اتصال Agent خارجی به API ایرانی

سناریوی واقعی: Agent فروش متصل به APIهای ایرانی

فرض کنید یک فروشگاه دارید و می‌خواهید Agent هوشمند فقط جواب سؤال ندهد، بلکه بتواند وضعیت مشتری را بررسی و عملیات انجام دهد.

وب‌سرویس‌هایی مانند سرویس پیامک کاوه‌نگار نیز API ارائه می‌کنند و می‌توان آنها را در Workflowهای HTTP محور قرار داد. برای جزئیات فنی هر سرویس باید مستندات همان Provider بررسی شود.
مستندات API کاوه‌نگار

چگونه API ایرانی را در n8n فراخوانی کنیم؟

اگر سرویس Node آماده نداشته باشد، تقریباً همیشه می‌توانید از HTTP Request استفاده کنید. کافی است Method، URL، Header و Body را مطابق مستندات API تنظیم کنید.

نمونه عمومی درخواست Bearer Token

curl -X POST "https://api.example.ir/v1/action" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "customer_id": 1258,
    "action": "check_status"
  }'

نصب n8n روی VPS خارج با Docker

n8n استفاده از Docker را برای بسیاری از سناریوهای Self-hosting پشتیبانی می‌کند و در مستندات فعلی Docker Compose نیز یکی از روش‌های اصلی نصب است.

برای شروع ساده ابتدا Docker و Compose را نصب کنید:

sudo apt update
sudo apt install docker.io docker-compose-v2 -y
sudo systemctl enable --now docker

یک پوشه برای Stack ایجاد کنید:

mkdir -p /opt/n8n
cd /opt/n8n

Docker Compose پایه برای n8n + PostgreSQL

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: CHANGE_THIS_PASSWORD
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      - postgres
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: CHANGE_THIS_PASSWORD
      N8N_ENCRYPTION_KEY: CHANGE_TO_A_LONG_RANDOM_SECRET
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://n8n.example.com/
      GENERIC_TIMEZONE: Asia/Tehran
      TZ: Asia/Tehran
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
  postgres_data:

در نسخه‌های جدید n8n بهتر است برای Reverse Proxy از N8N_WEBHOOK_URL استفاده شود. متغیر قدیمی WEBHOOK_URL از نسخه 2.35.0 Deprecated شده است.

اجرای Stack:

docker compose up -d
docker compose ps
docker compose logs -f n8n

چرا PostgreSQL بهتر از SQLite است؟

برای تست و Workflow کم‌حجم SQLite ساده است، اما وقتی Execution زیاد می‌شود، چند Worker دارید یا Queue Mode فعال می‌کنید، PostgreSQL انتخاب مناسب‌تری برای Production است. مستندات n8n نیز برای معماری Queue Mode استفاده از SQLite را توصیه نمی‌کنند.

Webhook؛ مهم‌ترین بخش n8n روی VPS خارج

بخش زیادی از Workflowها با Webhook شروع می‌شوند. برای مثال سایت شما پس از ثبت سفارش یک Request به n8n می‌فرستد یا سرویس پرداخت نتیجه Transaction را به یک Callback اعلام می‌کند.

اگر n8n پشت Nginx یا Reverse Proxy قرار دارد، باید URL عمومی صحیح برای Webhook تعریف شود؛ در غیر این صورت ممکن است n8n آدرس داخلی Port 5678 را تولید کند. مستندات فعلی n8n برای این حالت N8N_WEBHOOK_URL و N8N_PROXY_HOPS را معرفی می‌کنند.

N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

معماری Hybrid؛ بهترین راه برای API خارجی + API ایرانی

در بسیاری از پروژه‌های ایرانی بهترین معماری این نیست که همه چیز را فقط در ایران یا فقط در خارج قرار دهید. معماری Hybrid می‌تواند مزیت هر دو Location را هم‌زمان بدهد.

مسیر پیشنهادی درخواست

User
  |
  v
n8n Agent - Foreign VPS
  |
  +------> OpenAI / Claude / Gemini
  |
  +------> Global SaaS APIs
  |
  +------> Secure Iran API Gateway
              |
              +----> SMS API
              +----> Payment API
              +----> Iranian CRM
              +----> Internal ERP

چه منابعی برای n8n Agentic AI نیاز داریم؟

اگر خود LLM روی VPS اجرا نمی‌شود و فقط API مدل خارجی را فراخوانی می‌کنید، n8n به GPU نیاز ندارد. مصرف اصلی متعلق به Node.js، Database، تعداد Executionها و داده‌هایی است که بین Nodeها منتقل می‌شوند.

این مقادیر نقطه شروع عملی هستند و عدد ثابت رسمی برای همه Workflowها محسوب نمی‌شوند. یک Workflow که فایل 100MB پردازش می‌کند می‌تواند چند برابر یک Workflow متنی ساده RAM مصرف کند.

Queue Mode در n8n برای چیست؟

وقتی تعداد Workflowها بالا می‌رود، بهتر است فرآیند دریافت Webhook و اجرای واقعی Job از هم جدا شود. n8n برای این کار Queue Mode دارد. در این معماری Main Instance درخواست‌ها را مدیریت می‌کند و Workerها Jobها را از Queue دریافت می‌کنند.

برای Queue Mode، Redis در نقش Queue Broker قرار می‌گیرد و چند Worker می‌توانند به Redis و Database مشترک متصل شوند. n8n همچنین امکان اجرای چند Worker را فراهم می‌کند.

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

چه زمانی Queue Mode لازم نیست؟

اگر روزانه چندصد Workflow سبک دارید، اضافه کردن Redis و چند Worker فقط معماری را پیچیده می‌کند. ابتدا یک Instance ساده و PostgreSQL راه‌اندازی کنید و Metrics واقعی را ببینید.

MCP چه نقشی در Agentic Workflow دارد؟

Model Context Protocol یا MCP روشی استاندارد برای معرفی Toolها و قابلیت‌ها به AI Clientهاست. n8n در نسخه‌های فعلی MCP Server رسمی دارد و می‌تواند Workflowهای انتخاب‌شده را در اختیار AI Client سازگار قرار دهد.

یعنی می‌توانید یک Workflow برای «استعلام سفارش»، یکی برای «ارسال پیامک» و دیگری برای «ایجاد Ticket» بسازید و آنها را به‌عنوان Tool در اختیار Agent قرار دهید.

Human-in-the-loop؛ بخشی که نباید از Agent حذف شود

AI Agent می‌تواند اشتباه کند. بنابراین Workflowهای دارای اثر واقعی نباید صرفاً به خروجی مدل اعتماد کنند.

امنیت Credentialهای ایرانی و خارجی

یک Workflow Agentic ممکن است هم‌زمان API Key مدل AI، توکن پیامک، Secret پرداخت، Credential Database و OAuth Token داشته باشد. بنابراین Backup و Encryption n8n از خود Workflow مهم‌تر می‌شود.

n8n از Encryption Key برای محافظت از Credentialهای ذخیره‌شده استفاده می‌کند. اگر از Worker استفاده می‌کنید، Main و Workerها باید Encryption Key یکسان داشته باشند تا Credentialها قابل استفاده باشند.

N8N_ENCRYPTION_KEY=use-a-long-random-secret-here

امن‌سازی n8n روی اینترنت

Firewall پایه

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Webhookهای ایرانی را چگونه امن کنیم؟

اگر یک سرویس ایرانی قرار است Callback را به VPS خارج ارسال کند، Endpoint شما باید Public باشد؛ اما Public بودن به معنی بدون احراز هویت بودن نیست.

Idempotency چرا در Workflowهای مالی حیاتی است؟

اگر Provider یک Webhook را دوبار ارسال کند، Workflow نباید دوبار اعتبار مشتری را افزایش دهد یا دو پیامک سفارش ثبت کند. برای Actionهای حساس یک Event ID یا Transaction ID را در Database ثبت کنید و قبل از اجرای Action بررسی کنید که قبلاً Process نشده باشد.

Retry هوشمند برای APIهای داخلی

قطع موقت شبکه نباید باعث شکست کل Agent شود. اما Retry بی‌نهایت هم خطرناک است.

Agent نباید آزادانه هر API را صدا بزند

یکی از خطرهای Agentic AI این است که ابزار بسیار قدرتمندی در اختیار مدل قرار دهیم. اگر Tool شما Endpoint عمومی HTTP باشد و مدل بتواند URL یا Body را آزادانه بسازد، سطح ریسک بالا می‌رود.

بهتر است Toolهای Agent محدود و هدفمند باشند. برای نمونه به‌جای Tool عمومی «HTTP Request»، Tool جداگانه‌ای با نام «CheckPaymentStatus» بسازید که فقط Transaction ID را بگیرد و خودش Endpoint، Method و Authentication را مدیریت کند.

نمونه Agentهای قابل ساخت روی n8n

Make چه زمانی بهتر از n8n است؟

اگر نمی‌خواهید مسئول Update سیستم‌عامل، Docker، Database، Monitoring و Backup باشید، Make می‌تواند تجربه ساده‌تری ارائه دهد. Make در حال حاضر هزاران Integration آماده و AI Agent داخل Canvas دارد.

اما اگر هدف اصلی شما Self-hosting کامل Workflow Engine، کنترل VPS، Community Node، Custom Code یا معماری اختصاصی است، n8n انعطاف بیشتری برای این مدل Deploy فراهم می‌کند.

Make On-prem Agent برای API ایرانی چه کاربردی دارد؟

در سازمانی که Make Enterprise دارد، می‌توان On-prem Agent را روی Linux نصب کرد و از HTTP Agent برای دسترسی به API موجود در شبکه خصوصی استفاده کرد. Make اعلام کرده که On-prem Agent امکان اتصال به Applicationها و Databaseهایی را فراهم می‌کند که مستقیماً از اینترنت قابل دسترسی نیستند.

این روش از نظر معماری با «Self-host کردن Make» فرق دارد. Agent واسط داخل شبکه شماست اما Scenario همچنان متعلق به محیط Make است.

چگونه بفهمیم API ایرانی از VPS خارج قابل دسترسی است؟

اول DNS و TLS را تست کنید:

curl -I https://api.example.ir
curl -v https://api.example.ir

زمان اتصال را هم بررسی کنید:

curl -o /dev/null -s \
  -w "DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTotal: %{time_total}\n" \
  https://api.example.ir

اگر GET ساده موفق است، باز هم Endpoint واقعی با Authentication را در محیط Test Provider آزمایش کنید؛ چون Policy بعضی APIها روی Endpointهای مختلف متفاوت است.

چه زمانی VPS ایران به‌عنوان Relay لازم می‌شود؟

Relay ایران باید چقدر قوی باشد؟

اگر VPS ایران فقط نقش Reverse Proxy یا API Gateway را دارد و هیچ مدل AI روی آن اجرا نمی‌شود، معمولاً منابع زیادی نیاز نیست. مصرف اصلی به تعداد Request و Logging بستگی دارد.

چه اطلاعاتی نباید به LLM خارجی ارسال شود؟

Agentic Workflow به این معنی نیست که تمام Payload هر API را مستقیماً وارد Prompt کنید. بهتر است قبل از ارسال به مدل، داده را Minimize و Mask کنید.

Pattern بهتر: Tool نتیجه محدود برگرداند

به‌جای اینکه Agent پاسخ خام API پرداخت را ببیند، Workflow واسط فقط خروجی محدود و قابل‌فهم تولید کند:

{
  "payment_status": "paid",
  "order_id": 8241,
  "amount": 1250000
}

در این حالت Agent اطلاعاتی را دریافت می‌کند که برای تصمیم لازم است، نه کل Response داخلی Provider.

Backup و Disaster Recovery در n8n

برای Production سه بخش باید Backup شوند: Database، Volume مربوط به n8n و Encryption Key. اگر فقط Workflow JSON داشته باشید، Execution History و بخشی از تنظیمات عملیاتی را از دست می‌دهید.

مانیتورینگ Workflowها

Agent ممکن است ظاهراً فعال باشد اما API خارجی Timeout بدهد، Worker Crash کند یا Queue پر شود. بنابراین فقط Up بودن Container کافی نیست.

برای بررسی اولیه:

docker compose ps
docker stats
free -h
df -h
uptime

چه چیزی را مانیتور کنیم؟

چرا Execution Data می‌تواند دیسک را پر کند؟

در n8n هر Execution می‌تواند Input و Output Nodeها را ذخیره کند. اگر روزانه هزاران Execution اجرا شود یا Workflow فایل و JSON بزرگ پردازش کند، Database به مرور رشد زیادی می‌کند.

برای Production باید Retention و Pruning متناسب با نیاز Audit تنظیم شود. Workflow موفقی که یک سال قبل اجرا شده لزوماً لازم نیست تمام Payload خود را برای همیشه نگه دارد.

اشتباهات رایج در اجرای n8n روی VPS خارج

n8n یا Make برای کسب‌وکار ایرانی؟

چک‌لیست Production قبل از فعال کردن Agent

سوالات متداول درباره n8n، Agentic AI و VPS خارج

آیا n8n را می‌توان روی سرور مجازی خارج نصب کرد؟

بله. n8n رسماً Self-hosting را پشتیبانی می‌کند و می‌توان آن را با Docker یا Docker Compose روی VPS لینوکس اجرا کرد.

آیا Make هم مثل n8n کاملاً Self-hosted است؟

در سرویس فعلی عمومی Make، خیر. Make روی زیرساخت Cloud اجرا می‌شود و در Enterprise قابلیت On-prem Agent برای اتصال Cloud Make به سرویس‌های شبکه خصوصی وجود دارد.

آیا VPS خارج می‌تواند به API ایرانی وصل شود؟

در بسیاری از موارد بله، اما این موضوع به Provider، WAF، IP Policy و وضعیت شبکه بستگی دارد. باید API واقعی را از IP همان VPS تست کنید.

اگر API ایرانی فقط IP ایران را قبول کند چه کنیم؟

می‌توان یک VPS ایران را به‌عنوان API Gateway یا Relay قرار داد و n8n خارجی فقط با آن Gateway امن ارتباط برقرار کند.

برای n8n چند گیگ RAM لازم است؟

برای تست سبک می‌توان از حدود 2GB شروع کرد. برای Workflow تجاری همراه PostgreSQL معمولاً 4GB فضای عملیاتی بهتری می‌دهد و برای Agentهای پرتعداد یا Workerهای متعدد ممکن است 8GB یا بیشتر لازم شود.

آیا برای Agentic AI روی n8n به GPU نیاز است؟

اگر LLM از طریق API خارجی فراخوانی شود، خیر. GPU فقط زمانی اهمیت پیدا می‌کند که بخواهید مدل زبانی را روی همان سرور اجرا کنید.

آیا PostgreSQL برای n8n ضروری است؟

برای آزمایش کوچک SQLite قابل استفاده است، اما برای Production، رشد Executionها و Queue Mode استفاده از PostgreSQL معماری مناسب‌تری است.

Queue Mode چه زمانی لازم می‌شود؟

وقتی Workflowهای هم‌زمان زیاد می‌شوند یا اجرای Jobهای طولانی باعث فشار روی Main Instance می‌شود، می‌توان با Redis و Workerهای جداگانه اجرای Workflowها را توزیع کرد.

آیا n8n برای اتصال به سرویس ایرانی Node اختصاصی لازم دارد؟

خیر. اگر سرویس API مبتنی بر HTTP ارائه کند، معمولاً HTTP Request Node برای اتصال کافی است و می‌توان Header، Query، Authentication و Body را متناسب با مستندات API تنظیم کرد.