الذكاء الاصطناعي

GitHub يوضح سبب اختفاء نشاط الوكيل في مقاييس Copilot

كشفت GitHub عن خلل في ربط جلسات الوكيل بمصدرها في بعض إصدارات IDE، مما أدى إلى إهمال جزء من النشاط في التقارير، مع بدء توزيع الإصلاحات الآن.

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 7 أكتوبر 2026 · آخر تحديث: 7 أكتوبر 2026 · 5 دقائق قراءة

GitHub يوضح سبب اختفاء نشاط الوكيل في مقاييس Copilot — الصورة: GitHub Changelog

تشخيص الخلل التقني في مقاييس الاستخدام

أعلنت GitHub عن تحديد السبب وراء الانخفاض المفاجئ في نشاط الوكيل (Agent Activity) أو أسطر الكود المرتبطة به في مقاييس استخدام Copilot، وذلك في وقت حافظ فيه إجمالي الاستخدام على نمط نمو مستقر. جاء هذا التشخيص بعد ملاحظة فرق بين البيانات المرصودة على الخوادم والبيانات المرسلة من التطبيقات المحلية، مما دفع الفريق التقني إلى إجراء تحليل دقيق لسلاسل البيانات. ويمكن الرجوع إلى GitHub Changelog للاطلاع على التفاصيل الأصلية للمصدر.

تبيّن أن السبب الجذري يكمن في التحديثات الأخيرة التي أجرتها عدة بيئات تطوير (IDEs) لنقل جلسات الوكيل إلى إطار عمل Copilot SDK. هذه الجلسات الجديدة لم تحمل معرّفات كافية لتحديد بيئة التطوير المصدرية بدقة، مما جعل أنظمة المقاييس غير قادرة على إسناد النشاط إلى IDE معين بشكل صحيح. نتيجة لذلك، تم استبعاد معظم هذا النشاط من التقارير الرئيسية، بينما تم احتساب جزء منه بشكل خاطئ كنشاط لـ Copilot CLI. ويمكن الرجوع إلى Back to changelog للاطلاع على التفاصيل الأصلية للمصدر.

نطاق التأثير والإصدارات المتضررة

يقتصر تأثير هذا الخلل على إصدارات IDEs التي تعتمد حصرياً على Copilot SDK لوضع الوكيل (Agent Mode). المطورون الذين يستخدمون إصدارات أقدم لا يتأثرون بهذه المشكلة، حيث أن بياناتهم تُحتسب بشكل صحيح في التقارير الحالية. هذا التمييز مهم لفهم سبب اختلاف القراءات بين فرق العمل المختلفة التي قد تستخدم إصدارات متفاوتة من أدوات التطوير.

تشمل التأثيرات تقارير المؤسسات والمستخدمين الأفراد، سواء كانت تقارير يومية أو شهرية (28 يوماً). تبقى الفجوة في البيانات قائمة لأي مطور يظل على إصدار متأثر حتى يقوم بتحديث بيئته. خلال هذه الفترة، تبقى مقاييس مثل loc_added_sum و loc_deleted_sum المرتبطة بتعديلات الوكيل (agent_edit) أقل من قيمتها الفعلية، مما قد يعطي انطباعاً خاطئاً عن مستوى الإنتاجية أو الاعتماد على الذكاء الاصطناعي.

خطة الإصلاح وتوقيت التوزيع

بدأت GitHub بتوزيع الإصلاحات بشكل تدريجي. أصبح التحديث متاحاً بالفعل لمستخدمي Visual Studio Code، مما يعني أن نشاطهم الوكيل سيبدأ بالظهور مرة أخرى في لوحة التحكم ومقاييس الاستخدام عبر واجهة البرمجة (API) بعد التحديث. بالنسبة لبيئات التطوير الأخرى، من المتوقع أن تصل التحديثات في إصدارات قادمة، مع استهداف اكتمال عملية التوزيع لجميع المنصات المعتمدة بحلول نوفمبر 2026.

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

التوصيات للمؤسسات وإدارة البيئات

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

كما توضح الشركة أن التسعير والفوترة لم يتأثرا بهذا الخلل. المشكلة كانت تتعلق حصرياً بكيفية إسناد النشاط في مقاييس الاستخدام (Usage Metrics)، وليس بما تم احتسابه فعلياً من رسوم. هذا التمييز يطمئن المستخدمين بأن تكاليفهم الشهرية كانت صحيحة، رغم أن القراءات الظاهرة في التقارير كانت متضائلة مؤقتاً.

تأثير الخلل على مقاييس Copilot CLI

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

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

فهم الفجوة بين البيانات المحلية والخوادم

توضح GitHub أن معظم مقاييس الاستخدام التفصيلية، مثل تقسيمات الميزات واللغات والنماذج وأسطر الكود، تعتمد على البيانات التلمسية (Telemetry) التي يرسلها كل IDE. في المقابل، تسجل الخوادم بيانات موثوقة حول المستخدمين النشطين، لكنها لا تستطيع رصد ما يحدث داخل محرر الكود. عندما تتعارض التقارير مع بيانات Copilot الأخرى، يكون السبب عادةً في جانب العميل (Client-side).

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

أفضل الممارسات لضمان اكتمال البيانات

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

يمكن للمدراء اكتشاف العملاء القدامى من خلال تقارير المستخدم الواحد، حيث تتضمن الحقل totals_by_ide معلومات عن last_known_ide_version و last_known_plugin_version لكل مستخدم. يوفر هذا رؤية واضحة عن من يحتاج إلى تحديث، مما يسهل عملية إدارة البيئة التقنية وضمان استمرارية دقة البيانات التحليلية.