هندسة الحلقة.
الكاتب الأصلي: Addy Osmani
مُجمَّع: بيجي، BlockBeats

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

يتكون هذا الدور تقريبًا من خمسة وحدات: Automations (اكتشاف وتصنيف المهام تلقائيًا وفقًا للجدول الزمني)، Worktrees (عزل بيئات تطوير متعددة متزامنة)، Skills (تراكم معرفة المشروع والممارسات الفريقية)، Plugins/Connectors (الربط مع أدوات حقيقية مثل GitHub وLinear وSlack وقواعد البيانات)، Sub-agents (فصل المنفذين عن المراجعين)، بالإضافة إلى طبقة ذاكرة خارجية، مثل ملفات Markdown أو لوحات Linear، لحفظ الحالة والتقدم.

تذكير المقال أن معنى Loop Engineering لا يقتصر على "جعل الذكاء الاصطناعي يجري عدة دورات"، بل يكمن في دمج حكم المهندسين في تصميم النظام مبكرًا. يمكن للدورات أن تضخم بشكل كبير كفاءة المطورين، لكنها لن تحل محل التحقق أو الفهم أو اتخاذ القرار. الخطر الحقيقي لا يكمن في استخدام الدورات، بل في استخدامها كذريعة لتجنب فهم الكود والنظام. ربما تكون القدرة الأساسية للتعاون المستقبلي مع الذكاء الاصطناعي في البرمجة ليست مجرد كتابة Prompt جيد، بل تصميم سير عمل Agent موثوق وقابل للتحقق ومستدام.

Below is the original text:

يقوم هندسة التكرار (Loop Engineering) باستبدال دورك كـ"شخص يكتب تعليمات للوكلاء". عليك تصميم نظام يُجري التعليمات للوكلاء نيابةً عنك. يمكن فهم "التكرار" هنا على أنه هدف تكراري: تُحدد هدفًا، ثم يقوم الذكاء الاصطناعي بالتكرار باستمرار حتى إكمال المهمة. وهو يتكون تقريبًا من خمسة مكونات، وقد امتلك الآن Claude Code وCodex هذه المكونات الخمسة.

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

قال @steipete مؤخرًا: "لا ينبغي لك أن تكتب تعليمات مباشرة لوكيل الترميز بعد الآن. يجب أن تُصمم دورات تُوجّه الوكلاء الخاصة بك." وبالمثل، قال @bcherny، المسؤول عن Claude Code في Anthropic: "لم أعد أُوجّه Claude مباشرة. لدي مجموعة من الدورات التي تعمل وتُوجّه Claude، وتحدد بنفسها الخطوة التالية. وظيفتي هي كتابة الدورات."

So what does this mean?

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

الآن، أنت تبني نظامًا صغيرًا: فهو يكتشف المهام بنفسه، ويوزع المهام، ويفحص النتائج، ويسجل الحالة المكتملة، ثم يقرر الخطوة التالية التي يجب اتخاذها. بمعنى آخر، تجعل هذا النظام يُدير الوكلاء بدلاً من أن تُوجههم يدويًا مرارًا وتكرارًا. لقد كتبت سابقًا "قريبه" — هندسة إطار العمل للوكيل (agent harness engineering)، وهي بناء بيئة تشغيل لوكيل واحد؛ ونموذج المصنع (factory model)، وهو نظام بناء البرمجيات. أما هندسة الحلقة (Loop engineering) فهي تقع على مستوى أعلى من إطار العمل. فهي تشبه إطار العمل، لكنها تعمل وفق مؤقت، وتُنشئ مساعدين صغار، وتُغذي نفسها ذاتيًا.

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

خمسة مكونات، بالإضافة إلى بعض التوضيحات

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

أولاً، Automations (المهام التلقائية): تُفعّل وفقًا للجدول، وتُنفّذ اكتشافًا وتصنيفًا تلقائيًا.

ثانيًا، Worktrees (أشجار العمل): تمنع عاملين يعملان بالتوازي من التداخل مع ملفات بعضهما البعض.

ثالثًا، المهارات: اكتب معرفة المشروع لتجنب اعتماد الوكيل على التخمين في كل مرة.

رابعًا، Plugins and connectors (الإضافات والموصلات): تمكّن الوكيل من الاتصال بالأدوات التي تستخدمها بالفعل.

خامسًا، Sub-agents (الوكلاء الفرعيون): واحد مسؤول عن اقتراح الحلول، والآخر مسؤول عن التحقق من الحلول.

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

الآن، كلا المنتجين يمتلكان هذه المكونات الخمسة.

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

التشغيل الآلي هو ما يجعل الحلقة تصبح حقًا حلقة، وليس مهمة مؤقتة قمت بتشغيلها يدويًا مرة واحدة. في تطبيق Codex، يمكنك إنشاء مهمة تشغيل آلي من خلال علامة التبويب "التشغيل الآلي"، واختيار المشروع، والنص الذي يجب تشغيله، وتكرار التشغيل، وما إذا كان سيتم تشغيله في بيئة التحقق المحلية الخاصة بك أو في بيئة العمل الخلفية. ستُرسل نتائج التشغيل التي تكتشف مشكلات إلى صندوق الوارد "التقسيم"، بينما سيتم أرشفة النتائج التي لا تكتشف أي مشكلات تلقائيًا، وهو أمر رائع. يستخدم فريق OpenAI الداخلي هذا أيضًا لأداء مهام مملة ولكن ضرورية، مثل تقسيم المشكلات اليومية، وتلخيص أسباب فشل CI، وكتابة تقارير الالتزام، وتتبع الأخطاء التي أدخلها الأشخاص الأسبوع الماضي. يمكن للمهام الآلية أيضًا استدعاء المهارات، لذا يمكنك الحفاظ على قابلية صيانة المهام المتكررة: تفعيل $skill-name بدلاً من لصق مجموعة كاملة من التعليمات في مهمة مجدولة لن يُحدّثها أحد في المستقبل.

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

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

