ذاكرة لوكيل AI: من التعقيد إلى 300 سطر من الكود

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

MemPalace والخطأ الأول

بدأ كل شيء برؤية طموحة — MemPalace، نظام ذاكرة مستوحى من معمارية القصور الوسيطة. بدا ذكياً على الورق، لكن في الواقع أنشأ 58 ألف جزء مكرر وتحول إلى متاهة لا يمكن اختراقها. طبقات كثيرة جداً من التجريد، سحر كثير جداً. الوكيل ضاع في ذاكرته الخاصة.

الطريق إلى البساطة

بعد MemPalace، بسّط المؤلف المجموعة إلى أربعة مكونات: MEMORY.md (قاعدة البيانات الرئيسية)، USER.md (سياق المستخدم)، SQLite state.db (الحالة)، HippoRAG (البحث) وملفات wiki (البيانات المنظمة). لكن حتى هذا بدا زائداً. الخطوة الصحيحة كانت كتابة `findings_to_wiki`، سكريبت بايثون بسيط من 300 سطر يحفظ تلقائياً التحليلات المنظمة (المحددة برؤوس مثل `## Findings`) في ملفات markdown ويحولها إلى صفحات wiki. بدون أطر عمل، بدون ORM، فقط ملفات ونصوص.

التوسع: ClickHouse

عندما يكون هناك وكيل واحد فقط، يعمل تخزين الملفات بشكل مثالي. لكن إذا كنت بحاجة إلى دعم 100+ مستخدم في نفس الوقت، تحتاج إلى قاعدة بيانات حقيقية. هنا يأتي دور ClickHouse 24.x. المزايا الرئيسية:

• البحث المتجه عبر دالة `cosineDistance()` — بحث سريع عن الذكريات المتشابهة دلالياً
• البحث النصي مع فهرس `tokenbf_v1` — بحث نصي كامل عبر الذاكرة
• التقسيم حسب user_id — عزل بيانات المستخدم المدمج في قاعدة البيانات
• TTL للحذف التلقائي — يتم حذف السجلات القديمة بدون تدخل يدوي

يقوم ClickHouse بتحليل البحث عبر ملايين السجلات في أجزاء من الثانية. لذاكرة الوكيل، هذا أكثر من كافٍ.

ماذا يعني هذا

الخلاصة الرئيسية: لا تبدأ بالتوسع. حل المشكلة بطريقة بسيطة (ملفات، markdown، 300 سطر من الكود)، ثم وسّع فقط إذا لزم الأمر. أظهر نيكولاي أن أفضل مسار هندسي هو من التعقيد إلى البساطة، وليس العكس.