مهندس جوجل يعلّمك ما هو هندسة الحلقات؟ خمسة مكعبات + ذاكرة خارجية، دورة الذكاء الاصطناعي الإلزامية لعام 2026

Loop Engineering هي نظام ينفذ تلقائيًا وكيل prompts الخاص بك، ويتكون من خمسة مكونات أساسية: الأتمتة، الأشجار العمل، المهارات، الإضافات/الموصلات، والوكلاء الفرعيين، بالإضافة إلى ذاكرة خارجية. هذا المقال مستوحى من مهندس برمجيات جوجل أدّي أوسماني.
(ملخص سابق: هل يمكن لـ Anthropic في Claude Fable 5 أن يمنع نماذج المصدر المفتوح الصينية من التسلل؟)
(معلومات إضافية: Anthropic: الرائدة في نماذج الذكاء الاصطناعي في أمريكا، وتقول إن حماية الديمقراطية تتطلب تفوقها على الصين، وتقترح أن يكون هجوم التقطير جريمة جنائية)

فهرس المقال

Toggle

• خمسة مكونات أساسية، مع بعض الملاحظات
• Automations: نبضات القلب في الحلقة
• Worktrees: لا تدع التوازي يتحول إلى فوضى
• Skills: أخيرًا لن تضطر لإعادة شرح مشروعك في كل مرة
• Plugins و Connectors: أدوات الحلقة التي تلمس أدواتك الحقيقية
• Sub-agents: فصل من يقوم بالعمل عن من يراجع
• كيف يبدو شكل الحلقة
• ما لا تزال الحلقة تقوم به
• بناء الحلقة، لكن الاستمرار كمهندس برمجيات

Loop engineering هو استبدال "الوكيل الذي يطلب prompt يدويًا" بنظام تصممه أنت ليقوم بذلك. يمكن فهم "الحلقة" هنا كهدف تكراري: تحدد الهدف، ثم يكرر الذكاء الاصطناعي العملية حتى يكتمل. أعتقد أن هذه قد تكون طريقتنا المستقبلية للتعاون مع وكلاء التشفير.

لكن، قبل أن نبدأ، هذا لا يزال في مراحله المبكرة، وأنا أيضًا أشكك فيه، ويجب أن تكون حذرًا جدًا من تكلفة الرموز (tokens). أريد أن أتناول الأمر من زوايا متعددة: ما هو، وما يعنيه.

قال بيتر ستاينبرغر مؤخرًا: "لم يعد عليك أن تطلب prompt لوكيل التشفير الخاص بك. عليك أن تصمم حلقة ت prompts لوكيلك." وقال بوريس تشيرني، مسؤول Claude Code في أنثروبيك، شيئًا مشابهًا: "لم أعد أطلب prompt لـ Claude. أترك الحلقة لتقوم بprompt Claude، وتقرر الحلقة بنفسها ما يجب فعله."

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

الآن، أنت تبني نظامًا صغيرًا: يبحث عن عمل، يوزع العمل، يراجع العمل، يسجل ما تم، ثم يقرر الخطوة التالية، ويقوم هذا النظام بتنفيذ الوكيل بدلاً منك. لقد كتبت سابقًا عن "حاضنة الوكيل" (agent harness)، وهو بيئة لتشغيل وكيل واحد، وهو نموذج "مصنع البرمجيات".

Loop engineering هو مستوى أعلى من harness: harness لا يزال موجودًا، لكنه يعمل بشكل منتظم، ويولد مساعدين، ويقوم بتغذية نفسه.

ما فاجأني هو أن الأمر لم يعد مجرد أداة. قبل عام، كان عليك أن تكتب حلقة باستخدام الكثير من bash، وتديرها بنفسك، وكانت خاصة بك. الآن، هذه المكونات مدمجة مباشرة في المنتج. قائمة Steinberger تقريبًا تتطابق مع تطبيق Codex، وتتطابق تقريبًا مع Claude Code. بمجرد أن تكتشف أن الشكل هو نفسه، لن تتجادل بعد ذلك حول "أي أداة تستخدم"، بل ستصمم حلقة يمكن تشغيلها بغض النظر عن الأداة التي تستخدمها.

