Searchable transcript of Your Coding Agent Can't Undo Its Own Mistakes - Tanmay Sah & Dolly Sah — AI Engineer (16:38). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by AI Engineer. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 مرحباً بالجميع. أنا تانماي. تنضم إليّ اليوم دولي، وسنقدم "زر التراجع " المفقود لوكلاء البرمجة. لنتخيل وكيل برمجة يعمل على مشكلة في مستودع برمجيات. يطبق الوكيل التصحيح، ويجري الاختبارات، وتنجح جميعها. حتى أنه ينشئ علامة إصدار، لكن التكامل اللاحق يفشل. والآن، إليكم السؤال. هل يمكن للوكيل حقاً إعادة كل شيء إلى الحالة التي كان عليها من قبل؟ يمكن لـ Git إخبارنا بما تغير في المستودع ، ولكن ماذا عن التغييرات خارج Git، مثل استدعاءات واجهة برمجة التطبيقات الخارجية ، أو إعدادات وقت التشغيل، أو الإشعارات؟ وإعادة محاولة تنفيذ
00:56 عملية ما ببساطة لا تعني بالضرورة التراجع عما حدث بالفعل. لذا، أردنا أن نفهم ليس فقط ما إذا كانت الوكلاء قادرة على إكمال المهام، بل ما إذا كانت قادرة على التعافي عند حدوث خطأ ما. هذا يقودنا إلى أول أعمالنا البحثية، Undo Bench. أردنا التحقيق فيما إذا كانت قدرة الوكيل على إكمال المهمة تترجم أيضاً إلى قدرته على التعافي من الفشل. قمنا بتقييم الوكلاء عبر 2880 تجربة مقترنة، مقارنين بين التنفيذ العادي والتنفيذ في ظل فشل مفتعل.
01:49 في الظروف العادية، حقق الوكيل معدل نجاح بنسبة 84%، ولكن عندما أدخلنا حالات فشل، تعافت 47%فقط من التجارب الناجحة عادةً بنجاح. لاحظ أن هاتين النسبتين المئويتين لهما مقامات مختلفة، لكن نعم، حتى عندما يستطيع الوكيل إكمال مهمة بنجاح، يظل التعافي تحدياً كبيراً. الآن، دعونا ننظر في سيناريو فشل محدد. تخيل وكيل برمجة يرسل طلباً إلى نظام خارجي لإنشاء تذكرة. تم إرسال الطلب والوكيل ينتظر رداً.
02:40 بعد ذلك، يستلم الخادم الطلب وينشئ التذكرة رقم 781 بنجاح، لكن إشعار الاستلام يضيع في طريقه إلى الوكيل. من وجهة نظر الوكيل، انتهت مهلة الطلب، لكن الوكيل لا يعلم أن التذكرة قد تم إنشاؤها بالفعل. انتهاء المهلة يخبرنا أن الرد لم يصل، وليس أن العملية قد فشلت. لذا، يعيد الوكيل محاولة الطلب دون التحقق مما إذا كانت العملية الأولى قد تم تنفيذها. والآن لدينا تذكرتان على الرغم من أن الوكيل كان ينوي إنشاء تذكرة واحدة فقط.
03:27 في Undo Bench، أنتجت عمليات إعادة المحاولة الساذجة تأثيرات مكررة في 54%من هذه الأنواع من التجارب. لهذا السبب نحتاج إلى التمييز بين الاستجابة الفاشلة والعمليات الفاشلة. الآن، مرحلة الفشل تغير الإجابة أيضاً. ما أعنيه هو أن التعافي يعتمد أيضاً على توقيت حدوث الفشل. قبل التغيير، تكون إعادة المحاولة آمنة بشكل عام لأنه لم يتغير شيء. ولكن، أثناء التغيير، ربما يكون النظام قد تعدل جزئياً ، لذا نحتاج إلى فحص حالته.
04:13 وبعد التغيير ، ربما تكون العملية قد اكتملت حتى وإن فُقد تأكيد الاستلام. كما رأينا للتو، قد تؤدي إعادة المحاولة إلى إنشاء نسخ مكررة . لذا، نحتاج إلى استراتيجيات تعافٍ مختلفة اعتماداً على مرحلة الفشل. الآن، لماذا لا يمكننا ببساطة استخدام أمر Git revert؟ حسناً، يمكن لـ Git استعادة تغييرات المستودع، لكن وكلاء البرمجة يعدّلون أيضاً حالة وقت التشغيل، بما في ذلك سجلات الأدوات والبرمجيات الوسيطة والإعدادات.
04:59 كما يمكنهم أيضاً إحداث تأثيرات خارجية مثل النشر أو الكتابة في قاعدة البيانات. لذا، لا يقوم Git revert بعكس كل هذه التغييرات. يجب أن تتوافق آلية التعافي مع نوع التأثير الذي أحدثه الوكيل. ويصبح هذا مهماً بشكل خاص عندما يبدأ وكلاء البرمجة في تعديل بيئة تنفيذهم، أو ما نسميه بصلابة الوكيل. يشمل ذلك المطالبات، والأدوات، والبرمجيات الوسيطة، ومستمعي الأحداث، والموارد، وتكوينات التوجيه.
05:41 قد تؤدي مثل هذه التغييرات إلى تحسين أداء الوكيل، لكنها قد تجعل التعافي أكثر صعوبة. بعبارة أخرى ، يمكن أن يصبح الوكيل أكثر قدرة بينما يصبح أقل قابلية للاستعادة. ولهذا السبب، يحتاج التراجع إلى أكثر من مجرد أمر عكسي. الآن، ليس التراجع عن تغيير ما دائماً بالبساطة التي يبدو عليها عكس أمرٍ ما. لنفترض أن وكيلاً قام بتغيير مهلة زمنية من 30 إلى 60. للتراجع عن هذا التغيير، يحتاج إلى معرفة أن القيمة الأصلية كانت 30.
06:29 لهذا السبب يلتقط Evo undo شاهداً للحالة السابقة قبل تطبيق التغيير. يوفر ذلك الشاهد المعلومات اللازمة لاستعادة الحالة الأصلية والتحقق لاحقاً من أن التعافي قد نجح بالفعل. والآن يطرح السؤال، ما مدى تكرار فشل التحسينات في الصلابة؟ في Evo undo، قمنا بتقييم 600 مهمة تطوير . من بينها، أنتجت 478 تحسينات في القدرات ، لكن 197 من تلك التحسينات كانت تعاني من عيوب في التعافي.
07:12 أي حوالي 42%من الحالات الإيجابية في القدرات. إذن، الخلاصة هنا هي أن التغيير يمكن أن يحسن قدرة الوكيل ومع ذلك يترك النظام غير قادر على التعافي بشكل موثوق. والآن يمكننا القول لماذا لم ينجح طلب " الرجاء إصلاح التراجع". لذا، بطبيعة الحال ، أردنا استخدام التلقين وإخبار الوكيل: " هل يمكنك ببساطة إصلاح كل حالات فشل التعافي هذه؟" لقد اختبرنا أربع استراتيجيات إصلاح موجهة بواسطة مدقق، ولكن في ظل لغة التعافي الأصلية، لم ينجح أي منها في إصلاح حالات الفشل الـ 197 الطبيعية.
08:05 المشكلة لم تكن بالضرورة في استنتاج الوكيل. في بعض الحالات، افتقر الوكيل إلى معلومات دقيقة حول الحالة الأصلية. وفي حالات أخرى، لم تستطع لغة التعافي التعبير عن العملية المطلوبة لعكس السلسلة . لذا، قمنا بدراسة هاتين المحدوديتين بشكل منفصل. إذن، هناك عقبتان. الأولى هي تأصيل الحالة ، والأخرى هي القدرة التعبيرية للتعافي. عندما قدمنا معلومات دقيقة حول ما تغير ومكانه، تحسنت نسبة الاستعادة من 0 إلى 38 من أصل 48 حالة.
08:54 والثانية هي تعبيرية الاستعادة. لذا، عندما قدمنا عمليات تراجع أكثر ثراءً، تحسنت الاستعادة بشكل ملحوظ من 0 إلى 142 من أصل 143 حالة. تأتي هذه النتائج من مجموعتين تجريبيتين مختلفتين، لكنهما تظهران معاً لماذا تحتاج الاستعادة إلى معلومات دقيقة عن الحالة والقدرة على تنفيذ عملية التراجع المطلوبة. الآن، يتبادر إلى ذهننا سؤال: هل يمكن لآلية تراجع أفضل إنقاذ الطفرات الفاشلة؟ إذن، ماذا يحدث عندما نمنح الوكيل قدرات استعادة أفضل؟ مع لغة الاستعادة الأصلية، لم يمكن استعادة أي من الطفرات الـ 197 المعيبة، ولكن بعد توسيع لغة الاستعادة،
09:55 نجحنا في استعادة 180 من أصل 197 حالة. هذا يمثل حوالي 92%. ونتيجة لذلك، ارتفع عدد التحسينات المقبولة من 281 إلى 461 من أصل 600 مهمة. هذا تحسن بمقدار 30 نقطة مئوية، وهذا يقودنا إلى السؤال التالي. كيف نبني عمليات التحقق من الاستعادة هذه ضمن عملية تطور الوكيل؟ سأقوم الآن بتسليم الكلمة إلى دولي لاستعراض خوارزمية "إيفو أندو". >> حسناً. شكراً تانماي. إذن، دعنا ندخل في كيفية عمل "إيفو أندو" فعلياً.
10:39 أولاً، سنبدأ بالوكيل، حيث سيبدأ الوكيل عمله. يقوم الوكيل بمعالجة الطفرة بناءً على حالته الحالية بالإضافة إلى عقد التأثير وخطة الاستعادة. وقبل تطبيق الطفرة، نلتقط شاهداً للحالة يمثل الحالة الأصلية. وقبل ذلك، أثناء الاختبار في بيئة الاختبار، سيقوم الوكيل بتطبيق الطفرة وتنفيذ خطة الاستعادة. سيقوم مدقق مستقل أيضاً بالتحقق مما إذا كانت الحالة الأصلية قد استعيدت أم لا.
11:19 إذا أدت الطفرة إلى تحسين القدرة بناءً على المعايير المحددة من قبل المستخدم واجتازت فحص الاستعادة، فإن الوكلاء يقبلون التغييرات . بخلاف ذلك، سيحاول الوكيل الإصلاح، أو يقوم المدقق نفسه برفض الطفرة تماماً. بهذه الطريقة، تصبح القابلية للاستعادة جزءاً من قرار القبول بدلاً من كونها شيئاً نخطط له بعد نشر وكيل الذكاء الاصطناعي. حسناً، شكراً لك. بعد ذلك، سنستعرض ما شرحه تانماي بالفعل في مثال.
12:04 اسمحوا لي أن أوضح كيف سيبدو مثال تغيير الوقت من 30 إلى 60 في الواقع . إذن، لنبدأ بالحالة الأصلية، مثال بسيط لوكيلنا الذي لديه قيمة وقت تبلغ 30. قبل تغيير أي شيء، ستقوم Evo undo أولاً بقراءة القيمة الأصلية. ثم ستقوم بحفظ القيمة الأصلية والتقاطها كشاهد للحالة. نحن نعرف بالضبط ما الذي يجب استعادته إذا اضطررنا لذلك، سنعرف ما الذي يجب استعادته أو ما هي الحالة الصحيحة التي يجب العودة إليها.
12:48 الآن، يأتي دور التعديل. الآن، يقوم الوكيل بتغيير المهلة الزمنية من 30 إلى 60 كما نريد منه أن يفعل. وإذا كانت الاستعادة مطلوبة، تستخدم خاصية التراجع الشاهد المحفوظ لاستعادة المهلة الزمنية إلى 60. الآن، وبشكل مستقل، سيؤكد المُحقق في النهاية أن القيمة المستعادة تطابق القيمة الأصلية. لذا، لا تُعتبر الاستعادة ناجحة لمجرد تشغيل أمر تراجع، بل سيتحقق المُحقق من الحالة الناتجة للتأكد من أننا نقوم بالفعل بالاستعادة إلى الحالة التي نريدها .
13:32 حسناً، الآن يأتي السؤال الأكبر. لدينا الآن هذه القدرة على الاستعادة ضمن ترسانتنا. هل يجب علينا استخدامها بشكل موحد وتطبيق آلية الاستعادة على جميع الإخفاقات؟ حسناً، بالطبع لا. لا يمكن استعادة كل الإخفاقات بنفس الطريقة. إذا لم يتغير شيء، فإذا لم يتغير شيء في النظام، فنحن ببساطة نريد منه أن يستعيد وضعه، ونريد ببساطة أن يقوم بإعادة المحاولة بأمان. نريد من الوكيل أن يعيد المحاولة ببساطة لتحقيق الحالة التي نريد الوصول إليها.
14:13 ومع ذلك، إذا كانت لدينا الحالة الأصلية، فيمكننا استعادتها إذا تم تنفيذ الإجراء الخارجي بالفعل، وهنا سنحتاج إلى آلية تعويض أو إجراء تعويضي لعكس تأثيره. وإذا لم نتمكن من الاستعادة، أو إذا لم نتمكن من التحقق من أن الاستعادة آمنة، أو إذا رفض المُحقق عملية الاستعادة، فيجب على الوكيل التوقف والتصعيد. تعتمد الاستجابة الصحيحة بالتأكيد على ما حدث بالفعل وعلى ما يمكن عكسه بأمان وما لا يمكن.
14:56 هذا يقودني إلى الشريحة الأخيرة تقريباً، والتي تدور حول تجميع كل شيء في ورقتي البحثيتين "Undo Bench" و "Evo Undo". إذن ، النقاط الرئيسية هنا هي أولاً، أن " Undo Bench" يوضح نجاح تنفيذ المهمة. يوضح "Undo Bench" أن نجاح تنفيذ المهمة لا يضمن دائماً نجاح استعادتها. ثانياً، توفر خوارزمية Evo undo عملية منظمة: التقاط الحالة الأصلية، وتطبيق التعديل، والاسترداد، والتحقق المستقل، والإعادة.
15:33 لذا، تعمل خوارزمية Evo undo بالطريقة التي قصدناها تماماً. ثالثاً، يجب ألا نسمح بتغييرات التطور الذاتي إلا عند استيفاء متطلبات القدرة والقابلية للاسترداد معاً. في نهاية المطاف، بينما نمنح الوكلاء مزيداً من الاستقلالية، يجب أن نمنحهم أيضاً طرقاً أكثر موثوقية للتعافي من أفعالهم. حسناً. أخيراً، آمل أن تتذكروا الوكيل الذي تحدثنا عنه في البداية. كان يبحث عن زر تراجع.
16:06 حسناً، الآن لديه واحد. لقد بدأنا في بناء هذه القدرة من خلال مشروعنا البحثي Evo undo. ويمكنكم استكشاف المزيد عبر مستودع GitHub الخاص بنا. يمكنكم مسح رمز الاستجابة السريعة (QR) الظاهر على الشاشة للوصول إلى الصفحة. هدفنا هو جعل الاسترداد قدرة أساسية لوكلاء الذكاء الاصطناعي، بحيث لا يقتصر دور الوكيل على تنفيذ الإجراء فحسب، بل يتمكن أيضاً من التعافي عند حدوث خطأ ما. شكراً جزيلاً لكم.