Azure | 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

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

GPT-5.5 هنا ويأتي إلى Azure Foundry — ما يحتاج مطورو .NET معرفته

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

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

أعلنت Microsoft للتو أن GPT-5.5 متاح عمومًا في Microsoft Foundry. إذا كنت تبني وكلاء على Azure، فهذا هو التحديث الذي كنت تنتظره.

تطور GPT-5

GPT-5: وحّد التفكير والسرعة في نظام واحد
GPT-5.4: تفكير متعدد الخطوات أقوى، قدرات وكالية مبكرة للمؤسسات
GPT-5.5: تفكير أعمق في السياق الطويل، تنفيذ وكالي أكثر موثوقية، كفاءة أفضل في الرموز

ما الذي تغيّر فعلًا

برمجة وكالية محسّنة: يحتفظ GPT-5.5 بالسياق عبر قواعد الشفرة الكبيرة، ويشخّص الإخفاقات المعمارية، ويتوقع متطلبات الاختبار. يستدل النموذج على ما يؤثر فيه أيضًا الإصلاح قبل التصرف.

كفاءة الرموز: مخرجات أعلى جودة مع رموز أقل ومحاولات أقل. انخفاض مباشر في التكلفة والكمون في الإنتاج.

التسعير

النموذج	المدخلات ($/M رمز)	المدخلات المخزنة	المخرجات ($/M رمز)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

لماذا يهم Foundry

يتيح لك Foundry Agent Service تعريف الوكلاء في YAML أو توصيلهم بـ Microsoft Agent Framework أو GitHub Copilot SDK أو LangGraph أو OpenAI Agents SDK — وتشغيلهم كوكلاء مستضافين معزولين مع نظام ملفات دائم وهوية Microsoft Entra مستقلة وتسعير بمقياس صفري.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "أنت مساعد مفيد.", name: "وكيلي");

اطلع على الإعلان الكامل لجميع التفاصيل.

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 يعني أنه يعمل مع الأدوات التي تُبنى بالفعل. جميع التفاصيل في الإعلان الرسمي.

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 في مشروعك القادم.

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

الضبط الدقيق RFT في Foundry أصبح أرخص وأذكى — إليك ما تغيّر

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

إذا كنت تبني تطبيقات .NET تعتمد على نماذج مضبوطة الضبط الدقيق، فتحديثات Foundry هذا الشهر تستحق الانتباه. الضبط الدقيق بالتعزيز (Reinforcement Fine-Tuning) أصبح أكثر سهولة في الوصول وأقل تكلفة بشكل ملموس.

التفاصيل الكاملة في الإعلان الرسمي، وهنا التفصيل العملي.

التدريب العالمي لـ o4-mini

o4-mini هو النموذج المفضّل لأحمال العمل المكثفة بالاستدلال والتطبيقات الوكيلية. الخبر الكبير: يمكنك الآن إطلاق وظائف الضبط الدقيق من أكثر من 13 منطقة Azure بأسعار تدريب أقل للرمز الواحد مقارنةً بالتدريب القياسي. نفس البنية التحتية، نفس الجودة، نطاق أوسع.

إذا كان فريقك موزعاً جغرافياً، فهذا يهمّك. لم تعد مقيّداً بعدد محدود من المناطق للتدريب.

إليك استدعاء REST API لبدء وظيفة تدريب عالمية:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

العلامة trainingType: globalstandard هي الفارق الرئيسي.

مُقيِّمات نماذج جديدة: عائلة GPT-4.1

تُحدِّد المُقيِّمات إشارة المكافأة التي يُحسِّن النموذج استناداً إليها. حتى الآن، كانت المُقيِّمات المبنية على النماذج محدودة بمجموعة أصغر من النماذج. الآن تحصل على ثلاثة خيارات جديدة: GPT-4.1 وGPT-4.1-mini وGPT-4.1-nano.

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

استراتيجية التدرّج عملية للغاية:

GPT-4.1-nano للتكرارات الأولية. تكلفة منخفضة، حلقات تغذية راجعة سريعة.
GPT-4.1-mini بمجرد استقرار قواعد تقييمك وحاجتك إلى دقة أعلى.
GPT-4.1 للتقييم في الإنتاج أو القواعد المعقدة حيث تهمّ كل قرار تسجيل.

يمكنك حتى دمج أنواع المُقيِّمات في وظيفة RFT واحدة. استخدم مطابقة السلاسل لبُعد “الإجابة الصحيحة” ومُقيِّم نموذج لتقييم جودة الاستدلال. هذه المرونة هي ما يجعل هذا مفيداً فعلاً لأحمال العمل الحقيقية.

المشكلة الخفية في تنسيق بيانات RFT

هذه النقطة تُوقع الناس في مشكلات. تنسيق بيانات RFT مختلف عن SFT. يجب أن تكون الرسالة الأخيرة في كل صف بدور User أو Developer — وليس Assistant. الإجابة المتوقعة تذهب في مفتاح من المستوى الأعلى مثل reference_answer يرجع إليه المُقيِّم مباشرةً.

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

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

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

ابدأ بحجم صغير. من عشرة إلى مئة عيّنة. مُقيِّم بسيط. تحقق من صحة الحلقة. ثم قم بالتوسع.

تجاربك في الذكاء الاصطناعي على Azure تُهدر المال — إليك كيفية إصلاح ذلك

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

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

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

لماذا تختلف أعباء عمل الذكاء الاصطناعي

إليك الحقيقة. أعباء عمل .NET التقليدية يمكن التنبؤ بها نسبيًا. أنت تعرف مستوى App Service الخاص بك، وتعرف وحدات SQL DTUs، ويمكنك تقدير الإنفاق الشهري بدقة معقولة. أما أعباء عمل الذكاء الاصطناعي؟ فالأمر مختلف تمامًا.

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

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

الإدارة مقابل التحسين — اعرف الفرق

هناك تمييز من المقال أعتقد أن المطورين يُغفلونه: هناك فرق بين إدارة التكاليف وتحسينها.

الإدارة هي التتبع وإعداد التقارير. تضبط الميزانيات في Azure Cost Management، تتلقى التنبيهات، وترى لوحات المعلومات. هذا الحد الأدنى المطلوب.

التحسين هو حيث تتخذ قرارات فعلية. هل تحتاج فعلًا إلى مستوى S3، أم أن S1 يتعامل مع الحمل؟ هل تلك الحوسبة الدائمة التشغيل تجلس خاملة في عطلات نهاية الأسبوع؟ هل يمكنك استخدام المثيلات الفورية (spot instances) لمهام التدريب؟

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

ما الذي يُحدث فرقًا فعليًا

استنادًا إلى المقال وتجربتي الخاصة، إليك ما يُغير الأمور:

اعرف ما تُنفقه وأين. ضع وسومًا (tags) على مواردك. بجدية. إذا لم تستطع تحديد أي مشروع أو تجربة يستنزف ميزانيتك، فلن تتمكن من تحسين أي شيء. Azure Cost Management مع وسوم صحيحة هو أفضل أصدقائك.

ضع حواجز الحماية قبل أن تُجرّب. استخدم Azure Policy لتقييد وحدات SKU المكلفة في بيئات التطوير والاختبار. ضع حدودًا للإنفاق على عمليات نشر Azure OpenAI الخاصة بك. لا تنتظر حتى تصل الفاتورة لتدرك أن شخصًا ما ترك مجموعة GPU تعمل طوال عطلة نهاية الأسبوع.

أعد تحجيم الموارد باستمرار. تلك الآلة الافتراضية التي اخترتها خلال النمذجة الأولية؟ على الأرجح أنها خاطئة للإنتاج. Azure Advisor يُقدم توصيات — انظر إليها فعلًا. راجع شهريًا لا سنويًا.

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

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

الخلاصة

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

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

أدوات 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. وبصراحة، كلما قل التبديل بين علامات التبويب، كان ذلك أفضل.

Aspire 13.2 يضيف MongoDB EF Core وAzure Data Lake — تكاملان يستحقان التجربة

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

صدر Aspire 13.2 للتو مع تكاملَين جديدَين لقواعد البيانات يستحقان اهتمامك: MongoDB Entity Framework Core وAzure Data Lake Storage. إذا كنت تريد استخدام EF Core مع MongoDB في تطبيق Aspire، أو تحتاج إلى ربط أعباء عمل data lake مع سرد خدمات صحيح، فهذا الإصدار يقدّم الاثنين.

MongoDB يلتقي بـ EF Core في Aspire

هذا هو ما أنا أكثر حماساً له. دعمت Aspire MongoDB لفترة، لكنه كان دائماً المشغّل الخام — لا EF Core، ولا DbContext، ولا استعلامات LINQ مقابل مستنداتك. الآن تحصل على تجربة EF Core الكاملة مع MongoDB، بالإضافة إلى فحوصات الصحة التلقائية وسرد الخدمات من Aspire.

الإعداد يتبع نمط Aspire المعتاد. في AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

ثم في مشروعك المُستهلِك، أضف تكامل EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

وسجّل DbContext الخاص بك:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

