Developer-Tools | The .NET Blog

Azure MCP Server الآن .mcpb — ثبّته بدون أي Runtime

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

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

هل تعرف ما الذي كان مزعجًا في إعداد خوادم MCP؟ كنت بحاجة إلى runtime. Node.js لنسخة npm، وPython لـ pip/uvx، و.NET SDK لمتغير dotnet.

غيّر Azure MCP Server كل ذلك للتو. أصبح متاحًا الآن كـ .mcpb — MCP Bundle — والإعداد بالسحب والإفلات.

ما هو MCP Bundle؟

فكّر فيه كامتداد VS Code (.vsix) أو امتداد متصفح (.crx)، ولكن لخوادم MCP. ملف .mcpb هو أرشيف ZIP مكتفٍ بذاته يتضمن الملف الثنائي للخادم وجميع تبعياته.

كيفية التثبيت

1. نزّل الحزمة لمنصتك

انتقل إلى صفحة GitHub Releases ونزّل ملف .mcpb لنظام تشغيلك ومعماريتك.

2. ثبّت في Claude Desktop

الطريقة الأسهل: اسحب ملف .mcpb وأفلته في نافذة Claude Desktop بينما تكون على صفحة إعدادات الامتدادات (☰ → ملف → الإعدادات → الامتدادات). راجع تفاصيل الخادم، انقر تثبيت، وأكّد.

3. المصادقة على Azure

az login

هذا كل شيء. يستخدم Azure MCP Server بيانات اعتماد Azure الموجودة لديك.

للبدء

التنزيل: GitHub Releases
المستودع: aka.ms/azmcp
التوثيق: aka.ms/azmcp/docs

اطلع على المقال الكامل.

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 إصدار مهم (صدر الإصدار التجريبي منذ أيام).

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

Foundry Toolboxes: نقطة نهاية واحدة لجميع أدوات وكلاء الذكاء الاصطناعي

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

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

ثمة مشكلة تبدو عادية حتى تواجهها بنفسك: تبني المؤسسة وكلاء ذكاء اصطناعي متعددة، كل منها يحتاج أدوات، وكل فريق يُهيؤها من الصفر. نفس تكامل البحث على الويب، نفس إعداد Azure AI Search، نفس اتصال خادم GitHub MCP — لكن في مستودع مختلف، من فريق مختلف، ببيانات اعتماد مختلفة، ودون أي حوكمة مشتركة.

أطلقت Microsoft Foundry للتو Toolboxes في معاينة عامة، وهو إجابة مباشرة على هذه المشكلة.

ما هو Toolbox؟

Toolbox هو حزمة أدوات مُسمّاة وقابلة لإعادة الاستخدام، تُعرَّف مرة واحدة في Foundry وتُعرض عبر نقطة نهاية واحدة متوافقة مع MCP. أي بيئة تشغيل وكيل تتحدث MCP يمكنها استهلاكه — دون قيد على Foundry Agents.

الوعد بسيط: build once, consume anywhere. عرِّف الأدوات، هيِّئ المصادقة مركزيًا (OAuth passthrough، الهوية المُدارة في Entra)، انشر نقطة النهاية. كل وكيل يحتاج تلك الأدوات يتصل بنقطة النهاية ويحصل عليها جميعًا.

الأركان الأربعة (اثنان متاحان اليوم)

الركن	الحالة	ما يفعله
Discover	قريبًا	إيجاد الأدوات المعتمدة دون بحث يدوي
Build	متاح	تجميع الأدوات في حزمة قابلة لإعادة الاستخدام
Consume	متاح	نقطة نهاية MCP واحدة تعرض جميع الأدوات
Govern	قريبًا	مصادقة مركزية + إمكانية مراقبة جميع استدعاءات الأدوات

