اگر تاکنون با عامل‌های هوشمند (Agent) که پس از چند ساعت کار، دستورات اولیه شما را فراموش می‌کنند یا در پاسخ‌هایشان دچار تضاد می‌شوند دست‌وپنجه نرم کرده‌اید، مشکل از معماری حافظه آن‌هاست. طبق گزارش فنی منتشر شده در ۲۵ ژوئن ۲۰۲۶ در وب‌سایت dev.to، سامانه AIClaw با تفکیک صریح «حقایق ماندگار» از «تاریخچه گفتگوها»، این نقص ساختاری را برطرف کرده است.
بسیاری از سیستم‌های عامل‌محور، تمام داده‌ها را در یک ظرف واحد و تفکیک‌نشده می‌ریزند. این رویکرد معمولاً منجر به سه حالت شکست رایج می‌شود: اول اینکه پرامپت‌ها بیش از حد شلوغ و گران می‌شوند؛ دوم، داده‌ها در بلوک‌های کدر پایگاه داده پنهان می‌شوند که کاربر امکان ویرایش آن‌ها را ندارد؛ و سوم، گفتگوهای قدیمی یا به‌کلی فراموش می‌شوند یا با شدت بیش از حد دوباره بارگذاری می‌گردند. برای حل این مشکل، AIClaw از دو ابزار مجزا برای دو مأموریت متفاوت استفاده می‌کند.
همان‌طور که در بررسی‌های پیشین ما درباره‌ی چالش‌های پنجرهٔ زمینه (Context Window) اشاره کردیم، مدیریت بهینه توکن‌ها کلید پایداری مدل است. در این راستا، AIClaw معماری حافظه دائمی را به‌صورت فایل‌های متنی ساده (Plain Text) پیاده‌سازی کرده است تا به‌جای بلوک‌های سریال‌شده و پیچیده، با فرمت‌های قابل‌فهم ذخیره شوند. این پیاده‌سازی در مسیر internal/tools/memorytool/memory.go قرار دارد و جزئیات آن در فایل README.md پروژه مستند شده است.
بر اساس مستندات این پروژه، سیستم از دو فایل کلیدی استفاده می‌کند:
MEMORY.md: برای ذخیره یادداشت‌های ماندگار عامل، حقایق محیطی و قراردادهای کاری.USER.md: برای ذخیره ترجیحات کاربر و سبک ارتباطی او.
از آنجا که این‌ها فایل‌های ساده‌ای هستند، اپراتورها می‌توانند بدون نیاز به دیباگ کردن ورودی‌های پیچیده پایگاه داده، رفتار عامل را مستقیماً بازبینی و ویرایش کنند. این انتخاب کاربردی، یک پایگاه دانش ایجاد می‌کند که به‌طور کامل توسط انسان قابل‌حسابرسی است.
برای جلوگیری از حجیم شدن پرامپت سیستمی (System Prompt) — که شبیه به دستورالعمل‌های ثابت یک آشپزخانه است تا مدل بداند در هر لحظه چه نقشی دارد — AIClaw محدودیت‌های شدیدی را بر تعداد کاراکترها اعمال کرده است. طبق مستندات فنی، سقف تعداد کاراکترها برای MEMORY.md برابر ۲۲۰۰ و برای USER.md برابر ۱۳۷۵ کاراکتر است.
وقتی این محدودیت‌ها پر شوند، سیستم به «حالت نمایه» (Index Mode) تغییر وضعیت می‌دهد. در این حالت، به‌جای تزریق تمام متن به پرامپت، فهرستی فشرده شامل شناسه‌های ورودی (Entry IDs)، تگ‌ها و خلاصه‌ها به مدل ارائه می‌شود. سپس عامل با استفاده از ابزار مخصوص memory و دستور recall (به صورت memory(action=recall, ids=[...])) تنها زمانی که واقعاً به جزئیات نیاز داشته باشد، اطلاعات کامل را بازیابی می‌کند. این یک موازنه‌ی هوشمندانه است تا حافظه بلندمدت حفظ شود بدون اینکه هر بار هزینهٔ توکن‌های اضافی پرداخت شود.
امنیت در این معماری اولویت بالایی دارد و عملیات نوشتن در حافظه به‌عنوان یک سطح حساس امنیتی (Security Surface) تلقی می‌شود. ابزار حافظه پیش از ذخیره، محتوا را به‌دقت اسکن می‌کند تا الگوهای مشکوک «تزریق پرامپت» (Prompt Injection) یا کاراکترهای نامرئی یونیکد را شناسایی و رد کند. این کار مانع از آن می‌شود که مهاجمان دستورات مخربی را در حافظه جای دهند تا در جلسات آینده به‌عنوان بخشی از پرامپت سیستمی اجرا شوند.
برخلاف حافظه دائمی، یادآوری تاریخچه توسط ابزار مجزای جست‌وجوی جلسه مدیریت می‌شود که در مسیر internal/tools/sessionsearch/session_search.go قرار دارد. این ابزار برای پاسخ به پرسش‌هایی درباره رشته‌های استقرار (Deployment Threads) قبلی، پیام‌های خطای خاص یا توصیفات پیشین کاربر از گردش‌کار (Workflow) به کار می‌رود. این ابزار در دو حالت عمل می‌کند: حالت «بدون پرس‌وجو» (No Query) که گفتگوهای اخیر را همراه با پیش‌نمایش برمی‌گرداند، و حالت «با پرس‌وجو» (Query Provided) که قطعات متنی مطابق با جست‌وجو را از پیام‌های پیشین استخراج می‌کند.
به گزارش dev.to، AIClaw برای بهینه‌سازی این بخش از جداول مجازی FTS5 در SQLite استفاده می‌کند که در مسیر internal/store/gormstore/fts.go پیاده شده است. این ساختار تضمین می‌کند که نمایه‌گذاری و جست‌وجو با استفاده از تریگرها (Triggers)، سریع و همگام (Synchronized) باشد. در محیط‌هایی که FTS5 در دسترس نیست، سیستم به‌طور خودکار و برای حفظ عملکرد، به مسیر جست‌وجوی استاندارد SQL LIKE تغییر وضعیت می‌دهد. این قابلیت، همان «تخریب تدریجی» (Graceful Degradation) است که برای سیستم‌های Local-first ضروری است.
یک مکانیزم حیاتی دیگر، «عکس‌برداری» (Snapshot) از فایل‌های حافظه در ابتدای هر جلسه است. لودر سیستم در مسیر internal/agent/prompt_loaders.go با فراخوانی تابع memorytool.LoadSnapshot(...) بلوک‌های حافظه را با پرامپت زمان اجرا ادغام می‌کند تا رفتار پرامپت در طول یک جلسه ثابت بماند.
نکته کلیدی و حیاتی این است که تغییرات حافظه در طول یک جلسه، روی جلسات آینده اثر می‌گذارد، نه جلسه‌ای که در حال حاضر در حال اجراست. این محدودیت از بروز دسته‌ای از مشکلات دشوار در دیباگ جلوگیری می‌کند؛ مشکلاتی که در آن عامل ممکن است در میانه راه، دستورالعمل‌های خودش را به‌طور خاموش تغییر دهد و باعث سردرگمی در اجرا شود.
این رویکرد منضبط، پارادایم عامل‌محور را از «بارگذاری تاریخچه زیاد و امید به موفقیت» به یک مدل بازیابی ساختاریافته تغییر می‌دهد و یک چت‌بات فراموش‌کار را به سیستمی با پایگاه دانش قابل‌اعتماد و قابل‌حسابرسی توسط انسان تبدیل می‌کند.
گام بعدی شما
- اگر از تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب را باز می‌کند تا دقیق پاسخ دهد — استفاده می‌کنید، بررسی کنید که آیا پیاده‌سازی فعلی شما حافظه را بیش از حد ساده کرده و همه چیز را در یک فضای برداری (Vector Store) واحد ریخته است یا خیر.
- برای درک عمیق‌تر، ساختار دایرکتوری‌های
internal/tools/memorytoolوinternal/tools/sessionsearchرا در کدهای AIClaw تحلیل کنید. - سعی کنید تفکیک بین «ترجیحات کاربر» و «حقایق محیطی» را در پرامپت‌های خود پیاده کنید تا نرخ توهم مدل کاهش یابد.
اما مدیریت این حجم از داده در لبه‌های شبکه چالش‌های جدیدی ایجاد می‌کند؛ بررسی تحلیل ما درباره رایانش لبه (Edge Computing) برای بهینه‌سازی مدل‌ها را از دست ندهید.
گفتگو