من هنا، الأمر EF Core قياسي. عرّف كياناتك، استخدم DbContext كما تفعل مع أي مزوّد آخر. يعالج التكامل تجميع الاتصالات وتتبعات OpenTelemetry وفحوصات الصحة خلف الكواليس.

لمطوّري .NET الذين استخدموا MongoDB مع المشغّل الخام وربطوا سلاسل الاتصال يدوياً، هذا تحسين ملموس في جودة الحياة. تحصل على تجريد EF Core الكامل دون فقدان سرد خدمات Aspire.

Azure Data Lake Storage ينضم إلى الحفلة

الإضافة الكبيرة الثانية هي تكامل Azure Data Lake Storage (ADLS). إذا كنت تبني مسارات بيانات أو عمليات ETL أو منصات تحليلات، يمكنك الآن ربط موارد Data Lake بنفس الطريقة التي تربط بها أي تبعية Aspire أخرى.

في AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

في المشروع المُستهلِك:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

لا إدارة يدوية لسلاسل الاتصال، ولا بحث عن بيانات الاعتماد. تُوفّر Aspire الموارد وتحقنها. لمن يبنون تطبيقات .NET سحابية أصلية تلمس كلاً من البيانات التشغيلية وأعباء عمل التحليلات، يجعل هذا data lake مواطناً من الدرجة الأولى في نموذج Aspire.

الإصلاحات الصغيرة التي تهمّ

بعيداً عن الميزات الرئيسية، هناك بعض تحسينات جودة الحياة التي تستحق الذكر:

إصلاح سلسلة اتصال MongoDB — الشرطة المائلة للأمام قبل اسم قاعدة البيانات تُعالَج الآن بشكل صحيح. إذا كنت تعمل حول هذه المشكلة، يمكنك إزالة الحل البديل
تصدير SQL Server — يُصدّر Aspire.Hosting.SqlServer الآن خيارات إعداد خادم إضافية للتحكم الدقيق
تحديثات المحاكيات — محاكي ServiceBus 2.0.0، ومحاكي App Configuration 1.0.2، والمحاكي التجريبي لـ CosmosDB يتضمن الآن فحص الجاهزية
Azure Managed Redis — يُعيَّن الآن افتراضياً إلى rediss:// (Redis Secure)، لذا الاتصالات مشفّرة بشكل افتراضي

ذلك الأخير دقيق لكن مهمّ — Redis المشفّر افتراضياً يعني شيئاً أقل للإعداد في الإنتاج.

خلاصة القول

Aspire 13.2 إصدار تدريجي، لكن تكاملَي MongoDB EF Core وData Lake يسدّان فجوات حقيقية. إذا كنت تنتظر دعماً صحيحاً لـ EF Core مع MongoDB في Aspire، أو احتجت Data Lake أن يكون تبعية من الدرجة الأولى، قم بالترقية إلى 13.2 وجرّبهما. يُسقّل الأمر aspire add كل ما تحتاجه.

اقرأ ملاحظات الإصدار الكاملة لمزيد من التفاصيل، واطّلع على معرض التكاملات للقائمة الكاملة.

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 هنا لمزيد من السياق.

Azure Smart Tier متاح للعموم — تحسين تكاليف تخزين Blob تلقائياً بدون قواعد دورة الحياة

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

إذا قضيت وقتاً في ضبط سياسات دورة حياة Azure Blob Storage ثم شاهدتها تنهار عندما تتغير أنماط الوصول، فهذا المقال يخصك. أعلنت Microsoft للتو عن التوافر العام لـ smart tier لـ Azure Blob وData Lake Storage — قدرة تدرّج مُدارة بالكامل تنقل الكائنات تلقائياً بين الطبقات الساخنة والباردة والمتجمدة بناءً على الاستخدام الفعلي.

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

المفهوم واضح: يقيّم smart tier باستمرار وقت آخر وصول لكل كائن في حساب التخزين الخاص بك. البيانات التي يُوصل إليها بشكل متكرر تبقى في الطبقة الساخنة، وتنتقل البيانات غير النشطة إلى الطبقة الباردة بعد 30 يوماً، ثم إلى الطبقة المتجمدة بعد 60 يوماً أخرى. عند الوصول إلى البيانات مجدداً، تُرقَّى فوراً إلى الطبقة الساخنة. تبدأ الدورة من جديد.

لا قواعد دورة حياة للضبط. لا تنبؤات بأنماط الوصول. لا ضبط يدوي.

خلال فترة المعاينة، أفادت Microsoft بأن أكثر من 50% من السعة المُدارة بـ smart tier انتقلت تلقائياً إلى طبقات أبرد بناءً على أنماط الوصول الفعلية. هذا تخفيض ذو معنى في التكاليف لحسابات التخزين الكبيرة.

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

إذا كنت تبني تطبيقات تولّد سجلات أو بيانات قياس أو بيانات تحليلية أو أي نوع من ممتلكات البيانات المتنامية — وبصراحة، من لا يفعل — فتكاليف التخزين تتراكم بسرعة. النهج التقليدي كان كتابة سياسات إدارة دورة الحياة واختبارها وإعادة ضبطها عندما تتغير أنماط الوصول في تطبيقك. يزيل smart tier سير العمل بأكمله.

بعض السيناريوهات العملية التي يساعد فيها هذا:

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

كيفية الإعداد

تفعيل smart tier إعداد لمرة واحدة:

الحسابات الجديدة: اختر smart tier كطبقة الوصول الافتراضية أثناء إنشاء حساب التخزين (يُشترط التكرار المنطقي)
الحسابات القائمة: بدّل طبقة الوصول للـ blob من افتراضيتك الحالية إلى smart tier

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

المقايضة التي يجب معرفتها

قواعد التدرّج في smart tier ثابتة (30 يوماً إلى بارد، 90 يوماً إلى متجمد). إذا احتجت إلى عتبات مخصصة — مثلاً الانتقال إلى البارد بعد 7 أيام لحمل عمل محدد — فقواعد دورة الحياة هي الحل المناسب. ولا تخلط بينهما: تجنب استخدام قواعد دورة الحياة على الكائنات المُدارة بـ smart tier، إذ يمكن أن تتعارض.

خلاصة القول

هذا ليس ثورياً، لكنه يحل صداعاً تشغيلياً حقيقياً. إذا كنت تدير حسابات blob storage متنامية وتعبت من صيانة سياسات دورة الحياة، فعّل smart tier ودع Azure يتولى الأمر. إنه متاح اليوم في جميع مناطق السحابة العامة المنطقية تقريباً.

أين تستضيف وكلاء الذكاء الاصطناعي على Azure؟ دليل عملي للقرار

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

إن كنت تبني وكلاء ذكاء اصطناعي بـ .NET في الوقت الراهن، ربما لاحظت شيئاً: ثمة الكثير من طرق استضافتها على Azure. Container Apps، وAKS، وFunctions، وApp Service، وFoundry Agents، وFoundry Hosted Agents — وكلها تبدو معقولة حتى تحتاج فعلاً إلى اختيار واحدة. نشرت Microsoft للتو دليلاً شاملاً لاستضافة وكلاء Azure AI يوضّح هذا الأمر، وأريد تحليله من منظور مطوّر .NET عملي.

الخيارات الستة في لمحة

إليك كيف أُلخّص المشهد:

الخيار	الأنسب لـ	أنت تُدير
Container Apps	التحكم الكامل في الحاويات دون تعقيد K8s	إمكانية المراقبة، الحالة، دورة الحياة
AKS	الامتثال للمؤسسات، متعدد المجموعات، شبكات مخصصة	كل شيء (هذا هو الهدف)
Azure Functions	المهام الوكيلة قصيرة الأمد المدفوعة بالأحداث	شبه لا شيء — خادم حقيقي بلا خوادم
App Service	وكلاء HTTP البسيطة، حركة المرور المتوقعة	النشر، إعداد التوسّع
Foundry Agents	وكلاء بدون كود عبر البوابة/SDK	شبه لا شيء
Foundry Hosted Agents	وكلاء بأُطر مخصصة مع بنية تحتية مُدارة	كود وكيلك فقط

الخيارات الأربعة الأولى هي حوسبة للأغراض العامة — يمكنك تشغيل وكلاء عليها، لكنها لم تُصمَّم لذلك. الخياران الأخيران وكيل-أصيل: يفهمان المحادثات ومكالمات الأدوات ودورات حياة الوكلاء كمفاهيم أولى.

Foundry Hosted Agents — النقطة الأمثل لمطوّري وكلاء .NET

ها هو ما لفت انتباهي. تقع Foundry Hosted Agents في المنتصف تماماً: تحصل على مرونة تشغيل كودك الخاص (Semantic Kernel، Agent Framework، LangGraph — ما تشاء) لكن المنصة تتولى إدارة البنية التحتية وإمكانية المراقبة وإدارة المحادثات.

القطعة الرئيسية هي Hosting Adapter — طبقة تجريد رفيعة تربط إطار وكيلك بمنصة Foundry. بالنسبة لـ Microsoft Agent Framework يبدو هكذا:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

