از مسئله معماری تا طراحی اولین AI Agent

در مقاله پیشین، با معماری درونی AI Agent، مفهوم سیستم‌های چندعاملی (Multi-Agent Systems)، نقش پروتکل Model Context Protocol (MCP) و جایگاه ابزارهایی مانند n8n در اکوسیستم هوش مصنوعی آشنا شدیم. دیدیم که یک AI Agent صرفاً نسخه پیشرفته‌تری از ChatGPT نیست، بلکه سیستمی است که می‌تواند هدف را درک کند، برای رسیدن به آن برنامه‌ریزی انجام دهد، از حافظه استفاده کند، ابزارهای مختلف را به کار گیرد و در قالب یک جریان کاری منسجم، مسئله‌ای واقعی را حل کند.

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

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

ظهور ابزارهای Low-Code و No-Code، به‌ویژه n8n، این وضعیت را تغییر داده است. امروز می‌توان بدون نوشتن هزاران خط کد، عامل‌های هوشمندی طراحی کرد که اسناد پروژه را تحلیل کنند، گزارش تهیه کنند، اطلاعات را میان نرم‌افزارهای مختلف جابه‌جا کنند و حتی مجموعه‌ای از فعالیت‌های تکراری را به‌صورت کاملاً خودکار انجام دهند.

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

این وضعیت شباهت زیادی به دانشجویی دارد که پیش از شناخت مسئله طراحی، نرم‌افزار Revit را باز می‌کند و شروع به ترسیم دیوارها می‌کند. نتیجه معمولاً مدلی خواهد بود که از نظر فنی صحیح است، اما پاسخ مناسبی برای مسئله طراحی ارائه نمی‌دهد.

در طراحی عامل‌های هوشمند نیز دقیقاً همین منطق برقرار است.

یک AI Agent خوب، از n8n آغاز نمی‌شود.

از شناخت مسئله آغاز می‌شود.

نخستین اصل در طراحی Agent؛ مسئله را طراحی کنید، نه Workflow را

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

دلیل این موضوع روشن است.

هوش مصنوعی نمی‌تواند مسئله‌ای را حل کند که هنوز به‌درستی تعریف نشده است.

در معماری نیز همین اصل برقرار است. پیش از آنکه نخستین خط روی کاغذ ترسیم شود، معمار باید بداند قرار است چه مسئله‌ای را حل کند. آیا پروژه یک مدرسه است یا بیمارستان؟ آیا هدف کاهش مصرف انرژی است یا افزایش تعاملات اجتماعی؟ آیا کارفرما به دنبال حداقل هزینه ساخت است یا بیشترین کیفیت فضایی؟

تمام تصمیم‌های بعدی بر اساس پاسخ همین پرسش‌ها شکل می‌گیرند.

طراحی AI Agent نیز دقیقاً از همین نقطه آغاز می‌شود.

به جای آنکه از خود بپرسیم «چگونه با n8n یک Agent بسازیم؟»، باید بپرسیم:

کدام مسئله تکراری دفتر معماری ما ارزش خودکارسازی دارد؟

این تغییر زاویه نگاه، مهم‌ترین تفاوت میان یک کاربر عادی و یک طراح سیستم‌های هوشمند است.

چه مسئله‌ای برای نخستین Agent مناسب است؟

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

تقریباً همیشه چنین پروژه‌ای شکست می‌خورد.

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

در طراحی Agent نیز همین اصل برقرار است.

بهترین پروژه برای شروع، پروژه‌ای است که سه ویژگی داشته باشد.

نخست آنکه مسئله‌ای واقعی را حل کند.

دوم آنکه بارها در طول پروژه‌های مختلف تکرار شود.

و سوم آنکه خروجی آن قابل ارزیابی باشد.

با این معیارها، یکی از مناسب‌ترین نمونه‌ها برای معماران، طراحی یک دستیار تحلیل اسناد معماری است.

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

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

به همین دلیل، در این مجموعه آموزشی، نخستین AI Agent خود را بر اساس همین سناریو طراحی خواهیم کرد.

پروژه‌ای که در این آموزش خواهیم ساخت

فرض کنید یک دفتر معماری پروژه طراحی یک مجموعه آموزشی را دریافت کرده است.

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

پیش از آغاز طراحی، معمار باید صدها صفحه سند را مطالعه کند و پاسخ پرسش‌هایی مانند موارد زیر را بیابد:

حداقل سرانه فضاهای آموزشی چقدر است؟

چه محدودیت‌هایی برای ارتفاع ساختمان وجود دارد؟

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

کدام فضاها باید در مجاورت یکدیگر قرار گیرند؟

چه استانداردهایی برای نور طبیعی یا دسترسی افراد دارای معلولیت وجود دارد؟

پاسخ به این پرسش‌ها معمولاً چندین ساعت یا حتی چندین روز زمان نیاز دارد.

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

کاربر تنها فایل PDF را در اختیار Agent قرار می‌دهد و سؤال خود را مطرح می‌کند.

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

اگرچه این پروژه نسبتاً ساده به نظر می‌رسد، اما تقریباً تمام اجزای اصلی یک AI Agent واقعی را در خود جای داده است؛ دریافت ورودی، پردازش داده، ارتباط با مدل زبانی، مدیریت جریان کار و تولید خروجی نهایی.

