من Prompt Engineering إلى Loop Engineering

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

النموذج يستطيع أن يفكر، ويكتب، ويبرمج، ويبحث، لكنه في النهاية ينتظر منك أن تقول له: والآن؟

هذه الجملة قد تكون أهم شيء يتغير مع الـAgents، لأن الـAI بدأ يتعلم شيئا مختلف أن يكمل العمل من دون أن ينتظر السؤال التالي.

ولأن هذا التحول يحدث على مراحل، سأمر على أربع صور للحلقة Loop، من أبسطها إلى أكثرها استقلالية. والسؤال الذي يفرق بينها واحد ما الذي تسلمه للـAgent في كل مرة؟

سنتحدث عن اربع انواع لل و للـLoop وكل نوع خاص يحالة معينة

الحلقة التي تعتمد على الدور أنت تسلمه العمل، وتحتفظ بالتحقق

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

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

هذه أبسط حلقة ممكنة، وهي مناسبة تماما للمهام القصيرة وغير المتكررة. عيبها الوحيد أن التحقق ما زال في رأسك أنت

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

الخطوة الأولى لتحسينها ليست Prompt أطول، بل نقل خطوات التحقق التي تفعلها يدويا إلى Skill، حتى يفحص الوكيل عمله بنفسه: شغل الخادم، افتح الصفحة، اضغط الزر، تأكد أن الـConsole نظيف، قس الأداء. وكلما كان الفحص رقميا، كان أسهل عليه أن يحكم على نفسه.

الحلقة التي تعتمد على الهدف: أنت تسلمه شرط التوقف

كل ما سبق يمكن اختصاره في جملة واحدة: حسن أداء الموقع حتى تصل النتيجة إلى 90، وتوقف بعد خمس محاولات.

هنا تغير شيء مهم لم تعد تعطيه خطوات، بل أعطيته هدفا. ولم يعد هو من يقرر متى يكفي.

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

وهذه في رأيي أهم نقطة في الموضوع كله: يجب أن تعطي الـAI طريقة ليحكم على عمله. إذا طلبت منه تحسين الكود، ما معنى «تحسين»؟ وإذا طلبت منه إصلاح مشكلة، كيف يعرف أنها انحلت؟ وإذا طلبت منه رفع الجودة، ما الرقم الذي يعني أن المهمة انتهت؟

بدل «حسن الكود» تقول: اجعل جميع الاختبارات تمر، وارفع التغطية إلى 90%، ثم توقف. الفرق بين الجملتين ليس في طول الـPrompt، بل في أن الثانية أعطته تعريفا للنجاح.

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

الحلقة التي تعتمد على الوقت: أنت تسلمه المشغل

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

المهمة نفسها لا تتغير، المتغير هو المدخلات. وتتوقف الحلقة حين تلغيها أنت أو حين ينتهي العمل نفسه.
المهمة نفسها لا تتغير، المتغير هو المدخلات. وتتوقف الحلقة حين تلغيها أنت أو حين ينتهي العمل نفسه.

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

الحلقة الاستباقية: أنت تسلمه الطلب نفسه

ماذا لو لم يحتج الـAgent إلى وقت محدد أصلا؟ ماذا لو كان هناك حدث يبدأ العمل؟ وصل Bug جديد، أو Pull Request، أو تغيرت بيانات، أو ظهر تنبيه، أو وصلت رسالة.

يمكن للحدث أن يشغل الـAgent: يقرأ ما حدث، ويحلله، وينفذ المهمة، ويفحص النتيجة، ثم يتوقف، دون أن يكون هناك شخص جالس أمام الشاشة ينتظر ليكتب Prompt.

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

عند هذه النقطة لم يعد الـAgent مجرد أداة، بل أصبح جزءا من النظام نفسه.

لكن الاستقلالية لها ثمن

كلما أعطيت الـAgent حرية أكبر، أصبحت جودة النظام المحيط به أهم، لأن الـAgent الجيد داخل نظام سيئ قد ينتج نتائج سيئة. إذا لم يعرف كيف يتحقق سيعلن النجاح مبكرا، وإذا لم يكن لديه حد للمحاولات قد يستمر بلا نهاية، وإذا لم تكن لديه أدوات مناسبة سيحاول حل المشكلة بالطريقة الخطأ، وإذا لم يعرف متى يتوقف فسيستمر فقط لأنه يستطيع الاستمرار.

