n8n چیست؟ آموزش ساخت ایجنت هوش مصنوعی برای کسب‌وکارها

برای اینکه یک متن تولیدشده بدون بازبینی به پیام ارسالی تبدیل نشود، تولید پاسخ را از اجازه ارسال جدا کنید. طبق معرفی n8n در Microsoft Learn برای اکوسیستم Agent 365، n8n پلتفرمی برای خودکارسازی گردش‌کار و اتصال برنامه‌هاست. گردش‌کار (Workflow) یعنی زنجیره‌ای مشخص از دریافت ورودی، پردازش و تولید خروجی.

این راهنما برای مدیر عملیات و مسئول فنی کسب‌وکاری است که می‌خواهد درخواست‌های متنی مشتری را به فرایندی قابل کنترل وصل کند. مسیر آموزش از تعیین حدود اختیار شروع می‌شود و به ساخت نمونه n8n و آزمون خطا می‌رسد؛ آموزش نصب کامل زیرساخت یا نسخه آماده اتصال به سامانه واقعی نیست. برای تصمیم‌های مالی یا تغییر برگشت‌ناپذیر داده، نمونه گفت‌وگویی را بدون کنترل مستقل وارد کار روزانه نکنید.

در n8n چه تصمیمی را باید به مدل سپرد؟

مدل زبانی بزرگ (LLM) یعنی سامانه‌ای برای پردازش و تولید زبان. طبق مستندات الگوهای برنامه‌های ایجنتی در Microsoft Learn، ایجنت هوش مصنوعی (AI Agent) سامانه‌ای است که مدل در آن انتخاب ابزار و گام بعدی را هدایت می‌کند. طبق همین مستندات Microsoft Learn، در گردش‌کار قطعی، کد مسیر اجرا را تعیین می‌کند. برای طراحی در n8n، فقط تصمیم‌هایی را به مدل بسپارید که با قواعد روشن ازپیش‌نوشته‌شده حل نمی‌شوند.

ابزار (Tool) یعنی تابعی که سامانه برای انجام کاری مشخص فراخوانی می‌کند. مثلاً در فروشگاه اینترنتی، خواندن وضعیت سفارش یک ابزار است؛ اما تفسیر جمله «بسته‌ام هنوز نرسیده» یک وظیفه زبانی است. اگر بعد از تشخیص درخواست همیشه باید همان ابزار خوانده شود، هنوز دلیلی برای سپردن انتخاب مسیر به مدل ندارید. برای تصمیم طراحی، گزینه‌ها را با معیارهای یکسان مقایسه کنید.

اگر ترتیب مراحل از پیش روشن است، گردش‌کار ثابت را انتخاب کن؛ اگر انتخاب ابزار بعدی واقعاً به نتیجه مرحله قبلی وابسته است، ایجنت با ابزارهای محدود را انتخاب کن.

کم‌کد (Low-code) یعنی ساخت بخش عمده منطق با اجزای آماده و تکمیل فنی در نقاط لازم. طبق Microsoft Learn، n8n در این دسته قرار می‌گیرد؛ اما برای پروژه کسب‌وکاری، تعریف قرارداد داده، مجوز و رفتار هنگام خطا را از برنامه کار حذف نکنید. اتصال اجزا فقط بخشی از طراحی است.

وقتی پاسخ درست است اما فرایند قابل اعتماد نیست

برای سنجش قابل‌اعتمادبودن ایجنت n8n، خروجی هر مرحله را جدا از پیام نهایی بررسی کنید. اگر متن پاسخ درست است اما معلوم نیست اطلاعات از کجا آمده، چه کسی اجازه دسترسی داشته و چه چیزی واقعاً ارسال شده، پرونده هنوز قابل تأیید نیست. معیار پیشنهادی پذیرش، امکان دنبال‌کردن درخواست از ورودی تا نتیجه ثبت‌شده در سامانه مقصد است، نه صرفاً پایان‌یافتن اجرای گردش‌کار.

