Ai | The .NET Blog

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

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

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

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

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

ما هو MCP Bundle؟

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

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

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

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

2. ثبّت في Claude Desktop

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

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

az login

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

للبدء

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

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

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

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

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

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 للتوثيق الكامل، والإعلان الأصلي لجميع التفاصيل.

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

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

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

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

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

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

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

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

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

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

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

from azure.ai.agentserver.agentframework import from_agent_framework

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إطاري للقرار

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

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

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

خلاصة القول

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

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

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

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

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

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

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

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

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

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

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

## Instructions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة القول

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

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

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

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

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

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

ما هو Azure MCP Server؟

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

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

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

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

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

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

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

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

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

تحصين الأمان

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

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

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

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

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

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

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

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

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

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

البدء

اختر مسارك:

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

خلاصة القول

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

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

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

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

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

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

خادم 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 هو مكسب سريع — أدواتك المخصصة تصبح قدرات ذكاء اصطناعي مؤسسية مع مصادقة مناسبة ودون تغييرات في كود الخادم.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة القول

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

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

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

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

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

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

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

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

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

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

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

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

aspire docs list

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

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

aspire docs search "redis"

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

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

aspire docs get redis-integration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة القول

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

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

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

إطار عمل 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.

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