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

ما تعنيه هندسة الحلقات

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

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

لماذا ظهر المصطلح في 2026

يجري تثبيت الاسم علنًا الآن. تجاوز مستودع GitHub cobusgreyling/loop-engineering عدد 9,600 نجمة خلال شهرين من ظهوره الأول (حتى يوليو 2026)، تحت العبارة: "توقّف عن كتابة المطالبات. صمّم الحلقة. احصل على نتيجة." وهو يجمع هذا التحول في ستة مكوّنات أساسية: الجدولة، وworktrees، والمهارات، والمكونات الإضافية وموصلات الربط، والوكلاء الفرعيون، والذاكرة الدائمة المحفوظة خارج المحادثة.

وينقل عن Boris Cherny، الذي يقود Claude Code في Anthropic:

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

ويحظى مستودع ثانٍ، AI-Builder-Club/skills، بنحو 1,100 نجمة (حتى يوليو 2026)، ويسمي الدورين مباشرة: "حزام codebase" يجعل المستودع آمنًا لكي يشغّل فيه الوكيل الاختبارات وعمليات النشر، و"مهندس حلقات" يبني مسارات عمل تستيقظ عند وقوع محفز، وتنفّذ العمل، وتكتب ما تعلمته في ملف مشترك حتى تتمكن الحلقة التالية من قراءته.

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

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

تتكوّن كل حلقة عاملة من هذه الأجزاء الأربعة. وإذا تجاوزت الحلقة أحدها، فقد تستمر دون ضوابط واضحة.

• المشغّل. الحدث الذي يبدأ التشغيل: مؤقّت، أو webhook، أو pull request جديد، أو تنبيه.
• النطاق. الملفات وبيانات الاعتماد والشبكة التي يمكن للعامل الوصول إليها أثناء ذلك التشغيل.
• التحقّق. فحص يعيد 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 هذه المشكلة بتكلفة منخفضة: يحصل كل تشغيل على دليله الخاص وفرعه الخاص، مع مشاركة مخزن كائنات واحد.

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

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

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

التحقق: الحاجز الذي يجعل الحلقة آمنة

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

#!/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 الفكرة بأكملها. يحدد رمز الخروج من فحص تثق به مسبقًا، مثل مجموعة الاختبارات أو أداة فحص الأنواع، ما إذا كان سيتم دفع الفرع أو حذفه. تنتج الحلقة التي لا تحتوي على حاجز أعمالًا لا يملك أحد وقتًا لمراجعتها، وهذا أسوأ من عدم إنتاج أي عمل. أما الحلقة التي تحتوي على حاجز فتنتج فرعًا اجتاز مسبقًا المعيار نفسه الذي يجب أن يجتازه فرع المساهم البشري.

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

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

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

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

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

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

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

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

أين تفشل الحلقات

تتسم حالات الفشل بالرتابة، وتتكرر بين الفرق.

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

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

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

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

FAQ

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

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

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

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

ما هو حزام قاعدة الشفرة؟

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

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

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

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

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