هذه هي قصة استضافتك بالكامل. يتولى المحوّل ترجمة البروتوكول، والبثّ عبر server-sent events، وسجل المحادثات، وتتبع OpenTelemetry — كل ذلك تلقائياً. لا middleware مخصص، لا سباكة يدوية.

النشر بسيط بشكل حقيقي

نشرت وكلاء إلى Container Apps من قبل وتعمل، لكنك تنتهي بكتابة الكثير من كود الربط لإدارة الحالة وإمكانية المراقبة. مع Hosted Agents وـazd، يكون النشر:

# تثبيت إضافة وكلاء AI
azd ext install azure.ai.agents

# التهيئة من قالب
azd ai agent init

# بناء، رفع، نشر — انتهى
azd up

ذلك الأمر الواحد azd up يبني حاويتك، ويرفعها إلى ACR، ويُوفّر مشروع Foundry، ويُنشئ نقاط نهاية النماذج، ويُشغّل وكيلك. خمس خطوات في أمر واحد.

إدارة المحادثات المدمجة

هذا الجانب هو الذي يُوفّر أكثر الوقت في الإنتاج. بدلاً من بناء مخزن حالة محادثة خاص بك، تتولى Hosted Agents ذلك بشكل أصيل:

# إنشاء محادثة دائمة
conversation = openai_client.conversations.create()

# الدور الأول
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# الدور الثاني — السياق محفوظ
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

لا Redis. لا مخزن جلسات Cosmos DB. لا middleware مخصص لتسلسل الرسائل. المنصة تتولى الأمر ببساطة.

إطاري للقرار

بعد مراجعة الخيارات الستة جميعها، إليك نموذجي الذهني السريع:

هل تحتاج إلى بنية تحتية صفرية؟ ← Foundry Agents (بوابة/SDK، بلا حاويات)
هل لديك كود وكيل مخصص لكنك تريد استضافة مُدارة؟ ← Foundry Hosted Agents
هل تحتاج مهاماً وكيلة مدفوعة بالأحداث قصيرة الأمد؟ ← Azure Functions
هل تحتاج أقصى تحكم في الحاويات دون K8s؟ ← Container Apps
هل تحتاج امتثالاً صارماً ومتعدد المجموعات؟ ← AKS
هل لديك وكيل HTTP بسيط بحركة مرور متوقعة؟ ← App Service

لمعظم مطوّري .NET الذين يبنون بـ Semantic Kernel أو Microsoft Agent Framework، من المرجح أن تكون Hosted Agents نقطة البداية الصحيحة. تحصل على التوسّع إلى الصفر، وOpenTelemetry المدمج، وإدارة المحادثات، ومرونة الإطار — دون إدارة Kubernetes أو تمديد سلسلة إمكانية مراقبة خاصة بك.

خلاصة القول

مشهد استضافة الوكلاء على Azure ينضج بسرعة. إن كنت تبدأ مشروع وكيل ذكاء اصطناعي جديداً اليوم، أُوصي بجدية بالنظر في Foundry Hosted Agents قبل الوصول إلى Container Apps أو AKS من عادة. البنية التحتية المُدارة توفّر وقتاً حقيقياً، ونمط Hosting Adapter يتيح لك الحفاظ على اختيار إطارك.

اطّلع على الدليل الكامل من Microsoft ومستودع Foundry Samples للحصول على أمثلة عملية.

مهارات الوكيل في .NET أصبحت أكثر مرونة من أي وقت مضى

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

إذا كنت تبني وكلاء باستخدام Microsoft Agent Framework، فأنت تعرف القاعدة: تعرّف المهارات، واربطها بمزوّد، واترك الوكيل يقرر أيّها يستدعي. الجديد هو كيفية تأليف تلك المهارات — وقفزة المرونة ملموسة.

يُقدّم التحديث الأحدث ثلاثة أنماط تأليف مميزة لمهارات الوكيل: مستندة إلى الملفات، ومستندة إلى الفئات، ومحدّدة بكود مضمّن. الثلاثة تتوصّل بـ AgentSkillsProviderBuilder واحد، أي يمكنك المزج والتوفيق دون أي منطق توجيه أو كود ربط خاص. دعني أرشدك عبر كل واحدة ومتى تلجأ إليها.

المهارات المستندة إلى الملفات: نقطة البداية

المهارات المستندة إلى الملفات هي بالضبط ما يوحي به اسمها — دليل على القرص بملف SKILL.md، وسكريبتات اختيارية، ومستندات مرجعية. فكّر في الأمر كأبسط طريقة لمنح وكيلك قدرات جديدة:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

تُعلن البيانات الأولية في SKILL.md اسم المهارة ووصفها، ويخبر قسم التعليمات الوكيلَ كيف يستخدم السكريبتات والمراجع:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

ثم تربطها مع SubprocessScriptRunner.RunAsync لتنفيذ السكريبت:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

يكتشف الوكيل المهارة تلقائياً ويستدعي سكريبت التزويد عند الحاجة إلى التحقق من حالة الحساب. نظيف وبسيط.

المهارات المستندة إلى الفئات: الشحن عبر NuGet

هنا تصبح الأمور مثيرة للاهتمام للفرق. المهارات المستندة إلى الفئات تشتق من AgentClassSkill<T> وتستخدم سمات مثل [AgentSkillResource] و[AgentSkillScript] لكي يكتشف الإطار كل شيء عبر الانعكاس:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

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

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

تظهر كلتا المهارتين في النص التوجيهي للنظام للوكيل. يقرر الوكيل أيّهما يستخدم بناءً على المحادثة — لا حاجة لكود توجيه.

المهارات المضمّنة: الجسر السريع

تعرف تلك اللحظة حين يبني فريق آخر بالضبط المهارة التي تحتاجها، لكنها لن تُشحن لدورة تطوير كاملة؟ AgentInlineSkill هو جسرك:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

أضفها إلى المُنشئ تماماً كالأخريات:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

حين تُشحن حزمة NuGet أخيراً، تستبدل المهارة المضمّنة بالمستندة إلى الفئات. الوكيل لا يلاحظ الفرق.

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

موافقة السكريبت: الإنسان في الحلقة

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

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

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

لماذا يهمّ هذا التوليف

القوة الحقيقية ليست في أي نمط تأليف منفرد — بل في التركيب. يمكنك:

البدء صغيراً بمهارة مستندة إلى ملفات، والتكرار على التعليمات، وشحنها دون كتابة C#
شحن مهارات قابلة لإعادة الاستخدام كحزم NuGet تضيفها فرق أخرى بسطر واحد
سد الفجوات بمهارات مضمّنة حين تحتاج شيئاً الآن
تصفية أدلة المهارات المشتركة بمسندات حتى يحمّل وكيلك فقط ما ينبغي
إضافة رقابة بشرية للسكريبتات التي تلمس أنظمة الإنتاج

كل هذه تتركّب عبر AgentSkillsProviderBuilder. لا توجيه خاص، ولا منطق شرطي، ولا فحوصات نوع المهارة.

خلاصة القول

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

اطّلع على الإعلان الأصلي للشرح الكامل، ووثائق Agent Skills على Microsoft Learn، وأمثلة .NET على GitHub للتطبيق العملي.

إطلاق Azure MCP Server 2.0 — أتمتة السحابة الوكيلية المستضافة ذاتياً أصبحت حقيقة

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

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

لم يعد الأمر كذلك. لقد وصل Azure MCP Server للإصدار 2.0 المستقر، والميزة الرئيسية هي بالضبط ما طالبت به فرق المؤسسات: دعم خادم MCP البعيد المستضاف ذاتياً.

ما هو Azure MCP Server؟

مراجعة سريعة. ينفّذ Azure MCP Server مواصفة بروتوكول سياق النموذج ويعرض قدرات Azure كأدوات منظمة وقابلة للاكتشاف يمكن لوكلاء الذكاء الاصطناعي استدعاؤها. فكر فيه كجسر موحد بين وكيلك وAzure — التزويد والنشر والمراقبة والتشخيص، كل ذلك من خلال واجهة واحدة متسقة.

الأرقام تتحدث عن نفسها: 276 أداة MCP عبر 57 خدمة Azure. هذا تغطية جدية.

الأمر الكبير: نشر عن بُعد مستضاف ذاتياً

إليك المسألة. تشغيل MCP محلياً على جهازك مناسب للتطوير والتجارب. لكن في سيناريو فريق حقيقي، تحتاج إلى:

وصول مشترك للمطورين والأنظمة الوكيلية الداخلية
تكوين مركزي (سياق المستأجر، افتراضيات الاشتراك، بيانات القياس)
حدود شبكة المؤسسة وسياساتها
التكامل في مسارات CI/CD

يعالج Azure MCP Server 2.0 كل ذلك. يمكنك نشره كخدمة داخلية مُدارة مركزياً مع نقل بيانات يعتمد على HTTP، ومصادقة مناسبة، وحوكمة متسقة.

للمصادقة، لديك خياران متينان:

Managed Identity — عند التشغيل جنباً إلى جنب مع Microsoft Foundry
تدفق On-Behalf-Of (OBO) — تفويض OpenID Connect يستدعي واجهات برمجية Azure باستخدام سياق المستخدم الذي سجّل الدخول

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

تحصين الأمان

هذا ليس مجرد إصدار ميزات — إنه إصدار أمني أيضاً. يضيف إصدار 2.0:

التحقق المعزز من نقاط النهاية
الحماية من أنماط الحقن في الأدوات الموجهة بالاستعلامات
ضوابط عزل أكثر إحكاماً لبيئات التطوير

إذا كنت ستعرض MCP كخدمة مشتركة، فهذه الضمانات مهمة. بشكل كبير.

أين يمكنك استخدامه؟

قصة توافق العملاء واسعة. يعمل Azure MCP Server 2.0 مع:

بيئات التطوير المتكاملة: VS Code، Visual Studio، IntelliJ، Eclipse، Cursor
وكلاء سطر الأوامر: GitHub Copilot CLI، Claude Code
مستقل: خادم محلي للإعدادات البسيطة
بعيد مستضاف ذاتياً: النجم الجديد في إصدار 2.0

بالإضافة إلى ذلك، هناك دعم للسحابة السيادية لـ Azure US Government وAzure التي تشغّلها 21Vianet، وهو أمر حيوي للنشرات الخاضعة للتنظيم.

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

إذا كنت تبني تطبيقات وكيلية باستخدام .NET — سواء كان ذلك Semantic Kernel أو Microsoft Agent Framework أو تنسيقك الخاص — يمنحك Azure MCP Server 2.0 طريقة جاهزة للإنتاج للسماح لوكلائك بالتفاعل مع بنية Azure التحتية. بدون أغلفة REST مخصصة. بدون أنماط تكامل خاصة بالخدمة. فقط MCP.

بالاقتران مع واجهة برمجية Fluent لتطبيقات MCP التي أُطلقت قبل أيام، تنضج منظومة .NET MCP بسرعة.

البدء

اختر مسارك:

مستودع GitHub — الكود المصدري والوثائق وكل شيء
صورة Docker — نشر في حاوية
امتداد VS Code — تكامل مع بيئة التطوير المتكاملة
دليل الاستضافة الذاتية — الميزة الرئيسية في إصدار 2.0

خلاصة القول

Azure MCP Server 2.0 هو بالضبط نوع الترقية التحتية التي لا تبدو لامعة في العرض التوضيحي لكنها تغير كل شيء عملياً. خادم MCP البعيد المستضاف ذاتياً مع مصادقة مناسبة وتحصين أمني ودعم سحابة سيادية يعني أن MCP جاهز للفرق الحقيقية التي تبني سير عمل وكيلية حقيقية على Azure. إذا كنت تنتظر إشارة “جاهز للمؤسسات” — هذه هي.

Microsoft Foundry مارس 2026 — GPT-5.4 وإطلاق خدمة Agent وتحديث SDK الذي يغيّر كل شيء

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

منشورات “ما الجديد في Microsoft Foundry” الشهرية عادةً مزيج من التحسينات التدريجية والميزة الرئيسية العَرَضية. إصدار مارس 2026؟ إنه في الأساس كله ميزات رئيسية. خدمة Foundry Agent تصبح متاحة للعموم، وGPT-5.4 يُشحن للإنتاج، وSDK يحصل على إصدار مستقر رئيسي، وFireworks AI تجلب استدلال النماذج المفتوحة إلى Azure. دعني أُفصّل ما يهمّ مطوّري .NET.

Foundry Agent Service جاهز للإنتاج

هذه هي الكبرى. بيئة تشغيل الوكلاء من الجيل التالي متاحة للعموم — مبنية على OpenAI Responses API، ومتوافقة مع وكلاء OpenAI على مستوى البروتوكول، ومفتوحة للنماذج من مزوّدين متعددين. إذا كنت تبني بواجهة Responses API اليوم، فإن الهجرة إلى Foundry تضيف أمان المؤسسات، والشبكات الخاصة، وEntra RBAC، والتتبع الكامل، والتقييم — فوق منطق وكيلك الحالي.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

الإضافات الرئيسية: شبكات خاصة شاملة من طرف إلى طرف، وتوسيع مصادقة MCP (بما في ذلك OAuth passthrough)، وVoice Live في مرحلة المعاينة للوكلاء الكلامية، ووكلاء مستضافون في 6 مناطق جديدة.

GPT-5.4 — الموثوقية فوق الذكاء الخام

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

النموذج	السعر (لكل مليون رمز)	الأفضل لـ
GPT-5.4 (≤272K)	$2.50 / $15 للمخرجات	وكلاء الإنتاج، البرمجة، سير عمل المستندات
GPT-5.4 Pro	$30 / $180 للمخرجات	التحليل المعمّق، الاستدلال العلمي
GPT-5.4 Mini	فعّال من حيث التكلفة	التصنيف، الاستخراج، استدعاءات الأدوات الخفيفة

الحركة الذكية هي استراتيجية توجيه: GPT-5.4 Mini يتعامل مع العمل عالي الحجم ومنخفض الزمن بينما يتولى GPT-5.4 الطلبات المكثفة بالاستدلال.

SDK مستقر أخيراً

حزمة azure-ai-projects SDK أصدرت إصدارات مستقرة عبر جميع اللغات — Python 2.0.0 وJS/TS 2.0.0 وJava 2.0.0 و.NET 2.0.0 (الأول من أبريل). تبعية azure-ai-agents اختفت — كل شيء يقع تحت AIProjectClient. ثبّت بـ pip install azure-ai-projects والحزمة تحزم openai وazure-identity كتبعيات مباشرة.

لمطوّري .NET، هذا يعني حزمة NuGet واحدة لكامل سطح Foundry. لا مزيد من إدارة حزم وكلاء منفصلة.

Fireworks AI تجلب النماذج المفتوحة إلى Azure

ربما الإضافة الأكثر أهمية معمارياً: Fireworks AI تعالج أكثر من 13 تريليون رمز يومياً بـ ~180,000 طلب/ثانية، متاحة الآن عبر Foundry. DeepSeek V3.2 وgpt-oss-120b وKimi K2.5 وMiniMax M2.5 عند الإطلاق.

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

أبرز الإضافات الأخرى

Phi-4 Reasoning Vision 15B — استدلال متعدد الوسائط للرسوم البيانية والمخططات وتخطيطات المستندات
Evaluations GA — مُقيِّمات جاهزة للاستخدام مع مراقبة إنتاج مستمرة مُوصَلة إلى Azure Monitor
Priority Processing (معاينة) — مسار حوسبة مخصص لأحمال العمل الحساسة لزمن الاستجابة
Voice Live — بيئة تشغيل كلامية تتصل مباشرةً بوكلاء Foundry
Tracing GA — فحص كامل لتتبعات الوكلاء مع الفرز والتصفية
إهمال PromptFlow — الهجرة إلى Microsoft Framework Workflows بحلول يناير 2027

خلاصة

مارس 2026 نقطة تحوّل لـ Foundry. إتاحة خدمة Agent للعموم، وحزم SDK مستقرة عبر جميع اللغات، وGPT-5.4 لوكلاء إنتاج موثوقين، واستدلال النماذج المفتوحة عبر Fireworks AI — المنصة جاهزة لأحمال العمل الجادة.

اقرأ الملخص الكامل وابنِ وكيلك الأول للبدء.

بناء واجهات مستخدم متعددة الوكلاء في الوقت الفعلي دون أن تبدو صندوقاً أسود

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

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

نشر فريق Microsoft Agent Framework للتو شرحاً رائعاً حول دمج مهام سير عمل MAF مع AG-UI، وهو بروتوكول مفتوح لبث أحداث تنفيذ الوكيل إلى واجهة المستخدم الأمامية عبر Server-Sent Events. وبصراحة؟ هذا هو الجسر الذي كنا نفتقده.

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

إذا كنت تبني تطبيقات مدعومة بالذكاء الاصطناعي، فمن المحتمل أنك اصطدمت بهذا الجدار. تنسيق الواجهة الخلفية يعمل بشكل رائع — يُسلّم الوكلاء العمل لبعضهم، وتنطلق الأدوات، وتُتخذ القرارات. لكن الواجهة الأمامية لا تعرف شيئاً مما يجري خلف الكواليس. يعالج AG-UI ذلك من خلال تعريف بروتوكول قياسي لبث أحداث الوكيل (مثل RUN_STARTED وSTEP_STARTED وTOOL_CALL_* وTEXT_MESSAGE_*) مباشرةً إلى طبقة واجهة المستخدم عبر SSE.

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

طوبولوجيا التسليم هي النجم الحقيقي

ما لفت انتباهي هو كيف يتيح لك HandoffBuilder إعلان رسم بياني توجيه موجّه بين الوكلاء:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

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

الإنسان في الحلقة بطريقة فعلية

يعرض هذا التوضيح نمطَي مقاطعة تحتاجهما أي تطبيق وكيل في العالم الحقيقي:

