وكلاء الذكاء الاصطناعي ببساطة: كيف يخطط الوكيل ويبني ويختبر البرمجيات

من روبوت محادثة إلى وكيل: ما الفرق؟

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

كلاهما يعتمد على نموذج لغة كبير (LLM) في الأساس. الفرق ليس في «ذكاء» النموذج بقدر ما هو في النظام المحيط به: الوكيل يملك أدوات يستطيع استخدامها، وذاكرة لما فعله، وحلقة عمل تسمح له بالمحاولة والتصحيح. إن أردت فهم النماذج نفسها أولاً، اقرأ دليل النماذج اللغوية لأصحاب الأعمال.

تخيّل الفرق بين أن تسأل صديقاً مهندساً عن طريقة تركيب رف، وبين أن تستأجر فنياً يأتي بأدواته ويركّب الرف ويتأكد أنه ثابت. الأول يعطيك معلومة، والثاني يسلّمك نتيجة. هذا بالضبط ما تغيّر في عالم البرمجيات: لم يعد السؤال «ماذا يعرف النموذج؟» فقط، بل «ماذا يستطيع أن يفعل، وكيف يتأكد أن ما فعله صحيح؟».

حلقة الوكيل: فهم، تخطيط، تنفيذ، ملاحظة

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

1. 1
   فهم الهدف

   يقرأ الوكيل طلبك ويحاول استخراج المطلوب: من المستخدم؟ ما الشاشات؟ ما القيود؟ إن كان شيء غامضاً، يسأل الوكيل الجيد قبل أن يبدأ بدل أن يخمّن.

2. 2
   التخطيط

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

3. 3
   التنفيذ بالأدوات

   لكل مهمة يختار الوكيل الأداة المناسبة: كتابة ملف، تشغيل أمر، استعلام قاعدة بيانات، فتح الصفحة في متصفح. هذا ما يسمى استدعاء الأدوات (Tool Calling).

4. 4
   الملاحظة

   بعد كل خطوة يقرأ الوكيل النتيجة: هل نجح البناء؟ هل ظهرت رسالة خطأ؟ هل اجتازت الاختبارات؟ هذه الملاحظة هي ما يميز الوكيل عن مجرد مولّد نصوص.

5. 5
   التصحيح أو المتابعة

   إن فشلت الخطوة، يحلل السبب ويجرب حلاً آخر. وإن نجحت، ينتقل إلى المهمة التالية في الخطة، حتى يكتمل الهدف أو يصل إلى نقطة تحتاج قرارك.

الوكيل الجيد لا يُقاس بأنه لا يخطئ، بل بأنه يلاحظ خطأه ويصلحه.

لاحظ أن الحلقة تتكرر عشرات المرات في مشروع واحد. لهذا قد يستغرق الوكيل دقائق في مهمة يبدو لك أنها بسيطة: هو لا يكتب فقط، بل يكتب ثم يشغّل ثم يقرأ ثم يعدّل.

الأدوات: ما الذي يستطيع الوكيل لمسه فعلاً؟

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

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

كيف يبني الوكيل تطبيقاً من البداية إلى النهاية

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

1. التوضيح والخطة

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

2. البناء طبقة بطبقة

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

3. الاختبار

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

4. النشر والمتابعة

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

أين يخطئ الوكلاء؟

الوكلاء أدوات قوية، لكنهم ليسوا معصومين. معرفة أنماط الفشل الشائعة تساعدك على اكتشافها مبكراً:

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

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

لقائمة فحص كاملة قبل الإطلاق، راجع مقال هل تثق بالكود المولّد بالذكاء الاصطناعي؟.

الضوابط ونقاط المراجعة البشرية

الحل ليس أن تراقب كل سطر يكتبه الوكيل، بل أن يكون في النظام ضوابط (Guardrails) واضحة، ونقاط يتوقف عندها الوكيل لينتظر قرارك. هذه أهم الضوابط التي تستحق أن تسأل عنها في أي أداة:

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

كيف تعمل مع الوكيل بفعالية

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

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

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

لمزيد من الأمثلة والقوالب، اقرأ كيف تكتب أوامر تبني تطبيقات أفضل، وإن كنت جديداً على الفكرة كلها فابدأ بـ ما هو الـ Vibe Coding؟.

أسئلة تطرحها قبل اختيار أداة مبنية على الوكلاء

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

• هل يعرض الوكيل خطته وينتظر موافقتي قبل التغييرات الكبيرة؟
• هل يختبر ما يبنيه فعلاً، أم يكتفي بكتابة الكود؟
• هل أستطيع التراجع إلى أي نسخة سابقة بسهولة؟
• هل أملك الكود كاملاً وأستطيع تصديره إلى GitHub؟
• هل يفهم طلباتي بالعربية ويبني واجهة RTL صحيحة؟
• هل يدعم الدفع المحلي وتسجيل الدخول بالجوال دون تكاملات معقدة؟
• أين تُستضاف بياناتي، وهل توجد خيارات استضافة داخل المنطقة؟

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

أسئلة شائعة

مصطلحات في هذا المقال