خمسة مكونات أساسية، مع بعض الملاحظات

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

2. Automations: تفعيل تلقائي بناءً على جدول زمني، للقيام بالاكتشاف والتصنيف.
3. Worktrees: عزل الوكلاء المتوازيين حتى لا يتداخلوا.
4. Skills: ترميز المعرفة الخاصة بالمشروع التي كانت تعتمد على التخمين.
5. Plugins و Connectors: ربط الوكيل بالأدوات التي تستخدمها بالفعل.
6. Sub-agents: وكيل واحد يطرح فكرة، وآخر يراجعها.

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

الآن، هناك منتجان يدعمان جميع العناصر الخمسة.

| المصطلح الأصلي | | --- | دور الحلقة | تطبيق Codex | Claude Code | | --- | --- | --- | --- | | Automations | الاكتشاف والتوجيه المجدول | قسم Automations: اختيار المشروع، prompt، التكرار، البيئة؛ النتائج تدخل صندوق التصنيف؛ /goal يُستخدم للتشغيل حتى الانتهاء | مهام مجدولة و cron، /loop، /goal، hooks، GitHub Actions | | Worktrees | عزل تطوير الميزات المتوازي | كل خيط داخله worktree | git worktree، --worktree، العزل على مستوى subagent: worktree | | Skills | ترميز معرفة المشروع | مهارات الوكيل (SKILL.md)، باستخدام $name أو استدعاء ضمني | SKILL.md الخاص بالوكيل | | Plugins / connectors | ربط أدواتك | Connectors (MCP) مع الإضافات الموزعة | خوادم MCP مع الإضافات | | Sub-agents | تصميم والتحقق | تُعرف في .codex/agents/ باستخدام TOML | وكلاء المهام في .claude/agents/، فرق الوكلاء، الوكلاء الفرعيون | | State | تتبع الحالة المكتملة | Markdown أو عبر connector يربط Linear | Markdown (AGENTS.md، ملف التقدم) أو عبر MCP يربط Linear |

الأسماء تختلف هنا وهناك، لكن القدرة الجوهرية واحدة. سأفصل كل واحد، لأن التفاصيل الدقيقة هي التي تحدد استقرار الحلقة أو تسربها.

Automations: نبضات القلب في الحلقة

Automations هو ما يجعل "الحلقة" فعلاً حلقة، وليس مجرد "شيء قمت بتشغيله مرة واحدة". في تطبيق Codex، تبني واحدة في قسم Automations، تختار المشروع، prompt، التكرار، البيئة؛ النتائج تدخل صندوق التصنيف، والغير مكتشف يُنظم تلقائيًا.

يستخدمها OpenAI داخليًا للمهام الروتينية: تصنيف قضايا اليوم، ملخصات CI الفاشلة، ملخصات الالتزامات، تتبع الأخطاء التي أُدخلت الأسبوع الماضي. يمكن لـ Automation استدعاء skill، لذا يمكن لروتينك أن يُدار: فقط أطلق $skill-name بدلاً من لصق مجموعة أوامر في جدول زمني غير محدث.

Claude Code يسلك نفس المسار لكن عبر الجدولة و hooks. يمكنك استخدام /loop لإعادة prompt أو أوامر بفاصل زمني، أو جدولة cron، أو استخدام hooks لتشغيل أوامر shell عند نقاط معينة في دورة حياة الوكيل، أو رفع المهمة على GitHub Actions لتستمر بعد إغلاق اللابتوب. المفهوم هو نفسه: تحدد مهمة تلقائية، تعطيها إيقاعًا، وتكتشفها تلقائيًا أمامك، دون الحاجة للتدخل اليدوي.

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

