اگر یک عامل هوشمند دسترسی مستقیم برای نوشتن در حافظه بلندمدت خود داشته باشد، به‌سرعت آن را با حجم عظیمی از اطلاعات نادرست اما با اطمینان بالا پر می‌کند. برای حل این مشکل، توسعه‌دهنده‌ای به نام Olund سیستمی را پیاده کرده است که دقیقاً شبیه به خواب انسان عمل می‌کند تا فقط داده‌های با سیگنال بالا باقی بمانند. این سیستم با تجمیع رویدادهای اپیزودیک (گذرا) به‌صورت آفلاین، تضمین می‌کند که تنها اطلاعاتی که ارزش ماندگاری دارند حفظ شوند.
طبق مستندات منتشرشده در ۲۹ جولای ۲۰۲۶ در وب‌سایت olund.dev، این سازوکار عمل ثبت داده‌ها را از تصمیم‌گیری درباره ارزش یادآوری آن‌ها جدا می‌کند. اکثر معماری‌های فعلی عامل‌های هوشمند با مشکلی به نام «آلودگی حافظه» (Memory Pollution) دست‌وپنجه نرم می‌کنند؛ وضعیتی که در آن نویزهای گذرا به جای واقعیت‌های بادوام پذیرفته می‌شوند. برای مثال، اگر یک عامل در میانه انجام یک وظیفه تصمیم بگیرد که تکه‌ای از اطلاعات مهم است، اغلب نمی‌تواند تشخیص دهد که آن جزئیات تا یک هفته بعد کاملاً بی‌ربط خواهند بود. Olund با تبدیل حافظه به یک فرآیند کند و گیت‌دار (درست مانند تثبیت بیولوژیکی خاطرات در هنگام خواب) به‌جای یک دفتر ثبت لحظه‌ای، از این مشکل جلوگیری کرده است. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت ورودی‌ها کلید پایداری سیستم است؛ در اینجا نیز این یعنی هرچه داده‌ها بیشتر تکرار شوند، احتمال ثبت آن‌ها در حافظه بلندمدت بیشتر می‌شود.
معماری رؤیاپردازی (The Dreaming Architecture)
این سیستم روی یک پشته‌ای (Stack) مبتنی بر سیستم فایل اجرا می‌شود و هیچ دیمون (Daemon) مقیم ندارد. به‌جای آن، یک زمان‌بندی (Scheduler) دو چرخه مجزا را فعال می‌کند:
- چرخه صبحگاهی: کارهای سبک‌تر را انجام می‌دهد، مانند تولید توصیه‌ها و شناسایی وظایفی که نیاز به توجه فوری دارند.
- چرخه شبانه: پردازش‌های سنگین ارتقای حافظه را مدیریت می‌کند. در این مرحله، تماس‌های ابزاری (Tool Calls)، خلاصه‌ی جلسات و افکار ثبت‌شده طی روز تحلیل می‌شوند.
برای جلوگیری از تداخلات هم‌زمانی (Concurrency Conflicts)، دقیقاً یک ماشین مالک فرآیند «رؤیاپردازی» است. سایر ماشین‌های موجود در خوشه (Cluster) — شبیه به یک تیم که در آن فقط یک نفر اجازه دارد گزارش نهایی را بنویسد و بقیه فقط می‌خوانند — صرفاً فایل‌های بادوام نهایی را مطالعه می‌کنند. این مدل «تک‌نویسنده» (Single-writer model) نیاز به منطق‌های پیچیده برای ادغام داده‌ها (Merge Logic) در هنگام همگام‌سازی را کاملاً حذف می‌کند. این رویکرد به مدیریت وضعیت (State) کمک می‌کند، درست مانند زمانی که پایگاه‌داده SQLite حافظهٔ عامل‌ها را در برابر کرش مقاوم کرد تا پایداری سیستم در مقیاس بالا حفظ شود.
به منظور پیش‌بینی‌پذیر نگه داشتن هزینه‌ها، هر چرخه تحت یک بودجه سخت‌گیرانه از توکن (Token) فعالیت می‌کند. اگر سیستم در میانه یک چرخه به سقف خروجی برسد، پردازش مواردی که در حال حاضر در گیت هستند را به پایان رسانده و مقدار اضافی را برای اجرای بعدی ثبت (Log) می‌کند. این سقف ساختاری باعث می‌شود هزینه روزانه عملیات بین ۱ تا ۳ دلار باقی بماند.
خط لوله حافظه (The Memory Pipeline)
در چرخه شبانه، داده‌ها برای فیلتر کردن نویز از یک خط لوله پنج‌مرحله‌ای عبور می‌کنند:
۱. خوشه‌بندی (Cluster): رویدادها با استفاده از بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگانش را مشخص می‌کند — گروه‌بندی می‌شوند. واقعیت‌های بادوام بر اساس تم‌هایی که در چندین جلسه مختلف ظاهر شده‌اند شناسایی می‌شوند، نه بر اساس یک اتفاق تک‌گیر و ایزوله.
۲. تأمل (Reflect): یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — هر خوشه را تحلیل کرده و یک «واقعیت کاندید» پیشنهاد می‌دهد. در این مرحله، شناسه‌ی (ID) رویدادهای پشتیبان برای حفظ منشأ داده‌ها (Provenance) نگه داشته می‌شود.
۳. امتیازدهی (Score): کاندیدها تحت بررسی‌های ساختاری قرار می‌گیرند. آن‌ها باید تعداد کافی رویداد پشتیبان متمایز در بازه‌های زمانی مختلف داشته باشند و نباید صرفاً بازنویسی واقعیت‌های شناخته‌شده قبلی باشند.
۴. قضاوت (Judge): دو بررسی مجزا توسط LLM تأیید می‌کنند که آیا کاندید پیشنهادی با حافظه موجود تضاد دارد یا یک مورد تکراری است.
۵. ارتقاء یا صف (Promote or Queue): تنها کاندیدهایی که امتیاز اطمینان بالا دارند و حداقل سه رویداد پشتیبان دارند، به‌طور خودکار ارتقاء می‌یابند. هر مورد دیگری به صف بررسی دستی (Manual Review Queue) منتقل می‌شود.
این ساختار لایه‌بندی شده برای پالایش اطلاعات، یادآور معماری‌های سه لایه برای شبیه‌سازی آگاهی است که در آن حافظه و اهداف در سطوح مختلف پردازش می‌شوند تا رفتاری هوشمندانه ایجاد شود.
مهندسی برای رد کردن داده‌ها (Engineering for Refusal)
Olund تأکید می‌کند که کیفیت سیستم به آنچه «نمی‌نویسد» و رد می‌کند بستگی دارد. در حالی که تولید کاندیدها آسان است، اما آلودگی حافظه با گذشت زمان اثرات مرکب دارد. یک واقعیت غلط می‌تواند در ده‌ها جلسه آینده مورد استناد قرار گیرد و زنجیره‌ای از خطاها را ایجاد کند.
دو شکست مهندسی خاص باعث تغییر طراحی نهایی شد: نخست، یک «عدم تطابق کف خاموش» (Silent Floor Mismatch) رخ داد؛ زمانی که مرحله خوشه‌بندی اجازه می‌داد خوشه‌های دو رویدادی عبور کنند، اما مرحله امتیازدهی آن‌ها را حذف می‌کرد. این وضعیت هیچ خطایی تولید نمی‌کرد و فقط باعث می‌شد سیستم «ساکت‌تر» شود، که ثابت کرد شناسایی آستانه‌های ناسازگار در مراحل مختلف خط لوله بسیار دشوار است.
دوم، سیستم در ابتدا در صورت بروز خطای شبکه گذرا در LLM، کل چرخه را متوقف (Abort) می‌کرد. معماری به‌روز شد تا هرگونه شکست سخت LLM به یک پیش‌فرض محافظه‌کارانه (مثلاً فرض بر اینکه واقعیت جدید است) تنزل یابد (Degrade) تا یک اختلال کوچک در API باعث از بین رفتن پردازش‌های یک روز کامل نشود.
از واقعیت‌ها به مهارت‌ها (From Facts to Skills)
فرآیند تثبیت حافظه همچنین گردش‌های کاری تکراری را شناسایی می‌کند. وقتی سیستم تشخیص دهد که یک رویه (Procedure) خاص حداقل در سه مورد در روزهای مختلف اجرا شده است و هنوز مهارتی برای آن تعریف نشده، به‌طور خودکار پیش‌نویس یک فایل «مهارت» (Skill File) را می‌نویسد.
این پیش‌نویس‌ها تا زمانی که کاربر انسانی آن‌ها را به‌طور صریح فعال نکند، غیرفعال و برای بدنه عامل (Agent Harness) نامرئی می‌مانند. این رویکرد نقش انسان را از وظیفه طاقت‌فرسای نوشتن پیش‌نویس‌ها به وظیفه باارزشِ «تأیید توانمندی‌ها» تغییر می‌دهد. این تحول در مدیریت داده‌ها مشابه رویکرد OpenClaw در جایگزینی گزارش‌های متنی با پایگاه‌داده است که هدف آن بهینه‌سازی نحوه ذخیره‌سازی و بازیابی تجربیات عامل است.
این روش، عامل هوشمند را از یک مجری ساده وظایف به سیستمی تبدیل می‌کند که رفتار را از طریق تکرار می‌آموزد. عامل با تحلیل «ردپای» کارهای روزانه، تجربه‌های اپیزودیک را به مجموعه‌ای از مهارت‌های بادوام تبدیل می‌کند.
گام بعدی شما
- اگر عامل‌های AI شما دچار توهمات تکراری می‌شوند، معماری «پردازش آفلاین شبانه» را برای جداسازی ثبت داده از تثبیت حافظه بررسی کنید.
- برای کاهش هزینه‌ها، سقف سخت‌گیرانه توکن (Hard Token Budget) را برای چرخه‌های پردازشی پس‌زمینه پیاده کنید.
- سیستم‌های خود را به‌گونه‌ای طراحی کنید که در صورت قطع API، به‌جای توقف کامل، به یک حالت پیش‌فرض ایمن (Fail-safe) بازگردند.
اما این روش مدیریت حافظه تنها بخشی از معماری است؛ اثر استفاده از دیتابیس‌های برداری در مقیاس بالا را در تحلیل ما درباره Vector Databases دنبال کنید.
گفتگو