Google وTambo وGenUI: ثلاثة أساليب لواجهات AI تُبنى لحظيًا

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

كيف تختلف واجهات المستخدم التوليدية

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

« الواجهة متغيرة جداً بحيث لا يمكن ترميز جميع الحالات مسبقاً. »

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

الفكرة هنا ليست لجعل الواجهة أكثر تأثيراً، بل لتقليل الحمل المعرفي غير الضروري وتسريع العمل مع الرد.

ثلاثة نماذج للتجميع

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

الطريق الأكثر وضوحاً هو السماح للنموذج بإنشاء HTML وعرضه مباشرة في المتصفح. هذا سريع للنموذج الأولي، لكن في الإنتاج هذا الخيار هش: يكسر النموذج بسهولة نظام التصميم، يخترع سمات غير موجودة ويثير مخاوف أمان إضافية.

• توليد HTML — أقصى حرية للنموذج، حد أدنى من التحكم لفريق المنتج.
• النهج الإعلاني — يصف الوكيل الواجهة عبر JSON وقاموس المكونات، ويعيد العميل تقديمها داخل مجموعة UI الخاصة به.
• اختيار المكون الجاهز — لا يقوم الوكيل بترميز الواجهة بل يستبدل البيانات في بطاقات وأشكال وجداول معدة مسبقاً.

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

الخيار الأكثر قابلية للتحكم هو مكتبة المكونات الجاهزة: النموذج له حرية أقل، لكن الواجهة تبقى قابلة للتنبؤ. هذا النهج أقل ملاءمة لعدد لا نهائي من السيناريوهات، لكنه يعمل بشكل أفضل حيث تكون UX أكثر أهمية من الارتجال.

لماذا تم اختيار Tambo

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

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

نتيجة لذلك، اختارت المؤلفة Tambo — إطار عمل مفتوح المصدر لـ React يعمل بنموذج المكون الجاهز ويضيف دورة الحياة والحالات والاتصال ثنائي الاتجاه بين UI والوكيل عبر AG-UI. يتم تسجيل المكونات مع الأوصاف وأنماط Zod للدعائم، وبعد ذلك يختار الوكيل ما يجب عرضه ويمكنه بث البيانات إلى المكون في الوقت الفعلي.

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

ماذا يعني هذا

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