الانتقال إلى المحتوى الرئيسي

نظرة عامة

يوفر CrewAI نظام ذاكرة موحد — فئة Memory واحدة تستبدل أنواع الذاكرة المنفصلة (قصيرة المدى، طويلة المدى، ذاكرة الكيانات، والخارجية) بواجهة برمجة تطبيقات ذكية واحدة. تستخدم الذاكرة LLM لتحليل المحتوى عند الحفظ (استنتاج النطاق والفئات والأهمية) وتدعم الاسترجاع متعدد العمق مع تسجيل مركب يمزج بين التشابه الدلالي والحداثة والأهمية. يمكنك استخدام الذاكرة بأربع طرق: مستقلة (سكربتات، دفاتر ملاحظات)، مع فرق Crew، مع Agents، أو داخل التدفقات.

البدء السريع

أربع طرق لاستخدام الذاكرة

مستقلة

استخدم الذاكرة في السكربتات ودفاتر الملاحظات وأدوات سطر الأوامر أو كقاعدة معرفة مستقلة — لا حاجة لوكلاء أو فرق Crew.

مع فرق Crew

مرّر memory=True للإعدادات الافتراضية، أو مرّر مثيل Memory مُعدّ للسلوك المخصص.
عند استخدام memory=True، ينشئ الفريق مثيل Memory() افتراضيًا ويمرر إعداد embedder الخاص بالفريق تلقائيًا. يشترك جميع الوكلاء في الفريق في ذاكرة الفريق ما لم يكن لدى الوكيل ذاكرته الخاصة. بعد كل مهمة، يستخرج الفريق تلقائيًا حقائق منفصلة من مخرجات المهمة ويخزّنها. قبل كل مهمة، يسترجع الوكيل السياق ذا الصلة من الذاكرة ويحقنه في موجّه المهمة.

مع Agents

يمكن للوكلاء استخدام ذاكرة الفريق المشتركة (افتراضيًا) أو تلقي عرض محدد النطاق للسياق الخاص.
يمنح هذا النمط الباحث نتائج خاصة بينما يقرأ الكاتب من ذاكرة الفريق المشتركة.

مع التدفقات

كل تدفق يحتوي على ذاكرة مدمجة. استخدم self.remember() و self.recall() و self.extract_memories() داخل أي دالة تدفق.
انظر وثائق التدفقات لمزيد من المعلومات حول الذاكرة في التدفقات.

النطاقات الهرمية

ما هي النطاقات

يتم تنظيم الذكريات في شجرة هرمية من النطاقات، مشابهة لنظام الملفات. كل نطاق هو مسار مثل / أو /project/alpha أو /agent/researcher/findings.
توفر النطاقات ذاكرة تعتمد على السياق — عند الاسترجاع ضمن نطاق، تبحث فقط في ذلك الفرع من الشجرة، مما يحسّن كلًا من الدقة والأداء.

كيف يعمل استنتاج النطاق

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

تصوير شجرة النطاقات

MemoryScope: عروض الأشجار الفرعية

يقيّد MemoryScope جميع العمليات على فرع من الشجرة. يمكن للوكيل أو الكود الذي يستخدمه الرؤية والكتابة فقط ضمن تلك الشجرة الفرعية.

أفضل الممارسات لتصميم النطاقات

  • ابدأ بشكل مسطح، ودع LLM ينظّم. لا تبالغ في هندسة تسلسل النطاقات مسبقًا. ابدأ بـ memory.remember(content) ودع استنتاج النطاق في LLM ينشئ الهيكل مع تراكم المحتوى.
  • استخدم أنماط /{entity_type}/{identifier}. تنشأ التسلسلات الطبيعية من أنماط مثل /project/alpha و /agent/researcher و /company/engineering و /customer/acme-corp.
  • حدد النطاق حسب الاهتمام، وليس حسب نوع البيانات. استخدم /project/alpha/decisions بدلاً من /decisions/project/alpha. هذا يبقي المحتوى ذا الصلة معًا.
  • حافظ على العمق ضحلًا (2-3 مستويات). النطاقات المتداخلة بعمق تصبح متفرقة جدًا. /project/alpha/architecture جيد؛ /project/alpha/architecture/decisions/databases/postgresql عميق جدًا.
  • استخدم النطاقات الصريحة عندما تعرف، ودع LLM يستنتج عندما لا تعرف. إذا كنت تخزّن قرار مشروع معروف، مرّر scope="/project/alpha/decisions". إذا كنت تخزّن مخرجات وكيل حرة الشكل، اترك النطاق ودع LLM يحدده.

