هندسة السياق لوكلاء الذكاء الاصطناعي طويلة الأمد

تشير تحليلات Arize، وورقة arXiv حول تجاوز نافذة السياق، وشرح الإنتاج من Redis، ومقارنة هندسة أطر التشغيل من Atlan، مجتمعةً، إلى تحول عملي في تصميم الوكلاء. بات تقييم الوكلاء طويلة التشغيل يعتمد بدرجة أقل على حجم نافذة السياق لدى النموذج، وبدرجة أكبر على طبقة التحكم المحيطة بها. تجعل Arize هذا التحول ملموسًا. فهي تسمي أدوات وكلاء وأنظمة ذاكرة/أطر تشغيل مطروحة بالفعل، منها Pi وOpenClaw وClaude Code وLetta، بوصفها أمثلة على هندسة السياق على مستوى إطار التشغيل، وتصف محاكيًا تفاعليًا يوضح كيف تمتلئ نافذة من 200 ألف token.

التفاصيل العامة المتاحة في المصادر المذكورة متفاوتة. تقدم Arize أرقام تنفيذ ملموسة لـ Pi وOpenClaw وClaude Code وLetta. وتقدم ورقة بحثية حول حل تجاوز نافذة السياق في وكلاء الذكاء الاصطناعي آلية أعم للتعامل مع مخرجات الأدوات التي يمكن أن تتجاوز أي نافذة عملية. ويلخص شرح Redis حول تجاوز نافذة السياق أعراض الإنتاج: أخطاء API صارمة، وتدهور صامت في الجودة، وتراكم مخرجات الأدوات، وزمن استجابة أطول مع نمو الـ prompts. وتوفر مقارنة Atlan بين هندسة الـ prompt والسياق وإطار التشغيل استعارة الطبقات المفيدة: هندسة الـ prompt تشكل الرسالة، وهندسة السياق تشكل ما يراه النموذج، وهندسة إطار التشغيل تشكل بيئة الوكيل بأكملها.

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

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

طريقة أوضح لقراءة المجموعة الأولى من الحدود هي:

• Pi: تتوقف قراءات الملفات عند 2,000 سطر أو 50KB، أيهما يأتي أولًا. ويتضمن المحتوى المُعاد تلميح متابعة يخبر النموذج بنطاق الأسطر الذي عُرض وكيفية المتابعة باستخدام offset وlimit. يرث OpenClaw هذا السلوك، ثم يضيف حدودًا منفصلة: ملفات bootstrap محدودة بـ 12,000 حرف لكل ملف و60,000 حرف إجمالًا. وتحصل نتائج الأدوات على ميزانية أخرى قدرها 16,000 حرف أو 30% من نافذة السياق، أيهما أصغر.

يستخدم Claude Code تصميمًا ببوابتين. وفقًا لـ Arize، يتحقق أولًا من حد 256KB بالبايت قبل فتح ملف، ثم يحسب tokens النتيجة مقابل ميزانية قدرها 25,000 token بعد القراءة. حتى بالنسبة إلى الملفات الواقعة تحت الحد، يعيد افتراضيًا 2,000 سطر من البداية، ويقتطع الأسطر التي يزيد طولها على 2,000 حرف. وإذا أعاد النموذج قراءة نطاق الملف نفسه ولم يكن الملف قد تغير، يستطيع Claude Code إرجاع stub بدلًا من تكرار المحتوى الكامل.

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

النمط التالي هو التعامل مع السياق كنافذة عرض، لا كتخزين.

يعرض Pi وClaude Code ترقيم الصفحات عبر offset وlimit. يضيف OpenClaw اقتطاع الرأس/الذيل في بعض المواضع، مع الإبقاء على البداية والنهاية عندما يكون الوسط أقل احتمالًا للأهمية. تقول Arize إن OpenClaw يستخدم تقسيمًا بنسبة 75% للرأس / 25% للذيل لملفات bootstrap كبيرة الحجم، وقد يحتفظ بكل من الرأس والذيل لنتائج الأدوات عندما يبدو الذيل مهمًا، مثل الأخطاء أو أقواس JSON الختامية أو الكلمات الشبيهة بالملخص.

تذهب Letta أبعد من ذلك بجعل الملفات تعيش خارج الـ prompt. تُحلل الملفات المرفوعة، وتُقسّم إلى أجزاء، وتُضمّن في مخزن متجهات، ما يمنح الوكيل عرضًا مباشرًا وبحثًا دقيقًا وبحثًا دلاليًا. عندما يكون ملف مفتوحًا ضمن السياق، تعرض Letta عرضًا مُدارًا يتدرج حجمه مع سياق النموذج: 5,000 حرف لسياق 8K، و15,000 لسياق 32K، و25,000 لسياق 128K، و40,000 لسياق 200K+. كما يتدرج عدد الملفات المفتوحة في الوقت نفسه، من 3 للنماذج الصغيرة إلى 15 للنماذج الكبيرة جدًا، مع سياسة LRU تُخرج الملفات الأقل وصولًا إليها مؤخرًا.

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

توضح Redis نقطة ذات صلة: نوافذ السياق الأكبر لا تلغي الحاجة إلى إدارة السياق. فـ prompts النظام، والمستندات المسترجعة، وسجل المحادثة، ومخرجات الأدوات كلها تتنافس على المساحة نفسها. وحتى قبل الوصول إلى حد صارم، يمكن أن تتدهور النماذج عندما تُدفن المعلومات ذات الصلة داخل مدخلات طويلة.

التجاوز هو الفشل الواضح. أما فقدان الهدف فأهدأ. لا يزال لدى الوكيل مساحة للرد، لكنه ينسى الهدف الأصلي، أو يفوّت قيدًا، أو يبدأ بتحسين مهمة فرعية محلية.

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

تفيد Arize بأن Pi يشغّل الضغط عندما تتجاوز tokens السياق المقدرة نافذة السياق ناقص tokens الاحتياط، مع احتياطي افتراضي قدره 16,384 token. ويحتفظ بأحدث نحو 20,000 token ويلخص المحتوى الأقدم في رسالة مستخدم اصطناعية تُضاف قبل الذيل المحتفَظ به. كما يتجنب القطع عبر أزواج استدعاء الأداة/نتيجة الأداة.

يضيف OpenClaw سياسة سجل أكثر عدوانية. عندما يتجاوز السجل 50% من نافذة السياق، يقسم الرسائل إلى كتل tokens متساوية الكتلة، ويحذف أقدم كتلة، ويلخص المحتوى المحذوف عبر تلخيص متعدد المراحل والتمريرات، ويصلح اقتران استدعاءات الأدوات/نتائجها. وينفذ أيضًا تفريغًا قبل الضغط: تمنح دورة وكيلة صامتة الوكيل فرصة لحفظ الحالة في ملفات الذاكرة قبل اختفاء السجل. وبشكل منفصل، يشذب نتائج الأدوات في الذاكرة بسلوك soft-trim وhard-clear على TTL لذاكرة تخزين مؤقت مدته 5 دقائق.

يضغط Claude Code قرب نهاية النافذة. تقول Arize إن مُشغّله هو نافذة السياق الفعالة ناقص مخزنًا احتياطيًا قدره 13,000 token، ما يضع الضغط عند نحو 167K token لنموذج بسياق 200K. يطلب prompt التلخيص الخاص به أقسامًا منظمة تغطي الطلب الأساسي، والمفاهيم التقنية، والملفات والكود، والأخطاء والإصلاحات، وحل المشكلات، ورسائل المستخدم، والمهام المعلقة، والعمل الحالي، والخطوة التالية. وبعد الضغط، يمكنه إعادة إرفاق ما يصل إلى 5 ملفات قُرئت مؤخرًا ضمن ميزانية tokens.

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

يجب ألا توضع بعض المخرجات في نافذة السياق إطلاقًا.

تجعل ورقة arXiv ذلك ملموسًا عبر سير عمل في علم المواد. تولد إحدى الأدوات بنية شبكة إلكترونية لجزيء: مصفوفة ثلاثية الأبعاد بأبعاد 128 × 128 × 128، بإجمالي 2,097,152 عنصر float32. يتجاوز ذلك المخرج بكثير نافذة السياق في نماذج اللغة الكبيرة المستخدمة على نطاق واسع. لكن الأداة التالية تحتاج إلى الشبكة كمدخل.

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

هذا هو أنظف فصل بين الاستدلال ونقل البيانات. لا يحتاج النموذج إلى «رؤية» مصفوفة من مليوني عنصر ليمررها إلى أداة أخرى. يحتاج إلى معرفة أن المصفوفة موجودة، وما الذي تمثله، وأي عملية يجب أن تستهلكها تاليًا.

ينطبق المنطق نفسه خارج المصفوفات العلمية. غالبًا ما تنتمي استجابات JSON الكبيرة، وملفات PDF، والسجلات، والتضمينات، وملفات الوسائط، وصادرات قواعد البيانات إلى التخزين، لا إلى الـ prompt. وبالنسبة إلى الأنظمة المبنية حول أدوات MCP أو موصلات API مخصصة، يجب أن يكون تمرير المؤشرات خيار تصميم من الدرجة الأولى، لا ترقيعًا بعد أول تجاوز.

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

الدرس الأعمق هو أن نافذة السياق مورد نادر في وقت التشغيل. التعامل معها كـ «ذاكرة» مفيد، لكن فقط إذا تصرف إطار التشغيل كنظام تشغيل: يخصص، ويُخرج، ويُصفّح، ويضغط، ويزيل التكرار، ويحفظ بشكل دائم. تمييز الطبقات لدى Atlan مفيد هنا. لا تستطيع هندسة الـ prompt إصلاح قارئ ملفات يسكب 80,000 token غير ذي صلة في الاستدعاء التالي. تستطيع هندسة السياق تحسين مجموعة العمل. وتقرر هندسة إطار التشغيل ما إذا كانت مجموعة العمل تلك محمية أصلًا.

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

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

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

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

رابعًا، انقل القيم الكبيرة إلى خارج الـ prompt. خزّنها، وسمّها، ومرر المؤشرات عبر الأدوات. هذا مهم خصوصًا للوكلاء الذين يستدعون APIs، أو يعالجون المستندات، أو ينسقون أنظمة متعددة الوكلاء.

أخيرًا، اختبر فقدان الهدف بشكل منفصل عن التجاوز. يمكن للوكيل أن يبقى تحت النافذة الصارمة وأن ينحرف مع ذلك. السؤال الصحيح ليس فقط «هل قبلت API الـ prompt؟» بل «هل لا يزال الإجراء التالي يخدم المهمة الأصلية؟»

يحول الملخص أدناه هذه الأنماط إلى قائمة تحقق سريعة قبل الأسئلة الشائعة.

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

يجيب هذا القسم عن الأسئلة العملية وراء هندسة السياق للوكلاء طويلة الأمد: ما الذي يتجاوز السعة، وكيف تضيع الأهداف، وأي أنماط في إطار التشغيل تُبقي العمل على المسار.

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

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

تضع ميزانيات لكل مصدر، وترقّم قراءات الملفات، وتسترجع العروض ذات الصلة فقط، وتضغط السجل حول الحالة، وتزيل تكرار القراءات المتكررة، وتخزن المخرجات الكبيرة خارج الـ prompt.

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

لا. تساعد النوافذ الأكبر، لكن prompts النظام، وتعريفات الأدوات، والمستندات المسترجعة، والسجلات، والتاريخ، ما زالت تتنافس على المساحة، ويمكن أن تُدفن المعلومات ذات الصلة قبل الوصول إلى حد صارم.