تصور کنید کارمندی استخدام کرده‌اید که هر روز صبح با حافظه‌ای کاملاً پاک بیدار می‌شود و باید تمام دستورالعمل‌های کاری را از ابتدا بخواند. اگر امروز از عامل هوش مصنوعی خود در Make.com استفاده می‌کنید، احتمالاً با همین وضعیت دست‌وپنجه نرم می‌کنید؛ عاملی که می‌تواند به‌طور قابل‌اعتمادی لیدهای جدید را شناسایی کند، به آن‌ها امتیاز دهد، پیش‌نویس پاسخ‌ها را بنویسد و نتایج را در یک اجرای روزانه ثبت کند، اما هر صبح کور و بی‌خبر بیدار می‌شود. فرآیند تا زمانی که همه چیز طبق برنامه پیش می‌رود تمیز به نظر می‌رسد، اما به محض اینکه فردا از عامل بپرسید که امروز چه کرده است، متوجه مشکل می‌شوید. چون او هیچ حافظه‌ای ندارد، به‌سادگی همان لیدها را دوباره می‌خواند، همان پاسخ‌ها را دوباره می‌نویسد و همان تصمیمات قبلی را از صفر می‌گیرد.
این وضعیت به‌دلیل ماهیت «بدون وضعیت» (Stateless) معماری فعلی Make است. این یک انتخاب طراحی بنیادین در ساختار فعلی این پلتفرم است. بسیاری از سازندگان به اشتباه شناسه‌های گفتگو یا فایل‌های دانش را به عنوان حافظه واقعی می‌شناسند، اما این‌ها یا رشته‌های موقتی هستند یا مواد مرجع ایستا. تا تاریخ ۲۷ سپتامبر ۲۰۲۶، شکاف بین یک «عامل اجراکننده تسک» و یک «عامل یادگیرنده شغل»، همچنان یک ساخت دستی برای اپراتور باقی مانده است. در واقع، عامل شما یاد نمی‌گیرد، بلکه فقط تکرار می‌کند.
توهم حافظه در Make
پلتفرم Make دو قابلیت ارائه می‌دهد که حافظه را تقلید می‌کنند اما در مقیاس واقعی شکست می‌خورند. بسیار مهم است که درک کنیم حافظه در Make در واقع چیست و چه چیزی نیست:
- شناسه‌های گفتگو (Conversation IDs): یک فیلد Conversation ID در ماژول وجود دارد. اگر این فیلد خالی بماند، هر اجرا یک هویت جدید برای عامل ایجاد می‌کند که هیچ خاطره‌ای از تعاملات قبلی ندارد. اگر روی یک مقدار ثابت تنظیم شود، اجراها در همان رشته (Thread) به گفتگو ادامه می‌دهند. اگرچه این حس حافظه را منتقل می‌کند، اما این رشته به‌مرور طولانی، قدیمی و گران می‌شود، زیرا هر صبح مدل باید کل آن را دوباره بخواند. علاوه بر این، این حافظه محبوس است؛ یعنی سناریوی دومی که از همان عامل استفاده می‌کند، نمی‌تواند آن را ببیند. برای مدیریت بهینه این حجم از داده، استفاده از بودجه‌بندی سه‌لایهٔ زمینه می‌تواند مانع از غرق شدن عامل در داده‌های حجیم شود.
- فایل‌های دانش (Knowledge Files): شما می‌توانید پرسش‌های متداول (FAQs)، دستورالعمل‌های برند و سیاست‌های شرکت را آپلود کنید. این‌ها در یک ذخیره‌ساز برداری RAG قرار می‌گیرند و عامل در زمان اجرا، بخش‌های مرتبط را استخراج می‌کند. این یک ماده مرجع مفید است، اما حافظه نیست. دستورالعمل‌های برند شما یادشان نمی‌آید که در اجرای شماره ۴۷ چه اتفاقی افتاده است و هیچ‌چیز در جریان آپلود دانش، از تجربه درس نمی‌گیرد.
این وضعیت اپراتورها را با یک انتخاب سخت مواجه می‌کند: یا رشته‌های گفتگویی که تا ابد انباشته می‌شوند و به‌مرور «احمق‌تر» می‌شوند، یا یک پایگاه دانش که در زمان منجمد شده است. هیچ‌کدام نمی‌توانند به این سوال پاسخ دهند: «دیروز چه کردی و امروز چه چیزی را باید متفاوت انجام دهی؟»
راهکار «تحویل شیفت»
برای حل این مشکل، اپراتورها به‌طور سنتی از Data Storeهای داخلی Make برای ذخیره و بازیابی دستی وضعیت (State) استفاده می‌کردند. در این روش، پیش از اجرای عامل، شما باید آخرین ID لید پردازش شده، رشته‌های باز و تصمیمات گرفته شده را جستجو می‌کردید و پس از اجرا، وضعیت جدید را دوباره می‌نوشتید. این کار عملاً سازنده اتوماسیون را به یک مدیر پایگاه‌داده پاره‌وقت تبدیل می‌کرد که باید طرح‌های داده (Schemas) را طراحی کند، تصمیم بگیرد چه چیزی سریال‌سازی شود و زمانی که اجراها در نیمه راه شکست می‌خورند، وضعیت‌های نیمه‌کاره را عیب‌یابی کند.
یک رویکرد منعطف‌تر و مقاوم‌تر، الگوی «تحویل شیفت» (Shift-Handoff) است. هر اجرای عامل را مانند یک شیفت کاری تصور کنید. در پایان هر شیفت، کارگر یک یادداشت کوتاه تحویل می‌نویسد: «چه کارهایی انجام دادم، چه تصمیماتی گرفتم، چه مواردی هنوز باز است و کجاها اشتباه شد». این مفهوم شباهت زیادی به لایه حافظه Funes دارد که با بهینه‌سازی انتقال وضعیت، هزینه‌های جابه‌جایی بین عامل‌ها را به‌شدت کاهش داده است.
جزئیات الگوی تحویل شیفت
وقتی این الگو در یک سناریوی Make پیاده‌سازی می‌شود، مکانیزم آن به شرح زیر است:
- شروع اجرا: عامل آخرین دسته از یادداشت‌های تحویل را بارگذاری می‌کند. او کل تاریخچه را نمی‌خواند، بلکه فقط مقدار کافی برای دانستن موارد مهم در لحظه حال را دریافت می‌کند.
- حین اجرا: عامل با استفاده از ابزارهای در دسترس خود، کارهای عادی‌اش را انجام می‌دهد.
- پایان اجرا: عامل یک یادداشت کوتاه در یک یا دو پاراگراف می‌نویسد. او ثبت می‌کند که چه اتفاقی افتاده و اجرای بعدی باید چه چیزی را بداند.
- ردیابی خطا: تلاش‌های شکست‌خورده در اینجا ثبت می‌شوند. این یادداشت‌های خاص اغلب بیشترین صرفه‌جویی مالی را ایجاد می‌کنند، زیرا مانع از آن می‌شوند که عامل اشتباهات هزینه‌بر قبلی را تکرار کند.
عامل این یادداشت‌ها را خودش، با کلمات خودش و در زمان اجرا می‌نویسد. در طول هفته‌ها، این پشته به یک تاریخچه عملیاتی فشرده از اتوماسیون تبدیل می‌شود که لیدهای بررسی شده و موارد خاص (Edge Cases) برای اجتناب را مستند می‌کند.
پیاده‌سازی حافظه از طریق MCP
نقطه عطف فنی برای این الگو، پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) است. اکنون عامل‌های هوش مصنوعی Make می‌توانند به سرورهای MCP به‌عنوان ابزارهای مستقیم متصل شوند. مستندات رسمی، ابزارهای MCP را به‌عنوان یک نوع ابزار پشتیبانی شده معرفی می‌کنند که از طریق احراز هویت متصل می‌شوند. این بدان معناست که حافظه به جای اینکه زیرساختی باشد که کاربر در داخل سناریو نگهداری کند، به سرویسی تبدیل می‌شود که عامل آن را فراخوانی می‌کند.
با استفاده از یک لایه حافظه میزبانی شده مانند Vilix AI، این تنظیمات به یک تسک ۱۰ دقیقه‌ای کاهش می‌یابد:
۱. اتصال سرور حافظه MCP به‌عنوان یک ابزار در ماژول عامل هوش مصنوعی.
۲. افزودن یک دستور در پرامپت برای بارگذاری حافظه اخیر در شروع اجرا.
۳. افزودن یک دستور در پرامپت برای ذخیره خلاصه اجرا در پایان.
این روش نیاز به منطق‌های پیچیده جستجو (Lookup) و لوله‌کشی‌های Data Store را از بین می‌برد. چون از MCP استفاده می‌کند، همان حافظه می‌تواند یک عامل را در پلتفرم‌های مختلف دنبال کند. یک گردش‌کار در n8n که لیدها را پردازش می‌کند، یک تسک زمان‌بندی شده برای پیش‌نویس گزارش هفتگی، یا یک کلاینت چت برای عیب‌یابی، همگی می‌توانند از یک حافظه مشترک بخوانند و بنویسند. Vilix AI تاریخچه کامل گفتگوها را ذخیره می‌کند، نه فقط حقایق استخراج شده، و این به یادداشت تحویل اجازه می‌دهد تا به گفتگوهای اصلی ارجاع دهد.
اثرات عملیاتی
وقتی یک عامل می‌تواند یادداشت‌های تحویل خودش را بخواند، دیگر به لیدهای تکراری پیام نمی‌دهد و از تکرار رویکردهای شکست‌خورده روزهای قبل پرهیز می‌کند. او لزوماً از نظر هوش خام «باهوش‌تر» نمی‌شود؛ بلکه صرفاً جایگاه خود را در جریان کاری گم نمی‌کند. او دیگر سوالاتی را که قبلاً پاسخ داده است نمی‌پرسد و روش‌هایی را که سه‌شنبه گذشته امتحان کرده و شکست خورده بود، تکرار نمی‌کند.
برای کاربر، این به معنای تغییر از مدیریت یک توالی شکننده از ماژول‌ها به مدیریت یک «کارمند دیجیتال» پایدار است. عامل خودش سریال‌سازی تجربیاتش را مدیریت می‌کند و یک تاریخچه عملیاتی فشرده از کل اتوماسیون می‌سازد. این انتقال، نقطه اصطکاک اصلی برای عامل‌های در سطح تولید (Production-grade) را حل می‌کند: یعنی هزینه تکرار.
سرویس Vilix AI این قابلیت را به‌عنوان یک لایه ابری ارائه می‌دهد که نیازی به اجرای پایگاه‌داده یا تنظیم بردارها ندارد. طرح رایگان آن، استفاده‌های واقعی را بدون محدودیت زمانی پوشش می‌دهد و یک دوره آزمایشی ۷ روزه Pro بدون نیاز به کارت اعتباری در دسترس است. داده‌ها قابل انتقال باقی می‌مانند و کاربران می‌توانند در هر زمان همه چیز را در یک فرمت قابل حمل صادر یا حذف کنند.
با برون‌سپاری مدیریت وضعیت به یک سرور MCP، سناریوی شما خلوت می‌ماند در حالی که کاربرد عامل در طول زمان رشد می‌کند. حافظه، تفاوت بین عاملی است که فقط یک تسک را اجرا می‌کند و عاملی است که یک شغل را یاد می‌گیرد.
گام بعدی شما
- اگر از Make.com استفاده می‌کنید، بررسی کنید آیا عامل شما در هر اجرا داده‌های تکراری را پردازش می‌کند یا خیر.
- پروتکل MCP را در مستندات Make جست‌وجو کنید تا متوجه شوید چگونه ابزارهای خارجی را به حافظه متصل کنید.
- برای تست، یک لایه حافظه ابری (مانند Vilix) را به سناریوی خود اضافه کنید و دستور «نوشتن یادداشت پایان شیفت» را به پرامپت سیستمی اضافه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو