«پایان فراموشی در جلسات»؛ راهکاری برای حافظه بلندمدت عامل‌های هوشمند

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

به نقل از راهنمای فنی منتشر شده در dev.to در ۱۷ اکتبر ۲۰۲۶، می‌توان با پیاده‌سازی یک ذخیره‌ساز حافظه مبتنی بر فایل (File-backed memory store) که پس از ری‌استارت شدن فرآیندها باقی می‌ماند، این مشکل را حل کرد. این قابلیت در ادامه بهبودهای قبلی روی عامل‌ها اضافه شده است؛ عامل‌هایی که پیش از این توانمند، خودمختار و ایمن‌تر شده بودند. این عامل در حال حاضر می‌تواند از ابزارها در یک محیط ایزوله Docker استفاده کند، برای کارهای طولانی برنامه‌ریزی نماید، در صورت نیاز درخواست کمک کند، سیاست‌های ابزاری را رعایت کند و هنگامی که به محدودیت منابع رسید، متوقف شود. با این حال، بدون حافظه بلندمدت، عامل هر بار که برنامه بسته شود، زمینه‌های حیاتی را فراموش می‌کند؛ مثلاً این حقیقت که یک پروژه از uv استفاده می‌کند یا اینکه یک عملیات مهاجرت (migration) دیروز به طور ناقص انجام شده است.

بسیاری از عامل‌های فعلی تنها به حافظه کوتاه‌مدت متکی هستند؛ یعنی لیستی از پیام‌ها که به عنوان زمینه (Context) به مدل ارسال می‌شود. این لیست شامل پرامپت سیستمی، پیام‌های کاربر، پاسخ‌های مدل و نتایج ابزارهاست. در حالی که این روش برای کارهای فوری مؤثر است، اما در بلندمدت شکست می‌خورد؛ زیرا مدل دارای یک پنجره زمینه محدود است و هر توکن اضافی، تأخیر (Latency) و هزینه را افزایش می‌دهد. برای عبور از این محدودیت، توسعه‌دهندگان می‌توانند داده‌های گذرا و مربوط به جلسه را از حقایق پایدار و بلندمدت جدا کنند. این رویکرد ساده‌ساز در مقابل متدهای پیچیده‌تری قرار می‌گیرد، مانند استفاده از گراف‌های تصمیم Brethof-Brain برای مقابله با فراموشی عامل‌ها که ساختاری متفاوت برای مدیریت حافظه ارائه می‌دهد.

طبق گزارش dev.to، به جای استفاده از پایگاه‌داده‌های برداری پیچیده، بهینه‌ترین نقطه شروع برای حافظه بلندمدت، یک دایرکتوری ساده شامل فایل‌های Markdown است. در این ساختار، یک کلاس به نام MemoryStore وظیفه خواندن و نوشتن در فایل‌های خاصی را بر عهده دارد که در مسیر ~/.agent-harness/memory/ قرار دارند.

معماری حافظه

برای جلوگیری از آلودگی داده‌ها (Data Pollution)، سیستم تداوم را به دو محدوده (Scope) مجزا تقسیم می‌کند:

• حافظه پروژه (project.md): ذخیره درس‌های بادشتاه و پایدار درباره محیط پروژه و قراردادهای آن، مانند «برای دستورات پایتون از uv استفاده کن».
• حافظه کاربر (user.md): ذخیره ترجیحات و انتظارات پایدار کاربر، مانند «پاسخ‌های کوتاه و مختصر را ترجیح می‌دهد».

جزئیات پیاده‌سازی

کلاس MemoryStore دایرکتوری ریشه و یک زیردایرکتوری خاص به نام sessions را مدیریت می‌کند. این کلاس از یک متد کمکی به نام _notes_path استفاده می‌کند تا اطمینان حاصل شود که مدل نمی‌تواند نام فایل‌های دلخواه را انتخاب کند؛ این متد فقط «project» یا «user» را به عنوان محدوده‌های معتبر می‌پذیرد و در غیر این صورت، خطای ValueError صادر می‌کند.

• read_notes: متن فایل مورد نظر در محدوده درخواستی را با کدگذاری UTF-8 می‌خواند. اگر فایل وجود نداشته باشد، عبارت «(empty)» را برمی‌گرداند.
• append_notes: فایل را در حالت append (افزودن) باز می‌کند. اگر فایل از قبل حاوی داده باشد، پیش از نوشتن محتوای جدید و پاک‌سازی شده (stripped)، یک خط جدید اضافه می‌کند تا قالب‌بندی تمیز باقی بماند.

