لماذا لا يتوقف وكيلك أبدًا Image: AI generated

التباهي بالتشغيل المستمر 24/7

“أنا أشغّل الوكيل على مدار 24 ساعة.”

عبارة كثيرًا ما نراها على X. وكأن الوكيل كلما طال تشغيله أنجز المزيد من العمل. وكأن الإنسان يصبح أكثر إنتاجية حين لا ينام.

لكن الشعور الذي ينتابني أمام هذه الجملة ليس الإعجاب بل التساؤل.

“لماذا لم ينتهِ بعد؟”

النظام السليم هو النظام القادر على التوقف

أوكلتُ إلى الوكيل مهمة كتابة اختبارات لـ 527 دالة. النتيجة:

الوكيل المستقل:  أنجز 40 / 527 ثم أعلن "لقد أتممت كل شيء"
حلقة الـ CLI:    أكمل 527 / 527 حتى النهاية ثم توقف

استغرقت حلقة الـ CLI ساعة واحدة. لا 24 ساعة. تعالج دالة واحدة، وتتحقق منها، وإذا نجحت تنتقل إلى التالية، وحين تنتهي جميعها تتوقف. جوهر هذه الحلقة ليس السرعة بل أن شرط الإنهاء معرّف آليًا.

TODO → كتابة الاختبار → قياس التغطية → PASS/DONE → التالي → ... → اكتمال الكل → توقّف

finite. measurable. monotonic. لذلك تتقارب. لذلك تتوقف.

القدرة على التوقف ليست نقطة ضعف. بل تعني أن النظام سليم.

ثلاثة أسباب لعدم التوقف

عندما يعمل وكيل لفترة طويلة، فغالبًا ما يكون السبب واحدًا من ثلاثة.

1. المُحقِّق ضعيف

"looks good"
"seems better"
"more scalable"
"clean architecture"

هذه ليست معايير تقارب. إنها أحكام ذاتية. go test يُعيد pass/fail، لكن من يحكم على “clean architecture”؟ LLM آخر؟ هذا أشبه بأن تسأل صديقك الثمل “هل أنا ثمل؟”.

والأدلة التجريبية تؤكد ذلك. تتحيّز أحكام LLM المستخدمة لتقييم الكود حتى أمام التحويرات السطحية لكود ذي معنى متطابق، فتتضخم الدرجات أو تُخصم بلا وجه حق (Moon et al. 2025)، وتُذعن النماذج فتُغيّر إجابتها في 58.19% من الحالات (SycEval, Fanous et al. 2025). “looks good” لا علاقة لها بالصحة. علاوة على ذلك، فإن المعيار الضعيف لا يكتفي بعدم التوقف — فحين يصبح القياس هدفًا ينهار القياس (قانون غودهارت؛ Manheim & Garrabrant 2018)، وتلجأ نماذج الاستدلال القادرة إلى اختراق إجراء التحقق نفسه بدلًا من حلّ المهمة مباشرة (Bondarenko et al. 2025).

دون معيار تقارب، لا نهاية.

2. لا حدود للمهمة

"حسّن قاعدة الكود"
"اجعل المعمارية أنظف"
"استمر في التحسين"

هذه مهام بلا شرط إنهاء. حتى المطور البشري يتيه إلى ما لا نهاية مع أهداف كهذه. والوكيل ليس مختلفًا. “التحسين” اتجاه وليس وجهة.

3. الإنتروبيا تتجاوز سرعة التصحيح

أكثر الأنماط شيوعًا وأكثرها مكرًا.

أثناء التعديل يضيف الوكيل تجريدات. يُدخل مستويات غير مباشرة. يصنع تعميمات لا لزوم لها. يبدو الكود وكأنه “يتحسّن”، لكن في الواقع تتراكم إنتروبيا جديدة أسرع من سرعة المُحقِّق في إزالتها.

يُنشئ التجريد اليوم → يُزيله غدًا → يُضيفه مجددًا بعد غد

هذا تحسين غير رتيب (non-monotonic optimization). يبدو كأنه يتقدّم إلى الأمام لكنه يراوح مكانه. يبدو كآلة حركة دائمة لكنه يستهلك الطاقة فحسب. والطاقة في هذه الحالة هي الـ tokens.

ترصد الأدلة التجريبية واسعة النطاق هذا الانحراف. رفع تبنّي Cursor السرعة على المدى القصير، لكن تحذيرات التحليل الساكن وتعقيد الكود ظلّا يتزايدان باطّراد، وكان هذا التراكم السبب الرئيس في تباطؤ السرعة على المدى الطويل (He et al. 2025، 807 مستودعًا مفتوح المصدر). ومن بين أكثر من 300 ألف commit كتبها الذكاء الاصطناعي، نجا 22.7% من المشكلات المُدخَلة كدَين تقني حتى أحدث إصدار (Liu et al. 2026). التصحيح لا يلحق بالإنتروبيا.

ليست مشكلة بحث بل مشكلة إرضاء قيود

هنا يتجلّى فرق جوهري في وجهة النظر.

القول بأن “تشغيل الوكيل لفترة أطول يعطي نتائج أفضل” يرى هندسة البرمجيات كـمشكلة بحث (search problem). توقّع أن البحث الطويل في فضاء واسع سيُفضي إلى حل أفضل.

لكن هندسة البرمجيات في جوهرها مشكلة إرضاء قيود (constraint satisfaction problem).

  • يجب أن تتطابق الأنواع
  • يجب أن تنجح الاختبارات
  • يجب أن تتحقق التغطية
  • يجب أن يتطابق الـ schema
  • يجب الالتزام بقواعد الـ lint