أمثلة حالات الاستخدام

فريق متعدد المشاريع:
سياق خاص لكل وكيل مع معرفة مشتركة:
دعم العملاء (سياق لكل عميل):

شرائح الذاكرة

ما هي الشرائح

MemorySlice هو عرض عبر نطاقات متعددة، ربما متباعدة. على عكس النطاق (الذي يقيّد على شجرة فرعية واحدة)، تتيح لك الشريحة الاسترجاع من عدة فروع في وقت واحد.

متى تستخدم الشرائح مقابل النطاقات

  • النطاق: استخدمه عندما يجب تقييد وكيل أو كتلة كود على شجرة فرعية واحدة. مثال: وكيل يرى فقط /agent/researcher.
  • الشريحة: استخدمها عندما تحتاج إلى دمج السياق من عدة فروع. مثال: وكيل يقرأ من نطاقه الخاص بالإضافة إلى معرفة الشركة المشتركة.

شرائح القراءة فقط

النمط الأكثر شيوعًا: منح وكيل إمكانية القراءة من فروع متعددة دون السماح له بالكتابة في المناطق المشتركة.

شرائح القراءة والكتابة

عند تعطيل القراءة فقط، يمكنك الكتابة في أي من النطاقات المضمّنة، لكن يجب تحديد النطاق صراحة.

التسجيل المركب

يتم ترتيب نتائج الاسترجاع بواسطة مزيج مرجّح من ثلاث إشارات:
حيث:
  • similarity = 1 / (1 + distance) من فهرس المتجهات (0 إلى 1)
  • decay = 0.5^(age_days / half_life_days) — اضمحلال أُسي (1.0 لليوم، 0.5 عند نصف العمر)
  • importance = درجة أهمية السجل (0 إلى 1)، يتم تعيينها وقت الترميز
قم بإعدادها مباشرة على منشئ Memory:
يتضمن كل MemoryMatch قائمة match_reasons حتى تتمكن من رؤية سبب ترتيب نتيجة معينة في موضعها (مثل ["semantic", "recency", "importance"]).

طبقة تحليل LLM

تستخدم الذاكرة LLM بثلاث طرق:
  1. عند الحفظ — عندما تحذف النطاق أو الفئات أو الأهمية، يحلل LLM المحتوى ويقترح النطاق والفئات والأهمية والبيانات الوصفية (الكيانات والتواريخ والموضوعات).
  2. عند الاسترجاع — للاسترجاع العميق/التلقائي، يحلل LLM الاستعلام (الكلمات المفتاحية، تلميحات الوقت، النطاقات المقترحة، التعقيد) لتوجيه الاسترجاع.
  3. استخراج الذكرياتextract_memories(content) يقسم النص الخام (مثل مخرجات المهمة) إلى عبارات ذاكرة منفصلة. يستخدم الوكلاء هذا قبل استدعاء remember() على كل عبارة حتى يتم تخزين حقائق ذرية بدلاً من كتلة كبيرة واحدة.
جميع التحليلات تتدهور بسلاسة عند فشل LLM — انظر سلوك الفشل.

توحيد الذاكرة

عند حفظ محتوى جديد، يتحقق خط أنابيب الترميز تلقائيًا من وجود سجلات مماثلة في التخزين. إذا كان التشابه أعلى من consolidation_threshold (الافتراضي 0.85)، يقرر LLM ما يجب فعله:
  • keep — السجل الحالي لا يزال دقيقًا وغير مكرر.
  • update — يجب تحديث السجل الحالي بمعلومات جديدة (يوفر LLM المحتوى المدمج).
  • delete — السجل الحالي قديم أو تم استبداله أو تناقضه.
  • insert_new — ما إذا كان يجب إدراج المحتوى الجديد أيضًا كسجل منفصل.
هذا يمنع تراكم النسخ المكررة. على سبيل المثال، إذا حفظت “CrewAI ensures reliable operation” ثلاث مرات، يتعرف التوحيد على النسخ المكررة ويحتفظ بسجل واحد فقط.