به همین دلیل، پس از ساخت این Agent، توسعه آن به سیستم‌هایی پیچیده‌تر مانند دستیار BIM، تحلیل‌گر انرژی، کنترل‌کننده ضوابط یا حتی یک اکوسیستم چندعاملی، بسیار ساده‌تر خواهد بود.

 

 

قبل از باز کردن n8n، نقشه عامل هوشمند را طراحی کنید

اگر تاکنون آموزش‌های ساخت AI Agent در YouTube یا شبکه‌های اجتماعی را دنبال کرده باشید، احتمالاً با روندی مشابه روبه‌رو شده‌اید؛ مدرس نرم‌افزار n8n را باز می‌کند، چند Node را به یکدیگر متصل می‌کند، کلید API را وارد می‌کند و در پایان، یک Agent ساده ساخته می‌شود که به چند سؤال پاسخ می‌دهد.

اگرچه این شیوه برای آشنایی اولیه با محیط نرم‌افزار مناسب است، اما معمولاً یک ضعف اساسی دارد؛ کاربر یاد می‌گیرد چگونه Nodeها را به هم متصل کند، اما نمی‌آموزد چگونه یک سیستم طراحی کند.

همین موضوع باعث می‌شود بسیاری از افراد پس از پایان آموزش، نتوانند پروژه واقعی خود را پیاده‌سازی کنند. آن‌ها منوهای n8n را می‌شناسند، اما وقتی با مسئله‌ای جدید روبه‌رو می‌شوند، نمی‌دانند از کجا باید شروع کنند.

این همان تفاوت میان آموزش ابزار و آموزش طراحی سیستم است.

در معماری نیز وضعیت مشابهی وجود دارد. کسی که تمام فرمان‌های Revit را می‌شناسد، الزاماً معمار خوبی نیست. آنچه یک معمار را متمایز می‌کند، توانایی تحلیل مسئله، سازمان‌دهی فضاها و تبدیل نیازهای کارفرما به یک ساختار منطقی است. نرم‌افزار تنها وسیله اجرای این تفکر است.

در طراحی AI Agent نیز n8n تنها ابزار اجراست؛ طراحی واقعی پیش از باز شدن نرم‌افزار انجام می‌شود.

از مسئله تا جریان اطلاعات

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

در طراحی Agent نیز باید دقیقاً همین کار را انجام دهیم؛ با این تفاوت که به جای فضاها، با جریان اطلاعات سروکار داریم.

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

به همین دلیل، پیش از آنکه اولین Node را در n8n اضافه کنیم، باید مسیر حرکت اطلاعات را روی کاغذ ترسیم کنیم.

سه پرسش که ستون فقرات هر AI Agent را تشکیل می‌دهند

تقریباً هر عامل هوشمند، صرف‌نظر از پیچیدگی آن، بر پایه سه پرسش شکل می‌گیرد.

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

عامل هوشمند قرار است چه چیزی را دریافت کند؟ آیا یک فایل PDF است؟ آیا کاربر متنی را وارد می‌کند؟ آیا اطلاعات از یک پایگاه داده یا نرم‌افزار BIM خوانده می‌شود؟ شاید هم رویدادی مانند دریافت یک ایمیل، آغازگر فرآیند باشد.

ورودی، نقطه شروع تمام تصمیم‌های بعدی است.

پرسش دوم این است که عامل هوشمند قرار است چه پردازشی انجام دهد؟

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

هرچه این بخش دقیق‌تر تعریف شود، کیفیت Agent نیز بالاتر خواهد بود.

و در نهایت، پرسش سوم این است که خروجی مطلوب چیست؟

آیا نتیجه باید به صورت یک گزارش PDF تولید شود؟ در قالب یک فایل Word ذخیره شود؟ برای اعضای تیم ایمیل گردد؟ در Google Sheets ثبت شود؟ یا تنها به‌صورت یک پاسخ در صفحه چت نمایش داده شود؟

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

سناریوی آموزشی این مقاله

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

فرض کنید دفتر معماری شما پروژه طراحی یک مجموعه درمانی را دریافت کرده است. کارفرما چندین فایل شامل ضوابط طراحی، برنامه فیزیکی، دستورالعمل‌های وزارت بهداشت و اسناد اولیه پروژه ارسال کرده است.

هدف این است که عامل هوشمندی طراحی کنیم که بتواند این اسناد را مطالعه کند و به پرسش‌های تیم طراحی پاسخ دهد.

برای مثال، معمار می‌تواند از Agent بپرسد:

«حداقل عرض راهروهای بخش بستری چقدر است؟»

یا

«چه الزاماتی برای نور طبیعی اتاق‌های بستری در این اسناد ذکر شده است؟»

یا

«تمام محدودیت‌های مرتبط با خروج اضطراری را استخراج کن.»

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

اگر این سناریو را به زبان Workflow ترجمه کنیم، ساختار بسیار ساده‌ای خواهیم داشت:

ابتدا فایل دریافت می‌شود.

سپس متن آن استخراج می‌شود.

در ادامه، پرسش کاربر به همراه متن اسناد برای مدل زبانی ارسال می‌شود.

مدل پاسخ مناسب را تولید می‌کند.

و در نهایت، پاسخ در اختیار کاربر قرار می‌گیرد یا در قالب یک فایل ذخیره می‌شود.

نکته مهم این است که در این مرحله هنوز درباره n8n، OpenAI یا حتی مدل زبانی تصمیمی نگرفته‌ایم. ما تنها معماری سیستم را طراحی کرده‌ایم.

چرا این مرحله از خود n8n مهم‌تر است؟

