كيف تقتصد وكلاء الذكاء الاصطناعي في الرموز عند التعامل مع قاعدة أكواد كبيرة: 5 أنماط

المشكلة: الرموز تذوب في الاستكشاف

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

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

خمسة أنماط لتحسين السياق

1. تقليل السياق الدائم (Minimize Permanent Context)

تتكرر قصة تراكم المعرفة بالشكل نفسه دائمًا: يُنشأ ملف AGENTS.md أو CLAUDE.md، ويبدأ المرء بوضع فيه كمية متزايدة من المعلومات. أولًا البنية وهيكل المستودع، ثم قواعد كتابة الكود، واتفاقيات الخدمات، وخصوصيات التعامل مع قاعدة البيانات والاختبارات وCI/CD والتكاملات.

المشكلة: تتحول هذه المجموعة كاملة إلى سياق دائم. فعند تعديل خدمة الفوترة (billing)، لا يحتاج الوكيل غالبًا إلى قواعد تطوير تطبيق الهاتف، لكن إن كانت موجودة في السياق العام، يحصل النموذج عليها مرارًا وتكرارًا. ينبغي أن تكون التعليمات العامة خريطةً للمشروع (أين تقع المعلومة؟) لا موسوعة (بماذا نُحدِّث عمومًا؟). يُشير ملف AGENTS.md الجذري إلى مكان التعليمات التفصيلية الخاصة بالمصادقة (auth) والفوترة (billing) وقاعدة البيانات (database) والبنية التحتية (infrastructure) - أما بقية المعلومات فتُحمَّل عند الطلب.

2. السياق التدريجي (Progressive Context)

تُنظَّم المعرفة في طبقات: السياق العام ← سياق المجال/الخدمة ← تعليمات خاصة بالمهمة ← تنفيذ مرجعي ← الكود المصدري ذو الصلة. ففي مهمة إضافة مزوّد دفع جديد، يمرّ الوكيل بالمسار: AGENTS.md ← services/payments/AGENTS.md ← skills/add-payment-provider.md ← تنفيذ مزوّد موجود ← ملفات المصدر ذات الصلة. أما بالنسبة لتطبيق الهاتف، فالمسار مختلف تمامًا، وللبنية التحتية مسار ثالث. وبدلًا من 20,000 رمز لـ«كل شيء عن المشروع»، يحصل الوكيل على: السياق العام (500) + سياق الخدمة (700) + تعليمات المهمة (600) + المرجع (800) + ملفات المصدر (2500). ويبقى الجزء الأكبر من معرفة المشروع منفصلًا ولا يدخل السياق إلا عندما يصبح ذا صلة.

3. تقليل الاستكشاف (Reduce Exploration)

حتى مع سياق دائم صغير، يبقى مصدر كبير لاستهلاك الرموز: استكشاف قاعدة الكود. فيحتاج الوكيل لمعرفة أين تقع معالجات الدفع، وأي خدمة تنشر الأحداث، وما هو وسيط الرسائل (message broker) المستخدم، وأين تقع المستهلكات (consumers)، وكيف تُنشأ الإشعارات، وأين القوالب، وكيف تُختبر. ويوفّر المستودع الجيد نقاط دخول: خريطة للمشروع مقسّمة إلى أقسام (معالجات HTTP: services//handlers/، منطق الأعمال: services//domain/ وغيرها)، وأمثلة مرجعية ذهبية (golden examples) (فعند إضافة مستهلك رسائل جديد، يوضح رابط إلى services/orders/consumers/order-created/ البنية، والتسمية، ومعالجة الأخطاء، والتسجيل (logging)، والتفاعل بين الطبقات، وطريقة الاختبار)، ومبدأ «البحث قبل القراءة» (search before read) (أي البحث أولًا عبر rg أو git grep أو أدوات LSP، ثم القراءة).

4. إعادة استخدام المعرفة (Reuse Knowledge)

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

ينبغي القضاء على هذا الازدواج المعرفي. فإذا كشف الاستكشاف عن خاصية مهمة وثابتة في النظام، يستحق هذا الاكتشاف أن يُحفظ في docs/payment-flow.md مع وصف مختصر، وقائمة بالملفات، ورابط إلى التنفيذ المرجعي.

بهذا، تبدأ جلسة الذكاء الاصطناعي التالية بمئات قليلة من الرموز لوصف منظّم، بدلًا من إعادة قراءة الملفات. تُحفظ المعرفة المفيدة في AGENTS.md، أو تعليمات الخدمة، أو الوثائق، أو مهارات خاصة بالمهام (skills)، أو ملاحظات البنية، أو أمثلة مرجعية، أو تعليقات الكود، تبعًا لنطاقها.

وتنتج عن ذلك دورة: اكتشاف مكلف ← معرفة منظّمة ← استرجاع رخيص لاحق.

5. حافظ على نظافة السياق (Keep Context Clean)

الجانب المعكوس للنمط السابق: إذا حُفظ كل اكتشاف مفيد، تنمو الوثائق باستمرار ويبدأ ما يسمى تلوث السياق (context pollution) - حيث تتعايش تعليمات بالية وأمثلة غير مُحدَّثة واتفاقيات منسيّة مع المعلومات الجديدة. ولا بد من تنظيف السياق بانتظام: حذف المعلومات المتجاوَزة، وتحديث الأمثلة، وإزالة الازدواجية. وكما هو الحال في الكود، من الأفضل حذف الوثائق المتجاوَزة بدلًا من تركها مع تعليق يُشير إلى تجاوزها.

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