AI Agents | The .NET Blog

Microsoft Agent Framework الجزء الثالث: من الأدوات إلى سير العمل — تتشابك قطع البناء في مكانها

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

إذا كنت تتابع سلسلة Building Blocks for AI في .NET، فأنت تعلم: الجزء الأول أعطانا IChatClient (الواجهة العالمية للنماذج)، والجزء الثاني أعطانا Microsoft.Extensions.VectorData (البحث الدلالي وRAG). كلاهما أساسي ومفيد بمفرده. لكن هنا يبدأ كل شيء في الاتصال ببعضه.

الجزء الثالث عن Microsoft Agent Framework — وبصراحة، هذه القطعة التي كنت أنتظر رؤيتها في .NET. الإصدار 1.0 شُحن في أبريل. الواجهة البرمجية مستقرة. حان وقت بناء وكلاء حقيقيين.

ما هو الوكيل فعلاً (مقابل روبوت المحادثة)

قبل الخوض في الكود، لنوضح هذا التمييز. روبوت المحادثة يستقبل المدخلات، يستدعي النموذج، يُعيد المخرجات. حلقة بسيطة.

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

فكر في الأمر هكذا: IChatClient كإجراء محادثة. الوكيل كتفويض قائمة مهام لشخص ما.

وكيلك الأول في 10 أسطر

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

أسلوب التمديد .AsAIAgent() هو الجسر. نفس النمط مثل .AsIChatClient() من MEAI — يلف SDK الموفر في تجريد مستقر. يعمل مع Azure OpenAI وOpenAI وGitHub Models وMicrosoft Foundry أو النماذج المحلية.

البث يعمل أيضاً:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

إعطاء الأدوات للوكيل

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

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

شيئان يستحقان الملاحظة. أولاً، AIFunctionFactory من MEAI — نفس مصنع الأدوات الذي ستستخدمه مع IChatClient العادي. إذا عرّفت أدوات لسيناريوهات الدردشة بالفعل، فهي تعمل هنا أيضاً.

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

الجلسات: محادثات تتذكر فعلاً

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

بدون جلسة، كل استدعاء RunAsync عديم الحالة. مع الجلسة، الوكيل يعرف النكتة التي تشير إليها. AgentSession يحافظ على تاريخ المحادثة بين الأدوار.

للخدمات عديمة الحالة في الإنتاج، الجلسات تُسلسَل بشكل نظيف:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... خزّنه في مكان ما ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

هذا أمر بالغ الأهمية إذا كان وكيلك يعمل في بيئة serverless أو مُوسَّعة أفقياً.

AIContextProvider: ذاكرة دائمة عبر الجلسات

الجلسات تحافظ على تاريخ المحادثة داخل جلسة. ولكن ماذا عن معرفة أشياء عن مستخدم عبر الجلسات؟ AIContextProvider يتعامل مع ذلك.

له خطافان:

ProvideAIContextAsync — يعمل قبل كل تفاعل، يحقن سياقاً في الوكيل
StoreAIContextAsync — يعمل بعد كل تفاعل، يتيح التعلم والاستمرارية

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

سير عمل متعدد الوكلاء

هنا يستحق الإطار اسمه. يتضمن نظام سير عمل قائم على الرسم البياني حيث يتصل المنفذون (الوكلاء، الوظائف، أياً كان) عبر الحواف.

بعض الأنماط المدعومة أصلاً:

تسلسلي: مخرجات الوكيل A تغذي الوكيل B
متزامن (توزيع/تجميع): الإرسال إلى وكلاء متعددين بالتوازي وتجميع النتائج
توجيه مشروط: توجيه العمل إلى وكلاء مختلفين بناءً على المخرجات
حلقات الكاتب-الناقد: وكيل يكتب، آخر يقيّم، حلقة حتى الموافقة
سير عمل فرعية: تأليف سير العمل بشكل هرمي

مثال الكاتب-الناقد:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

نظيف، مقروء، والتوجيه القائم على الشروط يعني أنك لا تكتب منطق الحلقة بنفسك.

الإنسان في الحلقة

لا ينبغي أن يعمل كل شيء باستقلالية كاملة. للعمليات الحساسة — الكتابة في قواعد البيانات، المعاملات المالية، إرسال الاتصالات — تريد أن يوافق إنسان قبل أن ينفذ الوكيل.

يحتوي الإطار على دعم مدمج لهذا عبر FunctionApprovalRequestContent وFunctionApprovalResponseContent. الوكيل يقترح استدعاء الأداة، كود تطبيقك يعرضه للمستخدم، والاستجابة تحدد ما إذا كان التنفيذ يستمر.

هذه هي الطريقة الصحيحة للتفكير في الوكلاء في البيئات المؤسسية: ليس مستقلاً بالكامل، بل استقلالية بضوابط.

الصورة الكاملة

إذا تراجعت خطوة للخلف:

MEAI يمنحك واجهة عالمية لأي نموذج
VectorData يمنح وكلاءك الوصول إلى معرفة مؤسستك عبر البحث الدلالي
Agent Framework ينسق كل شيء — يستخدم IChatClient داخلياً، يتكامل مع موفري السياق، وينسق عبر سير العمل

كل قطعة صُممت لتتكامل مع الأخريات. راجع المنشور الأصلي لـ Jeremy Likness ومستودع GitHub لـ Agent Framework للحصول على الأمثلة الكاملة.

الخلاصة

منشور الجزء الثالث من Microsoft Agent Framework يُغلق حلقة سلسلة Building Blocks. لمطوري .NET الذين يريدون بناء وكلاء الذكاء الاصطناعي — ليس فقط روبوتات المحادثة، بل وكلاء حقيقيين يستخدمون الأدوات ويتذكرون الأشياء وينسقون — هذا هو طريقك للأمام.

الإصدار المستقر 1.0 يعني أنه يمكنك البناء بهذا في الإنتاج. إذا كنت تنتظر للقفز في تطوير الوكلاء في .NET، فالوقت الآن مناسب.

خادم SQL MCP على Azure App Service — بدون حاويات

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

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

لهذا السبب استرعى هذا انتباهي. يمكن لخادم SQL MCP الآن العمل على Azure App Service — بدون Docker، بدون Kubernetes، فقط مع نفس ملف تكوين Data API Builder (DAB) الذي يكشف قاعدة بيانات SQL الخاصة بك عبر MCP وREST وGraphQL.

ما هو خادم SQL MCP؟

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

مبني على Data API Builder، مما يعني أن ملف تكوين واحد يدير MCP و REST و GraphQL في آنٍ واحد. يتحدث وكيلك مع نقطة نهاية MCP. يتحدث تطبيقك التقليدي مع REST أو GraphQL. نفس التكوين، نفس بيئة التشغيل، واجهات مختلفة.

هذا مفيد حقاً — لا داعي للحفاظ على طبقتي API منفصلتين.

مشكلة الحاوية (والحل)

استخدم نموذج النشر الأصلي لخادم SQL MCP الحاويات. يعمل بشكل جيد في كثير من الفرق — لكن ليس في جميعها. تعتمد كثير من فرق .NET معياراً على Azure App Service أو الأجهزة الافتراضية. إلزام بيئة تشغيل حاويات فقط لكشف نقطة نهاية SQL يضيف احتكاكاً لم يطلبه أحد.

يُظهر الإرشاد الجديد كيفية تخطي الحاوية تماماً. كل شيء يعمل بأمر dab start، مستضافاً على App Service كعملية ويب .NET 8 قياسية.

# تثبيت Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# تهيئة التكوين
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# إضافة كيان
dab add products --source dbo.products --permissions "authenticated:*"

# تكوين موفر مصادقة App Service
dab configure --runtime.host.authentication.provider AppService

# تشغيل الخادم
dab start

عند هذه النقطة لديك MCP على /mcp، وREST وGraphQL من نفس العملية — ولا شيء يعمل في حاوية.

المصادقة بدون مفاتيح API مشتركة

هذا هو الجزء الذي أقدّره أكثر. عند النشر على App Service، تقوم بتكوين Microsoft Entra ID كموفر مصادقة. لا أسرار مشتركة في ملفات التكوين، ولا مفاتيح API للتدوير.

تبقى سلسلة الاتصال في متغيرات بيئة App Service (وليس في dab-config.json)، ونقطة نهاية MCP محمية بمصادقة المنصة. إذا كانت أحمال عمل Azure لديك متوافقة بالفعل مع Entra ID، فهذا يندمج بشكل طبيعي.

للتطوير المحلي، انتقل إلى وضع Simulator ونقل STDIO. عُد إلى وضع AppService قبل النشر. نظيف وصريح.

النشر على App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

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

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

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

راجع الإرشاد الكامل في المقالة الأصلية ومستودع العينات على GitHub.

الخلاصة

خادم SQL MCP على App Service خيار عملي لفرق .NET التي تريد منح وكلائها وصولاً منظماً إلى بيانات SQL بدون استراتيجية حاويات. جرّبه — سيقدّر وكلاؤك واجهة API النظيفة.

تحديث Visual Studio لأبريل: تكامل Cloud Agent لسير عمل .NET

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

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

Visual Studio April Update: Cloud Agent Integration for .NET Workflows يستحق اهتماماً دقيقاً إذا كنت تبني أو تشغّل أنظمة .NET على نطاق واسع.

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

لماذا يهمّ ذلك لفرق .NET

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

الخطوات العملية التالية

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

المصدر

المقالة الأصلية: https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/

حوكمة استدعاءات أدوات MCP في .NET باستخدام Agent Governance Toolkit

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

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

Governing MCP Tool Calls in .NET with the Agent Governance Toolkit يستحق اهتماماً دقيقاً إذا كنت تبني أو تشغّل أنظمة .NET على نطاق واسع.

لماذا يهمّ ذلك لفرق .NET

الخطوات العملية التالية

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

المصدر

المقالة الأصلية: https://devblogs.microsoft.com/dotnet/governing-mcp-tool-calls-in-dotnet-with-the-agent-governance-toolkit/