بسیاری از کاربران تصور می‌کنند ارزش اصلی یک Workflow در تعداد Nodeهای آن است؛ در حالی که تجربه توسعه‌دهندگان حرفه‌ای خلاف این موضوع را نشان می‌دهد.

یک Workflow با ده Node که بر اساس تحلیل صحیح مسئله طراحی شده باشد، معمولاً بسیار ارزشمندتر از Workflow صد Nodeیی است که بدون منطق مشخص ایجاد شده است.

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

در طراحی Agent نیز کیفیت به معماری سیستم وابسته است، نه به پیچیدگی ظاهری آن.

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

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

ورود به مرحله اجرا

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

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

 

 

ساخت اولین Workflow در n8n؛ از معماری جریان اطلاعات تا اجرای اولین Agent

اکنون زمان آن رسیده است که برای نخستین بار وارد محیط n8n شویم. اما پیش از آنکه اولین Node را روی صفحه قرار دهیم، لازم است یک سوءبرداشت رایج را اصلاح کنیم.

بسیاری از کاربران تصور می‌کنند Workflow همان AI Agent است. به همین دلیل، هر زمان چند Node را به یکدیگر متصل می‌کنند، تصور می‌کنند یک عامل هوشمند ساخته‌اند.

در حالی که چنین نیست.

Workflow در حقیقت «معماری اجرای تصمیم‌ها» است، نه خود تصمیم‌گیری.

برای درک بهتر این موضوع، می‌توان دوباره از یک مثال معماری استفاده کرد.

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

اما این مسیرها خودشان تصمیم نمی‌گیرند.

آن‌ها تنها جریان حرکت را سازمان‌دهی می‌کنند.

در AI Agent نیز دقیقاً همین اتفاق رخ می‌دهد.

مدل زبانی تصمیم می‌گیرد.

ابزارها عملیات را انجام می‌دهند.

حافظه اطلاعات را نگهداری می‌کند.

اما این Workflow است که تعیین می‌کند:

ابتدا چه اتفاقی بیفتد.

اطلاعات به کجا ارسال شوند.

چه زمانی مدل زبانی فراخوانی شود.

در چه شرایطی یک ابزار اجرا شود.

خروجی به کدام مرحله منتقل شود.

به همین دلیل، می‌توان گفت اگر LLM مغز سیستم باشد، Workflow ستون فقرات آن است.

چرا n8n؟

در میان ابزارهای موجود برای ساخت Agent، گزینه‌های متعددی مانند LangGraph، CrewAI، AutoGen، Flowise و OpenAI Agents SDK وجود دارند. هر یک از این ابزارها برای هدف خاصی طراحی شده‌اند و در پروژه‌های حرفه‌ای جایگاه مهمی دارند.

با این حال، برای معمارانی که تجربه برنامه‌نویسی ندارند، n8n یکی از مناسب‌ترین نقاط شروع محسوب می‌شود.

دلیل این انتخاب تنها سادگی رابط کاربری نیست.

n8n چند ویژگی مهم دارد که آن را برای دفاتر معماری جذاب می‌کند.

نخست آنکه متن‌باز (Open Source) است و وابستگی کامل به یک شرکت خاص ندارد.

دوم اینکه هزاران اتصال آماده (Integration) برای نرم‌افزارها و سرویس‌های مختلف در اختیار کاربر قرار می‌دهد.

سوم اینکه تقریباً تمام قابلیت‌هایی که برای ساخت یک AI Agent نیاز داریم، از جمله ارتباط با مدل‌های زبانی، مدیریت فایل‌ها، پایگاه‌های داده، حافظه، APIها و حتی MCP، در آن قابل پیاده‌سازی است.

و شاید مهم‌تر از همه، n8n اجازه می‌دهد با رشد پروژه، Workflowهای ساده به اکوسیستم‌های چندعاملی تبدیل شوند؛ بدون آنکه لازم باشد تمام سیستم از ابتدا بازنویسی شود.

نصب n8n؛ کدام نسخه مناسب است؟

در حال حاضر سه روش اصلی برای استفاده از n8n وجود دارد.

نسخه Cloud که روی سرورهای n8n اجرا می‌شود و سریع‌ترین راه برای شروع است.

نسخه Desktop که روی رایانه شخصی نصب می‌شود و برای آموزش و آزمایش گزینه مناسبی است.

و نسخه Self-Hosted که روی سرور اختصاصی نصب می‌شود و معمولاً توسط شرکت‌ها و دفاتر حرفه‌ای مورد استفاده قرار می‌گیرد.

اگر هدف شما یادگیری و ساخت نخستین Agent است، نسخه Cloud یا Desktop هر دو انتخاب مناسبی هستند.

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

اولین Workflow؛ صفحه سفید، اما نه بدون نقشه

پس از ورود به n8n، با یک صفحه تقریباً خالی روبه‌رو می‌شوید.

این صفحه در نگاه اول ممکن است بسیار ساده به نظر برسد، اما در حقیقت همان بوم طراحی سیستم شماست.

هر Node که روی این صفحه قرار می‌دهید، مانند یک فضای عملکردی در پلان معماری است.

هر اتصال میان Nodeها، همانند مسیرهای ارتباطی میان فضاها عمل می‌کند.

و کل صفحه، چیزی شبیه پلان عملکردی عامل هوشمند شما خواهد بود.

