كيف يحل Codex مشكلة الضغط بطريقة مختلفة

إن استخدمت Claude Code في جلسة برمجة حقيقية، فلا بد أنك رأيت الرسالة: “Compacting conversation…” تظهر في الطرفية، وبعدها مباشرة يبدأ الشيء الغريب. النموذج ينسى ما ناقشته قبل عشر دقائق. زمن الاستجابة يرتفع. تسأل عن دالة أعدت هيكلتها للتو معاً، فيجيبك وكأنه يسمع عنها لأول مرة.

يحدث هذا لأن نافذة السياق بسعة 200K token في Claude Code تمتلئ أسرع مما يتوقع معظم الناس. جلسة إعادة هيكلة كبيرة، بضع عمليات قراءة لملفات، واستدعاءات أدوات بمخرجات طويلة، وإذا بك عند الحد الأقصى. حين تصل إلى العتبة — نحو 75-92% من النافذة، وإن كنت رأيتها تُطلق عند 65% — يلخص Claude Code المحادثة، ويتخلص من الرسائل الأصلية، ويكمل بالملخص وحده. أي معلومة لم تُدرج في الملخص ذهبت إلى غير رجعة.

كنت أسمع باستمرار أن Codex من OpenAI يتعامل مع هذه المشكلة بطريقة مختلفة، فأمضيت وقتاً في تفكيك كل تحليل عام متاح. أكثر الأعمال إثارةً كان لـ Kangwook Lee، كبير مسؤولي الذكاء الاصطناعي في Krafton، الذي استخدم حقن prompt لعكس هندسة الـ pipeline الفعلي.

ما الذي يفقده الضغط ولماذا يهم

المشكلة الجوهرية بسيطة. التلخيص ضغط بالفقدان. حين يضغط Claude Code، يُشغّل تلخيصاً في الخلفية للمحادثة كاملة، يُنشئ كتلة ضغط، ويتخلص من كل شيء قبلها. ملفات CLAUDE.md تنجو لأنها تُعاد قراءتها من القرص، لكن أي شيء قلته في المحادثة فقط يختفي ما لم يلتقطه المُلخِّص.

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

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

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

داخل pipeline الضغط المشفر في Codex

تحليل Kangwook Lee كان ذكياً. استخدم حقنتين متسلسلتين في الـ prompt لاستخراج السلوك الداخلي لنظام الضغط في Codex.

الحقنة الأولى استهدفت نموذج الضغط نفسه. حين يُطلق Codex عملية الضغط، لا يلخص محلياً. يُرسل المحادثة إلى نموذج لغوي منفصل على خوادم OpenAI يُنتج ملخصاً. حقنة Lee خدعت هذا المُلخِّص ليُدرج system prompt الخاصة به في مخرجات الملخص. ثم شفّر الخادم هذا الملخص — الذي يحتوي الآن على الـ prompt المُسرَّبة — بـ AES وأعاده كـ blob معتم.

الحقنة الثانية استغلت خطوة فك التشفير. بتمرير الـ blob المشفر إضافةً إلى رسالة مستخدم مُعدَّة خصيصاً إلى Responses API، فك الخادم تشفير الـ blob وجمع سياق النموذج. ولأن الحقنة الأولى أدمجت system prompt المُلخِّص داخل الملخص، كشف السياق المُفكَّك تشفيره عن آلية عمل الـ pipeline بأكملها.

هذا ما وجده: حين تستدعي compact() API في Codex، نموذج لغوي منفصل يلخص المحادثة، وتعود النتيجة مشفرة بـ AES. في الدورة التالية، يفك الخادم تشفير هذا الـ blob، يُضيف prompt تسليم (“هذا ملخص المحادثة السابقة”)، ثم يُغذّي كل شيء للنموذج. مفتاح التشفير يعيش على خوادم OpenAI. العميل لا يرى الملخص بصيغته غير المشفرة أبداً.

تبيّن أن prompt الضغط نفسه شبه مطابق لقالب الضغط في Codex CLI مفتوح المصدر للنماذج غير-Codex. لا صلصة سرية في هندسة الـ prompt. الجزء المثير للاهتمام هو المعمارية: تشفير ملخصات من جانب الخادم، فك تشفير وحقن من جانب الخادم، وـ blob معتم يمرّره العميل دون أن يستطيع فحصه أو تعديله.