برای نمونه، در پیگیری سفارش، پاسخ «سفارش شما ارسال شده» باید به وضعیت ثبت‌شده همان سفارش متکی باشد. در برگه ممیزی، شناسه درخواست، منبع اطلاعات و نتیجه ارسال را کنار هم ثبت کنید. اگر فقط متن نهایی را نگه دارید، برای تشخیص تفاوت میان برداشت اشتباه مدل، پاسخ ناقص سرویس و خطای ارسال، مدرک کافی نخواهید داشت.

پیش از اصلاح طراحی، مسیر را چنین ترسیم کنید: پیام مشتری وارد می‌شود، مدل متنی می‌نویسد و همان متن برای مشتری ارسال می‌شود. در این طرح پیشنهادی، محل بررسی مالکیت سفارش یا تأیید پاسخ مشخص نیست. نشانه مسئله همین ابهام است؛ برای هر مرحله باید بتوان مسئول تصمیم و ورودی معتبر آن را نام برد.

پس از تصمیم به جداسازی اختیارها، مسیر را به دریافت پیام، بررسی هویت، خواندن اطلاعات مجاز، تهیه پیش‌نویس، بازبینی و ارسال تفکیک کنید. تغییر اصلی، اضافه‌شدن یک مدل قوی‌تر نیست؛ تولید متن دیگر اجازه ارسال محسوب نمی‌شود. برای بررسی نیازهای گسترده‌تر داده و دسترسی، راهنمای طراحی دستیار متصل به اطلاعات شرکت مکمل این معماری است.

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

آموزش ساخت نمونه اولیه n8n با مدل زبانی

برای ساخت نمونه اولیه n8n، ابتدا اتصال مدل و رفت‌وبرگشت پیام را جدا از داده واقعی کسب‌وکار آزمایش کنید. طبق Google Codelabs، نمونه آموزشی اتصال Gemini به ایجنت n8n با افزودن اجزای گفت‌وگو و مدل ساخته می‌شود و از پنل گفت‌وگو آزمایش می‌شود. نام‌های اجزا در مراحل زیر از همان آموزش Google Codelabs آمده‌اند؛ تطبیق آن‌ها با رابط نسخه نصب‌شده را جدا انجام دهید.

1. یک محیط آزمایشی n8n آماده کنید و آن را به سامانه واقعی ارسال پیام یا تغییر سفارش وصل نکنید. گره (Node) یعنی واحدی از گردش‌کار که وظیفه مشخصی دارد. پیش از افزودن گره‌ها، خروجی مورد انتظار را بنویسید: دریافت یک پیام آزمایشی و تولید پاسخ، بدون دسترسی به اطلاعات مشتری.
2. اطلاعات اتصال (Credential) یعنی داده لازم برای برقراری دسترسی به یک سرویس. طبق مسیر آموزشی Google Codelabs، اطلاعات اتصال Gemini را بسازید و برای اتصال مدل به کار ببرید. کلید دسترسی را داخل متن دستور مدل ننویسید و برای تمرین، حسابی با دسترسی به سامانه‌های عملیاتی شرکت انتخاب نکنید.
3. یک گردش‌کار جدید بسازید. محرک (Trigger) یعنی رویدادی که اجرای گردش‌کار را آغاز می‌کند. طبق Google Codelabs، محرک گفت‌وگوی معرفی‌شده با نام Simple Chat و گره ایجنت را به نمونه اضافه کنید. در این مرحله فقط مشخص کنید پیام ورودی از کجا وارد می‌شود و کدام جزء مسئول پردازش آن است.
4. طبق Google Codelabs، مدل Gemini را به گره ایجنت متصل کنید. یک دستور محدود بنویسید؛ مثلاً از مدل بخواهید موضوع پیام مشتری را تشخیص دهد و در صورت کمبود اطلاعات سؤال تکمیلی بپرسد. هنوز ابزار ارسال پیام یا تغییر داده اضافه نکنید؛ هدف این مرحله بررسی اتصال مدل و دریافت پاسخ است.
5. طبق Google Codelabs، نمونه را از پنل گفت‌وگو اجرا کنید. پیام معمولی، پیام ناقص و درخواست خارج از موضوع را امتحان کنید و پاسخ مورد انتظار را کنار پاسخ دریافتی بنویسید. از مدل درباره وضعیت واقعی سفارش نپرسید؛ هنوز منبع سفارش به آن وصل نشده است. پاسخ روان را مدرک دسترسی به اطلاعات کسب‌وکار ندانید.