إذا أعطيتها شرطًا مثل "اختبارات /auth تمر جميعها، و lint نظيف"، فستتوقف. لدى Codex أيضًا نفس الشيء، يُسمى /goal، ويعمل عبر عدة دورات حتى يتحقق شرط إيقاف يمكن التحقق منه، ويمكن إيقافه واستئنافه ومسحه. نفس الأمر في الأداتين، وهو نمط أساسي للمقالة.

إذن، الجزء الأول هو "إظهار العمل". الأجزاء المتبقية من الحلقة هي "العمل على تلك الأعمال".

Worktrees: لا تدع التوازي يتحول إلى فوضى

عندما تشغل أكثر من وكيل في نفس الوقت، تبدأ الملفات في التصادم، وهذه هي طريقة تعطل النظام. كتابة نفس الملف من قبل وكيلين، مثل مهندسين يلتزمون بنفس السطر من الكود دون تنسيق مسبق، مؤلم جدًا. git worktree يحل هذه المشكلة: هو دليل عمل منفصل، فرع خاص، ويشارك سجل المستودع نفسه، لذلك تحرير وكيل واحد لا يعيق الآخر.

يدعم Codex العمل باستخدام worktree مدمج، بحيث يمكن لعدة خيوط أن تعمل على نفس المستودع دون تصادم. Claude Code يستخدم git worktree، و --worktree، وإعداد isolation: worktree على مستوى subagent (كل مساهم يحصل على checkout جديد، ويحذف نفسه بعد الانتهاء) لتوفير نفس العزل. في مقال "تكاليف التنسيق"، شرحت من وجهة نظر بشرية أن worktree يزيل التصادم الميكانيكي، لكن أنت هو الحد الأقصى، ومراجعتك هي التي تحدد عدد الوكلاء الذين يمكنك تشغيلهم، وليس الأداة.

Skills: أخيرًا لن تضطر لإعادة شرح مشروعك في كل مرة

Skill هو ما يجعلك لا تعيد شرح سياق مشروعك في كل جلسة. كلا الأداتين تستخدم نفس التنسيق: مجلد يحتوي على SKILL.md، يتضمن الأوامر والبيانات الوصفية، مع سكربتات، مراجع، أصول اختيارية. عند استدعاء $ أو /skills، يُشغل skill، أو يُشغل تلقائيًا عندما يتطابق مهمتك مع وصف skill — وهذا يفسر لماذا الوصف الدقيق والبسيط يتفوق على الوصف الجميل والذكي.

Claude Code يتبع نفس النهج، كما شرحت في مقال "مهارات الوكيل".

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

هناك شيء يجب تمييزه: skill هو تنسيق كتابة، و plugin هو طريقة التوزيع. عندما تريد مشاركة skill عبر مستودعات، أو تجميع عدة skills في حزمة، فإنك تعبئها كـ plugin. Codex يفعل ذلك، وClaude Code أيضًا.

Plugins و Connectors: أدوات الحلقة التي تلمس أدواتك الحقيقية

الحلقة التي تعتمد فقط على نظام ملفات هي حلقة صغيرة جدًا. Connectors، المبنية على MCP، تتيح للوكيل قراءة تذاكر القضايا، استعلام قواعد البيانات، استدعاء API staging، إرسال رسائل Slack. كلا من Codex و Claude Code يتحدثان عن MCP، لذلك عادةً يمكنك استخدام connector الذي كتبته لوكيل واحد مباشرةً مع الآخر. الإضافات (Plugins) تجمع بين connectors و skills في حزمة واحدة، بحيث يمكن لزملائك تثبيتها مرة واحدة، بدلاً من إعادة بنائها من الذاكرة.

هذه هي الفارق بين "الوكيل يقول لك: هذا هو التعديل" و"الحلقة تفتح PR، تربط تذكرة Linear، وتُرسل إشعارًا بعد نجاح CI". Connectors هي السبب في أن الحلقة يمكنها العمل في بيئتك الحقيقية، وليس فقط لإخبارك "إذا كان يمكن، فسيقوم بذلك".

