Runtime-Structured Task Decomposition for Agentic Coding Systems
تقدم هذه الورقة البحثية تفكيك المهام ذو البنية التشغيلية، وهو نهج معماري لأنظمة البرمجة الوكيلية يستبدل المطالبات المتجانسة بمنطق تحكم قابل للتنفيذ لعزل الإخفاقات وإعادة تشغيل المهام الفرعية الفاشلة فقط، مما يقلل تكاليف إعادة المحاولة بنسبة تصل إلى 73.2% مقارنة بالتفكيك الاستاتيكي و51.7% مقارنة بالنماذج المرجعية المتجانسة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تحاول إصلاح آلة معطلة، ولكن بدلاً من وجود ميكانيكي بشري، لديك مساعد آلي ذكي جداً، ولكنه أخرق قليلاً (الذكاء الاصطائي).
المشكلة: الروبوت "الكل أو لا شيء"
تعمل معظم أنظمة البرمجة الحالية بالذكاء الاصطناعي مثل روبوت يحاول إصلاح الآلة بأكملها في عملية تفكير واحدة ضخمة ومستمرة.
- النهج المتجانس (Monolithic): تخبر الروبوت: "أصلح هذا المحرك بالكامل". فيبدأ بالتفكير في كل الخطوات دفعة واحدة.
- العيب: إذا ارتكب الروبوت خطأً صغيراً في الخطوة الثالثة (مثل تحديد برغي بشكل خاطئ)، فإن عملية التفكير بأكملها تنهار. ولأن الروبوت لم يقسم تفكيره إلى خطوات منفصلة، فعليه أن يبدأ من البداية تماماً، ويعيد قراءة جميع الكتيبات وإعادة التفكير في كل خطوة. هذا الأمر مكلف، بطيء، ومبذر.
الحل القديم "المُعالج": خط التجميع
تحاول بعض الأنظمة إصلاح ذلك عن طريق تقسيم المهمة إلى قائمة من الخطوات (الخطوة 1: انظر، الخطوة 2: أصلح، الخطوة 3: اختبر).
- النهج الثابت (Static): هذا يشبه خط تجميع جامد. إذا فشلت الخطوة 2، فلا يمكن للروبوت مجرد إصلاح الخطوة 2. ولأن خط التجميع ثابت، فعليه إعادة تنفيذ الخطوة 2، والخطوة 3، والخطوة 4 للوصول إلى النتيجة النهائية.
- المفاجأة: وجدت الورقة البحثية أن خط التجميع الجامد هذا هو في الواقع أسوأ من الروبوت "الكل أو لا شيء" في بعض الحالات! لأنه يضطر لإعادة تشغيل خطوات متعددة بعد الفشل، فينتهي به الأمر باستهلاك طاقة (رموز/Tokens) أكثر مما لو بدأ من الصفر تماماً.
الحل الجديد: "المدير الذكي" (تفكيك المهام بهيكل وقت التشغيل)
يقترح المؤلفون طريقة جديدة للعمل تسمى تفكيك المهام بهيكل وقت التشغيل (RSTD). تخيل مديراً للمشروع لا يكتفي بإعطاء الأوامر فحسب، بل يراقب العمل بنشاط.
- مهام صغيرة ومحققة: بدلاً من أمر واحد ضخم، يقوم المدير بتفكيك المهمة إلى مهام صغيرة ومحددة (مثلاً: "ابحث عن الخطأ"، "اكتب الإصلاح"، "تحقق من الإصلاح").
- قاعدة "التوقف والتحقق": بعد كل مهمة صغيرة، يقوم المدير بالتحقق من العمل فوراً.
- إذا كان العمل جيداً، ينتقل المدير إلى الخطوة التالية.
- إذا كان العمل سيئاً (على سبيل المثال، خطوة "البحث عن الخطأ" أغفلت شيئاً ما)، فإن المدير يرسل الروبوت فقط لإصلاح تلك الخطوة المحددة.
- لا إعادة قراءة: لا يضطر الروبوت لإعادة قراءة الكتيب بالكامل أو إعادة تنفيذ الخطوات التي أتمها بشكل صحيح. هو فقط يصلح ذلك الجزء المكسور.
النتائج: توفير الطاقة
اختبر الباحثون هذا على مشكلتين حقيقيتين في البرمجيات: إصلاح كود يحتوي على أخطاء متعددة، ومعرفة سبب تعطل خادم كمبيوتر (Server). وقارنوا بين ثلاثة أساليب:
- المفكر الضخم (المتجانس).
- خط التجميع الجامد (الثابت).
- المدير الذكي (RSTD).
ما وجدوه:
- كان خط التجميع الجامد هو الأكثر تكلفة. فعندما يرتكب خطأً، يضطر لإعادة تنفيذ ثلاث أو أربع خطوات، مما يكلف 80% أكثر من الطاقة مقارنة بالبدء من الصفر.
- المدير الذكي كان هو الفائز. فعندما يرتكب خطأً، يعيد تنفيذ الخطوة المكسورة الواحدة فقط.
- في اختبار تعطل الخادم، وفر 51% من الطاقة مقارنة بـ "المفكر الضخم".
- وفر 73% من الطاقة مقارنة بـ "خط التجميع الجامد".
العقبة
هناك مقايضة بسيطة. يتطلب نهج "المدير الذكي" قدراً أكبر قليلاً من الإعداد والتواصل بين المدير والروبوت، حتى عندما تسير الأمور على أكمل وجه. لذا، إذا لم يرتكب الروبوت أي خطأ أبداً، فقد يكون "المدير الذكي" أبطأ قليلاً من "المفكر الضخم".
ومع ذلك، في العالم الحقيقي، الأخطاء تحدث. وتخلص الورقة البحثية إلى أنه من خلال بناء أنظمة يمكنها التوقف، والتحقق، وإصلاح الجزء المكسور فقط، فإننا نوفر قدراً هائلاً من الوقت والمال عند حدوث الأخطاء. إنها تحول نظام "الانهيار وإعادة التشغيل" إلى نظام "الإصلاح والاستمرار".
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.