Your AI Agent's Context Window Is RAM, Not Storage. That Explains Most Production Failures.

عند العمل على نطاق واسع، فإن عنق الزجاجة في أداء العميل المدعوم بالذكاء الاصطناعي (AI agent) لا يتعلق بالنموذج نفسه تقريبًا كعامل أساسي. بل يتعلق بالمعلومات التي يمكن للنموذج الوصول إليها، ومتى يمكنه ذلك، وكم تبلغ كمية البيانات التي يمكن استيعابها في نافذة السياق (context window) في أي لحظة.

تتميز جميع نماذج اللغات الكبيرة الرئيسية بوجود نافذة سياق. حيث يدعم نموذج GPT-4o ما يصل إلى 128,000 رمز (Tokens). ويدعم Claude حوالي 200,000 رمز. بينما يدعم Gemini 2.5 Pro أكثر من مليون رمز. وتستمر هذه الأرقام في النمو، وتفترض فرق العمل دائمًا أن المشكلة قد حُلت. يقومون ببناء العميل، وحشو نافذة السياق بالتعليمات، ونتائج الأدوات، وسجل المحادثات، وتفضيلات المستخدم، ثم يشغلونه.

يعمل هذا الأسلوب بنجاح في العروض التجريبية، ولكنه يفشل عند التطبيق الفعلي في بيئة العمل والإنتاج. والسبب في ذلك بنيوي ولا يرتبط بالنموذج نفسه.

نافذة السياق هي ذاكرة مؤقتة زائلة

تتصرف نافذة السياق مثل ذاكرة الوصول العشوائي (RAM) في الكمبيوتر؛ فهي سريعة، ويمكن للنموذج الوصول إلى أي شيء بداخلها في أي وقت، وهي الشيء الوحيد الذي يمكن للنموذج التفكير فيه وتحليله في وقت الاستدلال. لكنها أيضًا مؤقتة، ومحدودة السعة، ومكلفة للغاية لكل رمز.

معاملة نافذة السياق كقاعدة بيانات، وحشوها بكل شيء قد يحتاجه العميل، يؤدي إلى نفس الإخفاقات التي قد تواجهها إذا حاولت تشغيل تطبيق إنتاجي بالكامل على ذاكرة الوصول العشوائي (RAM) دون وجود قرص صلب. يعمل هذا حتى يتوقف فجأة. وعندما يفشل، يكون نمط الفشل خفيًا: فالعميل لا يتوقف عن العمل، ولكنه يبدأ ببساطة في ارتكاب الأخطاء.

اختبرت دراسة أجراها Gamage مدى التزام العملاء بالقيود المفروضة من قبل المستخدم عبر المحادثات الطويلة. ففي الجولة الخامسة، التزم العملاء بالقيود المحددة بنسبة 73% من الوقت. وبحلول الجولة 16، انخفض هذا الرقم إلى 33%. لم تتغير التعليمات، ولم يتغير النموذج، بل إن القيود ببساطة تراجعت إلى أعماق نافذة السياق، مدفونة تحت الرسائل الأحدث، ومخرجات الأدوات، وخطوات التفكير والتحليل المتوسطة.

هذا ما يُعرف بتلاشي التفضيلات (preference dilution)، وهو أحد أنماط الفشل الأربعة التي تعود مباشرة إلى التشبيه بذاكرة الوصول العشوائي (RAM).

أربع طرق يفشل بها استخدام السياق كمخزن في بيئة الإنتاج

1. تضخم الرموز (Token bloat)

كل استدعاء لأداة يعيد بيانات، وكل جولة محادثة تضيف رموزًا جديدة. ودون إدارة نشطة، يمكن للجلسة التي تبدأ بـ 2,000 رمز أن تتضخم لتصل إلى أكثر من 25,000 رمز خلال بضعة تبادلات في الحوار. ويعني اتساع السياق بطء الاستدلال، وزيادة التكاليف، وتراجع الدقة نظراً لزيادة المواد التي يتعين على النموذج الانتباه إليها.