در این مقاله، برخلاف بسیاری از آموزش‌ها، قرار نیست ده‌ها Node را بدون هدف کنار هم قرار دهیم.

ابتدا تنها چهار Node خواهیم ساخت؛ زیرا تقریباً تمام Agentهای بزرگ دنیا نیز در ساده‌ترین حالت، از همین چهار مرحله آغاز می‌شوند:

دریافت درخواست کاربر.

ارسال درخواست به مدل زبانی.

دریافت پاسخ.

نمایش نتیجه.

شاید این Workflow بسیار ساده به نظر برسد، اما همین ساختار پایه، هسته اولیه تقریباً تمام سیستم‌های Agentic است. در بخش‌های بعدی، حافظه، ابزارها، فایل‌های PDF، پایگاه‌های دانش و در نهایت Agentهای تخصصی را دقیقاً بر روی همین ستون فقرات اضافه خواهیم کرد.

 

ساخت اولین Workflow؛ چهار Node که هسته تمام AI Agentها را تشکیل می‌دهند

اکنون زمان آن رسیده است که نخستین Workflow خود را در n8n ایجاد کنیم. اگر تاکنون هیچ تجربه‌ای در کار با این نرم‌افزار نداشته‌اید، احتمالاً محیط آن در نگاه اول بسیار ساده به نظر می‌رسد؛ صفحه‌ای سفید که باید Nodeهای مختلف را روی آن قرار دهید و با خطوطی به یکدیگر متصل کنید.

اما همین صفحه سفید، همان جایی است که معماری یک عامل هوشمند شکل می‌گیرد.

بسیاری از کاربران تازه‌کار تصور می‌کنند هرچه تعداد Nodeها بیشتر باشد، Agent آن‌ها هوشمندتر خواهد بود. این تصور نادرست است. تجربه نشان می‌دهد بسیاری از Workflowهای حرفه‌ای که روزانه هزاران درخواست را پردازش می‌کنند، از ساختاری بسیار ساده و شفاف بهره می‌برند. تفاوت آن‌ها با پروژه‌های آماتور، در تعداد Nodeها نیست؛ بلکه در نحوه سازمان‌دهی اطلاعات است.

در این آموزش نیز دقیقاً از همین رویکرد استفاده می‌کنیم. به‌جای ساخت یک Workflow پیچیده، ابتدا هسته اصلی سیستم را ایجاد می‌کنیم؛ ساختاری که بعداً حافظه، ابزارها، فایل‌های PDF، پایگاه دانش و حتی چندین Agent تخصصی روی آن سوار خواهند شد.

معماری اولین Agent

عامل هوشمندی که در این مرحله می‌سازیم تنها چهار گام دارد:

کاربر درخواست خود را وارد می‌کند.

درخواست برای مدل زبانی ارسال می‌شود.

مدل زبانی پاسخ را تولید می‌کند.

پاسخ به کاربر نمایش داده می‌شود.

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

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

گام اول؛ ایجاد یک Workflow جدید

پس از ورود به n8n، روی گزینه Create Workflow کلیک کنید.

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

در نگاه اول ممکن است صدها Node مختلف مشاهده کنید؛ از Google Drive و Gmail گرفته تا پایگاه‌های داده، سرویس‌های ابری و مدل‌های هوش مصنوعی.

در این مرحله، همه آن‌ها را نادیده بگیرید.

یکی از اشتباهات رایج کاربران، استفاده هم‌زمان از تعداد زیادی Node است. هرچه Workflow ساده‌تر باشد، اشکال‌زدایی و توسعه آن نیز آسان‌تر خواهد بود.

گام دوم؛ انتخاب Trigger

هر Workflow باید از یک نقطه آغاز شود. در n8n این نقطه آغاز، Trigger نام دارد.

Trigger مشخص می‌کند چه اتفاقی باعث فعال شدن Workflow شود.

در پروژه‌های مختلف، Trigger می‌تواند متفاوت باشد. برای مثال:

• دریافت یک ایمیل جدید
• بارگذاری یک فایل
• ثبت یک فرم
• رسیدن زمان مشخص
• دریافت درخواست از طریق API
• یا فشردن یک دکمه توسط کاربر

در این آموزش، ساده‌ترین گزینه را انتخاب می‌کنیم؛ Manual Trigger.

این Node به ما اجازه می‌دهد هر زمان که بخواهیم، Workflow را به‌صورت دستی اجرا کنیم. استفاده از Manual Trigger باعث می‌شود در مراحل آموزش، بدون درگیر شدن با تنظیمات پیچیده، روی منطق سیستم تمرکز کنیم.

پس از افزودن این Node، هنوز هیچ عملیات هوشمندی انجام نمی‌شود. تنها مشخص کرده‌ایم که سیستم از کجا آغاز شود.

گام سوم؛ افزودن Node هوش مصنوعی

اکنون باید مغز سیستم را اضافه کنیم.

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

در این آموزش از OpenAI Chat Model استفاده خواهیم کرد، زیرا در حال حاضر یکی از پایدارترین و کامل‌ترین گزینه‌ها برای ساخت Agentهای متنی محسوب می‌شود.

پس از اضافه کردن Node، باید کلید API خود را وارد کنید. این کلید، مجوز ارتباط n8n با سرویس OpenAI است.

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

فعلاً هدف ما تنها آشنایی با ساختار Workflow است.

گام چهارم؛ اتصال Nodeها

اکنون کافی است خروجی Manual Trigger را به ورودی Node مربوط به OpenAI متصل کنید.