مقاطعات موافقة الأدوات — عندما يستدعي وكيل أداةً محدّدة بـ approval_mode="always_require"، يتوقف سير العمل ويُرسل حدثاً. تعرض الواجهة الأمامية نافذة موافقة باسم الأداة وحججها. لا حلقات إعادة محاولة تستهلك الرموز — مجرد تدفق توقف-موافقة-استئناف نظيف.

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

يتدفق كلا النمطين كأحداث AG-UI قياسية، لذا لا تحتاج واجهتك الأمامية إلى منطق مخصص لكل وكيل — فهي تُصيّر أيّ حدث يأتي عبر اتصال SSE.

الربط بينهما بسيط بشكل مفاجئ

التكامل بين MAF وAG-UI يتلخص في استدعاء دالة واحدة:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

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

رأيي

بالنسبة لنا كمطوّري .NET، السؤال الفوري هو: “هل يمكنني فعل هذا في C#؟” إطار عمل Agent متاح لكلٍّ من .NET وPython، وبروتوكول AG-UI مستقل عن اللغة (فهو مجرد SSE). لذا بينما يستخدم هذا العرض التوضيحي بالتحديد Python وFastAPI، فإن النمط ينتقل مباشرةً. يمكنك ربط ASP.NET Core minimal API بنقاط نهاية SSE باتباع نفس مخطط أحداث AG-UI.

الخلاصة الأكبر هي أن واجهات المستخدم متعددة الوكلاء أصبحت مصدر قلق من الدرجة الأولى، لا فكرة لاحقة. إذا كنت تبني أي شيء تتفاعل فيه الوكلاء مع البشر — دعم العملاء، أو مسارات الموافقة، أو معالجة المستندات — فإن مجموعة تنسيق MAF وشفافية AG-UI هي النمط الواجب اتباعه.

خلاصة القول

AG-UI + Microsoft Agent Framework يمنحانك أفضل ما في العالمين: تنسيق متين متعدد الوكلاء في الواجهة الخلفية، ورؤية في الوقت الفعلي في الواجهة الأمامية. لا مزيد من تفاعلات الوكيل كصندوق أسود.

راجع الشرح الكامل ومستودع بروتوكول AG-UI للتعمق أكثر.

تقييم التحديث من 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 لتجربتها على قاعدة الكود الخاصة بك.

خادم SQL MCP — الطريقة الصحيحة لمنح وكلاء الذكاء الاصطناعي وصولاً إلى قواعد البيانات

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

لنكن صريحين: معظم خوادم MCP الخاصة بقواعد البيانات المتاحة اليوم مثيرة للقلق. تأخذ استعلاماً بلغة طبيعية، وتولّد SQL بشكل ديناميكي، وتشغّله مباشرةً على بياناتك الإنتاجية. ماذا يمكن أن يحدث بسبب ذلك؟ (كل شيء. كل شيء يمكن أن يحدث.)

أعلن فريق Azure SQL للتو عن خادم SQL MCP، وهو يتبع نهجاً مختلفاً جذرياً. مبنيٌّ كميزة في Data API builder (DAB) 2.0، يمنح وكلاءَ الذكاء الاصطناعي وصولاً منظّماً وحتمياً إلى عمليات قاعدة البيانات — دون NL2SQL، ودون كشف مخططك، وبتحكم كامل في الصلاحيات في كل خطوة.

لماذا لا NL2SQL؟

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

بدلاً من ذلك، يستخدم خادم SQL MCP نهج NL2DAB. يتعامل الوكيل مع طبقة تجريد الكيانات في Data API builder ومنشئ الاستعلامات المدمج فيه لإنتاج T-SQL دقيق ومنسّق بشكل حتمي. النتيجة ذاتها للمستخدم، لكن دون مخاطر الـ JOINs المهلوسة أو الكشف غير المقصود للبيانات.

سبعة أدوات، لا سبعمائة

يكشف خادم SQL MCP عن سبعة أدوات DML بالضبط، بغض النظر عن حجم قاعدة البيانات:

describe_entities — اكتشاف الكيانات المتاحة والعمليات
create_record — إدراج صفوف
read_records — الاستعلام عن الجداول والعروض
update_record — تعديل الصفوف
delete_record — حذف الصفوف
execute_entity — تشغيل الإجراءات المخزّنة
aggregate_records — استعلامات التجميع

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

يمكن تمكين أو تعطيل كل أداة بشكل مستقل:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

البدء بثلاثة أوامر

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

هذا خادم SQL MCP يعمل ويكشف جدول Customers لديك. تعني طبقة تجريد الكيانات أنه بإمكانك تغيير الأسماء والأعمدة، وتقييد الحقول لكل دور، والتحكم بدقة فيما يراه الوكلاء — دون الكشف عن تفاصيل المخطط الداخلي.

قصة الأمان متينة

هنا تؤتي نضج Data API builder ثماره:

التحكم في الصلاحيات في كل طبقة — كل كيان يحدد الأدوار التي يمكنها القراءة والإنشاء والتحديث والحذف، والحقول المرئية لكل دور
تكامل Azure Key Vault — إدارة آمنة لسلاسل الاتصال والأسرار
Microsoft Entra + OAuth مخصص — مصادقة جاهزة للإنتاج
سياسة أمان المحتوى — يتفاعل الوكلاء عبر عقد محكوم، لا SQL خام

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

قواعد بيانات وبروتوكولات متعددة

يدعم خادم SQL MCP كلاً من: Microsoft SQL وPostgreSQL وAzure Cosmos DB وMySQL. ولأنه ميزة DAB، فإنك تحصل على نقاط نهاية REST وGraphQL وMCP في آنٍ واحد من نفس الإعداد. نفس تعريفات الكيانات، ونفس قواعد التحكم في الصلاحيات، ونفس الأمان — عبر البروتوكولات الثلاثة.

يمكن للإعداد التلقائي في DAB 2.0 فحص قاعدة بياناتك وبناء الإعداد بشكل ديناميكي، إذا كنت مرتاحاً لتجريد أقل في مرحلة النمذجة السريعة.

رأيي

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

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

خلاصة القول

خادم SQL MCP مجاني ومفتوح المصدر ويعمل في أي مكان. إنه النهج التوجيهي من Microsoft لمنح وكلاء الذكاء الاصطناعي وصولاً آمناً إلى قواعد البيانات. اطلع على المقال الكامل والوثائق للبدء.

ربط خوادم MCP على Azure Functions بوكلاء Foundry — إليك الطريقة

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

ثمة شيء أحبه في منظومة MCP البيئية: تبني خادمك مرة واحدة ويعمل في كل مكان. VS Code وVisual Studio وCursor وChatGPT — كل عميل MCP يستطيع اكتشاف أدواتك واستخدامها. الآن، تضيف Microsoft مستهلكاً جديداً إلى تلك القائمة: وكلاء Foundry.

نشرت Lily Ma من فريق Azure SDK دليلاً عملياً حول ربط خوادم MCP المنشورة على Azure Functions بوكلاء Microsoft Foundry. إذا كان لديك خادم MCP بالفعل، فهذا إضافة قيمة صافية — لا إعادة بناء مطلوبة.

لماذا هذا التركيب منطقي

يمنحك Azure Functions بنية تحتية قابلة للتوسع، ومصادقة مدمجة، وفوترة بدون خادم لاستضافة خوادم MCP. يمنحك Microsoft Foundry وكلاء ذكاء اصطناعي يستطيعون التفكير والتخطيط واتخاذ الإجراءات. ربط الاثنين يعني أن أدواتك المخصصة — الاستعلام عن قاعدة بيانات، أو استدعاء واجهة برمجية تجارية، أو تشغيل منطق التحقق — تصبح قدرات يستطيع وكلاء الذكاء الاصطناعي المؤسسي اكتشافها واستخدامها بصورة مستقلة.

النقطة الجوهرية: خادم MCP الخاص بك يبقى كما هو. أنت تضيف Foundry فحسب كمستهلك إضافي. الأدوات ذاتها التي تعمل في إعداد VS Code الخاص بك تشغّل الآن وكيل ذكاء اصطناعي يتفاعل معه فريقك أو عملاؤك.

خيارات المصادقة

هنا تكمن القيمة الحقيقية للمقال. أربع طرق للمصادقة تبعاً لسيناريوك:

الطريقة	حالة الاستخدام
مبنية على مفتاح (افتراضية)	التطوير أو الخوادم التي لا تستخدم Entra auth
Microsoft Entra	الإنتاج مع الهويات المُدارة
OAuth identity passthrough	الإنتاج حيث يُصادق كل مستخدم بشكل فردي
بدون مصادقة	التطوير/الاختبار أو البيانات العامة فقط

للإنتاج، Entra Microsoft مع هوية الوكيل هي المسار الموصى به. OAuth identity passthrough مخصص للحالات التي يهمّ فيها سياق المستخدم — يطلب الوكيل من المستخدمين تسجيل الدخول، ويحمل كل طلب رمز المستخدم الخاص به.

الإعداد

التدفق على مستوى عالٍ:

