حافظه در ایجنت‌های عملیاتی؛ ایجنت چه چیزی را باید به یاد بیاورد

در موج اول Vibe Coding، بحث سر این بود که چطور بدون نوشتن دستی کد، محصول بسازیم. موج دوم که حالا با عنوان Opsless شناخته می‌شود، یک قدم جلوتر است: کار عملیاتی روزمره — فروش، پشتیبانی، حسابداری — بدون باز کردن نرم‌افزار انجام می‌شود. یک Agent مستقیماً از طریق API یا MCP روی CRM، Helpdesk و سیستم حسابداری کار می‌کند و انسان فقط نتیجه را می‌بیند. اما همین که Agent مستقل‌تر عمل می‌کند، یک سؤال زیرساختی جدی جلو می‌آید: این Agent چه چیزی را باید به یاد بیاورد؟ حافظه، تفاوت بین یک ابزار خودکار خنگ و یک همکار عملیاتی قابل‌اعتماد است.

چرا حافظهٔ Agent با حافظهٔ اپلیکیشن فرق دارد

یک اپلیکیشن سنتی حافظه‌ای ندارد؛ فقط داده در دیتابیس ذخیره می‌شود و هر بار کوئری می‌زنید. اما یک Agent عملیاتی باید بین چند تماس API، بین چند session، و گاهی بین چند روز، یک بافت (context) پیوسته حفظ کند. اگر Agent قرار است در یک وضعیت CRMless روی Nabux به‌عنوان یک لید رفتار کند — پیگیری کند، پاسخ بدهد، تصمیم بگیرد که چه زمانی باید تشدید (escalate) شود — باید بداند قبلاً چه گفته، چه تصمیمی گرفته شده و چرا. بدون این پیوستگی، هر تعامل از صفر شروع می‌شود و مشتری همان حسی را می‌گیرد که از یک ربات پشتیبانی بی‌حافظه می‌گیرد؛ دقیقاً نقطهٔ ضعفی که Opsless قرار است حل کند، نه بازتولید.

سه لایهٔ حافظه در یک Agent عملیاتی

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

• حافظهٔ کوتاه‌مدت (context window): چیزی که در همان یک اجرا یا session زنده است — پیام فعلی مشتری، نتیجهٔ آخرین فراخوانی API. با پایان task از بین می‌رود.
• حافظهٔ کاری (working memory): وضعیت یک task مشخص که ممکن است چند ساعت یا چند روز طول بکشد — مثلاً «این تیکت در انتظار تأیید مالی است، مرحلهٔ بعد فاکتور است».
• حافظهٔ بلندمدت سازمانی (long-term memory): دانشی که فراتر از یک task عمر می‌کند — ترجیحات یک مشتری خاص، قوانین کسب‌وکار، استثناهای تکرارشونده.