لذلك لم يعد بناء الـAgent مجرد اختيار نموذج أقوى، بل تصميم البيئة التي يعمل فيها:

• ما الذي يستطيع الوصول إليه، وما الذي يستطيع تغييره؟

• كيف يختبر، وكيف يعرف أنه نجح؟

• ما الحد الأقصى للمحاولات، وما الذي يحدث إذا فشل؟

• من يراجع عمله؟ وكيل ثانٍ بسياق نظيف يكون أقل انحيازا، لأنه لم يمر بالتفكير الذي أوصل الأول إلى نتيجته.

وابدأ من الأبسط دائما. ليست كل مهمة تحتاج حلقة معقدة.

أصلح النظام، لا الخطأ

لو ارتكب الـAgent خطأ مرة واحدة، يمكنك إصلاح الخطأ. لكن إذا ارتكب الخطأ نفسه مرة ثانية وثالثة، فالمشكلة لم تعد في المخرجات، بل في الـLoop.

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

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

وهنا تدخل التكلفة

الـLoop التي تجعل الـAgent يعمل عشر مرات ستستهلك أكثر من Agent يعمل مرة واحدة، ولو كانت كل محاولة تستدعي Agents أخرى فقد تتضاعف التكلفة بسرعة.

لذلك ليست الفكرة أن تجعل الـAI يعمل إلى الأبد، بل أن تجعله يعمل حتى ينجز المهمة:

• إذا كان بالإمكان تنفيذ خطوة بسيطة بـScript، فلا داعي لأن يفكر فيها Agent في كل مرة.

• إذا كان الهدف واضحا، فلا حاجة إلى Workflow معقد.

• إذا كانت المهمة تحتاج فحصا كل ساعة، فلا تجعلها تعمل كل دقيقة.

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

الـLoop الجيدة ليست الأطول، بل الأقصر التي توصل إلى النتيجة بثقة.

من Prompt Engineering إلى Loop Engineering

لفترة طويلة كان السؤال: كيف نكتب Prompt أفضل؟ ثم ظهر الـAgent فأصبح السؤال: كيف نجعل النموذج يستخدم الأدوات وينفذ المهمة؟ والآن يظهر سؤال مختلف: كيف نجعل النظام يستمر في العمل حتى يحقق النتيجة؟

الأول يحاول تحسين ما تقوله للنموذج، والثاني يحاول تحسين ما يحدث بعد أن تقوله. وهذا في رأيي أهم، لأن المستقبل لن يكون بالضرورة Agent واحدا خارقا يعرف كل شيء، بل مجموعة من الـAgents لكل واحد منها دور: واحد ينفذ، وآخر يختبر، وآخر يراجع، والنظام يقيس ثم يقرر هل يعيد المحاولة أم يتوقف.

وهنا تصبح قوة النظام أقل ارتباطا بالـPrompt الذي كتبته، وأكثر ارتباطا بالهندسة التي بنيتها حوله.

من أين تبدأ

انظر إلى عملك اليومي، واختر مهمة واحدة أنت فيها عنق الزجاجة، ثم اسأل: أي جزء يمكنني تسليمه؟

هل أستطيع كتابة فحص التحقق؟ إذن ابدأ بـSkill. هل الهدف واضح وقابل للقياس؟ إذن ابدأ بـ/goal. هل العمل يصلك على جدول؟ إذن ابدأ بـ/loop. ثم شغل الحلقة، وراقب أين تتعثر وأين تزيد عن حدها، ولا تتردد في تعديلها.

قديما كنا نسأل: ماذا أقول للـAI؟ ثم أصبحنا نسأل: ماذا أطلب من الـAgent؟ والسؤال القادم: كيف أبني نظاما لا يحتاج أن أطلب منه في كل مرة؟

هذه هي اللحظة التي يتوقف فيها الـAI عن انتظارك. ليس لأنه أصبح مستقلا بالكامل، بل لأنك أعطيته شيئا أهم من التعليمات: هدف، وأدوات، وطريقة ليتحقق، وسببا ليعيد المحاولة، وشرطا واضحا ليتوقف.

وعندها فقط يبدأ الـAI بالعمل بدلا منك، وليس معك فقط.

Originally published on X.