انشر خادم MCP على Azure Functions — نماذج متاحة لـ .NET وPython وTypeScript وJava
فعّل مصادقة MCP المدمجة في تطبيق الدالة الخاص بك
احصل على URL نقطة النهاية — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
أضف خادم MCP كأداة في Foundry — انتقل إلى وكيلك في البوابة، أضف أداة MCP جديدة، وأدخل نقطة النهاية وبيانات الاعتماد

ثم اختبره في ملعب Agent Builder بإرسال موجّه يُشغّل إحدى أدواتك.

رأيي

قصة إمكانية التركيب هنا تزداد قوةً بشكل حقيقي. أنشئ خادم MCP مرة واحدة بـ .NET (أو Python أو TypeScript أو Java)، وانشره على Azure Functions، وكل عميل متوافق مع MCP يستطيع استخدامه — أدوات البرمجة، وتطبيقات الدردشة، والآن وكلاء الذكاء الاصطناعي المؤسسي. هذا نمط “اكتب مرة واحدة، استخدم في كل مكان” يعمل فعلاً.

لمطوّري .NET تحديداً، امتداد Azure Functions MCP يجعل هذا أمراً مباشراً. تعرّف على أدواتك كـ Azure Functions، وانشر، وستحصل على خادم MCP جاهز للإنتاج مع كل الأمان والتوسعية التي يوفرها Azure Functions.

خلاصة

إذا كانت لديك أدوات MCP تعمل على Azure Functions، فإن ربطها بوكلاء Foundry هو مكسب سريع — أدواتك المخصصة تصبح قدرات ذكاء اصطناعي مؤسسية مع مصادقة مناسبة ودون تغييرات في كود الخادم.

اقرأ الدليل الكامل للحصول على تعليمات خطوة بخطوة لكل طريقة مصادقة، وراجع الوثائق التفصيلية لإعدادات الإنتاج.

هندسة المنصات الوكيلية تصبح حقيقة — 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 هو نظرة مبكرة لكن ملموسة على هندسة المنصات الوكيلية في التطبيق. استنسخ المستودع، وجرّب العرض التوضيحي، وابدأ في التفكير في كيفية احتياج واجهات برمجية منصتك وسياساتها للظهور حتى يستطيع الوكيل استخدامها بأمان.

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

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.

KubeCon أوروبا 2026: ما يجب أن يهتمّ به مطوّرو .NET فعلاً

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

تعرف ذلك الشعور حين يصدر منشور إعلانات ضخم وأنت تتصفحه تفكّر “رائع، لكن ما الذي يغيّره هذا فعلاً بالنسبة لي”؟ هذا بالضبط شعوري في كل موسم KubeCon.

نشرت Microsoft للتوّ ملخصها الكامل لـ KubeCon Europe 2026 — كتبه Brendan Burns بنفسه — وفي الحقيقة؟ ثمة مضمون حقيقي هنا. لا مجرد مربعات اختيار للميزات، بل تحسينات تشغيلية من النوع الذي يغيّر طريقة تشغيل الأشياء في الإنتاج.

دعني أُفصّل ما يهمّ فعلاً لنا كمطوّري .NET.

mTLS دون ضريبة service mesh

إليك الحقيقة بشأن شبكات الخدمات: الجميع يريد ضمانات الأمان، ولا أحد يريد الأعباء التشغيلية. AKS يسدّ تلك الفجوة أخيراً.

Azure Kubernetes Application Network يمنحك TLS المتبادل، والتفويض الواعي بالتطبيق، وبيانات تتبع حركة المرور — دون نشر شبكة كاملة ثقيلة بالحاويات الجانبية. مدمجاً مع Cilium mTLS في Advanced Container Networking Services، تحصل على اتصال مشفّر بين الـ pods باستخدام شهادات X.509 وSPIRE لإدارة الهوية.

ما يعنيه هذا عملياً: واجهات ASP.NET Core APIs تتحدث إلى العمال الخلفيين، وخدمات gRPC تستدعي بعضها — كل ذلك مشفّر ومُتحقق من الهوية على مستوى الشبكة، بدون أي تغييرات في كود التطبيق. هذا ضخم.

للفرق التي تنقل من ingress-nginx، ثمة أيضاً Application Routing with Meshless Istio مع دعم كامل لـ Kubernetes Gateway API. لا حاويات جانبية. قائم على المعايير. وشحنوا أداة ingress2gateway للهجرة التدريجية.

إمكانية مراقبة GPU ليست مُلحقةً بعد الواقعة

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

AKS يعرض الآن مقاييس GPU بشكل أصلي إلى Prometheus وGrafana المُدارَين. نفس المنظومة، نفس لوحات المعلومات، نفس خط أنابيب التنبيه. لا أدوات تصدير مخصصة، لا وكلاء من جهات خارجية.

على صعيد الشبكة، أضافوا رؤية لكل تدفق لحركة HTTP وgRPC وKafka مع تجربة Azure Monitor بنقرة واحدة. عناوين IP، والمنافذ، وأحمال العمل، واتجاه التدفق، وقرارات السياسة — كل ذلك في لوحات معلومات مدمجة.

وإليك ما أوقفني مندهشاً: شبكات الحاويات الوكيلية تضيف واجهة ويب تتيح لك طرح أسئلة باللغة الطبيعية حول حالة شبكة مجموعتك. “لماذا لا يصل pod X إلى الخدمة Y؟” ← تشخيصات للقراءة فقط من بيانات تتبع حية. هذا مفيد فعلاً في الساعة الثانية صباحاً.

شبكة متعددة العناقيد لا تتطلب شهادة دكتوراه

كان Kubernetes متعدد العناقيد تاريخياً تجربة “أحضر معك الصمغ الشبكي الخاص بك”. يشحن Azure Kubernetes Fleet Manager الآن شبكة متعددة العناقيد عبر شبكة Cilium cluster mesh المُدارة:

اتصال موحّد عبر عناقيد AKS
سجل خدمات عالمي للاكتشاف متعدد العناقيد
تهيئة مُدارة مركزياً، لا تكرار لكل عنقود

إذا كنت تشغّل خدمات .NET المصغّرة عبر مناطق متعددة للمرونة أو الامتثال، فهذا يستبدل الكثير من التجهيزات المخصصة الهشّة. الخدمة A في West Europe تستطيع اكتشاف واستدعاء الخدمة B في East US عبر الشبكة، مع سياسات توجيه وأمان متسقة.

ترقيات لا تتطلب شجاعة

لنكن صريحين — ترقيات Kubernetes في الإنتاج مُجهِدة. “رقّي وتأمّل الخير” كانت الاستراتيجية الفعلية لفرق كثيرة جداً، وهي السبب الرئيسي في تخلّف العناقيد عن الإصدارات.

قدرتان جديدتان تُغيّران هذا:

ترقيات agent pool بالأزرق والأخضر تُنشئ pool عقد موازياً بالتهيئة الجديدة. تحقق من السلوك، وانقل حركة المرور تدريجياً، واحتفظ بمسار تراجع واضح. لا مزيد من التعديلات في المكان على عقد الإنتاج.

التراجع عن agent pool يتيح لك العودة بـ pool العقد إلى إصدار Kubernetes وصورة العقدة السابقة بعد ترقية فاشلة — دون إعادة بناء العنقود.

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

أحمال العمل بالذكاء الاصطناعي تصبح مواطنين من الدرجة الأولى في Kubernetes

العمل مفتوح المصدر في المنبع لا يقل أهمية. Dynamic Resource Allocation (DRA) وصل للإتاحة العامة في Kubernetes 1.36، مما يجعل جدولة GPU ميزة من الدرجة الأولى بدلاً من حلّ مؤقت.

عدة مشاريع تستحق المتابعة:

المشروع	ما يفعله
AI Runway	واجهة Kubernetes مشتركة للاستدلال — انشر النماذج دون معرفة K8s، مع اكتشاف HuggingFace وتقديرات التكلفة
HolmesGPT	تشخيص وكيلي لبيئات السحابة الأصيلة — أصبح الآن مشروع CNCF Sandbox
Dalec	إنشاء صور حاويات تصريحي مع توليد SBOM — ثغرات أمنية أقل في مرحلة البناء

الاتجاه واضح: يجب أن تعمل واجهة .NET API الخاصة بك، وطبقة تنسيق Semantic Kernel، وأحمال عمل الاستدلال جميعها على نموذج منصة متسق واحد. نحن في طريقنا إلى ذلك.

من أين أبدأ هذا الأسبوع

إذا كنت تُقيِّم هذه التغييرات لفريقك، فإليك قائمة الأولويات الصادقة:

إمكانية المراقبة أولاً — فعّل مقاييس GPU وسجلات تدفق الشبكة في عنقود غير الإنتاج. انظر ما الذي كنت تفتقده.
جرّب ترقيات الأزرق والأخضر — اختبر سير عمل التراجع قبل ترقية عنقود الإنتاج التالية. ابنِ الثقة في العملية.
جرّب الشبكة الواعية بالهوية — اختر مسار خدمة داخلي واحد وفعّل mTLS مع Cilium. قِس الأعباء الإضافية (تنبيه: إنها ضئيلة).
قيّم Fleet Manager — إذا كنت تشغّل أكثر من عنقودين، فإن الشبكة متعددة العناقيد تؤتي ثمارها في تقليل التجهيزات المخصصة.

