مطوّر يراقب الوكلاء في شيفرته شهرًا: شجرة الملفات أغلى من JSON

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

المقال الأصلي متاح على هيئة إعلان تمهيدي، لذلك نستعرض أدناه الأطروحات المعلنة والمنطق الهندسي الكامن وراءها. أما قياسات المؤلف الدقيقة فمن الأفضل الاطلاع عليها في المصدر الأصلي.

لماذا الشجرة أغلى من JSON

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

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

مجلد build وكلمات المرور

يتعلق الدرس الثاني بالتصفية. تبدو قاعدة «تخطَّ المجلدات التي اسمها build» معقولة، إلى أن يظهر في المشروع دليل بالاسم نفسه يحتوي على الشيفرة المصدرية لا على نواتج البناء. والأكثر موثوقية أن تنظر إلى ما يفعله المجلد: هل هو مُدرج في .gitignore، وهل يولّده البناء، ومتى جرى تعديله آخر مرة.

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

وكيل بلا رقابة

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

• صيغة وصف المشروع: الشجرة النصية أغلى من JSON.
• المرشِّحات: اسم المجلد لا يصلح معيارًا وحيدًا.
• الأسرار: إخفاء القيم بدل حذف الأسطر.
• قناة النقل: خادم MCP نقطة موحدة للتحكم فيما يراه الوكيل.
• المخاطرة: نمو السياق دون ضبط في الجلسات الطويلة.

من أين تبدأ فحص مشروعك

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

ثم قارن بين الصيغ. مرّر المستودع نفسه عبر الشجرة وعبر JSON مضغوط، وقارن عدد الرموز. بعد ذلك أعد النظر في قواعد الاستبعاد: اعتمد على .gitignore وعلامات الملفات المولَّدة، لا على قائمة أسماء.

وأخيرًا، فعّل إخفاء الأسرار قبل إرسال البيانات إلى الوكيل لا بعده. وتحقق من أن ملف الإعدادات المُخفاة قيمه ما زال يمرّ عبر المحلِّل. وحدّد للوكيل ميزانية: حدًّا لحجم السياق ولعدد مرات إعادة قراءة الملف الواحد. بهذا يتحول شهر من المراقبة إلى مجموعة قواعد، لا إلى مفاجأة عابرة.