وكيل الذكاء الاصطناعي لديك ينسى كل شيء: حيل MCP التي تعالج تضخم السياق

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

ذاكرة تعمّر أطول من الجلسة
النصف الآخر من المشكلة أن الوكلاء ينسون بين الجلسات، لا داخل الجلسة فحسب. أغلق الطرفية ويذهب السياق. أعد فتحها غدًا فلا يكون للوكيل أي فكرة عمّا قررته، ولا عن النهج الذي رفضته، ولا عن سبب كون الشيفرة على ما هي عليه. تعيد الشرح، ويعيد الوكيل الاستنتاج، وفي مكان ما يُتخذ القرار مرتين.
أدوات الذاكرة الدائمة في هذا المجال تتبع مقاربات مختلفة. أحد أبرزها يلتقط ما يفعله الوكيل أثناء الجلسة، ويضغطه بنموذج، ويحقن الأجزاء ذات الصلة في الجلسات المقبلة. الطرح غير براق لكنه صحيح: وكيل يتذكر شكل مشروعك أثمن من وكيل أذكى قليلًا في مهمة واحدة. وقد تحرّك كبار مزوّدي النماذج في الاتجاه نفسه، مضيفين مفاتيح تسمح للـ subagent بضغط context الخاص به أسبق من المحادثة الأصلية، تحديدًا حتى لا يحمل تاريخ الجلسة كله إلى مهمة لا تحتاج منه شيئًا.
السؤال التصميمي المثير هنا هو ماذا نتذكر. تذكّر كل شيء فأنت قد أعدت بناء المشكلة الأصلية في صورة أبطأ. تذكّر أقل من اللازم فتكون الذاكرة عديمة الفائدة. المشاريع التي تكتسب زخمًا هي التي تتذكر انتقائيًا، على أساس أن ملخصًا جيدًا للشهر الماضي يتفوق على سجل مثالي للساعة الماضية.
التوجيه (routing) كاستراتيجية سياق
القطعة الثالثة من الأحجية هي التوجيه (routing): أن تقرر، قبل تشغيل مهمة، أي نموذج وأي أدوات تحتاجها، حتى لا تُحمّل بقدرات لن تستخدمها أبدًا. النموذج الذي أُخبر بسبعة عشر تكاملًا مختلفًا ينفق السياق على السبعة عشر حتى لو كانت المهمة تحتاج واحدًا فقط. فرض التوجيه عبر المنصات يبدو كتفصيل بنية تحتية. لكنه في الحقيقة قرار ميزانية سياق متنكّر.
هنا تتوقف المشكلة عن الظهور كمشكلة تخزين مؤقت وتبدأ بالظهور كتصميم أنظمة. نافذة السياق لدى الوكيل مورد، تمامًا كما الذاكرة والقرص موردان، والأدوات التي تعاملها كذلك هي التي تُبقي الوكلاء متماسكين في المهام الطويلة. وليس مصادفة أن تتقارب مشاريع الـ sandboxing والذاكرة والتوجيه: إنها ثلاث زوايا للندرة نفسها.
نمط الـ subagent هو أوضح مثال. عندما يولّد وكيل مساعدًا لمهمة ضيقة، لا يحتاج ذلك المساعد إلى أن يرث المحادثة بأكملها. تسليمه سياقًا نظيفًا لا يحوي إلا المهمة الحالية أرخص وأدق، ولهذا تسمح أطر العمل (harnesses) الأحدث للـ subagent بضغط context الخاص به أسبق من الأصل. الأصل يحتفظ بالتاريخ الطويل؛ والابن يحصل على مكتب جديد. الفرق التي شغّلت وكلاء في إعادة هيكلة تمتد أسبوعًا تصل عادة إلى هذه القاعدة من تلقاء نفسها، غالبًا بعد مشاهدة subagent ينفق نافذته كاملة في إعادة قراءة محادثة لم يكن يحتاجها.
لماذا يظهر هذا الآن
لا شيء من هذه المشكلات جديد. الوكلاء يفقدون السياق منذ أول وكيل عمل. ما تغيّر أن الوكلاء صار يُتوقع منهم العمل ساعات، عبر جلسات كثيرة، على عمل يهم. اللعبة لا تخسر شيئًا حين تنسى. أما أداة يعتمد عليها فريق في إعادة هيكلة تمتد أسبوعًا فتخسر الكثير.
السوق انتبه. قبل سنتين كان "وكيلنا يمتلك نافذة سياق بسعة 200k" نقطة بيع. الآن السؤال المفيد هو ما نسبة تلك النافذة المصروفة على الإشارة. المزوّدون الذين يدركون هذا يطلقون أدوات تحكّم في الضغط وعزل سياق الـ subagent. والمجتمع يطلق السباكة التي تجعل بقية الأمر مُحتملًا.
الخاتمة غير البراقة
هناك إغراء بأن نقرأ أخبار الوكلاء في أكتوبر كقصة عن نماذج أذكى وإضافات أذكى. لكن القصة الأهدأ والأمتن تدور حول النظافة (hygiene). صارت الوكلاء مفيدة بما يكفي لتعمل فترات طويلة، والفترات الطويلة تكشف كل ضعف في طريقة إدارتها لذاكرتها.
المشاريع التي تتسلق قوائم الرائج هي التي تقبل حقيقة عادية: عنق زجاجة العمل المستقل نادرًا ما يكون الذكاء الخام، بل القدرة على البقاء في المهمة دون أن يغرق الوكيل في ملاحظاته. أصلح الذاكرة، واحصر الضجيج في sandbox، ووجّه القدرات، فيبدو نموذج كفؤ فحسب ممتازًا فجأة. أخطئ في ذلك فيقضي حتى نموذج متقدم (frontier) عصرَه في إعادة قراءة ملف سجل قرأه خمس مرات سابقًا.
مقالات ذات صلة
الوكيل المستقل عن harness: تشغيل أي نموذج حدودي على جهازك
النموذج هو الذكاء، والـ harness هو السباكة، ولا حاجة لأن يسكنا الحزمة نفسها. مجموعة من المشاريع مفتوحة المصدر تفصل بينهما لتشغيل أي نموذج حدودي من الواجهة التي تفضّلها، مع إبقاء الوصول محليًا افتراضيًا.
بت واحد يكفي: لماذا يواصل BitNet من مايكروسوفت كسب القلوب
وزن البت الواحد ليس حيلة. كيف يستبدل نظام BitNet الثلاثي من مايكروسوفت الضرب بالجمع، ويشغّل النماذج الكبيرة على وحدة معالجة مركزية عادية، وبأي ثمن.
الدليل التنظيمي الجديد لفيديو الذكاء الاصطناعي: علامات قابلة للقراءة الآلية بموجب قانون الذكاء الاصطناعي الأوروبي
تجعل المادة 50 من قانون الذكاء الاصطناعي الأوروبي بيانات المصدر الوصفية مسألة امتثال. العلامة تُدمج عند الإنتاج ويُفقدها خط الإنتاج بسهولة.
غوغل تُحيل كل نقاط نهاية Veo إلى التقاعد: كواليس تغيير الفيديو في 22 أكتوبر
ستوقف غوغل في 22 أكتوبر 2026 كل نقاط نهاية Veo في Gemini API، بما فيها veo-3.1-lite-generate-preview، وتستبدلها بـ gemini-omni-1.1-flash المفوتر بالرمز.