2. تلاشي التفضيلات

تفقد القيود الصارمة التي وُضعت في بداية المحادثة تأثيرها مع امتلاء نافذة السياق. تميل قيود التنفيذ ("افعل X دائمًا") إلى الصمود، بينما تتلاشى قيود الحظر والامتناع ("لا تفعل Y أبدًا"). والنتيجة: عميل يتبع قواعدك في بداية الجلسة ويتجاهلها بهدوء في نهايتها.

3. التناقضات في منتصف الجلسة

عندما تتعارض التعليمات المبكرة مع المدخلات اللاحقة، يميل النموذج عادةً إلى تفضيل الأحدث. هذا ليس خللًا في النموذج، بل نتيجة طبيعية لآليات الانتباه (attention mechanics). ففي نافذة السياق الطويلة، يمنح النموذج وزنًا أكبر للرموز الحديثة. فإذا قام المستخدم بتصحيح تفضيل معين في الجولة 12، فلن يتم تحديث التفضيل الأصلي من الجولة الأولى، بل يتم ببساطة التغلب عليه وتجاوزه في بعض الأحيان.

4. فقدان الذاكرة بين الجلسات المختلفة

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

الحل: طبقتان، وليس طبقة واحدة

يفصل النمط البنيوي الناشئ عبر عمليات النشر الفعلي لذاكرة العميل إلى طبقتين، مما يحاكي طريقة عمل أجهزة الكمبيوتر دائمًا.

تضم الذاكرة العاملة (Working memory - نافذة السياق) ما يحتاجه العميل في اللحظة الحالية: المهمة الحالية، والنتائج المتوسطة، والتحليل النشط، والمحادثة الأخيرة. وتتم إدارتها بشكل نشط؛ فعندما تعيد أداة ما 2,000 رمز من مخرجات واجهة برمجة التطبيقات (API)، يقوم العميل المصمم جيدًا بتلخيصها إلى 100 رمز قبل إدخالها في السياق. وعند اكتمال مهمة فرعية، يتم التخلص من بياناتها الزائدة.

بينما تحتفظ الذاكرة المستمرة (Persistent memory - التخزين الخارجي) بما يحتاجه العميل عبر الجلسات المتعددة: تفضيلات المستخدم، والقيود الصارمة، والسلوكيات المكتسبة، وحقائق الهوية، والأنماط السلوكية. وتعيش هذه الطبقة خارج نافذة السياق، في مخزن المتجهات (vector store)، أو قاعدة بيانات، أو نظام ذاكرة مخصص. ويتم استردادها عبر البحث الدلالي في بداية كل جولة، مع تخصيص ميزانية محددة تتراوح بين 5 إلى 10 حقائق ذات صلة لدمجها في نافذة السياق إلى جانب المهمة الحالية.

قرار توجيه البيانات بسيط للغاية: هل ستظل هذه المعلومات ذات صلة بعد 30 يومًا؟ إذا كانت الإجابة نعم، تذهب إلى الذاكرة المستمرة. وإذا كانت لا، تبقى في الذاكرة العاملة ويتم التخلص منها بمجرد اكتمال المهمة.

المقارنات المعيارية تؤكد ذلك

نشرت Mem0، وهي واحدة من أكثر أطر عمل ذاكرة العملاء اعتمادًا على نطاق واسع (ومدمجة مع 13 إطار عمل للعملاء بما في ذلك LangChain و CrewAI و OpenAI Agents SDK)، نتائج المقارنة المعيارية في عام 2026 والتي توضح بالأرقام الفارق الكبير بين النهجين.

في مقياس LoCoMo (الذي يختبر الاستدعاء عبر الجلسات المتعددة من خلال 1,540 سؤالاً)، سجل خط الأساس للسياق الكامل (حيث يتم حشو كل شيء داخل النافذة) دقة بلغت 72.9% باستخدام حوالي 26,000 رمز لكل استعلام مع زمن استجابة p95 يبلغ 17.12 ثانية. بينما سجلت بنية الذاكرة ثنائية الطبقات دقة بلغت 91.6% باستخدام حوالي 6,956 رمزًا لكل استعلام فقط مع زمن استجابة p95 يبلغ 1.44 ثانية.

