"لديه نافذة سياق بمليون token" يُطرح كأنه يحل كل شيء. لا يفعل ذلك. تعلّمت هذا بالطريقة الصعبة، بحشر قاعدة كود كاملة في استدعاء Claude واحد ومشاهدة الوكيل يصبح أسوأ، ليس أفضل. المزيد من السياق ليس مجانياً، وليس دائماً أفضل. دعني أشرح ما هي نافذة السياق فعلاً ومتى يفيدك الرقم الكبير في مقابل متى يضرّك.
ما هي النافذة فعلاً
نافذة السياق هي الحد الأقصى لعدد الـ tokens التي يمكن للنموذج معالجتها في طلب واحد — كل ما ترسله (الـ prompt النظامي، الأدوات، تاريخ الرسائل الكامل، الملفات) بالإضافة إلى كل ما يولّده. على نماذج Claude الحالية، نافذة الإدخال كبيرة: Opus 4.6 و4.7 و4.8 كلها تعمل بسياق 1 مليون token، وSonnet 4.6 أيضاً 1 مليون، وHaiku 4.5 هو 200 ألف. الإخراج محدود بشكل منفصل — ما يصل إلى 128 ألف token على نماذج Opus، و64 ألفاً على Sonnet وHaiku.
لاحظ أن هذين حدّان مختلفان. الوصول إلى حد الإدخال يعطيك stop_reason: "model_context_window_exceeded". الوصول إلى الحد المطلوب للإخراج يعطيك stop_reason: "max_tokens". يعنيان أشياء مختلفة ويحتاجان إصلاحات مختلفة، لذا تعامل مع كلا الفرعين. الناس يخلطون بينهما باستمرار ثم يتساءلون لماذا لم يُجدِ رفع max_tokens — لأن المشكلة كانت في جانب الإدخال.
لماذا الـ token ليس كلمة
فحص سريع للآلية، لأن ذلك يهم عند وضع الميزانية. النموذج لا يرى كلمات؛ يرى tokens، وهي قطع دون الكلمة يُنتجها برنامج التقطيع. النثر الإنجليزي يبلغ تقريباً token لكل ثلاثة أرباع كلمة. الكود يُقطَّع بكثافة أكبر. النص غير الإنجليزي، بكثافة أكبر أيضاً.
مما يعني أنك لا تستطيع تقدير أعداد tokens في Claude باستخدام tiktoken — هذا برنامج التقطيع الخاص بـ OpenAI، وهو يُقلّل حسابات Claude بنسبة 15-20% على النص العادي وبمعدل أكبر بكثير على الكود. إذا احتجت رقماً حقيقياً، استدعِ endpoint الـ count_tokens بنفس معرّف النموذج الذي ستستخدمه للاستدلال. برامج التقطيع خاصة بالنماذج. Opus 4.8 وFable 5 يتشاركان نفس البرنامج؛ النماذج القديمة تعدّ بشكل مختلف. لا تُعيد استخدام ميزانية قِيسَت على النموذج الخطأ.
الجزء الذي لا يحذّرك منه أحد: ملء النافذة يُدهور الجودة
إليك الجانب المعاكس للحدس. مجرد أنه يمكنك وضع مليون token لا يعني أنك ينبغي أن تفعل ذلك. النماذج تُولي اهتماماً أقل موثوقية للمعلومات المدفونة في وسط سياق طويل جداً، والسياق الصاخب يُخفّف الإشارة التي يحتاجها النموذج للخطوة الحالية. شاهدت وكيلاً بسياق نظيف من 20,000 token يتفوق على نفس الوكيل عند 400,000 token في المهمة المتطابقة، لأنه عند 400,000 token، 95% مما كان يُولي اهتمامه كانت مخرجات أدوات قديمة من اثنتي عشرة خطوة سابقة.
إذن الهدف ليس تعظيم ما تحشره. بل إبقاء السياق ملائماً. سقف المليون token هو هامش أمان للمدخلات الكبيرة حقاً — مستودع كامل تحتاج تحليله دفعة واحدة، مستند طويل، أثر بحث عميق. إنه ليس ترخيصاً للتهرب من التنظيف أبداً.
ثلاث أدوات للإبقاء على السياق ملائماً
هذه الأدوات تحل مشاكل مختلفة؛ اختر حسب ما هو مكسور.
تحرير السياق يقلّص. يمسح نتائج الأدوات والكتل التفكيرية القديمة من النص بناءً على عتبات تضبطها. المحتوى المُمسوح يُحذف، لا يُستبدل. ألجأ إليه حين تكون مخرجات الأدوات القديمة ثقلاً زائداً وتريد نصاً خفيفاً دون فقدان بنية المحادثة. إنه الخيار الصحيح للحفاظ على دقة استدعاء الأدوات في الحلقات الطويلة.
الضغط يُلخّص. حين تقترب محادثة من حد النافذة، تُكثّف الـ API التاريخ السابق في كتلة ملخّص من جهة الخادم. استخدمه حين ستصل فعلاً إلى السقف وتحتاج إلى الاستمرار. مشكلة حرجة واحدة: يجب أن تضيف response.content الكامل مجدداً إلى رسائلك في كل دورة — كتل الضغط تعيش هناك، وإذا استخرجت النص فحسب وأضفته، فإنك تفقد حالة الضغط بصمت وتنهار العملية برمتها.
الذاكرة تستمر عبر الجلسات. الأداتان الأخريان تعملان داخل محادثة واحدة؛ الذاكرة هي ملفات يقرأها الوكيل ويكتبها وتنجو من إعادة تشغيل العملية. حين يجب أن تعيش الحالة أطول من الجلسة — التفضيلات، التعلّمات المتراكمة، مفكّرة جارية — هذه ذاكرة، ليس سياقاً. وبصدق، نماذج كـ Opus 4.8 تؤدي أداءً ملحوظاً أفضل حين تعطيها مكاناً لكتابة الأشياء وتقول لها أن تتحقق منه في المرة القادمة.
كثير من الوكلاء طويلي الأمد يستخدمون الثلاثة. التحرير يقلّص الدورات الميتة، الضغط يُلحق بك قرب السقف، الذاكرة تحتفظ بما يهم بين التشغيلات.
مبدأ توجيهي للميزانية أفادني كثيراً
فكّر في سياقك على أنه ذو ثلاث مناطق. البادئة الثابتة (الـ prompt النظامي، الأدوات) — أبقِها مستقرة، لا تتغير أبداً، وكمكافأة تُخزَّن مؤقتاً. مجموعة العمل — الدورات الأخيرة التي يحتاجها النموذج فعلاً للخطوة الحالية. والذيل — السؤال الحالي أو نتيجة الأداة. حين تبدأ مجموعة العمل بالامتلاء بأشياء لم يُشر إليها النموذج منذ دورات كثيرة، هذه هي إشارتك للتحرير أو الضغط. ليس حين تصل إلى رقم tokens معين. حين تنخفض الملاءمة.
ملاحظة عملية أخيرة: المخرجات الكبيرة. إذا طلبت أي شيء قريب من سقف إخراج 128,000 token على نموذج Opus، يجب عليك بث الطلب. الاستدعاءات غير المبثوثة تصطدم بمهلات HTTP للـ SDK عند max_tokens العالية — الطلب يموت ببساطة وهو ينتظر. استخدم مساعد البث واسحب الرسالة النهائية منه.
نافذة المليون token قدرة حقيقية وأحياناً بالضبط ما تحتاجه. لكن المهارة ليست في ملئها. المهارة في معرفة متى سياق نظيف وملائم من 30,000 token سيتفوق على سياق منتفخ من 600,000 — وهو ما ثبت في تجربتي في بناء الوكلاء أنه الحال في معظم الأوقات.