GitHub Copilot | The .NET Blog

VS Code 1.118: يحصل Copilot CLI على أسماء الجلسات وشارات النماذج وـ TypeScript 7.0 Nightly

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المنشور تلقائيًا. للاطلاع على النسخة الأصلية، انقر هنا.

Visual Studio Code 1.118 إصدار أصغر ومركّز — يتضمن في معظمه تحسينات على Copilot CLI.

Copilot CLI: الجلسات تحصل على أسماء حقيقية

تُستخدم الآن واجهات برمجة تطبيقات عناوين الجلسات في SDK الخاص بـ Copilot CLI كمصدر للحقيقة لأسماء الجلسات. بدلاً من التسميات المولّدة تلقائيًا، تعرض الجلسات الاسم الحقيقي من SDK.

التبديل بين الجلسات بشكل أسرع

تمتلك تطبيق Agents الآن اختصارات Ctrl+1 وCtrl+2 وما إلى ذلك للتبديل السريع بين الجلسات.

شارات النماذج في المحادثة

تعرض ردود Copilot CLI في لوحة المحادثة الآن شارة النموذج — يمكنك رؤية أي نموذج تعامل مع كل طلب بلمحة واحدة.

الاختيار التلقائي للنموذج في Copilot CLI

تعمل ميزة الاختيار التلقائي للنموذج الآن أيضًا في وكيل Copilot CLI.

الانضمام إلى TypeScript 7.0 Nightly

يمكنك الآن الانضمام لاختبار الإصدارات الليلية من TypeScript 7.0 مباشرةً من إعدادات VS Code. TypeScript 7.0 إصدار مهم (صدر الإصدار التجريبي منذ أيام).

راجع ملاحظات الإصدار الكاملة.

azd + GitHub Copilot: إعداد المشروع بالذكاء الاصطناعي وحل الأخطاء بذكاء

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

تُرجِمت هذه المقالة تلقائيًا. للاطلاع على النسخة الأصلية بالإنجليزية، انقر هنا.

هل تعرف تلك اللحظة التي تريد فيها نشر تطبيق موجود على Azure فتجد نفسك تحدق في ملف azure.yaml فارغ، محاولًا تذكر ما إذا كان Express API الخاص بك يجب أن يستخدم Container Apps أم App Service؟ تلك اللحظة أصبحت الآن أقصر بكثير.

يتكامل Azure Developer CLI (azd) الآن مع GitHub Copilot بطريقتين عمليتين: سقالة المشروع بمساعدة الذكاء الاصطناعي خلال azd init، واستكشاف الأخطاء وإصلاحها بذكاء عند فشل عمليات النشر. كلا الميزتين تعملان بالكامل داخل الطرفية.

الإعداد مع Copilot أثناء azd init

عند تشغيل azd init، يظهر الآن خيار “Set up with GitHub Copilot (Preview)”. اختره وسيحلل Copilot قاعدة التعليمات البرمجية الخاصة بك لإنشاء azure.yaml وقوالب البنية التحتية ووحدات Bicep — بناءً على الكود الفعلي.

azd init
# اختر: "Set up with GitHub Copilot (Preview)"

المتطلبات:

azd 1.23.11 أو أحدث — تحقق بـ azd version أو حدّث بـ azd update
اشتراك نشط في GitHub Copilot (فردي أو للأعمال أو للمؤسسات)
GitHub CLI (gh) — سيطلب azd تسجيل الدخول إذا لزم الأمر

ما أجده مفيدًا حقًا: يعمل في الاتجاهين. تبني من الصفر؟ يساعدك Copilot على تهيئة خدمات Azure الصحيحة من البداية. لديك تطبيق موجود تريد نشره؟ وجّه Copilot إليه وسيُنشئ التهيئة دون الحاجة إلى إعادة هيكلة أي شيء.

ما الذي يفعله فعليًا

لنفترض أن لديك Node.js Express API يعتمد على PostgreSQL. بدلًا من اتخاذ قرار يدوي بين Container Apps وApp Service ثم كتابة Bicep من الصفر، يكتشف Copilot تقنياتك ويُنشئ:

azure.yaml بالإعدادات الصحيحة لـ language وhost وbuild
وحدة Bicep لـ Azure Container Apps
وحدة Bicep لـ Azure Database for PostgreSQL

ويُجري فحوصات مسبقة قبل تغيير أي شيء — يتحقق من نظافة دليل git، ويطلب موافقتك على أدوات خادم MCP مسبقًا. لا شيء يحدث دون علمك بما سيتغير بالضبط.

استكشاف الأخطاء وإصلاحها مع Copilot

أخطاء النشر لا مفر منها. معاملات مفقودة، مشكلات في الأذونات، توفر SKU — ونادرًا ما تخبرك رسالة الخطأ بالشيء الوحيد الذي تحتاج معرفته فعلًا: كيف تُصلحه.

بدون Copilot، الحلقة تبدو هكذا: انسخ الخطأ ← ابحث في المستندات ← اقرأ ثلاث إجابات Stack Overflow غير ذات صلة ← شغّل بعض أوامر az CLI ← أعد المحاولة وتمنَّ. مع Copilot في azd، تنهار هذه الحلقة. عند فشل أي أمر azd، يعرض فورًا أربعة خيارات:

Explain — شرح بلغة مبسطة لما حدث
Guidance — تعليمات خطوة بخطوة لإصلاح المشكلة
Diagnose and Guide — تحليل كامل + يطبق Copilot الإصلاح (بموافقتك) + إعادة محاولة اختيارية
Skip — التعامل معه بنفسك

النقطة الرئيسية: لدى Copilot بالفعل سياق مشروعك والأمر الفاشل وتفاصيل الخطأ. اقتراحاته خاصة بـ وضعك.

ضبط السلوك الافتراضي

إذا كنت دائمًا تختار نفس الخيار، تجاوز الموجه التفاعلي:

azd config set copilot.errorHandling.category troubleshoot

القيم: explain وguidance وtroubleshoot وfix وskip. يمكنك أيضًا تمكين الإصلاح التلقائي وإعادة المحاولة:

azd config set copilot.errorHandling.fix allow

العودة إلى الوضع التفاعلي في أي وقت:

azd config unset copilot.errorHandling.category

خاتمة

شغّل azd update للحصول على أحدث إصدار وجرّب azd init في مشروعك القادم.

اقرأ الإعلان الأصلي هنا.

VS Code 1.117: الوكلاء يحصلون على فروع Git الخاصة بهم وهذا رائع

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

يستمر الخط الفاصل بين “مساعد الذكاء الاصطناعي” و"زميل الذكاء الاصطناعي" في التلاشي. وصل VS Code 1.117 للتو وملاحظات الإصدار الكاملة مليئة بالمحتوى، لكن القصة هنا واضحة: يصبح الوكلاء مواطنين من الدرجة الأولى في سير عملك التطويري.

إليك ما يهم فعلاً.

وضع Autopilot يتذكر أخيراً تفضيلاتك

في السابق، كان عليك إعادة تمكين Autopilot في كل مرة تبدأ فيها جلسة جديدة. أمر مزعج. الآن يستمر وضع الأذونات عبر الجلسات ويمكنك تكوين الوضع الافتراضي.

يدعم مضيف الوكيل ثلاث تكوينات للجلسة:

Default — تطلب الأدوات التأكيد قبل التشغيل
Bypass — يوافق تلقائياً على كل شيء
Autopilot — استقلالية كاملة، يجيب على أسئلته الخاصة ويستمر

إذا كنت تُنشئ سقالة لمشروع .NET جديد مع الترحيلات وDocker وCI — اضبطه على Autopilot مرة واحدة وانسَ الأمر. يبقى هذا التفضيل.

عزل Worktree وGit لجلسات الوكيل

هذه هي الميزة الكبرى. تدعم جلسات الوكيل الآن عزل worktree وgit الكامل. هذا يعني أنه عندما يعمل الوكيل على مهمة، يحصل على فرعه الخاص ودليل عمله. يبقى فرعك الرئيسي دون مساس.

