نافذة السياق لوكيل LLM: ما الذي يدخلها ولماذا ينسى الوكيل القواعد

ما هي نافذة السياق في LLM

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

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

ما الذي يدخل نافذة سياق الوكيل

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

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

لماذا ينسى الوكيل القواعد في الجلسة الطويلة

شكوى شائعة: في بداية الجلسة يلتزم الوكيل بالقواعد الموجودة في CLAUDE.md بدقة، ثم بعد ساعة من العمل يبدأ في خرقها. هو لم «ينسَها» بالمعنى الحرفي، فنص القواعد ما زال في النافذة. المشكلة في طريقة توزيع النموذج للانتباه على نص طويل.

Lost in the middle

أظهرت دراسة لـ Liu وزملائه عام 2023 أن النماذج اللغوية تستفيد بشكل أفضل من المعلومات الموجودة في بداية السياق الطويل ونهايته، أكثر مما تستفيد من تلك الموجودة في وسطه. تُحمَّل ملفات التعليمات في بداية الجلسة، لكن مع تقدم الحوار يتراكم فوقها وتحتها نص أكثر فأكثر. القاعدة التي كانت واضحة تصبح تدريجيًا في المنطقة التي يرى فيها النموذج أقل ما يمكن.

تنخفض حصة القواعد في النافذة

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

الأمثلة الحديثة تتغلب على القواعد القديمة

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

Context rot: تدهور الجودة قبل بلوغ الحد

Context rot («تعفن السياق») هو الاسم الذي يُطلق على ظاهرة تتراجع فيها جودة ردود النموذج كلما امتلأت النافذة، رغم أن الحد التقني ما زال بعيدًا. النموذج يقبل فعليًا 200 ألف توكن، لكنه يعمل عند 150 ألفًا أسوأ مما عند 20 ألفًا: يخطئ أكثر في التفاصيل، ويكرر حلولًا رُفضت، وينسى التعليمات.

علامات أن الجلسة «تعفنت»:

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

إضافة قاعدة أخرى لعلاج ذلك عديمة الفائدة: القاعدة الجديدة ستضيع في الضوضاء نفسها. يجب تقليل الضوضاء.

ضغط السياق (Compaction)

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

في Claude Code يوجد لذلك الأمر /compact الذي يمكن تمرير تلميح إليه حول ما يُركَّز عليه عند الضغط. وعندما تقترب النافذة من حدها ينفذ Claude Code الضغط تلقائيًا أيضًا. أما الأمر /clear فيمسح التاريخ بالكامل ويبدأ من صفحة بيضاء، والأمر /context يُظهر ما تشغله النافذة الآن.

/context
/compact احفظ: هدف المهمة، والقرارات المتخذة مع أسبابها، وقائمة الملفات المعدّلة، وما بقي للتحقق
/clear

ما الخطر في الضغط

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

الضغط أم جلسة جديدة

كيف توفّر نافذة سياق الوكيل

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

1. موجّه قصير في ملف التعليمات

يُقرأ ملف الدخول CLAUDE.md أو AGENTS.md كاملًا في كل جلسة. ملف من 600 سطر يعني تكلفة دائمة بحدود 10–20 ألف توكن. احتفظ فيه بأوامر الفحص والقيود الصارمة وخريطة المشروع، وضع التفاصيل حسب الموضوع في مستندات منفصلة يفتحها الوكيل عند الحاجة فقط.

2. معارف تُحمَّل عند الطلب

في Claude Code skills تُحمَّل في السياق أولًا الصيغة المختصرة فقط، ويُحمَّل النص الكامل للتعليمات عندما تحتاج المهمة إلى هذه المهارة. وهذه طريقة جيدة لإبقاء الإجراءات النادرة، كالنشر والترحيل والإصدار، في متناول اليد دون دفع ثمنها في كل جلسة.

3. وكلاء فرعيون للعمل المزعج

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

4. مخرجات الأدوات الهادئة

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

# ضوضاء: آلاف الأسطر في النافذة مع كل تشغيل
pytest -v

# هادئ: عند النجاح سطر واحد، وعند السقوط الاختبارات الساقطة فقط
pytest -q --tb=short

# السجل لا يُؤخذ كاملًا، بل آخره والأخطاء فقط
tail -n 50 app.log | grep -i error

5. مهمة واحدة لكل جلسة

لا تمتد جلسة واحدة عبر ثلاث مهام غير مرتبطة. تاريخ المهمة الأولى لا فائدة منه للثالثة، لكنه يشغل المكان ويربك الوكيل. أنهيتم المهمة، ثبّتوا النتيجة، ثم افتحوا جلسة جديدة.

6. الحالة في الملفات لا في التاريخ

كل ما يجب أن يبقى بعد الضغط والجلسات الجديدة اكتبه في المستودع: الهدف، والقرارات مع أسبابها، والبدائل المرفوضة، وما أُنجز وكيف جرى التحقق منه، والخطوة التالية. مثلًا في PLAN.md وPROGRESS.md. عندها لا تبدأ الجلسة الجديدة بإعادة سرد، بل بمستند دقيق، ويمكنك أن تمسح التاريخ دون خوف.

# PROGRESS.md
## الهدف
تحويل حساب الخصومات إلى قروش صحيحة

## المنجز (مُتحقَّق منه)
- app/payments/discount.py: من float إلى int، و make test أخضر
- أُضيفت migration 041 وطُبقت محليًا

## القرارات
- التقريب: مصرفي، كما لدى مزوّد الدفع

## المرفوض
- Decimal في النموذج: يكسر تسلسل webhooks

## الخطوة التالية
تحديث سيناريو e2e لإتمام الطلب، وتشغيل make e2e

القواعد الحرجة ليست في النافذة وحدها

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

قاعدة هارنس جيدة: ما يمكن فحصه آليًا يُفحص آليًا، ولا يبقى في السياق إلا ما يحتاج إلى حكم.

الخلاصة

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