این اتصال، همان چیزی است که در معماری Workflow اهمیت دارد.

در ظاهر تنها یک خط میان دو Node رسم شده است، اما در واقع این خط مسیر حرکت اطلاعات را مشخص می‌کند.

از این لحظه، هر زمان Trigger فعال شود، اطلاعات مستقیماً به مدل زبانی ارسال خواهند شد.

اگر این اتصال وجود نداشته باشد، حتی بهترین مدل هوش مصنوعی نیز هیچ داده‌ای دریافت نخواهد کرد.

در طراحی سیستم‌های Agentic، کیفیت همین ارتباط‌های به‌ظاهر ساده، نقش تعیین‌کننده‌ای در عملکرد کل سیستم دارد.

گام پنجم؛ تولید اولین پاسخ

در تنظیمات Node مربوط به OpenAI، یک پیام آزمایشی وارد کنید.

برای مثال بنویسید:

«خودت را به‌عنوان یک دستیار معماری معرفی کن و وظیفه خود را در دو جمله توضیح بده.»

سپس روی Execute Workflow کلیک کنید.

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

شاید این پاسخ از نظر عملکرد بسیار ساده باشد، اما در حقیقت اتفاق مهمی رخ داده است.

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

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

 

اولین Workflow واقعی در n8n برای معماران

ساخت اولین AI Agent بدون برنامه‌نویسی

تا اینجا، معماری درونی Agent، نقش LLM، حافظه، ابزارها، MCP و Workflow را شناختیم و محیط n8n را نیز آماده کردیم. اکنون زمان آن رسیده است که نخستین Agent واقعی خود را بسازیم.

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

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

مسئله‌ای که قرار است حل کنیم

فرض کنید در دفتر معماری خود بارها با چنین وضعیتی روبه‌رو شده‌اید.

کارفرما می‌پرسد:

«برای طراحی یک درمانگاه ۳۰۰۰ متری چه فضاهایی لازم است؟»

یا

«ضوابط طراحی پارکینگ را برای این پروژه پیدا کن.»

یا

«برای طراحی یک مدرسه ابتدایی چه استانداردهایی وجود دارد؟»

در حالت معمول، معمار باید میان فایل‌های مختلف، آیین‌نامه‌ها، پروژه‌های قبلی و موتورهای جستجو جابه‌جا شود.

اما اگر یک Agent اختصاصی داشته باشید، تنها کافی است سؤال را مطرح کنید.

Agent خودش:

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

همین Agent ساده، پایه تمام سیستم‌های پیشرفته آینده خواهد بود.

قبل از ساخت Workflow، سناریوی سیستم را طراحی کنید

یکی از رایج‌ترین اشتباهات کاربران n8n این است که بلافاصله شروع به اضافه کردن Nodeها می‌کنند.

این دقیقاً همان اشتباهی است که یک معمار اگر بدون برنامه فیزیکی شروع به ترسیم پلان کند، مرتکب می‌شود.

قبل از باز کردن n8n باید روی کاغذ بنویسید:

کاربر چه چیزی می‌گوید؟

↓

سیستم چه اطلاعاتی لازم دارد؟

↓

اطلاعات از کجا باید تهیه شوند؟

↓

کدام Agent تصمیم می‌گیرد؟

↓

نتیجه چگونه نمایش داده شود؟

اگر این نمودار را نتوانید روی کاغذ ترسیم کنید، در n8n نیز موفق نخواهید شد.

Workflow را مانند پلان معماری ببینید

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

در پلان معماری:

ورودی

↓

لابی

↓

راهرو

↓

اتاق‌ها

↓

خروجی

وجود دارد.

در Workflow نیز دقیقاً همین ساختار دیده می‌شود.

درخواست کاربر

↓

تحلیل درخواست

↓

جستجوی اطلاعات

↓

استدلال

↓

تولید پاسخ

↓

نمایش خروجی

هر Node دقیقاً مانند یک فضاست.

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

معماری اولین Agent

اولین Agent ما تنها از چند بخش تشکیل می‌شود.

ورودی (Input)

↓

مدل زبانی

↓

ابزار جستجو

↓

مدل زبانی

↓

خروجی

همین.

اما پشت این ساختار ساده، تقریباً تمام مفاهیم Agentic AI قرار دارد.

مرحله اول؛ Trigger

در n8n هر Workflow با یک Trigger آغاز می‌شود.

Trigger یعنی:

چه چیزی سیستم را بیدار می‌کند؟

مثلاً

رسیدن پیام تلگرام

رسیدن ایمیل

کلیک کاربر

اجرای زمان‌بندی

Webhook

فرم سایت

در این آموزش، ساده‌ترین حالت را انتخاب می‌کنیم.

Chat Trigger

یا

Webhook

هر دو مناسب هستند.

Webhook بیشتر در پروژه‌های واقعی استفاده می‌شود.

Chat Trigger برای یادگیری مناسب‌تر است.

مرحله دوم؛ دریافت درخواست کاربر

کاربر می‌نویسد:

«ضوابط طراحی کتابخانه را پیدا کن.»

این متن وارد Workflow می‌شود.

در این لحظه هنوز هیچ هوش مصنوعی اتفاق نیفتاده است.

سیستم فقط متن را دریافت کرده است.

مرحله سوم؛ اولین LLM

اکنون اولین Node مربوط به OpenAI اضافه می‌شود.

اما یک نکته مهم وجود دارد.