ابزار خواندن سفارش را با قرارداد مشخص بسازید

برای تبدیل تمرین به نمونه کسب‌وکاری، یک ابزار محدود با نام read_order_status طراحی کنید. این نام، پیشنهاد آموزشی است و به گره آماده‌ای در n8n اشاره نمی‌کند. ورودی ابزار را شناسه سفارش و هویت تأییدشده درخواست‌کننده تعریف کنید؛ خروجی نیز وضعیت مجاز سفارش یا خطایی مشخص باشد. برای طراحی نشانی درخواست و پاسخ‌های خطا، توضیح قرارداد ورودی و خروجی سرویس کمک می‌کند مرز اتصال را روشن بنویسید.

هویت درخواست‌کننده را از نشست معتبر سامانه دریافت کنید، نه از ادعای او در متن پیام. پیش از تحویل نتیجه ابزار به مدل، دسترسی کاربر به سفارش را در سرویس مقصد بررسی کنید. اگر مجوز وجود ندارد، اطلاعات سفارش را به مدل ندهید؛ تولید پاسخ مؤدبانه جای بررسی مالکیت داده را نمی‌گیرد.

دستور زیر برای محدودکردن وظیفه زبانی نمونه مناسب است، اما کنترل امنیتی محسوب نمی‌شود:

فقط درباره پیگیری سفارش پاسخ بده. اطلاعات وضعیت را از ابزار خواندن سفارش بگیر. اگر شناسه سفارش موجود نیست، آن را درخواست کن. اگر سرویس دسترسی را رد کرد، اطلاعات سفارش را نمایش نده. اگر نتیجه نامشخص بود، پاسخ قطعی نساز و درخواست بررسی انسانی آماده کن. پاسخ را به شکل پیش‌نویس بنویس؛ ارسال پیام و تغییر سفارش در اختیار تو نیست.

وب‌هوک (Webhook) یعنی روشی که یک سامانه هنگام رخ‌دادن رویداد، به سامانه دیگر خبر می‌دهد. برای جایگزینی ورودی آزمایشی با پیام واقعی، ابتدا سازوکار دریافت رویداد با وب‌هوک را روشن کنید. قرارداد دریافت پیام باید شناسه درخواست و منبع آن را مشخص کند؛ مدل نباید مسئول تشخیص معتبر‌بودن فرستنده باشد.

برای خروجی نیز وضعیت‌هایی مانند «پیش‌نویس آماده»، «اطلاعات ناکافی» و «نیازمند بررسی انسانی» تعریف کنید. پیش از عبور به مرحله بعد، وجود داده‌های ضروری و معتبر‌بودن وضعیت را با قواعد قطعی بررسی کنید. اگر خروجی با قرارداد سازگار نیست، آن را به ارسال نفرستید. این ساختار، پیشنهاد معماری است و برای اجرا به پیاده‌سازی اتصال‌ها و آزمون مستقل نیاز دارد.

اختیار ایجنت را کجا و چگونه محدود کنیم؟

اختیار بیش‌ازحد (Excessive Agency) یعنی دادن امکان اجرای عملیات فراتر از نیاز وظیفه؛ OWASP منشأ این خطر را قابلیت اضافی، مجوز اضافی و خودمختاری اضافی تفکیک می‌کند. طبق OWASP، کنترل مجوز باید در سامانه مقصد انجام شود و عملیات پراثر به تأیید انسانی نیاز دارند. برای ایجنت n8n، محدودیت را در ابزار و حساب متصل پیاده کنید، نه فقط در دستور خطاب به مدل.

