تطلب من الوكيل أن يضيف زرّ إعجاب لصفحة الويب التي تعمل عليها. فيقرأ الكود الموجود مسبقاً، ويجري التعديل الذي يجده لازماً، ويشغّل الاختبارات الضرورية، ثم يعيد إليك شيئاً يظنّ أنه يعمل.
عندها تراجع أنت النتيجة التي توصل إليها بنفسك، وتكتب الأمر التالي الذي ترغب في تنفيذه.
هنا أنت الحلقة: أنت من يبدأ كل دورة، وأنت من يقرّر إن كانت النتيجة كافية أم تحتاج جولةً أخرى من العمل.
هذه هي نقطة الاختناق نفسها التي قد تعيق عملك.
طالما بقيتَ أنت من يضغط الزرّ في كل دورة، فسرعةُ العمل مقيّدةٌ بسرعتك أنت لا بسرعة الوكيل، وهذا بحد ذاته قد يضيع من وقتك الكثير، الذي ربما يمكنك استغلاله في تحقيق شيء أفضل.
والتحوّل الذي يتحدّث عنه كثيرٌ من المطوّرين اليوم تحت اسم «هندسة الحلقات» (loop engineering) هو نقلُ هذا الدور عنك: أن تتوقّف عن كونك الشخص الذي يُلقّن الوكيل، وتصير الشخص الذي يصمّم النظام الذي يُلقّنه.
بوريس تشيرني (Boris Cherny)، المسؤول عن Claude Code في Anthropic، يلخّصها بجملةٍ صارت شعاراً: «لم أعُد ألقّن Claude. صار لديّ حلقاتٌ تُلقّنه وتقرّر ما يفعل. مهمّتي الآن أن أكتب الحلقات».
لكنّ كلمة «حلقة» نفسها غامضة، وإن بحثتَ عن تعريفها وجدتَ إجاباتٍ متعدّدة متضاربة. فريق Claude Code يعرّفها تعريفاً محدّداً: الحلقة أن يكرّر الوكيل دورات عمل مستمرة حتى يتحقّق شرط توقّف.
وتحت هذا التعريف الواحد تندرج أنواعٌ من الحلقات تختلف عن بعضها البعض في أربعة أشياء: ما يطلق الحلقة، وما يوقفها، والأداة المستخدمة من أدوات Claude Code، ونوع المهام الذي يناسبها.
وفهم هذه الفروق هو ما يجعلك تختار الأداة الصحيحة للمهمة المطلوبة بدلاً من الإفراط في التعقيد؛ فليست كل مهمة تحتاج حلقة معقدة، والقاعدة هنا أن تبدأ بأبسط حل يكفي، ثم تلجأ إلى الأنماط الأعقد حين تستدعي المهمة ذلك.
الدورة الأساسية: ما الذي يجري داخل كل «دورة عمل»؟
قبل استعراض أنواع الحلقات، لا بد من فهم اللبنة الأساسية التي تتكرر في الحلقة نفسها: الدورة الواحدة (turn).
فعندما تُكلّف Claude بمهمة، فإنه يدخل دورة جديدة، وهذه الدورة تمر بثلاث مراحل متداخلة، لا خطوات مرتبة مسبقاً.
الأولى هي جمع السياق (gathering context)؛ إذ يبحث في ملفاتك ويقرأ ما يلزم ليفهم الكود المحيط بالمهمة.
والثانية هي اتخاذ الإجراء (taking action)؛ كإجراء تعديل، أو تنفيذ أمر، أو استدعاء أداة. والمهم هنا أن إجراءاته ليست مخططة سلفاً، بل يقررها ديناميكياً بناءً على نتيجة الخطوة السابقة.
والثالثة هي التحقق (verifying)، وفيه يفحص نتيجة عمله. فإذا حددت له معياراً يمكن التحقق منه آلياً (مثل نجاح جميع الاختبارات أو خلو الكود من تحذيرات المدقق (linter)) أمكنه تشغيل هذا الفحص بنفسه وتصحيح الأخطاء إذا فشلت.
يسمي فريق التطوير هذه الدورة الثلاثية باسم الحلقة الوكيلة (agentic loop)، وهي تتكيف مع طبيعة طلبك؛ فالسؤال عن الكود قد يكتفي بمرحلة جمع السياق وحدها، في حين أن إصلاح خطأ برمجي قد يتطلب الدوران في المراحل الثلاث مراراً حتى يستقيم الحل. وكلّ نوعٍ من أنواع الحلقات الأربع القادمة ليس إلا هذه الدورة نفسها، ولكن مع اختلافٍ في محفّز بدء الدورة التالية وشرط إيقاف التكرار.
النوع الأول: الحلقة القائمة على الدورة (Turn-based)
هذه أبسط الحلقات وأكثرها شيوعاً: كل أمرٍ ترسله يبدأ دورةً يديرها الوكيل ثم يعيد إليك المخرجات، فتراجعها وتقرّر أنت الخطوة التالية.
- محفز البدء: أمر مباشر منك.
- شرط التوقف: تقدير Claude بأنه أنجز المهمة، أو حاجته إلى سياق إضافي منك.
- المهام المناسبة لها: المهامّ القصيرة التي ليست جزءاً من عمليةٍ متكرّرة أو مجدوَلة.
ما تفوّضه إلى الوكيل في هذا النمط محدود؛ فأنت تكلّفه بالعمل، بينما تحتفظ لنفسك بمسؤولية التحقق والقرار.
والسبيل العملي لتقليل عدد الدورات — ومن ثم اختصار الوقت وخفض التكلفة — هو نقل جزء من عملية التحقق اليدوي إلى الوكيل، ليفحص عمله بنفسه قبل عرضه عليك، وهنا يأتي دور ملف المهارة (SKILL.md).
والمهارة (skill) هي ملف تكتب فيه خطوات التحقق التي كنت تجريها يدوياً، ليتّبعها الوكيل في كل دورة.
وكلما كانت هذه الفحوصات كمية وقابلة للقياس، سهل على الوكيل التحقق من عمله دون تدخل منك؛ فمعيار مثل «نجاح 12 اختباراً من أصل 12» أو «تجاوز الأداء عتبة 90» هو حكم حاسم لا يتطلب تقديراً بشرياً.
وعلى سبيل المثال، عند كتابة مهارة للتحقق من تعديلات واجهة المستخدم، يمكنك توجيه الوكيل بألا يعتبر العمل مكتملاً بمجرد تعديل الكود، بل عليه تشغيل خادم التطوير (development server)، وفتح الصفحة في المتصفح، والتفاعل مع العنصر الجديد (كالضغط على الزر والتحقق من تغير الحالة)، والتقاط لقطة شاشة لمعاينة التغيير، وفحص سجل أخطاء المتصفح (console log) للتأكد من خلوه من التحذيرات، ثم إجراء قياس للأداء.
فإذا فشلت أي خطوة، يقوم الوكيل بإصلاح الكود ويعيد الفحص من البداية؛ وبذلك يمتنع عن تسليم عمل لم يستكمل التحقق منه.
هكذا ينتقل التحقق من مهمة تؤديها بنفسك بعد كل دورة إلى عملية يجريها الوكيل ذاتياً داخل الدورة، مما يقلل من عدد الأوامر التي تحتاج لإرسالها.
النوع الثاني: الحلقة القائمة على الهدف (/goal)
في المهام المركبة، غالباً لا تكفي دورة واحدة؛ إذ يعمل الوكيل بكفاءة أكبر عندما يُتاح له التكرار والتصحيح الذاتي. غير أن الوكيل، إذا تُرك ليقيم عمله بنفسه، قد يتوقف مبكراً ويسلمك عملاً ناقصاً يعتقد أنه مكتمل، أو قد يستمر دون حاجة فتخسر الوقت والتكلفة.
وهنا يكمن دور الأمر /goal.
- محفز البدء: أمر مباشر منك في حينه.
- شرط التوقف: تحقق الهدف المطلوب، أو بلوغ الحد الأقصى للدورات.
- المهام المناسبة لها: المهام ذات المعايير المحددة التي يمكن التحقق من اكتمالها.
عند استخدام هذا النمط، تكتب بعد الأمر /goal وصفاً دقيقاً لما يعنيه اكتمال المهمة، فيواصل الوكيل العمل والتكرار سعياً لتحقيقه بدلاً من التوقف عند أول نتيجة مقبولة ظاهرياً. مثال:
/goal get the homepage Lighthouse score to 90 or above, stop after 5 triesتعتمد هذه الآلية على عنصر يسمى المقيم (evaluator)، وفهم طريقة عمله هو المفتاح لاستخدام /goal بفاعلية. فعندما ينهي الوكيل دورة عمل، لا يحدد بنفسه ما إذا كان قد حقق الهدف، بل يُرسل الشرط المطلوب ونص المحادثة إلى نموذج منفصل وسريع (يكون عادةً Haiku)، ليقوم بمراجعة السياق والإجابة بنعم أو لا مع تقديم تبرير مختصر.
فإذا كانت الإجابة «لا»، يعود الوكيل إلى العمل مستعيناً بالسبب المقدّم كدليل لتوجيه الدورة التالية. أما إذا كانت الإجابة «نعم»، تنتهي الحلقة ويُسجل الهدف مكتملاً.
ومن الناحية التقنية، فإن الأمر /goal يمثّل غلافاً مبسّطاً لـ خطّاف التوقف (stop hook) — وهو إجراء يُستدعى تلقائياً كلما حاول الوكيل إنهاء العمل. وبذلك يتيح لك /goal تفعيل هذه الميزة مباشرةً بأمر بسيط، بدلاً من تهيئتها يدوياً في ملفات إعداد المشروع.
وتكمن فائدة فصل المقيم عن الوكيل في أن الحكم على اكتمال المهمة يصدر من طرف محايد بمنظور جديد، لا من النموذج نفسه الذي نفذ الحل وقد ينحاز لعمله. فالمقيم يشبه مصحّح امتحان ثانٍ لا يرى سوى ورقة إجابة الطالب؛ فهو لا يشارك في حل المسألة بنفسه، بل يقيم النتيجة بناءً على ما كُتب أمامه فقط. وتترتب على ذلك قاعدة عملية بالغة الأهمية: المقيم لا يشغّل أي أدوات ولا يقرأ ملفات المشروع بنفسه، بل ينحصر علمه بما يعرضه الوكيل صراحةً في نص المحادثة.
لذا، عند صياغة شرط التوقف، يجب كتابته بطريقة تمكّن الوكيل من إثبات تحقيقها في سياق الحوار. فعلى سبيل المثال، يعد الشرط «نجاح جميع اختبارات test/auth» شرطاً مناسباً، لأن الوكيل سيقوم بتشغيل الاختبارات لتظهر نتائجها في نص المحادثة أمام المقيم. في المقابل، فإن كتابة شرط غامض لا يترك أثراً مكتوباً في الحوار لن يتيح للمقيم أي وسيلة للحكم على مدى اكتماله.
وعادةً ما يجمع الشرط الفعال ثلاثة عناصر رئيسية:
- حالة نهائية قابلة للقياس (مثل نتيجة اختبار معين، أو رمز خروج عملية البناء، أو عدد الملفات المعدلة)
- طريقة إثبات واضحة (توضح كيف يبرهن الوكيل على الإنجاز، كأن يخرج الأمر
npm testبالرمز0)، - قيوداً يلتزم بها الوكيل أثناء العمل (مثل «دون تعديل أي ملف في مجلد الاختبارات»).
وبما أن الحلقات المفتوحة قد تستمر في الدوران بلا نهاية إذا تعذر تحقيق الشرط، يُنصح دائماً بوضع سقف محدد لعدد المحاولات ضمن نص الأمر نفسه، مثل إضافة عبارة «توقّف بعد 20 محاولة». ويصل الحد الأقصى لطول الشرط المقبول إلى 4000 حرف، ولا يمكن تشغيل أكثر من هدف واحد نشط في الوقت نفسه داخل الجلسة.
ولا بد من التنبيه إلى أن الأمر /goal يكمل الوضع التلقائي (auto mode) ولا يغني عنه؛ فالوضع التلقائي يوافق على استدعاءات الأدوات داخل الدورة الواحدة لمنع توقف الوكيل عند كل خطوة، ولكنه لا يملك بدء دورة جديدة بمفرده. في حين أن /goal يتولى تسيير العمل وتجاوز التوقفات بين الدورات المتتالية. وبدمج هاتين الميزتين، يعمل الوكيل في دورات متواصلة دون أن يستوقفك للموافقة على استدعاء الأدوات أو عند نهاية كل دورة.
النوع الثالث: الحلقة القائمة على الوقت (/loop و/schedule)
تتكرر بعض المهام البرمجية بطبيعتها مع ثبات خطواتها وتغير مدخلاتها فقط، مثل تلخيص رسائل الفريق كل صباح. كما تعتمد مهام أخرى على التفاعل مع بيئات خارجية، وتعد أبسط طريقة للتعامل معها هي فحصها دورياً للاستجابة للتغيرات — مثل مراقبة طلبات الدمج (pull requests) لاستقبال المراجعات الجديدة أو إصلاح إخفاقات التكامل المستمر (CI).
وفي مثل هذه الحالات، تكون الحلقة قائمة على الوقت وليس على أمر مباشر منك.
- محفز البدء: مرور فاصل زمني محدد.
- شرط التوقف: إلغاء الحلقة يدوياً، أو اكتمال العمل المطلوب (مثل دمج الطلب أو خلو طابور المهام).
- المهام المناسبة لها: العمل الدوري المتكرر، أو التفاعل المستمر مع الأنظمة الخارجية.
يتيح لك الأمر /loop إعادة تشغيل أمر معين تلقائياً على فترات زمنية محددة. مثال:
/loop 5m check my PR, address review comments, and fix failing CIبهذا الأمر، يفحص الوكيل طلب الدمج كل خمس دقائق، ويعالج تعليقات المراجعة، ويصلح الأعطال في بيئة التكامل المستمر، دون أي تدخل متكرر منك.
ويمكنك كذلك تمرير مهارة مخصصة كأمر متكرر، مثل تشغيل /loop 20m /review-pr 1234 لإعادة تقييم طلب الدمج دورياً.
ويتميز هذا الأمر بمرونة عالية عند استخدامه دون تحديد فاصل زمني؛ إذ يحدد Claude الفترات الفاصلة ديناميكياً بناءً على وتيرة التحديثات المكتشفة. فيقلل وقت الانتظار عندما تكون هناك عمليات بناء جارية أو نشاط مكثف على طلب الدمج، ويزيده تلقائياً عندما يستقر العمل ولا يطرأ أي جديد.
تساعد هذه الجدولة الديناميكية في خفض التكاليف، لأنها تتجنب تكرار عمليات الفحص غير المجدية عندما لا يطرأ أي تغيير.
ومع ذلك، يجب الانتباه إلى أن الأمر /loop يعمل محلياً على جهازك؛ مما يتطلب إبقاء جلسة العمل مفتوحة لتستمر الحلقة في الدوران. كما أن لهذه الحلقات حداً زمنياً أقصى؛ إذ تنتهي الحلقات المتكررة تلقائياً بعد سبعة أيام من إنشائها، فتُنفّذ لمرة أخيرة ثم تتوقف تماماً.
ويمثل هذا التدبير إجراءً وقائياً يمنع استمرار الحلقات المنسية في العمل واستهلاك الموارد.
أما إذا كنت بحاجة لتشغيل الحلقة بشكل مستقل عن جهازك، فيمكنك نقلها إلى السحابة بإنشاء روتين (routine) عبر الأمر /schedule. يعمل هذا الروتين على البنية التحتية السحابية لشركة Anthropic، فلا يتأثر بإغلاق جهازك أو إنهاء جلستك المحلية.
لكن هذا الاستقلال السحابي يأتي مقابل حدود في المرونة؛ إذ لا يمكن ضبط الفاصل الزمني للروتين لأقل من ساعة كاملة (بينما ينزل /loop إلى مستوى الدقيقة)، كما أنه ينفذ مهامه على نسخة نظيفة من مستودع الكود وليس على تعديلاتك المحلية المباشرة.
وبناءً على ذلك، تكون القاعدة العملية هي استخدام /loop للاختبار السريع ومتابعة المهام أثناء جلستك، والاعتماد على الروتين السحابي للمهام التي تريد تشغيلها باستمرار دون الحاجة لربطها بجهازك الشخصي.
النوع الرابع: الحلقات الاستباقية (Proactive)
في هذا النمط، يخرج المهندس البشري من الصورة تماماً أثناء التنفيذ؛ فلا تحتاج إلى بدء الجلسة أو مراقبتها في الوقت الفعلي. وتُبنى الحلقة الاستباقية بدمج الأدوات الثلاث السابقة لإدارة تدفقات عمل متكررة ومحددة بدقة.
- محفز البدء: حدث خارجي (مثل إرسال كود جديد) أو جدول زمني سحابي.
- شرط التوقف: تنتهي كل مهمة فرعية عند تحقيق هدفها الخاص، بينما يظل روتين المراقبة العام نشطاً حتى توقفه يدوياً.
- المهام المناسبة لها: تدفقات العمل المتكررة والمهام الروتينية مثل فرز بلاغات الأخطاء (triage)، وترحيل كتل الكود (migrations)، وتحديث مكتبات الاعتماديات.
ويتمثل جوهر هذا النظام في دمج أدوات متعددة لتعمل معاً بشكل متواصل؛ فيطلق /schedule روتيناً سحابياً للبحث عن المهام الجديدة، ويحدد /goal معايير القبول والانتهاء لكل مهمة، وتضمن ملفات المهارات اتباع خطوات التحقق المطلوبة، بينما يتولى سير العمل الديناميكي (dynamic workflows) تنسيق وكلاء فرعيين لإصلاح الأخطاء ومراجعة الحلول، مع تفعيل الوضع التلقائي لضمان تقدم العمل دون استئذان بشري عند كل خطوة.
وعلى سبيل المثال، لمعالجة ملاحظات المستخدمين الواردة، يمكن صياغة التوجيه التالي:
/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged, actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.ويستحق سير العمل الديناميكي (dynamic workflows) المذكور توضيحاً إضافياً لكونه يمثل أحد أقوى مكونات هذا النظام؛ فهو عبارة عن برنامج نصي (script) مكتوب بلغة JavaScript يُنشئه Claude تلقائياً ليصف كيفية تنسيق عشرات أو مئات الوكلاء الفرعيين وإدارتهم. ثم يقوم محرك مخصص بتشغيل هذا السكريبت في الخلفية لتظل جلستك الأساسية حرة للمهام الأخرى.
ولا تكمن قوة هذا الأسلوب في القدرة على تشغيل عدد أكبر من الوكلاء فحسب، بل في نقل «خطة العمل» من ذاكرة النموذج المؤقتة إلى كود برمجي صريح وقابل للمراجعة وإعادة التشغيل. ويفتح ذلك الباب لتطبيق أنماط متقدمة لضبط الجودة، ومن أبرزها التحقق التخاصمي (adversarial verification)؛ إذ تُكلَّف مجموعة من الوكلاء الفرعيين بمحاولة العثور على ثغرات أو دحض الحلول التي اقترحها وكلاء آخرون، فلا يُعتمد الحل إلا إذا صمد أمام هذا الفحص المضاد.
وللسيطرة على التكلفة والموارد، يخضع سير العمل لقيود صارمة: كتشغيل 16 وكيلاً كحد أقصى بالتوازي، وسقف إجمالي يبلغ 1000 وكيل في التشغيلة الواحدة، وهو ما يحول دون وقوع النظام في حلقات لانهائية جامحة.
وفي هذا الهيكل، يتم توزيع النماذج الذكية بناءً على طبيعة المهمة؛ إذ توجّه المهام المتكررة والبسيطة إلى نماذج أصغر وأسرع وأرخص تكلفة، بينما يُحتفظ بالنموذج الأكبر والأقوى للمهام التي تتطلب تفكيراً معقداً أو اتخاذ قرارات حاسمة. ويعد هذا التوزيع الذكي للمهام أحد أهم ركائز إبقاء تكلفة الحلقات الاستباقية تحت السيطرة.
أين تكمن كلفة الحلقة، وكيف تضبطها
قد تفاجئك الحلقات التي تعمل دون قيود بفاتورة استهلاك ضخمة، ويعود السبب في ذلك إلى الآلية التي تعمل بها الوكالات الذكية. فالوكيل لا يستهلك الرموز (tokens) بالنمط البسيط للمحادثات العادية التي تقتصر على سؤال وجواب؛ بل يدور في حلقة متكررة تتضمن قراءة الملفات واستدعاء الأدوات وإجراء عمليات التحقق.
وفي كل خطوة جديدة، يُعاد إرسال كامل سياق المحادثة المتراكم إلى النموذج. وهكذا، فعند الوصول إلى الدورة العشرين في حلقة عمل تقرأ ملفات متعددة، قد يتجاوز حجم المدخلات المرسلة في استدعاء واحد عشرات الآلاف من الرموز.
لهذا السبب، تتزايد التكلفة مع زيادة طول الحلقة بشكل غير خطي (non-linear). فبينما قد تكلف حلقة من خمس خطوات أضعافاً قليلة مقارنة باستعلام بسيط، فإن حلقة من مئتي خطوة (وهو رقم معتاد عند استكشاف الأخطاء البرمجية المعقدة وإصلاحها) قد يتضاعف استهلاكها لأكثر من مئة ضعف؛ ليتحول ما كان يمكن إنجازه بأقل من دولار واحد عبر أمر مباشر ومحدد، إلى تكلفة تصل لعشرات الدولارات في حلقة عمل مفتوحة.
لذا، يكمن الحل في وضع حدود واضحة ومدروسة للحلقة. وفيما يلي أهم الممارسات لضبط الاستهلاك:
- اختيار الأداة والنموذج المناسبين للمهمة: لا تتطلب المهام البسيطة استدعاء عدة وكلاء أو بناء سير عمل ديناميكي معقد، بل يمكن إنجازها بنماذج أصغر وأوفر تكلفة. تجنب إطلاق سير عمل ديناميكي لحل مشكلة يمكن معالجتها بأمر واحد مباشر.
- صياغة معايير النجاح والتوقف بدقة: كلما حددت بوضوح معنى «اكتمال العمل»، تمكن الوكيل من الوصول إلى النتيجة المطلوبة في دورات أقل دون التوقف مبكراً.
- التجربة على نطاق ضيق قبل التشغيل الكامل: بما أن سير العمل الديناميكي قد يطلق مئات الوكلاء، فمن المستحسن اختبار الاستهلاك على مجلد فرعي واحد أو نطاق ضيق من الكود، للتأكد من سلامة التصميم قبل تعميمه على كامل مستودع المشروع.
- الاعتماد على البرمجيات النصية (scripts) للمهام الحتمية: تشغيل نص برمجي محدد الخطوات أرخص بكثير من جعل النموذج يعيد التفكير والاستنتاج في كل دورة؛ لذا، فإن المهام ذات المنطق الثابت يجب كتابتها كسكريبت يُستدعى مباشرة، بدلاً من إتاحة المجال للوكيل لاستنباطها في كل مرة.
- تحجيم وتيرة عمل الروتين: احرص على جعل الفاصل الزمني متناسباً مع معدل تغير النظام الذي تراقبه؛ فتشغيل فحص دوري كل خمس دقائق لمراقبة نظام لا يتغير إلا مرة واحدة في اليوم يمثل إهداراً خالصاً للموارد.
وتوفر بيئة التطوير أدوات مباشرة لمراقبة هذا الاستهلاك؛ فيعرض الأمر /usage تفاصيل الاستهلاك الأخير مقسمة بحسب المهارات والوكلاء الفرعيين وخوادم البروتوكول (MCP)، بينما يُظهر الأمر /goal (دون وسائط إضافية) عدد الدورات والرموز المستهلكة في الهدف الحالي، ويعرض الأمر /workflows استهلاك كل وكيل نشط مع إتاحة خيار إيقافه في أي لحظة.
كيف تحافظ على جودة المخرجات
ترتبط جودة مخرجات الحلقة بجودة النظام المحيط بها والبيئة التي تعمل فيها؛ فالوكيل بطبيعته يحاكي الأنماط البرمجية والأعراف المتبعة في مستودع الكود الخاص بك. بناءً على ذلك، يبدأ التأسيس للجودة قبل إطلاق الحلقة نفسها:
- الحفاظ على نظافة كود المشروع: بما أن الوكيل يحاكي الأنماط المكتوبة أمامه، فإن وجود كود منظم ونظيف سيقوده لإنتاج حلول مشابهة، بينما ينعكس الكود الفوضوي سلباً على جودة إنتاجه.
- تزويد الوكيل بوسائل التحقق الذاتي: احرص على صياغة معايير الجودة المتبعة لدى فريقك وتوثيقها في ملفات مهارات (skills) واضحة، لتتحول تلك القواعد من أفكار شفهية إلى تعليمات برمجية يلتزم بها الوكيل.
- إتاحة وثائق المراجع (documentation): يؤدي توفير أدلة الاستخدام والمراجع البرمجية لأطر العمل والمكتبات المستعملة إلى تمكين الوكيل من تبني أحدث الحلول البرمجية وتجنب الطرق المتقادمة.
- تعيين وكيل مستقل للمراجعة البرمجية: يساعد استخدام نموذج مستقل للمراجعة في تقديم تقييم غير متحيز، نظراً لأن المراجع لا يشترك في سياق التفكير نفسه الذي مر به الوكيل كاتب الكود. وتوفر المنصة مهارة مدمجة
/code-reviewتطلق وكلاء متعددين لفحص التغييرات بالتوازي من زوايا أمنية وفنية مختلفة.
ويتمثل المبدأ الأساسي لتحسين جودة النظام بمرور الوقت في التعامل مع الأخطاء الفردية كفرص للتطوير؛ فعندما يخفق الوكيل في تحقيق المعيار المطلوب في حالة معينة، لا تكتفِ بإصلاح الكود يدوياً، بل وثّق هذا التوجيه وصغه كمعيار فحص في المهارة المعنية لضمان تفادي الخطأ في كافة الدورات المستقبلية. فالخطأ الذي يُعالج لمرة واحدة قد يتكرر، أما الخطأ الذي يُرصّد في المهارة فيُمحى أثره نهائياً.
حدود الأتمتة: أين يظل دور المهندس البشري؟
إن السلاسة التي يتيحها تسليم المهام إلى الحلقات التلقائية قد تخفي خطورة حقيقية؛ فالأتمتة الكاملة دون رقابة قد تؤدي إلى تراكم الأخطاء دون شعور المطور بها. وكما صاغها آدي عثماني (Addy Osmani): «الحلقة التي تعمل بلا رقيب هي حلقة تخطئ بلا رقيب».
فأتمتة دورات العمل لا تعفيك من المسؤولية القانونية والفنية عن سلامة المنتج النهائي؛ إذ تظل عملية التحقق ومراجعة الكود التزاماً شخصياً يقع على عاتقك، كما أن فهمك العميق لبنية المشروع وتفاصيله قد يتآكل تدريجياً إذا اقتصر دورك على تشغيل الحلقات دون قراءة الكود الناتج بعناية.
ومن هنا، فإن حالة الاسترخاء البرمجي المتمثلة في الضغط على زر التشغيل والمغادرة تشكل خطراً حقيقياً على جودة المشروع. لذلك، تنصرف النصائح المنهجية إلى ضرورة تصميم الحلقات كأدوات مساعدة تدعم دورك كمهندس ومصمم للنظام، لا كبديل يلغي وجودك ويقتصر دورك بعده على إطلاق العمل اليدوي.
وإذا أردت البدء في تطبيق هذه الممارسات بشكل عملي، فابدأ بتحليل مهامك اليومية وتحديد إحدى النقاط التي تمثل عنق زجاجة في سير عملك، ثم تساءل:
ما الجزء الذي يمكن تفويضه للوكيل؟
هل يمكنني أتمتة اختبارات التحقق وتفويضها له (الحلقة القائمة على الدورة)؟
هل معيار النهاية واضح بما يكفي لتفويض شرط التوقف (الحلقة القائمة على الهدف /goal)؟
هل يتبع العمل جدولاً زمنياً ثابتاً يتيح تفويض محفز البدء (الحلقة القائمة على الوقت /loop أو السحابة /schedule)؟
ابدأ بالحد الأدنى الذي يفي بالغرض، وأطلق الحلقة، وراقب كفاءتها، ثم عدلها بحسب الحاجة.
ويلخص الجدول التالي كيفية الاختيار بين هذه الأنماط:
| نوع الحلقة | ما تفوضه للوكيل | متى تستعملها | الأداة المقترحة |
|---|---|---|---|
| القائمة على الدورة | التحقق | أثناء استكشاف المشاكل أو اتخاذ القرارات | مهارات تحقق مخصصة |
| القائمة على الهدف | شرط التوقف | عندما يكون شكل النتيجة النهائية واكتمالها واضحاً | /goal |
| القائمة على الوقت | محفز بدء العمل | للمهام المرتبطة بجدول زمني أو أحداث خارجية | /loop أو /schedule |
| الاستباقية | كامل تدفق العمل | عندما يكون العمل دورياً ومحدد المتطلبات بدقة | كل ما سبق + سير العمل الديناميكي |
خلاصة القول، إن المهارة الجوهرية في عصر الذكاء الاصطناعي لا تكمن في صياغة أوامر تلقين أفضل، بل في تحديد الأجزاء القابلة للتفويض من عملك؛ وهي أربعة: التنفيذ، والتحقق، وشرط التوقف، ومحفز البدء.
وكلما تمكنت من تفويض مساحة أكبر من هذه الأركان بثقة مدعومة بآليات تحقق صممتها بنفسك، اقتربت من التحول إلى مهندس يدير المنظومة بكاملها ويشرف عليها، بدلاً من أن تظل مجرد مشغل يدوي لها.
وإن أردت الانطلاق من المصدر مباشرةً، فدليل «البدء مع الحلقات» من Anthropic هو المرجع الأساسي لهذه الأنماط الأربعة، وصفحة توثيق /goal تشرح المقيّم وشرط التوقف بتفصيلٍ عمليّ: