Habr AI: كيف تولّت نماذج LLM المكلفة إدارة الحالة وخفّضت تكاليف التطوير

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

حيث أخفقت الوكلاء

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

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

لماذا غيّر الأدوار

لاحظت الفريق أثناء الاختبارات أن نماذج مختلفة لديها بالفعل "طباع" عمل متميزة. يتصرف Gemini 3 Pro مثل مطور واثق جداً ويمكن أن ينحرف عن المواصفات الأصلية. MiniMax M2.5، على النقيض من ذلك، حذر ويقرأ نصف المشروع قبل اتخاذ الخطوة الأولى. أظهرت Claude Sonnet 4.6 أفضل توازن بين الاستقلالية والانضباط، لكن استخدامها في كل إجراء صغير تبين أنه مكلف جداً للشركات الناشئة.

وهنا نمت الفكرة الجديدة: يجب تعيين نموذج قوي ليس للروتين، بل للسيطرة.

"المدير التنفيذي لا يجري مكالمات باردة."

بدلاً من مخطط حيث تكتب نماذج اللغة الكبيرة المكلفة أعقد الأكواد، أدخلت الفريق عدة قواعد صارمة:

• وكيل واحد يقود مواصفة واحدة من البداية إلى النهاية ويصحح أخطاءه الخاصة.
• يعمل الوكيل فقط مع "مقعد عمل" محدود من 5-8 ملفات، وليس المستودع بأكمله.
• عند إغلاق ملف، يحفظ ذاكرة موجزة للنتائج المفيدة لتجنب سحب كود المصدر كاملاً إلى السياق.
• النموذج الأكثر ذكاءً لا يكود مباشرة، بل يعمل كمدير حالة للعامل الرخيص.

كيف يعمل المدير

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

يقوم مدير الحالة بأربعة أشياء بالتتابع:

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

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

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

تأثير إضافي — تبدأ الاختبارات والتوثيق في الظهور مع المهمة بشكل افتراضي، ويتحول المطورون من دور المنفذين اليدويين إلى دور المشغلين والمعماريين للعملية.

ماذا يعني هذا

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

بالنسبة للفريق التي تم حرقها بالفعل من قبل "مبرمجي مستقلين"، هذا واحد من أكثر الاستنتاجات المعمارية عملية في الأشهر الأخيرة.