نباید از مدل بخواهید مستقیماً پاسخ تولید کند.

بلکه ابتدا باید نقش او را مشخص کنید.

مثلاً:

«تو یک معمار پژوهشگر هستی.

ابتدا تشخیص بده سؤال کاربر درباره چیست.

موضوع را استخراج کن.

نوع ساختمان را مشخص کن.

مشخص کن آیا برای پاسخ نیاز به جستجو وجود دارد یا خیر.»

این همان چیزی است که در Agentها Reasoning اولیه نامیده می‌شود.

چرا این کار مهم است؟

فرض کنید کاربر بنویسد:

«برای طراحی یک مدرسه چه استانداردهایی لازم است؟»

مدل باید ابتدا بفهمد:

نوع ساختمان = آموزشی

نیاز = استاندارد طراحی

نیاز به جستجو = بله

بدون این مرحله، Agent تقریباً کور عمل می‌کند.

خروجی این مرحله

به جای متن طولانی، بهتر است خروجی ساختاریافته باشد.

مثلاً

موضوع:

School

نوع درخواست:

Design Standards

نیاز به جستجو:

True

کلیدواژه:

School Design Standards

هرچه خروجی ساختاریافته‌تر باشد، ادامه Workflow ساده‌تر خواهد بود.

مرحله چهارم؛ تصمیم‌گیری

حالا سیستم باید تصمیم بگیرد.

آیا لازم است جستجو انجام شود؟

یا خیر؟

در n8n این کار با Nodeهای شرطی انجام می‌شود.

IF

Switch

Condition

مثلاً

اگر نیاز به جستجو = True

↓

برو به مرحله جستجو

اگر False

↓

مستقیماً پاسخ بده

همین مرحله، Agent را از یک ChatBot ساده جدا می‌کند.

مرحله پنجم؛ Tool

اکنون اولین Tool وارد سیستم می‌شود.

در این آموزش، Tool می‌تواند هر چیزی باشد.

Google Drive

Notion

PDF

Excel

پایگاه دانش

وب

یا حتی پوشه پروژه‌های شما.

فرض کنید تمام آیین‌نامه‌های معماری را در یک پوشه ذخیره کرده‌اید.

Agent اکنون به آن پوشه مراجعه می‌کند.

اسناد مرتبط را پیدا می‌کند.

متن را استخراج می‌کند.

دوباره به LLM بازمی‌گرداند.

تفاوت بسیار مهم

ChatGPT معمولی می‌گوید:

«من فکر می‌کنم…»

اما Agent می‌گوید:

«اجازه بده بررسی کنم…»

همین تفاوت، آینده هوش مصنوعی را ساخته است.

مرحله ششم؛ بازیابی اطلاعات (Retrieval)

در این مرحله Agent اطلاعات واقعی را جمع‌آوری می‌کند.

مثلاً:

فایل شماره ۱۲

↓

فصل نور طبیعی

↓

بند ۵

↓

ضوابط کلاس درس

↓

جدول ابعاد

همه این اطلاعات استخراج می‌شوند.

اما هنوز پاسخ نهایی تولید نشده است.

چرا Retrieval اهمیت دارد؟

یکی از بزرگ‌ترین ضعف‌های مدل‌های زبانی، توهم (Hallucination) است.

گاهی مدل اطلاعاتی را تولید می‌کند که وجود خارجی ندارد.

اما وقتی پاسخ بر اساس اسناد واقعی ساخته شود، احتمال خطا به شدت کاهش پیدا می‌کند.

به همین دلیل تقریباً تمام Agentهای حرفه‌ای امروز از Retrieval استفاده می‌کنند.

مرحله هفتم؛ دومین LLM

اکنون اطلاعات واقعی وارد مدل می‌شوند.

این بار Prompt متفاوت است.

به جای اینکه از مدل بخواهیم اطلاعات تولید کند، می‌گوییم:

«بر اساس اسناد زیر پاسخ بده.

اگر اطلاعات کافی نبود اعلام کن.

چیزی از خودت اضافه نکن.»

این یکی از مهم‌ترین تفاوت‌های Agentهای حرفه‌ای با ChatBotهای عمومی است.

مرحله هشتم؛ تولید پاسخ

اکنون پاسخ آماده می‌شود.

اما بهتر است خروجی ساختار مشخصی داشته باشد.

مثلاً

خلاصه

↓

استانداردها

↓

منابع

↓

پیشنهاد طراحی

↓

نکات مهم

به این ترتیب پاسخ همیشه کیفیت ثابتی خواهد داشت.

مرحله نهم؛ ثبت در حافظه

اکثر آموزش‌های n8n در همین مرحله تمام می‌شوند.

اما یک Agent واقعی تازه از اینجا شروع می‌شود.

سیستم باید بداند:

چه سؤالی پرسیده شد؟

چه پاسخی تولید شد؟

چه منابعی استفاده شدند؟

کدام پروژه بود؟

کاربر چه کسی بود؟

این اطلاعات باید ذخیره شوند.

ممکن است در:

Notion

Supabase

PostgreSQL

Pinecone

یا هر پایگاه داده دیگری نگهداری شوند.

همین حافظه است که باعث می‌شود Agent هر روز باهوش‌تر شود.

مرحله دهم؛ ارسال خروجی

در نهایت پاسخ برای کاربر ارسال می‌شود.

از طریق:

تلگرام

واتساپ

ایمیل

وب‌سایت

Slack