مثال عملي

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="البحث في الوثائق والرد على issues في GitHub",
 tools=[
 {"type": "web_search", "description": "البحث في الوثائق العامة"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

بعد النشر، تُوفر Foundry نقطة نهاية موحدة. اتصال واحد، جميع الأدوات.

لا قيد على Foundry Agents

تُنشأ Toolboxes وتُدار في Foundry، لكن سطح الاستهلاك هو بروتوكول MCP المفتوح. يمكن استخدامها من وكلاء مخصصة (Microsoft Agent Framework، LangGraph)، وGitHub Copilot وبيئات IDE الأخرى المتوافقة مع MCP.

لماذا يهم هذا الآن

موجة الوكلاء المتعددة تصل إلى الإنتاج. كل وكيل جديد هو سطح جديد للإعداد المكرر والبيانات الاعتمادية القديمة والسلوك غير المتسق. أساس Build + Consume كافٍ للبدء في المركزة. حين يصل ركن Govern، ستتوفر طبقة أدوات قابلة للمراقبة الكاملة ومُتحكَّم بها مركزيًا لكامل أسطول الوكلاء.

خلاصة

لا يزال مبكرًا — معاينة عامة، Python SDK أولًا، مع Discover وGovern في الطريق. لكن النموذج راسخ والتصميم الأصيل لـ MCP يعني أنه يعمل مع الأدوات التي تُبنى بالفعل. جميع التفاصيل في الإعلان الرسمي.

Windows App Dev CLI v0.3: تشغيل F5 من الطرفية وأتمتة واجهة المستخدم للوكلاء الذكيين

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

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

تجربة F5 في Visual Studio رائعة. لكن فتح VS لمجرد تشغيل تطبيق Windows مُحزَّم وتنقيحه — سواء في خط أنابيب CI، أو سير عمل آلي، أو عندما يُجري وكيل ذكاء اصطناعي الاختبارات — يُشكّل عبئًا زائدًا.

صدر الإصدار v0.3 من Windows App Development CLI للتو، ويعالج هذا الأمر مباشرةً بميزتين رئيسيتين: winapp run وwinapp ui.

winapp run: F5 من أي مكان

يستقبل winapp run مجلد تطبيق غير مُحزَّم وملف manifest، وينفّذ كل ما يفعله VS عند تشغيل التنقيح: تسجيل حزمة loose، وتشغيل التطبيق، والحفاظ على LocalState بين عمليات إعادة النشر.

# قم ببناء التطبيق، ثم شغّله كتطبيق مُحزَّم
winapp run ./bin/Debug

يعمل مع WinUI وWPF وWinForms وConsole وAvalonia والمزيد. صُمِّمت الأوضاع للمطورين وسير العمل الآلي على حد سواء:

--detach: يُشغَّل التطبيق ويُعاد التحكم فورًا إلى الطرفية. مثالي لـ CI.
--unregister-on-exit: يُزيل الحزمة المُسجَّلة عند إغلاق التطبيق.
--debug-output: يلتقط رسائل OutputDebugString والاستثناءات في الوقت الفعلي.

حزمة NuGet جديدة: dotnet run للتطبيقات المُحزَّمة

يتوفر للمطورين العاملين بـ .NET حزمة NuGet جديدة: Microsoft.Windows.SDK.BuildTools.WinApp. بعد التثبيت، يتولى dotnet run إدارة الحلقة الداخلية بأكملها: البناء، وتحضير حزمة loose-layout، والتسجيل في Windows، والتشغيل — كل ذلك في خطوة واحدة.

winapp init
# أو
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: أتمتة واجهة المستخدم من سطر الأوامر

هذه هي الميزة التي تفتح سيناريوهات الوكلاء الذكيين. يوفر winapp ui وصولًا كاملًا عبر UI Automation لأي تطبيق Windows قيد التشغيل — WPF وWinForms وWin32 وElectron وWinUI3 — مباشرةً من الطرفية.

ما يمكن تحقيقه:

سرد جميع النوافذ على المستوى الأعلى
التنقل في شجرة UI Automation الكاملة لأي نافذة
البحث عن عناصر بالاسم أو النوع أو معرّف الأتمتة
النقر والاستدعاء وتعيين القيم
التقاط لقطات الشاشة
انتظار ظهور العناصر — مثالي لمزامنة الاختبارات

يُتيح الجمع بين winapp ui وwinapp run سير عملًا كاملًا من الطرفية: بناء ← تشغيل ← تحقق. يمكن للوكيل تشغيل التطبيق، وفحص حالة الواجهة، والتفاعل برمجيًا، والتحقق من النتيجة.

مستجدات أخرى

winapp unregister: يحذف حزمة sideloaded عند الانتهاء.
winapp manifest add-alias: يُضيف اسمًا مستعارًا لتشغيل التطبيق بالاسم من الطرفية.
إكمال تلقائي بـ Tab: تهيئة إكمال PowerShell بأمر واحد.

كيفية التثبيت

winget install Microsoft.WinAppCli
# أو
npm install -g @microsoft/winappcli

الأداة في معاينة عامة. راجع مستودع GitHub للتوثيق الكامل، والإعلان الأصلي لجميع التفاصيل.

كتابة Hooks في azd بـ Python وTypeScript و.NET: وداعًا لسكريبتات Shell

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

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

إن كنت قد امتلكت مشروعًا بالكامل بـ .NET واضطررت رغم ذلك إلى كتابة سكريبتات Bash لـ hooks في azd، فأنت تعرف هذا الألم. لماذا التبديل إلى صياخة shell في خطوة pre-provisioning بينما كل شيء آخر في المشروع مكتوب بـ C#؟

هذا الإحباط لديه الآن حل رسمي. أطلقت Azure Developer CLI دعم متعدد اللغات لـ hooks، وهو بالضبط بقدر ما يبدو جيدًا.

ما هي الـ Hooks

الـ Hooks هي سكريبتات تعمل في نقاط حيوية من دورة حياة azd — قبل provisioning، وبعد deployment، والمزيد. تُعرَّف في azure.yaml وتتيح حقن منطق مخصص دون تعديل الـ CLI.

في السابق، دُعم فقط Bash وPowerShell. الآن يمكن استخدام Python أو JavaScript أو TypeScript أو .NET — ويتولى azd الباقي تلقائيًا.

كيف يعمل الاستدلال

ما عليك سوى الإشارة إلى ملف وسيستنتج azd اللغة من الامتداد:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

لا إعداد إضافي. إذا كان الامتداد غامضًا، يمكنك إضافة kind: python (أو اللغة المناسبة) صراحةً.

تفاصيل مهمة حسب اللغة

Python

ضع requirements.txt أو pyproject.toml بجانب السكريبت (أو في أي دليل أعلى). سينشئ azd بيئة افتراضية تلقائيًا، ويثبت التبعيات، ويشغل السكريبت.

JavaScript وTypeScript

نفس النمط — ضع package.json بالقرب من السكريبت وسيشغل azd أولاً npm install. بالنسبة لـ TypeScript يستخدم npx tsx دون خطوة تجميع ودون tsconfig.json.

.NET

وضعان متاحان:

وضع المشروع: إذا كان هناك .csproj بجانب السكريبت، سيشغل azd تلقائيًا dotnet restore وdotnet build.
وضع الملف الواحد: في .NET 10+ يمكن تشغيل ملفات .cs المستقلة مباشرةً عبر dotnet run script.cs. لا حاجة لملف مشروع.

إعداد خاص بكل منفذ

تدعم كل لغة كتلة config اختيارية:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

لماذا يهم هذا لمطوري .NET

كانت الـ hooks آخر مكان في مشروع قائم على azd يجبر على تغيير اللغة. الآن يمكن لكامل pipeline النشر — من كود التطبيق إلى lifecycle hooks — أن يعيش في لغة واحدة. يمكنك إعادة استخدام أدوات .NET الموجودة في hooks، والإشارة إلى مكتبات مشتركة، والتخلص من صيانة سكريبتات shell.

خلاصة

أحد تلك التغييرات التي تبدو صغيرة لكنها تزيل الكثير من الاحتكاك اليومي مع azd. دعم متعدد اللغات لـ hooks متاح الآن — تحقق من المنشور الرسمي للحصول على التوثيق الكامل.

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 وبيئة تنفيذ آمنة هو بالضبط ما كانت فرق الإنتاج تنتظره.

توقف عن حراسة طرفيتك: الوضع المنفصل في Aspire يغير سير العمل

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

في كل مرة تشغّل فيها Aspire AppHost، تختفي طرفيتك. مقفلة. مشغولة حتى Ctrl+C. تريد تشغيل أمر سريع؟ افتح تبويبًا جديدًا. تريد التحقق من السجلات؟ تبويب آخر. هذا الاحتكاك الصغير يتراكم بسرعة.

يحل Aspire 13.2 هذا. كتب James Newton-King تفاصيل كاملة، وبصراحة، هذه إحدى تلك الميزات التي تُغيّر طريقة عملك فوراً.

الوضع المنفصل: أمر واحد، الطرفية تعود

aspire start

هذا اختصار لـ aspire run --detach. يعمل AppHost الخاص بك في الخلفية وتستعيد طرفيتك فوراً.

إدارة ما يعمل

التشغيل في الخلفية مفيد فقط إذا كنت تستطيع إدارة ما هو جارٍ. يأتي Aspire 13.2 بمجموعة كاملة من أوامر CLI:

# قائمة جميع AppHost العاملة
aspire ps

# فحص حالة AppHost محدد
aspire describe

# بث السجلات من AppHost العامل
aspire logs

# إيقاف AppHost محدد
aspire stop

دمجه مع الوضع المعزول

الوضع المنفصل يتزاوج طبيعياً مع الوضع المعزول:

aspire start --isolated
aspire start --isolated

كل مثيل يحصل على منافذ عشوائية وأسرار منفصلة ودورة حياة خاصة به.

لماذا هذا ضخم لوكلاء البرمجة

وكيل البرمجة الذي يعمل في طرفيتك يمكنه الآن:

تشغيل التطبيق بـ aspire start
الاستعلام عن حالته بـ aspire describe
التحقق من السجلات بـ aspire logs لتشخيص المشكلات
إيقافه بـ aspire stop عند الانتهاء

تشغيل aspire agent init يهيّئ ملف مهارات Aspire الذي يعلّم الوكلاء هذه الأوامر.

خلاصة

الوضع المنفصل هو ترقية لسير العمل متنكرة كعلامة بسيطة. اقرأ المقال كاملاً واحصل على Aspire 13.2 مع aspire update --self.

أدوات Azure MCP مدمجة الآن في Visual Studio 2022 — لا حاجة إلى امتداد

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

إذا كنت تستخدم أدوات Azure MCP في Visual Studio من خلال الامتداد المنفصل، فأنت تعرف العملية — تثبيت VSIX، إعادة التشغيل، والأمل ألا ينكسر، وإدارة تعارضات الإصدارات. لقد اختفى هذا الاحتكاك.

أعلنت Yun Jung Choi أن أدوات Azure MCP تُشحن الآن مباشرةً كجزء من حمل عمل تطوير Azure في Visual Studio 2022. بدون امتداد. بدون VSIX. بدون رقصة إعادة التشغيل.

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

ابتداءً من Visual Studio 2022 الإصدار 17.14.30، يأتي Azure MCP Server مجمّعاً مع حمل عمل تطوير Azure. إذا كان حمل العمل هذا مثبتاً بالفعل، فتحتاج فقط إلى تفعيله في GitHub Copilot Chat وستنتهي.

أكثر من 230 أداة عبر 45 خدمة Azure — متاحة مباشرةً من نافذة الدردشة. سرّد حسابات التخزين لديك، انشر تطبيق ASP.NET Core، شخّص مشاكل App Service، استعلم Log Analytics — كل ذلك دون فتح أي علامة تبويب في المتصفح.

لماذا هذا أهم مما يبدو

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

مسار تحديث واحد عبر Visual Studio Installer
لا انجراف في الإصدارات بين الامتداد وبيئة التطوير المتكاملة
دائماً حديث — يتحدث MCP Server مع إصدارات VS المنتظمة

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

ما الذي يمكنك فعله به

تغطي الأدوات دورة التطوير الكاملة من خلال Copilot Chat:

التعلم — اسأل عن خدمات Azure وأفضل الممارسات وأنماط البنية
التصميم والتطوير — احصل على توصيات الخدمة وضبط كود التطبيق
النشر — زوّد الموارد وانشر مباشرةً من بيئة التطوير المتكاملة
استكشاف الأخطاء — استعلم السجلات وتحقق من صحة الموارد وشخّص مشاكل الإنتاج

مثال سريع — اكتب هذا في Copilot Chat:

List my storage accounts in my current subscription.

يستدعي Copilot أدوات Azure MCP في الخلفية، ويستعلم اشتراكاتك، ويعيد قائمة منسقة بالأسماء والمواقع وحيازات SKU. لا حاجة إلى البوابة الإلكترونية.

كيفية التفعيل

حدّث إلى Visual Studio 2022 17.14.30 أو أحدث
تأكد من تثبيت حمل عمل Azure development
افتح GitHub Copilot Chat
انقر على زر Select tools (أيقونة المفكَّين)
فعّل Azure MCP Server

هذا كل شيء. يبقى مفعّلاً عبر الجلسات.

تحفظ واحد

الأدوات معطلة افتراضياً — تحتاج إلى الاشتراك الصريح. والأدوات الخاصة بـ VS 2026 غير متاحة في VS 2022. كما يعتمد توافر الأدوات على أذونات اشتراك Azure لديك، تماماً كما في البوابة الإلكترونية.

الصورة الأكبر

هذا جزء من اتجاه واضح: يصبح MCP الطريقة المعيارية لعرض أدوات السحابة في بيئات تطوير المطورين. رأينا بالفعل إصدار Azure MCP Server 2.0 المستقر وتكاملات MCP عبر VS Code والمحررات الأخرى. دمجه في نظام حمل العمل في Visual Studio هو التطور الطبيعي.

بالنسبة لنا كمطوري .NET الذين يعيشون داخل Visual Studio، يزيل هذا سبباً آخر للتحول إلى بوابة Azure. وبصراحة، كلما قل التبديل بين علامات التبويب، كان ذلك أفضل.

azd update — أمر واحد يتحكّم في جميع مديري الحزم

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

هل تعرف رسالة “إصدار جديد من azd متاح” التي تظهر كل أسابيع قليلة؟ تلك التي تتجاهلها لأنك لا تتذكر إن كنت قد ثبّتت azd عبر winget أو Homebrew أو ذلك السكريبت curl الذي شغّلته قبل ستة أشهر؟ نعم، تمّ حلّ هذا الأمر أخيراً.

شحنت Microsoft للتو azd update — أمر واحد يُحدّث Azure Developer CLI إلى أحدث إصدار بصرف النظر عن طريقة تثبيتك الأصلية. Windows، macOS، Linux — لا يهم. أمر واحد.

كيف يعمل

azd update

هذا كل شيء. إن أردت الوصول المبكر إلى الميزات الجديدة، يمكنك التبديل إلى بناء الـ insiders اليومي:

azd update --channel daily
azd update --channel stable

يكتشف الأمر طريقة التثبيت الحالية لديك ويستخدم آلية التحديث المناسبة داخلياً. لا مزيد من “انتظر، هل استخدمت winget أم choco على هذا الجهاز؟”.

التحفّظ الصغير

يأتي azd update ابتداءً من الإصدار 1.23.x. إن كنت على إصدار أقدم، ستحتاج إلى إجراء تحديث يدوي أخير باستخدام طريقة تثبيتك الأصلية. بعد ذلك، azd update يتولى كل شيء من الآن فصاعداً.

تحقق من إصدارك الحالي بـ azd version. إن احتجت تثبيتاً جديداً، وثائق التثبيت ستُرشدك.

لماذا هذا مهم

هذا تحسين صغير لجودة الحياة، لكن بالنسبة لأولئك منّا الذين يستخدمون azd يومياً لنشر وكلاء الذكاء الاصطناعي وتطبيقات Aspire إلى Azure، البقاء محدّثاً يعني حالات أقل من “هذه الخطأ تمّ إصلاحها بالفعل في الإصدار الأخير”. شيء واحد أقل يجب التفكير فيه.

اقرأ الإعلان الكامل والغوص العميق لـ Jon Gallant هنا لمزيد من السياق.

.NET Aspire 13.2 يريد أن يكون أفضل صديق لوكيل الذكاء الاصطناعي

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

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

نشر فريق Aspire للتو منشوراً متأنياً للغاية حول هذه المشكلة بالضبط، وإجابتهم مقنعة: صُمِّم Aspire 13.2 ليس للبشر وحدهم، بل لوكلاء الذكاء الاصطناعي أيضاً.

المشكلة حقيقية

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

نضيف تعليمات Markdown ومهارات مخصصة وإرشادات محددة لتوجيهها، غير أن كل ذلك غير موثوق، ولا يمكن تصريفه، ويكلف رصيداً من التوكن لمجرد تحليله. أصاب فريق Aspire جوهر المسألة: تحتاج الوكلاء إلى مصرِّفات وواجهات برمجية منظّمة، لا إلى مزيد من Markdown.

Aspire بوصفه بنية تحتية للوكلاء

إليك ما يُقدّمه Aspire 13.2 في مجال التطوير الوكيلي:

مكدّسك البرمجي بالكامل في كود موجَّه بالأنواع. يُعرِّف AppHost طوبولوجيا تطبيقك الكاملة — واجهة برمجية، وواجهة أمامية، وقاعدة بيانات، وذاكرة تخزين مؤقت — في TypeScript أو C# قابل للتصريف:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

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

أمر واحد يتحكم في الجميع. بدلاً من إدارة الوكيل لـ docker compose up وnpm run dev وسكريبتات تشغيل قاعدة البيانات بشكل منفصل، كل شيء يكون ببساطة aspire start. تنطلق جميع الموارد بالترتيب الصحيح، على المنافذ الصحيحة، بالإعداد الصحيح. العمليات طويلة الأمد لن تعلّق الوكيل أيضاً — Aspire يتولى إدارتها.

الوضع المعزول للوكلاء المتوازية. مع --isolated، تحصل كل عملية تشغيل في Aspire على منافذ عشوائية خاصة بها وأسرار مستخدم منفصلة. هل لديك عدة وكلاء تعمل عبر worktrees مختلفة في Git؟ لن تتعارض. هذا أمر بالغ الأهمية لأدوات مثل وكلاء الخلفية في VS Code التي تُطلق بيئات متوازية.

عيون الوكيل من خلال التتبع التشخيصي. هنا يصبح الأمر قوياً حقاً. تكشف واجهة Aspire CLI عن بيانات OpenTelemetry كاملة أثناء التطوير — التتبعات، والمقاييس، والسجلات المنظّمة. لا يقتصر الوكيل على قراءة مخرجات وحدة التحكم وتأمّل الخير. يستطيع تتبّع طلب فاشل عبر الخدمات، وتحديد نقاط الاختناق في النقاط الطرفية البطيئة، وتحديد موضع الخلل بدقة. هذه إمكانية مراقبة بجودة الإنتاج في حلقة التطوير.

تشبيه حواجز مضمار البولينغ

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

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

البدء

جديد على Aspire؟ ثبِّت واجهة CLI من get.aspire.dev واتبع دليل البدء السريع.

تستخدم Aspire بالفعل؟ شغِّل aspire update --self للحصول على الإصدار 13.2، ثم وجِّه وكيل البرمجة المفضّل لديك نحو مستودعك. قد تتفاجأ بمدى تقدّمه مع الحواجز الواقية التي يُوفّرها Aspire.

خلاصة القول

لم يعد Aspire 13.2 مجرد إطار للتطبيقات الموزّعة — إنه يتحوّل إلى بنية تحتية أساسية للوكلاء. تعريفات المكدّس المنظّمة، والإطلاق بأمر واحد، والتشغيل المتوازي المعزول، وبيانات التتبع التشخيصي في الوقت الفعلي، كل ذلك يمنح وكلاء الذكاء الاصطناعي تحديداً ما يحتاجونه للانتقال من كتابة الكود إلى شحن التطبيقات.

اقرأ المنشور الكامل من فريق Aspire للاطلاع على كل التفاصيل ومقاطع الفيديو التوضيحية.

VS Code 1.116 — تطبيق Agents يحصل على التنقل بلوحة المفاتيح وإكمالات سياق الملفات

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

VS Code 1.116 هو إصدار أبريل 2026، وبينما يكون أخف من بعض التحديثات الأخيرة، فإن التغييرات مركّزة وذات معنى — خاصةً إذا كنت تستخدم تطبيق Agents يومياً.

إليك ما وصل، استناداً إلى ملاحظات الإصدار الرسمية.

تحسينات تطبيق Agents

يستمر تطبيق Agents في النضج مع صقل لقابلية الاستخدام يُحدث فارقاً حقيقياً في سير العمل اليومي:

اختصارات لوحة مفاتيح مخصصة — يمكنك الآن التركيز على عرض Changes، وشجرة الملفات داخل Changes، وعرض Chat Customizations باستخدام أوامر واختصارات لوحة مفاتيح مخصصة. إذا كنت تنقر في تطبيق Agents للتنقل بين العناصر، فهذا يجلب سير عمل كامل بلوحة المفاتيح.

مربع حوار المساعدة لإمكانية الوصول — يؤدي الضغط على Alt+F1 في مربع إدخال المحادثة الآن إلى فتح مربع حوار مساعدة يُظهر الأوامر المتاحة واختصارات لوحة المفاتيح. يمكن لمستخدمي قارئات الشاشة أيضاً التحكم في مستوى التفصيل في الإعلانات. إمكانية الوصول الجيدة تفيد الجميع.

إكمالات سياق الملفات — اكتب # في محادثة تطبيق Agents لتشغيل إكمالات سياق الملفات المحدودة بمساحة عملك الحالية. هذا أحد تلك التحسينات الصغيرة لجودة الحياة التي تُسرّع كل تفاعل — لا مزيد من كتابة مسارات الملفات الكاملة عند الإشارة إلى الكود.

حل روابط CSS `@import`

ميزة لطيفة لمطوري الواجهة الأمامية: يحل VS Code الآن مراجع CSS @import التي تستخدم مسارات node_modules. يمكنك Ctrl+النقر خلال عمليات الاستيراد مثل @import "some-module/style.css" عند استخدام المُجمِّعات. بسيطة لكنها تُزيل نقطة احتكاك في سير عمل CSS.

خلاصة القول

VS Code 1.116 يدور حول الصقل — يجعل تطبيق Agents أكثر قابلية للتنقل وأسهل في الوصول وأكثر ملاءمة للوحة المفاتيح. إذا كنت تقضي وقتاً كبيراً في تطبيق Agents (وأظن أن كثيراً منا يفعل)، فإن هذه التغييرات تتراكم لتُحسّن تجربتك.

اطلع على ملاحظات الإصدار الكاملة للقائمة الشاملة.

إعداد النوافذ العائمة في Visual Studio الذي لم تكن تعرفه (لكنك يجب أن تعرفه)

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

إذا كنت تستخدم شاشات متعددة مع Visual Studio (وصراحةً، من لا يفعل ذلك في هذه الأيام)، فقد اختبرت على الأرجح هذا الإزعاج: نوافذ الأدوات العائمة تختفي عند تصغير بيئة التطوير الرئيسية، وتظل دائماً فوق كل شيء آخر، ولا تظهر كأزرار منفصلة في شريط المهام. يناسب هذا بعض سير العمل، لكنه محبط مع إعدادات الشاشات المتعددة.

شارك Mads Kristensen من فريق Visual Studio إعداداً غير معروف يغير كلياً طريقة تصرف النوافذ العائمة. قائمة منسدلة واحدة. هذا كل شيء.

الإعداد

Tools > Options > Environment > Windows > Floating Windows

تحتوي القائمة المنسدلة “These floating windows are owned by the main window” على ثلاثة خيارات:

None — استقلالية كاملة. كل نافذة عائمة تحصل على إدخالها الخاص في شريط المهام وتتصرف كنافذة Windows عادية.
Tool Windows (الافتراضي) — تطفو المستندات بحرية، وتظل نوافذ الأدوات مرتبطة ببيئة التطوير.
Documents and Tool Windows — السلوك الكلاسيكي لـ Visual Studio، كل شيء مرتبط بالنافذة الرئيسية.

لماذا يُعدّ “None” الخيار الأمثل مع الشاشات المتعددة

اضبطه على None وستتصرف جميع نوافذ الأدوات العائمة والمستندات فجأة كتطبيقات Windows حقيقية. تظهر في شريط المهام، وتبقى مرئية عند تصغير نافذة Visual Studio الرئيسية، وتتوقف عن إجبار نفسها إلى مقدمة كل شيء.

ادمج هذا مع PowerToys FancyZones ويصبح الأمر مغيّراً لقواعد اللعبة. أنشئ تخطيطات مخصصة عبر شاشاتك، وثبّت Solution Explorer في منطقة، ومنقّح الأخطاء في أخرى، وملفات الكود أينما تريد. كل شيء يبقى في مكانه، وكل شيء يمكن الوصول إليه باستقلالية، ويشعر مساحة عملك بالتنظيم بدلاً من الفوضى.

توصيات سريعة

مستخدمو الشاشات المتعددة: اضبط على None، وادمجه مع FancyZones
المستخدمون العرضيون للنوافذ العائمة: Tool Windows (الافتراضي) خيار وسط جيد
سير العمل التقليدي: Documents and Tool Windows يحافظ على كل شيء كلاسيكياً

نصيحة احترافية: Ctrl + نقر مزدوج على شريط عنوان أي نافذة أداة لتعويمها أو إرسائها فوراً. لا يلزم إعادة تشغيل بعد تغيير الإعداد.

خلاصة القول

إنه أحد تلك الإعدادات التي تجعلك تفكر “لا أصدق أنني لم أكن أعرف عن هذا”. إذا كانت النوافذ العائمة في Visual Studio قد أزعجتك يوماً، فاذهب وغيّر هذا الإعداد الآن.

اقرأ المقال الكامل للتفاصيل ولقطات الشاشة.

الوضع المعزول في Aspire يحلّ كابوس تعارض المنافذ في التطوير المتوازي

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

إن سبق لك أن حاولت تشغيل نسختين من المشروع ذاته في الوقت نفسه، فأنت تعرف معاناة ذلك. المنفذ 8080 مشغول بالفعل. المنفذ 17370 محجوز. أوقف شيئاً، وأعد التشغيل، وتعامل مع متغيرات البيئة — إنه مُدمِّر للإنتاجية.

هذه المشكلة تزداد سوءاً لا تحسّناً. وكلاء الذكاء الاصطناعي تُنشئ worktrees في Git للعمل بشكل مستقل. وكلاء الخلفية تُطلق بيئات منفصلة. المطورون يستنسخون المستودع ذاته مرتين لفروع الميزات. كل هذه السيناريوهات تصطدم بالحائط نفسه: نسختان من التطبيق ذاته تتصارعان على المنافذ ذاتها.

يُعالج Aspire 13.2 هذا بخيار واحد. كتب James Newton-King من فريق Aspire التفاصيل الكاملة، وهي إحدى تلك الميزات التي تجعلك تتساءل “لماذا لم يكن هذا موجوداً من قبل؟”.

الحل: `--isolated`

aspire run --isolated

هذا كل شيء. تحصل كل عملية تشغيل على:

منافذ عشوائية — لا مزيد من التعارضات بين النسخ
أسرار مستخدم معزولة — سلاسل الاتصال ومفاتيح API تبقى منفصلة لكل نسخة

لا إعادة تعيين يدوية للمنافذ. لا تعامل مع متغيرات البيئة. تحصل كل عملية تشغيل على بيئة نظيفة خالية من التعارضات تلقائياً.

سيناريوهات حقيقية تبرز فيها هذه الميزة

نسخ متعددة. لديك فرع ميزة في دليل ما وإصلاح خطأ في آخر:

# الطرفية 1
cd ~/projects/my-app-feature
aspire run --isolated

# الطرفية 2
cd ~/projects/my-app-bugfix
aspire run --isolated

يعمل كلاهما دون تعارضات. تُظهر لوحة التحكم ما يعمل وأين.

وكلاء الخلفية في VS Code. حين ينشئ وكيل الخلفية في Copilot Chat worktree في Git للعمل على كودك بشكل مستقل، قد يحتاج إلى تشغيل AppHost في Aspire. دون --isolated، سيحدث تعارض في المنافذ مع worktree الرئيسية. معه، تعمل كلتا النسختين ببساطة.

مهارة Aspire التي تشحن مع aspire agent init تُوجّه الوكلاء تلقائياً لاستخدام --isolated عند العمل في worktrees. لذا يجب أن يتعامل وكيل الخلفية في Copilot مع هذا مباشرةً.

اختبارات التكامل جنباً إلى جنب مع التطوير. تحتاج إلى تشغيل الاختبارات مقابل AppHost حيّ أثناء مواصلة بناء الميزات؟ الوضع المعزول يمنح كل سياق منافذه وإعداداته الخاصة.

كيف يعمل داخلياً

حين تُمرّر --isolated، تُولّد واجهة CLI مُعرِّفاً فريداً للنسخة. يُشغّل هذا سلوكين:

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

لا يحتاج كودك إلى أي تغييرات. اكتشاف خدمات Aspire يحلّ نقاط النهاية في وقت التشغيل، لذا يتصل كل شيء بشكل صحيح بصرف النظر عن تعيين المنافذ.

متى تستخدمه

استخدم --isolated عند تشغيل نسخ متعددة من AppHost ذاته في الوقت نفسه — سواء كان ذلك تطويراً متوازياً، أو اختبارات آلية، أو وكلاء ذكاء اصطناعي، أو worktrees في Git. للتطوير بنسخة واحدة حيث تفضّل منافذ محددة، يظل aspire run العادي يعمل بشكل جيد.

خلاصة القول

الوضع المعزول ميزة صغيرة تحلّ مشكلة حقيقية ومتزايدة الشيوع. مع دفع التطوير بمساعدة الذكاء الاصطناعي نحو سير عمل أكثر توازياً — وكلاء متعددة، وworktrees متعددة، وسياقات متعددة — أصبحت القدرة على تشغيل نسخة أخرى ببساطة دون التصارع على المنافذ أمراً ضرورياً.

اقرأ المنشور الكامل للاطلاع على جميع التفاصيل التقنية وجرّبه بـ aspire update --self للحصول على الإصدار 13.2.

VS Code 1.115 — إشعارات الطرفيات الخلفية، واستضافة وكلاء SSH، والمزيد

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

وصل VS Code 1.115 للتو، وبينما يكون إصداراً أخف من حيث الميزات الرئيسية، فإن التحسينات المتعلقة بالوكيل مفيدة حقاً إذا كنت تعمل مع مساعدي الترميز بالذكاء الاصطناعي يومياً.

دعني أسلط الضوء على ما يستحق المعرفة فعلاً.

الطرفيات الخلفية تُبلّغ الوكلاء الآن

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

لماذا يهم هذا؟ إذا استخدمت وضع وكيل Copilot لتشغيل أوامر البناء أو مجموعات الاختبار في الخلفية، فأنت تعرف ألم سؤال “هل انتهى ذلك بعد؟” — كانت الطرفيات الخلفية أساساً نهج “أطلق وانسَ”. الآن يتلقى الوكيل إشعاراً عند اكتمال dotnet build أو dotnet test، يرى المخرجات، ويمكنه الاستجابة وفقاً لذلك. تغيير بسيط يجعل سير العمل المدفوع بالوكلاء أكثر موثوقية بشكل ملحوظ.

يوجد أيضاً أداة send_to_terminal جديدة تتيح للوكلاء إرسال أوامر إلى الطرفيات الخلفية مع تأكيد المستخدم، مما يحل مشكلة كون run_in_terminal مع مهلة ينقل الطرفيات إلى الخلفية ويجعلها للقراءة فقط.

استضافة الوكيل عن بُعد عبر SSH

يدعم VS Code الآن الاتصال بالأجهزة البعيدة عبر SSH، وتثبيت CLI تلقائياً وتشغيله في وضع مضيف الوكيل. هذا يعني أن جلسات الوكيل الذكي لديك يمكن أن تستهدف البيئات البعيدة مباشرة — مفيد لمطوري .NET الذين يبنون ويختبرون على خوادم Linux أو الأجهزة الافتراضية السحابية.

تتبع التعديلات في جلسات الوكيل

يتم الآن تتبع تعديلات الملفات التي تتم خلال جلسات الوكيل واستعادتها، مع عرض الفروقات والتراجع/الإعادة واستعادة الحالة. إذا أجرى وكيل تغييرات على كودك وحدث خطأ ما، يمكنك رؤية ما تغيّر بالضبط والتراجع عنه. راحة بال حقيقية عند السماح للوكلاء بتعديل قاعدة الكود.

وعي علامات تبويب المتصفح وتحسينات أخرى

بعض الإضافات الإضافية لجودة الحياة:

تتبع علامات تبويب المتصفح — يمكن للمحادثة الآن تتبع علامات التبويب المفتوحة خلال جلسة والربط بها، حتى يتمكن الوكلاء من الإشارة إلى صفحات الويب التي تشاهدها
لصق الملفات في الطرفية — الصق الملفات (بما في ذلك الصور) في الطرفية بـ Ctrl+V أو السحب والإفلات أو النقر الأيمن
تغطية الاختبار في الخريطة المصغرة — تظهر مؤشرات تغطية الاختبار الآن في الخريطة المصغرة لنظرة عامة بصرية سريعة
الضغط للتكبير على Mac — يدعم المتصفح المدمج إيماءات الضغط للتكبير
حصص Copilot في Sessions — يعرض شريط الحالة معلومات الاستخدام في عرض Sessions
الأيقونات المفضلة في Go to File — صفحات الويب المفتوحة تعرض أيقوناتها المفضلة في قائمة الاختيار السريع

خلاصة القول

VS Code 1.115 إصدار تدريجي، لكن تحسينات الوكيل — إشعارات الطرفيات الخلفية واستضافة وكيل SSH وتتبع التعديلات — تتجمع لتعطي تجربة أكثر سلاسة ملحوظة للتطوير المدعوم بالذكاء الاصطناعي. إذا كنت تستخدم وضع وكيل Copilot لمشاريع .NET، فهذه هي إصلاحات جودة الحياة التي تقلل الاحتكاك اليومي.

اطلع على ملاحظات الإصدار الكاملة لكل التفاصيل.

Aspire 13.2 يُقدّم CLI للوثائق — ويمكن لوكيل الذكاء الاصطناعي استخدامه أيضاً

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

هل تعرف تلك اللحظة التي تكون فيها غارقاً في AppHost في Aspire، تربط التكاملات ببعضها، ثم تحتاج إلى التحقق من المعاملات التي يتوقعها تكامل Redis بالضبط؟ تنتقل إلى المتصفح، وتبحث في aspire.dev، وتُحدّق في وثائق الواجهة البرمجية، ثم تعود إلى محررك. السياق ضائع. الإيقاع مقطوع.

وصل حلٌّ لهذا في Aspire 13.2. تتيح لك واجهة aspire docs CLI البحث عن الوثائق الرسمية لـ Aspire وتصفّحها وقراءتها مباشرةً من طرفيّتك. وبما أنها مدعومة بخدمات قابلة لإعادة الاستخدام، يمكن لوكلاء الذكاء الاصطناعي والمهارات استخدام الأوامر ذاتها للبحث في الوثائق بدلاً من ابتكار واجهات برمجية غير موجودة.

المشكلة التي يحلّها فعلاً

يُصيب David Pine كبد الحقيقة في منشوره الأصلي: كانت وكلاء الذكاء الاصطناعي سيئة للغاية في مساعدة المطورين على بناء تطبيقات Aspire. كانت توصي بـ dotnet run عوضاً عن aspire run، وتُحيل إلى learn.microsoft.com للوثائق التي تعيش على aspire.dev، وتقترح حزم NuGet قديمة، وابتكار واجهات برمجية غير موجودة — وهذه أكثر ما يزعجني.

لماذا؟ لأن Aspire كان مخصصاً لـ .NET فقط لفترة أطول مما كونه متعدد اللغات، وتعمل نماذج اللغة الكبيرة من بيانات تدريب سابقة للميزات الأحدث. حين تمنح وكيل الذكاء الاصطناعي القدرة على البحث الفعلي في الوثائق الحالية، يتوقف عن التخمين ويبدأ في أن يكون مفيداً.

ثلاثة أوامر، صفر تبويبات في المتصفح

الواجهة بسيطة بشكل منعش:

عرض قائمة بجميع الوثائق

aspire docs list

يُعيد كل صفحة وثائق متاحة على aspire.dev. تحتاج مخرجات قابلة للقراءة آلياً؟ أضف --format Json.

البحث عن موضوع

aspire docs search "redis"

يبحث في العناوين والمحتوى مع ترتيب النتائج حسب الصلة. نفس محرك البحث الذي يُشغّل أدوات التوثيق داخلياً. تحصل على نتائج مرتّبة مع العناوين، والمسارات المختصرة، ودرجات الصلة.

قراءة صفحة كاملة (أو قسم واحد فقط)

aspire docs get redis-integration

يبثّ الصفحة كاملةً بتنسيق Markdown إلى طرفيّتك. تحتاج قسماً واحداً فقط؟

aspire docs get redis-integration --section "Add Redis resource"

دقة جراحية. لا تمرير عبر 500 سطر. فقط الجزء الذي تحتاجه.

زاوية وكيل الذكاء الاصطناعي

هنا يصبح الأمر مثيراً للاهتمام للمطورين الذين يبنون بأدوات الذكاء الاصطناعي. تعمل أوامر aspire docs ذاتها أدواتٍ لوكلاء الذكاء الاصطناعي — عبر المهارات، وخوادم MCP، أو مجمّعات CLI البسيطة.

بدلاً من أن يخترع مساعد الذكاء الاصطناعي واجهات Aspire البرمجية بناءً على بيانات تدريب قديمة، يمكنه استدعاء aspire docs search "postgres"، والعثور على وثائق التكامل الرسمية، وقراءة الصفحة المناسبة، وتزويدك بالنهج الموثّق. توثيق حيّ ومحدَّث — لا ما حفظه النموذج قبل ستة أشهر.

البنية التحتية وراء هذا مقصودة. بنى فريق Aspire خدمات قابلة لإعادة الاستخدام (IDocsIndexService، IDocsSearchService، IDocsFetcher، IDocsCache) بدلاً من تكامل وحيد الغرض. هذا يعني أن محرك البحث ذاته يعمل للبشر في الطرفية، ولوكلاء الذكاء الاصطناعي في محررك، وللأتمتة في خط أنابيب CI.

سيناريوهات واقعية

بحث سريع في الطرفية: أنت في عمق ثلاثة ملفات وتحتاج معاملات إعداد Redis. أمران، تسعون ثانية، والعودة إلى العمل:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

التطوير بمساعدة الذكاء الاصطناعي: مهارة VS Code الخاصة بك تُجمّع أوامر CLI. تسأل “أضف قاعدة بيانات PostgreSQL إلى AppHost” فيبحث الوكيل في الوثائق الحقيقية قبل الإجابة. لا ابتكار واجهات وهمية.

التحقق في CI/CD: يتحقق خط أنابيبك من إعدادات AppHost مقابل الوثائق الرسمية برمجياً. مخرجات --format Json تنساب بسلاسة إلى jq وأدوات أخرى.

قواعد معرفة مخصصة: هل تبني أدوات ذكاء اصطناعي خاصة بك؟ أرسل مخرجات JSON المنظّمة مباشرةً إلى قاعدة معرفتك:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

لا استخلاص من الويب. لا مفاتيح API. نفس البيانات المنظّمة التي تستخدمها أدوات التوثيق داخلياً.

الوثائق دائماً حيّة

هذا هو الجانب الذي أقدّره أكثر من غيره. لا تُنزّل واجهة CLI لقطة ثابتة — بل تستعلم من aspire.dev مع تخزين مؤقت يستند إلى ETag. في اللحظة التي تتحدث فيها الوثائق، تعكس واجهتك وأي مهارة مبنية عليها ذلك التحديث. لا نسخ قديمة، لا لحظات “لكن الويكي قال…”.

خلاصة القول

aspire docs هي إحدى تلك الميزات الصغيرة التي تحلّ مشكلة حقيقية بنظافة. البشر يحصلون على وصول للوثائق من الطرفية مباشرةً. وكلاء الذكاء الاصطناعي يحصلون على طريقة للتوقف عن التخمين والبدء في الرجوع إلى الوثائق الفعلية. وكل ذلك مدعوم بمصدر حقيقة واحد.

إذا كنت تبني بـ .NET Aspire ولم تجرب واجهة CLI بعد، شغِّل aspire docs search "your-topic-here" وتحقق من شعورك. ثم فكّر في تغليف تلك الأوامر في أي مهارة ذكاء اصطناعي أو إعداد أتمتة تستخدمه — وكلاؤك سيشكرونك.

اطّلع على تحليل David Pine المعمّق حول كيفية تطور أدوات التوثيق، ومرجع CLI الرسمي للاطلاع على كل التفاصيل.

azd يتيح الآن تشغيل وكلاء الذكاء الاصطناعي وتصحيح أخطائها محلياً — إليك ما تغيّر في مارس 2026

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

سبعة إصدارات في شهر واحد. هذا ما دفعه فريق Azure Developer CLI (azd) في مارس 2026، والميزة الرئيسية هي التي كنت أنتظرها: حلقة تشغيل وتصحيح محلية لوكلاء الذكاء الاصطناعي.

نشر PC Chan الملخص الكامل، ومع أن المحتوى غزير، دعني أُصفّيه إلى ما يهم فعلاً مطوّري .NET الذين يبنون تطبيقات مدعومة بالذكاء الاصطناعي.

تشغيل وكلاء الذكاء الاصطناعي وتصحيح أخطائها دون نشر

هذه هي الكبرى. تُضيف إضافة azure.ai.agents الجديدة مجموعة من الأوامر التي توفّر لك تجربة حلقة داخلية حقيقية لوكلاء الذكاء الاصطناعي:

azd ai agent run — يُشغّل وكيلك محلياً
azd ai agent invoke — يُرسل رسائل إليه (محلياً أو بعد النشر)
azd ai agent show — يعرض حالة الحاوية وسلامتها
azd ai agent monitor — يبثّ سجلات الحاوية في الوقت الفعلي

قبل هذا، كان اختبار وكيل ذكاء اصطناعي يعني النشر إلى Microsoft Foundry في كل مرة تُجري فيها تغييراً. الآن يمكنك التكرار محلياً، واختبار سلوك وكيلك، والنشر فقط حين تكون مستعداً. إن كنت تبني وكلاء باستخدام Microsoft Agent Framework أو Semantic Kernel، فهذا يُغيّر سير عملك اليومي.

يعمل أمر invoke مقابل الوكلاء المحليين والمنشورين على حدٍّ سواء، مما يعني أنك تستطيع استخدام سير عمل الاختبار ذاته بصرف النظر عن مكان تشغيل الوكيل. هذا هو النوع من التفاصيل التي تُوفّر عليك الحاجة إلى صيانة مجموعتين من نصوص الاختبار.

GitHub Copilot يُنشئ السقالات لمشروع azd الخاص بك

بات azd init يُقدّم خياراً “إعداد مع GitHub Copilot (معاينة)”. بدلاً من الإجابة يدوياً على الأسئلة حول بنية مشروعك، يُهيّئ وكيل Copilot الإعداد نيابةً عنك. يتحقق من وجود دليل عمل غير نظيف قبل تعديل أي شيء، ويطلب موافقة على أدوات خادم MCP مسبقاً.

حين يفشل أمر ما، يُقدّم azd الآن استكشاف أخطاء بمساعدة الذكاء الاصطناعي: اختر فئة (شرح، توجيه، استكشاف أخطاء، أو تخطّي)، ودع الوكيل يقترح حلاً، ثم أعد المحاولة — كل ذلك دون مغادرة الطرفية. لإعدادات البنية التحتية المعقدة، هذا توفير حقيقي للوقت.

Container App Jobs وتحسينات النشر

بعض ميزات النشر الجديرة بالإشارة:

Container App Jobs: يُنشر azd الآن Microsoft.App/jobs من خلال إعداد host: containerapp الموجود. يُحدّد قالب Bicep الخاص بك ما إذا كان الهدف Container App أم Job — لا إعداد إضافي.
مهل نشر قابلة للتهيئة: خيار --timeout الجديد في azd deploy وحقل deployTimeout في azure.yaml. لا مزيد من التخمين حول الحد الافتراضي البالغ 1200 ثانية.
احتياطي البناء المحلي: حين يفشل البناء عن بُعد في ACR، ينتقل azd تلقائياً إلى البناء المحلي باستخدام Docker/Podman.
التحقق المحلي المسبق للنشر: يتم التحقق من معاملات Bicep محلياً قبل النشر، مما يكتشف المعاملات المفقودة دون رحلة ذهاب وإياب إلى Azure.

تحسينات تجربة المطوّر

بعض التحسينات الأصغر التي تتراكم لتُحدث فارقاً:

الكشف التلقائي عن pnpm/yarn لمشاريع JS/TS
دعم pyproject.toml لتعبئة Python
أدلة قوالب محلية — يقبل azd init --template الآن مسارات نظام الملفات للتكرار دون اتصال
رسائل خطأ أفضل في وضع --no-prompt — تُبلَّغ جميع القيم المفقودة دفعة واحدة مع أوامر الحل
متغيرات بيئة البناء مُحقونة في جميع العمليات الفرعية لبناء الأطر (.NET، Node.js، Java، Python)

هذه الأخيرة دقيقة لكنها مهمة: بناء .NET الخاص بك لديه الآن وصول إلى متغيرات بيئة azd، مما يعني أنك تستطيع إجراء حقن إعداد وقت البناء دون نصوص إضافية.

خلاصة القول

حلقة تصحيح أخطاء وكيل الذكاء الاصطناعي المحلية هي نجمة هذا الإصدار، لكن تراكم تحسينات النشر وصقل تجربة المطوّر يجعل azd يبدو أكثر نضجاً من أي وقت مضى. إن كنت تنشر تطبيقات .NET إلى Azure — خاصةً وكلاء الذكاء الاصطناعي — فهذا التحديث يستحق التثبيت.

تحقق من ملاحظات الإصدار الكاملة لكل التفاصيل، أو ابدأ بـ تثبيت azd.

Azure DevOps يُصلح أخيراً تجربة مستخدم محرر Markdown التي اشتكى منها الجميع

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

إذا كنت تستخدم Azure Boards، فمن المرجح أنك مررت بهذا الموقف: تقرأ وصف عنصر عمل، ربما تراجع معايير القبول، ثم تنقر نقراً مزدوجاً عن طريق الخطأ. فجأة — أنت في وضع التحرير. لم تكن تريد تحرير أي شيء. كنت فقط تقرأ.

أعلن Dan Hellem عن هذا الإصلاح، وهو من التغييرات التي تبدو صغيرة لكنها تزيل احتكاكاً حقيقياً من سير عملك اليومي.

ما الذي تغيّر

يفتح محرر Markdown لحقول نص عناصر العمل الآن في وضع المعاينة افتراضياً. يمكنك قراءة المحتوى والتفاعل معه — اتباع الروابط ومراجعة التنسيق — دون القلق من الدخول إلى وضع التحرير عن طريق الخطأ.

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

هذا هو التغيير. هذا كل شيء.

لماذا هذا أهم مما يبدو

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

بالنسبة للفرق التي تُجري تخطيط السبرينت، أو تنقية قائمة المهام المتراكمة، أو مراجعة الكود باستخدام Azure Boards، يتراكم هذا الاحتكاك الصغير. كل دخول غير مقصود إلى وضع التحرير يعني تحولاً في السياق. وكل لحظة “انتظر، هل غيّرت شيئاً؟” هي انتباه مُهدَر.

السلوك الافتراضي الجديد يحترم نمط التفاعل الأكثر شيوعاً: فأنت تقرأ عناصر العمل أكثر بكثير مما تحررها.

حالة الإطلاق

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

خلاصة القول

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

Bookmark Studio يُضيف نظام التنقل بالفتحات والمشاركة إلى إشارات Visual Studio المرجعية

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

الإشارات المرجعية في Visual Studio كانت دومًا… مقبولة. تضع إشارة، تنتقل إلى التالية، ثم تنسى أيها أيها. تؤدي وظيفتها، لكنها لم تكن يومًا الميزة التي تصفها بالقوية.

أصدر Mads Kristensen للتو Bookmark Studio، وهي إضافة تجريبية تسد بالضبط الفجوات التي ربما اصطدمت بها إذا كنت تستخدم الإشارات المرجعية بانتظام.

التنقل بالفتحات

الإضافة الأساسية: يمكن الآن تعيين الإشارات المرجعية إلى فتحات من 1 إلى 9 والقفز إليها مباشرةً بـ Alt+Shift+1 حتى Alt+Shift+9. تحصل الإشارات الجديدة تلقائيًا على الفتحة المتاحة التالية، لذا يعمل التنقل السريع في معظم الحالات دون أي إعداد.

قد يبدو هذا بسيطًا، لكنه يحوّل الإشارات المرجعية من “لديّ بعض الإشارات في مكان ما” إلى “الفتحة 3 هي وحدة التحكم API، الفتحة 5 هي طبقة الخدمة، الفتحة 7 هي الاختبار.” هذا النوع من التنظيم المكاني يجعل التنقل شبه فوري خلال جلسات العمل المركّز.

مدير الإشارات المرجعية

نافذة أداة جديدة تعرض جميع إشاراتك المرجعية في مكان واحد مع إمكانية التصفية بالاسم أو الملف أو الموقع أو اللون أو الفتحة. انقر نقرًا مزدوجًا أو تنقل بلوحة المفاتيح للقفز إلى أي إشارة.

إذا كان لديك يومًا ما خمس أو ست إشارات مرجعية أو أكثر وعجزت عن تحديد أيها أيها، فهذا وحده يستحق تثبيت الإضافة.

التنظيم بالتسميات والألوان والمجلدات

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

جميع البيانات الوصفية تُخزَّن لكل حل (solution)، لذا يظل تنظيم إشاراتك المرجعية محفوظًا عبر الجلسات.

التصدير والمشاركة

هذه هي الميزة التي لم أكن أعلم أنني أريدها. يتيح لك Bookmark Studio تصدير الإشارات المرجعية كنص عادي أو Markdown أو CSV. هذا يعني أنك تستطيع:

تضمين مسارات الإشارات في أوصاف طلبات السحب
مشاركة مسارات التحقيق مع زملاء الفريق
نقل مجموعات الإشارات بين المستودعات أو الفروع

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

إشارات مرجعية تتتبع حركة الكود

يتتبع Bookmark Studio الإشارات المرجعية بالنسبة للنص المرتبطة به، لذا لا تنزلق إلى سطور خاطئة بينما تُحرِّر الكود. إذا سبق لك أن وضعت إشارات خلال جلسة تصحيح أخطاء ثم وجدتها كلها تشير إلى سطور خاطئة بعد عملية إعادة هيكلة — هذا يحل تلك المشكلة.

خلاصة

لا يُعيد Bookmark Studio اختراع أي شيء. بل يأخذ ميزة كانت “كافية” لسنوات ويجعلها مفيدة حقًا للتطوير المركّز. التنقل بالفتحات ومدير الإشارات المرجعية وإمكانيات التصدير هي أبرز ما يقدمه.

احصل عليه من Visual Studio Marketplace وجرّبه.

تحديث 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 لتجربة كل ذلك.

من الحاسوب المحمول إلى الإنتاج: نشر وكلاء الذكاء الاصطناعي إلى Microsoft Foundry بأمرين

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

تعرف تلك الهوّة بين “يعمل على جهازي” و"منشور ويخدم حركة المرور"؟ بالنسبة لوكلاء الذكاء الاصطناعي، كانت تلك الهوّة واسعة بشكل مؤلم. تحتاج إلى توفير الموارد، ونشر النماذج، وربط الهوية، وإعداد المراقبة — وهذا قبل أن يتمكن أي شخص من استدعاء وكيلك فعليًا.

Azure Developer CLI جعل للتو هذا أمرًا من خطوتين.

سير عمل `azd ai agent` الجديد

دعني أستعرض كيف يبدو هذا فعليًا. لديك مشروع وكيل ذكاء اصطناعي — لنقل وكيل كونسيرج فندقي. يعمل محليًا. تريده يعمل على Microsoft Foundry.

azd ai agent init
azd up

هذا كل شيء. أمران اثنان. azd ai agent init يُنشئ كود البنية التحتية في مستودعك، وazd up يُوفِّر كل شيء على Azure وينشر وكيلك. تحصل على رابط مباشر لوكيلك في بوابة Foundry.

ما يحدث تحت الغطاء

يُولِّد أمر init قوالب Bicep حقيقية قابلة للفحص في مستودعك:

Foundry Resource (الحاوية ذات المستوى الأعلى)
Foundry Project (حيث يعيش وكيلك)
تكوين نشر النموذج (GPT-4o، إلخ.)
Managed identity مع تعيينات أدوار RBAC المناسبة
azure.yaml لخريطة الخدمة
agent.yaml مع بيانات الوكيل الوصفية ومتغيرات البيئة

إليك الجزء المهم: أنت تملك كل هذا. إنه Bicep موثَّق في مستودعك. يمكنك فحصه وتخصيصه وإيداعه جنبًا إلى جنب مع كود وكيلك. لا صناديق سحرية مبهمة.

حلقة التطوير الداخلية

ما يعجبني حقًا هو قصة التطوير المحلي. حين تكرر على منطق الوكيل، لا تريد إعادة النشر في كل مرة تغيّر فيها مطالبة:

azd ai agent run

يُشغّل هذا وكيلك محليًا. اقرنه مع azd ai agent invoke لإرسال مطالبات اختبارية، وستحصل على حلقة تغذية راجعة محكمة. عدّل الكود، أعد التشغيل، استدعِ، كرّر.

أمر invoke ذكي في التوجيه أيضًا — عندما يعمل وكيل محلي، يستهدفه تلقائيًا. وعندما لا يعمل، يضرب نقطة النهاية البعيدة.

المراقبة في الوقت الفعلي

هذه هي الميزة التي أقنعتني. بمجرد نشر وكيلك:

azd ai agent monitor --follow

كل طلب واستجابة يتدفقان عبر وكيلك يتدفقان إلى طرفيتك في الوقت الفعلي. لتصحيح مشكلات الإنتاج، هذا لا يُقدَّر بثمن. لا حاجة للبحث في log analytics، ولا انتظار لتجميع المقاييس — ترى ما يحدث الآن.

مجموعة الأوامر الكاملة

إليك المرجع السريع:

الأمر	ما يفعله
`azd ai agent init`	إنشاء مشروع وكيل Foundry مع كود البنية التحتية
`azd up`	توفير موارد Azure ونشر الوكيل
`azd ai agent invoke`	إرسال مطالبات إلى الوكيل البعيد أو المحلي
`azd ai agent run`	تشغيل الوكيل محليًا للتطوير
`azd ai agent monitor`	بث السجلات في الوقت الفعلي من الوكيل المنشور
`azd ai agent show`	التحقق من صحة الوكيل وحالته
`azd down`	تنظيف جميع موارد Azure

لماذا يهم هذا مطوري .NET

على الرغم من أن المثال في الإعلان مبني على Python، فإن قصة البنية التحتية مستقلة عن اللغة. وكيل .NET الخاص بك يحصل على نفس سقالة Bicep، ونفس إعداد managed identity، ونفس خط المراقبة. وإذا كنت تستخدم بالفعل azd لتطبيقات .NET Aspire أو عمليات نشر Azure، فهذا يندرج بسلاسة في سير عملك الحالي.

لقد كانت هوّة النشر لوكلاء الذكاء الاصطناعي إحدى أكبر نقاط الاحتكاك في المنظومة. الانتقال من نموذج أولي يعمل إلى نقطة نهاية إنتاجية مع هوية وشبكة ومراقبة مناسبة لا ينبغي أن يستغرق أسبوعًا من عمل DevOps. الآن يستغرق أمرين وبضع دقائق.

خلاصة

azd ai agent متاح الآن. إذا كنت تُؤجل نشر وكلاء الذكاء الاصطناعي الخاصة بك لأن إعداد البنية التحتية بدا يستلزم جهدًا كبيرًا، جرّب هذا. اطّلع على الشرح التفصيلي الكامل للخطوات الكاملة بما في ذلك تكامل تطبيق الدردشة الأمامي.

Developer-Tools | The .NET Blog

Azure MCP Server الآن .mcpb — ثبّته بدون أي Runtime

ما هو MCP Bundle؟

كيفية التثبيت

للبدء

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

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

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

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

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

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

Foundry Toolboxes: نقطة نهاية واحدة لجميع أدوات وكلاء الذكاء الاصطناعي

ما هو Toolbox؟

الأركان الأربعة (اثنان متاحان اليوم)

مثال عملي

لا قيد على Foundry Agents

لماذا يهم هذا الآن

خلاصة

Windows App Dev CLI v0.3: تشغيل F5 من الطرفية وأتمتة واجهة المستخدم للوكلاء الذكيين

winapp run: F5 من أي مكان

حزمة NuGet جديدة: dotnet run للتطبيقات المُحزَّمة

winapp ui: أتمتة واجهة المستخدم من سطر الأوامر

مستجدات أخرى

كيفية التثبيت

كتابة Hooks في azd بـ Python وTypeScript و.NET: وداعًا لسكريبتات Shell

ما هي الـ Hooks

كيف يعمل الاستدلال

تفاصيل مهمة حسب اللغة

Python

JavaScript وTypeScript

.NET

إعداد خاص بكل منفذ

لماذا يهم هذا لمطوري .NET

خلاصة

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

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

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

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

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

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

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

الخلاصة

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

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

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

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

الخلاصة

توقف عن حراسة طرفيتك: الوضع المنفصل في Aspire يغير سير العمل

الوضع المنفصل: أمر واحد، الطرفية تعود

إدارة ما يعمل

دمجه مع الوضع المعزول

لماذا هذا ضخم لوكلاء البرمجة

خلاصة

أدوات Azure MCP مدمجة الآن في Visual Studio 2022 — لا حاجة إلى امتداد

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

لماذا هذا أهم مما يبدو

ما الذي يمكنك فعله به

كيفية التفعيل

تحفظ واحد

الصورة الأكبر

azd update — أمر واحد يتحكّم في جميع مديري الحزم

كيف يعمل

التحفّظ الصغير

لماذا هذا مهم

.NET Aspire 13.2 يريد أن يكون أفضل صديق لوكيل الذكاء الاصطناعي

المشكلة حقيقية

Aspire بوصفه بنية تحتية للوكلاء

تشبيه حواجز مضمار البولينغ

البدء

خلاصة القول

VS Code 1.116 — تطبيق Agents يحصل على التنقل بلوحة المفاتيح وإكمالات سياق الملفات

تحسينات تطبيق Agents

حل روابط CSS @import

خلاصة القول

إعداد النوافذ العائمة في Visual Studio الذي لم تكن تعرفه (لكنك يجب أن تعرفه)

الإعداد

لماذا يُعدّ “None” الخيار الأمثل مع الشاشات المتعددة

توصيات سريعة

خلاصة القول

الوضع المعزول في Aspire يحلّ كابوس تعارض المنافذ في التطوير المتوازي

حل روابط CSS `@import`

الحل: `--isolated`

سير عمل `azd ai agent` الجديد