تجارب صغيرة، تغذية راجعة سريعة. هذه دائماً هي الحركة الصحيحة.

خلاصة

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

إذا كنت على AKS بالفعل، فهذه لحظة رائعة لتحسين مستوى عملياتك. وإذا كنت تخطط لنقل أحمال عمل .NET إلى Kubernetes — المنصة أصبحت للتوّ أكثر جاهزيةً للإنتاج بشكل ملموس.

خادم SQL MCP، وCopilot في SSMS، ومحور قواعد البيانات بالوكلاء: ما الذي يهمّ فعلاً من SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

أطلقت Microsoft للتو SQLCon 2026 بالتزامن مع FabCon في أتلانتا، وهناك الكثير لاستيعابه. يغطي الإعلان الأصلي كل شيء من خطط التوفير إلى ميزات الامتثال للمؤسسات. سأتجاوز شرائح تسعير المؤسسات وأركّز على الأجزاء التي تهمّ إذا كنت مطوراً يبني أشياء باستخدام Azure SQL والذكاء الاصطناعي.

خادم SQL MCP في معاينة عامة

هذا هو العنوان الرئيسي بالنسبة لي. تمتلك Azure SQL Database Hyperscale الآن خادم SQL MCP في معاينة عامة يتيح لك توصيل بيانات SQL بأمان بالوكلاء والـ Copilots باستخدام Model Context Protocol.

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

لمن يبنون وكلاء ذكاء اصطناعي باستخدام Semantic Kernel أو Microsoft Agent Framework، يفتح هذا مساراً تكاملياً نظيفاً. يحتاج وكيلك التحقق من المخزون؟ البحث عن سجل عميل؟ التحقق من صحة طلب؟ يمنحه MCP طريقة منظمة للقيام بذلك دون أن تكتب كود جلب بيانات مخصصاً لكل سيناريو.

GitHub Copilot في SSMS 22 أصبح متاحاً عموماً

إذا كنت تقضي وقتاً في SQL Server Management Studio — ولنكن صادقين، معظمنا لا يزال يفعل ذلك — فإن GitHub Copilot متاح الآن عموماً في SSMS 22. نفس تجربة Copilot التي تستخدمها بالفعل في VS Code وVisual Studio، لكن لـ T-SQL.

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

فهارس المتجهات حصلت على تحسين جوهري

تمتلك Azure SQL Database الآن فهارس متجهات أسرع وأكثر قدرةً مع دعم كامل للإدراج والتحديث والحذف. هذا يعني أن بيانات المتجهات تبقى حديثة في الوقت الفعلي — لا حاجة لإعادة الفهرسة الدفعية.

إليك ما هو جديد:

التكميم لأحجام فهارس أصغر دون خسارة دقة كبيرة
التصفية التكرارية للحصول على نتائج أدق
تكامل أوثق مع محسّن الاستعلامات لأداء متوقع

إذا كنت تقوم بالتوليد المعزز بالاسترجاع (RAG) باستخدام Azure SQL كمخزن متجهات، فهذه التحسينات مفيدة مباشرةً. يمكنك الاحتفاظ بمتجهاتك إلى جانب بياناتك العلائقية في نفس قاعدة البيانات، مما يبسّط بنيتك بشكل ملحوظ مقارنةً بتشغيل قاعدة بيانات متجهات منفصلة.

تتوفر تحسينات المتجهات نفسها أيضاً في SQL database في Fabric، نظراً لأن كليهما يعمل على نفس محرك SQL في الأساس.

محور قواعد البيانات في Fabric: الإدارة الوكيلية

هذا يتطلع إلى المستقبل أكثر، لكنه مثير للاهتمام. أعلنت Microsoft عن محور قواعد البيانات في Microsoft Fabric (وصول مبكر)، الذي يمنحك لوحة تحكم موحّدة عبر Azure SQL وCosmos DB وPostgreSQL وMySQL وSQL Server عبر Arc.

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

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

ما يعنيه هذا لمطوّري .NET

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

إذا كنت تبني تطبيقات .NET تعتمد على Azure SQL، إليك ما سأفعله فعلاً:

جرّب خادم SQL MCP إذا كنت تبني وكلاء ذكاء اصطناعي. إنه أنظف طريقة لمنح وكلائك وصولاً إلى قاعدة البيانات دون تسليك مخصص.
فعّل Copilot في SSMS إذا لم تكن قد فعلت ذلك بعد — مكسب إنتاجية مجاني للعمل اليومي بـ SQL.
ابحث في فهارس المتجهات إذا كنت تقوم بـ RAG وتشغّل حالياً مخزن متجهات منفصلاً. التوحيد إلى Azure SQL يعني خدمة أقل للإدارة.

خلاصة القول

الإعلان الكامل يحتوي على المزيد — خطط التوفير، ومساعدو الترحيل، وميزات الامتثال — لكن قصة المطوّر تكمن في خادم MCP، وتحسينات المتجهات، وطبقة الإدارة الوكيلية. هذه هي القطع التي تغيّر طريقة بنائك، لا مجرد ميزانيتك.

اطّلع على الإعلان الكامل من Shireesh Thota للصورة الكاملة، وسجّل للوصول المبكر إلى محور قواعد البيانات إذا أردت تجربة تجربة الإدارة الجديدة.

الاستجابات في الخلفية في Microsoft Agent Framework: لا مزيد من القلق من انتهاء المهلة

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

إذا بنيت أي شيء باستخدام نماذج التفكير مثل o3 أو GPT-5.2، فأنت تعرف المعاناة. يبدأ وكيلك في التفكير في مهمة معقدة، يجلس العميل ينتظر، وفي مكان ما بين “كل شيء على ما يرام” و"هل تعطل؟" تنتهي مهلة اتصالك. كل ذلك العمل؟ ضاع.

أصدر Microsoft Agent Framework للتو الاستجابات في الخلفية — وبصراحة، هذه من الميزات التي كان يجب أن تكون موجودة منذ اليوم الأول.

مشكلة الاستدعاءات الحاجبة

في نمط الطلب-الاستجابة التقليدي، يحجب عميلك حتى ينتهي الوكيل. هذا يعمل بشكل جيد للمهام السريعة. لكن عندما تطلب من نموذج تفكير إجراء بحث معمق أو تحليل متعدد الخطوات أو إنشاء تقرير من 20 صفحة؟ أنت تتطلع إلى دقائق من الوقت الفعلي. خلال تلك الفترة:

يمكن أن تنتهي مهل اتصالات HTTP
تقلبات الشبكة تقتل العملية بأكملها
يحدق مستخدمك في مؤشر تحميل متسائلاً إذا كان أي شيء يحدث

الاستجابات في الخلفية تقلب هذا رأساً على عقب.

كيفية عمل رموز الاستمرارية

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

سير العمل مباشر:

أرسل طلبك مع AllowBackgroundResponses = true
إذا كان الوكيل يدعم المعالجة في الخلفية، تحصل على رمز استمرارية
استعلم حسب جدولك حتى يعود الرمز null — هذا يعني أن النتيجة جاهزة

إليك الإصدار بـ .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

إذا أكمل الوكيل فوراً (المهام البسيطة، النماذج التي لا تحتاج معالجة في الخلفية)، لا يُعاد رمز استمرارية. كودك يعمل فقط — بدون معالجة خاصة.

البث مع الاستئناف: السحر الحقيقي

الاستعلام مناسب لسيناريوهات “أطلق وانسَ”، لكن ماذا عن عندما تريد تقدماً في الوقت الفعلي؟ الاستجابات في الخلفية تدعم أيضاً البث مع استئناف مدمج.

كل تحديث مبث يحمل رمز استمراريته الخاص. إذا انقطع اتصالك في منتصف البث، تستأنف من حيث توقفت تماماً:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

يستمر الوكيل في المعالجة من جانب الخادم بغض النظر عما يحدث مع عميلك. هذا تحمّل للأعطال مدمج دون كتابة منطق إعادة المحاولة أو قواطع الدائرة.

متى تستخدم هذا فعلاً

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

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

بالنسبة لنا كمطوري .NET الذين يبنون تطبيقات مؤسسية، النقطة الأخيرة مثيرة للاهتمام بشكل خاص. فكر في تطبيق Blazor حيث يطلب مستخدم تقريراً معقداً — تطلق مهمة الوكيل، تعرض له مؤشر تقدم، وتتركه يستمر في العمل. بدون مشاكل WebSocket، بدون بنية تحتية مخصصة للطوابير، فقط رمز واستعلام دوري.

خلاصة القول

الاستجابات في الخلفية متاحة الآن في .NET وPython من خلال Microsoft Agent Framework. إذا كنت تبني وكلاء يفعلون أي شيء أكثر تعقيداً من الأسئلة والأجوبة البسيطة، فهذا يستحق إضافته إلى أدواتك. نمط رمز الاستمرارية يبقي الأمور بسيطة مع حل مشكلة إنتاجية حقيقية جداً.

