تصور کنید بین Claude Code، Cursor و Gemini CLI جابه‌جا می‌شوید، اما هر ابزار انگار در دنیای خودش است و حافظهٔ ابزار قبلی را ندارد. چون این ابزارها «مغز» مشترکی ندارند، تجربه کار با آن‌ها اغلب شبیه شروع از نقطه صفر است. یک برنامه‌نویس ممکن است ۲۰ دقیقه وقت بگذارد تا در Claude Code تصمیم بگیرد فریم‌ورک Express را برای Hono کنار بگذارد و pnpm را به جای npm انتخاب کند، اما یک ساعت بعد، Cursor با اطمینان از او می‌پرسد که اصلاً Relayer روی چه فریم‌ورکی است.
این گسستگی، شکستِ مدل‌های زبانی نیست، بلکه یک مشکل ذخیره‌سازی است. اکثر سامانه‌های حافظه فعلی بر پایه پایگاه‌داده برداری (Vector Database) — شبیه به یک سیستم بایگانی که کاغذها را بر اساس شباهت موضوعی کنار هم می‌گذارد، نه ترتیب زمانی — کار می‌کنند. این سیستم‌ها برای یافتن موضوعات مرتبط بسیار کارآمد هستند، اما در مدیریت «حافظهٔ ساختاری» (Load-bearing memory) شکست می‌خورند؛ چون نمی‌توانند تشخیص دهند کدام تصمیم قدیمی است و کدام‌یک فعلاً معتبر است.
همان‌طور که در تحلیل قبلی ما درباره‌ی مدیریت داده‌های حساس در عامل‌های هوشمند (مانند کلیدهای Master) اشاره کردیم، چالش فعلی از «امنیت» به «مدیریت وضعیت» (Project State) پروژه تغییر کرده است. طبق گزارش‌های فنی، در یک ذخیره‌ساز برداری، اگر دوشنبه بگویید از Express استفاده می‌کنید و پنجشنبه آن را به Hono تغییر دهید، سیستم هر دو پاسخ را برمی‌گرداند چون از نظر معنایی شبیه هستند. این منجر به این می‌شود که عامل‌های هوشمند با اعتمادبه‌نفس کامل، تصمیمی را پیشنهاد دهند که شما قبلاً آن را لغو یا معکوس کرده‌اید. برخی برای حل این مشکل از «وزن‌دهی زمانی» (Recency-weighting) استفاده می‌کنند، اما این کار فقط باعث می‌شود پاسخ‌های غلط به‌کندی محو شوند، نه اینکه کاملاً حذف گردند. این چالش‌ها در واقع بخشی از بحران گسترده‌تری است که در راهکارهای مقابله با فراموشی در جلسات عامل‌های هوشمند به آن‌ها پرداخته‌ایم.
برای حل این بن‌بست، توسعه‌دهنده‌ای در جریان هکاتون Graph Hacks، پروژه Engram را بر پایه FalkorDB ساخت. Engram لیست‌های تخت برداری را با یک ساختار گرافی جایگزین می‌کند که در آن «جایگزینی» (Supersession) به‌صورت یک یال (Edge) صریح مدل‌سازی می‌شود. در این سیستم، داده‌های قدیمی پاک نمی‌شوند، بلکه رابطه‌ای تعریف می‌شود که می‌گوید: (:Memory {text: "Relayer uses Hono"}) -[:SUPERSEDES {reason: "switched for built-in validators"}]-> (:Memory {text: "Relayer uses Express", status: "superseded"}). این ساختار به هوش مصنوعی اجازه می‌دهد به‌طور پیش‌فرض فقط حافظه‌های فعال را ببیند، اما در عین حال تاریخچه کامل تغییرات و دلیل وقوع آن‌ها را برای بازرسی حفظ کند. این رویکرد شباهت زیادی به مدل گراف‌های تصمیم Brethof-Brain دارد که برای جلوگیری از فقدان حافظه در عامل‌ها طراحی شده است.
مزایای فنی ساختار گرافی
به نقل از گزارش dev.to، رویکرد گرافی سه مزیت کلیدی نسبت به روش‌های سنتی تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — دارد:
- منشأ صریح (Explicit Provenance): ردیابی اینکه کدام ابزار در کدام جلسه تصمیمی گرفته است، تبدیل به یک پیمایش ساده در گراف می‌شود:
Tool -[:RAN]-> Session -[:CAPTURED]-> Memory -[:SUPERSEDES]-> Memory. این روش بسیار بهینه‌تر از استفاده از یک فایل JSON پیچیده است که احتمالاً از هم گسیخته است. پاسخ به سؤال «این حافظه را توضیح بده» صرفاً پیمایش یال‌های گراف است. - گسترش گراف (Graph Expansion): بازیابی اطلاعات از طریق یال‌های موجودیت‌ها بهبود می‌یابد، نه فقط از طریق تطبیق لغوی. اگر حافظه‌ای ذکر کند «از Hono استفاده می‌کند» بدون اینکه نام پروژه را بیاورد، مدل با یک گام پیمایش در یال‌های
RELATED_TO(که هر بار دو موجودیت در یک حافظه مشترک ظاهر شوند، تقویت می‌شوند) باز هم می‌تواند این حقیقت را پیدا کند. - جداسازی چندگرافی (Multigraph Isolation): FalkorDB اجازه می‌دهد برای هر پروژه یک گراف مجزا و یک گراف کلی در یک نمونه (Instance) داشته باشیم، آن هم بدون نیاز به زیرساخت اضافی. این یعنی تصمیمات پروژه A هرگز به پروژه B نشت نمی‌کند چون از نظر فیزیکی در گراف‌های متفاوتی قرار دارند.
چالش‌های پیاده‌سازی
بر اساس مستندات توسعه‌دهنده، ساخت این زیرساخت با رفتارهای مستندی در ابزارها برخورد کرد. توسعه‌دهنده متوجه شد که نتایج کوئری‌های FalkorDB به‌جای آرایه‌های موقعیتی، به‌صورت اشیایی با کلیدهای نام‌گذاری شده (RETURN aliases) برمی‌گردند (مثلاً {m: {...}, score: ...}). چون دسترسی به یک شیء با ایندکس [0] در جاوااسکریپت بدون ایجاد خطا مقدار undefined برمی‌گرداند، نسخه‌های اولیه توابع کوئری به‌طور خاموش اجرا می‌شدند اما هیچ خروجی مفیدی نمی‌دادند و ساعت‌ها زمان برای عیب‌یابی تلف شد.
جست‌وجوی متنی نیز چالش‌برانگیز بود. چون این سیستم از RediSearch استفاده می‌کند، عبارت‌های چندکلمه‌ای به‌صورت AND منطقی یا تطبیق دقیق عبارت (Phrase match) تفسیر می‌شوند. پرسشی طبیعی مثل «Relayer از چه فریم‌ورکی استفاده می‌کند» با حافظه‌هایی که فقط کلمه «Relayer» داشتند تطبیق نمی‌یافت، چون کوئری شامل تمام کلمات دیگر به‌صورت عیناً نبود. راهکار نهایی، حذف کلمات توقف (Stop words) و اتصال کلمات باقی‌مانده با عملگر OR بود.
همچنین در دسترسی به APIها ناهماهنگی‌هایی دیده شد. توسعه‌دهنده سعی کرد از مدل Kimi K2 شرکت Moonshot از طریق Groq استفاده کند، اما با وجود ذکر آن در مستندات خود Groq به عنوان یک مدل میزبانی شده، API خطای ۴۰۴ برگرداند. در نهایت مشخص شد که برای فهمیدن مدل‌های واقعاً در دسترس برای یک کلید API خاص، باید ابتدا مسیر /v1/models استعلام شود.
جریان کاری یکپارچه
در پیاده‌سازی نهایی، Claude Code حافظه را به‌طور خودکار از طریق قلاب‌های جلسه (Session Hooks) ثبت می‌کند. تصمیمات بدون نیاز به دستورات دستی مثل «این را به خاطر بسپار»، در پایان هر جلسه وارد گراف می‌شوند.
سپس Cursor و Gemini CLI از طریق پروتکل زمینهٔ مدل (MCP) به همین حافظه مشترک دسترسی پیدا می‌کنند. یک اشاره کوچک در ابتدای هر تسک — به‌ویژه دستور engram_recall — تابع بازیابی را فعال می‌کند و اجازه می‌دهد این ابزارها، زمینه‌ای را که عامل‌های دیگر ساخته‌اند، به ارث ببرند. این یکپارچگی در واقع بخشی از تحول گسترده‌تری است که در بررسی ابزارهای کدنویسی AI در سال ۲۰۲۶ دیدیم، جایی که نقش برنامه‌نویس از کدنویس صرف به یک ارکستراتور تبدیل می‌شود.
این تغییر، فرض بنیادی ابزارهای هوش مصنوعی را از «دستیارهای ایزوله» به یک «لایه شناختی مشترک» تغییر می‌دهد. با تبدیل حافظه از یک سطلِ بردار‌های مشابه به گرافی از حقیقت‌های تکامل‌یافته، برنامه‌نویسان دیگر مجبور نیستند هر بار حرف‌هایشان را برای ابزارهای مختلف تکرار کنند.
برای مشاهده این سیستم، یک رابط کاربری وب محلی طراحی شده که گراف را به‌صورت بصری نمایش می‌دهد؛ گره‌ها بر اساس وضعیت رنگ‌آمیزی شده‌اند و یال‌های SUPERSEDES برجسته شده‌اند. این موضوع ارزش سیستم را ثابت می‌کند: شما می‌توانید از ابزاری بپرسید تصمیمی که ابزار دیگری گرفته است و پاسخ فعلی را همراه با تاریخچه کامل برای پشتیبانی از آن دریافت کنید.
در آینده، شاهد پذیرش گسترده‌تر MCP (Model Context Protocol) خواهیم بود، زیرا ابزارهای بیشتری به سمت این معماری با وضعیت مشترک (Shared-state) حرکت می‌کنند.
گام بعدی شما
- بررسی مستندات Model Context Protocol (MCP) برای متصل کردن ابزارهای مختلف کدنویسی به یک منبع داده واحد.
- آزمایش جایگزینی ذخیره‌سازهای برداری ساده با گراف‌های دانش برای پروژه‌هایی که تغییرات وضعیت (State) در آن‌ها زیاد است.
- دنبال کردن توسعه FalkorDB برای مدیریت حافظه در مقیاس‌های بزرگتر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو