Agents | The .NET Blog

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

from azure.ai.agentserver.agentframework import from_agent_framework

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إطاري للقرار

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

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

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

خلاصة القول

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

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

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

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

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

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

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

ما هو Azure MCP Server؟

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

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

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

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

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

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

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

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

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

تحصين الأمان

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

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

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

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

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

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

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

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

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

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

البدء

اختر مسارك:

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

خلاصة القول

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة القول

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

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

هندسة المنصات الوكيلية تصبح حقيقة — Git-APE يُظهر كيف

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

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

كانت هندسة المنصات من تلك المصطلحات التي تبدو رائعة في محادثات المؤتمرات لكنها عادةً ما تعني “أنشأنا بوابة داخلية وغلافاً لـ Terraform.” الوعد الحقيقي — بنية تحتية ذاتية الخدمة آمنة فعلاً ومُحكَّمة وسريعة — كانت دائماً على بُعد خطوات.

نشر فريق Azure للتو الجزء الثاني من سلسلة هندسة المنصات الوكيلية، وهذا الجزء يتعلق بالتطبيق العملي. يطلقون عليه Git-APE (نعم، الاختصار مقصود)، وهو مشروع مفتوح المصدر يستخدم وكلاء GitHub Copilot بالإضافة إلى خوادم Azure MCP لتحويل الطلبات باللغة الطبيعية إلى بنية تحتية مُتحقَّق منها ومنشورة.

ما الذي يفعله Git-APE فعلاً

الفكرة الجوهرية: بدلاً من تعلّم المطوّرين وحدات Terraform، أو التنقل في واجهات المستخدم للبوابات، أو تقديم تذاكر إلى فريق المنصة، يتحدثون مع وكيل Copilot. يفسّر الوكيل النية، ويولّد البنية التحتية كأكواد، ويتحقق منها مقابل السياسات، وينشر — كل ذلك داخل VS Code.

إليك الإعداد:

git clone https://github.com/Azure/git-ape
cd git-ape

افتح مساحة العمل في VS Code، وتُكتشف ملفات إعداد الوكيل تلقائياً بواسطة GitHub Copilot. تتفاعل مع الوكيل مباشرةً:

@git-ape deploy a function app with storage in West Europe

يستخدم الوكيل Azure MCP Server خلف الكواليس للتفاعل مع خدمات Azure. يُمكّن إعداد MCP في إعدادات VS Code قدرات محددة:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

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

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

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

التنظيف بسيط بالقدر نفسه:

@git-ape destroy my-resource-group

رأيي

لأكن صريحاً — هذا يتعلق بالنمط أكثر من الأداة المحددة. Git-APE نفسه هو بنية مرجعية/توضيحية. لكن الفكرة الكامنة — الوكلاء كواجهة لمنصتك، وMCP كبروتوكول، وGitHub Copilot كمضيف — هي وجهة تجربة المطوّر في المؤسسات.

إذا كنت فريق منصة تبحث عن كيفية جعل أدواتك الداخلية صديقةً للوكلاء، فلا يوجد نقطة بداية أفضل. وإذا كنت مطوّر .NET تتساءل عن كيفية ارتباط هذا بعالمك: يعمل Azure MCP Server ووكلاء GitHub Copilot مع أي عبء عمل على Azure. واجهة برمجة ASP.NET Core، ومكدّس .NET Aspire، والخدمات المُعبّأة في حاويات — كل ذلك يمكن أن يكون هدفاً لتدفق نشر وكيلي.

خلاصة القول

Git-APE هو نظرة مبكرة لكن ملموسة على هندسة المنصات الوكيلية في التطبيق. استنسخ المستودع، وجرّب العرض التوضيحي، وابدأ في التفكير في كيفية احتياج واجهات برمجية منصتك وسياساتها للظهور حتى يستطيع الوكيل استخدامها بأمان.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

خلاصة القول

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

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

خدمة 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)

إذا كنت قادماً من حزمة azure-ai-agents، فإن الوكلاء أصبحوا الآن عمليات من الدرجة الأولى على AIProjectClient في azure-ai-projects. أزل التبعية المنفصلة واستخدم get_openai_client() لتشغيل الاستجابات.

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

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

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

Agents | The .NET Blog

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

ما هو CodeAct؟

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

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

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

جرّبه الآن

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

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

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

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

كيف تختار

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

ما هو Toolbox؟

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

مثال عملي

لا قيد على Foundry Agents

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

خلاصة

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

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

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

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

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

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

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

الخلاصة

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

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

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

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

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

إطاري للقرار

خلاصة القول

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

ما هو Azure MCP Server؟

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

تحصين الأمان

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

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

البدء

خلاصة القول

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

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

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

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

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

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

خلاصة

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

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

حل روابط CSS @import

خلاصة القول

هندسة المنصات الوكيلية تصبح حقيقة — Git-APE يُظهر كيف

ما الذي يفعله Git-APE فعلاً

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

رأيي

خلاصة القول

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

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

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

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

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

خلاصة القول

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

مبنية على Responses API

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

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

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

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

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

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

خلاصة

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