Copilot يتحكم بسطح المكتب: ماذا تعني ميزة Computer Use لوكلاء البرمجة؟
أطلقت GitHub معاينة Computer Use في Copilot CLI وتطبيق Copilot. نشرح ما تفعله الميزة، وكيف تُفعَّل، وضوابط الأمان، ومتى تتجنبها.
في الأول من أكتوبر 2026 أعلنت GitHub أن ميزة «استخدام الحاسوب» (Computer Use) صارت متاحة بنسخة معاينة عامة داخل Copilot CLI وتطبيق Copilot على macOS وويندوز. الخبر لا يتعلق بنموذج أذكى، بل بشيء مختلف: وكيل يستطيع أن ينظر إلى الشاشة ويضغط ويكتب داخل تطبيقات لا توفّر واجهة برمجية أصلاً.
في هذا المقال نشرح ما تفعله الميزة، وكيف تُفعَّل، وما الضوابط التي وضعتها GitHub، ومتى تكون الخيار الأخير لا الأول.
ما الذي تغيّر بالضبط؟
حتى الآن كان وكيل البرمجة يعمل داخل الطرفية والمحرر: يقرأ الملفات، ينفّذ الأوامر، ويستدعي أدوات عبر MCP أو واجهات API. أي برنامج لا يملك واحدة من هذه الواجهات كان خارج نطاقه. مع الميزة الجديدة يستطيع Copilot، بحسب إعلان GitHub:
- قراءة المحتوى المتاح في التطبيق والسياق البصري على الشاشة.
- الضغط على عناصر التحكم وإدخال النص وتعديله.
- الضغط على المفاتيح والتمرير والسحب.
- التنقّل عبر خطوات عمل تمتد على أكثر من تطبيق.
أي أن البرامج القديمة وأدوات الواجهة الرسومية فقط، التي لا تملك API ولا سطر أوامر ولا تكاملاً مع MCP، أصبحت قابلة للأتمتة من الوكيل نفسه الذي يكتب الشيفرة.
الفكرة العملية: الواجهة الرسومية صارت «واجهة برمجية احتياطية» للوكيل، تُستخدم حين لا يوجد باب آخر.
كيف تُفعَّل الميزة؟
التفعيل بسيط ومقصود أن يكون صريحاً:
| الموضع | طريقة التفعيل |
|---|---|
| Copilot CLI | الأمر /computer on |
| فحص الحالة | الأمر /computer show |
| الإيقاف | الأمر /computer off |
| تطبيق Copilot | الإعدادات ثم Computer Use ثم تفعيل الخيار، أو /computer on |
على macOS يرشدك Copilot لمنح صلاحيتي «إمكانية الوصول» (Accessibility) و«تسجيل الشاشة» (Screen Recording)، وهما الصلاحيتان اللتان بدونهما لا يستطيع أي برنامج رؤية الشاشة أو التحكم بها.
الضوابط التي أعلنتها GitHub
لأن التحكم بسطح المكتب أخطر من تشغيل أمر في الطرفية، أضافت GitHub طبقات حماية واضحة:
- طلب موافقة قبل التحكم بأي تطبيق. لا يبدأ Copilot بالنقر داخل تطبيق قبل أن تقبل.
- قائمة «اسمح دائماً». يمكنك مراجعة التطبيقات التي سمحت لها دائماً وإعادة ضبطها.
- إعدادات المؤسسة. يمكن للإعدادات التي تديرها المؤسسة تعطيل الميزة بالكامل.
هذه النقطة الأخيرة مهمة للشركات: سياسة واحدة تكفي لمنع الميزة عن كل الفريق قبل أن يقرر أحد تجربتها على جهاز يحوي بيانات حساسة.
متى تستخدمها، ومتى تتجنبها؟
نصيحة GitHub نفسها لافتة: استخدم الأدوات المباشرة (API وخوادم MCP وأوامر الطرفية) كلما أمكن، لأنها أكثر قابلية للتنبؤ من التفاعل مع سطح المكتب. وتحذّر صراحة من ثلاثة أمور: النقرات الخاطئة، وتوقف الوكيل في منتصف المهمة، ووصول بيانات حساسة ظاهرة على الشاشة إلى سياق الوكيل.
حالات مناسبة
- اختبار واجهة شاملة (end-to-end) لتطبيق سطح مكتب لا يملك إطار اختبار.
- مهام متكررة في برنامج قديم لا يمكن تعديله أو لا يوفّر API.
- مهام إدارية تمر عبر عدة تطبيقات، كإدخال بيانات من برنامج إلى آخر.
حالات يُفضّل تجنبها
- أي عمل يمكن إنجازه بأمر في الطرفية أو استدعاء API.
- شاشات تعرض كلمات مرور أو بيانات عملاء أو مفاتيح.
- مهام لا يمكنك مراقبتها أو التراجع عنها بسهولة.
كيف يغيّر هذا عمل المطوّر اليومي؟
أبرز أثر عملي هو إغلاق الفجوة بين الشيفرة والتطبيق الذي تعمل عليه فعلاً. كثيراً ما يكتب الوكيل تعديلاً على واجهة، ثم تضطر أنت لفتح التطبيق وتجربته يدوياً والعودة بالملاحظات. مع استخدام الحاسوب يمكن للوكيل أن يشغّل التطبيق بنفسه، ويجرّب المسار، ويلتقط ما ظهر على الشاشة، ثم يعدّل الشيفرة بناءً على ما رأى. هذه الحلقة المغلقة كانت تحتاج سابقاً إلى إطار اختبار مكتوب بعناية لكل تطبيق.
ثلاث ملاحظات للفرق التقنية
- الاختبار ليس بديلاً عن الاختبارات الآلية. سيناريو ينقر فيه الوكيل على الشاشة أبطأ وأقل ثباتاً من اختبار مكتوب، فاستخدمه لاكتشاف المشكلات لا لتثبيتها كاختبار دائم.
- السجلّ مهم. راجع ما فعله الوكيل بعد كل مهمة، خصوصاً حين تمر المهمة بتطبيقات تحوي بيانات مالية أو بيانات عملاء.
- المعاينة تعني التغيّر. سلوك الميزة والأوامر والصلاحيات قد يتبدّل قبل الإطلاق العام، فلا تبنِ عليها عملية إنتاجية حرجة الآن.
أين تقع الميزة بين أدوات الوكلاء؟
ترتّب الأدوات الحالية عادةً من الأكثر قابلية للتنبؤ إلى الأقل: استدعاء API مباشر، ثم أمر في الطرفية، ثم أداة عبر MCP، وأخيراً التحكم بالشاشة. كل درجة أسفل هذا الترتيب تزيد المرونة وتقلّل الثبات. لذلك تأتي ميزة Copilot الجديدة في آخر السلّم، وهذا بالضبط ما تقوله GitHub في نصيحتها: جرّب الأدوات الأخرى أولاً.
كيف تجرّبها بأمان؟
جرّب الميزة أولاً في بيئة معزولة: حساب مستخدم منفصل أو جهاز اختبار، مع تطبيق واحد فقط مفتوح. ابدأ بمهمة صغيرة قابلة للتراجع، وراقب كل خطوة بنفسك، وأغلق النوافذ التي تحوي بيانات خاصة قبل البدء. لا تفعّل خيار «اسمح دائماً» في الأيام الأولى، وراجع القائمة بعد كل تجربة.
وإن كنت مسؤولاً في فريق، فقرّر مسبقاً هل تُترك الميزة مفتوحة أم تُقيَّد عبر إعدادات المؤسسة، لأنها معاينة عامة وسلوكها قد يتغيّر.
أسئلة شائعة
هل تعمل الميزة على لينكس؟
بحسب إعلان GitHub، المعاينة الحالية متاحة على macOS وويندوز فقط، داخل Copilot CLI وتطبيق Copilot.
هل تغني عن خوادم MCP والـ API؟
لا. GitHub نفسها توصي بالأدوات المباشرة أولاً لأنها أكثر ثباتاً. استخدام الحاسوب خيار للحالات التي لا توجد فيها واجهة أخرى.
هل يرى Copilot كل ما على شاشتي؟
بعد موافقتك يستطيع قراءة المحتوى المتاح في التطبيق والسياق البصري، لذلك حذّرت GitHub من أن البيانات الحساسة الظاهرة قد تصبح جزءاً من سياق الوكيل. أغلق ما لا يلزم قبل التشغيل.
الخلاصة
وصول استخدام الحاسوب إلى Copilot يوسّع ما يستطيع الوكيل لمسه: من الملفات والأوامر إلى أي تطبيق له واجهة رسومية. القيمة الحقيقية في البرامج القديمة والاختبارات الشاملة، أما المخاطر فتتعلق بالنقرات الخاطئة وبياناتك الظاهرة على الشاشة. جرّبها في بيئة معزولة، وابقَ مع الأدوات المباشرة حين تتوفر، وتعامل مع هذه الميزة كأداة احتياط لا كمسار أساسي.
المصدر: إعلان GitHub Changelog