والأفضل من ذلك — يولّد Copilot CLI أسماء فروع ذات معنى لجلسات worktree هذه. لا مزيد من agent-session-abc123. تحصل على شيء يصف فعلاً ما يفعله الوكيل.

لمطوري .NET الذين يديرون فروع ميزات متعددة أو يصلحون أخطاء بينما تعمل مهمة بناء سقالة طويلة، هذا تغيير جذري. يمكنك أن تجعل وكيلاً يبني وحدات تحكم API الخاصة بك في worktree واحدة بينما تُصحّح مشكلة في طبقة الخدمة في أخرى. لا تعارضات. لا تخزين مؤقت. لا فوضى.

الوكلاء الفرعيون وفرق الوكلاء

يدعم بروتوكول مضيف الوكيل الآن الوكلاء الفرعيين. يمكن للوكيل تشغيل وكلاء أخرى للتعامل مع أجزاء من مهمة ما. فكّر في الأمر كتفويض — الوكيل الرئيسي ينسّق، والوكلاء المتخصصة تتولى الأجزاء.

هذا في مرحلة مبكرة، لكن الإمكانات لسير عمل .NET واضحة. تخيّل وكيلاً يتعامل مع ترحيلات EF Core بينما يُعدّ آخر اختبارات التكامل. لم نصل بالكامل إلى هناك بعد، لكن وصول دعم البروتوكول الآن يعني أن الأدوات ستتبع بسرعة.

مخرجات الطرفية تُدرج تلقائياً عندما يرسل الوكلاء مدخلات

أمر بسيط لكن ذو معنى. عندما يرسل الوكيل مدخلات إلى الطرفية، تُدرج مخرجات الطرفية الآن تلقائياً في السياق. في السابق، كان الوكيل يحتاج إلى دورة إضافية فقط لقراءة ما حدث.

إذا سبق لك مشاهدة وكيل يشغّل dotnet build ويفشل، ثم يحتاج إلى جولة انتقالية أخرى فقط لرؤية الخطأ — هذا الاحتكاك اختفى. يرى المخرجات فوراً ويتفاعل معها.

تطبيق Agents يُحدّث نفسه على macOS

يقوم تطبيق Agents المستقل على macOS الآن بالتحديث الذاتي. لا مزيد من التنزيل اليدوي للإصدارات الجديدة. يبقى محدّثاً تلقائياً.

الأشياء الأصغر التي تستحق المعرفة

التحويم فوق package.json يعرض الآن كلاً من الإصدار المثبّت وأحدث إصدار متاح. مفيد إذا كنت تدير أدوات npm إلى جانب مشاريع .NET.
الصور في تعليقات JSDoc تُعرض بشكل صحيح في التحويم والإكمالات.
جلسات Copilot CLI تُشير الآن إلى ما إذا كانت أُنشئت بواسطة VS Code أو خارجياً — مفيد عند القفز بين الطرفيات.
Copilot CLI وClaude Code وGemini CLI معترف بها كأنواع shell. يعرف المحرر ما تشغّله.

الخلاصة

VS Code 1.117 ليس إضافة ميزات مبهرجة. إنه بنية تحتية. عزل Worktree، وأذونات دائمة، وبروتوكولات وكلاء فرعيين — هذه هي اللبنات الأساسية لسير عمل يتولى فيه الوكلاء مهام حقيقية ومتوازية دون المساس بكودك.

إذا كنت تبني باستخدام .NET ولم تتعمق بعد في سير العمل الآلي، بصراحة، الآن هو الوقت المناسب للبدء.

Docker Sandbox يسمح لوكلاء Copilot بإعادة هيكلة كودك دون تعريض جهازك للخطر

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

إذا استخدمت وضع الوكيل في Copilot لأي شيء يتجاوز التعديلات الصغيرة، فأنت تعرف المعاناة. كل كتابة ملف، كل أمر في الطرفية — مطالبة أخرى بالإذن. الآن تخيّل تشغيل ذلك عبر 50 مشروعًا. ليس ممتعًا.