Sub-agents: فصل من يقوم بالعمل عن من يراجع

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

يُنشئ Codex subagent فقط عند الطلب، ويعمل بشكل متوازي، ويجمع النتائج ليعطي إجابة واحدة. في .codex/agents/، تعرف وكلائك باستخدام TOML، وكل واحد لديه اسم، وصف، تعليمات، اختيار نموذج، واعتبار الجهد المنطقي — يمكن أن يكون المراجع قويًا، أو سريعًا، أو للقراءة فقط. Claude Code يستخدم أيضًا .claude/agents/، وفرق الوكلاء، ويقومون بنقل العمل بين بعضهم البعض: exploration، تنفيذ، والتحقق من المواصفات.

لقد اقترحت سابقًا نماذج مثل "تنظيم وكيل الكود" و"مراجعة الكود العدائية". في الحلقة، هذا مهم جدًا لأنه يعمل عندما لا تكون متابعًا، ويجب أن تثق في المراجع. Subagent يستهلك رموز tokens أكثر لأنه يحتاج إلى تشغيل نماذج وأدوات مستقلة، لذا يُستخدم فقط عندما تحتاج إلى رأي ثانٍ.

نموذج /goal في Claude Code يعتمد على ذلك: يقرر نموذج جديد ما إذا كانت الحلقة مكتملة، وليس النموذج الذي يكتب الكود — "المنفذ مقابل المراجع" يُطبق على شرط التوقف نفسه.

كيف يبدو شكل الحلقة

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

يبدأ automation يوميًا في المستودع. يستدعي prompt خاص بـ triage، لقراءة فشل CI، القضايا المفتوحة، الالتزامات الأخيرة، ويكتب كل ذلك في ملف markdown أو لوحة Linear. لكل اكتشاف مهم، يفتح خيط عمل معزول، يرسل وكيلًا لاقتراح الحل، ثم يرسل وكيلًا آخر لمراجعة المهارات الحالية والاختبارات على المسودة.

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

عند مراجعة ما قمت به، أنت فقط صممت مرة واحدة. لا يوجد خطوة تتطلب prompt منك. هذا هو تطبيق قول Steinberger: "الحلقة تتكرر بشكل تلقائي." ويمكن تشغيل نفس الحلقة على Codex وClaude Code، لأن المكونات هي نفسها.

ما لا تزال الحلقة تقوم به

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

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

فهمك لا يزال يتدهور، طالما سمحت بذلك. كلما أسرعت في إصدار المنتج "غير الذي كتبته بنفسك"، زاد الفجوة بين "ما هو موجود" و"ما تملكه حقًا". هذا هو دين الاستيعاب (comprehension debt). حلقة سلسة ستسرع من ذلك، إلا إذا قرأت ما تفعله الحلقة.

الوضع المريح هو وضع خطير. عندما تدير الحلقة بنفسك، ستشعر برغبة في التوقف عن التدخل، وتركها تعود إليك النتائج. أسمي ذلك "الاستسلام المعرفي" (cognitive surrender). تصميم الحلقة بحيث تعمل وأنت تملك الحكم هو علاج، لكن عندما تريد تجنب التفكير، يصبح تسريعًا — نفس الحركة، لكن بنتائج معاكسة.

بناء الحلقة، لكن الاستمرار كمهندس برمجيات

أعتقد أن هذا هو مستقبل عملنا. ومع ذلك، إذا لم أراجع الكود بنفسي، أو اعتمدت كليًا على الحلقة التلقائية، فإن جودة المنتج ستتدهور. ربما أجد نفسي في دوامة هبوط، أعمق وأعمق.

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

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

لهذا السبب، تصميم الحلقة أصعب من prompt engineering، وليس أسهل. تركيز تشيرني ليس على جعل العمل أبسط، بل على نقل نقطة الرافعة (leverage point).

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