الدرس 20: الذاكرة الدائمة — الذاكرة طويلة المدى

هذا جزء من سلسلة دروس هيرميس إيجنت الرسمية. عرض كل الدروس

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

ماذا تفعل الذاكرة الدائمة؟

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

الخطوة 1: تعرّف على ملفي الذاكرة

ذاكرة الوكيل موجودة في ملفين، مخزّنين في ~/.hermes/memories/:

الملف	ماذا يخزّن؟	الحد الأقصى للحجم
MEMORY.md	ملاحظات الوكيل الشخصية — حقائق عن البيئة، اتفاقيات، أشياء تعلّمها	2,200 حرف (~800 رمز)
USER.md	ملفك الشخصي — التفضيلات، أسلوب التواصل، التوقعات	1,375 حرفًا (~500 رمز)

الحدود مقصودة. إنها تُجبر الوكيل على الاحتفاظ فقط بما هو مهم، مثل دفتر ملاحظات منظم بدلًا من درج فوضوي.

الخطوة 2: شاهد كيف تظهر الذاكرة في التلقين

في بداية كل جلسة، يقوم الوكيل بتحميل الملفين ويعرضهما كـلقطة مجمّدة في تلقين النظام الخاص به. إليك مثالًا لما “يراه” الوكيل:

══════════════════════════════════════════════
الذاكرة (ملاحظاتك الشخصية) [67% — 1,474/2,200 حرف]
══════════════════════════════════════════════
مشروع المستخدم هو خدمة ويب بلغة Rust في ~/code/myapi باستخدام Axum + SQLx
§
هذا الجهاز يعمل بنظام Ubuntu 22.04، ومثبّت عليه Docker و Podman
§
المستخدم يفضّل الردود المختصرة، ولا يحب الشرح المطوّل

لاحظ التفاصيل:

ترويسة توضح نوع المخزن (ذاكرة أو ملف المستخدم)
نسبة الاستخدام وعدد الأحرف — حتى يعرف الوكيل مقدار المساحة المتبقية
الإدخالات مفصولة بعلامة § (علامة القسم)
يمكن أن تكون الإدخالات متعددة الأسطر

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

الخطوة 3: الوكيل يدير ذاكرته بنفسه

يستخدم الوكيل أداة تسمى memory بثلاثة إجراءات:

add — إضافة إدخال ذاكرة جديد
replace — استبدال إدخال موجود (يستخدم مطابقة النص الجزئي مع old_text)
remove — حذف إدخال لم يعد ذا صلة (يستخدم أيضًا old_text)

لا يوجد إجراء read لأن الذاكرة محقونة بالفعل في التلقين — الوكيل يراها دائمًا.

إليك مثال بسيط لكيفية استخدام الوكيل للأداة:

memory action=add content="المستخدم يفضّل النقاط النقطية على الفقرات"

أو استبدال تفضيل قديم:

memory action=replace old_text="المستخدم يفضّل الردود المختصرة" new_text="المستخدم يفضّل إجابات من سطر واحد مع رموز تعبيرية"

الخطوة 4: ماذا يحدث عندما تمتلئ الذاكرة؟

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

لاحظ أيضًا: replace مقيد بالحد أيضًا. استبدال إدخال بآخر أطول يمكن أن يتجاوز الحد، لذا يجب تقصير المحتوى الجديد (أو حذف إدخال آخر) ليتناسب.

الخطوة 5: وكيل واحد لكل مجلد هيرميس الرئيسي (مهم!)

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

الخلاصة

الذاكرة الدائمة تمنح هيرميس إيجنت طريقة بسيطة ومحدودة لتذكّرك عبر الجلسات. ملفان صغيران — MEMORY.md و USER.md — يحملان ملاحظات منسقة، تُحقن كلقطة مجمّدة في بداية الجلسة. الوكيل يدير هذه الملفات بنفسه باستخدام أداة memory، وحدود الأحرف تُبقي الأمور مركّزة. فقط تذكر: وكيل واحد لكل مجلد رئيسي، واللقطة تتحدث فقط في بداية الجلسة.