نشر فريق Azure للتو مقالًا حول Docker Sandbox لوكلاء GitHub Copilot، وصراحةً، هذا أحد أكثر التحسينات العملية في أدوات الوكلاء التي رأيتها. يستخدم microVMs لمنح Copilot بيئة معزولة تمامًا حيث يمكنه العمل بحرية — تثبيت الحزم، وتشغيل عمليات البناء، وتنفيذ الاختبارات — دون لمس جهازك المضيف.

ما الذي يمنحك إياه Docker Sandbox فعليًا

الفكرة الأساسية بسيطة: تشغيل microVM خفيفة الوزن ببيئة Linux كاملة، ومزامنة مساحة عملك إليها، والسماح لوكيل Copilot بالعمل بحرية بداخلها. عند الانتهاء، تُزامَن التغييرات للخارج.

إليك ما يجعلها أكثر من مجرد “تشغيل الأشياء في حاوية”:

مزامنة مساحة العمل ثنائية الاتجاه التي تحافظ على المسارات المطلقة. هيكل مشروعك يبدو متطابقًا داخل وضع الحماية. لا أعطال بناء مرتبطة بالمسارات.
Docker daemon خاص يعمل داخل microVM. يمكن للوكيل بناء الحاويات وتشغيلها دون تركيب مقبس Docker الخاص بجهازك المضيف أبدًا. هذا أمر بالغ الأهمية من ناحية الأمان.
وكلاء تصفية HTTP/HTTPS تتحكم في ما يمكن للوكيل الوصول إليه على الشبكة. أنت تحدد السجلات ونقاط النهاية المسموح بها. هجمات سلسلة التوريد من npm install مارق داخل وضع الحماية؟ محجوبة.
وضع YOLO — نعم، هذا ما يسمونه. يعمل الوكيل دون مطالبات بالإذن لأنه حرفيًا لا يستطيع إلحاق الضرر بجهازك المضيف. كل إجراء تدميري محصور.

لماذا يجب أن يهتم مطورو .NET

فكّر في أعمال التحديث التي تواجهها كثير من الفرق الآن. لديك حل .NET Framework يضم 30 مشروعًا، وتحتاج إلى نقله إلى .NET 9. هذا مئات من تغييرات الملفات — ملفات المشاريع، وتحديثات مساحات الأسماء، واستبدالات الـ API، وترحيلات NuGet.

مع Docker Sandbox، يمكنك توجيه وكيل Copilot نحو مشروع، والسماح له بإعادة الهيكلة بحرية داخل microVM، وتشغيل dotnet build وdotnet test للتحقق، وقبول التغييرات التي تعمل فعليًا فحسب. لا خطر في تدمير بيئة التطوير المحلية لديك أثناء التجريب.

يصف المقال أيضًا تشغيل أسطول من الوكلاء المتوازيين — كل منهم في وضع الحماية الخاص به — للتعامل مع مشاريع مختلفة في آنٍ واحد. بالنسبة لحلول .NET الكبيرة أو معماريات الخدمات المصغّرة، هذا توفير هائل للوقت. وكيل واحد لكل خدمة، جميعهم يعملون بعزل، وجميعهم يُتحقق منهم بشكل مستقل.

زاوية الأمان مهمة

إليك الأمر الذي يتخطاه معظم الناس: حين تسمح لوكيل ذكاء اصطناعي بتنفيذ أوامر اعتباطية، فأنت تثق به بجهازك بالكامل. يعكس Docker Sandbox هذا النموذج. يحصل الوكيل على استقلالية كاملة داخل بيئة قابلة للرمي. يضمن وكيل الشبكة أنه لا يسحب إلا من المصادر المعتمدة. يظل نظام ملفاتك المضيف وDocker daemon وبيانات اعتمادك بمنأى عن اللمس.

بالنسبة للفرق التي لديها متطلبات امتثال — وهذا ينطبق على معظم بيئات .NET المؤسسية — هذا هو الفرق بين “لا يمكننا استخدام الذكاء الاصطناعي الوكيل” و"يمكننا تبنّيه بأمان."

الخلاصة