یا رابط اختصاصی شرکت.

کاربر فقط نتیجه را می‌بیند.

اما در پشت صحنه، ده‌ها تصمیم گرفته شده است.

معماری واقعی همین است

اگر به این Workflow نگاه کنید، متوجه خواهید شد که تقریباً تمام مفاهیمی که در مقاله قبل آموختیم، اکنون در قالب یک سیستم واقعی کنار هم قرار گرفته‌اند:

• Trigger، نقطه آغاز تعامل است.
• مدل زبانی نخست، درخواست را تحلیل و هدف را مشخص می‌کند.
• منطق شرطی (IF/Switch)، درباره مسیر اجرای Workflow تصمیم می‌گیرد.
• ابزارها (Tools)، اطلاعات واقعی را از محیط بازیابی می‌کنند.
• مدل زبانی دوم، بر پایه داده‌های معتبر پاسخ را تولید می‌کند.
• حافظه (Memory)، تجربه این تعامل را برای استفاده در آینده ذخیره می‌کند.
• و در نهایت، خروجی از طریق یکی از کانال‌های ارتباطی به کاربر ارائه می‌شود.

این همان چرخه‌ای است که در مقیاس‌های بزرگ‌تر، به سامانه‌های چندعاملی و دستیارهای هوشمند حرفه‌ای تبدیل می‌شود. نکته مهم آن است که تفاوت میان یک Agent ساده و یک Agent سازمانی، بیش از آنکه در تعداد Nodeها باشد، در کیفیت طراحی این جریان کار و هماهنگی میان اجزای آن است.

 

 

 

 

 

 از یک Agent ساده تا دستیار هوشمند معماری

چگونه اولین AI Agent اختصاصی دفتر معماری خود را بسازیم؟

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

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

اگر Agent تنها به مدل زبانی متکی باشد، این دانش را در اختیار ندارد. بنابراین نخستین گام برای ساخت یک دستیار حرفه‌ای، اتصال Agent به «دانش دفتر معماری» است.

یک Agent عمومی یا یک Agent اختصاصی؟

فرض کنید از ChatGPT بپرسید:

«برای طراحی بیمارستان چه استانداردهایی وجود دارد؟»

پاسخی نسبتاً مناسب دریافت خواهید کرد؛ اما اگر سؤال را کمی تخصصی‌تر کنید:

«در پروژه بیمارستان الف که سال گذشته طراحی کردیم، چرا بخش تصویربرداری از اورژانس جدا شد؟»

مدل زبانی پاسخی نخواهد داشت؛ زیرا هرگز به اسناد آن پروژه دسترسی نداشته است.

اکنون همین سؤال را از Agent اختصاصی دفتر معماری بپرسید.

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

همین تفاوت، مرز میان یک ابزار عمومی و یک دستیار سازمانی است.

دانش سازمانی؛ ارزشمندترین دارایی دفاتر معماری

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

هر پروژه تجربه‌ای جدید تولید می‌کند:

• جزئیات اجرایی که موفق بوده‌اند.
• اشتباهاتی که نباید تکرار شوند.
• راه‌حل‌هایی که در شرایط خاص نتیجه داده‌اند.
• ترجیحات کارفرمایان.
• تفسیرهای خاص از ضوابط.
• روش‌های هماهنگی میان رشته‌ها.
• الگوهای طراحی که بارها آزموده شده‌اند.

متأسفانه بخش زیادی از این دانش پس از پایان پروژه از بین می‌رود یا تنها در ذهن افراد باقی می‌ماند.

یکی از مهم‌ترین کاربردهای AI Agent، تبدیل این دانش پراکنده به یک حافظه قابل جستجو و قابل استفاده است.

Agent باید چه چیزهایی را بشناسد؟

برای یک دفتر معماری، منابع اطلاعاتی می‌توانند بسیار متنوع باشند.

برای مثال:

• فایل‌های PDF آیین‌نامه‌ها
• مقررات ملی ساختمان
• نشریات سازمان برنامه
• استانداردهای وزارت بهداشت
• پروژه‌های قدیمی
• فایل‌های Word
• فایل‌های Excel
• مدل‌های BIM
• فایل‌های IFC
• مکاتبات پروژه
• صورت‌جلسات
• گزارش‌های نظارت
• برنامه فیزیکی پروژه‌ها
• بانک جزئیات اجرایی
• چک‌لیست‌های داخلی شرکت

هر یک از این منابع می‌تواند به بخشی از حافظه Agent تبدیل شود.

آیا لازم است همه چیز را وارد کنیم؟

خیر.

یکی از اشتباهات رایج، تلاش برای وارد کردن هزاران فایل به سیستم از همان روز اول است.

بهتر است توسعه Agent تدریجی باشد.

برای مثال:

هفته اول:

فقط مقررات ملی ساختمان

هفته دوم:

پروژه‌های بیمارستانی

هفته سوم:

چک‌لیست‌های طراحی

هفته چهارم:

آرشیو جلسات

هفته پنجم:

جزئیات اجرایی

این روش باعث می‌شود کیفیت سیستم همواره قابل کنترل باقی بماند.

معماری پایگاه دانش

پیش از وارد کردن اسناد، باید درباره ساختار آن‌ها فکر کنید.

این مرحله شباهت زیادی به طراحی کتابخانه یک ساختمان دارد.

اگر هزاران کتاب بدون طبقه‌بندی روی زمین قرار گیرند، ارزش چندانی نخواهند داشت.

