الذكاء الاصطناعي

ميتا تكشف كيف بنّت تطبيق Forum بالاعتماد على وكلاء الذكاء الاصطناعي

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

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 15 أكتوبر 2026 · آخر تحديث: 15 أكتوبر 2026 · 5 دقائق قراءة

ميتا تكشف كيف بنّت تطبيق Forum بالاعتماد على وكلاء الذكاء الاصطناعي — الصورة: Meta Engineering

تطبيق Forum كنموذج تجريبي للهندسة الذكية

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

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

من الإشراف المباشر إلى الإشراف على الحلقة

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

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

التحقق الآلي كشرط أساسي للمضي قدماً

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

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

إعادة هيكلة البنية التحتية لدعم الوكلاء

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

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

عزل النماذج الأولية لضمان أمان الإنتاج

مع اقتراب تطبيق Forum من مرحلة الإنتاج، واجه الفريق تحدياً يتعلق بأمان النماذج الأولية. أرادوا مساحة لتجارب الوكلاء والأكواد التجريبية دون التأثير على استقرار التطبيق النهائي. بدلاً من الاعتماد على البوابات المميزة (Feature Gating) التي تترك الكود التجريبي موجوداً في حزمة الإنتاج، طوروا نكهة بناء منفصلة. هذا التطبيق العازل يشارك نفس قاعدة الكود والأنظمة التصميمية مع الإنتاج، لكنه يستبعد كود النموذج الأولي من حزمة البناء النهائية، مما يوفر ضماناً قوياً لأمان التطبيق المستخدم فعلياً.

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