يحل Docker Sandbox التوتر الجوهري في برمجة الوكلاء: الوكلاء يحتاجون إلى حرية ليكونوا مفيدين، لكن الحرية على جهازك المضيف خطيرة. تمنحك microVMs الأمرين معًا. إذا كنت تخطط لأي عملية إعادة هيكلة أو تحديث .NET واسعة النطاق، فهذا يستحق الإعداد الآن. إن الجمع بين ذكاء الكود في Copilot وبيئة تنفيذ آمنة هو بالضبط ما كانت فرق الإنتاج تنتظره.

تقييم التحديث من GitHub Copilot هو أفضل أداة ترحيل لا تستخدمها بعد

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

ترحيل تطبيق .NET Framework قديم إلى .NET الحديث هو أحد تلك المهام التي يعلم الجميع أنه يجب القيام بها لكن لا أحد يريد البدء بها. إنها ليست مجرد “تغيير إطار العمل الهدف.” إنها واجهات API اختفت، وحزم لم تعد موجودة، ونماذج استضافة تعمل بشكل مختلف تمامًا، وملايين القرارات الصغيرة حول ما تضعه في حاوية، وما تُعيد كتابته، وما تتركه كما هو.

نشر Jeffrey Fritz للتو تعمقًا كاملًا في تقييم تحديث GitHub Copilot، وصراحةً؟ هذه أفضل أدوات الترحيل التي رأيتها لـ .NET. ليس بسبب توليد الكود — هذا أصبح أمرًا مفروغًا منه الآن. بل بسبب وثيقة التقييم التي تُنتجها.

إنها ليست مجرد محرك اقتراحات كود

تتبع إضافة VS Code نموذج تقييم ← تخطيط ← تنفيذ. تُحلّل مرحلة التقييم قاعدة الكود بأكملها وتُنتج وثيقة منظمة تلتقط كل شيء: ما يحتاج إلى التغيير، وموارد Azure المراد توفيرها، ونموذج النشر المراد استخدامه. كل ما يلي — كود البنية التحتية، والحاويات، وبيانات النشر — ينبع مما يجده التقييم.

يُخزَّن التقييم تحت .github/modernize/assessment/ في مشروعك. كل تشغيل يُنتج تقريرًا مستقلًا، لذا تبني سجلًا تاريخيًا ويمكنك تتبع كيف تتطور وضعية الترحيل لديك كلما أصلحت المشكلات.

طريقتان للبدء

التقييم الموصى به — المسار السريع. اختر من بين المجالات المنسّقة (ترقية Java/.NET، جاهزية السحابة، الأمان) واحصل على نتائج ذات معنى دون لمس التكوين. رائع للنظرة الأولى على وضع تطبيقك.

التقييم المخصص — المسار المستهدف. قم بتكوين ما تريد تحليله بالضبط: الحوسبة المستهدفة (App Service، AKS، Container Apps)، نظام التشغيل المستهدف، تحليل الحاويات. اختر أهدافًا متعددة على Azure لمقارنة مناهج الترحيل جنبًا إلى جنب.

عرض المقارنة مفيد حقًا. تطبيق به 3 مشكلات إلزامية لـ App Service قد يكون لديه 7 لـ AKS. رؤية كليهما يساعد في اتخاذ قرار الاستضافة قبل الالتزام بمسار الترحيل.

تفصيل المشكلات قابل للتنفيذ

كل مشكلة تأتي بمستوى حرجية:

إلزامية — يجب إصلاحها وإلا يفشل الترحيل
محتملة — قد تؤثر على الترحيل، تحتاج إلى حكم بشري
اختيارية — تحسينات موصى بها، لن تعيق الترحيل

وكل مشكلة تربط بالملفات والأسطر المتأثرة، وتُقدم وصفًا تفصيليًا لما هو خاطئ ولماذا يهم ذلك للمنصة المستهدفة، وتُعطي خطوات معالجة ملموسة (ليس فقط “أصلح هذا”)، وتتضمن روابط للتوثيق الرسمي.

يمكنك تسليم مشكلات فردية للمطورين وسيكون لديهم كل ما يحتاجون إليه للتصرف. هذا هو الفرق بين أداة تخبرك “هناك مشكلة” وأخرى تخبرك كيف تحلها.

