حافظه و قابلیت اطمینان ایجنت

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

حافظه چیست؟#

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

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

هارنس
┤── پنجره‌ی کانتکست: حالت کاری موقت
┘── مخزن حافظه: حالت پایدار بین تعامل‌ها

در جلسه‌ی ۲ ساده‌ترین شکلش را دیدیم: فایل‌های CLAUDE.md. اما طراحی حافظه در واقع مجموعه‌ای از تصمیم‌های سیاستی است، هر کدام برای یک مرحله.

خط لوله‌ی حافظه#

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

و پرسش هفتم که جدا از این خط لوله است: مالک حافظه کیست؟ (پایین‌تر به آن می‌رسیم.)

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

کی چیزی حافظه شود؟#

یک طیف داریم: از «همه‌چیز را بنویس» (یادآوری بالا، نویز زیاد) تا «انتخابی بنویس» (دقت بالا). راه‌های انتخابی نوشتن، از صریح به ضمنی:

1. درخواست صریح کاربر: «این را یادت بماند»
2. قواعد قطعی، مثلاً هر وقت کاربر اشتباهی را اصلاح کرد
3. یک دسته‌بند کوچک
4. بازبینی دوره‌ای با LLM

به چه شکلی؟#

یک واقعیت واحد را در چهار شکل ببینید: «سرو مدل را از vLLM به SGLang بردیم».

کجا؟#

کی از حافظه استفاده شود؟#

• خودکار: در هر نوبت جستجو و افزودن. قابل پیش‌بینی، اما تأخیر و کانتکست نامربوط اضافه می‌کند.
• کنترل با runtime: هارنس با قاعده تصمیم می‌گیرد. انتخابی و کارا، اما قاعده یا دسته‌بند لازم دارد.
• کنترل با مدل: مدل ابزارهای search_memory، add_memory، update_memory و forget_memory را صدا می‌زند. بر اساس نیاز است، اما ممکن است خواندن یا نوشتن مفیدی را از قلم بیندازد.

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

بازیابی فقط شباهت معنایی نیست#

خط لوله‌ی ساده این است: کوئری ← جستجوی برداری ← k مورد برتر ← پرامپت. اما شباهت فقط یکی از سیگنال‌هاست:

• دامنه: همان کاربر، پروژه یا کار؟
• اهمیت: نبودنش چقدر هزینه دارد؟
• اعتبار: الان و برای این کار هنوز درست است؟
• منشأ: از کجا آمده و چقدر قابل اعتماد است؟

زمان اعتبار و منشأ#

آوریل ۲۰۲۶: «پروژه با vLLM سرو می‌شود»   → جایگزین شده
ژوئن  ۲۰۲۶: «پروژه با SGLang سرو می‌شود»  → فعلی (منبع: رویداد ۲۸)

همین را در گراف دانش این‌طور می‌نویسند؛ یال هم زمان اعتبار دارد و هم منبع:

Project ──SERVES_WITH──► vLLM     valid: Apr 2026 → Jun 2026 (superseded)
Project ──SERVES_WITH──► SGLang   valid: Jun 2026 → present
                                   source: Episode 28
                                   "We moved serving from vLLM to SGLang."

بدون زمان اعتبار نمی‌دانید کدام واقعیت جدیدتر است. بدون منشأ نمی‌دانید به آن اعتماد کنید یا نه. حافظه‌ی خوب هر دو را ثبت می‌کند.

فراموشی یک عمل اصلی است#

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

تعمیم و یکپارچه‌سازی#

اگر کاربر بارها درباره‌ی vLLM، SGLang، TRT-LLM و زمان‌بندی LLM پرسیده، می‌شود این تعمیم را ساخت: «علاقه‌ی مکرر به سیستم‌های استنتاج LLM (اطمینان: متوسط)». کی این کار را بکنیم؟ بعد از جمع شدن شواهد کافی، وقتی واقعیت‌ها تکرار یا تناقض دارند، و تا جای ممکن در یک کار پس‌زمینه.

