ما هي هندسة الحلقات في الذكاء الاصطناعي؟

ما المقصود بهندسة الحلقات

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

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

سبب ظهور المصطلح في 2026

يُرسَّخ هذا الاسم علناً في الوقت الحالي. وقد تجاوز مستودع GitHub cobusgreyling/loop-engineering عدد 9,600 نجمة خلال شهرين من ظهوره الأول (حتى July 2026)، تحت العبارة: "لا تكتب prompts. صمّم الحلقة. احصل على نتيجة." وهو يلخّص هذا التحول في ستة مكوّنات أساسية: الجدولة، وworktrees، والمهارات، وplugins وconnectors، وsub-agents، والذاكرة الدائمة المحفوظة خارج المحادثة.

وهو يقتبس Boris Cherny، الذي يقود Claude Code في Anthropic:

لم أعد أكتب prompts إلى Claude. لدي حلقات تعمل وتكتب prompts إلى Claude.

ويحظى مستودع ثانٍ، AI-Builder-Club/skills، بنحو 1,100 نجمة (حتى July 2026)، ويسمّي الدورين مباشرة: "codebase harness" يهيّئ المستودع بحيث يستطيع agent تشغيل الاختبارات وعمليات النشر فيه بأمان، و"loop engineer" يبني workflows تستيقظ عند وقوع trigger، وتنفّذ العمل، وتكتب ما تعلّمته في ملف مشترك كي تتمكن الحلقة التالية من قراءته.

لم يبتكر أي من المستودعين هذه الممارسة. فأي شخص شغّل build ليلياً، أو linter ضمن continuous integration، أو cron job يفتح ticket، يعرف بنيتها مسبقاً. الجديد هو أن العامل داخل الحلقة أصبح الآن غير حتمي، وهذا يغيّر ما يجب أن تنفّذه الآليات المحيطة به.

الأجزاء الأربعة للحلقة

تحتوي كل حلقة عاملة على هذه الأجزاء الأربعة. وإذا تجاوزت الحلقة أحدها، فقد توقظك الساعة 3 صباحاً.

• المشغِّل. الحدث الذي يبدأ التنفيذ: مؤقّت، أو webhook، أو طلب سحب جديد، أو تنبيه.
• النطاق. الملفات وبيانات الاعتماد والشبكة التي يمكن للوكيل الوصول إليها أثناء ذلك التنفيذ.
• التحقق. فحص يُرجع exit code يحدد ما إذا كان سيتم الاحتفاظ بمخرجات التنفيذ أو التخلص منها.
• الميزانية. حد الرموز المميّزة والوقت والمال الذي ينهي التنفيذ سواء نجح أم لا.

حوّل هذه الأجزاء الأربعة إلى أسئلة، وستحصل على مراجعة تصميم لأي وكيل تستعد لتركه قيد التشغيل.

المشغّل: ما الذي يوقظ الوكيل

المؤقّت هو أبسط مشغّل. وعلى خادم Linux، يتفوّق مؤقّت systemd على cron في هذه الحالة لأنه يسجّل الأحداث، ويعيد المحاولة وفق ما تحدده، ولا يبدأ نسخة ثانية من وحدة ما تزال قيد التشغيل. وتزيل هذه الخاصية أكثر أخطاء التداخل شيوعاً في حلقات الوكلاء: تشغيلين يعدّلان الفرع نفسه.

اكتب الوحدة في /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

واكتب المؤقّت في /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

يجب أن يعرض systemctl list-timers عمود NEXT يحتوي على وقت مستقبلي، وعمود LEFT يعرض عدّاً تنازلياً. تعني النتيجة الفارغة أن المؤقّت غير مفعّل، لأن enable من دون --now يجدوله للإقلاع التالي فقط. ويكتسب TimeoutStartSec=1800 أهمية أكبر مما يبدو: فإذا علق الوكيل في انتظار إدخال، فسيبقي الوحدة نشطة إلى أجل غير مسمى، ولن يعمل المؤقّت مرة أخرى. اقرأ نتيجة تشغيل باستخدام journalctl -u agent-loop.service -n 50.

إذا شغّلت الحلقة من cron بدلاً من ذلك، فأضف آلية حماية من التداخل، لأن cron سيبدأ نسخة ثانية من دون تردد:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

يخرج flock -n فوراً بالحالة 1 عندما يكون القفل محجوزاً، لذلك تختفي العملية الثانية بهدوء بدلاً من التنافس مع العملية الأولى. ينطبق إعداد خدمة systemd ومؤقّتها نفسه على أي مهمة طويلة التشغيل على الخادم، سواء كانت وكيلاً أم لا.

الحد الفاصل: امنح كل تشغيل نسخته الخاصة

الوكيل الذي يحرّر شجرة العمل لديك يمكن أن يفقد عملك غير الملتزم به. تحل Git worktrees هذه المشكلة بتكلفة منخفضة: يحصل كل تشغيل على مجلده وفرعه الخاصين، مع مشاركة مخزن كائنات واحد.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

