ما هي هندسة الحلقة؟

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

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

تُعد هندسة الحلقة ممارسة ناشئة في الهندسة القائمة على الوكلاء تُشكل الأساس للعديد من وكلاء AI Coding مثل IBM Bob و Claude Code و Codex من OpenAI. تعمل هندسة الحلقة على تحسين نظام التنفيذ العام، مما يمكّن الوكلاء من حل المشكلات المعقدة ومتعددة الخطوات بأقل قدر من الإشراف.

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

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

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

تتبع حلقات الوكيل عادةً نمطًا قياسيًا: 

1. الهدف
   
   
2. الإجراء
   
   
3. الملاحظة
   
   
4. التعديل

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

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

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

يقوم النظام الوكيل بتقييم نتائج الإجراء. مع توليد الكود المؤتمت، قد يجري الوكيل اختبار تكامل مستمر (CI) لمعرفة ما إذا كان الكود الناتج ناجح أم فاشل.

بناءً على الملاحظة، يقوم النظام بتقييم الملاحظات التقييمية وإجراء أي تغييرات ضرورية على نهجه قبل إعادة تشغيل الحلقة الوكيلة.

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

عند تصميم الحلقات التي ستحقق نتائج جيدة، يقوم المطورون عادةً بتضمين: 

• الأتمتة أو الجدولة
  
  
• الخطافات (Hooks)
  
  
• هندسة السياق
  
  
• الوصول إلى الأدوات
  
  
• أشجار العمل
  
  
• المهارات
  
  
• الوكلاء الفرعيون
  
  
• الهيكل الأساسي (Spine)

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

تُؤتمِت الأنظمة المستندة إلى Unix مثل Linux أو macOS المهام باستخدام مُجدوِل زمني يُعرف باسم مهمة cron.

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

يستخدم المطورون الخطافات (Hooks) بشكل كبير لأغراض الأمان والجودة، مثل فرض السياسات، والتحقق من صحة المخرجات، وتفعيل مسارات العمل تلقائيًا. على سبيل المثال، قد يُستخدم خطاف ما قبل الإيداع (pre-commit hook) للتحقق من مطابقة الكود للمعايير قبل إيداع التغييرات في المستودع. 

تُزيل الخطافات (Hooks) مهامًا مثل الحوكمة وفحوصات الجودة عن كاهل الوكلاء في الحلقة، مما يقلل من تكاليف الرموز المميزة واستهلاك الحوسبة.

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

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

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

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

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

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

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

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

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

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

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

يساعد نهج العنصر البشري في الحلقة على تجنب أخطر مزالق التوليد الآلي للأكواد البرمجية، مثل الأكواد غير المتحقق من صحتها، ودَيْن الفهم، ودَيْن القصد، والاستسلام المعرفي.

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

تُعرف الفجوة بين إجمالي كمية الأكواد البرمجية في النظام ومدى استيعاب البشر لها باسم "دَيْن الفهم" (Comprehension Debt). مع كتابة الوكلاء للمزيد من الكود وقلة مراجعة البشر له، تتراكم ديون الفهم. 

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

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

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

عندما يقبل المطورون مخرجات الحلقة دون أي تساؤل، تزداد ديون الفهم بسرعة.