Aks | The .NET Blog

أين تستضيف وكلاء الذكاء الاصطناعي على 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 للحصول على أمثلة عملية.

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 — المنصة أصبحت للتوّ أكثر جاهزيةً للإنتاج بشكل ملموس.