الانتقال الحقيقي في استخدام وكلاء الذكاء الاصطناعي ليس أن تكتب prompt أطول، بل أن تصمّم Loop تجعل الوكيل يعرف متى يبدأ، ماذا يحاول أن يحقق، كيف يفحص نفسه، متى يقرر، ومتى يتوقف.
هذه هي النقلة المهمة في التعامل مع أدوات مثل Codex و Claude و Claude Code. بدل أن تبقى جالساً أمام الشاشة تعطي الوكيل أمراً بعد أمر، تبدأ ببناء نظام صغير يجعله يعمل باتجاه هدف واضح مع حدود أمان واضحة.
الفكرة ليست أن نترك الذكاء الاصطناعي يعمل بلا رقابة. العكس تماماً. الفكرة أن ننقل الرقابة من متابعة يدوية متعبة إلى هندسة مسبقة: هدف، تحقق، قرارات، ذاكرة، ميزانية، وشروط توقف.
شاهد الحلقة الكاملة على YouTube
لماذا لم يعد الـ prompting وحده كافياً؟
الطريقة التقليدية التي يستخدمها كثير من الناس اليوم واضحة: تفتح Codex أو Claude، تكتب prompt، تنتظر الرد، تجرب النتيجة، تلاحظ مشكلة، ترجع تكتب prompt جديد، ثم تكرر العملية.
هذه الطريقة ستبقى مهمة. لن تختفي. لكنها تصبح محدودة عندما يكون لديك عمل متكرر، أو فحوصات كثيرة، أو خطوات تحتاج قراراً بعد كل نتيجة.
هنا يظهر معنى Loop Engineering. أنت لا تطلب من الوكيل أن ينفذ خطوة واحدة. أنت تبني له حلقة عمل: يبدأ عند حدث معين، يحاول تحقيق هدف، يفحص مخرجاته، يقرر الخطوة التالية، ثم يكرر أو يتوقف حسب شروط محددة.
هذا التحول يهم المطورين، وصنّاع الأدوات، وأي شخص يستخدم AI Agents بكثافة. لأنه ينقل جزءاً من الشغل من “أنا أتابع كل خطوة” إلى “أنا صممت طريقة المتابعة مسبقاً”.
Loop Engineering ليس Automation باسم جديد
من الأخطاء الشائعة أن نخلط بين Loop و Automation. التشابه موجود، لكن الفرق جوهري.
الـ Automation غالباً تبدأ بـ trigger وتنتهي بمخرج عبر خطوات ثابتة. إذا حدث هذا الشيء، نفّذ هذه السلسلة. المسار معروف مسبقاً، والتصرفات محددة.
أما الـ Loop فهي أقرب إلى نظام قرار. يوجد trigger أيضاً، لكن بعده يعمل الوكيل باتجاه هدف، ويفحص هل اقترب من الهدف أم لا، ثم يأخذ قراراً بناءً على المخرجات.
قد يكرر المحاولة. قد يغير الطريقة. قد يطلب موافقة بشرية. قد يوقف نفسه لأنه وصل إلى الحد الأقصى من المحاولات. وقد يكتب تقريراً يشرح لماذا لم ينجح.
بمعنى عملي: Automation تنفذ مساراً. Loop تطارد هدفاً ضمن حدود.
البنية الأساسية لأي Loop ناجحة
إذا أردت بناء Loop مفيدة مع Codex أو Claude، لا تبدأ بالسؤال: “ما هو prompt المناسب؟” ابدأ بالسؤال: “ما هي بنية الحلقة؟”
كل Loop قوية تحتاج عدداً من المكونات الواضحة. وكل مكون يحميك من نوع مختلف من الفوضى.
1. Trigger واضح: ما الذي يبدأ الحلقة؟
الـ trigger هو الحدث الذي يوقظ الوكيل. قد يكون يدوياً، مثل أن تكتب له عبارة معينة. وقد يكون مجدولاً، مثل task تعمل كل يوم. وقد يكون حدثاً تقنياً، مثل push على GitHub أو رسالة بريد تحمل عنواناً معيناً.
من دون trigger واضح، ستبقى الحلقة فكرة ضبابية. أما عندما تحدد “متى تبدأ”، تبدأ هندسة السلوك فعلياً.
2. هدف قابل للتحقق: كيف نعرف أننا نجحنا؟
الهدف هو قلب الـ Loop. وكلما كان الهدف أوضح، أصبح الوكيل أقدر على العمل باستقلالية.
لا تقل له: “حسّن المشروع”. هذا هدف واسع جداً. قل له مثلاً: “تحقق أن عملية deployment انتهت بنجاح، وأن الصفحة الرئيسية تعمل، وأنه لا توجد أخطاء حرجة في logs”.
الهدف الجيد ليس بالضرورة أن يكون مثالياً أو رقمياً بالكامل، لكنه يجب أن يسمح للوكيل أن يجيب على سؤال بسيط: هل تحقق الهدف أم لا؟
3. طريقة تحقق: ما الدليل الذي يعتمد عليه الوكيل؟
لا يكفي أن تعطي الوكيل هدفاً. يجب أن تعطيه طريقة فحص الهدف.
مثلاً: افحص status الخاص بالـ deployment، افتح رابط الموقع، راقب رسائل الخطأ، شغّل tests محددة، ثم لخّص النتائج. هذه ليست تفاصيل جانبية؛ هذه هي الآلية التي تمنع الوكيل من التخمين.
كلما كانت أدلة التحقق أوضح، قلّت احتمالية أن يعتبر الوكيل أن العمل انتهى وهو لم ينتهِ فعلاً.
4. Decision Gates: ماذا يفعل عند كل نتيجة؟
بوابة القرار هي النقطة التي تقول فيها للوكيل: إذا رأيت هذه النتيجة، افعل هذا. وإذا رأيت نتيجة أخرى، افعل شيئاً مختلفاً.
مثلاً: إذا نجح deployment، اكتب تقريراً وتوقف. إذا فشل بسبب خطأ واضح في الكود، حاول إصلاحه مرة واحدة. إذا فشل بسبب صلاحية أو إعداد إنتاجي، توقف واطلب موافقة بشرية.
هذه البوابات هي الفرق بين وكيل يكرر عشوائياً ووكيل يعمل داخل منطق واضح.
5. شروط توقف: متى يجب أن تنتهي الحلقة؟
شرط التوقف ليس رفاهية. هو جزء أمني أساسي.
Loop بلا شرط توقف قد تستمر في الدوران، تستهلك tokens، وتنتج محاولات كثيرة بلا قيمة. لذلك يجب أن تحدد متى يتوقف الوكيل: عند تحقق الهدف، عند الوصول إلى عدد محاولات معين، عند عدم تحسن النتيجة، أو عند ظهور حالة تحتاج إنساناً.
أحياناً يكفي شرط بسيط: “إذا حاولت ثلاث مرات ولم يتغير المخرج، توقف واكتب تقريراً”. هذا الشرط وحده قد يحميك من ساعات من الدوران غير المفيد.
الذاكرة والملفات: لماذا تحتاج Loop إلى مكان تعيش فيه؟
بما أن الـ Loop قد تعمل على أكثر من لفة، فهي تحتاج ذاكرة. لا تريد من الوكيل أن يبدأ كل مرة وكأنه لا يعرف ما حدث في المحاولة السابقة.
لهذا من المفيد أن تحدد target folder أو مساحة عمل واضحة. هناك يمكن أن يكتب الوكيل logs، ملاحظات، نتائج فحوصات، تقارير، أو ملفات حالة.
هذه الذاكرة تسمح له أن يعرف: ماذا جربت؟ ماذا فشل؟ ماذا تغير؟ وما القرار التالي المنطقي؟
وهنا يبدأ جزء مهم من التفكير في self-improving systems. إذا كانت الحلقة تجمع الملاحظات والنتائج، فيمكن لاحقاً أن تستخدم هذه المعرفة لتحسين طريقة عملها في كل مرة.
لكن هذا لا يعني أن تتركها تعدّل نفسها بلا حدود. التحسين الذاتي يحتاج حدوداً أوضح، وليس حدوداً أقل.
الأدوات والصلاحيات: لا تعطِ الوكيل مفاتيح كل شيء
كل AI Agent يعمل من خلال أدوات ومهارات وصلاحيات. وقد تكون هذه الأدوات بسيطة مثل قراءة الملفات، أو حساسة مثل تعديل الكود، تشغيل أوامر، إرسال إيميلات، أو التعامل مع أنظمة خارجية.
في Loop Engineering، يجب أن تحدد بوضوح ما هو المسموح وما هو الممنوع.
هل يستطيع الوكيل تعديل الملفات؟ هل يستطيع عمل commit؟ هل يستطيع تشغيل deployment؟ هل يستطيع حذف ملفات؟ هل يستطيع إرسال رسالة إلى شخص؟ هل يستطيع استخدام أدوات خارجية؟
هذه الأسئلة ليست بيروقراطية. هي guardrails. وهي الفرق بين تجربة ممتعة ونظام قد يخرب شيئاً لا تريد أن يقترب منه.
القاعدة العملية: أعطِ الوكيل أقل صلاحيات تكفي لتحقيق الهدف. ثم وسّعها فقط عندما تعرف لماذا تحتاج ذلك.
مثال عملي: اجعل Codex يراقب الـ deployment بدلاً منك
تخيل أنك تعمل على موقع أو أداة، وكلما دفعت الكود إلى GitHub يبدأ deployment. في العادة، ماذا تفعل؟ تفتح منصة النشر، تراقب العملية، تنتظر، تفتح الموقع، تتأكد أن كل شيء يعمل.
هذه مهمة مناسبة جداً لـ Loop لأنها متكررة، ولها trigger واضح، وهدف واضح، وأدلة تحقق واضحة.
الـ trigger يمكن أن يكون push على branch معين. الهدف: التأكد أن deployment انتهى بنجاح وأن الموقع يعمل. التحقق: فحص status، قراءة logs، فتح صفحات محددة، وربما تشغيل checks بسيطة.
ثم تأتي بوابات القرار. إذا كل شيء ناجح، يكتب الوكيل تقريراً قصيراً ويتوقف. إذا ظهر خطأ معروف، يحاول إصلاحه ضمن حدود. إذا ظهر خطأ غير واضح أو يحتاج صلاحية حساسة، يوقف الحلقة ويطلب موافقتك.
بهذا الشكل، أنت لم تجعل Codex “يفعل كل شيء”. أنت جعلته يعمل داخل نظام واضح. وهذا هو جوهر Loop Engineering.
Human in the loop: متى يجب أن يدخل الإنسان؟
أحياناً تكون النتيجة غير مؤكدة. الوكيل قد يقول: “أنا واثق بنسبة جيدة أن الهدف تحقق”، لكنه لا يملك دليلاً قاطعاً. أو قد يواجه قراراً له أثر كبير: حذف ملف، تعديل إعداد إنتاجي، إرسال رسالة، أو تغيير شيء حساس.
هنا تحتاج Human Approval Gate.
ببساطة: إذا وصل الوكيل إلى حالة معينة، يتوقف ويطلب موافقة بشرية. قد تكون الموافقة داخل الأداة نفسها، أو عبر رسالة، أو بأي آلية تبنيها في النظام.
هذه ليست عودة إلى المتابعة اليدوية القديمة. أنت لا تراجع كل خطوة. أنت تدخل فقط عند نقاط القرار التي تستحق تدخلك.
وهذا التوازن مهم: استقلالية في العمل المتكرر، ورقابة بشرية عند المخاطر أو عدم اليقين.
متى تستخدم Loop؟ ومتى لا تستخدمها؟
استخدم Loop عندما يكون لديك هدف واضح يمكن قياسه أو التحقق منه، وعندما تكون المهمة متكررة بما يكفي لتستحق الهندسة، وعندما تستطيع وضع guardrails وصلاحيات محدودة.
استخدمها أيضاً عندما تستطيع تعريف دليل النجاح: تقرير، checklist، نتيجة test، status، log، أو مقارنة واضحة بين قبل وبعد.
لكن لا تستخدم Loop لمجرد أن المصطلح جذاب.
إذا كان الهدف ضبابياً، لا تبنِ Loop. إذا لم تعرف كيف يتحقق الوكيل من النجاح، لا تبنِ Loop. إذا كنت ستعطيه صلاحيات مفتوحة جداً من البداية، لا تبنِ Loop بشكل احترافي قبل أن تضبط الحدود.
ولا تبنِ Loop إذا لم تكن تعرف متى يجب أن تتوقف.
الفن هنا ليس أن تجعل الوكيل يعمل وحده فقط. الفن أن تجعله يعمل وحده إلى أن يصل إلى نقطة واضحة: نجاح، فشل مفهوم، حاجة لموافقة، أو توقف آمن.
Loop Builder: لماذا تحتاج مساعداً لبناء الحلقة نفسها؟
واحدة من الأفكار العملية في الحلقة هي استخدام مهارة أو طريقة تساعد Codex أو Claude على بناء الـ Loop معك، بدلاً من أن تحاول تذكر كل المكونات وحدك.
الفكرة أن تطلب من الوكيل ألا يبدأ التنفيذ مباشرة، بل أن يسألك الأسئلة الصعبة أولاً: ما الهدف؟ ما trigger؟ ما أدوات التحقق؟ ما الصلاحيات؟ ما شروط التوقف؟ متى تحتاج موافقة بشرية؟ أين تُحفظ الذاكرة؟ ما حدود استهلاك tokens؟
هذا الأسلوب يغيّر العلاقة مع الوكيل. بدل أن يكون منفذاً فورياً، يصبح شريك تصميم يساعدك على هندسة نظام العمل قبل تشغيله.
وهذا مهم جداً لأن أغلب مشاكل الـ Loops لا تظهر لأن الوكيل ضعيف، بل لأننا لم نوضح له النظام الذي يجب أن يعمل داخله.
المدخل الحقيقي إلى self-improving agents
الفكرة الأكثر تقدماً في Loop Engineering هي أن الحلقة لا تكتفي بتنفيذ مهمة. يمكن أن تجمع ملاحظات عن أدائها، وتتعلم من المحاولات السابقة، وتحسّن طريقة عملها بمرور الوقت.
مثلاً: في كل مرة تفشل عملية deployment، تحفظ الحلقة نوع الخطأ، طريقة حله، وقرارها النهائي. مع الوقت، يصبح لديها سجل يساعدها على التعامل مع الحالات المتكررة بسرعة أكبر.
هذا هو المدخل العملي لفكرة self-improving agents أو self-improving systems.
لكن يجب أن نكون دقيقين هنا. التحسين الذاتي لا يعني ترك الوكيل يعيد كتابة كل شيء كما يريد. يعني تصميم منظومة ملاحظات وذاكرة وقرارات تسمح له بالتحسن داخل قيود واضحة.
كلما كان النظام أكثر استقلالية، احتاج إلى guardrails أقوى، لا أضعف.
الخلاصة العملية: قبل أن تبني أول Loop، اكتب هذه الأسئلة
إذا أردت تطبيق الفكرة اليوم، لا تبدأ بأداة. ابدأ بورقة صغيرة واكتب:
ما الحدث الذي سيبدأ الـ Loop؟
ما الهدف المحدد الذي يجب تحقيقه؟
ما الدليل الذي يثبت أن الهدف تحقق؟
ما القرارات المحتملة بعد كل نتيجة؟
ما الصلاحيات المسموحة والممنوعة؟
أين سيحفظ الوكيل الحالة والذاكرة؟
ما الحد الأقصى للمحاولات أو استهلاك tokens؟
متى يجب أن يتوقف؟
متى يجب أن يطلب موافقة إنسان؟
إذا لم تستطع الإجابة عن هذه الأسئلة، فأنت على الأغلب لا تحتاج Loop بعد. أنت تحتاج توضيح الهدف أولاً.
أما إذا أجبت عنها، فستجد أن بناء الـ Loop أصبح أسهل بكثير، سواء استخدمت Codex أو Claude أو أي نظام آخر.
النقطة الأهم
Loop Engineering ليست موضة جديدة في عالم الذكاء الاصطناعي. هي طريقة أكثر نضجاً للتعامل مع AI Agents.
بدل أن تطلب من الوكيل “افعل هذا” كل مرة، تبدأ بتصميم بيئة تجعله يعرف كيف يعمل، كيف يقيس، كيف يقرر، وكيف يتوقف.
وهنا تأتي القيمة الحقيقية: متابعة أقل، تحكم أكثر، ومخاطر أوضح.
سؤالي لك: ما أول مهمة متكررة في شغلك تستحق أن تتحول إلى Loop؟ والأهم: ما شرط التوقف الذي سيمنعها من الدوران بلا فائدة؟