يمثل ذلك تحسنًا في الدقة بمقدار 18.7 نقطة مئوية مع استخدام رموز أقل بـ 4 مرات وخفض زمن الاستجابة بنسبة 91%. فالعميل لا يصبح أقل تكلفة وأسرع فحسب، بل يصبح أكثر دقة بشكل ملموس وقابل للقياس.

وقد أظهر تقرير حالة ذاكرة عملاء الذكاء الاصطناعي لعام 2026 الصادر عن Mem0 مكاسب أكبر في المهام الأكثر أهمية في بيئات المؤسسات: حيث شهد التفكير والتحليل الزمني (معرفة ما تغير ومتى تغير) والاستعلامات متعددة الخطوات (ربط الحقائق عبر جلسات متعددة) أكبر قفزات في الدقة، وهي بالتحديد القدرات التي تتطلبها مهام سير العمل في الشركات والمؤسسات.

ماذا يعني هذا لنشر عملاء الذكاء الاصطناعي في المؤسسات والشركات

النتائج والآثار العملية واضحة ومباشرة.

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

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

أما إذا كان عملاؤك يستخدمون بنية ثنائية الطبقات، فإنهم يحافظون على الالتزام بالقيود بنسبة تفوق 90% بغض النظر عن طول المحادثة، وينقلون التفضيلات المكتسبة عبر الجلسات المختلفة، ويعملون بجزء بسيط من تكلفة الرموز.

هذا الاختلاف ليس نظريًا؛ بل هو الفرق بين عميل تجريبي يعمل بنجاح في عرض توضيحي، وعميل فعلي تم نشره ليعمل بالكفاءة والنطاق الواسع اللذين تحتاجهما المؤسسات والشركات بالفعل.

خمسة أنماط للذاكرة في بيئة العمل الفعلي

تتجه فرق العمل التي تبني عملاء للعمل الفعلي نحو تطبيق مجموعة من أنماط التنفيذ المقررة:

1. تثبيت القيود الصارمة (Hard constraint pinning). يتم إدخال القواعد البالغة الأهمية (متطلبات الامتثال، والسياسات الأمنية، وإرشادات الهوية التجارية) في الجزء العلوي من موجه النظام في كل جولة، بحيث لا تتراجع أبدًا إلى أعماق السياق.

2. ضغط نتائج الأدوات. تُلخص استجابات واجهة برمجة التطبيقات (API) الخام قبل دخولها إلى نافذة السياق. لتتحول حمولة JSON المكونة من 2,000 رمز إلى ملخص مكون من 100 رمز مع استخراج الحقول ذات الصلة فقط.

3. إعادة الإدخال النشط للمعدِّلات. يتم استخراج التصحيحات الواردة في منتصف المحادثة (مثل: "في الواقع، أرسل دائمًا نسخة مخفية للفريق القانوني في هذه الحالات") وحفظها في الذاكرة المستمرة وإعادة إدخالها في الجولات اللاحقة بدلاً من الاعتماد على النموذج لتذكرها من سجل المحادثة.

4. استخراج البيانات عند إنهاء الجلسة. في نهاية كل جلسة، يفحص النظام المحادثة بحثًا عن تفضيلات جديدة وتصحيحات وسلوكيات مكتسبة، ثم ينقلها إلى التخزين المستمر.

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

التحول الجوهري في المهارات المطلوبة

قبل عام من الآن، كان عنق الزجاجة في تطوير العملاء متمثلًا في هندسة الأوامر (prompt engineering): أي كيفية جعل النموذج يفهم ما تريده. أما في عام 2026، فقد انتقل عنق الزجاجة إلى هندسة السياق (context engineering): أي كيفية إدخال المعلومات الصحيحة في الطبقة الصحيحة وفي الوقت المناسب تمامًا.

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

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