لماذا يبدو وكيل البرمجة عالقًا أثناء التفكير: زمن الوصول إلى أول رمز

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

هذه ليست مشكلة جديدة، لكن إصدارات 2026-09-22 زادت الأمر سوءًا بطريقة محددة وقابلة للقياس. أعلى إعدادات التفكير في النماذج الجديدة تشتري الدقة بالتفكير الطويل قبل النطق بأي شيء. رصدت Artificial Analysis أن النسخة "القصوى" من التفكير في GPT-6 Sol تستغرق 102.15 ثانية حتى أول رمز، وGPT-6 Luna تستغرق 124.23 ثانية. هذه قياسات طرف ثالث على تهيئة محددة، وليست أرقامًا من المورّد، وهذا التحفظ مهم، لكن الاتجاه لا لبس فيه: الصمت في بداية التشغيل أصبح الآن طويلًا بما يكفي ليصبح غير قابل للتمييز عن الفشل.

الخلاصة السريعة

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

الانتظار طال، والنموذج الرخيص ليس هو السريع

إليك ما تقوله قياسات الطرف الثالث عن نموذجي GPT-6 الجديدين عند إعداد التفكير الأقصى.

اقرأ العمودين الأخيرين معًا. تكلّف Luna عشر ما يكلّفه Sol لكل رمز، وتجعلك تنتظر وقتًا أطول قبل أن تتكلم. التكلفة وزمن الاستجابة محوران منفصلان، والحدس القائل بأن النموذج الأرخص هو النموذج الأسرع هو ببساطة خطأ هنا.

تحفظان صادقان قبل أن يبني أي أحد لوحة متابعة على تلك الأرقام. أولًا، هي مصدرها Artificial Analysis وليست من OpenAI، وهي تصف نسخ التفكير "القصوى" تحديدًا. أما إعدادات الجهد الأدنى فهي شيء مختلف، وأرقامك أنت ستتغير حسب حجم المطالبة وتوافر الأدوات والمكان الذي يصل إليه مرورك. ثانيًا، الوقت حتى أول رمز ليس القياس نفسه لسرعة الإخراج. تقول Anthropic إن Claude Opus 5.5 ينتج إخراجًا أسرع بنحو 30% من Opus 5، وهذا تصريح عن الرموز التالية للأول. يمكن لنموذج أن يبث بسرعة ويتركك مع ذلك محدقًا في لا شيء لمدة دقيقة ونصف.

الطرفية الصامتة ليست حالة

للصمت في الطرفية أربعة أسباب على الأقل، والطرفية تعرضها جميعًا بالمظهر نفسه:

1. بيئة التشغيل تعمل. يجري التفكير، ولا إخراج بعد.
2. التشغيل انتهى منذ فترة وهو ينتظر إجابة إنسان على سؤال.
3. الطلب فشل. توثيق Sharkly صريح في مدى سهولة إساءة قراءة هذا: "Timeout / 408 / 504 تعني أن الطلب كان بطيئًا أو ملغى أو متأخرًا بسبب بوابة. هذا ليس نفس أن يكون الجهاز غير متصل."
4. الجهاز فعلًا اختفى، أو أن المجلد الذي احتاجه التشغيل لم يكن متاحًا أبدًا.

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

رد الفعل التلقائي الذي يلجأ إليه الناس هو إيقافه وإعادة تشغيله. عند جهد التفكير العالي يكون هذا الرد الفعل مكلفًا مرتين. تدفع كامل انتظار أول رمز مرة أخرى، وترمي التفكير الذي كان على وشك أن يصل.

ما يجب أن تفصله الحالة

يستحق نموذج Sharkly نفسه أن يُحتذى به سواء استخدمت Sharkly أم لا، لأنه يفصل بين شيئين تدمجهما الطرفية. إنه الفصل نفسه الذي يجعل حالة التشغيل والسجلات وإشارات الفشل مقروءة أصلًا. للتشغيل حالة تنفيذ: Queued، Dispatched، Waiting for local directory، Running، Completed، Failed أو Canceled. وللمهمة حالة دورة حياة، وللوكيل حالة عمل فوقها: Working، Waiting for human reply، Waiting for human review أو Error. ويذكر التوثيق الحد الفاصل بصراحة: حالات التشغيل هذه "لا تعني تلقائيًا أن المهمة تحمل حالة سير العمل نفسها."

هذا الفصل هو الجواب الكامل على سؤال "عالق أم يفكر".

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

مهلة المهمة لكل مهمة التي ضبطتها في مارس

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

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

هناك إعدادان مرتبطان يستحقان المراجعة نفسها. الحد الأقصى للمهام المتوازية الجارية هو حد التزامن الحقيقي لديك، وعندما تكون كل المجلدات المهيّأة مشغولة، تجلس التشغيلات الجديدة في Waiting for local directory بدل أن تفشل، وهو سلوك صحيح يبدو كتعليق إذا كنت تراقب طرفية فقط.

هل يحل التخزين المؤقت المشكلة؟

جزئيًا، وليس الجزء الذي تريده. يمنح تخزين المطالبات المؤقت من OpenAI لـ GPT-6 خصمًا بنسبة 90% على قراءات الإدخال المخزنة مؤقتًا مع معدلات إصابة أعلى افتراضيًا، ويضيف نقاط توقف صريحة لتختار أين ينتهي بادئة مخزنة، ولم يعد يكسر الذاكرة المؤقتة عند تغيير جهد التفكير أو توافر الأدوات. ويذكر GitHub انخفاضًا بأكثر من 50% في رموز المطالبات التي تحتاج معالجة جديدة عبر مليارات الطلبات. هذا مكسب حقيقي في التكلفة وزمن الاستجابة على المطالبة، وإصلاح تغيير الجهد مفيد فعلًا للوكلاء الذين يصعّدون مهمة من إعداد رخيص إلى إعداد مكلف في منتصف المسار.

لكنه لا يزيل تمريرة التفكير. الذاكرة المؤقتة الدافئة تعني أن جزءًا أقل من مطالبتك يُعالج من الصفر. لا تعني أن النموذج قد فكّر بالفعل في العلّة عندك. خصّص ميزانية للانتظار على أي حال.

متى تدفع ثمن الانتظار ومتى لا

استخدم إعداد التفكير الأقصى عندما تكون المهمة مما لا تريد تشغيله مرتين: ترحيل، أو إعادة هيكلة شاملة، أو أي شيء تكلّف فيه الإجابة الخاطئة أكثر من تسعين ثانية. تذكر OpenAI أن Sol عند إعداد xhigh يسجل 33.2% في AutomationBench 1.0.6 بتكلفة $0.27 للمهمة، وهذا هو شكل المقايضة. الدقة اليوم رخيصة بالمال ومكلفة بالوقت الفعلي.

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

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

ما لا يصلحه هذا

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

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