مايكروسوفت وهواوي تطلقان أنظمة ذاكرة متنافسة للوكلاء الذكيين (2026)
٢١ يوليو ٢٠٢٦

ملخص: بفارق ثمان وأربعين ساعة، قدم مختبران مختلفان تماماً إجابات جديدة لنفس المشكلة — عملاء الذكاء الاصطناعي (AI agents) الذين يفقدون كل شيء بمجرد انتهاء الجلسة.
أعلنت Microsoft Research عن Memora في 29 يونيو 2026: وهي بنية ذاكرة مراجعة من قبل النظراء، نُشرت في ICML 2026، وتدعي تحقيق نتائج متطورة مع تقليل توكنات السياق (context tokens) بنسبة تصل إلى 98%.1 وفي 1 يوليو، أطلق مجتمع openJiuwen مفتوح المصدر التابع لشركة Huawei نظام JiuwenMemory، وهو مكدس ذاكرة مكون من أربع طبقات مع دورة دمج "حلم" (Dreaming) غير تقليدية مستوحاة من أبحاث النوم.2
كلاهما يستهدف نفس نمط الفشل. ولا يعد أي منهما منتجاً نهائياً، ويحمل أحدهما تحذيراً قانونياً حقيقياً مرتبطاً ببلد المنشأ، كما أن مجال ذاكرة العملاء بالكامل لديه عادة موثقة من الأرقام المبلغ عنها ذاتياً والتي لا تصمد أمام الاختبارات المستقلة.
في سطر واحد: أطلقت Microsoft و Huawei كلاً منهما بنية ذاكرة جديدة لعملاء الذكاء الاصطناعي في نفس الأسبوع — Memora مراجعة من قبل النظراء ومتبناة بشكل محدود، و JiuwenMemory طموحة من الناحية الهيكلية ولكنها غير مؤكدة وتحمل تحذيراً بشأن البيانات وفقاً للقانون الصيني، ولا ينبغي الوثوق بأي منهما بناءً على أرقام المقارنة المرجعية وحدها.
ما ستتعلمه
- لماذا أصبحت "ذاكرة العميل" تخصصاً هندسياً قائماً بذاته في عام 2026، متميزاً عن مجرد توسيع نافذة السياق
- ما الذي تفعله Memora من Microsoft بشكل مختلف فعلياً عن RAG و Mem0 وذاكرة الرسوم البيانية للمعرفة (knowledge-graph memory)
- ما الذي تضيفه JiuwenMemory من Huawei — بما في ذلك الجزء المحدد الذي لا توثقه توزيعاتها مفتوحة المصدر بالطريقة التي وصفها إعلان الإطلاق
- لماذا تمثل المقارنات المرجعية للذاكرة المبلغ عنها ذاتياً (LoCoMo, LongMemEval) مشكلة مصداقية حقيقية في هذه الفئة بأكملها، وليس فقط لهذين المشروعين
- الشرط القانوني الملموس الملحق بـ JiuwenMemory والذي لا علاقة له بجودة الكود الخاص بها
- كيفية تقييم أي من المشروعين فعلياً قبل المراهنة عليه في عميل إنتاجي (production agent)
لماذا يهم هذا الآن
كل نموذج لغوي كبير هو، تحت تجربة المنتج، عديم الحالة (stateless). تنتهي المحادثة، وتفرغ نافذة السياق، وتبدأ الجلسة التالية من الصفر. بالنسبة لروبوت دردشة، هذا أمر مزعج. أما بالنسبة لعميل يُتوقع منه إدارة مشروع يستمر لعدة أسابيع، أو تتبع علاقة مع عميل، أو تراكم الخبرات عبر مئات الجلسات، فإن هذا الأمر يجعله غير مؤهل. صياغة Microsoft Research للمشكلة كانت: "كل محادثة طويلة تجبر النموذج على إعادة قراءة تاريخه بالكامل، وكل معلومة جديدة إما أن تُخزن كنص خام (مجزأ ومشوش) أو تُضغط في ملخص غامض (تضيع فيه التفاصيل الدقيقة)".1
الحل ليس ببساطة نافذة سياق أكبر — فهذا يزيد التكلفة خطياً ولا يزال يجبر النموذج على إعادة قراءة كل شيء في كل دورة. كانت إجابة الصناعة هي طبقة ذاكرة منفصلة تقع خارج النموذج: استخراج ما يهم من المحادثة، وتخزينه بشكل دائم، واسترجاع الشريحة ذات الصلة فقط في بداية الجلسة التالية. وبحلول عام 2026، أصبح هذا مجالاً مزدحماً بمجموعة مقارنات مرجعية خاصة به (LoCoMo, LongMemEval)، ومصطلحاته الخاصة، و — كما يتضح من الإطلاقين المذكورين هنا — مشاكل المصداقية الخاصة به.
ما الذي تفعله Memora بشكل مختلف
الخطوة المركزية في Memora هي التوقف عن معاملة "ما يتم تخزينه" و"كيف يتم العثور عليه" كأنهما نفس المشكلة. كل إدخال في الذاكرة يتكون من جزأين: تجريد أساسي (primary abstraction)، وهو عبارة من ست إلى ثماني كلمات تلخص موضوع الذاكرة، وقيمة الذاكرة (memory value)، وهي المحتوى الكامل غير المضغوط. يتم تحويل التجريد الأساسي فقط إلى embedding وفهرسته — أما المحتوى الغني الموجود تحته فلا يتم البحث عنه مباشرة أبداً، لذا لا يضطر أبداً إلى الضغط ليكون فعالاً.1
علاوة على ذلك، توفر cue anchors (مرتكزات الإشارة) — وهي علامات قصيرة يتم إنشاؤها تلقائيًا من محتوى الذاكرة نفسه — طريقة ثانية وموازية للعثور على نفس الذاكرة دون الحاجة إلى مخطط ثابت.
مثال من شركة Microsoft: إذا قال المستخدم "اتفق ديف وسارة على دفع النموذج الأولي إلى 1 أبريل، والمشروع التجريبي إلى 2 مايو، والمنتج الأدنى القابل للتطبيق (MVP) إلى 30 مايو"، فإن نظام الرسم البياني للمعرفة (knowledge-graph) سيحتاج إلى أنواع كيانات وعلاقات محددة مسبقًا لتمثيل ذلك.
بدلاً من ذلك، يقوم Memora بإنشاء تجريد أساسي واحد ("اتفق ديف وسارة على الجدول الزمني المحدث لمشروع Orion") بالإضافة إلى عدة مرتكزات إشارة ("تحديث ديف لمشروع Orion"، "جدول النموذج الأولي لمشروع Orion"). أي سؤال لاحق عن أي جزء من هذه الجملة سيعود إلى نفس الذاكرة، دون الالتزام بأنطولوجيا (ontology) مسبقة.1
عملية الاسترجاع ليست مجرد محاولة واحدة أيضًا. يقوم "المسترجع الموجه بالسياسات" (policy-guided retriever) بتكرار تحسين استعلامه، وتتبع مرتكزات الإشارة للوصول إلى ذكريات مرتبطة ولكنها ليست متشابهة بشكل واضح، ويقرر بنفسه متى يتوقف — وهو أمر أقرب إلى كيفية تتبع الشخص لرابط يتذكره جزئيًا منه إلى عملية بحث واحدة عن متجه (vector lookup).1
بالنسبة للنتائج: تفيد Microsoft بأن دقة حكم LLM بلغت 86.3% على LoCoMo (مقياس يتضمن حوارات بمتوسط 600 دور) و87.4% على LongMemEval (سياقات تصل إلى 115,000 توكن)، متفوقًا على RAG و Mem0 و Nemori و Zep و LangMem، وحتى تغذية النموذج بسجل المحادثة الكامل مباشرة.1
يفعل ذلك مع تخزين ما يقرب من نصف عدد إدخالات الذاكرة لكل محادثة مقارنة بـ Mem0 (344 مقابل 651) واستخدام توكنات سياق أقل بنسبة تصل إلى 98% من استدلال السياق الكامل.1
الورقة البحثية خلف هذا المشروع — "Memora: A Harmonic Memory Representation Balancing Abstraction and Specificity"3 — نُشرت في ICML 2026 وفقًا لإعلان Microsoft Research، والكود متاح على GitHub تحت رخصة MIT.14
حتى وقت كتابة هذه السطور، وبعد ثلاثة أسابيع من تدوينة المدونة، حصل هذا المستودع على 111 نجمة و9 عمليات اشتقاق (forks). وهو زخم متواضع ولكنه حقيقي لإصدار بحثي — ولا يزال يُقدم كالتزام أولي واحد دون إصدار محدد، لذا تعامل معه ككود بحثي وليس كاعتمادية مستقرة.4
ما الذي يفعله JiuwenMemory بشكل مختلف
أطلق مجتمع openJiuwen التابع لشركة Huawei — وهو جهد لمنصة وكلاء AI مفتوحة المصدر، وليس قسم منتجات في Huawei يشحن مباشرة — نظام JiuwenMemory بعد يومين، في 1 يوليو.2 يصف إعلان إطلاق المشروع المحرك باسم "AutoGenetic Memory" ويعتمد على استعارة قطاعات الجينات: يجب أن تنمو الذاكرة وتعيد تنظيم نفسها بالطريقة التي تتكرر وتتكيف بها المعلومات الجينية، بدلاً من مجرد التراكم ككومة متزايدة من النصوص المخزنة.5
من الناحية المعمارية، يسلك JiuwenMemory مساراً مختلفاً عن تصميم Memora القائم على "التجريد زائد مرساة الإشارة" (abstraction-plus-cue-anchor). يقوم JiuwenMemory بتقسيم الذاكرة إلى أربع طبقات مستمرة: تخزن L0 سجل المحادثات الخام حرفياً كطبقة أساسية؛ وتحتوي L1 على ملخصات مضغوطة بواسطة LLM لكل دورة محادثة وبشكل تدريجي؛ أما L2 فهي الذاكرة المهيكلة — وهي ذاكرة عرضية مستخرجة تلقائياً (أحداث وقرارات مؤرخة) وذاكرة دلالية (معرفة خلفية دائمة لا ينبغي للدردشات اليومية أن تمسحها)،25 بالإضافة إلى نوع متغيرات عام يدعمه المخطط (schema) ولكن لا يدرجه بنفسه؛6 وتأتي L3 في الأعلى كطبقة ملف تعريف المستخدم الموحدة — وهي عبارة عن بيانات توكيدية/نفيية دائمة حول هوية المستخدم، بما في ذلك العلاقات والممتلكات،6 إلى جانب حقول ملموسة مثل الاسم، والمنطقة الزمنية، واللغة25 — وهي الطبقة التي تظل متاحة بشكل مباشر في بداية كل جلسة.
الجزء الأكثر تميزاً هو Dreaming (الحلم) — وهي خدمة خلفية اختيارية، معطلة افتراضياً، تقوم بشكل دوري بإعادة قراءة جلسات المستخدم المخزنة واستخلاص المعرفة الدائمة منها وفق جدول زمني، بدلاً من القيام بذلك فقط في لحظة وصول الرسالة.6
يصف إعلان الإطلاق هذه العملية بأنها "نموذج نوم" من ثلاث مراحل، مصمم بشكل فضفاض بناءً على كيفية ترسيخ الذاكرة البشرية أثناء الليل. تقوم مرحلة "النوم الخفيف" (Light Sleep) بعملية فحص تدريجي لبيانات الجلسة الجديدة. أما مرحلة "حركة العين السريعة" (REM)، فيقوم فيها LLM بإتمام عملية الاستخراج والتصنيف في تمريرة واحدة.
وتتعامل مرحلة "النوم العميق" (Deep Sleep) النهائية مع إزالة التكرار الدلالي وحل التعارضات قبل الكتابة في الذاكرة طويلة المدى.65 فإذا ذكر المستخدم تفضيلاً لقاعدة بيانات معينة في الأسبوع الماضي وتفضيلاً مختلفاً بالأمس، فإن هذه المرحلة هي التي تقرر أي نسخة هي الحالية.
وفقاً لملف README الخاص بالمستودع، يتم وضع نقاط تفتيش (checkpointed) للمسح التدريجي بحيث ينجو من عمليات إعادة التشغيل، كما أن بدء المجدول هو عملية "idempotent" لكل زوج من النطاق والمستخدم. وتستخدم عمليات الكتابة نفس قفل مستوى المستخدم المستخدم في الاستخراج المباشر وتعيد استخدام نفس آلية اكتشاف التعارض الدلالي، لذا لا تتصادم المسارات أو تتكرر أبداً.6
هناك ميزة مصاحبة تسمى MemoryTurbo تعالج مقايضة هندسية حقيقية: إذا كان الاستخراج يحدث فقط في الخلفية، فهل يجب على الاسترجاع الانتظار؟ إجابة JiuwenMemory هي آلية يسميها ملف README الخاص بالمشروع Momentum Decoupling (فك ارتباط الزخم) — وهو مسار كتابة من مستويين، حيث تهبط أدوار المحادثة الجديدة فوراً في مخزن متجهات (vector store) لطبقة ذاكرة مؤقتة قابلة للبحث، بينما تعمل خطة الاستخراج الأكثر ثقلاً بشكل غير متزامن خلفها بناءً على الأولوية وحمل الحوسبة. يقوم نموذج أصغر أولاً بتجميع المحادثات حسب الموضوع بحيث يتم استخراج الأدوار ذات الصلة كمجموعة، مما يمنع إجراء استدعاءات LLM المكلفة لكل دور محادثة على حدة.6
هنا لا تتفق أرقام المشروع نفسه مع بعضها البعض. يذكر ملف الـ README أن Momentum Decoupling يقلل من زمن الاستجابة الملحوظ للمستخدم بنسبة 92%؛6 بينما يشير إعلان الإطلاق والتغطية الصحفية لنفس الإطلاق إلى رقم أقل وهو 80% بدلاً من ذلك، إلى جانب انخفاض إضافي في استخدام التوكنز (tokens) بنسبة تزيد عن 50%.52 ويُقال إن دقة الاسترجاع تظل ثابتة حتى أثناء انتظار عملية الاستخراج، لأن طبقة التخزين المؤقت (cache layer) نفسها تظل قابلة للبحث.6 لا يستند أي من الرقمين إلى معيار قياس خارجي مسمى — فكلاهما تقارير من المطورين — وحقيقة أن توثيق المشروع نفسه وتغطية إطلاقه لا يتفقان على النسبة المئوية هي معاينة صغيرة ومستقلة لمشكلة مصداقية معايير القياس التي سيتناولها هذا المقال لاحقاً.
هناك مكونان إضافيان يكملان البنية المعلنة.
تحول Graph Memory المحادثات والمستندات والمحتوى المهيكل إلى رسم بياني معرفي (knowledge graph) يتطور باستمرار، بحيث يمكن للعميل (agent) تتبع روابط الكيانات والعلاقات بدلاً من الاعتماد على التشابه الدلالي (semantic similarity) وحده — وهو أقرب في جوهره إلى Graphiti الخاص بـ Zep منه إلى مخزن متجهي (vector store) مسطح.
تحتفظ الحلقات (Episodes) بمصدر البيانات الأصلي، وتحتفظ الكيانات والعلاقات بالنتيجة المهيكلة، ويقوم الرسم البياني بالدمج والتحديث مع وصول محادثات جديدة.5 هناك قيد حقيقي يستحق المعرفة قبل تقييمه: وفقاً لتوثيق بنية المشروع، تعمل Graph Memory حالياً كوحدة مستقلة ولم يتم ربطها بعد في خط معالجة LongTermMemory.add_messages الرئيسي — لذا فإن استخدامها اليوم يعني استدعاءها مباشرة بدلاً من الحصول عليها تلقائياً جنباً إلى جنب مع بقية عمليات استخراج الذاكرة.6
توسع Swarm Memory الفكرة نفسها عبر فريق من العملاء. يراكم كل عميل ذاكرته الخاصة بينما يساهم بمعرفة قابلة للمشاركة في مجمع على مستوى المؤسسة، بحيث يرث العميل المضاف حديثاً المعرفة المتراكمة في المجال بدلاً من البدء من الصفر.5
ما يربط كل ذلك معاً هو طبقة محول (adapter layer) غير مقيدة عمداً، مقسمة على محورين: بُعد الإضافات (Plugin) الموجه لمنصات العملاء، وبُعد المزود (Provider) الموجه لمحركات الذاكرة، مع شحن Mem0 كمزود بديل إلى جانب JiuwenMemory نفسها.5 الهدف — وهو جعل الذاكرة بنية تحتية محمولة بدلاً من شيء مقيد بإطار عمل واحد — قريب مفاهيمياً مما تحاول MCP القيام به لأدوات العملاء بشكل أوسع، رغم أن كليهما يحل المشكلة من خلال آليات مختلفة تماماً.
هناك ملاحظة واحدة تستحق التنبيه لأي شخص يقيم هذا اليوم. يوثق ملف الـ README الإنجليزي في مستودع GitHub العام Graph Memory و MemoryTurbo بالتفصيل — حيث يحصل كلاهما على قسم ميزات خاص بهما، ولدى Graph Memory وثيقة API مخصصة ومرتبطة.6 ما لا يتم توثيقه كميزة مسمى هو Swarm Memory: السلسلة النصية الوحيدة ذات الصلة في ملف الـ README الحالي هي "JiuwenSwarm"، المدرجة كواحدة من عدة منصات عملاء يمكن لمحول بُعد الإضافات الربط بها — وهو ذكر لتوافق الإضافات، وليس وصفاً لقدرات الذاكرة.6
هذه فجوة أضيق من قول "إن البنية المعلنة غير موثقة إلى حد كبير" — فمعظم ما وصفه منشور الإطلاق موجود بالفعل في المستودع العام، بما في ذلك Graph Memory و MemoryTurbo. ولكن هذا يعني أن المطور الذي يقيم توزيعة GitHub يجب أن يتأكد من Swarm Memory تحديداً — بدلاً من قائمة الميزات بالكامل — قبل افتراض أنها تعمل كما هو موصوف. المستودع الأساسي للمشروع مستضاف على GitCode بدلاً من GitHub. هناك فخ عملي في كلا المضيفين: مستودع GitHub يعتمد افتراضياً على فرع develop، بينما لا يزال فرع main يقدم ملف README قديماً لا يوثق أياً من هذه الميزات — اقرأ develop، وليس ما يظهر في main.67
مقارنة Memora و JiuwenMemory مع المنافسين
| Memora (Microsoft) | JiuwenMemory (Huawei/openJiuwen) | |
|---|---|---|
| تاريخ الإصدار | 29 يونيو 20261 | 1 يوليو 20262 |
| الحالة | ورقة بحثية مراجعة من قبل الأقران، نُشرت في ICML 20261 | مشروع مجتمعي مفتوح المصدر، بدون مراجعة من الأقران |
| الآلية الأساسية | تجريد أساسي + مراسي إشارات، استرجاع موجه بالسياسات1 | مخزن طبقي L0–L3 + توحيد Dreaming غير متزامن6 |
| درجة LoCoMo المسجلة | 86.3% (تقييم LLM)1 | زيادة بنسبة 15% مقارنة بالذاكرة الأصلية لـ OpenClaw، لم يتم نشر الدرجة المطلقة2 |
| الترخيص | MIT4 | Apache-2.06 |
| تفاعل المستودع (وقت الجلب) | 111 نجمة، 9 نسخ (forks) على GitHub4 | 4 نجوم، 4 نسخ على مرآة GitHub — ولكن 438 نجمة، 25 نسخة على GitCode، مستودعه الأساسي7 |
| التحقق المستقل | لا يوجد حتى الآن — عمره ثلاثة أسابيع | لا يوجد — تقارير ذاتية من المشروع نفسه2 |
| تنبيه هام | كود بحثي، لا يوجد إصدار محدد (tagged release) بعد4 | قانون الاستخبارات الوطني الصيني ينطبق على المطور (انظر أدناه)2 |
من أجل المقارنة، هناك مشروعان رائدان يتنافس معهما كلا المشروعين ضمنياً: Mem0 هو القائد الحالي للمجتمع — حيث نمت نجومه على GitHub من حوالي 47,800 في يونيو 2026 إلى حوالي 60,700 اعتباراً من 21 يوليو8 — بتصميم يعتمد على المتجهات مع رسوم بيانية اختيارية، بينما يركز محرك Graphiti مفتوح المصدر من Zep على الذاكرة الزمنية والواعية بالعلاقات بدلاً من أرقام الاعتماد الخام. لا تعتبر أي من هاتين المقارنتين متكافئة مع Memora أو JiuwenMemory: فـ Mem0 و Zep منتجات ناضجة ومعتمدة على نطاق واسع وتتنافس في جودة الإنتاج، بينما النظامان اللذان يغطيهما هذا المقال لم يتجاوز عمرهما ثلاثة أسابيع.
مشكلة مصداقية المعايير المرجعية (Benchmarks)
هذا هو الجزء الذي يجب أن يشكل كيفية قراءتك لكل رقم في هذا المقال، بما في ذلك أرقام Microsoft. لقد أصبح LoCoMo و LongMemEval هما المعياران المرجعيان الفعليان لذاكرة الوكلاء (agent memory) بنفس الطريقة التي أصبح بها MMLU معياراً لقدرات النماذج العامة، ونفس الشيء الذي حدث مع MMLU يحدث هنا: الجميع يقدم تقارير جيدة جداً عنها.
تذكر Mem0 تحقيق نسبة 92.5% على LoCoMo باستخدام خوارزمية الذاكرة الجديدة التي أطلقتها في أبريل 2026 — ارتفاعاً من 71.4% باستخدام خوارزميتها السابقة — رغم أن ملف README الخاص بـ Mem0 يحدد أن هذا الرقم يعكس منصتها المدارة، مضيفة أن مستخدمي المصادر المفتوحة "يجب أن يتوقعوا مكاسب مشابهة في الاتجاه ولكن ليست أرقاماً متطابقة".9 إذا أخذنا هذا الرقم على ظاهره، فإن 92.5% هي بالفعل أعلى من نسبة 86.3% التي ادعتها Memora. والاثنان ليسا متطابقين تماماً — فقد نُشرت ورقة Memora على arXiv في فبراير 2026، قبل وجود خوارزمية Mem0 في أبريل، لذا لم يكن أي من الفريقين يقيس أداءه مقابل النظام الحالي للآخر — وهو في حد ذاته مثال جيد يوضح لماذا يحتاج كل رقم في هذه القطعة، بما في ذلك أرقام Microsoft، إلى نفس القدر من التدقيق. وتدعي EverOS من EverMind تحقيق 93.05%.2 بينما تدعي JiuwenMemory تحسناً نسبياً بنسبة 15% مقارنة بخط أساس غير منشور.
وفي تقريرها عن أرقام JiuwenMemory تحديداً، استشهدت Tech Times بقطعة منفصلة لمقارنة الأطر البرمجية وجدت فجوة تتراوح بين 15 إلى 37 نقطة بين ما تعلنه أطر الذاكرة عن نفسها وما يصمد أمام التحقق من طرف ثالث.2
يأتي هذا الرقم من تلك المقارنة الخارجية، وليس من اختبار أجراه فريق Microsoft أو Huawei على نظام الآخر. تعامل مع هذا الرقم كإشارة إلى سجل هذه الفئة، وليس كاستنتاج محدد حول Memora أو JiuwenMemory.
الاستنتاج الصادق ليس أن أي واحد من هذه الأرقام مفبرك. فقد خضعت ورقة Microsoft لمراجعة الأقران، وهو فحص حقيقي وإن كان غير مثالي، وهو ما لم تحصل عليه أرقام JiuwenMemory.
بل إن درجة الاختبار المرجعية التي ينشرها الفريق الذي بنى النظام، على لوحة صدارة عامة بدون أدوات قياس موحدة، هي مجرد ادعاء يجب اختباره مقابل ضغط العمل الخاص بك — وليست حكماً نهائياً يؤخذ على ظاهره.
سؤال مخاطر البيانات في الصين
هذا الجزء من القصة لا علاقة له بجودة الكود وعلاقته بالكامل بالولاية القضائية، وهو يستحق نفس الدقة التي أُعطيت للادعاءات التقنية أعلاه بدلاً من إثارة الذعر أو التجاهل.
ينص قانون الاستخبارات الوطني في الصين — الذي اعتمده اللجنة الدائمة للمجلس الوطني لشعب الصين في 27 يونيو 2017 ودخل حيز التنفيذ في اليوم التالي وفقاً للمادة 32 من القانون نفسه — في المادة 7 على أن "جميع المنظمات والمواطنين يجب أن يدعموا ويساعدوا ويتعاونوا مع جهود الاستخبارات الوطنية وفقاً للقانون".10
هذا التزام قانوني عام ينطبق على المنظمات والمواطنين الصينيين — ومن بينهم Huawei، بصفتها شركة يقع مقرها الرئيسي في Shenzhen.
في 30 يونيو 2020، حدد مكتب السلامة العامة والأمن الداخلي التابع لـ FCC رسمياً شركة Huawei — بالاشتراك مع ZTE، جنباً إلى جنب مع الشركات الأم والتابعة والزميلة لكل شركة — كـ "شركات مغطاة" بموجب قواعد الأمن القومي للوكالة.11
واستشهد اقتراح المفوضية في نوفمبر 2019 لتغطية كلتا الشركتين بـ "صلاتهما الجوهرية بالحكومة الصينية" و"القانون الصيني الذي يتطلب منهما المساعدة في أنشطة التجسس". واستند المكتب في تعييناته النهائية إلى "مجموع الأدلة". وقال رئيس المفوضية آنذاك، Ajit Pai، إن كلتا الشركتين "تخضعان بشكل عام للقانون الصيني الذي يلزمهم بالتعاون مع أجهزة الاستخبارات في البلاد".11
استهدف هذا التعيين أجهزة اتصالات Huawei تحديداً، ولا يمتد تلقائياً إلى مكتبة ذاكرة Python مفتوحة المصدر. لكن الالتزام القانوني الأساسي الذي دفع لهذا الإجراء هو شرط قائم على الشركة، وليس شيئاً يعتمد على ما إذا كان المنتج أجهزة أو برمجيات.
نفت Huawei علنًا تقديم بيانات المستخدمين للحكومة الصينية. هذا النفي لم يتم اختباره في إجراء قضائي مستقل، والالتزام القانوني قائم كشرط دائم سواء تم تقديم أي طلب محدد أم لا.2
وهذا بالضبط هو السبب في أن الغموض هنا غير مريح ولا يمكن حله بمجرد عملية تدقيق حقائق واحدة.
الأهمية العملية بالنسبة لـ JiuwenMemory تحديدًا: أن عملية الـ Dreaming الخاصة به تعيد هيكلة المعرفة التفصيلية حول المستخدمين — التفضيلات، القرارات، سياق المشروع — باستمرار في ملف تعريف قابل للاستعلام.
تراخيص المصدر المفتوح تجعل الكود قابلاً للتدقيق، لكنها لا تغير النظام القانوني للدولة التي تحكم المنظمة التي كتبت هذا الكود.
بالنسبة للاستخدام العام في التطوير والبحث، فهذه حقيقة ثانوية. أما بالنسبة لأي شخص يفكر في استخدامه في مهام تتضمن بيانات خاضعة للرقابة، أو بيانات ملكية، أو بيانات عملاء، فإن هذا الأمر يجب أن يكون جزءًا من تقييم حقيقي للمخاطر قبل النشر، وليس مجرد فكرة لاحقة.
ماذا يعني هذا للمطورين
لا يوجد أي من هذين المشروعين في حالة "جاهز للإنتاج" (production-ready) بالمعنى الذي يُستخدم عادةً لهذا المصطلح.
Memora هو إصدار بحثي عمره ثلاثة أسابيع بدون نسخة محددة (tagged version) — هو حقًا يمثل أحدث ما توصل إليه العلم على الورق، ومدعوم بمراجعة النظراء، ولكنه لا يزال مجرد نتاج بحثي وليس تبعية (dependency) يتم صيانتها.
أما JiuwenMemory فهو أوسع من حيث النطاق: عدة خلفيات تخزين، ومزودو ذاكرة قابلون للتوصيل، وخدمة دمج خلفية اختيارية. لكنه يفتقر إلى التحقق من المعايير المستقلة، كما أن الـ Graph Memory لم يتم ربطها بعد في خط استخراج البيانات الرئيسي، وحتى توثيقه الخاص لا يتفق مع تغطية الإطلاق الخاصة به بشأن رقم رئيسي (92% مقابل 80% في ادعاء زمن الاستجابة لـ MemoryTurbo).
وإذا كانت سيادة البيانات بعيدًا عن الولاية القضائية الصينية تهم طبيعة عملك، فهذا سؤال قانوني يجب حله قبل التعامل مع بيانات مستخدمين حقيقية من خلاله.
الخطوة العملية لأي منهما — وفي الواقع لأي إطار عمل لذاكرة العميل (agent-memory) يدعي تحقيق درجة LoCoMo أو LongMemEval هذا العام — هي واحدة: اقرأ الهندسة المعمارية (architecture)، لأن هذا هو المكان الذي توجد فيه الأفكار الحقيقية.
إن تقسيم Memora بين التجريد والتحديد، وتصميم JiuwenMemory الطبقي المضاف إليه الـ Dreaming، كلاهما مساهمات هندسية مشروعة تستحق التعلم منها.
ثم قم بإجراء التقييم الخاص بك مقابل مهام عملك قبل الثقة في أرقام أي قائمة متصدرين (leaderboard)، بما في ذلك الأرقام الموجودة في جدول المقارنة الخاص بهذا المقال أعلاه.
إذا كنت تفضل امتلاك طبقة الذاكرة بالكامل بدلاً من اعتماد أي من هذين المشروعين، فإن بناء مخزن ذاكرة طويل المدى مدعوم بـ Postgres باستخدام pgvector هو نقطة بداية أصغر ومحققة بالكامل.
وإذا كنت تستخدم Claude تحديدًا، فإن أداة الذاكرة وواجهات برمجة تطبيقات تحرير السياق (context-editing APIs) الخاصة بـ Anthropic تحل نسخة أضيق من نفس المشكلة دون الحاجة إلى أي تبعية خارجية على الإطلاق.
الخلاصة
نظرت منظمتان لا تتواصلان مع بعضهما البعض إلى نفس نمط الفشل — الوكلاء الذين ينسون كل شيء بمجرد انتهاء الجلسة — وقدمتا حلولاً مختلفة معمارياً في غضون 48 ساعة من بعضهما البعض.
هذا ليس مجرد صدفة بقدر ما هو إشارة إلى أن المشكلة أصبحت ملحة لدرجة أن فرقاً جادة متعددة تتسابق لحلها في وقت واحد، بنفس الطريقة التي التقى فيها وكلاء استخدام المتصفح من عدة موردين عند نفس المقياس المرجعي في وقت سابق من هذا الشهر.
الشيء الجديد حقاً هنا هو الهندسة: فصل التخزين عن هيكل الاسترجاع، وتوحيد الذاكرة وفق جدول زمني بدلاً من اللحظة الحالية فقط.
أما الشيء الذي ليس جديداً — والذي تؤكده هاتان الإطلاقتان مرة أخرى — هو أن درجة المقياس المرجعي من الفريق الذي بنى النظام الفائز بالمقياس هي مجرد ادعاء، وليست حقيقة.
وبالنسبة لأحد هذين المشروعين على الأقل، هناك سؤال ثانٍ غير تقني حول الولاية القضائية، وهو سؤال لن تجيب عليه أرقام قائمة المتصدرين على أي حال.
الحواشي السفلية
-
Microsoft Research, "Memora: A Harmonic Memory Representation Balancing Abstraction and Specificity" (نُشر في 29 يونيو 2026). https://www.microsoft.com/en-us/research/blog/memora-a-harmonic-memory-representation-balancing-abstraction-and-specificity/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
-
جيري أوينز، "ذاكرة وكيل الذكاء الاصطناعي تتعلم عبر الجلسات: إطار عمل هواوي يأتي مع مخاطر بيانات صينية،" Tech Times (نُشر في 2 يوليو 2026، الساعة 9:54 صباحاً بتوقيت شرق الولايات المتحدة). https://www.techtimes.com/articles/319523/20260702/ai-agent-memory-learns-across-sessions-huawei-framework-ships-china-data-risk.htm ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15
-
"Memora: تمثيل ذاكرة توافقي يوازن بين التجريد والخصوصية،" arXiv:2602.03315 (قُدم في 3 فبراير 2026). https://arxiv.org/abs/2602.03315 ↩ ↩2
-
مستودع microsoft/Memora GitHub (تم الوصول إليه في 21 يوليو 2026). https://GitHub.com/microsoft/Memora ↩ ↩2 ↩3 ↩4 ↩5
-
机器之心 (Machine Heart), "لا مزيد من «فقدان الذاكرة» عبر الجلسات: مجتمع openJiuwen يطلق AutoGenetic Memory مفتوح المصدر" — إعلان إطلاق AutoGenetic Memory / JiuwenMemory من قبل openJiuwen، نُشر في 2 يوليو 2026. يدرج مستودع الكود الأساسي كـ https://gitcode.com/openJiuwen/agent-memory/. https://www.163.com/dy/article/L0R5811O0511AQHO.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
ملف README الخاص بـ openJiuwen-ai/agent-memory على فرع
developالافتراضي، "JiuwenMemory" (تم الحصول عليه في 21 يوليو 2026). https://GitHub.com/openJiuwen-ai/agent-memory ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 -
إحصائيات مستودع openJiuwen-ai/agent-memory — نسخة مرآة GitHub (تم جلبها في 21 يوليو 2026، https://GitHub.com/openJiuwen-ai/agent-memory) والمستودع الأساسي على GitCode (تم جلبه في 21 يوليو 2026، https://gitcode.com/openJiuwen/agent-memory). ↩ ↩2
-
TECHSY، "8 AI Agent Memory Tools & Mem0 Alternatives (2026)" (تم التحديث في 19 يوليو 2026) — يشير إلى أن Mem0 لديه 61.2 ألف نجمة على GitHub اعتباراً من 19 يوليو 2026، ارتفاعاً من 47.8 ألف في يونيو 2026. https://techsy.io/en/blog/best-ai-agent-memory-tools. رقم 60.7 ألف المستخدم أعلاه هو العدد المباشر من مستودع mem0ai/mem0 على GitHub (تم جلبه في 21 يوليو 2026)، https://GitHub.com/mem0ai/mem0، وقد تم استخدامه بدلاً من رقم المجمّع. ↩
-
ملف README لمستودع mem0ai/mem0 على GitHub، قسم "New Memory Algorithm (April 2026)" (تم جلبه في 21 يوليو 2026). https://GitHub.com/mem0ai/mem0 ↩
-
China Law Translate، "National Intelligence Law of the P.R.C. (2017)" (كما تم تعديله في 2018) — المادة 7؛ اعتمدته الدورة 28 للجنة الدائمة للمجلس الوطني لشعب الصين في 27 يونيو 2017، ودخل حيز التنفيذ في 28 يونيو 2017 وفقاً للمادة 32. https://www.chinalawtranslate.com/en/national-intelligence-law-of-the-p-r-c-2017/ ↩ ↩2
-
لجنة الاتصالات الفيدرالية، "FCC Designates Huawei and ZTE as National Security Threats" (بيان صحفي، 30 يونيو 2020) — يشمل التصنيف كلا الشركتين معاً كـ "شركات مغطاة". https://docs.fcc.gov/public/attachments/DOC-365255A1.pdf ↩ ↩2