مالک حافظه کیست؟#

• حافظه‌ی متعلق به ایجنت: فایل‌هایی که هارنس روی دیسک نگه می‌دارد (CLAUDE.md، یادداشت‌ها). ساده و شفاف.
• سیستم حافظه‌ی اختصاصی: یک سرویس که ایجنت صدا می‌زند و بین ایجنت‌ها و نشست‌ها مشترک است:

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

MemGPT یکی از ایده‌های پایه‌ی این حوزه است: از حافظه‌ی مجازی سیستم‌عامل الهام گرفت. پنجره‌ی کانتکست حکم RAM را دارد و حافظه‌ی بیرونی حکم دیسک. خود مدل با فراخوانی تابع، اطلاعات را بین این دو جابه‌جا می‌کند، مثل page in و page out.

خرابی‌های حافظه#

مورد «تزریق ماندگار» خطرناک‌ترین است، چون یک حمله‌ی یک‌باره را دائمی می‌کند. در جلسه‌ی ۹ به آن برمی‌گردیم.

ارزیابی حافظه#

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

بنچمارک‌های رایج: LoCoMo (ACL 2024؛ ۱۵۴۰ سؤال روی ۱۰ گفتگوی طولانی) و نسخه‌ی پالایش‌شده‌اش LoCoMo-Refined، LongMemEval (ICLR 2025؛ ۵۰۰ سؤال برای ۵ توانایی حافظه) و BEAM (ICLR 2026؛ ۲۰۰۰ سؤال با کانتکست تا ۱۰ میلیون توکن). این‌ها بیشتر یادآوری و استدلال روی تاریخچه‌ی گفتگو را می‌سنجند: استدلال زمانی، به‌روزرسانی، ترجیحات و اینکه مدل بداند کی نباید جواب بدهد.

پشته‌ی حافظه‌ی ایجنت#

دو چیدمان رایج:

چیدمان اول حافظه را بین ایجنت‌ها و نشست‌ها قابل اشتراک می‌کند و چیدمان دوم ساده‌تر و شفاف‌تر است.

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

هر مرحله یک تصمیم سیاستی است:

Observe
  └─ Select              Is this worth remembering?
  └─ Encode / organize   What representation preserves the needed meaning?
  └─ Store               Where should it live? File, database?
  └─ Retrieve            What is useful for the current task?
  └─ Reflect/consolidate Does this update or contradict an old memory?
  └─ Forget              When is information stale or irrelevant?

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

قابلیت اطمینان: چرا خطاها جمع می‌شوند#

یک اجرا فقط وقتی موفق است که همه‌ی قدم‌ها موفق باشند. اگر هر قدم ۹۵٪ احتمال موفقیت داشته باشد:

>>> [round(0.95 ** n, 2) for n in (1, 5, 10, 20, 50)]
[0.95, 0.77, 0.6, 0.36, 0.08]

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

خطا از کجا می‌آید؟ پنج لایه#

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

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

۱. تعریف کار#

۲. هارنس#

۳. مدل#

۴. ابزار#

۵. محیط#

طراحی برای خرابی: خلاصه#

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

پرسش‌هایی برای فکر کردن#

• اگر بتوانید احتمال موفقیت هر قدم را از ۹۵٪ به ۹۹٪ برسانید، احتمال موفقیت یک اجرای ۵۰ قدمی چقدر می‌شود؟ کدام کار ارزان‌تر است: بهبود هر قدم یا کم کردن تعداد قدم‌ها؟
• کدام خرابی‌های حافظه را در ایجنتی که خودتان استفاده می‌کنید دیده‌اید؟

منابع#

• اسلاید جلسه: Agents design III: agent memory and reliability (6_agent_design_3.pdf)
• Packer و همکاران، MemGPT: Towards LLMs as Operating Systems
• Where agents fail (arXiv:2509.25370)
• LongMemEval و LoCoMo