• قابلیت ابزار را محدود کنید. برای ابزار خواندن وضعیت سفارش، امکان تغییر آدرس یا لغو سفارش تعریف نکنید؛ هر عملیات اضافه را با نیاز مشخص کسب‌وکار توجیه کنید.
• مجوز حساب را محدود کنید. طبق توصیه OWASP، حساب ابزار خواندن نباید صرفاً به دلیل راحتی اتصال، اجازه نوشتن یا حذف داده داشته باشد؛ محدودیت را در سرویس مقصد اعمال کنید.
• خودمختاری را محدود کنید. فهرست عملیات نیازمند تأیید را پیش از اجرا مشخص کنید و اجازه ندهید مدل، حساس‌بودن عملیات پیشنهادی خودش را تنها مرجع تصمیم بداند.

تأیید را به عملیات مشخص متصل کنید

طبق Microsoft Learn در راهنمای تأیید انسانی ابزارها، نظارت انسانی در حلقه (Human-in-the-loop) یعنی اجرای عملیات برای دریافت تصمیم انسان متوقف شود و تصمیم به اجرای بعدی برسد. همان راهنمای Microsoft Learn نمایش نام تابع و ورودی‌های آن را برای تأیید توضیح می‌دهد؛ این توضیح، الگوی Microsoft Agent Framework است و نباید آن را نام تنظیمات آماده n8n دانست.

برای پیاده‌سازی این الگو، درخواست تأیید را همراه شناسه پرونده، متن پیشنهادی، گیرنده و نوع عملیات ذخیره کنید. بازبین باید همان چیزی را ببیند که قرار است اجرا شود. اگر متن یا گیرنده پس از تأیید تغییر کرد، تأیید قبلی را برای نسخه تازه معتبر ندانید. درخواست تأیید، پایان فرایند نیست؛ وضعیت «در انتظار تأیید» باید مسیر ادامه، رد و انقضا داشته باشد.

پیش از اجرای پاسخ تأییدشده، وضعیت سفارش را دوباره بخوانید. مثلاً اگر سفارش در فاصله انتظار لغو شده، پیش‌نویس قدیمی را ارسال نکنید و پرونده را برای بازبینی برگردانید. مدت اعتبار تأیید را متناسب با حساسیت فرایند تعیین کنید و برای بی‌پاسخ‌ماندن درخواست تأیید، مسیر توقف مشخص داشته باشید.

طبق راهنمای اتصال n8n به Microsoft Entra Agent ID در Microsoft Learn، نمونه مستقل با هویت برنامه و نمونه به‌نمایندگی با هویت تفویض‌شده کار می‌کند؛ همان منبع این نمونه را راهنمای استقرار عملیاتی نمی‌داند. در طراحی کسب‌وکار مشخص کنید مجوز متعلق به سرویس است یا کاربر؛ حساب پرمجوز مشترک را جایگزین بررسی دسترسی هر مشتری نکنید.

هزینه و استقرار n8n را با چه معیارهایی بسنجیم؟

هزینه ساخت ایجنت n8n را از روی نام ابزار یا تعداد گره‌ها برآورد نکنید. برای برآورد پروژه، اجرای زیرساخت، مصرف مدل، ساخت اتصال‌ها و رسیدگی انسانی به خطاها را جدا ثبت کنید. طبق Google Codelabs، مسیر استقرار نمونه روی Google Cloud Run به صورتحساب فعال نیاز دارد و منابع حذف‌نشده هزینه ایجاد می‌کنند؛ بنابراین پایان آزمایش را همراه با تصمیم روشن درباره نگهداری یا حذف منابع تعریف کنید.

برای مقایسه گزینه‌ها، یک درخواست نماینده را از ابتدا تا انتها دنبال کنید. تعداد فراخوانی مدل، ابزارهای درگیر، داده جابه‌جاشده و دفعات نیاز به بازبین را ثبت کنید. سپس هزینه همان مسیر را با تعرفه سرویس‌های انتخاب‌شده بسنجید. برای هر درخواست نیز سقف زمان اجرا و تعداد فراخوانی تعریف کنید؛ رسیدن به سقف باید به توقف کنترل‌شده برسد، نه ادامه نامحدود.

