صورة: من إنشاء الذكاء الاصطناعي
كل من أوكل عملًا كبيرًا إلى وكيل ذكاء اصطناعي يعرف هذا. الحلقة تنهار دائمًا عند النقطة نفسها: اللحظة التي يعلن فيها النموذج من تلقاء نفسه «لقد انتهيت» — بينما هو في الحقيقة لم ينتهِ.
reins هو إطار عمل Quest CLI ينتزع سلطة إعلان الإنجاز تلك من الذكاء الاصطناعي ويسلّمها إلى الآلة. يقسّم قائمة العمل إلى بنود مفردة كما تُقسَّم المهام في الألعاب إلى quests، ويعطيها للذكاء الاصطناعي واحدًا واحدًا، ويحكم على «هل انتهى؟» لا بكلام الذكاء الاصطناعي بل بفحص آلي. وفي قلبه تجلس وحدة صغيرة اسمها الـ turn.
كلمتان ستتردّدان في المقال، فلنثبّتهما أولًا.
- البوابة (gate) — فاحص يفحص المُقدَّم آليًا ويحكم عليه بنجاح (PASS) أو فشل (FAIL). لا انطباع إنسان، ولا تقييم ذاتي من الذكاء الاصطناعي.
- الـ ratchet (السقاطة) — ترس لا يدور إلا في اتجاه واحد. نستخدمه بمعنى أن البند الذي أُقفل بنجاحٍ مرةً لا يُفتح مرة أخرى أبدًا.
يتتبّع هذا المقال turn واحدًا من بدايته إلى نهايته، عبر ما يمرّ به بالضبط. يبدو الـ turn صغيرًا، لكنك إن فككته وجدتَه reins كلَّه في صورة مصغَّرة.
العناصر الستة الجوهرية في Reins Engineering
اضغط الهندسة التي يقف عليها reins في سطر واحد فتقرأ: هندسة نقل سلطة إعلان الإنجاز من الذكاء الاصطناعي إلى بوابة آلية حتمية. و«حتمية» هنا ليست كلمة صعبة؛ معناها أن المدخل نفسه يعطي دائمًا النتيجة نفسها. الاختبار إمّا يمرّ وإمّا يفشل، وحكم الأمس لا يختلف عن حكم اليوم بحسب المزاج.
في سلالة هندسة البرومبت (اختيار الكلمات) ← هندسة السياق (تقديم السياق) ← هندسة الهارنس (إقامة الأسوار)، يأتي Reins بوصفه اللجام الذي يضبط الاتجاه. تُجمَّع هذه الهندسة من ستة عناصر.
| # | العنصر | في سطر واحد | الجملة المعيارية |
|---|---|---|---|
| 1 | إنجاز تحكم به الآلة | يجب أن يكون شرط الإنجاز مما تجيب عنه الآلة بنعم/لا، والآلة هي التي تحكم — يُجرَّد الذكاء الاصطناعي من سلطة تقرير أنه انتهى | «الإنجاز تحكم به البوابة، لا يُدَّعى ادعاءً» |
| 2 | تغذية راجعة حتمية | حقائق لا آراء — «أين، وماذا كان ينبغي أن يكون، وماذا كان فعلًا» تصير الإشارةَ الدالّة على الإصلاح | «أعطِه آراءً يتملّق، وأعطِه حقائق يصحّح» |
| 3 | سياق اتجاهي (دليل + أمثلة) | إن كانت التغذية الراجعة إشارة تصحيح، فالدليل والأمثلة إشارتا اتجاه — لا يغني أحدهما عن الآخر | «عنق الزجاجة ليس الذكاء بل السياق» |
| 4 | Ratchet Pattern (قفل تعاقدي) | البند الذي مرّ لا يتغيّر، والعمل المتبقي لا يفعل إلا أن يتقلّص — الانتهاء مضمون بالبنية | remaining(t+1) ≤ remaining(t) |
| 5 | دوام التقدّم | التقدّم يعيش خارج العملية (على القرص) — حتى لو مات الذكاء الاصطناعي يبقى التقدّم | “Agents are disposable; progress is cumulative.” |
| 6 | صدّ الـ cheese (بوابات النطاق) | حتى الفحص الآلي يُخترَق بالحِيَل إن اكتفى بفحص القشرة — على البوابة أن تعيد التحقق من الحقائق الفعلية لنطاقها | «لكل بوابة نطاق» |
لا بأس إن ظلّت مصطلحات الجدول غريبة عليك. فالـ turn هو أصغر وحدة تلتقي فيها هذه الستة داخل دورة واحدة، ولذلك فإن تتبّع turn واحد حتى نهايته يجمع العناصر الستة كلَّها، كلًّا في موضعه. ولنرسم الخريطة مسبقًا: compose، أول خطوات الـ turn، يجمّع السياق الاتجاهي والتغذية الراجعة الحتمية؛ وjudge يصدر الحكم الآلي (صدّ الـ cheese هو جودة تصميم تلك البوابة)؛ وrecord يقفل الـ ratchet ويجعل التقدّم دائمًا.
ما هو الـ Reins Turn؟
الـ Reins Turn هو أصغر وحدة تنفيذ في reins، تُختتم فيها محاولة واحدة على بند quest واحد على هيئة توليد ← حكم ← تسجيل. فالحلقة ليست سوى تكرار للـ turns، وتقدّم الـ quest ليس سوى تراكم للـ turns. ولذلك يكفي التعريفَ سطرٌ واحد.
Turn N = المحاولة (Attempt) المسجَّلة رقم N. ما لم يُسجَّل ليس turn.
الـ Attempt هو «سجلّ واحد لمحاولة واحدة». وهنا نقطة دقيقة — الـ turn ليس «استدعاءً واحدًا للـ LLM». شرط وجود الـ turn ليس الاستدعاء بل التسجيل. إذا استُدعي الـ LLM لكن النتيجة لم تُسجَّل في الـ ratchet، فذلك الـ turn لم يحدث قط. وبالعكس: نتيجة قدّمها إنسان بيده، متى سُجِّلت، فهي turn. حتى من دون LLM. الذي يعدّ الـ turns ليس النموذج بل الـ ratchet.
هذا التعريف الواحد هو جذر كل الخصائص الآتية — استقلالية المُشغِّل، مناعة إعادة التشغيل، قابلية التدقيق. دَع الأسماء تمرّ الآن مرورًا؛ سنلقى كلًّا منها ثانيةً في موضعه.
الـ turn الواحد أربع خطوات بالضبط
يمرّ الـ turn بأربع خطوات على الترتيب. تحمل الخطوات أسماء إنجليزية، لكن ما تفعله بسيط — تجميع (compose)، وتوليد (generate)، وحكم (judge)، وتسجيل (record).
| الخطوة | ما تفعله | الخاصية |
|---|---|---|
| ① compose | تقرأ سجلّ كل الـ turns السابقة (الـ Log) وتجمّع البرومبت الذي سيُعطى للـ LLM | دالة نقية |
| ② generate | تستدعي الـ LLM مرة واحدة لإنتاج المخرَج | الخطوة الاحتمالية الوحيدة |
| ③ judge | تحكم البوابة على المخرَج (PASS / REVIEW / FAIL) | حتمية |
| ④ record | تطبّق الحكم على الـ ratchet وتحفظه على القرص | الخطوة الوحيدة غير القابلة للعكس |
«الدالة النقية» تعني أن المدخل نفسه يعطي دائمًا المخرج نفسه دون أي أثر جانبي آخر، و«غير القابلة للعكس» تعني أنها متى نُفِّذت لا يمكن التراجع عنها. عندئذٍ يتّضح جوهر الجدول — من الخطوات الأربع، ② وحدها احتمالية، و④ وحدها غير قابلة للعكس. التوليد لا يستطيع أن يحكم، والحكم لا يستطيع أن يولّد. عدم يقين الذكاء الاصطناعي محبوس في خانة واحدة، والقرار الذي لا رجعة فيه محبوس في خانة أخرى.
ولنقف عند خيار تصميمي غريب واحد. هذا التتابع الرباعي غير مُنفَّذ على هيئة نسختين من كود Go. بل هو معرَّف في وثيقة واحدة يقرؤها البشر اسمها pkg/cli/turn.md (وثيقة TANGEUL)، تُضمَّن في الملف التنفيذي (go:embed) وتُفسَّر وقت التشغيل. المصدر المعياري لـ«كيف يدور الـ turn» ليس كودًا بل وثيقة مقروءة — وسبب هذا الخيار يعود في نهاية المقال.
① compose — السياق لا يأتي إلا من الـ Log
الـ Log هو الدفتر، المحفوظ على القرص، الذي سُجِّلت فيه كل الـ turns حتى الآن. ومدخل تجميع برومبت الـ turn رقم N شيء واحد بالضبط: هذا الـ Log. أمّا حالةٌ تختبئ في مكان ما من ذاكرة البرنامج وتتلاشى بموت العملية — فلا وجود لشيء كهذا.
البرومبت المجمَّع من الـ Log ثلاث طبقات.
- ما يجب فعله — ما الذي ينبغي إنتاجه في هذا البند (تعليمات الكتابة وسياق التحقق)
- الدليل — البرومبت النظامي العام، مضافًا إليه، إن كان الـ turn السابق FAIL، تدريبُ القاعدة التي سبّبته (الدليل الخاص بكل قاعدة)
- ذيل التغذية الراجعة — حقائق الـ FAIL السابق. «أين، وماذا كان ينبغي أن يكون، وماذا كان فعلًا»
وبلغة العناصر الستة أعلاه: الدليل هو السياق الاتجاهي، وذيل التغذية الراجعة هو التغذية الراجعة الحتمية. وكلاهما يُجمَّع آليًا من الـ Log في كل turn.
وثمّة قاعدة دقيقة لكنها مهمة. ما يتّخذه compose مرجعًا ليس آخر Attempt، بل آخر Attempt حُكم عليه (judged) — أي اكتمل حتى صدور الحكم. حتى لو توسّط بينهما خطأ توليد كتعطّل خادم الـ LLM، فما تراه إعادة المحاولة ليس رسالة خطأ البنية التحتية بل التغذية الراجعة الوقائعية للـ FAIL السابق. أعطال التشغيل لا تلوّث سياق العمل.
② generate — الـ LLM لا يفعل سوى التوليد
يذهب البرومبت المجمَّع إلى الواجهة الخلفية للـ LLM في استدعاء واحد. ولا يهم أكانت الواجهة الخلفية HTTP API (ollama/xai/gemini) أم أداة سطر أوامر (claude/grok/codex/geminicli). في الحالين دورها ثابت: مولِّد. الإطار لا يكشف أي API يمكن عبره منح LLM سلطةَ PASS. لا أن الإطار «اختار ألا يمنح» سلطة الحكم — بل لا سبيل إلى منحها أصلًا. هكذا يصير العنصر 1 من الستة (الإنجاز الذي تحكم به الآلة) بنيةً.
حتى اختيار الواجهة الخلفية يُعاد حسابه من الـ Log في كل turn. البند الذي يواصل الفشل على النموذج الافتراضي يُرفَع إلى نموذج أقوى (التصعيد)، وهذا القرار أيضًا يُقرأ من الـ Log في كل turn — «هل بين القواعد المسبِّبة للـ FAILs الماضية قاعدةٌ من أهداف التصعيد؟». لا مفتاح مُبقًى مضاءً في مكان ما، ولا متغيّر محلي داخل الحلقة. البرنامج نفسه مع الـ Log نفسه — تُختار الواجهة الخلفية نفسها. وخاصية السلوك المتطابق بعد قتل العملية وإعادة تشغيلها — مناعة إعادة التشغيل — تأتي مجانًا.
③ judge — البوابة وحدها تحكم
الذي يحكم على المخرَج هو البوابة. والبوابة مجموعة قواعد لكشف الانتهاكات. كل قاعدة تنطلق (fire) حين تجد المشكلة الموكلة إليها، وتترك وراءها حقيقة واحدة — أين (Where)، وماذا كان ينبغي أن يكون (Expected)، وماذا كان فعلًا (Actual).
والتجميع حتمي. إن انطلقت ولو قاعدةُ Fail واحدة، فالحكم FAIL. وإلا، فإن انطلقت قاعدة Review، فالحكم REVIEW (منطقة رمادية يفحصها إنسان). وإن لم ينطلق شيء، فـ PASS. المُقدَّم نفسه مع القواعد نفسها — الحكم نفسه دائمًا. لا يوجد هنا فاحص يتبدّل جوابه في كل مرة تسأله.
وفي النطاقات المعقّدة التي تتشابك فيها القواعد — حيث يجعل انتهاكٌ واحد فحصًا آخر بلا معنى — يمكن رفع الحكم إلى رسم حجاجي (toulmin)، ونقل منطق الحكم نفسه إلى وثيقة قابلة للتدقيق (gate.md). وأيًّا كانت الصورة، فشيء واحد لا يتغيّر: الحاكم آلة.
④ record — الخطوة الوحيدة غير القابلة للعكس
طبّق الحكم على الـ ratchet، واحفظ على القرص، وصدِّر (export) البنود التي اختُتمت. هذه هي النقطة الوحيدة في الـ turn التي لا يمكن التراجع عنها.
- PASS / REVIEW / SKIPPED / BLOCKED ← قفل. الـ ratchet أحادي الاتجاه؛ لا يعود إلى الوراء.
- FAIL ← يزيد عدّاد المحاولات (
Tries) واحدًا ويبقى البند TODO. وعند بلوغ الحد الأقصى للمحاولات (الافتراضي 3) يُقفل بوصفه DONE. فـ«هذا البند لا يُفلح بهذه الطريقة» صورةٌ من صور الاختتام أيضًا — لا يُسمح لبند عالق واحد أن يحتجز الحلقة كلها رهينةً إلى الأبد. - خطأ التوليد ← يُسجَّل في الـ Log بوصفه Attempt (يُحفَظ أثر ما جرى)، لكنه لا يستهلك محاولة. تعطّل خادم الـ LLM ليس ذنب البند بل عطل تشغيلي. وإن استمر العطل، أوقف الحلقةَ صمّامُ أمان منفصل (التوقف بعد N إخفاقات توليد متتالية — قاطع دارة).
بهذه الخطوة وحدها يوجد الـ Log الذي سيقرؤه compose في الـ turn التالي. الـ record خاتمة الـ turn ومولِّد الـ turn التالي.
الفشل حقيقة لا رأي
بأي هيئة يعود الـ FAIL — هذا مفتاح تقارُب الـ turn (اقترابه من الجواب مع كل إعادة محاولة). لا رأيٌ من قبيل «الجودة ناقصة بعض الشيء»، بل هذا:
FAIL. root cause = who-anchor-present
Fact: where=who.anchors expected="source substring" actual="نائب المدير خالد الأحمد"
قراءتها بسيطة. أي حقل (where)، وماذا كان ينبغي أن يكون (expected — سلسلة موجودة فعلًا في المصدر)، وماذا كان فعلًا (actual). الموضع + القيمة المتوقَّعة + القيمة الفعلية. هذه، بالنسبة إلى الـ LLM، تغذية راجعة لا أحد فيها ليتملّقه — فالأرقام والمواضع ليست مشاعر. وهذه الحقيقة المهيكلة هي التي تقود النموذجَ المتملِّق لا إلى الجدال بل إلى التقارب.
وعلاوةٌ فوق ذلك. نصّ الـ FAIL الذي يُطعَم للنموذج هو العرض ذاته بالضبط للسلسلة التي تُطبع على الشاشة حين ينفّذ إنسان أمر submit (تكافؤ التغذية الراجعة — feedback parity). التغذية الراجعة التي يراها الإنسان والتي يراها النموذج لا تفترقان أبدًا. ولغز «ما الذي أُرسل إلى الذكاء الاصطناعي حتى أصلحه هكذا؟» غائب بنيويًّا.
ثلاث نقاط دخول، turn واحد
لنسمِّ من يدير الـ turn مُشغِّلًا (driver). في reins ثلاثة مشغِّلات: next حيث يتلقّى الإنسان البرومبت مباشرةً، وsubmit حيث يقدّم الإنسان النتيجة، وloop الآلي غير المُراقَب. لكن هذه ليست ثلاثة تنفيذات منفصلة. إنها ثلاث نقاط دخول إلى وثيقة الـ turn نفسها. والذي يفصل اليدوي عن الآلي قاعدةٌ واحدة بالضبط داخل الوثيقة.
الخاصية العملية التي يمنحها هذا: بدِّل المشغِّلات في منتصف الـ quest ويبقى البرومبت متطابقًا بايتًا ببايت. شغِّل الـ loop الآلي أمس، وليتسلّم إنسانٌ بـ next اليوم — ما دامت حالة الـ Log واحدة، يخرج البرومبت نفسه. وهذا ممكن لأن السياق لا يأتي إلا من الـ Log (رأينا ذلك في الخطوة ①)، وهو خاصية مُثبتة لا أمنية — اختبار ذهبي لتبديل المشغِّلات (driver-swap golden test) يتحقق من التطابق البايتي بمقارنة المخرجات عبر المشغِّلات.
تتبُّع turn واحد حتى النهاية
انتهت النظرية. لنشاهد turn حقيقيًا واحدًا من البداية إلى النهاية. هو بند واحد في quest يستخرج عناوين البريد الإلكتروني من الوثائق، في محاولته الثانية بعد أن فشل الـ turn السابق بـ FAIL لأن «الصيغة ليست بريدًا إلكترونيًا صحيحًا».
[فحص بدء الـ turn] هل البند TODO؟ هل بقيت محاولات؟ ← تقدَّم
① compose اعثر في الـ Log على آخر Attempt حُكم عليه ← FAIL، السبب = email-format
الدليل = البرومبت العام + تدريب قاعدة email-format
البرومبت = ما يجب فعله + "FAIL. Fact: where=email
expected='valid email format' actual='kim at example'"
② generate استدعاء الـ LLM ← {"email":"kim@example.com", ...}
③ judge مسح القواعد: email-format تمرّ، source-lacks-email تمرّ، freemail تمرّ
← لم تنطلق أي قاعدة Fail ← PASS
④ record الـ ratchet يقفل (لا رجعة) ← تسجيل Attempt #2 ← حفظ ← export
النموذج، وقد أُعطي حقيقةَ الفشل السابق («kim at example ليست صيغة بريد إلكتروني صحيحة»)، أصلح ذلك الموضع بعينه؛ والبوابة أكّدت المرور؛ والـ ratchet أقفله. هذا البند الآن PASS إلى الأبد. الـ turn التالي يتخطّاه، والعمل المتبقي لا يفعل إلا أن يتقلّص. وحين يبلغ كل بند حالةً مختتمة (PASS أو REVIEW أو بلوغ الحد الأقصى للمحاولات) تنتهي الحلقة. لا «حين يشعر الذكاء الاصطناعي بأنه انتهى» بل حين تبلغ البنود المتبقية صفرًا. التقارب مضمون بالبنية.
Loop Engineering — الصناعة سمّت المشكلة نفسها
في يونيو 2026، نال تحوّلٌ في طريقة التعامل مع الوكلاء اسمًا. كتب Peter Steinberger: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents” (لم يعد ينبغي لك أن توجّه البرومبت إلى وكلاء البرمجة؛ بل أن تصمّم الحلقات التي توجّه البرومبت إلى وكلائك)، وفي مطلع الشهر نفسه قال Boris Cherny من Anthropic، صانع Claude Code، في إحدى الفعاليات: “I don’t prompt Claude anymore. I have loops running… My job is to write loops” (لم أعد أوجّه البرومبت إلى Claude. لديّ حلقات تدور… عملي هو كتابة الحلقات). وبعد أيام، أطلق Addy Osmani من Google على هذا التيار اسم Loop Engineering — من شخص يوجّه البرومبت إلى الوكلاء، إلى شخص يصمّم الأنظمة التي توجّه البرومبت إلى الوكلاء.
يرسم هذا الخطاب سردية انتقال واحدة. هندسة البرومبت (اختيار الكلمات) ← هندسة السياق (اختيار المعلومات التي تُعرَض) ← هندسة الهارنس (بناء بيئة التنفيذ) ← هندسة الحلقات (تصميم دورة الملاحظة-الفعل-التحقق-التعافي نفسها). لقد انتقلت الرافعة طبقةً فطبقة نحو الخارج: من الكلمات إلى المعلومات، ومن المعلومات إلى البيئة، ومن البيئة إلى الدورة.
وتشريح Osmani للحلقة الجيدة لن يبدو غريبًا على من قرأ حتى هنا. أخرِج الحالة إلى القرص أو إلى لوحة، لا إلى المحادثة. افصل الوكيل الذي يبني عن الوكيل الذي يتحقق. اجعل الإنهاء يؤكّده حَكَمٌ منفصل، لا إعلانَ وكيل البرمجة الذاتي. ضَع ذلك بجانب الـ turn يتّضح التناظر بحدّة.
| توصية Loop Engineering | هيكلة الـ turn في reins |
|---|---|
| أخرِج الحالة إلى القرص أو إلى لوحة (النموذج ينسى) | الـ Log ليس مُعينًا للذاكرة بل المدخل الوحيد للـ turn — compose دالة نقية على الـ Log |
| افصل الباني عن المتحقق (وكلاء فرعيون) | المتحقق ليس LLM آخر بل بوابة حتمية — لا وجود أصلًا لـ API يمنح PASS |
| عرِّف شروط إنهاء قابلة للاختبار | رتابة الـ ratchet تضمن التقارب بوصفه لامتغيِّرًا — بنية لا شرطًا |
| ميِّز الإخفاقات القابلة للتعافي من القاتلة | مدمج في قواعد record — الـ FAIL يستهلك محاولة، وأخطاء التوليد من نصيب قاطع الدارة |
جوهر الفرق هو المسافة بين التوصية والبنية. أدبيات هندسة الحلقات نفسها تقرّ بتراتبية التحقق — إسناد الحكم إلى ذكاء اصطناعي (LLM-as-judge) “can be gamed or can collude with the actor” (يمكن التلاعب به أو أن يتواطأ مع الفاعل)، فحيثما أمكن فحصٌ حتمي، ضَع فحصًا حتميًا. لكن ذلك يبقى ممارسةً فضلى — توصيةً موكولة إلى حُسن نيّة المصمِّم. وإن كان الوكيل الفرعي المتحقق هو الآخر LLM في نهاية المطاف، فباب التواطؤ يظل مفتوحًا. reins يغلق ذلك الباب بالتصميم. البوابة وحدها تحكم، والإطار لا يكشف أي سبيل لإعطاء LLM حكمَ PASS.
وحيث تتحدث هندسة الحلقات عن الحلقة كلها، يحوّل reins دورةً واحدة من تلك الحلقة إلى عقد. فلكي نتقدّم خطوة أبعد من قول Cherny «عملي هو كتابة الحلقات»، لا بد أولًا من تعريف ما الذي تفعله الحلقة في الدورة الواحدة — ما الاحتمالي، وما الحتمي، وما الذي لا رجعة فيه. واسم ذلك التعريف هو الـ turn.
لماذا هذه الوحدة
أحكِم الـ turn هكذا تربح ثلاثة أشياء. والأسماء التي مرّت بنا عابرةً تجد مواضعها هنا.
- قابلية التدقيق — الجواب عن «بمَ يختلف الـ loop الآلي عن الـ next اليدوي؟» ليس عمليةَ مقارنة بين نسختي كود بل قاعدة واحدة في وثيقة. يمكنك أن تتأكد بعينيك أن في الوثيقة مسارًا واحدًا بالضبط يستطيع قفل PASS. لهذا كان المصدر المعياري للـ turn وثيقةً مقروءة لا كودًا.
- مناعة إعادة التشغيل — كل مدخلات الـ turn مشتقّة من الـ Log على القرص، فحتى لو ماتت العملية، يعيد الـ Log نفسُه إنتاجَ الـ turn نفسه.
- قابلية الاستغناء عن الوكلاء — بدِّل الوكلاء (نماذج LLM، المشغِّلات) ويظل التقدّم يتراكم ولا يتراجع أبدًا. “Agents are disposable; progress is cumulative.”
وبالعكس: النظام الذي يكون فيه الـ turn ضبابيًا — حيث يختبئ السياق في ذاكرة الجلسة، ويعلن النموذج الإنجاز بنفسه، وتتّكئ إعادة المحاولة على تاريخ المحادثة — يخسر الثلاثة كلها.
يبدو الـ turn صغيرًا. لكنه، بوصفه أصغر وحدة تفصل التوليد (الاحتمال) والحكم (الحتمية) والتسجيل (اللارجعة) وتسلسلها داخل دورة واحدة، فمن فهم الـ turn فقد فهم reins كله.
مقالات ذات صلة
- reins — لا يبقى من Quest CLI سوى النطاق، والـ ratchet يصير إطارًا — الإطار الذي هو بطل هذا المقال، في نسخته الكاملة.
- Ratchet Pattern — كيف تجعل الوكيل يكمل المهمة حتى النهاية — المعالجة الكاملة للقفل التعاقدي (العنصر 4 من الستة).
- كيفية صنع Quest CLI — بناء أداة تجعل الآلة هي من يحكم على الإنجاز بنفسك — المخطط العملي: أجزاء الـ quest الخمسة، تصميم البوابات، صدّ الـ cheese.
- كود السقاطة الذي يستغل IFEval — التجربة التي تُنتج فيها التغذيةُ الراجعة الحتمية + السياق الاتجاهي تقاربًا.
- Reins Engineering — الذكاء الاصطناعي بلجام — إعلان سلالة البرومبت←السياق←الهارنس←Reins.
- TANGEUL — قواعد مكتوبة بالماركداون، يراجعها البشر — لماذا المصدر المعياري للـ turn وثيقة.
للمزيد من القراءة (مصادر خارجية)
- Building Effective Agents — Anthropic — الكلاسيكية في تصميم حلقات الوكلاء. تمييزها بين «مسارات العمل (تنسيق حتمي) والوكلاء (بقيادة النموذج)» يتردّد صداه مع فصل التوليد/الحكم في هذا المقال.
- Agentic Loops: From ReAct to Loop Engineering — Data Science Dojo — مسح لسلالة حلقات الوكلاء، من ReAct إلى هندسة الحلقات.
- The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops — The New Stack — تغطية صناعية لتحوّل Boris Cherny.
المراجع
- Loop Engineering — Addy Osmani — 2026-06. تسمية المصطلح وتشريح الحلقة الجيدة (الأتمتة، وworktrees، والمهارات، والوكلاء الفرعيون، والحَكَم المنفصل، وإخراج الحالة).
- What Is Loop Engineering? A Complete Guide from Prompt to Harness Engineering — Tosea.ai — الانتقال الرباعي برومبت←سياق←هارنس←حلقة، وتراتبية التحقق التي تقدّم الحتمية، وخطر تواطؤ LLM-as-judge.
- Claude Code’s Creators Explain Agent Loops — The Neuron — Boris Cherny وCat Wu في تفاصيل تشغيل الحلقات:
/loopو/goal، وإخراج الحالة إلى القرص وLinear، وفصل البُناة عن المتحققين.
سجل التغييرات
- 2026-07-07: الطبعة الأولى