Multi-Agent | The .NET Blog

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

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

إطار عمل 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. اطّلع على دليل البدء السريع والأمثلة للبدء عملياً.

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