علي بابا تقول إن Qoder 1.0 خفّض رموز إدخال الوكيل بنسبة 40%. وعلي بابا هي التي أجرت الاختبار

Qoder 1.0، أداة البرمجة بالذكاء الاصطناعي من Alibaba Cloud، ليس إصدارًا يتعلق حقًا بالكود الذي يكتبه الوكيل. إنه إصدار يتعلق بالحاوية التي يعمل فيها الكود. في منشور تصميمي على مدونة Alibaba Cloud Community، يرى الفريق أن مساحة عمل IDE الكلاسيكية, وهي دليل يُفتح في نافذة حيث تشير شجرة الملفات والطرفية ولوحة Git والمحرر جميعها إلى المكان نفسه, تتوقف بهدوء عن التماسك بمجرد أن يتولى وكيل مهام حقيقية. تتوقف حالة النافذة وحالة التنفيذ وحالة التسليم عن كونها الشيء نفسه.

حل علي بابا هو التوقف عن التظاهر بأنها متطابقة. يرقّي Qoder 1.0 واجهة Chat التحاورية إلى بيئة تشغيل مهام وكيلة بخمسة حدود لكل مهمة: منطقة العمل والتنفيذ والمخرجات والتسليم والمعرفة. في وضع Agent العادي تتداخل هذه الطبقات في معظمها: الدليل الحالي هو دليل التنفيذ، وهو أيضًا دليل المخرجات، ويعملان Review وCommit على جذر Git نفسه. وعند إدخال شجرة عمل Git، تنفصل هذه الطبقات. تُنشأ المهمة من مستودع المصدر، وينفّذ الوكيل في شجرة عمل معزولة، وتتبع شجرة الملفات وReview شجرة العمل، وتبدأ Quest التالية مجددًا من مستودع المصدر.

بيئة تشغيل المهام تحل محل نافذة الدردشة

القرار التصميمي المهم هو أن المهمة قد تمتد عبر حالات متعددة لمنطقة العمل، وهي حالة لا تُمثّلها IDE التقليدية أبدًا. يضع وضع Quest، وهو نموذج يعتمد المواصفات أولًا للمهام المعقدة والطويلة الأمد، النمط: يكتب المطورون مواصفات مفصلة، ويعمل الوكيل وفقًا لها. يضيف Qoder 1.0 عرض Quest ثلاثي الأعمدة يجيب عن سؤال هندسي: كيف تنتقل مهمة الوكيل من جلسة دردشة إلى شيء يمكن عرضه ومراجعته واعتماده. تعرض منطقة الملخص والمراجع السياق الذي اعتمد عليه الوكيل، بحيث يُفترض أن يتحقق Review من سبب إجراء التغيير، لا فقط مما إذا كان الفرق (diff) يبدو صحيحًا.

تتحدث علي بابا بوضوح عمّا يحدث عندما تنحرف هذه الحدود:

قد يكتب Apply إلى الدليل الخاطئ. وقد يسترجع Reject الملفات الخاطئة. وقد يقارن Review الفرق الخاطئ. وقد يجري Commit حساباته على أساس دليل جذر Git الخاطئ.

والأسوأ أن هذه الأخطاء لا تظهر عادةً بينما يكتب الوكيل الكود. إنها تظهر عندما يكون المستخدم مستعدًا لتسليم المهمة، وهي أسوأ لحظة ممكنة لاكتشافها.

الأرقام خلف ادعاءات الذاكرة

أقوى الادعاءات في المنشور كمية، وتأتي من نظام الذاكرة والمعرفة، الذي تعامله علي بابا بوصفه جزءًا من بيئة المهمة لا ميزة منفصلة. أسفر اختبار A/B عبر الإنترنت استمر ثلاثة أيام عبر الفئات الخمس الأولى، يقارن بين تفعيل الذاكرة وتعطيلها، عن النتائج التالية، كما أوردتها الشركة:

المقياس	التغيّر مع تفعيل الذاكرة
معدل عدم الرضا	انخفاض 22.09%
الاحتفاظ بالكود	ارتفاع 11.10%
رموز الإدخال	انخفاض 40.13%
جولات المحادثة	انخفاض 32.60%

روى تقييم دون اتصال مبني على فهم البنية والامتثال للاتفاقيات والتكيف مع الحزمة التقنية قصة مماثلة. رفعت معرفة البنية درجات إنجاز المهام بنحو 25% بينما انخفض استهلاك الرموز نحو 30%؛ وحسّنت معرفة الحزمة التقنية الدرجات من البداية إلى النهاية بنحو 25% مع توفير في الرموز يقارب 15%؛ وحسّنت معرفة معايير البرمجة مدى مطابقة الكود للاتفاقيات المطلوبة.

تستحق هذه الأرقام الاحترام والتحفظ بقدر متساوٍ. إنها صادرة عن تقييمات أجرتها علي بابا على مشاريعها الخاصة، ولم يُبلَّغ عن أي تكرار مستقل. المنشور نفسه الذي يدّعي خفضًا بنسبة 40% في رموز الإدخال يرى أن تعزيز المعرفة قدرة هندسية يمكن قياسها، لا مجرد استراتيجية تلقين عامة. غير أن القياس هو تحديدًا ما ينقص خارج أسوار الشركة.

معرفة بسياج حولها

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

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

أشجار العمل المحلية مقابل الإرسال السحابي

في ما يخص التنفيذ المتوازي، يراهن Qoder 1.0 على خيار يبدو تقليديًا مقارنة بمنافسيه. تواصل Cursor، بيئة التطوير المتكاملة المدعومة بالذكاء الاصطناعي، دفع وكلائها إلى السحابة، وأضافت تطبيق جوال لإرسال وكلاء البرمجة من أي مكان، وتكاملًا أعمق مع Slack عبر المستودعات والقنوات. يبقى النموذج المتوازي في Qoder محليًا: أشجار عمل Git معزولة، واحدة لكل Quest، بينما يفحص المستخدم المخرجات ويقرر ما إذا كان سيراجع أو يطبق أو يعتمد. يقرّ المنشور بأن النموذج قد يبدو وكأنه “دليل فرع إضافي آخر”، لكنه يؤطره بوصفه تخصيص حد تنفيذ مستقل لكل مهمة.

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

ما يزال غير مُثبت

ثلاث فجوات تفصل ادعاءات Qoder 1.0 عن الحقيقة المثبتة. نتائج التقييم بلا تكرار مستقل؛ رقم الرموز البالغ 40% ورقم عدم الرضا البالغ 22% قياسات داخلية. لا يقدم المنشور بيانات عن أنماط الفشل: فهو يصف بوضوح ما يحدث عندما تعمل Apply وReject وReview وCommit على الأهداف الخاطئة، لكنه لا يذكر كم مرة يحدث ذلك أو ما تكلفته. ومعيار الشفافية المعتمد في أماكن أخرى من نظام Qwen البيئي، حيث تصدر الإصدارات عادةً مع بيانات التدريب وأداة التقييم وغالبًا نموذج المكافأة نفسه، لا يوجد له مقابل هنا.

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