اجرای n8n روی زیرساخت سازمان را معادل باقی‌ماندن همه داده‌ها در سازمان نگیرید. در نمونه Google Codelabs، n8n به Gemini متصل می‌شود؛ برای طراحی خودتان مشخص کنید چه داده‌ای به مدل فرستاده می‌شود و کجا ذخیره خواهد شد. اطلاعات غیرضروری مشتری را از ورودی حذف کنید و برای سوابق اجرا، سطح دسترسی و مدت نگهداری تعیین کنید.

مالک نگهداری زیرساخت را هم از ابتدا مشخص کنید. برنامه پشتیبان‌گیری، آزمون بازیابی و رسیدگی به خطاها را کنار ساخت گردش‌کار بنویسید، نه پس از تحویل. اگر تیم مسئول نگهداری ندارید، استقرار روی زیرساخت اختصاصی را فقط به دلیل کنترل بیشتر انتخاب نکنید؛ مسئولیت عملیاتی آن را نیز در مقایسه گزینه‌ها وارد کنید.

چه زمانی نمونه n8n آماده استفاده کسب‌وکاری است؟

نمونه n8n را زمانی برای استفاده محدود کسب‌وکاری بپذیرید که مسیر عادی، خطا و توقف آن آزموده شده باشند. معیار پذیرش را پیش از آزمایش بنویسید: پاسخ باید به داده مجاز متکی باشد، عملیات حساس بدون تأیید اجرا نشود و شکست سرویس به ادعای قطعی تبدیل نشود. برای آزمون اولیه از داده آزمایشی استفاده کنید و نتیجه مورد انتظار هر پرونده را مستقل از پاسخ مدل تعیین کنید.

• یک درخواست کامل و مجاز وارد کنید. وضعیت سفارش در پاسخ باید با داده منبع تطبیق داشته باشد و شناسه درخواست تا ثبت نتیجه ارسال قابل دنبال‌کردن بماند.
• شناسه سفارش متعلق به کاربر دیگر را بفرستید. نتیجه مورد انتظار، نرسیدن اطلاعات سفارش به مدل و کاربر است؛ پاسخ مؤدبانه بدون جلوگیری از دسترسی کافی نیست.
• نبود سفارش و قطع ارتباط سرویس را جداگانه آزمایش کنید. خروجی باید میان «داده پیدا نشد» و «داده قابل دریافت نبود» تفاوت بگذارد و مسیر پیگیری مناسب داشته باشد.
• درخواستی خارج از حدود وظیفه، مانند تغییر سفارش، وارد کنید. نتیجه مورد انتظار، توقف در مرز ابزارهای مجاز یا ارجاع به مسئول مشخص است، نه ساختن مسیر تازه توسط مدل.
• پس از تهیه پیش‌نویس، وضعیت سفارش یا گیرنده را تغییر دهید. تأیید قبلی نباید نسخه تغییریافته را پوشش دهد؛ پرونده باید دوباره به بازبین برگردد.
• یک درخواست ارسال را دوباره وارد کنید و حالت نامعلوم‌بودن نتیجه ارسال قبلی را نیز بسنجید. نتیجه مورد انتظار، جلوگیری از ارسال کورکورانه و ثبت وضعیت قابل پیگیری است.

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

سنجش را نیز به کیفیت متن محدود نکنید. در گزارش آزمایش، صحت اطلاعات، رعایت مجوز، وضعیت تأیید و نتیجه واقعی عملیات را جدا ثبت کنید. اگر مشکل از داده ناقص یا اتصال ناپایدار است، تعویض مدل را اصلاح پیش‌فرض ندانید؛ ابتدا همان مرحله شکست‌خورده را تعمیر و آزمون مرتبط را تکرار کنید. روان‌بودن پاسخ، جای قابلیت پیگیری فرایند را نمی‌گیرد.

نسخه نخست را با اختیار محدود وارد کار کنید و توسعه دسترسی را به نتیجه آزمون‌ها وابسته نگه دارید. اگر اتصال‌های اختصاصی به تیم اجرا نیاز دارند، طراحی اتوماسیون با کنترل انسانی را با ایران‌دیزاینر پیش ببرید.