كيف تعمل ذاكرة الوكيل فعليًا
اسأل روبوت محادثة السؤال نفسه مرتين في جلستين مختلفتين، وسيجيبك كغريب في كلتا المرتين. هذا ليس خللًا — إنه السلوك الافتراضي. النموذج اللغوي الخام لا يملك ذاكرة بين الاستدعاءات. كل ما "يتذكّره" داخل محادثة واحدة يعيش في نافذة السياق، وعندما تنتهي تلك المحادثة يزول.
الذاكرة هي الآلية التي تركّبها فوق ذلك لإصلاح هذه المشكلة: الأنظمة التي تقرر ما الذي ينبغي على الوكيل حمله معه إلى المستقبل، وأين يخزّنه، وكيف يستعيد القطعة الصحيحة في اللحظة الصحيحة. في 2026 لم تعد هذه مهمة جانبية بل أصبحت جزءًا أساسيًا من تصميم الوكيل، لها معاييرها القياسية وأطر عملها وأدبيات بحثية حقيقية. هذه الصفحة هي الخريطة.
- فهم لماذا نافذة السياق ليست ذاكرة — وأين يقع الحد الفاصل فعليًا
- التمييز بين أنواع الذاكرة الأربعة التي يستخدمها الوكلاء: العاملة والحدثية والدلالية والإجرائية
- مقارنة أنماط التخزين الأربعة: السياق الكامل، vector/RAG، الرسم البياني المعرفي، والضغط/التلخيص
- رؤية كيف ينفّذ كل من Claude وChatGPT وGemini الذاكرة اليوم
- اختيار نهج ذاكرة لوكيلك الخاص دون الإفراط في الهندسة
الفكرة الوحيدة التي يجب التمسك بها: السياق ≠ الذاكرة
أشيع خلط هو معاملة نافذة السياق الكبيرة على أنها "ذاكرة". إنها ليست كذلك. نافذة السياق هي مساحة عمل لدور واحد — تُملأ من الصفر في كل استدعاء، وهي محدودة، ومكلفة. كما يتدهور الانتباه عبرها (تأثير "الضياع في المنتصف" الذي تناولناه في هندسة السياق).
الذاكرة مختلفة بثلاث طرق:
| نافذة السياق | الذاكرة | |
|---|---|---|
| مدة الحياة | طلب واحد | عبر الجلسات، أيامًا، إلى الأبد |
| الحجم | سقف token ثابت | غير محدود فعليًا (مخزن خارجي) |
| التكلفة | تُدفع في كل دور | تُدفع مرة واحدة عند الكتابة؛ رخيصة عند الإحالة |
| الوصول | كل شيء، دائمًا في المشهد | انتقائي — استرجاع ما هو ذو صلة فقط |
اللعبة كلها في ذاكرة الوكيل هي نقل المعلومة الصحيحة بين هذين الاثنين: اكتب الحقائق الدائمة خارج النافذة كي لا تدفع ثمنها في كل دور، ثم اسحبها إليها فقط عندما تحتاج إليها هذه الخطوة تحديدًا. أتقِن هذا التدفق ويستطيع الوكيل العمل لأسابيع على نافذة سياق لا تحمل في أي وقت سوى بضعة آلاف من الرموز ذات الصلة.
الأنواع الأربعة للذاكرة
باستعارة (فضفاضة) من العلوم الإدراكية، تقاربت منظومة الوكلاء في 2026 على أربع فئات. نادرًا ما تحتاج الأربعة كلها — لكن تسميتها يمنعك من بناء كتلة واحدة تفعل كل شيء بشكل سيئ.
- ما هو موجود في نافذة السياق الآن — المهمة الحالية، الأدوار القليلة الأخيرة، نتائج الأدوات من هذه الخطوة. متطايرة بحكم التصميم. هذه هي المسودة، لا الأرشيف. إدارتها بشكل جيد هي هندسة السياق؛ ليست استمرارية.
- أشياء محددة حدثت، مع طابع زمني. 'يوم الثلاثاء قال المستخدم إن الدفع معطّل؛ يوم الأربعاء وضع الدعم علامة على أنه تمّ حلّه.' الذاكرة الحدثية زمنية بطبيعتها — الترتيب والزمن يهمّان. إنها ما يتيح للوكيل أن يستدل على تاريخٍ لا على لقطة.
- حقائق وتفضيلات دائمة، مجرّدة من متى تعلمتها. 'يفضّل المستخدم الوحدات المترية.' 'هذا العميل على الخطة المؤسسية.' الذاكرة الدلالية غير زمنية إلى حد كبير — تمثّل ما يعتقد الوكيل أنه صحيح حاليًا، لا الحدث الذي اكتشفه فيه.
- كيفية القيام بشيء ما — مهارات وسير عمل وروتينات مُتعلَّمة قابلة لإعادة الاستخدام. الأقل نضجًا بين الأربعة عمليًا. في أدوات مثل Claude Code، تعيش هذه غالبًا كملفات تعليمات (CLAUDE.md) ومهارات قابلة لإعادة الاستخدام بدلًا من مخزن تلقائي.
اختبار مفيد: إذا كنت ستجيب بـ "متى حدث ذلك؟" فهي حدثية؛ وإذا كنت ستجيب بـ "ما الصحيح؟" فهي دلالية؛ وإذا كنت ستجيب بـ "إليك الطريقة" فهي إجرائية؛ وإذا كانت تهمّ فقط للثواني القليلة القادمة، فهي ذاكرة عاملة ولا تحتاج إلى الإبقاء عليها إطلاقًا.
أنماط التخزين الأربعة
بمجرد أن تعرف ماذا تتذكّر، تختار كيف تخزّنه وتسترجعه. هناك أربعة أنماط سائدة، مرتبة تقريبًا بحسب التعقيد. معظم الأنظمة الحقيقية تجمع بين اثنين أو ثلاثة.
1. السياق الكامل (احشُر كل شيء)
احتفظ بالتاريخ بأكمله وأعد إرساله في كل دور. صفر بنية تحتية، استرجاع مثالي — إلى أن تصطدم بسقف الرموز، أو منحنى التكلفة، أو "الضياع في المنتصف". مناسب للمساعدين القصار؛ طريق مسدود لأي شيء طويل الأمد. هذا هو خط الأساس الذي يحسّنه كل نمط آخر.
2. ذاكرة Vector / RAG
اكتب كل ذكرى كـ embedding في قاعدة بيانات vector؛ وعند الاستعلام، حوّل الدور الحالي إلى embedding واسترجع أعلى-k من الذكريات الأكثر تشابهًا. هذه هي التوليد المعزَّز بالاسترجاع موجّهًا إلى تاريخ المحادثة بدلًا من المستندات. رخيصة وقابلة للتوسع، والافتراضية للاسترجاع الدلالي للحقائق والتفضيلات.
نقطة ضعفها: التشابه ≠ الصلة بالنسبة للأسئلة الزمنية أو متعددة القفزات. "ماذا قرّرنا بعد أن قُطعت الميزانية؟" سؤال ترتيبي، وتشابه جيب التمام لا يملك أي إحساس بالزمن أو بتسلسل حقيقتين معًا.
3. ذاكرة الرسم البياني المعرفي
خزّن الذكريات كـ كيانات وعلاقات — عقد وحواف، غالبًا مع طوابع زمنية على الحواف. للإجابة عن سؤال، تجتاز الرسم البياني بدلًا من المطابقة التقريبية للـ vectors. هذا ما يجعل الاستدلال متعدد القفزات والزمني قابلًا للحل ("من الذي حلّ محل الشخص الذي كان يملك الحساب الذي اشتكى منه المستخدم؟"). أطر مثل Zep/Graphiti بنت طرحها كله حول الرسوم البيانية المعرفية الزمنية. الكلفة هندسة حقيقية: الاستخراج، وحلّ الكيانات، ومنع الرسم البياني من التعفّن.
4. الضغط والتلخيص
اضغط دوريًا التاريخ الجاري إلى ملخّص مُقطّر وتابع منه — مقايضًا الاسترجاع الحرفي بنافذة أصغر وأرخص. هذا ما يفعله /compact في Claude Code، وما يفعله "التلخيص التلقائي" في كثير من منتجات المحادثة. إنه أرخص أشكال الذاكرة طويلة الأمد، وغالبًا أول شكل تحتاجه فعليًا. خطره: يُسقط الملخّص بصمت التفصيلة الوحيدة التي احتجتها. انظر حزم الوكيل طويلة التشغيل لمعرفة كيف يتجلّى ذلك عبر تشغيلات تدوم ساعات.
تُطبّق الأنظمة الحقيقية هذه على طبقات. تكديس شائع في 2026: الضغط للمحادثة الجارية، وvector للحقائق الدلالية، ورسم بياني فوقها فقط حين تظهر الاستعلامات الزمنية/متعددة القفزات فعليًا في حركة مرورك. لا تبنِ الرسم البياني حتى تشعر بالألم الذي يحلّه الرسم البياني.
كيف يفعلها الثلاثة الكبار
كل مساعد رئيسي الآن يشحن نوعًا ما من الذاكرة. إنها ليست الشيء نفسه، والفروق تهمّ.
| المنتج | ماذا يتذكّر | كيف يعمل (تقريبًا) |
|---|---|---|
| Claude | طبقتان: ذاكرة على مستوى التطبيق لتفضيلاتك، وأداة ذاكرة موجّهة للمطوّرين للوكلاء. | ذاكرة تطبيق Claude تخزّن الحقائق عبر المحادثات؛ وأداة الذاكرة إضافةً إلى تحرير السياق في الـ API تتيح للوكيل كتابة ملاحظات إلى مخزن من جهة العميل وتقليم نتائج الأدوات القديمة تلقائيًا للنجاة في التشغيلات الطويلة. |
| ChatGPT | "الذكريات المحفوظة" (حقائق صريحة) إضافةً إلى الإحالة إلى محادثاتك السابقة. | مزيج من حقائق ذكرها المستخدم وتفضيلات مُستخرجة تلقائيًا، تُحقن في سياق النظام في الأدوار اللاحقة. قابلة للتحرير والتبديل من قِبل المستخدم. |
| Gemini | سياق شخصي مستمدّ من محادثاتك، واختياريًا، من سطح حساب Google الأوسع. | يستحضر تفاصيل من محادثات سابقة ويمكنه التخصيص باستخدام سياق الحساب، مع خضوعه لضوابط الخصوصية لديك. |
خلاصتان. أولًا، ذاكرة المستهلك دلالية في معظمها — تفضيلات وحقائق — لا إعادة تشغيل حدثية كاملة. ثانيًا، إذا كنت تبني وكيلًا، فذاكرة المنتج المدمجة ليست نظام ذاكرتك؛ أنت تملك تلك الطبقة، مستخدمًا أوليات مثل أداة ذاكرة Claude أو إطارًا خارجيًا.
حوّل نموذجًا خامًا إلى وكيل يدوّن الملاحظات (أرخص ذاكرة حقيقية)
You have a file called MEMORY.md that persists between our sessions. At the END of each session, append any durable facts worth keeping: - my stable preferences (tools, formats, style) - decisions we made and WHY - open threads to resume next time At the START of each session, read MEMORY.md first and use it. Keep it under 30 lines — when it grows past that, consolidate and delete anything stale. Never store secrets or credentials.
هذا النمط الواحد — اكتب ملاحظات دائمة إلى ملف خارجي، اقرأها مجددًا في المرة القادمة — هو الـ 80/20 لذاكرة الوكيل. معظم آلية الأطر أدناه هي نسخة أكثر تلقائية وأكثر قابلية للتوسع من هذا بالضبط.
قياس الذاكرة: المعيار القياسي LoCoMo
لا يمكنك تحسين ما لا تستطيع قياسه، وكانت الذاكرة صعبة القياس إلى أن وصلت المعايير القياسية. الأكثر استشهادًا هو LoCoMo ("Evaluating Very Long-Term Conversational Memory of LLM Agents"): محادثات طويلة جدًا متعددة الجلسات — مئات الأدوار عبر عشرات الجلسات — مع أزواج سؤال-جواب من خمسة أنواع: أحادية القفزة، متعددة القفزات (عبر الجلسات)، الاستدلال الزمني، مفتوحة المجال، والعدائية.
ما يكشفه LoCoMo هو النمط الذي ينبغي التصميم حوله: الأنظمة تبلي حسنًا في الاسترجاع الواقعي أحادي القفزة وتنهار في الأسئلة الزمنية ومتعددة القفزات. وضع الفشل هذا هو بالضبط سبب وجود ذاكرة الرسم البياني المعرفي — إنها النمط الذي يرفع هاتين الفئتين أكثر من غيره. عندما تقيّم ذاكرة وكيلك الخاص، رجّح حالات متعددة القفزات والزمنية بشدة؛ فالاسترجاع أحادي القفزة يُجمّل كل شيء تقريبًا.
اختيار نهج دون إفراط في البناء
- لا تفعل شيئًا. الذاكرة العاملة (نافذة السياق) كافية. إضافة مخزن ذاكرة هنا محض عبء زائد.
- ابدأ بتدوين الملاحظات إلى ملف خارجي، أو بالذاكرة المدمجة في المنتج. هذا يغطي معظم احتياجات 'تذكّر تفضيلاتي' بتكلفة شبه معدومة.
- أضف الضغط/التلخيص. أبقِ على الحقائق الحاملة للثقل، وأسقِط السرد التفصيلي. هنا يعيش الوكلاء طويلو التشغيل.
- أضف ذاكرة vector/RAG. استرجع أعلى-k من الذكريات ذات الصلة لكل دور بدلًا من إعادة إرسال كل شيء.
- الآن فقط امدد يدك إلى رسم بياني معرفي — أو إطار مُدار (Mem0, Letta, Zep, LangMem) يمنحك واحدًا دون أن تصنع الاستخراج وحلّ الكيانات يدويًا.
الفخ هو البدء من الخطوة الخامسة. ذاكرة الرسم البياني مبهرة في العروض التوضيحية ومكلفة في الإنتاج. اصعد السلّم؛ وتوقف عند أول درجة تحلّ مشكلتك الفعلية.
Check yourself
0/4الخلاصة
الذاكرة ليست ميزة واحدة تُشغّلها — إنها تدفق تصمّمه: ما الذي يغادر النافذة، وأين يُخزّن، وكيف يعود. سمِّ أنواع الذاكرة الأربعة كي لا تبني كتلة واحدة لها جميعًا. ابدأ من أرخص نمط تخزين يحلّ مشكلتك واصعد فقط عندما تشعر بألم النمط التالي. وقِس بحالات زمنية ومتعددة القفزات، لأن الاسترجاع أحادي القفزة يجعل كل شيء يبدو أذكى مما هو عليه.
الذاكرة هي النصف الآخر من هندسة السياق: هندسة السياق تقرر ما الذي يملأ النافذة هذا الدور؛ والذاكرة تقرر ما الذي ينجو بين الأدوار. معًا هما ما يفصل روبوت المحادثة عن وكيل يتحسّن كلما طال عملك معه.
المصادر والقراءة الإضافية
- Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo) — المعيار القياسي الأساسي؛ صفحة المشروع.
- Effective context engineering for AI agents — Anthropic حول الضغط وتدوين الملاحظات والاسترجاع في الوقت المناسب.
- Claude memory tool & context editing docs — الأولية الموجّهة للمطوّرين.
- Agent Memory Techniques — 30 دفتر ملاحظات قابلة للتشغيل تغطي مخازن المحادثة المؤقتة، ومخازن vector، والرسوم البيانية المعرفية، والذاكرة الحدثية/الدلالية، وMem0 وLetta وZep وGraphiti وLoCoMo.
- The State of AI Agent Memory 2026 — تقرير مورّد حول معماريات الذاكرة والمعايير القياسية (اقرأه بحذر الأرقام المبلَّغة ذاتيًا المعتاد).
- ذات صلة على AILmanac: هندسة السياق · حزم الوكيل طويلة التشغيل · RAG · ذاكرة تطبيق Claude · الذاكرة وتحرير السياق (API).