كيف يبني وكيل الذكاء الاصطناعي تطبيقًا عمليًا عبر MCP: تحليل خطوة بخطوة

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

مسارَان لبناء التطبيقات بالذكاء الاصطناعي

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

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

كيف بنى الوكيل النظام

تبدأ المهمة كتعريف باللغة الطبيعية. في هذا التشغيل، وصف تعريف من نحو 1400 كلمة نظام استدعاءات المنتجات لشركة تصنيع: لوحة عامة بمؤشرات أساسية، وصفحة حالة تتابع استدعاءً واحدًا من الاكتشاف حتى الإغلاق، وسجل لإجراءات الاستجابة عبر كل الاستدعاءات. كانت التعليمات الرئيسية بسيطة عن قصد: ابنِ التطبيق، وحافظ على اتساق البيانات في كل الصفحات، وتحقّق من كل مرحلة قبل الانتقال إلى التالية.

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

البناء على مراحل مُتحقَّق منها

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

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

لماذا انخفض استهلاك الرموز عبر البناء

خلال البناء أظهر عدّاد الميزانية التقريبي نمطًا دالًّا. استهلك أول دور كبير — التخطيط ونموذج البيانات والصفحة الأولى — نحو 190 ألف رمز: إذ كان على الوكيل قراءة مراجع المنصّة وفهم عقود المكوّنات وتحديد بنية التطبيق. أما الصفحة الثانية وتعديلاتها فقد كلّفت نحو 84 ألفًا، وكلّف تكرار الصفحة الثالثة اللاحق نحو 51 ألفًا.

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

بعد البناء يبقى التطبيق عاديًا

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

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

ماذا يعني ذلك للفرق

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

يمكنك بناء مشروعك الخاص من وصف والاستمرار في العمل عليه في قسم «الكود».

المصدر: تحليل ToolJet MCP على dev.to.