إزالة التكرار داخل الدفعة

عند استخدام remember_many()، تتم مقارنة العناصر داخل نفس الدفعة مع بعضها البعض قبل الوصول إلى التخزين. إذا كان تشابه جيب التمام >= batch_dedup_threshold (الافتراضي 0.98)، يتم إسقاط العنصر الأحدث بصمت. هذا يلتقط النسخ المكررة الدقيقة أو شبه الدقيقة داخل دفعة واحدة دون أي استدعاءات LLM (رياضيات متجهات خالصة).

الحفظ غير الحاجب

remember_many() غير حاجب — يقدم خط أنابيب الترميز إلى خيط خلفي ويعود فورًا. هذا يعني أن الوكيل يمكنه المتابعة إلى المهمة التالية بينما يتم حفظ الذكريات.

حاجز القراءة

كل استدعاء recall() يستدعي تلقائيًا drain_writes() قبل البحث، مما يضمن أن الاستعلام يرى دائمًا أحدث السجلات المستمرة. هذا شفاف — لا تحتاج أبدًا إلى التفكير فيه.

إيقاف الفريق

عند انتهاء الفريق، يستنزف kickoff() جميع عمليات حفظ الذاكرة المعلقة في كتلة finally الخاصة به، لذا لا تُفقد أي عمليات حفظ حتى لو اكتمل الفريق بينما عمليات الحفظ الخلفية قيد التنفيذ.

الاستخدام المستقل

للسكربتات أو دفاتر الملاحظات حيث لا توجد دورة حياة فريق، استدعِ drain_writes() أو close() صراحة:

المصدر والخصوصية

يمكن لكل سجل ذاكرة أن يحمل علامة source لتتبع المصدر وعلامة private للتحكم في الوصول.

تتبع المصدر

يحدد معامل source من أين جاءت الذاكرة:

الذكريات الخاصة

الذكريات الخاصة مرئية فقط للاسترجاع عندما يتطابق source:
هذا مفيد بشكل خاص في النشرات متعددة المستخدمين أو المؤسسية حيث يجب عزل ذكريات المستخدمين المختلفين.

RecallFlow (الاسترجاع العميق)

يدعم recall() عمقين:
  • depth="shallow" — بحث متجهي مباشر مع تسجيل مركب. سريع (~200 مللي ثانية)، بدون استدعاءات LLM.
  • depth="deep" (افتراضي) — يشغل RecallFlow متعدد الخطوات: تحليل الاستعلام، اختيار النطاق، بحث متجهي متوازٍ، توجيه قائم على الثقة، واستكشاف متكرر اختياري عندما تكون الثقة منخفضة.
تخطي LLM الذكي: الاستعلامات الأقصر من query_analysis_threshold (الافتراضي 200 حرف) تتخطى تحليل LLM للاستعلام بالكامل، حتى في الوضع العميق. الاستعلامات القصيرة مثل “ما قاعدة البيانات التي نستخدمها؟” هي بالفعل عبارات بحث جيدة — تحليل LLM يضيف قيمة قليلة. هذا يوفر ~1-3 ثوانٍ لكل استرجاع للاستعلامات القصيرة النموذجية. فقط الاستعلامات الأطول (مثل أوصاف المهام الكاملة) تمر عبر تقطير LLM إلى استعلامات فرعية مستهدفة.
عتبات الثقة التي تتحكم في موجّه RecallFlow قابلة للإعداد:

إعداد المُضمِّن

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

التمرير إلى Memory مباشرة

عبر إعداد مُضمِّن Crew

عند استخدام memory=True، يتم تمرير إعداد embedder الخاص بالفريق:

أمثلة المزودين

مرجع المزودين

إعداد LLM

تستخدم الذاكرة LLM لتحليل الحفظ (استنتاج النطاق والفئات والأهمية)، وقرارات التوحيد، وتحليل استعلام الاسترجاع العميق. يمكنك إعداد النموذج المُستخدم.
يتم تهيئة LLM بشكل كسول — يتم إنشاؤه فقط عند الحاجة لأول مرة. هذا يعني أن Memory() لا يفشل أبدًا في وقت الإنشاء، حتى لو لم تكن مفاتيح API مُعيّنة. تظهر الأخطاء فقط عند استدعاء LLM فعليًا (مثلاً عند الحفظ بدون نطاق/فئات صريحة، أو أثناء الاسترجاع العميق). للتشغيل المحلي/الخاص بالكامل، استخدم نموذجًا محليًا لكل من LLM والمُضمِّن:

