أعطِ model قادرًا حقًّا مهمةً كبيرة وفوضوية، وراقب ما يحدث. يبدأ بقوة، ويؤدّي عملًا حقيقيًا، ثم — في مكان ما بعد منتصف الطريق — يعلن النجاح ونصف الـ checklist لم يكتمل. أو “يراجع” مخرجاته بنفسه فيُجيزها. أو ينسى بهدوء القيد الوحيد الذي كان يقلقك أكثر من غيره. الذكاء لم يكن موضع شكّ قط. الإدارة هي التي كانت كذلك.
ثمّة طريقة مفيدة لتسمية هذا: الـ coding agents اليوم عباقرة تُساء إدارتهم. الـ model يعرف أصلًا أكثر من أي فرد في فريقك. ما ينقصه هو مدير — شيء يحدّد العمل بدقة، ويقسّمه إلى أجزاء بالحجم المناسب، ويسلّم كل جزء لعقل جديد، ويراجع النتائج قبل اعتبار أي شيء منجزًا. الـ recursive agents هي أوضح إجابة نملكها عن مشكلة الإدارة هذه. هذا الدليل يتناول المبادئ الكامنة خلفها، بلغة بسيطة، ولماذا هي في الحقيقة قصةٌ عن الثقة.
عبقري تُساء إدارته: الفجوة ليست في الذكاء
لعامين تقريبًا، كان الافتراض أن AI أفضل يعني model أذكى، وأن model أذكى يعني عملًا أكثر موثوقية. ارتفعت القدرة بسرعة — لكن فجوة الموثوقية أبَت أن تُغلق بالوتيرة نفسها. يستطيع الـ model أن يتفوّق في اختبار استدلال صعب ويظلّ يُخفق في مهمة طويلة متعدّدة الأجزاء، لا لأنه صار أغبى، بل لأن المهمة الطويلة تعاقب نقاط ضعف مختلفة: البقاء على الهدف طوال ساعة، ومقاومة إغراء تصحيح المرء لورقته بنفسه، وإبقاء خمسين متطلبًا صغيرًا كلها نصب العين في آنٍ واحد.
هذه ليست إخفاقات ذكاء، بل إخفاقات موظف لامع بلا مدير. وإعادة التأطير هذه مهمّة، لأنها تغيّر ما تلجأ إليه. لو كانت المشكلة في الذكاء، لانتظرت model أكبر. أما وأن المشكلة في الإدارة، فيمكنك إصلاحها الآن — بوضع بنية أفضل حول الـ model الذي بين يديك بالفعل.
وهنا الجزء الذي يفاجئ الناس: بالبنية الصحيحة، يمكن لـ model متواضع أن يسبق آخر أكبر منه بكثير في هذا النوع من العمل. الـ model الكبير حين يُطلب منه فعل كل شيء في مرور واحد يحمل المهمة كاملة في عقل واحد مزدحم. أما الـ model الأصغر، حين يُمنح مديرًا يقسّم العمل إلى أجزاء صغيرة مُراجَعة، فلا يضطرّ إلى ذلك. التنسيق يتراكم أثره. وهذا أوضح دليل على أن عنق الزجاجة لم يكن يومًا القوة الذهنية الخام — بل الطبقة الغائبة من التحديد والتنسيق والتحقّق. الثقة ليست إلا كلمة أخرى للموثوقية، والموثوقية نتيجة إدارية.
ما معنى “recursive” فعلًا
ابدأ بـ agent عادي. كما نوضّح في ما هو الـ AI agent، يعمل ضمن loop — يتصرّف، ويلاحظ النتيجة الفعلية، ويقرّر الخطوة التالية، مرارًا وتكرارًا، حتى تكتمل المهمة. عقل واحد، context واحد، يكدح في المهمة.
الـ recursive agent يضيف حركة واحدة: يستطيع أن يستدعي نفسه. حين يواجه مهمة أكبر من أن تُحمَل في عقل واحد، لا يحاول ابتلاعها كاملة — بل يُطلق نسخًا من نفسه بوصفها sub-agents، ويسلّم كلّ واحدة شريحة صغيرة محدّدة جيدًا بـ context خاص جديد، ثم ينسّق نتائجها. ولأن كل sub-agent هو نفسه agent كامل، يمكنه فعل الشيء نفسه: تقسيم شريحته أكثر، وإطلاق sub-agents خاصة به، والنزول مستوىً أعمق. تمتدّ الـ recursion إلى العمق الذي تتطلّبه المشكلة.
التشبيه البشري هو مدير جيد يفوّض. أنت لا تحقّق بنفسك في كل خيط من مشروع كبير — بل تسلّم جزءًا لشخص قادر، وقد يسلّم هو بدوره جزءًا من حصّته لشخص آخر، وهكذا، وكلٌّ مركّز على أمر واحد ويرفع نتيجته لمن فوقه. لا أحد يحمل المشكلة كاملة في رأسه دفعةً واحدة، وهذا بالضبط سبب إنجازها على نحو جيد. الـ recursive agent هو ذلك الهيكل التنظيمي، مُجمَّعًا عند الطلب من أجل مهمة واحدة.
بقية هذا الدليل هي دليل المدير العملي: الحفنة من المبادئ التي تقرّر ما إذا كان كل هذا التفويض سيُنتج شيئًا يمكنك الوثوق به — أم مجرّد فوضى أكبر وأسرع.
المبدأ 1 — استكشِف الـ context، لا تبتلعه
الغريزة مع model قوي أن تُطعمه كل شيء — الـ codebase كاملًا، وكل مستند، والتاريخ بأكمله — وتتركه يرتّب الأمور. لكن هذه الغريزة تأتي بنتائج عكسية. كما نشرح في هندسة الـ context، ذاكرة الـ model العاملة كبيرة لكنها محدودة، والنافذة المزدحمة تُنتج إجابات أسوأ من المركّزة. احشُر كل شيء فيها، وتغرق الإشارة التي يحتاجها الـ model في ضجيج لا يحتاجه.
الـ recursive agents تقلب هذه العلاقة. فبدل أن يُصبّ الـ context داخل الـ agent، يجلس الـ context خارجه — بوصفه ملفات ومجلدات ومساحة عمل يتنقّل فيها الـ agent — ويتعامل الـ agent معه بوصفه شيئًا يستكشفه، فيجلب فقط الشريحة التي يحتاجها في اللحظة التي يحتاجها فيها. يقرأ ملفًا واحدًا، فيتعلّم شيئًا، فيقرّر ما ينظر إليه تاليًا. وحين يحتاج جزء من المهمة إلى انتباه عميق، يحصل ذلك الجزء على sub-agent خاص به بنافذة نظيفة خاصة، فلا يضطرّ أي عقل منفرد إلى حمل الأمر كله.
المكسب العملي أن “أكبر من أن يتّسع” يكفّ عن كونه جدارًا. فالمهمة التي كانت ستفيض عن أي context window واحد — repository متشعّب، أو مجلد فيه مئات المستندات — تصبح قابلة للمعالجة، لأنها ليست كلها في مكان واحد في آنٍ واحد. يشتغل الـ agent على المادة كما تشتغل أنت على خزانة ملفات: لا بحفظ كل مجلد، بل بمعرفة كيف تجد المجلد الصحيح.
المبدأ 2 — دَع الـ agent يقسّم العمل بنفسه
هنا الخطّ الذي يفصل بين recursive agent حقيقي وتقليدٍ يبدو ذكيًا. يمكنك بناء pipeline ثابت بيدك — “قسّم المُدخل إلى عشر قطع، وشغّل agent على كل قطعة، وادمج النتائج.” هذا مفيد، لكنه ليس recursive بالمعنى المهم: أنت من قرّر الشكل مسبقًا، وهو يقسّم كل مهمة بالطريقة نفسها سواء ناسبها ذلك أم لا. أعطِه مهمة هي في الحقيقة ثلاث مشكلات متفاوتة متنكّرة في هيئة مهمة واحدة، وسيظلّ يقطعها عشر شرائح متساوية.
الـ recursive agent يقرّر تقسيمه الخاص. ينظر إلى المهمة الفعلية ويستنتج كم جزءًا فيها، وأيّها كبير بما يكفي للتفويض، وإلى أي عمق يتكرّر في كلٍّ منها، ومتى يتوقّف. التقسيم قرار يتّخذه الـ model بشأن هذه المهمة تحديدًا، لا قالب فرضته على كل مهمة. وهذا ما يبقيه موثوقًا كلما صارت المهام متكتّلة وغير متوقّعة — وهي أجزاء العمل الحقيقي التي يتعامل معها الـ script الثابت أسوأ تعامل.
هذا دقيق لكنه محوري، لذا يستحقّ أن يُقال بوضوح: الـ map-reduce المكتوب مسبقًا ليس recursive agent. كلاهما يُطلق sub-agents؛ لكن واحدًا فقط يتكيّف. حين تقيّم أداة أو تكتب prompt، فهذه هي العلامة التي تبحث عنها — هل يختار الـ agent كيفية تقسيم المشكلة، أم أن التقسيم رُسِّخ قبل أن يرى العمل أصلًا؟
المبدأ 3 — المراجِع ليس هو الكاتب أبدًا
اطلب من model أن يفحص مخرجاته وفق معيار تقييم، فسيميل إلى إجازتها. هذا ليس كسلًا؛ إنه الجذب نفسه الذي يشعر به المرء وهو يدقّق كتابته — تقرأ ما قصدته، لا ما هو مكتوب فعلًا. المراجِع الذي كتب الشيء أيضًا مراجِعٌ متساهل، والمراجعة المتساهلة هي حيث تتسلّل النتائج غير الموثوقة حاملةً ختم الموافقة.
الإصلاح الـ recursive بنيويّ: الـ agent الذي يتحقّق من قطعة عمل هو agent مختلف عن الذي أنتجها، بـ context خاص جديد ومهمة واحدة — أن يجد الخطأ. وادفع الأمر أبعد فيصبح الفحص عدائيًا: أطلِق sub-agent مهمّته الصريحة أن يهاجم النتيجة، وأن يدحضها وفق المعيار بدل أن يباركها. عدّة متشكّكين مستقلّين خير من فحص واحد مُجامِل. (هذا أحد الأنماط الأساسية في الـ dynamic workflows، حيث يكتب agent script يقرن كل ملاحظة بـ verifier منفصل.)
وسبب أهمية هذا الكبيرة للثقة أن أكثر نمطَي الفشل شيوعًا في مهمة طويلة — التوقّف مبكرًا وتصحيح المرء لورقته بنفسه — كلاهما فشل في التقييم الذاتي. الـ agent الذي لا يدرك أنه أنجز 60% فقط، أو لا يرى الخلل في إجابته، لا يُصلَح بجعله أذكى بل بجعل الفحص مهمّة شخص آخر. فصل المهام فكرة قديمة في كل مؤسسة جادّة. والـ recursive agents تستعيرها.
المبدأ 4 — جهّز كل sub-agent عن قصد
الـ sub-agent لا يفوق قيمته ما يُمنح. أرسِل واحدًا لأداء مهمة دون الـ tool المحدّد الذي يحتاجه، أو دون الـ context الذي يحدّد معنى “الجيد” لهذه المهمة، وسيرتجل — بثقة، وغالبًا على نحو خاطئ. معظم عمل الـ sub-agents غير الموثوق يعود لا إلى model سيّئ، بل إلى model سيّئ التجهيز: لم يمتلك قط ما تطلّبته المهمة.
لذا فالنمط الموثوق أن تعلن، سلفًا، ما يحصل عليه كل sub-agent بالضبط قبل أن يبدأ: الـ tools المسموح له باستخدامها، والـ skills أو المواد المرجعية التي يحتاجها، وشريحة الـ context التي تخبره كيف يبدو النجاح. يفعل هذا أمرين في آن. يجعل الـ sub-agent قادرًا — فبين يديه الأدوات الصحيحة للعمل — ويجعل النظام كله واضحًا مقروءًا، لأنك (والـ agent الأب) تستطيعان رؤية بماذا جُهّزت كل قطعة، ومن ثمّ ما كان بوسعها فعله وما لم يكن. المهمة التي تفشل لأن sub-agent افتقر إلى tool هي فشل قابل للتشخيص. أما التي تفشل لأن أربعين شيئًا كانت متاحة على نحو غامض فاختار الخطأ منها، فليست كذلك.
هذا هو المحرّك الهادئ للموثوقية في هذا النهج كله. إنه أقل بريقًا من agent يُطلق سربًا من نسخه، لكن “كل sub-agent أُعطي بالضبط ما تطلّبته مهمّته، ولا شيء لم تتطلّبه” هو ما يفصل recursive agent تثق به عن عرضٍ مبهر يعمل مرة واحدة ثم لا يتكرّر أبدًا.
المبدأ 5 — احتفظ بالتشغيلات التي نجحت
في المرة الأولى التي يحلّ فيها agent مشكلة صعبة جديدة حلًّا جيدًا، يكون قد حدث شيء ثمين يسهل التفريط فيه: تسلسل — كيف فكّك المهمة، وبأي ترتيب اشتغل، وما الفحوص التي أجراها، وما الـ tools التي استخدمها كل خطوة. شغّل المهمة نفسها من جديد غدًا، وستكون تعتمد على الحظّ من جديد في أن يجد المسار الجيد نفسه.
الحركة هي أن تلتقط التشغيل الناجح وتحوّله إلى وصفة قابلة لإعادة الاستخدام. خذ session سار على ما يُرام واحفظ شكله — التقسيم، وخطوات التحقّق، والتجهيزات التي احتاجتها كل مرحلة — في workflow تستطيع توجيهه إلى مهام مشابهة لاحقًا. أنت لا تحفظ الإجابة؛ بل تحفظ الطريقة. وإذا أُحسِن ذلك، يصير النجاح لمرة واحدة نجاحًا قابلًا للتكرار، وهذا هو اللعبة كلها حين يكون هدفك الموثوقية لا عرضًا حالفه الحظّ.
ثمّة حدّ يستحقّ التسمية: الوصفة الملتقَطة موثوقة للمهام التي تشبه تلك التي جاءت منها، وأقل موثوقية كلما ابتعدت عنها. إنها قالب تكيّفه، لا تعويذة تردّدها — على الـ recursive agent أن يتعامل مع workflow محفوظ بوصفه شكلًا مبدئيًا يستطيع تعديله، لا script يشغّله بعمى. وبهذا الاستخدام، يصبح التقاط التشغيلات الناجحة طريقةَ تراكم الفريق: كل مشكلة صعبة حُلّت جيدًا تصير عونًا لمن يصطدم بعدها بمثلها.
متى تكون الـ recursion الأداة الخطأ
كل هذا قويّ، ما يجعله مغريًا للإفراط في استخدامه — وهذا هو الخطأ الذي يجب الاحتراس منه. للـ recursion تكاليف حقيقية: كل sub-agent يستهلك tokens، وكل مستوى عمق إضافي يزيد الـ latency، والـ agent الذي يبالغ في التقسيم قد يراكم فاتورةً وهو يفعل بأسطول ما كان agent واحد سيفعله في مرور واحد.
لذا فالسؤال الصادق قبل اللجوء إلى recursive agent هو: هل تتجاوز هذه المهمة فعلًا عقلًا واحدًا في context واحد؟ معظم العمل لا يتجاوزه. تعديل سريع، سؤال عادي، مراجعة واحدة — يتولّاها agent واحد على ما يُرام، ولفّها في recursion لا يفعل سوى حرق الحوسبة بلا مكسب. احفظ هذه الآلية للمهام الكبيرة فعلًا، أو المتوازية فعلًا، أو العدائية بحيث لا يسعها context واحد: migration على مستوى الـ repo، أو تدقيق عبر مئات الملفات، أو تحقيق عميق بنظريات متنافسة.
وحين تلجأ إليها، قيّدها عن قصد. حدّ العمق يضبط كم مستوى يمكن أن تنزل الـ recursion. ميزانية الـ tokens تضبط ما يمكن أن تُنفقه. وشرط التوقّف الواضح — لا ملاحظات جديدة، ولا أخطاء متبقّية، والهدف تحقّق على نحو يمكن إثباته — ينهيها حين يكتمل العمل بدل تركها تقرّر بنفسها. هذه الحواجز الواقية فظّة، لكنها ما يمنع أداة قوية من أن تصير أداة لا يمكن التنبّؤ بها. القوة بلا ميزانية ليست موثوقية؛ بل مجرّد مخاطرة بإخراج أفضل.
الصورة الأكبر: الموثوقية هي الثقة
تراجع خطوةً إلى الوراء، فإذا النهج كله فكرة واحدة تتكرّر عند كل مستوى: لا تجعل الـ model أذكى — امنحه مديرًا. حدّد العمل، وقسّمه إلى أجزاء بالحجم المناسب، وسلّم كلًّا منها لعقل جديد مجهَّز كما ينبغي، وافحص النتائج مع شخص غير الكاتب، واحتفظ بالطرق التي تنجح. لا شيء من هذه الحركات غريب. إنها ما تفعله المؤسسات الجيدة دائمًا مع الموهوبين، منقولةً إلى models موهوبة.
لهذا يتجاوز الأمر مجرّد الآليات. فالسبب في أن “الـ agent” لم يصر بعدُ “زميل فريق” في معظم العمل الجادّ هو الثقة، والثقة ليست إلا موثوقية كسبتها مع الوقت. الـ model الذي لا تستطيع التنبّؤ به model عليك أن تراجعه مرتين، وهذا يلغي معظم الرافعة. المبادئ هنا — استكشِف الـ context بدل ابتلاعه، ودَع الـ agent يقسّم عمله بنفسه، وافصل المنفّذ عن الفاحص، وجهّز كل قطعة عن قصد، واحتفظ بالتشغيلات التي نجحت، وقيّد الأمر كله — هي كيف تحوّل القدرة الخام إلى نتائج يمكنك الاعتماد عليها فعلًا.
الذكاء موجود بالفعل. العمل المثير الآن هو الإدارة. وإن أخذت شيئًا واحدًا من هذا: الـ recursive agent قوةٌ كبيرة موجَّهة إلى مشكلة واحدة، وقوة كهذه تستحقّ حواجز واقية. استخدم الـ recursion بمسؤولية.