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

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