kaeru يمنح Claude Code وCodex ذاكرة طويلة الأمد على شكل رسم بياني عبر MCP

كل من يعمل مع وكلاء الذكاء الاصطناعي لأكثر من أسبوع يعرف هذا المشهد. تفتح مشروعًا فيسألك الوكيل عن أمر أجبته عنه بالأمس. وبعد نصف ساعة يقترح إصلاح ما قررت ألا تمسّه، ويبدو مقنعًا لأنه لا يعرف السبب. وعندما يمتلئ السياق ويُضغط الحديث في ملخص، يتحول نصف النقاش إلى سطرين.

يقترح فريق Lamantin AI معالجة ذلك بطبقة ذاكرة مستقلة. تسمى الأداة kaeru، وشيفرتها المصدرية متاحة على GitHub. فيما يلي عرض لكيفية عملها ونقاط ضعفها. كاتب النص هو مطوّر الأداة نفسها، فتعاملوا مع ما يقوله بوصفه رؤية من الداخل.

لماذا لا يكفي ملف القواعد

الخطوة الأولى واحدة عند الجميع: CLAUDE.md أو AGENTS.md أو .cursorrules أو ملاحظة في Obsidian. وبعد نحو شهر تبدأ المشكلات:

• يُحدَّث الملف عندما نتذكره، أي بعد ثلاثة أيام وبفقدان بعض التفاصيل؛
• لا يفعل سوى النمو: الإضافة سهلة والحذف مخيف، ويصدّق الوكيل قاعدة الأمس وقاعدة أُلغيت قبل شهر بالقدر نفسه؛
• فيه «ماذا» لكن ليس فيه «لماذا»: عبارة «لا تلمس المحلّل» دون سبب لا يمكن التحقق منها ولا إلغاؤها؛
• لكل عضو في الفريق ملفه الخاص.

تعالج ADR وأدوات تتبع المهام مثل beads جزءًا من المشكلات، لكنها لا تعالج طبقة العمل بين الالتزامات (commits): الفرضيات والفحوص وخصوصيات بيئات الاختبار. وإدراج كل ذلك في المستودع يعني تلويث السجل، وعدم تدوينه يعني فقدانه. ولهذه الطبقة صُمّم kaeru.

كيف يعمل

يعمل kaeru على جهازك بوصفه خادم MCP، وتتصل به Claude Code وCodex وCursor وعملاء آخرون. تُخزَّن الذاكرة على شكل رسم بياني: ملاحظات («ملفات العميل تصل بترميز cp1251»)، وقرارات، ومهام ذات مواعيد، وفرضيات مع نتيجة التحقق منها، ومستندات. والروابط مصنّفة: «نشأ من»، «يحلّ محل»، «يدحض»، «يؤكد»، «يعطّل»، «يتعارض مع». ويمكن للوكيل حفظ السلسلة كاملة من الملاحظة إلى القرار بوصفها استدلالًا.

مثال من المقال: يشتبه الوكيل في أن التصدير الليلي يفشل بسبب حجم الملف. يختبر ملفًا بحجم 2 غيغابايت ويسجّل الفرضية فورًا مع حكم «مدحوضة». وإذا فشل التصدير مرة أخرى بعد أسبوع، يبدأ الوكيل التالي من تفسير آخر. وبلا ذاكرة تضيع النتيجة السلبية أولًا: الحلول الناجحة تصل إلى الشيفرة، أما الفاشلة فلا تصل إلى أي مكان.

يمكن استبدال القديم صراحةً. يعلّم استدعاء replace السجل السابق بأنه مُستبدَل ويُظهر الاستنتاجات التي استندت إليه. ولا يُحذف السجل، بل يحتفظ بتاريخه، ويمكن فتح نسخته في أي لحظة.

وهناك أيضًا تذكيرات: يمكن إخفاء السجل حتى تاريخ معيّن. مثال الكاتب: شهادة بيئة الاختبار تُجدَّد كل ستة أيام. في اليوم الخامس تلزم هذه المعلومة، وفي اليوم الأول تعيق فحسب. ويُحتسب موعد التذكير من أول عرض، ولذلك لا يضيع بعد إجازة.

ما تفعله الـ hooks وما يفعله الخادم

يتولى الخادم التخزين والملخص. أما متى يُطلب الملخص وماذا يُفعل عند ضغط السياق فيقرره العميل عبر hooks في Claude Code وCodex. وقد كتب المؤلف بعض الـ hooks لنفسه، وهي ليست ضمن kaeru حاليًا. وفي المستودع kaeru-first: قبل أن يوجّه الوكيل سؤالًا إلى الإنسان، يبحث الـ hook عن تطابقات في الذاكرة ويقترح قراءة ما وُجد أولًا.

وثمة ملاحظة مفيدة. اقترحوا على الوكيل ببساطة أن يقرأ الاستدلالات المحفوظة، ولم يفعل ذلك مرة واحدة خلال سبع جلسات. لذلك يُضاف الملخص تلقائيًا عند بدء الجلسة.

القيود

• لا يضمن kaeru صحة السجلات. فقد يدوّن الوكيل هراءً كما يفعل في ملف القواعد. والمكسب أنه يمكن رؤية الملاحظات التي نشأ منها الاستنتاج، ويمكن وسم الخطأ وإعادة بناء السلسلة.
• على الوكيل أن يستدعي استبدال القديم بنفسه. عند المؤلف بقيت قاعدتان بمعرّفين مختلفين للأشخاص أنفسهم في GitLab لمدة أسبوعين: سُجّلت الجديدة ولم تُستبدل القديمة.
• تطابق الكلمات لا يعني أن في السجل إجابة.
• خادم الفريق kaeru-cloud تقيمه بنفسك. وهو مصمم لفريق موثوق، بمساحة مشتركة واحدة مقسّمة حسب المشاريع، ولا يوجد حتى الآن عزل بين المستخدمين والمؤسسات. المشاريع خاصة افتراضيًا، وتُفحص السجلات قبل الإرسال بحثًا عن المفاتيح والرموز (tokens).

ما العمل بكل هذا

إذا كان وكلاؤك يعملون على المشروع نفسه أكثر من يومين، فمن المفيد تقسيم المعرفة إلى طبقتين. تبقى الاتفاقات الثابتة في المستودع (القواعد وADR) وتخضع للمراجعة. أما الاكتشافات العملية والفرضيات المرفوضة و«لماذا» فتحتاج إلى مخزن مستقل بتاريخ واستبدال صريح للقديم. وحتى دون kaeru يفيد تبنّي ممارستين: تدوين الفرضيات مع حكمها، وتزويد الوكيل بملخص قصير تلقائيًا بدل الأمل في أن يقرأه من تلقاء نفسه.