اما اگر همان کتاب‌ها بر اساس موضوع، نویسنده، تاریخ و دسته‌بندی سازمان‌دهی شوند، بازیابی اطلاعات بسیار ساده خواهد شد.

پایگاه دانش Agent نیز دقیقاً به همین منطق نیاز دارد.

هر سند باید دارای ویژگی‌هایی مانند:

• موضوع
• نوع پروژه
• سال
• کارفرما
• مرحله طراحی
• رشته تخصصی
• وضعیت اعتبار

باشد.

این اطلاعات که به آن‌ها Metadata گفته می‌شود، کیفیت جستجوی Agent را به شکل چشمگیری افزایش می‌دهند.

چرا ساختار داده از خود داده مهم‌تر است؟

فرض کنید دو دفتر معماری، هر دو هزار پروژه آرشیو کرده‌اند.

دفتر اول:

تمام فایل‌ها را فقط در پوشه‌ها ذخیره کرده است.

دفتر دوم:

همان فایل‌ها را با برچسب‌گذاری، دسته‌بندی، نسخه‌بندی و توضیحات مناسب سازمان‌دهی کرده است.

Agent دفتر دوم پاسخ‌های بسیار دقیق‌تری ارائه خواهد کرد؛ زیرا می‌تواند روابط میان اطلاعات را درک کند.

در دنیای Agentها، کیفیت داده تقریباً همیشه از حجم داده مهم‌تر است.

اولین پایگاه دانش خود را بسازید

اگر امروز بخواهید شروع کنید، پیشنهاد می‌شود تنها یک موضوع را انتخاب کنید.

برای مثال:

«طراحی مدرسه»

تمام فایل‌های مرتبط را جمع‌آوری کنید.

آیین‌نامه‌ها

پروژه‌ها

مقالات

ضوابط

نمونه‌های موفق

جزئیات اجرایی

همه را در یک ساختار منظم قرار دهید.

سپس Agent را فقط به همین مجموعه متصل کنید.

نتیجه بسیار بهتر از آن خواهد بود که هزاران فایل نامرتبط وارد سیستم شوند.

معماری Prompt؛ دانشی که رفتار Agent را شکل می‌دهد

بسیاری از افراد تصور می‌کنند هوشمندی Agent تنها به مدل زبانی وابسته است، در حالی که یکی از مهم‌ترین عوامل، نحوه طراحی Promptها است.

Prompt تنها یک سؤال نیست؛ بلکه مجموعه‌ای از قوانین رفتاری است.

برای یک Agent معماری، Prompt می‌تواند شامل مواردی مانند این باشد:

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

در عمل، Prompt همان نقشی را دارد که آیین‌نامه داخلی یک دفتر معماری برای اعضای تیم ایفا می‌کند.

Agent باید شخصیت حرفه‌ای داشته باشد

یکی از مزیت‌های Agent اختصاصی این است که می‌توانید رفتار آن را مطابق فرهنگ سازمان خود طراحی کنید.

برای مثال:

یک دفتر معماری پژوهش‌محور ممکن است بخواهد Agent همیشه ابتدا منابع علمی را بررسی کند.

یک شرکت مشاور ممکن است ترجیح دهد پاسخ‌ها رسمی و مستند باشند.

یک دفتر طراحی مفهومی ممکن است از Agent بخواهد ابتدا چند سناریوی خلاقانه ارائه کند و سپس محدودیت‌ها را بررسی نماید.

به این ترتیب، Agent تنها یک ابزار فنی نیست؛ بلکه بخشی از هویت حرفه‌ای سازمان خواهد شد.

اولین کاربرد واقعی در دفتر معماری

اکنون تصور کنید تمام این اجزا کنار هم قرار گرفته‌اند.

یکی از اعضای تیم می‌نویسد:

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

در پشت صحنه، Agent مراحل زیر را انجام می‌دهد:

• درخواست را تحلیل می‌کند.
• موضوعات اصلی را استخراج می‌کند.
• در پایگاه دانش دفتر جستجو می‌کند.
• مقررات ملی، استانداردهای درمانی و اسناد داخلی شرکت را بازیابی می‌کند.
• تعارض‌های احتمالی را مشخص می‌کند.
• پاسخ را با ذکر منبع تنظیم می‌کند.
• گزارش را در قالب Word یا PDF تولید می‌کند.
• نسخه‌ای از این تعامل را برای استفاده در پروژه‌های بعدی در حافظه ذخیره می‌کند.

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

از دستیار پرسش‌وپاسخ تا همکار دیجیتال

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

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

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

 

 

 

جمع‌بندی

در این مقاله، با مفاهیم پایه ساخت AI Agent آشنا شدیم و دیدیم که چگونه می‌توان بدون برنامه‌نویسی، نخستین Workflow هوشمند را در n8n طراحی کرد. همچنین یاد گرفتیم که یک Agent تنها یک مدل زبانی نیست، بلکه از اجزایی مانند Workflow، ابزارها، حافظه و پایگاه دانش تشکیل می‌شود.

در مقاله بعدی، وارد مرحله عملی‌تر خواهیم شد و به‌صورت گام‌به‌گام یک دستیار هوشمند معماری می‌سازیم؛ از اتصال n8n به OpenAI و طراحی Workflowهای حرفه‌ای گرفته تا ارتباط Agent با فایل‌های PDF، پایگاه دانش، Revit و سایر ابزارهای تخصصی معماری.