حين تُرضى هذه القيود جميعها، انتهى الأمر. لا حاجة لـ"مزيد من البحث". تعريف القيود، وإرضاؤها، والتوقف. هذا كل شيء.

الكود أصلًا مجال قابل للتحقق آليًا (machine-checkable domain). المُصرِّف، ومُدقِّق الأنواع، والاختبارات، والتغطية، والـ linter، والتحقق من الـ schema — كل هذه محقّقات حتمية. ما دامت هذه المحقّقات موجودة، فلماذا نُبقي الوكيل يبحث بلا نهاية؟

وأبحاث التعلّم تشير إلى الاتجاه نفسه. حين تُستخدم محقّقات حتمية كاختبارات الوحدة كمكافأة — مكافأة قابلة للتحقق (verifiable reward) — ترتفع صحة الكود مقارنةً بالتوليد المفتوح (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). المُحقِّق ليس أداة لتضييق البحث. بل هو دليل على أن هذه المشكلة من الأساس ليست بحثًا بل إرضاءً.

شروط الحلقة الجيدة

تنغلق حلقة الوكيل الجيدة عبر خمس مراحل:

1. تعريف المهمة   — ما الذي يجب تحقيقه (هدف قابل للحكم آليًا)
2. تحديد النطاق   — وحدة واحدة في كل مرة (دالة، endpoint، ملف)
3. تحقق رمزي     — أداة حتمية تحكم بـ pass/fail
4. التقارب       — إذا نجح فالتالي، وإذا فشل فإعادة المحاولة مع تغذية راجعة
5. الإنهاء       — إذا لم يبقَ عنصر، توقّف

في هذه البنية، يتولّى الـ LLM المرحلة 3 (التوليد) فقط. أما البقية فتتولّاها الآلة بالكامل. والأهم أن الآلة هي التي تقرّر “النهاية”. إذا أوكلتَ قرار الإنهاء إلى الـ LLM، فستسمع “لقد أتممت كل شيء” عند 40/527.

والتجارب تشير إلى الاتجاه نفسه. حين تُضيف نقدًا ذاتيًا (self-critique) إلى الـ LLM، ينهار أداؤه فعليًا في مهام الاستدلال والتخطيط، ولا يتحسّن بقدر كبير إلا حين تُضاف محقّقات خارجية سليمة (Stechly et al. 2024). والتصحيح الذاتي الجوهري دون تغذية راجعة خارجية يفشل، بل أحيانًا يزداد سوءًا بعد التصحيح (Huang et al. 2023). ثمة سبب لعدم إيكال الإنهاء إلى الـ LLM.

creative writing تختلف عن الكود

ثمة استثناء واحد. ليست كل المجالات هكذا.

الكتابة، والتسويق، والتصميم — هذه مجالات محقّقها ضعيف. لا يمكن الحكم آليًا على “هل هذه الجملة جيدة؟”. في مثل هذه المجالات قد يكون للبحث الطويل معنى. أن يُولّد الوكيل تنويعات عدة، ويختار الإنسان منها.

لكن الكود مختلف. الكود عالم مليء أصلًا بالمحقّقات الحتمية. في هذا العالم، التيهان الطويل (wandering) ليس بحثًا بل انحرافًا (drift).

سؤال

كم ساعة يعمل وكيلك الآن؟

هل هو يتقارب، أم ينحرف؟

هل يستطيع التوقف؟

وإن كان يستطيع، فلماذا لم يتوقف بعد؟

مقالات ذات صلة

قراءات إضافية (خارجية)

  • Designing agentic loops — Simon Willison. يجب أن تتوفّر معايير نجاح واضحة ومجموعة اختبارات ناجحة كي تتحقق حلقة الوكيل من نفسها وتتوقف — النظير البنّاء لهذا المقال.
  • Building Effective Agents — Anthropic. السبب في أن البرمجة مثالية للوكلاء هو أن الحل قابل للتحقق باختبارات آلية — يصبح المُحقِّق الحتمي إشارة توقف.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. القرار التصميمي الجوهري ليس نموذجًا أفضل بل شرط إنهاء قابل للقياس، ويحذّر من “confidence laundering” حيث يُخفي المخرَج الطليق عدم التقارب.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. الموثوقية لا تأتي من النموذج بل من هارنس الأدوات الحتمية (computational controls) — تمييزًا لها عن التحكّم الاستدلالي القائم على الذكاء الاصطناعي.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. “حين يصبح القياس هدفًا، يكفّ عن كونه قياسًا جيدًا” — تلخيص تقني لآلية الغش بالبروكسي حين يُستخدم محقّق ضعيف كمكافأة.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. كلما تراكمت tokens الإدخال تدهور المخرَج — السبب الآلي وراء أن حلقة الإضافة والإزالة وإعادة الإضافة تصبح تعزيزًا ذاتيًا لا تصحيحًا ذاتيًا.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. يُضخّم الذكاء الاصطناعي الصرامة القائمة — وفي ظل صرامة منخفضة يُسرّع الفوضى، وهي رؤية عملية لظاهرة سبق الإنتروبيا للتصحيح.

المصادر

حدود التحقق الذاتي · الحكم بالإنهاء

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · عدم موثوقية النقد الذاتي

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

الانحراف · تزايد تعقيد كود الذكاء الاصطناعي

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

المكافأة القابلة للتحقق · توليد الكود المبني على المُحقِّق

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

اختراق المكافأة · التلاعب بالمواصفات

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)