The .NET Blog

.NET 10 يأتي مع Ubuntu 26.04 LTS — ما الجديد

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

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

يوم Ubuntu LTS. أُطلق Ubuntu 26.04 (Resolute Raccoon) اليوم مع .NET 10.

ثبّت .NET 10 بأمرين

sudo apt update
sudo apt install dotnet-sdk-10.0

الحاويات: استبدل `-noble` بـ `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: بدء في 3ms، ثنائي بحجم 1.4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# ثنائي أصلي 1.4MB، بدء في 3ms

بالنسبة لأعباء العمل السحابية الأصلية حيث يهم وقت البدء الفعلي — Functions، الحاويات، serverless — هذا تغيير حقيقي في قواعد اللعبة.

تحتاج .NET 8 أو 9؟

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

يتضمن المقال الكامل مزيدًا من التفاصيل.

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

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

CodeAct في Agent Framework: كيف تخفض زمن استجابة وكيلك إلى النصف

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

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

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

هذا بالضبط ما يحله CodeAct — وفريق Agent Framework أصدر للتو دعماً تجريبياً عبر حزمة agent-framework-hyperlight الجديدة.

ما هو CodeAct؟

نمط CodeAct بسيط بأناقة: بدلاً من إعطاء النموذج قائمة من الأدوات لاستدعائها واحدة تلو الأخرى، تعطيه أداة execute_code واحدة وتتيح له التعبير عن الخطة بأكملها كبرنامج Python قصير.

الأسلوب	الوقت	الرموز
التقليدي	27.81 ث	6,890
CodeAct	13.23 ث	2,489
التحسن	52.4%	63.9%

الأمان: الأجهزة الافتراضية الصغيرة Hyperlight

تستخدم حزمة agent-framework-hyperlight الأجهزة الافتراضية الصغيرة Hyperlight. كل استدعاء execute_code يحصل على جهاز افتراضي صغير خاص به تم إنشاؤه حديثاً. بدء التشغيل يُقاس بالمللي ثانية. العزل عملياً مجاني.

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

الإعداد الأدنى

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

متى تستخدم CodeAct (ومتى لا تستخدمه)

استخدم CodeAct عندما:

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

ابقَ مع استدعاء الأدوات التقليدي عندما:

يُجري الوكيل استدعاءً أو اثنين فقط في كل دور
لكل استدعاء آثار جانبية تستوجب موافقة فردية

جرّبه الآن

pip install agent-framework-hyperlight --pre

اقرأ المنشور الكامل في مدونة Agent Framework.

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: "وكيلي");

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

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

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

أين يتذكر وكيلك الأشياء؟ دليل عملي لتخزين سجل المحادثات

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

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

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

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

نمطان أساسيان

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

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

كيف يُجرّد Agent Framework هذا

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("اسمي أليس.", session);
var second = await agent.RunAsync("ما اسمي؟", session);

مرجع سريع للموفرين

الموفر	التخزين	النموذج	الضغط
OpenAI/Azure Chat Completions	العميل	لا ينطبق	أنت
Foundry Agent Service	الخدمة	خطي	الخدمة
Responses API (افتراضي)	الخدمة	متفرع	الخدمة
Anthropic Claude, Ollama	العميل	لا ينطبق	أنت

كيف تختار

تحتاج تفرعًا أو “تراجعًا”؟ → Responses API مُدارة من الخدمة
تحتاج سيادة البيانات؟ → مُدارة من العميل مع موفر بقاعدة بيانات
روبوت محادثة بسيط؟ → خطية مُدارة من الخدمة تكفي

اقرأ المقال الكامل للاطلاع على شجرة القرار الكاملة.

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 متاح الآن — تحقق من المنشور الرسمي للحصول على التوثيق الكامل.

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

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

كتابة إضافات Node.js الأصلية بلغة C# مع .NET Native AOT

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

إليك سيناريو أحبه: فريق يعمل على أدوات .NET كان لديه إضافات Node.js أصلية مكتوبة بـ C++ ومُجمَّعة عبر node-gyp. كانت تعمل. لكنها كانت تتطلب تثبيت Python على كل جهاز مطوّر — إصدارًا قديمًا من Python — فقط لتجميع حزمة لن يمسّها أحد في الفريق مباشرةً.

فطرحوا سؤالًا معقولًا جدًا: لدينا .NET SDK مثبّت بالفعل، لماذا نكتب C++ أصلًا؟

كانت الإجابة هي Native AOT، والنتيجة أنيقة حقًا. كتب Drew Noakes من فريق C# Dev Kit كيفية القيام بذلك.

الفكرة الأساسية

إضافة Node.js الأصلية هي مكتبة مشتركة (.dll على Windows، .so على Linux، .dylib على macOS) يمكن لـ Node.js تحميلها في وقت التشغيل. الواجهة تُسمى N-API — واجهة برمجة تطبيقات C مستقرة ومتوافقة مع ABI. لا يهتم N-API بالغة التي أنتجت المكتبة، فقط أن تُصدِّر الرموز الصحيحة.

يمكن لـ .NET Native AOT تحقيق ذلك تمامًا. يُجمِّع كود C# مسبقًا إلى مكتبة مشتركة أصلية بنقاط دخول اختيارية.

إعداد المشروع

ملف المشروع في أدنى حد:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot يُخبر SDK بإنتاج مكتبة مشتركة عند dotnet publish.

تصدير نقطة الدخول

يتوقع Node.js أن تُصدِّر مكتبتك napi_register_module_v1. في C#، [UnmanagedCallersOnly] يفعل ذلك تمامًا:

[UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
}

اللاحقة u8 تُنتج ReadOnlySpan<byte> مع قيمة حرفية للسلسلة UTF-8، مُمرَّرة مباشرةً إلى N-API دون أي تخصيص ترميز.

حل N-API مقابل العملية المضيفة

تُصدَّر دوال N-API من node.exe نفسه، وليس من مكتبة منفصلة. لذا بدلًا من الربط بشيء ما، تحلّها مقابل العملية الجارية عند بدء التشغيل:

NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

مع ذلك، تعمل إعلانات P/Invoke بشكل نظيف:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

استدعاؤه من TypeScript

يُنتج dotnet publish مكتبتك الأصلية الخاصة بالمنصة. غيّر اسمها إلى .node واستخدمها مع require() القياسي:

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

هذا كل شيء. من TypeScript إلى C#، بدون Python، بدون C++.

خلاصة

استبدل فريق C# Dev Kit عبء Python/C++ بكود C# نظيف يعرف كل شخص في الفريق كيفية كتابته وتصحيحه. النمط ليس معقدًا بمجرد رؤيته، وهو مثال رائع على Native AOT يحل مشكلة حقيقية لا تُناقش بما فيه الكفاية.

اقرأ المقالة الأصلية على مدونة .NET.

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 ولم تتعمق بعد في سير العمل الآلي، بصراحة، الآن هو الوقت المناسب للبدء.

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

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

تجميع الدبابيس يصل أخيراً إلى خرائط .NET MAUI — خاصية واحدة، لا ألم

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

تعرف تلك اللحظة حين تحمّل خريطة بمئة دبوس ويتحول كل شيء إلى كتلة غير قابلة للقراءة؟ نعم، هذا كان تجربة .NET MAUI Maps — حتى الآن. لا مزيد من ذلك.

David Ortinau أعلن للتو أن .NET MAUI 11 Preview 3 يشحن تجميع الدبابيس جاهزاً للاستخدام على Android وiOS/Mac Catalyst. والجزء الأفضل — تفعيله سهل بشكل مدهش.

خاصية واحدة لحكمهم جميعاً

<maps:Map IsClusteringEnabled="True" />

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

مجموعات تجميع مستقلة

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

خاصية ClusteringIdentifier تتيح لك فصل الدبابيس إلى مجموعات مستقلة:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

الدبابيس ذات المعرّف نفسه تتجمع معاً. المعرّفات المختلفة تُشكّل مجموعات مستقلة حتى عند التقارب الجغرافي. لا معرّف؟ المجموعة الافتراضية. واضح ومتوقع.

معالجة النقر على المجموعة

حين ينقر مستخدم على مجموعة، تحصل على حدث ClusterClicked بكل ما تحتاجه:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

تمنحك وسيطات الحدث Pins (الدبابيس في المجموعة)، وLocation (المركز الجغرافي)، وHandled (اضبطها على true إذا أردت تجاوز التكبير الافتراضي). بسيط، عملي، تماماً ما تتوقعه.

تفاصيل المنصة تستحق المعرفة

على Android، يستخدم التجميع خوارزمية شبكية مخصصة تُعيد الحساب عند تغيّر مستوى التكبير — دون تبعيات خارجية. على iOS وMac Catalyst، يستفيد من دعم MKClusterAnnotation الأصيل في MapKit، مما يعني حركات انتقال سلسة وأصيلة للمنصة.

هذه إحدى الحالات التي اتخذ فيها فريق MAUI القرار الصحيح — الاتكاء على المنصة حيث يكون ذلك منطقياً.

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

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

لنا نحن مطوّري .NET الذين نبني تطبيقات جوالة متعددة المنصات، هذا هو نوع تحسينات جودة الحياة الذي يجعل MAUI خياراً عملياً حقيقياً للسيناريوهات المكثفة باستخدام الخرائط.

ابدأ الآن

ثبّت .NET 11 Preview 3 وحدّث حمل عمل .NET MAUI. نموذج Maps يتضمن صفحة Clustering جديدة يمكنك تجربتها مباشرةً.

ابنِ شيئاً به — واترح خرائطك أخيراً.

.NET أبريل 2026 — تحديثات الأمان التي يجب تطبيقها اليوم

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

صدرت تحديثات الخدمة لأبريل 2026 لـ .NET و.NET Framework، وتتضمن هذه الدفعة إصلاحات أمنية تريد تطبيقها في أقرب وقت. ست ثغرات CVE مُصلَحة، بما في ذلك ثغرتان للتنفيذ عن بُعد (RCE).

ما الذي تمت معالجته

إليك الملخص السريع:

CVE	النوع	يؤثر على
CVE-2026-26171	تجاوز ميزة الأمان	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	تنفيذ عن بُعد	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	تنفيذ عن بُعد	.NET 10, 9, 8
CVE-2026-32203	حجب الخدمة	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	حجب الخدمة	.NET Framework 3.0–4.8.1
CVE-2026-32226	حجب الخدمة	.NET Framework 2.0–4.8.1

تؤثر ثغرتا RCE (CVE-2026-32178 وCVE-2026-33116) على أوسع نطاق من إصدارات .NET وينبغي إعطاؤهما الأولوية.

الإصدارات المحدَّثة

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

جميعها متاحة عبر القنوات المعتادة — dotnet.microsoft.com، وصور الحاويات على MCR، ومديري حزم Linux.

ماذا تفعل

حدّث مشاريعك وخطوط CI/CD إلى أحدث إصدارات التصحيح. إذا كنت تشغّل حاويات، اسحب أحدث الصور. إذا كنت على .NET Framework، تحقق من ملاحظات إصدار .NET Framework للتصحيحات المقابلة.

بالنسبة لمن يشغّل .NET 10 في الإنتاج (وهو الإصدار الحالي)، فإن 10.0.6 تحديث إلزامي. ينطبق الأمر ذاته على .NET 9.0.15 و.NET 8.0.26 إذا كنت على تلك المسارات طويلة الأمد للدعم (LTS). ثغرتا تنفيذ عن بُعد ليستا مما يمكن تأجيله.

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 للحصول على أمثلة عملية.

تصحيح Azure DevOps Server لشهر أبريل 2026 — إصلاح اكتمال طلبات السحب وتحديثات الأمان

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

تنبيه سريع للفرق التي تشغل Azure DevOps Server المستضاف ذاتياً: أصدرت Microsoft التصحيح 3 لشهر أبريل 2026 مع ثلاثة إصلاحات محددة.

ما الذي تم إصلاحه

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

كيفية التحديث

نزّل التصحيح 3 وشغّل المثبت. للتحقق من تطبيق التصحيح:

<patch-installer>.exe CheckInstall

إذا كنت تشغّل Azure DevOps Server محلياً، توصي Microsoft بشدة بالبقاء على آخر تصحيح للأمان والموثوقية معاً. راجع ملاحظات الإصدار للتفاصيل الكاملة.

مهارات الوكيل في .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. إذا كنت تنتظر إشارة “جاهز للمؤسسات” — هذه هي.

.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 للاطلاع على كل التفاصيل ومقاطع الفيديو التوضيحية.

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 — المنصة جاهزة لأحمال العمل الجادة.

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

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.

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

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 للتعمق أكثر.

تطبيقات MCP تحصل على واجهة برمجة سلسة — أنشئ واجهات أدوات AI غنية في .NET بثلاث خطوات

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

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

Lilian Kasem من فريق Azure SDK قدّمت واجهة التهيئة السلسة الجديدة لتطبيقات MCP على .NET Azure Functions، وهو نوع تحسين تجربة المطوّر الذي يجعلك تتساءل لماذا لم يكن الأمر بهذه البساطة دائماً.

ما هي تطبيقات MCP؟

تطبيقات MCP تُوسّع Model Context Protocol بالسماح للأدوات بحمل مشاهداتها UI الخاصة، والأصول الثابتة، وعناصر التحكم الأمني. بدلاً من إعادة نص فحسب، يمكن لأداة MCP الخاصة بك عرض تجارب HTML كاملة — لوحات معلومات تفاعلية، ومرئيات بيانات، ونماذج تهيئة — كلها قابلة للاستدعاء من وكلاء الذكاء الاصطناعي ومُقدَّمة للمستخدمين من قِبل عملاء MCP.

كان الإشكال أن توصيل كل هذا يدوياً استلزم معرفة عميقة بمواصفات MCP: عناوين URI بصيغة ui://، وأنواع MIME خاصة، وتنسيق البيانات الوصفية بين الأدوات والموارد. ليس صعباً، لكنه مُضجِر.

واجهة البرمجة السلسة في ثلاث خطوات

الخطوة 1: عرّف دالتك. مجرد أداة Azure Functions MCP قياسية:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

الخطوة 2: ارقِها إلى تطبيق MCP. في بدء تشغيل برنامجك:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

الخطوة 3: أضف مشهد HTML الخاص بك. أنشئ assets/hello-app.html بأي واجهة مستخدم تحتاجها.

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

سطح واجهة البرمجة مصمَّم جيداً

بعض الأشياء التي أعجبتني حقاً:

مصادر المشهد مرنة. يمكنك تقديم HTML من ملفات على القرص، أو تضمين الموارد مباشرةً في التجميع للنشر الكامل المستقل:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP قابل للتركيب. تُدرج صراحةً المصادر الأصلية التي يحتاجها تطبيقك، متبعاً مبادئ الامتياز الأدنى. استدعِ WithCsp عدة مرات وتتراكم المصادر:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

التحكم في الرؤية. يمكنك جعل الأداة مرئية لـ LLM فقط، أو لواجهة المضيف فقط، أو لكليهما. تريد أداة تعرض واجهة المستخدم فقط ولا ينبغي للنموذج استدعاؤها؟ سهل:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

البدء

أضف حزمة المعاينة:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

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

خلاصة

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

اقرأ المنشور الكامل للمرجع الكامل لواجهة البرمجة والأمثلة.

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

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

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، فهذه هي إصلاحات جودة الحياة التي تقلل الاحتكاك اليومي.

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

C# 15 يحصل على أنواع الاتحاد — وهي بالضبط ما كنا نطلبه

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

هذه هي الميزة التي كنت أنتظرها. يُقدّم C# 15 الكلمة المفتاحية union — أنواع اتحاد مُميَّزة حقيقية مع مطابقة أنماط شاملة يُطبّقها المُحوِّل. إذا سبق لك أن حسدت F# على أنواع اتحادها المُميَّزة أو Rust على تعداداته، فأنت تعرف تمامًا لماذا يهم هذا.

نشر Bill Wagner التعمق الكامل على مدونة .NET، وصراحةً؟ التصميم نظيف وعملي ويتماشى تمامًا مع أسلوب C#. دعني أقودك عبر ما هو موجود فعليًا ولماذا هو أمر أكبر مما قد يبدو للوهلة الأولى.

المشكلة التي تحلها أنواع الاتحاد

قبل C# 15، كانت إعادة “أحد الأنواع الممكنة المتعددة” من دالة دائمًا تنازلًا:

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

لا شيء من هذه يمنحك ما تريده فعلًا: مجموعة مغلقة من الأنواع حيث يضمن المُحوِّل أنك تعاملت مع كل حالة. هذا ما تفعله أنواع الاتحاد.

الصيغة بسيطة بشكل جميل

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

سطر واحد. يمكن لـ Pet أن يحمل Cat أو Dog أو Bird. تُولَّد التحويلات الضمنية تلقائيًا:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

وهنا يكمن السحر — يُطبّق المُحوِّل المطابقة الشاملة:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

لا حاجة لـ _ للتجاهل. يعلم المُحوِّل أن هذا التعبير يغطي كل حالة ممكنة. إذا أضفت لاحقًا نوعًا رابعًا إلى الاتحاد، فكل تعبير switch لا يتعامل معه يُنتج تحذيرًا. الحالات المفقودة تُكتشف في وقت البناء لا في وقت التشغيل.

أين يُصبح هذا عمليًا

مثال Pet لطيف، لكن إليك أين تتألق الاتحادات فعلًا في الكود الحقيقي.

استجابات API التي تُعيد أشكالًا مختلفة

public union ApiResult<T>(T, ApiError, ValidationFailure);

الآن كل مستهلك مُجبر على التعامل مع النجاح والخطأ وفشل التحقق. لا مزيد من أخطاء “نسيت التحقق من حالة الخطأ”.

قيمة واحدة أو مجموعة

يُظهر نمط OneOrMore<T> كيف يمكن لاتحادات أن تحتوي على جسم مع دوال مساعدة:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

المستدعون يمررون الشكل الذي يناسبهم:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

تكوين أنواع غير مترابطة

هذه هي الميزة القاتلة على التسلسلات الهرمية التقليدية. يمكنك توحيد أنواع ليس بينها أي قاسم مشترك — string وException، int وIEnumerable<T>. لا حاجة لسلف مشترك.

اتحادات مخصصة للمكتبات الموجودة

إليك خيار تصميمي ذكي: أي فئة أو بنية بسمة [Union] تُعترف بها كنوع اتحاد، طالما تتبع النمط الأساسي (مُنشئات عامة لأنواع الحالة وخاصية Value). المكتبات مثل OneOf التي تُقدم بالفعل أنواعًا شبيهة بالاتحاد يمكنها الاشتراك في دعم المُحوِّل دون إعادة كتابة بنيتها الداخلية.

بالنسبة للسيناريوهات الحساسة للأداء مع أنواع القيمة، يمكن للمكتبات تنفيذ نمط وصول غير ملاكم مع دوال HasValue وTryGetValue.

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

أنواع الاتحاد هي جزء من قصة شمولية أوسع قادمة إلى C#:

أنواع الاتحاد — مطابقة شاملة على مجموعة مغلقة من الأنواع (متاحة الآن في المعاينة)
التسلسلات الهرمية المغلقة — المُعدِّل closed يمنع الفئات المشتقة خارج التجميع المُعرِّف (مقترح)
التعدادات المغلقة — تمنع إنشاء قيم بخلاف الأعضاء المُعلَّن عنهم (مقترح)

معًا، ستمنح هذه الميزات الثلاث C# أحد أنظمة مطابقة الأنماط الآمنة للنوع الأكثر شمولًا في أي لغة رئيسية.

جرّبها اليوم

أنواع الاتحاد متاحة في .NET 11 Preview 2:

ثبّت .NET 11 Preview SDK
استهدف net11.0 في مشروعك
اضبط <LangVersion>preview</LangVersion>

تحفظ واحد: في Preview 2، ستحتاج إلى تعريف UnionAttribute وIUnion في مشروعك لأنهما ليسا في وقت التشغيل بعد. احصل على RuntimePolyfill.cs من مستودع المستندات، أو أضف هذا:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

خلاصة

أنواع الاتحاد هي إحدى تلك الميزات التي تجعلك تتساءل كيف اجتزنا بدونها. مطابقة شاملة يُطبّقها المُحوِّل، وصيغة نظيفة، ودعم للأنماط العامة، وتكامل مع مطابقة الأنماط الموجودة — إنها كل ما كنا نطلبه، منجزًا بأسلوب C#.

جرّبها في .NET 11 Preview 2، اختبر حدودها، وشارك ملاحظاتك على GitHub. هذه نسخة معاينة، وفريق C# يستمع بنشاط. حالاتك الحدية وملاحظاتك التصميمية ستشكّل الإصدار النهائي.

للمرجع الكامل للغة، راجع مستندات أنواع الاتحاد ومواصفات الميزة.

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 الرسمي للاطلاع على كل التفاصيل.

إطار عمل Microsoft Agent يصل إلى الإصدار 1.0 — إليك ما يهمّ فعلاً لمطوّري .NET

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

إذا كنت تتابع رحلة Agent Framework منذ أيام Semantic Kernel وAutoGen الأولى، فهذا الخبر مهمّ. وصل Microsoft Agent Framework للتو إلى الإصدار 1.0 — جاهز للإنتاج، مع واجهات برمجية مستقرة، والتزام بالدعم طويل الأمد. متاح لكلٍّ من .NET وPython، وهو مستعد فعلاً للأعباء الحقيقية.

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

الملخص السريع

يوحّد Agent Framework 1.0 ما كان يُعرف بـ Semantic Kernel وAutoGen في حزمة تطوير واحدة مفتوحة المصدر. تجريد وكيل واحد. محرك تنسيق واحد. مزوّدو ذكاء اصطناعي متعددون. إذا كنت تتنقل بين Semantic Kernel لأنماط المؤسسات وAutoGen لمهام سير العمل متعددة الوكلاء على مستوى البحث، يمكنك التوقف عن ذلك. هذه هي الحزمة الواحدة الآن.

البدء سهل بشكل غير عادل

إليك وكيل عملي في .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

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

تنسيق متعدد الوكلاء — هذا هو الأمر الحقيقي

الوكلاء الفرديون مناسبون للعروض التوضيحية، لكن سيناريوهات الإنتاج عادةً ما تحتاج إلى تنسيق. يأتي Agent Framework 1.0 مزوّداً بأنماط تنسيق مجرّبة مباشرةً من Microsoft Research وAutoGen:

التسلسلي — يعالج الوكلاء بالترتيب (كاتب ← مراجع ← محرر)
المتزامن — توزيع على وكلاء متعددين بالتوازي، وتجميع النتائج
التسليم — يفوّض وكيل إلى آخر بناءً على النية
المحادثة الجماعية — يناقش وكلاء متعددون ويتقاربون على حل
Magentic-One — نمط متعدد الوكلاء على مستوى البحث من MSR

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

الميزات الأكثر أهمية

إليك قائمتي المختصرة بما يستحق المعرفة:

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

الذاكرة القابلة للتوصيل. سجل المحادثة، وحالة المفتاح-القيمة الدائمة، والاسترجاع القائم على المتجهات. اختر خلفيتك: Foundry Agent Service، أو Mem0، أو Redis، أو Neo4j، أو أنشئ واحدة خاصة بك. الذاكرة هي ما يحوّل استدعاء نموذج لغوي عديم الحالة إلى وكيل يتذكر السياق فعلاً.

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

دعم A2A وMCP. يتيح MCP (Model Context Protocol) للوكلاء اكتشاف الأدوات الخارجية واستدعاءها ديناميكياً. يُمكّن A2A (بروتوكول الوكيل-إلى-الوكيل) التعاون عبر أوقات التشغيل — يمكن لوكلاء .NET التنسيق مع وكلاء يعملون في أطر عمل أخرى. دعم A2A 1.0 قادم قريباً.

ميزات المعاينة التي تستحق المتابعة

شُحنت بعض الميزات كمعاينة في 1.0 — وظيفية لكن الواجهات البرمجية قد تتطور:

DevUI — مصحّح أخطاء محلي يعمل بالمتصفح لتصوير تنفيذ الوكيل وتدفقات الرسائل واستدعاءات الأدوات في الوقت الفعلي. فكّر في الأمر كـ Application Insights لكن للتفكير الوكيلي.
GitHub Copilot SDK وClaude Code SDK — استخدم Copilot أو Claude كإطار وكيل مباشرةً من كود التنسيق. ضع معاً وكيلاً قادراً على البرمجة إلى جانب وكلائك الأخرى في نفس سير العمل.
Agent Harness — بيئة تشغيل محلية قابلة للتخصيص تمنح الوكلاء الوصول إلى الصدفة ونظام الملفات وحلقات المراسلة. فكّر في وكلاء البرمجة وأنماط الأتمتة.
المهارات (Skills) — حزم قدرات نطاق قابلة لإعادة الاستخدام تمنح الوكلاء قدرات منظمة جاهزة.

الترحيل من Semantic Kernel أو AutoGen

إذا كان لديك كود Semantic Kernel أو AutoGen حالي، فهناك مساعدو ترحيل مخصصون يحللون كودك ويولّدون خطط ترحيل خطوة بخطوة. يرشدك دليل ترحيل Semantic Kernel ودليل ترحيل AutoGen عبر كل شيء.

إذا كنت على حزم RC، فالترقية إلى 1.0 مجرد رفع رقم الإصدار.

خلاصة القول

Agent Framework 1.0 هو المعلم الإنتاجي الذي كانت فرق المؤسسات تنتظره. واجهات برمجية مستقرة، ودعم متعدد المزوّدين، وأنماط تنسيق تعمل فعلاً على نطاق واسع، ومسارات ترحيل من كلٍّ من Semantic Kernel وAutoGen.

الإطار مفتوح المصدر بالكامل على GitHub، ويمكنك البدء اليوم بـ dotnet add package Microsoft.Agents.AI. اطّلع على دليل البدء السريع والأمثلة للبدء عملياً.

إذا كنت تنتظر إشارة “آمن للاستخدام في الإنتاج” — فهذه هي.

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

لوحة تحكم Aspire 13.2 حصلت للتو على واجهة برمجية للقياس عن بُعد — وهذا يغيّر كل شيء

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

إذا كنت تبني تطبيقات موزّعة باستخدام .NET Aspire، فأنت تعرف بالفعل أن لوحة التحكم هي أفضل شيء في التجربة بأكملها. جميع التتبعات والسجلات والمقاييس في مكان واحد — لا Jaeger خارجي، ولا إعداد Seq، ولا لحظات “دعني أتحقق من الطرفية الأخرى.”

قدّم Aspire 13.2 للتو تحسيناً ملحوظاً. أعلن James Newton-King عن التحديث، وبصراحة؟ ميزات تصدير القياس عن بُعد والواجهة البرمجية وحدها تستحق الترقية.

تصدير القياس عن بُعد بطريقة سليمة

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

يُضيف Aspire 13.2 حوار إدارة السجلات والقياس عن بُعد الصحيح حيث يمكنك:

مسح جميع بيانات القياس (مفيد قبل محاولة إعادة الإنتاج)
تصدير بيانات القياس المحددة إلى ملف ZIP بتنسيق OTLP/JSON القياسي
إعادة استيراد ذلك الـ ZIP إلى أي لوحة تحكم Aspire لاحقاً

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

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

واجهة برمجية للقياس عن بُعد هي المُغيِّر الحقيقي لقواعد اللعبة

هذا ما أنا أكثر حماساً له. تكشف لوحة التحكم الآن عن واجهة برمجية HTTP تحت /api/telemetry للاستعلام عن بيانات القياس برمجياً. نقاط النهاية المتاحة:

GET /api/telemetry/resources — سرد الموارد مع بيانات القياس
GET /api/telemetry/spans — الاستعلام عن الامتدادات بفلاتر
GET /api/telemetry/logs — الاستعلام عن السجلات بفلاتر
GET /api/telemetry/traces — سرد التتبعات
GET /api/telemetry/traces/{traceId} — الحصول على جميع امتدادات تتبع محدد

كل شيء يعود بتنسيق OTLP JSON. هذا يُشغّل أوامر CLI الجديدة aspire agent mcp وaspire otel، لكن الانعكاس الحقيقي أكبر: يمكنك الآن بناء أدوات وسكريبتات وتكاملات وكلاء ذكاء اصطناعي تستعلم عن بيانات القياس الفعلية لتطبيقك مباشرةً.

تخيّل وكيل ذكاء اصطناعي للبرمجة يمكنه النظر في تتبعاتك الموزّعة الفعلية أثناء التصحيح. هذا لم يعد افتراضياً — هذا ما تُمكّنه هذه الواجهة البرمجية.

قياس GenAI عن بُعد يصبح عملياً

إذا كنت تبني تطبيقات مدعومة بالذكاء الاصطناعي باستخدام Semantic Kernel أو Microsoft.Extensions.AI، فستقدّر محسّن تصوير قياس GenAI عن بُعد المحسَّن. يُضيف Aspire 13.2:

تُصيَّر أوصاف أدوات الذكاء الاصطناعي كـ Markdown
زر GenAI مخصص على صفحة التتبعات للوصول السريع إلى تتبعات الذكاء الاصطناعي
معالجة أفضل للأخطاء للـ JSON الغير معياري أو المقطوع للـ GenAI
التنقل بالنقر لتمييز التعريفات بين تعريفات الأدوات

تذكر منشور المدوّنة أن VS Code Copilot chat وCopilot CLI وOpenCode جميعها تدعم إعداد OTEL_EXPORTER_OTLP_ENDPOINT. وجّهها إلى لوحة تحكم Aspire ويمكنك حرفياً مشاهدة وكلاء الذكاء الاصطناعي تفكّر في الوقت الفعلي من خلال القياس عن بُعد. هذه تجربة تصحيح لن تجدها في أي مكان آخر.

خلاصة القول

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

إذا كنت بالفعل على Aspire، قم بالترقية. إذا لم تكن — هذا سبب وجيه للاطّلاع على aspire.dev ومعرفة سبب الاهتمام به.

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

VS Code 1.112: ما يهمك فعلاً كمطور .NET

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

وصل VS Code 1.112 للتو، وبصراحة؟ هذا الإصدار مختلف إذا كنت تقضي أيامك في عالم .NET. يوجد الكثير في ملاحظات الإصدار الرسمية، لكن دعني أوفر عليك التمرير وأركز على ما يهم فعلاً بالنسبة لنا.

Copilot CLI أصبح أكثر فائدة بكثير

الموضوع الرئيسي لهذا الإصدار هو استقلالية الوكيل — إعطاء Copilot مساحة أكبر للعمل دون مراقبة كل خطوة.

توجيه الرسائل وإضافتها إلى قائمة الانتظار

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

هذا رائع لمهام السقالات الطويلة باستخدام dotnet حيث تشاهد Copilot يُعدّ مشروعاً وتفكر “آه، أريد أيضاً MassTransit في هذا.”

مستويات الأذونات

هذا الأكثر إثارة لاهتمامي. تدعم جلسات Copilot CLI الآن ثلاثة مستويات أذونات:

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

إذا كنت تُنشئ سقالة لـ ASP.NET Core API جديدة مع Entity Framework والترحيلات وإعداد Docker — فوضع Autopilot يعني أنك تصف ما تريد ثم تذهب لتحضير قهوة. سيعرف كيف يُنجز المهمة.

يمكنك تمكين Autopilot بإعداد chat.autopilot.enabled.

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

عندما تفوّض مهمة لـ Copilot CLI، يُنشئ worktree. في السابق، إذا كان لديك تغييرات غير مُودَعة، كان عليك مراجعة Source Control لمعرفة ما سيتأثر. الآن يعرض عرض Chat التغييرات المعلّقة مباشرةً قبل أن تقرر ما إذا كنت تريد نسخها أو نقلها أو تجاهلها.

أمر بسيط، لكنه يجنّبك لحظة “انتظر، ماذا كان لديّ في منطقة الإعداد؟”

تصحيح تطبيقات الويب دون مغادرة VS Code

يدعم المتصفح المدمج الآن التصحيح الكامل. يمكنك تعيين نقاط التوقف والتنقل خطوة بخطوة وفحص المتغيرات — كل ذلك داخل VS Code. لا مزيد من التبديل إلى Edge DevTools.

يوجد نوع تصحيح جديد editor-browser، وإذا كانت لديك تكوينات تشغيل msedge أو chrome موجودة، فالترحيل بسيط كتغيير حقل type في launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

لمطوري Blazor، هذا تغيير جذري. أنت بالفعل تشغّل dotnet watch في الطرفية — الآن يبقى التصحيح في نفس النافذة أيضاً.

حصل المتصفح أيضاً على مستويات تكبير مستقلة (أخيراً)، وقوائم سياق صحيحة بنقر يمين، ويُحفظ التكبير لكل موقع على حدة.

عزل خادم MCP في صندوق رمل

هذا أهم مما تعتقد. إذا كنت تستخدم خوادم MCP — ربما أعددت خادماً مخصصاً لموارد Azure أو استعلامات قاعدة البيانات — فقد كانت تعمل بنفس أذونات عملية VS Code. هذا يعني وصولاً كاملاً إلى نظام الملفات والشبكة وكل شيء.

الآن يمكنك عزلها في صندوق رمل. في ملف mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

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

اكتشاف تخصيصات Monorepo

إذا كنت تعمل في monorepo (ولنكن صادقين، كثير من مشاريع .NET المؤسسية تصبح كذلك في نهاية المطاف)، فهذا يحل نقطة ألم حقيقية.

في السابق، إذا فتحت مجلداً فرعياً من مستودعك، لن يجد VS Code ملف copilot-instructions.md أو AGENTS.md أو المهارات المخصصة الموجودة في جذر المستودع. الآن مع إعداد chat.useCustomizationsInParentRepositories، يصعد إلى جذر .git ويكتشف كل شيء.

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

/troubleshoot لتصحيح أخطاء الوكيل

هل سبق أن أعددت تعليمات أو مهارات مخصصة وتساءلت لماذا لا يتم التقاطها؟ مهارة /troubleshoot الجديدة تقرأ سجلات تصحيح الوكيل وتخبرك بما حدث — أي الأدوات استُخدمت أو تجاوزت، ولماذا لم يُحمَّل التعليمات، وما الذي يتسبب في بطء الاستجابات.

مكّنها بـ:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

ثم اكتب /troubleshoot لماذا لا تُحمَّل مهارتي المخصصة؟ في المحادثة.

يمكنك أيضاً تصدير هذه السجلات واستيرادها الآن، وهو أمر رائع لمشاركتها مع فريقك عندما لا يعمل شيء كما هو متوقع.

دعم الصور والملفات الثنائية

يمكن للوكلاء الآن قراءة ملفات الصور من القرص والملفات الثنائية بشكل أصلي. تُعرض الملفات الثنائية بتنسيق hexdump، ومخرجات الصور (مثل لقطات الشاشة من المتصفح المدمج) تظهر في عرض دوّار.

لمطوري .NET، فكّر في: لصق لقطة شاشة لخطأ في واجهة المستخدم في المحادثة وطلب من الوكيل فهم ما الخطأ، أو تحليل مخرجات مكوّن Blazor.

المراجع الرمزية التلقائية

تحسين بسيط لجودة الحياة: عندما تنسخ اسم رمز (فئة أو طريقة وما إلى ذلك) وتلصقه في المحادثة، يحوّله VS Code الآن تلقائياً إلى مرجع #sym:Name. هذا يمنح الوكيل السياق الكامل عن هذا الرمز دون الحاجة لإضافته يدوياً.

إذا أردت نصاً عادياً بدلاً من ذلك، استخدم Ctrl+Shift+V.

تمكين/تعطيل الإضافات

في السابق، تعطيل خادم MCP أو إضافة كان يعني إلغاء تثبيته. الآن يمكنك تبديل تشغيلهم وإيقافهم — عالمياً وفي كل مساحة عمل على حدة. انقر يمين في عرض Extensions أو عرض Customizations وانتهى الأمر.

الإضافات من npm وpypi يمكنها أيضاً التحديث التلقائي الآن، وإن كانت ستطلب الموافقة أولاً لأن التحديثات تعني تشغيل كود جديد على جهازك.

خلاصة القول

يدفع VS Code 1.112 بقوة نحو تجربة الوكيل — استقلالية أكبر، وتصحيح أفضل، وأمان أكثر إحكاماً. لمطوري .NET، التصحيح عبر المتصفح المدمج وتحسينات Copilot CLI هي الميزات البارزة.

إذا لم تجرّب بعد تشغيل جلسة Copilot CLI كاملة في وضع Autopilot لمشروع .NET، فهذا الإصدار هو الوقت المناسب للبدء. فقط تذكر ضبط أذوناتك ودعه يعمل.

قم بتنزيل VS Code 1.112 أو التحديث من داخل VS Code عبر Help > Check for Updates.

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

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog

.NET 10 يأتي مع Ubuntu 26.04 LTS — ما الجديد

ثبّت .NET 10 بأمرين

الحاويات: استبدل -noble بـ -resolute

Native AOT: بدء في 3ms، ثنائي بحجم 1.4MB

تحتاج .NET 8 أو 9؟

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

ما هو MCP Bundle؟

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

للبدء

CodeAct في Agent Framework: كيف تخفض زمن استجابة وكيلك إلى النصف

ما هو CodeAct؟

الأمان: الأجهزة الافتراضية الصغيرة Hyperlight

الإعداد الأدنى

متى تستخدم CodeAct (ومتى لا تستخدمه)

جرّبه الآن

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

تطور GPT-5

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

التسعير

لماذا يهم Foundry

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

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

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

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

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

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

أين يتذكر وكيلك الأشياء؟ دليل عملي لتخزين سجل المحادثات

نمطان أساسيان

كيف يُجرّد Agent Framework هذا

مرجع سريع للموفرين

كيف تختار

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

خلاصة

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

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

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

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

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

خاتمة

كتابة إضافات Node.js الأصلية بلغة C# مع .NET Native AOT

الفكرة الأساسية

إعداد المشروع

تصدير نقطة الدخول

حل N-API مقابل العملية المضيفة

استدعاؤه من TypeScript

خلاصة

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

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

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

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

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

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

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

الخلاصة

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

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

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

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

الحاويات: استبدل `-noble` بـ `-resolute`