Anthropic وETH Zurich: ملف CLAUDE.md الطويل يضعف أداء الوكيل ويرفع التكاليف

صُمّم الملفان CLAUDE.md وAGENTS.md ليكونا وسيلة سريعة لشرح قواعد المشروع للوكيل، لكن دراسة جديدة تُظهر أن السياق الطويل يضر في أغلب الأحيان أكثر مما ينفع. ففي عينة من 138 مستودعًا بلغة Python، رصد باحثو ETH Zurich انخفاضًا في معدل النجاح (success rate) وارتفاعًا في التكاليف، خصوصًا مع الملفات المولَّدة تلقائيًا.

ماذا أظهرت الدراسة

أخذ مؤلفو بحث Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? 138 مستودعًا حقيقيًا، وجمعوا 5694 طلب دمج (pull request)، ثم شغّلوا المهام عبر أربعة نماذج: Claude Sonnet 4.5 وCodex GPT-5.2 وGPT-5.1 Mini وQwen3-30B. وقارنوا بين ثلاثة سيناريوهات: بلا ملفات خاصة، ومع تعليمات مولَّدة بواسطة LLM، ومع ملفات AGENTS.md يتولى صيانتها بشر. وهذه نقطة مهمة: فالدراسة لم تعتمد على عروض توضيحية مجردة، بل على مهام حقيقية من قواعد شيفرة قائمة.

جاءت النتيجة الرئيسية للملفات المولَّدة تلقائيًا غير مريحة. فقد انخفض معدل النجاح في المتوسط بنسبة 3%، وارتفعت تكلفة الاستدلال (inference cost) بأكثر من 20%. أما الملفات التي كتبها البشر فكان أداؤها أفضل: رفعت النجاح بنحو 4% تقريبًا، لكن السعر ارتفع أيضًا بنحو 19%. أي أن ملف السياق لم يتبيّن أنه مُسرِّع مجاني. وحتى عندما يفيد، يبقى مكسب الجودة متواضعًا مقارنةً بالدفع الزائد الدائم مقابل الرموز (tokens) والخطوات الإضافية التي ينفذها الوكيل.

لماذا يضر الملف الطويل

أكثر ملاحظات الدراسة مخالفةً للبديهة أن أوصاف بنية المشروع لا تساعد الوكيل تقريبًا على التوجه داخل المستودع. فالأقسام التي تشرح المجلدات والبنية المعمارية والحزمة التقنية تبدو مفيدة للإنسان، لكن الوكيل يجد كل ذلك غالبًا بنفسه عبر grep وglob وقراءة الملفات. وإذا كانت المعلومة موجودة أصلًا في pyproject.toml أو package.json أو إعدادات أداة فحص الشيفرة (linter) أو في بنية المستودع ذاتها، فإن الشرح الطويل لا يفعل سوى تكرار ما يستطيع النموذج اكتشافه بسرعة بمفرده.

إذا كان بوسع الوكيل أن يعرف ذلك من الشيفرة بنفسه، فالأفضل حذفه من التعليمات.

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

ما الذي يستحق الإبقاء

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

• أمر تشغيل الاختبارات غير القياسي
• مدير الحزم، إذا لم يكن واضحًا
• السكربتات والأدوات المخصصة وخصوصيات النشر (deploy)
• قواعد التسمية، إذا تعذّر استنتاجها سريعًا من الشيفرة
• رابط إلى .env.example أو أي ملف مدخل حيوي آخر

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

كما أن دراسة ETH Zurich لا تتناول تقريبًا قابلية صيانة الشيفرة ولا الالتزام بأسلوب المشروع، ولذلك لم يُحسم بعد الجدل حول فائدة هذه الملفات.

ماذا يعني ذلك

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

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