تطبع git worktree list سطراً واحداً لكل شجرة، يتضمن مسارها وcommit والفرع. عند انتهاء التشغيل، تحذف git worktree remove /srv/agent/work/triage-01 المجلد، بينما تزيل git worktree prune الإدخالات التي اختفى مجلدها. تصبح الحلقات المتوازية آمنة عند هذه النقطة، لأن وكيلين يعملان على فرعين مختلفين وفي مجلدين مختلفين لا يمكنهما الكتابة فوق عمل أحدهما الآخر.

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

التحقق: البوابة التي تجعل الحلقة آمنة

هذا هو الجزء الذي يميّز الحلقة عن cron job يكتب الأوامر آلياً. مخرجات الوكيل اقتراح. والبوابة هي التي تقرر.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

ينفّذ set -euo pipefail عملاً فعلياً في ذلك السكربت. من دون -e، يتم تجاهل فشل git fetch، ويستمر التشغيل باستخدام origin/main قديم. ومن دون -u، يتمدد الخطأ المطبعي في اسم متغير إلى سلسلة فارغة، ثم تُجرى عملية التنظيف على المسار الخطأ بدلاً من إيقاف التنفيذ برسالة واضحة.

كتلة if ! npm test هي جوهر الفكرة. يحدد رمز الخروج لفحص تثق به مسبقاً، مثل مجموعة الاختبارات أو مدقق الأنواع، ما إذا كان سيتم دفع الفرع أو حذفه. تنتج الحلقة التي لا تحتوي على بوابة عملاً لا يملك أحد وقتاً لمراجعته، وهذا أسوأ من عدم إنتاج أي عمل. أما الحلقة التي تحتوي على بوابة فتنتج فرعاً اجتاز بالفعل المعيار نفسه الذي يجب أن يجتازه فرع يقدمه مساهم بشري. لا توضح البوابة الناجحة مقدار الشيفرة التي عدّلها الوكيل للوصول إلى هذه النتيجة، لذلك من المفيد إقران الفحص بتوجيه ثابت مثل القاعدة التي تجعل الوكيل ينفذ أصغر تغيير يحقق المطلوب، ما يحافظ على صغر diff بما يكفي لتبقى مراجعته منخفضة التكلفة.

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

الميزانية: ما الذي يوقف التشغيل

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

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

الأنماط التي توثّقها المستودعات الرائجة

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

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

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

عندما تفشل الحلقات

الإخفاقات مملة، وتتكرر بين الفرق.

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

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

البدء دون المصطلحات

لا تحتاج إلى إطار عمل. يكفي خادم Linux صغير يعمل دائماً، ومستودع git تفشل مجموعة اختباراته عند وجوب الفشل، ومؤقت systemd واحد، وبرنامج shell نصي واحد يتضمن if لإنشاء حلقة عمل مكتملة. هذا هو المكان الذي ينبغي لمعظم الناس أن يبدأوا منه فعلاً، لأنك تجيب عن أسئلة التصميم بتشغيل النظام، لا باختيار أداة. بعد استقرار حلقة واحدة، يصبح تشغيل حلقة ثانية مسألة إضافة مؤقت آخر وworktree آخر في الغالب. راجع كيفية تشغيل وكيل برمجة بالذكاء الاصطناعي على VPS للإعداد الأساسي، وراجع خيارات وكلاء الذكاء الاصطناعي ذاتية الاستضافة الحالية إذا أردت تشغيل الوكيل نفسه على عتاد تتحكم فيه.

FAQ

هل تختلف هندسة الحلقات عن هندسة المطالبات؟

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

هل أحتاج إلى إطار عمل لبناء حلقة وكيل؟

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

ما هو harness لقاعدة الشيفرة؟

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

كيف أوقف حلقة وكيل قبل أن ترفع الفاتورة كثيراً؟

ضع حدوداً لها في 3 مواضع. عيّن TimeoutStartSec في وحدة systemd حتى يُنهى التشغيل العالق. حدّ عدد محاولات إعادة التشغيل داخل الـscript بدلاً من التكرار حتى النجاح. ضع حداً صارماً للإنفاق على حساب API، لأن هذا هو السقف الوحيد الذي لا يستطيع الوكيل التحايل عليه بالكلام. ثم سجّل تكلفة كل تشغيل، لأن الحلقة التي تتضاعف تكلفتها تكون عادةً حلقة اتسع نطاقها بهدوء.

ما الوظائف التي تستحق تحويلها إلى حلقة أولاً؟

اختر وظيفة لها شرط نجاح يمكن للآلة قراءته، ونطاق تأثير محدود. يشمل ذلك إصلاح build فاشل، وتحديث dependency، وإعادة إنشاء changelog، لأن test suite أو diff يمكنه إثبات النتيجة. أما العمل المفتوح، مثل إعادة الهيكلة أو التصميم، فلا يستوفي الشرط بعد، إذ لا يوجد ما يمكن للبوابة فحصه. والحلقة من دون بوابة طريقة مكلفة لتوليد عبء مراجعة.