مسارات الترقية المدعومة

لـ .NET تحديدًا:

.NET Framework ← .NET 10
ASP.NET ← ASP.NET Core

كل مسار ترقية له قواعد كشف تعرف أي واجهات API أُزيلت، وأي أنماط ليس لها مقابل مباشر، وما هي مشكلات الأمان التي تحتاج إلى اهتمام.

بالنسبة للفرق التي تدير تطبيقات متعددة، هناك أيضًا واجهة سطر أوامر (CLI) تدعم تقييمات دفعية متعددة المستودعات — استنسخ جميع المستودعات، وقيّمها جميعًا، واحصل على تقارير لكل تطبيق بالإضافة إلى عرض تجميعي للمحفظة.

رأيي

إذا كنت تجلس على تطبيقات .NET Framework قديمة (ولنكن صريحين، معظم فرق المؤسسات كذلك)، فهذه هي الأداة التي تبدأ بها. وثيقة التقييم وحدها تستحق الوقت — إنها تحوّل “يجب أن نحدّث” الغامضة إلى قائمة ملموسة ذات أولويات من بنود العمل مع مسارات واضحة للمضي قدمًا.

سير العمل التعاوني ذكي أيضًا: صدّر التقييمات، وشاركها مع فريقك، واستوردها دون إعادة التشغيل. مراجعات المعمارية حيث صانعو القرار ليسوا من يشغّل الأدوات؟ مغطاة.

خلاصة

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

اقرأ الشرح التفصيلي الكامل واحصل على إضافة VS Code لتجربتها على قاعدة الكود الخاصة بك.

هندسة المنصات الوكيلية تصبح حقيقة — Git-APE يُظهر كيف

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

كانت هندسة المنصات من تلك المصطلحات التي تبدو رائعة في محادثات المؤتمرات لكنها عادةً ما تعني “أنشأنا بوابة داخلية وغلافاً لـ Terraform.” الوعد الحقيقي — بنية تحتية ذاتية الخدمة آمنة فعلاً ومُحكَّمة وسريعة — كانت دائماً على بُعد خطوات.

نشر فريق Azure للتو الجزء الثاني من سلسلة هندسة المنصات الوكيلية، وهذا الجزء يتعلق بالتطبيق العملي. يطلقون عليه Git-APE (نعم، الاختصار مقصود)، وهو مشروع مفتوح المصدر يستخدم وكلاء GitHub Copilot بالإضافة إلى خوادم Azure MCP لتحويل الطلبات باللغة الطبيعية إلى بنية تحتية مُتحقَّق منها ومنشورة.

ما الذي يفعله Git-APE فعلاً

الفكرة الجوهرية: بدلاً من تعلّم المطوّرين وحدات Terraform، أو التنقل في واجهات المستخدم للبوابات، أو تقديم تذاكر إلى فريق المنصة، يتحدثون مع وكيل Copilot. يفسّر الوكيل النية، ويولّد البنية التحتية كأكواد، ويتحقق منها مقابل السياسات، وينشر — كل ذلك داخل VS Code.

إليك الإعداد:

git clone https://github.com/Azure/git-ape
cd git-ape

افتح مساحة العمل في VS Code، وتُكتشف ملفات إعداد الوكيل تلقائياً بواسطة GitHub Copilot. تتفاعل مع الوكيل مباشرةً:

@git-ape deploy a function app with storage in West Europe

يستخدم الوكيل Azure MCP Server خلف الكواليس للتفاعل مع خدمات Azure. يُمكّن إعداد MCP في إعدادات VS Code قدرات محددة:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

لماذا يهمّ هذا

لمن يبنون على Azure، يحوّل هذا محادثة هندسة المنصات من “كيف نبني بوابة” إلى “كيف نصف حواجز الحماية كواجهات برمجية.” حين تكون واجهة منصتك وكيل ذكاء اصطناعي، تصبح جودة قيودك وسياساتك هي المنتج.

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

التنظيف بسيط بالقدر نفسه:

@git-ape destroy my-resource-group

رأيي

لأكن صريحاً — هذا يتعلق بالنمط أكثر من الأداة المحددة. Git-APE نفسه هو بنية مرجعية/توضيحية. لكن الفكرة الكامنة — الوكلاء كواجهة لمنصتك، وMCP كبروتوكول، وGitHub Copilot كمضيف — هي وجهة تجربة المطوّر في المؤسسات.

إذا كنت فريق منصة تبحث عن كيفية جعل أدواتك الداخلية صديقةً للوكلاء، فلا يوجد نقطة بداية أفضل. وإذا كنت مطوّر .NET تتساءل عن كيفية ارتباط هذا بعالمك: يعمل Azure MCP Server ووكلاء GitHub Copilot مع أي عبء عمل على Azure. واجهة برمجة ASP.NET Core، ومكدّس .NET Aspire، والخدمات المُعبّأة في حاويات — كل ذلك يمكن أن يكون هدفاً لتدفق نشر وكيلي.

خلاصة القول

Git-APE هو نظرة مبكرة لكن ملموسة على هندسة المنصات الوكيلية في التطبيق. استنسخ المستودع، وجرّب العرض التوضيحي، وابدأ في التفكير في كيفية احتياج واجهات برمجية منصتك وسياساتها للظهور حتى يستطيع الوكيل استخدامها بأمان.

اقرأ المقال الكامل للشرح التفصيلي والعروض التوضيحية المرئية.

تحديث Visual Studio لشهر مارس يتيح لك بناء وكلاء Copilot مخصصين — وأداة find_symbol تستحق الاهتمام

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

حصل Visual Studio للتو على أهم تحديث لـ Copilot حتى الآن. أعلن Mark Downie عن إصدار مارس، والعنوان الرئيسي هو الوكلاء المخصصون — لكن بصراحة، أداة find_symbol المدفونة في منتصف القائمة قد تكون الميزة التي ستغير سير عملك أكثر من أي شيء آخر.

دعني أشرح ما هو موجود فعلاً.

وكلاء Copilot مخصصون في مستودعك

هل تريد أن يتبع Copilot معايير ترميز فريقك، أو يشغّل خط أنابيب البناء، أو يستعلم وثائقك الداخلية؟ يمكنك الآن بناء ذلك بالضبط.

يُعرَّف الوكلاء المخصصون كملفات .agent.md تضعها في .github/agents/ في مستودعك. يتمتع كل وكيل بوصول كامل إلى الوعي بمساحة العمل، وفهم الكود، والأدوات، ونموذجك المفضل، واتصالات MCP بالخدمات الخارجية. تظهر هذه الوكلاء في منتقي الوكلاء إلى جانب الوكلاء المدمجين.

هذا النمط ذاته الذي كان VS Code يدعمه — ومن الجيد رؤية Visual Studio يلحق به. إذا كانت فرقتك قد بنت وكلاء لـ VS Code، فينبغي أن تعمل ملفات .agent.md عبر كلا بيئتَي التطوير (مع ذلك، قد تتباين أسماء الأدوات، لذا اختبرها).

يحتوي مستودع awesome-copilot على إعدادات وكلاء يُسهم بها المجتمع يمكنك استخدامها نقطة انطلاق.

مهارات الوكيل: حزم تعليمات قابلة لإعادة الاستخدام

يتم التقاط المهارات تلقائياً من .github/skills/ في مستودعك أو ~/.copilot/skills/ في ملفك الشخصي. كل مهارة هي ملف SKILL.md يتبع مواصفات Agent Skills.

فكّر في المهارات كخبرات معيارية يمكنك دمجها وتبديلها. قد تكون لديك مهارة لاصطلاحات API الخاصة بك، وأخرى لأنماط الاختبار، وأخرى لسير عمل النشر. عندما تنشط مهارة، تظهر في المحادثة حتى تعرف أنها مُطبَّقة.

إذا كنت تستخدم المهارات في VS Code، فهي تعمل بالطريقة ذاتها في Visual Studio الآن.