اطلع على الوثائق الكاملة للرجوع الكامل إلى واجهة برمجية والمزيد من الأمثلة.

خادم Azure DevOps MCP يصل إلى Microsoft Foundry: ما الذي يعنيه هذا لوكلاء الذكاء الاصطناعي لديك

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

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

الآن أصبح خادم Azure DevOps MCP متاحاً في Microsoft Foundry، وهذه من التكاملات التي تجعلك تفكر في الإمكانات العملية.

ما الذي يحدث فعلاً

أصدرت Microsoft بالفعل خادم Azure DevOps MCP كـمعاينة عامة — ذلك هو الخادم نفسه. الجديد هو التكامل مع Foundry. يمكنك الآن إضافة خادم Azure DevOps MCP إلى وكلاء Foundry مباشرةً من كتالوج الأدوات.

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

كيفية الإعداد

الإعداد مباشر بشكل مفاجئ:

في وكيل Foundry الخاص بك، انتقل إلى Add Tools > Catalog
ابحث عن “Azure DevOps”
اختر Azure DevOps MCP Server (preview) وانقر Create
أدخل اسم مؤسستك وتواصل

هذا كل شيء. الوكيل لديك الآن وصول إلى أدوات Azure DevOps.

التحكم في ما يمكن للوكيل الوصول إليه

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

هذا مهم في سيناريوهات المؤسسات حيث لا تريد أن يُشغّل الوكيل مسار نشر بالخطأ لأن أحدهم طلب منه “المساعدة في الإصدار”.

لماذا هذا مثير للاهتمام لفرق .NET

فكر في ما يتيحه هذا عملياً:

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

بالنسبة لفرق .NET التي تستخدم بالفعل Azure DevOps لمسارات CI/CD وإدارة المشاريع، فإن امتلاك وكيل ذكاء اصطناعي يمكنه التفاعل مع تلك الأنظمة مباشرةً خطوة مهمة نحو أتمتة مفيدة حقيقية (وليس مجرد روبوت محادثة كخدمة).

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

هذا جزء من اتجاه أوسع: تصبح خوادم MCP الطريقة المعيارية التي تتفاعل بها وكلاء الذكاء الاصطناعي مع العالم الخارجي. نراها لـ GitHub وAzure DevOps وقواعد البيانات وواجهات برمجية SaaS — وتصبح Foundry المحور الذي تجتمع فيه هذه الاتصالات.

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

خلاصة القول

خادم Azure DevOps MCP في Foundry في مرحلة المعاينة، لذا توقع أن يتطور. لكن سير العمل الأساسي متين: اتصل، وضبط وصول الأدوات، واترك وكلاءك يعملون مع بيانات DevOps الخاصة بك. إذا كنت بالفعل في منظومة Foundry، فهذا على بُعد بضع نقرات. جربه وانظر إلى سير العمل التي يمكنك بناؤها.

اطلع على الإعلان الكامل للحصول على خطوات الإعداد التفصيلية والمزيد من المعلومات.

خدمة Foundry Agent متاحة للعموم: ما يهمّ فعلاً لبنّائي وكلاء .NET

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

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

خدمة Foundry Agent أصبحت الآن متاحة للعموم، وهذا الإصدار مركّز تماماً على سدّ تلك الفجوة في “كل ما يأتي بعده”.

مبنية على Responses API

هذا هو العنوان الرئيسي: خدمة Foundry Agent من الجيل التالي مبنية على OpenAI Responses API. إذا كنت تبني بالفعل باستخدام هذا البروتوكول، فإن الهجرة إلى Foundry تستلزم تغييرات طفيفة في الكود. ما ستكسبه: أمان المؤسسات، والشبكات الخاصة، وEntra RBAC، والتتبع الكامل، والتقييم — فوق منطق وكيلك الحالي.

البنية مفتوحة عن قصد. لست مقيّداً بمزوّد نماذج واحد أو إطار تنسيق واحد. استخدم DeepSeek للتخطيط، وOpenAI للتوليد، وLangGraph للتنسيق — بيئة التشغيل تتولى طبقة الاتساق.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

الشبكات الخاصة: العقبة المؤسسية أُزيلت

هذه هي الميزة التي تفتح الطريق أمام تبنّي المؤسسات. تدعم Foundry الآن الشبكات الخاصة الكاملة من طرف إلى طرف مع BYO VNet:

لا خروج عام — لا تلمس حركة مرور الوكيل شبكة الإنترنت العامة أبداً
حقن الحاوية/الشبكة الفرعية في شبكتك للاتصال المحلي
اتصال الأدوات مشمول — خوادم MCP، وAzure AI Search، ووكلاء بيانات Fabric تعمل جميعها عبر مسارات خاصة

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

مصادقة MCP بالطريقة الصحيحة

تدعم اتصالات خادم MCP الآن الطيف الكامل من أنماط المصادقة:

طريقة المصادقة	متى تستخدمها
مبنية على المفتاح	وصول مشترك بسيط للأدوات الداخلية على مستوى المؤسسة
Entra Agent Identity	من خدمة إلى خدمة؛ الوكيل يُصادق بهويته الخاصة
Entra Managed Identity	عزل على مستوى المشروع؛ لا إدارة لبيانات الاعتماد
OAuth Identity Passthrough	وصول مُفوَّض من المستخدم؛ الوكيل يعمل نيابةً عن المستخدمين

OAuth Identity Passthrough هو الأكثر إثارةً للاهتمام. عندما يحتاج المستخدمون إلى منح وكيل حق الوصول إلى بياناتهم الشخصية — OneDrive الخاص بهم، أو مؤسسة Salesforce الخاصة بهم، أو واجهة برمجية SaaS مقيّدة بالمستخدم — يعمل الوكيل نيابةً عنهم من خلال تدفقات OAuth القياسية. لا هوية نظام مشتركة تتظاهر بأنها الجميع.

Voice Live: الكلام إلى الكلام دون التعقيدات

كان إضافة الصوت إلى وكيل يعني سابقاً تجميع STT وLLM وTTS معاً — ثلاث خدمات، وثلاث نقاط تأخير، وثلاثة أسطح للفوترة، كلها متزامنة يدوياً. Voice Live يدمج ذلك كله في واجهة برمجية موحّدة مُدارة مع:

الكشف الدلالي عن نشاط الصوت ونهاية الدور (يفهم المعنى، لا الصمت فحسب)
قمع الضوضاء وإلغاء الصدى من جانب الخادم
دعم المقاطعة (يمكن للمستخدمين المقاطعة في منتصف الاستجابة)

تمرّ تفاعلات الصوت عبر نفس بيئة تشغيل الوكيل كالنص. نفس المُقيِّمات، ونفس التتبعات، ونفس رؤية التكاليف. لسيناريوهات دعم العملاء، والخدمة الميدانية، أو إمكانية الوصول، يستبدل هذا ما كان يستلزم سابقاً خط أنابيب صوتياً مخصصاً.

التقييمات: من مربّع اختيار إلى مراقبة مستمرة

هنا تأخذ Foundry جودة الإنتاج بجدية. يمتلك نظام التقييم الآن ثلاث طبقات:

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

كل شيء يُنشر إلى Azure Monitor Application Insights. جودة الوكيل، وصحة البنية التحتية، والتكلفة، وتتبع التطبيق — كل ذلك في مكان واحد.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

ستة مناطق جديدة للوكلاء المستضافين

الوكلاء المستضافون متاحون الآن في East US وNorth Central US وSweden Central وSoutheast Asia وJapan East وغيرها. هذا مهم لمتطلبات إقامة البيانات ولضغط زمن الاستجابة عندما يعمل وكيلك قريباً من مصادر بياناته.

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

على الرغم من أن نماذج الكود في إعلان الإتاحة للعموم تُقدَّم بـ Python أولاً، فإن البنية التحتية الأساسية مستقلة عن اللغة — وحزمة .NET SDK الخاصة بـ azure-ai-projects تتبع نفس الأنماط. واجهة Responses API، وإطار التقييم، والشبكات الخاصة، ومصادقة MCP — كل هذا متاح من .NET.

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

خلاصة

خدمة Foundry Agent متاحة الآن. ثبّت حزمة SDK، وافتح البوابة، وابدأ البناء. دليل البدء السريع يأخذك من الصفر إلى وكيل عامل في دقائق.

للتعمق التقني الكامل مع جميع نماذج الكود، راجع إعلان الإتاحة للعموم.

من الحاسوب المحمول إلى الإنتاج: نشر وكلاء الذكاء الاصطناعي إلى 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 متاح الآن. إذا كنت تُؤجل نشر وكلاء الذكاء الاصطناعي الخاصة بك لأن إعداد البنية التحتية بدا يستلزم جهدًا كبيرًا، جرّب هذا. اطّلع على الشرح التفصيلي الكامل للخطوات الكاملة بما في ذلك تكامل تطبيق الدردشة الأمامي.