لماذا التشفير أصلاً؟ لم يُجب تحليل Lee على هذا بشكل قاطع. نظرية أولى هي أن الـ blob المشفر يحتوي على أكثر من مجرد ملخص نصي: بيانات استعادة استدعاءات الأدوات، علامات الحالة الداخلية، أو بيانات وصفية منظمة لا تريد OpenAI الكشف عنها. احتمال آخر هو ببساطة أن الـ blobs المشفرة تمنع المستخدمين من التلاعب بالملخص للتأثير على سلوك النموذج. أجد التفسير الثاني أرجح، لكن لا شيء مؤكد.

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

قارن هذا بنهج Claude Code: كتلة الضغط قابلة للقراءة البشرية. يمكنك فحصها، ويمكنك تخصيص سلوك الضغط عبر معامل instructions أو بإضافة توجيهات ضغط مخصصة إلى CLAUDE.md. أكثر شفافية، لكن فقدان المعلومات الجوهري ذاته ينطبق عليه.

نمط تسليم الجلسة

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

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

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

ثم ثلاثة sub-agents تعمل بالتوازي، كل منها يبحث في سجلات JSONL الأصلية غير المضغوطة عن معلومات أغفلها الاستخراج. تبحث عن الثغرات: قرارات معمارية نوقشت لكن لم تُلتقط في رسائل المستخدم، أنماط أخطاء ظهرت فقط في مخرجات الأدوات، مسوّغات نُهج جرى رفضها. تجمع هذه الوكلاء نتائجها في ملف resume-prompt.md يحتوي على ملخص الجلسة، نتائج تحليل الثغرات، وقائمة الملفات المُعدَّلة.

file watcher في VS Code يكتشف الملف الجديد resume-prompt.md ويفتح جلسة جديدة تحمّله كسياق أولي. الجلسة الجديدة تبدأ بصورة واضحة ومكتملة عن المكان الذي توقفت عنده الجلسة السابقة.

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

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

KV cache بوصفه رافعة التكلفة الخفية

ثمة بُعد أداء تفوّت معظم النقاشات الإشارة إليه كلياً. KV cache — أزواج المفاتيح-القيم المحسوبة أثناء آلية الانتباه — يمكن إعادة استخدامها عبر الطلبات حين يكون بادئة الـ prompt متطابقة. طلبان يتشاركان نفس الرموز الافتتاحية يتخطيان إعادة الحساب لتلك الرموز.

الأرقام لافتة. في اختبار مضبوط يقارن system prompts ثابتة ومضطربة، حققت البادئات الثابتة معدل إصابة بالـ cache بنسبة 85% مع متوسط زمن أول رمز بلغ 953ms. البادئات المضطربة: 0% إصابة بالـ cache، و2,727ms TTFT. انخفض تكلفة الطلب الواحد من 0.033 دولار إلى 0.009 دولار. هذا تخفيض 65% في الزمن و71% في التكلفة من مجرد الحفاظ على بادئة الـ prompt ثابتة.

لهذا تداعيات مباشرة على نمط تسليم الجلسة. إذا كان ملف resume-prompt.md يبدأ دائماً بنفس البادئة الهيكلية — system prompt، تعليمات التسليم، ثم المحتوى المتغير — يُخزَّن الجزء الثابت في الـ cache. كل طلب لاحق في الجلسة الجديدة يستفيد من ذلك الـ cache. إن عشوائت بنية البادئة أو أدرجت محتوى متغيراً في مرحلة مبكرة، كل طلب يُعيد الحساب من الصفر.

صممت هيكل مجلدات جلساتي حول هذه الفكرة. الأرشفة المبنية على معرّف الجلسة تُبقي وثائق التسليم منظمة، واتفاقية البادئة الثابتة في prompts الاستئناف تعني أن أول 40-50K token من كل جلسة جديدة تُصيب KV cache. الفهرسة المسبقة لأرشيفات الجلسات بـ QMD — الذي تناولته بالتفصيل في مقالة منفصلة — يُسرّع خطوة الاسترجاع حين تحتاج الـ sub-agents إلى البحث في الجلسات التاريخية.

ما الذي يهم فعلاً

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

ما يهم هو ما تبنيه حول هذا القيد. نمط تسليم الجلسة، تحليل الثغرات، الاسترجاع القائم على JSONL، تحسين KV cache: هذه حلول هندسية لمشكلة لن يحلها أي قدر من تحسّن النماذج حلاً كاملاً. نافذة سياق بسعة 500K أو مليون token تؤخر المشكلة لكن لا تُزيلها.

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

تفاصيل تقنية مستقاة من تحليل Kangwook Lee وتوثيق API العام من OpenAI وAnthropic.