لذلك، تقوم Automations بجلب العمل إلى السطح، بينما يتعامل الجزء المتبقي من loop مع هذه المهام.

بمجرد تشغيلك أكثر من عامل ذكي، تصبح تعارضات الملفات نقطة فشل. كتابة عاملين ذكيين في نفس الملف في نفس الوقت تشبه تمامًا مهندسين اثنين يعدلان نفس السطر من الكود دون أي تواصل. يمكن لـ git worktree حل هذه المشكلة. إنه دليل عمل منفصل على فرع مستقل، لكنه يشارك نفس سجل مستودع الكود، لذا لا يمكن لتعديلات عامل ذكي أن تلمس أبدًا checkout عامل ذكي آخر من الناحية المادية.

يحتوي Codex على دعم مدمج لـ worktree، مما يسمح لعدة خيوط بالتعامل مع نفس المستودع في نفس الوقت دون تعارض. يمكن لـ Claude Code أيضًا تحقيق نفس العزل من خلال git worktree: يمكنك فتح جلسة في checkout مستقل باستخدام علامة --worktree، أو ضبط isolation: worktree على subagent لمنح كل مساعد فرعي checkout جديد يُنظف تلقائيًا بعد الانتهاء. لقد كتبت عن الجانب البشري لهذا الأمر في "تكلفة التوجيه": تعمل worktrees على القضاء على التعارضات الميكانيكية، لكنك لا تزال محدودًا. ما يحدد حقًا عدد الوكلاء الذين يمكنك تشغيلهم في وقت واحد ليس الأداة، بل عرض نطاق مراجعتك.

الـ Skill هو آلية تتيح لك عدم إعادة شرح نفس مجموعة العناصر في كل جلسة كما لو كنت سمكة ذهبية. كلا الأداتين تستخدمان نفس التنسيق: مجلد يحتوي على ملف SKILL.md يحتفظ بالتعليمات والبيانات الوصفية؛ بالإضافة إلى ملفات نصية اختيارية ومراجع وموارد. يقوم Codex بتشغيل الـ skill عندما تستدعيه باستخدام $ أو /skills، كما يقوم تلقائيًا بتشغيله عندما يتطابق مهامك مع وصف الـ skill. وهذا هو السبب في أن الوصف الموجز والبسيط غالبًا ما يكون أفضل من الوصف الذكي أو المزخرف. يفعل Claude Code نفس الشيء، وقد كتبت عن هذا النمط في مهارات الوكلاء.

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

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

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

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

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

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

لقد ناقشت هذا الرأي مرتين من قبل: مرة في code agent orchestra، ومرة أخرى في adversarial code review. وهو مهم بشكل خاص داخل الحلقة، لأن الحلقة ستستمر في العمل عندما لا تكون مراقبًا، لذا فإن المدقق الذي تثق به حقًا هو السبب الوحيد الذي يجعلك تجرؤ على المغادرة. ستستهلك الوكلاء الفرعيون بالفعل المزيد من الرموز، لأن كل وكيل يقوم بإجراء مكالمات نموذجية وأدوات خاصة به، لذا يجب عليك استخدامها في المواقف التي تستحق دفع تكلفة رأي ثانٍ. وهذا بالضبط ما يفعله /goal في Claude Code على مستوى الأساس: استخدام نموذج جديد لتحديد ما إذا كانت الحلقة قد اكتملت، بدلاً من ترك النموذج الذي أنجز العمل هو من يقرر ذلك. بمعنى آخر، فهو يطبق فصل "المُنشئ" و"المُدقق" على شرط الإيقاف نفسه.

كيف يبدو حلقة؟

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

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

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

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

Loop لا يزال لن يفعل شيئًا نيابةً عنك

غيرت Loop طريقة العمل، لكنها لن تُزيلك من العمل. في الواقع، مع تقوية loop، تصبح ثلاثة مشاكل أكثر حدة، وليس أسهل.

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

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

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

بناء loop، ولكن لا تزال كمهندس

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

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

نتيجة Loop ستختلف من شخص لآخر. يمكن لشخصين بناء نفس Loop تمامًا، لكنهما يحصلان على نتائج متعاكسة تمامًا. يستخدم أحدهم Loop لتسريع العمل الذي يفهمه بعمق؛ بينما يستخدم الآخر Loop لتجنب فهم العمل نفسه. Loop لا تعرف الفرق بين هذين الأمرين. أنت تعرف.

هذا هو السبب في أن تصميم الحلقات (loop design) أصعب من هندسة المُحفزات (prompt engineering)، وليس أسهل. لم يكن قصد تشيرني أن العمل أصبح أسهل، بل أن نقطة الرافعة انتقلت.

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

[رابط الأصل]

انقر لمعرفة الوظائف الشاغرة لدى BlockBeats

مرحبًا بانضمامك إلى المجتمع الرسمي لـ BlockBeats

مجموعة تيليجرام للاشتراك: https://t.me/theblockbeats

مجموعة Telegram للنقاش: https://t.me/BlockBeats_App

الحساب الرسمي على تويتر: https://twitter.com/BlockBeatsAsia