find_symbol: ملاحة رمزية تدرك اللغة للوكلاء

هنا تصبح الأمور مثيرة للاهتمام حقاً. تمنح أداة find_symbol الجديدة وضعَ وكيل Copilot ملاحةً رمزية فعلية مدعومة بخدمة اللغة. بدلاً من البحث في كودك كنص عادي، يمكن للوكيل:

إيجاد جميع المراجع لرمز عبر مشروعك
الوصول إلى معلومات النوع والإعلانات وبيانات النطاق
التنقل عبر مواقع الاستدعاء بوعي كامل باللغة

ما يعنيه هذا عملياً: عندما تطلب من Copilot إعادة هيكلة طريقة أو تحديث توقيع معامل عبر مواقع الاستدعاء، يمكنه فعلاً رؤية بنية كودك. لا مزيد من “قام الوكيل بتغيير الطريقة لكنه فاته ثلاثة مواقع استدعاء”.

اللغات المدعومة تشمل C# وC++ وRazor وTypeScript وأي لغة تتوفر لها إضافة LSP مدعومة. لمطوري .NET، هذا تحسين جوهري — قواعد كود C# ذات التسلسلات الهرمية العميقة للأنواع والواجهات تستفيد استفادة هائلة من الملاحة الرمزية.

تحليل أداء الاختبارات مع Copilot

يوجد الآن أمر Profile with Copilot في قائمة سياق Test Explorer. حدد اختباراً، انقر على التحليل، ويقوم وكيل التحليل تلقائياً بتشغيله وتحليل الأداء — يجمع بين بيانات استخدام المعالج وبيانات القياس لتقديم رؤى قابلة للتنفيذ.

لا مزيد من الإعداد اليدوي لجلسات المحلل، وتشغيل الاختبار، وتصدير النتائج، ومحاولة قراءة رسم بياني للهوية. يقوم الوكيل بالتحليل ويخبرك بما هو بطيء ولماذا. خاص بـ .NET حالياً، وهو أمر منطقي نظراً للتكامل العميق لـ Visual Studio مع أدوات تشخيص .NET.

نصائح الأداء أثناء التصحيح المباشر

أصبح تحسين الأداء يحدث أثناء التصحيح، لا بعده. بينما تتنقل خطوة بخطوة عبر الكود، يعرض Visual Studio وقت التنفيذ وإشارات الأداء بشكل مضمّن. هل ترى سطراً بطيئاً؟ انقر على Perf Tip واطلب من Copilot اقتراحات للتحسين في المكان ذاته.

يلتقط وكيل التحليل بيانات وقت التشغيل تلقائياً — الوقت المنقضي واستخدام المعالج وسلوك الذاكرة — ويستخدمها Copilot لتحديد مناطق الاختناق. هذا يجعل عمل الأداء جزءاً من سير عمل التصحيح بدلاً من مهمة منفصلة تؤجلها باستمرار.

إصلاح ثغرات NuGet من Solution Explorer

عندما تُكتشف ثغرة في حزمة NuGet، يظهر الآن إشعار مع رابط Fix with GitHub Copilot مباشرةً في Solution Explorer. انقر عليه ويحلل Copilot الثغرة، ويوصي بتحديثات الحزمة المناسبة، وينفّذها.

للفرق التي تكافح للحفاظ على تحديث التبعيات (وهو ما يصف الجميع تقريباً)، يُزيل هذا احتكاك “أعرف أن هناك ثغرة لكن معرفة مسار التحديث الصحيح مشروع بحد ذاته.”

خلاصة القول

الوكلاء المخصصون والمهارات هي العنوان الرئيسي، لكن find_symbol هي البطل الهادئ — إنها تغير جوهرياً مدى دقة Copilot عند إعادة هيكلة كود .NET. مجتمعةً مع تكامل التحليل المباشر وإصلاحات الثغرات، يجعل هذا التحديث ميزات الذكاء الاصطناعي في Visual Studio تشعر بالفاعلية الحقيقية لا مجرد عروض توضيحية.

قم بتنزيل Visual Studio 2026 Insiders لتجربة كل ذلك.