Claude Code وCodex يغيّران القواعد: هندسة السياق تحل محل الـ prompts

نشر موقع Habr AI تحليلًا مطوّلًا حول Context Engineering، وأطروحته الرئيسية عملية إلى أبعد حد: في الأدوات الوكيلية مثل Claude Code وCodex وCursor، لم تعد جودة النتيجة تعتمد على صياغة الطلب بقدر ما تعتمد على البيئة المحيطة بالنموذج بأكملها. فنص المستخدم نفسه يشغل حصة ضئيلة من السياق، أما التأثير الحاسم فيعود إلى الـ system prompt وتعليمات المشروع والذاكرة بين الجلسات والأدوات وسجل الحوار ونتائج استدعاء الأدوات. بعبارة أخرى، يغيب عصر «الـ prompt السحري»، ويحل محله تصميم السياق.

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

ويفسّر المؤلف سبب ذلك عبر معمارية Transformer. فآلية attention في صيغتها الأساسية ذات تعقيد تربيعي O(n^2): يجب أن يُقارَن كل token بكل token آخر. لذلك فإن إضافة المستندات والملفات والمراسلات الطويلة لا ترفع التكلفة خطيًا، بل تربيعيًا. وعمليًا ينعكس ذلك على أربعة معايير في آن واحد: سرعة الاستجابة، والتكلفة، والحدود المسموحة، والدقة. ومن هنا الأطروحة الأساسية: الـ context engineering الجيد لا يعني «حشر كل شيء في النموذج»، بل انتقاء الحد الأدنى من الـ tokens عالية الإشارة بما يرفع إلى أقصى درجة فرصة الحصول على النتيجة المطلوبة.

ثم ينتقل التحليل إلى مكوّنات السياق في الأنظمة الوكيلية. فإلى جانب أوزان النموذج نفسها، هناك عدة طبقات قابلة للتحكم على الأقل: الـ system prompt، وملفات المشروع مثل CLAUDE.md أو AGENTS.

md، والذاكرة الخاصة بالمستخدم والمشروع، وskills التي تحوي عمليات جاهزة، وتكاملات MCP، والملفات التي تُحمَّل بشكل موجّه، وكامل سجل tool_result. ويشدد المقال بوجه خاص على أن النموذج لا «يتذكر» المحادثة من تلقاء نفسه: فالـ harness يعيد في كل مرة تجميع السجل وإرساله إليه من جديد. ولهذا يبدأ كل وصف أداة زائد، وكل خادم MCP غير ضروري، وكل ملف نظامي طويل باستهلاك الـ tokens مرارًا.

ولتوفير التكلفة يلزم استخدام prompt cache، وcompact مدروس، وبدء جلسات جديدة عبر clear، وعزل الأبحاث الثقيلة في subagents، كي يتلقى الوكيل الرئيسي خلاصة قصيرة بدلًا من جبال من البيانات الوسيطة.

والجزء الأكثر عملية يخص تكلفة الوضع الوكيلي. فقد لا يكون طلب واحد إلى الوكيل استدعاءً واحدًا للنموذج، بل سلسلة من عدة استدعاءات مع tool use. ففي مثال تحليل عملية نشر (deploy) فاشلة، تتحول رسالة مستخدم واحدة إلى أربعة استدعاءات للنموذج وثلاثة تنفيذات للأدوات. وبدون التخزين المؤقت تصبح دورة كهذه بلا جدوى اقتصادية بسرعة؛ ومع prompt cache ينخفض السعر بشكل حاد، لكن حتى حينها ينبغي تذكّر أن output-tokens وthinking المخفي أغلى من input العادي، وأن تعريفات الأدوات (tool definitions) الطويلة والتعليمات النظامية تدخل في كل جولة.

ومن هنا استنتاج المؤلف: الخبير لا يتميز بكتابة prompts أكثر دهاءً، بل بأنه يبني مرة واحدة بيئة قابلة للتكرار — بقواعد المشروع والذاكرة والأدوات ذات الصلة والعمليات — ثم يُلزم الوكيل بالعمل وفق هذا «العقد».

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