تصور کنید بخواهید اشتباهی را در حافظهٔ یک عامل هوش مصنوعی اصلاح کنید، اما تمام خاطرات او به صورت میلیون‌ها عدد اعشاری نامفهوم در یک پایگاه داده ذخیره شده باشد. EverOS این کابوس را به پایان می‌رساند و حافظه را به شکلی تبدیل می‌کند که هر کسی با یک ویرایشگر متن ساده بتواند آن را بخواند و تغییر دهد. مدل‌های زبانی بزرگ به‌طور ذاتی «بدون وضعیت» (Stateless) هستند، به این معنا که پس از پایان هر جلسه، همه چیز را فراموش می‌کنند. EverOS این محدودیت را با اجازه دادن به عامل‌های هوش مصنوعی برای داشتن یک حافظه پایدار و قابل خواندن توسط انسان حل می‌کند که به صورت فایل‌های ساده Markdown ذخیره می‌شوند. این امر تضمین می‌کند که بافت و زمینه یک گفتگو، مدت‌ها پس از پایان جلسه باقی بماند. بر اساس گزارش وب‌سایت marktechpost.com، این سیستم اکنون تحت مجوز Apache 2.0 در دسترس است.
bیشتر سیستم‌های حافظه هوش مصنوعی، داده‌ها را درون پایگاه‌های داده برداری پیچیده محبوس می‌کنند و بازرسی یا ویرایش آنچه عامل «به یاد می‌آورد» را برای توسعه‌دهندگان تقریباً غیرممکن می‌کنند. تصور کنید تلاش کنید یک اشتباه را در پایگاه داده‌ای با میلیون‌ها عدد اعشاری اصلاح کنید؛ این یک کابوس واقعی است. EverOS با حافظه مانند مجموعه‌ای از یادداشت‌ها در یک «باغ دیجیتال» برخورد می‌کند و به شما اجازه می‌دهد با استفاده از ابزارهای استاندارد مانند Obsidian یا Git، مغز عامل را باز کنید، دستور grep را روی آن اجرا کنید و نسخه‌های مختلف آن را مدیریت نمایید. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در لایه‌ی داده، اولین قدم برای کنترل دقیق رفتار مدل است.
زمینه و طراحی سیستم
EverOS به‌عنوان یک کتابخانه پایتون و یک محیط اجرای حافظه با اولویت محلی (Local-first) طراحی شده است. این سیستم به صورت یک سرور عمل می‌کند که دارای یک رابط خط فرمان (CLI) و یک FastAPI HTTP API است و در تمامی بخش‌های خود از ساختار async-first (اولویت با عملیات غیرهمزمان) بهره می‌برد. توسعه‌دهندگان به‌جای نیاز به بازسازی کامل ساختاری، می‌توانند به‌سادگی این محیط اجرا را در حلقهٔ اجرای عامل موجود خود جای دهند.
برای مدیریت الگوریتم‌های واقعی استخراج، EverOS از یک کتابخانه مجزا و بدون وضعیت به نام EverAlgo استفاده می‌کند. در حالی که EverAlgo منطق استخراج داده‌ها را بر عهده دارد، EverOS فرآیند را سازمان‌دهی کرده و نتایج را روی دیسک ذخیره می‌کند. این رویکرد محلی تضمین می‌کند که داده‌ها هرگز مجبور نباشند محیط کاربر را ترک کنند و هر لایه از سیستم قابل بازرسی باقی بماند. برای تیم‌هایی که ترجیح می‌دهند میزبانی شخصی (Self-hosting) نکنند، یک گزینه مدیریت‌شده به نام EverOS Cloud در دسترس است که در SDK، موتور بازیابی و فرمت حافظه با نسخه محلی کاملاً یکسان است.
معماری فنی
پشتهٔ ذخیره‌سازی این سیستم از سه لایه کلیدی تشکیل شده است تا تعادلی بین سرعت و شفافیت ایجاد کند:
- Markdown: به عنوان «منبع واحد حقیقت» (Single Source of Truth) برای تمام حافظه‌ها عمل می‌کند. هر رکورد حافظه دقیقاً به عنوان یک فایل .md ذخیره می‌شود.
- SQLite: مدیریت وضعیت کلی سیستم و صف‌های وظایف (Task Queues) را بر عهده دارد.
- LanceDB: مدیریت بردار معنایی (Embedding) — که مانند کارت معرفی عددی برای هر واژه است تا همسایگان معنایی‌اش مشخص شوند — و همچنین تطبیق کلیدواژه‌های BM25 و فیلترهای اسکالار را انجام می‌دهد.
این ساختار سبک و بهینه، نیاز به زیرساخت‌های سنگین و پیچیده‌ای مانند MongoDB، Redis، Kafka، Elasticsearch یا Milvus را به‌طور کامل حذف می‌کند. این موضوع هزینه‌های عملیاتی و پیچیدگی‌های مدیریتی را برای توسعه‌دهندگان مستقل و تک‌نفره به‌شدت کاهش می‌دهد.
مکانیزم‌های بازیابی
این سیستم از روشی به نام mRAG استفاده می‌کند تا سه نوع بازیابی را در یک پرس‌وجوی واحد ترکیب کند: جست‌وجوی برداری متراکم (Dense Vector Search)، تطبیق کلیدواژه‌های BM25 و فیلترهای اسکالار از طریق LanceDB. برای اطمینان از اینکه داده‌ها قدیمی نمی‌شوند، یک «همگام‌ساز ایندکس آبشاری» (Cascade Index Sync) به کار گرفته شده است؛ به این صورت که یک File-watcher هر زمان تغییری در یک فایل .md شناسایی کند، به‌طور خودکار عملیات همگام‌سازی مجدد را تحریک می‌کند.
بازیابی در این سیستم در سطح شناسه‌های خاص نیز تفکیک شده است (Orthogonal)، که به توسعه‌دهندگان اجازه می‌دهد جست‌وجوها را بر اساس موارد زیر محدود (Scope) کنند:
user_id(شناسه کاربر)agent_id(شناسه عامل)app_id(شناسه اپلیکیشن)project_id(شناسه پروژه)session_id(شناسه جلسه)
این تفکیک دقیق برای استقرار سیستم‌های چند-عامل (Multi-agent) و چند-کاربری که در آن‌ها جداسازی سخت‌گیرانه داده‌ها الزامی است، حیاتی می‌باشد.
بخش‌بندی و تکامل حافظه
EverOS حافظه را به دو مسیر متمایز تقسیم می‌کند. حافظه در سمت کاربر، بخش‌های «پروفایل‌ها» (Profiles)، «اپیزودها» (Episodes)، «حقایق» (Facts) و «پیش‌بینی‌ها» (Foresights) را دنبال می‌کند. در مقابل، حافظه در سمت عامل بر روی «Caseها» (پرونده‌ها) و «مهارت‌ها» (Skills) متمرکز است. این تمایز در صنعت بسیار نادر است، زیرا اکثر کتابخانه‌ها تنها تاریخچه چت (Chat History) را دنبال می‌کنند.
مدل حافظه بر اساس هدف دسته‌بندی شده است: حافظه اپیزودیک به سوال «چه اتفاقی افتاد» پاسخ می‌دهد، حافظه پروفایل به سوال «این کاربر کیست» و حافظه رویه‌ای (Procedural) به سوال «این وظیفه چگونه باید انجام شود» پاسخ می‌دهد.
برجسته‌ترین ویژگی این سیستم، حلقهٔ حافظه رویه‌ای است. هر وظیفهٔ تکمیل‌شده به عنوان یک Case ثبت می‌شود. زمانی که سیستم الگوهای موفق تکراری را شناسایی کند، آن‌ها را به‌صورت آفلاین در قالب «مهارت‌ها» (Skills) پالایش و تقطیر می‌کند. این مکانیسم به عامل‌ها اجازه می‌دهد تا عملکرد خود را از طریق تجربه بهبود ببخشند، به‌جای اینکه در هر جلسه از نقطه صفر شروع کنند. این مهارت‌ها بدون نیاز به تنظیم دستی یا کدنویسی سخت (Hardcoding)، در میان یک تیم از عامل‌ها به اشتراک گذاشته می‌شوند.
در نسخه ۱.۱.۰، فرآیند بازتاب (Reflection) اضافه شده است. این مکانیسم آفلاین، خوشه‌های اپیزودها را ادغام کرده و پروفایل‌های کاربر و مهارت‌ها را در فاصله بین جلسات پالایش می‌کند. همچنین این نسخه APIهای دانش (Knowledge APIs) را برای مدیریت صفحات Markdown مبتنی بر منابع، با یک تاکسونومی اختصاصی و جست‌وجوی موضوعی معرفی کرده است.
بنچمارک‌ها و عملکرد
بر اساس داده‌های گزارش شده توسط تیم EverMind، این سیستم در سه محک کلیدی نتایج دقیقی گرفته است:
- صحت ۹۳.۰۵٪ در LoCoMo
- صحت ۸۳.۰۰٪ در LongMemEval
- صحت ۹۳.۰۴٪ در HaluMem
به‌طور خاص، LoCoMo و LongMemEval حافظه conversational بلندمدت را می‌سنجند، در حالی که HaluMem بر روی توهمات حافظه (Memory Hallucination) — یعنی زمانی که مدل چیزی را با اطمینان می‌گوید که در واقعیت وجود ندارد، شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — تمرکز دارد. از نظر سرعت، تیم سازنده به تأخیر بازیابی (p95) کمتر از ۵۰۰ میلی‌ثانیه اشاره کرده است. لازم به ذکر است که این اعداد توسط EverMind گزارش شده‌اند و باید روی بارهای کاری خاص تأیید شوند.
پیاده‌سازی‌های واقعی
در حال حاضر چندین پروژه از این لایه حافظه استفاده می‌کنند:
- Hive Orchestrator: یک شبکه ذهنی (Hive-mind) مبتنی بر مرورگر برای عامل‌های کدنویسی CLI که در آن مدل‌هایی مانند Claude Code، Codex، Gemini و OpenCode به عنوان فرآیندهای واقعی PTY با یکدیگر همکاری می‌کنند.
- Reunite: سیستمی که از حافظه معنایی برای جست‌وجوی ارزش‌های عمومی استفاده می‌کند تا پیوندهایی بین خاطرات والدین و فرزندان پیدا کند.
- سلامت و گجت‌های پوشیدنی: یک دستیار حافظه برای بیماران مبتلا به آلزایمر و یک پوشیدنی هوشمند که صداهای زندگی روزمره را به حافظه ساختاریافته تبدیل می‌کند.
- آموزش: یک «هم‌درس» (Study Buddy) که دارای حافظه تکامل‌یافته است.
علاوه بر این موارد، اکوسیستم شامل یک پلاگین для Claude Code و یک لایه حافظه مبتنی بر MCP برای دستیاران کدنویسی است.
یکپارچه‌سازی برای توسعه‌دهندگان
برای توسعه‌دهندگان، یکپارچه‌سازی بسیار مستقیم است. سیستم با پروتکل OpenAI سازگار است، به این معنی که یک تغییر ساده در Base URL اجازه می‌دهد تا به OpenRouter، vLLM، Ollama یا DeepInfra متصل شود.
نصب این سیستم مستلزم Python 3.12 یا نسخه‌های جدیدتر است. مراحل اولیه شامل دستور pip install everos برای نصب، everos init برای مقداردهی اولیه و everos server start برای اجرای سرور FastAPI است. برای جذب داده‌های چندوجهی (Multimodal)، بستهٔ اختیاری pip install everos[multimodal] در دسترس است که تجزیه و تحلیل PDFها، تصاویر و فایل‌های صوتی را ممکن می‌سازد. برای مدیریت اسناد Office، سیستم نیاز دارد تا LibreOffice را برای تبدیل فایل‌ها به PDF پیش از تجزیه و تحلیل داشته باشد.
این تغییر رویکرد به سمت حافظه مبتنی بر فایل و قابل بازرسی، یک فرض بنیادین در طراحی عامل‌ها را تغییر می‌دهد: حافظه از یک «مشکل ذخیره‌سازی در جعبه‌های سیاه» به یک «مسأله مدیریت دانش» تبدیل شده است. با فاصله گرفتن از ذخیره‌سازهای برداری مبهم و حرکت به سمت Markdown ساختاریافته، توسعه‌دهندگان به سطحی از شفافیت و کنترل دست می‌یابند که پیش از این وجود نداشت.
دفعه بعد که عاملی می‌سازید، بررسی کنید که آیا یک Vector DB واقعاً بهترین گزینه است یا اینکه یک پوشه ساده از فایل‌های Markdown می‌تواند عامل شما را هدایت‌پذیرتر (Steerable) کند.
گام بعدی شما
- اگر عامل‌هایی می‌سازید که با داده‌های حجیم سر و کار دارند، به‌جای وابستگی کامل به Vector DB، بخشی از حافظه را به فایل‌های Markdown منتقل کنید تا قابلیت دیباگ (عیب‌یابی) دستی داشته باشید.
- از قابلیت
everos initبرای ساخت یک ساختار حافظه محلی و آزمایش سرعت بازیابی در محیط توسعه استفاده کنید. - بررسی کنید که آیا «مهارت‌های» استخراج‌شده از Caseها، تضادی با دستورالعمل‌های اصلی (System Prompt) شما دارند یا خیر.
اما تأثیر این شفافیت بر امنیت داده‌های حساس در محیط‌های سازمانی، بحثی پیچیده‌تر است — به تحلیل ما درباره‌ی پروتکل‌های MCP در گزارش بعدی مراجعه کنید.
گفتگو