واجهة التخزين

  • الافتراضي: LanceDB، مخزّن تحت ./.crewai/memory (أو $CREWAI_STORAGE_DIR/memory إذا تم تعيين متغير البيئة، أو المسار الذي تمرره كـ storage="path/to/dir").
  • واجهة مخصصة: نفّذ بروتوكول StorageBackend (انظر crewai.memory.storage.backend) ومرّر مثيلًا إلى Memory(storage=your_backend).

الاستكشاف

فحص التسلسل الهرمي للنطاقات والفئات والسجلات:

سلوك الفشل

إذا فشل LLM أثناء التحليل (خطأ شبكة، حد معدل، استجابة غير صالحة)، تتدهور الذاكرة بسلاسة:
  • تحليل الحفظ — يتم تسجيل تحذير ولا يزال يتم تخزين الذاكرة مع النطاق الافتراضي /، فئات فارغة، وأهمية 0.5.
  • استخراج الذكريات — يتم تخزين المحتوى الكامل كذاكرة واحدة حتى لا يُفقد شيء.
  • تحليل الاستعلام — يتراجع الاسترجاع إلى اختيار نطاق بسيط وبحث متجهي حتى تستمر في الحصول على نتائج.
لا يتم رفع أي استثناء لفشل التحليل هذه؛ فقط فشل التخزين أو المُضمِّن سيرفع استثناءً.

ملاحظة حول الخصوصية

يتم إرسال محتوى الذاكرة إلى LLM المُعدّ للتحليل (النطاق/الفئات/الأهمية عند الحفظ، تحليل الاستعلام والاسترجاع العميق الاختياري). للبيانات الحساسة، استخدم LLM محليًا (مثل Ollama) أو تأكد من أن مزودك يلبي متطلبات الامتثال الخاصة بك.

أحداث الذاكرة

جميع عمليات الذاكرة تُصدر أحداثًا مع source_type="unified_memory". يمكنك الاستماع للتوقيت والأخطاء والمحتوى. مثال: مراقبة وقت الاستعلام:

استكشاف المشاكل

الذاكرة لا تستمر؟
  • تأكد من أن مسار التخزين قابل للكتابة (الافتراضي ./.crewai/memory). مرّر storage="./your_path" لاستخدام مجلد مختلف، أو عيّن متغير البيئة CREWAI_STORAGE_DIR.
  • عند استخدام فريق، تأكد من تعيين memory=True أو memory=Memory(...).
الاسترجاع بطيء؟
  • استخدم depth="shallow" لسياق الوكيل الروتيني. احتفظ بـ depth="deep" للاستعلامات المعقدة.
  • زد query_analysis_threshold لتخطي تحليل LLM لمزيد من الاستعلامات.
أخطاء تحليل LLM في السجلات؟
  • لا تزال الذاكرة تحفظ/تسترجع بإعدادات افتراضية آمنة. تحقق من مفاتيح API وحدود المعدل وتوفر النموذج إذا كنت تريد تحليل LLM كاملاً.
أخطاء حفظ خلفية في السجلات؟
  • عمليات حفظ الذاكرة تعمل في خيط خلفي. تُصدر الأخطاء كـ MemorySaveFailedEvent لكنها لا تعطل الوكيل. تحقق من السجلات للسبب الجذري (عادة مشاكل اتصال LLM أو المُضمِّن).
تعارضات الكتابة المتزامنة؟
  • عمليات LanceDB مُتسلسلة بقفل مشترك وتُعاد تلقائيًا عند التعارض. هذا يتعامل مع مثيلات Memory المتعددة التي تشير إلى نفس قاعدة البيانات (مثل ذاكرة وكيل + ذاكرة فريق). لا حاجة لإجراء.
تصفح الذاكرة من الطرفية:
إعادة تعيين الذاكرة (مثلاً للاختبارات):

مرجع الإعداد

جميع الإعدادات تُمرر كمعاملات كلمة مفتاحية إلى Memory(...). كل معامل له قيمة افتراضية معقولة.