عامل برای تعامل با این فایل‌ها از دو ابزار خاص read_memory و append_memory استفاده می‌کند. این‌ها در دسته «ابزارهای برنامه‌ریزی» (Planning Tools) قرار می‌گیرند، به این معنی که در داخل فرآیند (In-process) اجرا می‌شوند و برای هر فراخوانی نیاز به اجازه انسانی ندارند، که این امر جریان کاری خودمختار عامل را تسهیل می‌کند. از آنجایی که این ابزارها وضعیتِ بدنه (Harness state) را مدیریت می‌کنند و روی فایل‌های پروژه اثر نمی‌گذارند، در کنار scratchpad و لیست کارهای (to-do list) عامل اجرا می‌شوند.

حفاظ‌های امنیتی و حریم خصوصی

حافظه پایدار ریسک‌های امنیتی قابل توجهی را ایجاد می‌کند، زیرا یک یادداشت اشتباه می‌تواند رفتار عامل را به طور نامحدود تحت تأثیر قرار دهد. برای کاهش این ریسک، پیاده‌سازی فعلی قوانین سخت‌گیرانه‌ای را در پرامپت سیستمی اعمال می‌کند. عامل صراحتاً از ذخیره اسرار (Secrets)، کلیدهای API یا جزئیات گذرا مانند «در این سند از عنوان آبی استفاده کن» منع شده است.

محدودیت‌های امنیتی خاص شامل موارد زیر است:

• حفاظت از اعتبارنامه‌ها: کلیدهای API، رمزهای عبور و توکن‌ها هرگز نباید در زمینه مدل یا یک فایل پایدار قرار گیرند.
• جلوگیری از تزریق (Injection): محتوای تزریق‌شده از طریق پرامپت (Prompt-injection) که از یک صفحه وب یا فایل وارد شده است، هرگز نباید به حافظه بلندمدت ارتقا یابد.
• بازبینی انسانی: یادداشت‌ها باید مختصر باقی بمانند تا بتوانند به راحتی توسط یک انسان بازبینی و اصلاح شوند.

علاوه بر این، دایرکتوری حافظه خارج از محیط mount پروژه در Docker نگه داشته می‌شود. این امر تضمین می‌کند که عامل به جای استفاده از ابزارهای عمومی سیستم‌فایل، از طریق رابط کنترل‌شده MemoryStore به حافظه خود دسترسی داشته باشد و از حملات تزریق پرامپت برای انتقال محتوای مخرب وب به ذخیره‌ساز بلندمدت جلوگیری شود. از آنجایی که دایرکتوری حافظه حاوی داده‌های حساس کاربر است، باید با مجوزهای استاندارد سیستم‌عامل و سیستم‌های پشتیبان (Backup) محافظت شود.

تست جریان کاری

در یک تست عملی، کاربر می‌تواند به عامل بگوید: «من پاسخ‌های مختصر را ترجیح می‌دهم. این را برای جلسات آینده به خاطر بسپار». عامل ابتدا متد read_memory({'scope': 'user'}) را فراخوانی می‌کند، متوجه خالی بودن آن می‌شود و سپس append_memory({'scope': 'user', 'content': 'The user prefers concise answers.'}) را اجرا می‌کند.

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

این تغییر در معماری، فرض بنیادی مبنی بر اینکه عامل‌ها باید هر بار هنگام بوت شدن، محیط خود را «دوباره یاد بگیرند» را تغییر می‌دهد. با تبدیل حافظه به یک دفتر کل (Ledger) محدود و فقط-افزودنی (Append-only) از حقایق، توسعه‌دهندگان می‌توانند عامل‌هایی بسازند که واقعاً با جریان کاری کاربر تکامل می‌یابند.

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

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

گام بعدی شما

• بررسی کنید کدام داده‌های فعلی در پرامپت‌های شما «پایدار» هستند و می‌توانند به فایل‌های Markdown منتقل شوند.
• پیاده‌سازی یک لایه بازبینی (Review) برای فایل‌های حافظه تا از عدم ورود داده‌های غلط به حافظه بلندمدت مطمئن شوید.
• تست کنید که آیا تفکیک حافظه کاربر و پروژه، نرخ توهم مدل را در پروژه‌های بزرگ کاهش می‌دهد یا خیر.

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