Codex يتيح لك رفع الحد الأقصى للوكلاء الفرعيين إلى 64. إليك ما سيتعطل أولاً.

مقتطف إعدادات يتداول هذا الأسبوع: اضبط agents.max_concurrent_threads_per_session = 64 في ملف config.toml الخاص بـ Codex وشاهد جلسة واحدة تتفرّع إلى عشرات الوكلاء الفرعيين. المنشور الذي بدأ ذلك يزعم أن القيمة الافتراضية هي 3 وأن OpenAI اختبرت 64. الإعداد حقيقي. أما الرقمان فليسا في التوثيق، والجزء المثير ليس الحد الأقصى بحد ذاته، بل ما يحدث للعمل عند رفعه.

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

باختصار

يحدّد agents.max_concurrent_threads_per_session عدد خيوط الوكلاء المنشأة التي يُبقيها Codex مفتوحة في آنٍ واحد، دون احتساب الخيط الرئيسي. ولا ينشر المرجع قيمة افتراضية؛ بل يقول إن Codex يختار واحدة عندما يكون المفتاح غير مضبوط. تُعيد الوكلاء الفرعية ملخصات إلى الخيط الرئيسي، الذي ينتظرها جميعاً ويردّ مرة واحدة، وتوصي الوثائق بها للمهام كثيفة القراءة مع التحذير من أن سير العمل المتوازي كثيف الكتابة يُنشئ تعارضات وحملاً تنسيقياً. ورفع الحد إلى 64 يضغط على هاتين النقطتين تحديداً: الملفات المشتركة واستجابة موحّدة واحدة لا يستطيع أحد تدقيقها. يشغّل Sharkly ‏Codex كبيئة تشغيل ويرفع التوازي مستوى واحداً، حيث تكون كل عملية تشغيل مهمةً لها شجرة عمل خاصة وسجل خاص ومراجع خاص.

ما الذي يفعله الإعداد

هناك ثلاثة مفاتيح في قسم [agents] بملف config.toml تهمّنا هنا. والصياغة أدناه مأخوذة من مرجع الإعدادات.

وهناك مفتاحان مرتبطان، agents.default_subagent_model وagents.default_subagent_reasoning_effort، يحدّدان ما تعمل عليه الوكلاء المنشأة ما لم يحدّد استدعاء الإنشاء خلاف ذلك.

إذن يعمل المقتطف كما هو مكتوب:

[agents]
max_concurrent_threads_per_session = 64

ما لا يقوله المرجع هو ما القيمة الافتراضية، أو أن أي قيمة قد اختُبرت. تعامل مع «الافتراضي 3» و«OpenAI اختبرت 64» كادعاءات من منشور، لا من المورّد، حتى تقول الوثائق غير ذلك.

يضيف دليل الوكلاء الفرعيين جملتين تحدّدان ما إذا كان رفع الحد فكرة جيدة. عن النتائج: «عندما تعمل وكلاء كثيرون، ينتظر Codex حتى تتوفر جميع النتائج المطلوبة، ثم يُعيد استجابة موحّدة.» وعن الملاءمة: تناسب الوكلاء الفرعية «المهام كثيفة القراءة مثل الاستكشاف والاختبارات والفرز والتلخيص»، وينصح الدليل بالحذر مع «سير العمل المتوازي كثيف الكتابة، لأن الوكلاء التي تحرّر الكود في آنٍ واحد يمكن أن تُنشئ تعارضات وتزيد الحمل التنسيقي.»

اقرأ هاتين معاً وسيترتّب لك تسلسل الفشل من تلقاء نفسه.

ما الذي يفشل أولاً: نسخة العمل المشتركة

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

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

الحل هو ذاك الذي تتقارب عليه كل تهيئات الوكلاء المتوازية: نسخة عمل واحدة لكل وحدة عمل. في Sharkly، تحصل كل عملية تشغيل لمهمة على دليل معزول، ويستخدم العمل المدعوم بالمستودعات شجرة عمل git منفصلة لكل تشغيل، وهي الآلية التي يغطيها الوكلاء المتوازية في أشجار عمل معزولة. عشر مهام على مستودع واحد، دون أي حالة مشتركة. ويمكن أن تظل بيئة التشغيل التي تُجري التحرير هي Codex؛ فالعزل يُوفَّر حولها.

ما الذي يفشل ثانياً: الاستجابة الموحّدة

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

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

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

ما الذي يفشل ثالثاً: الإنسان في الحلقة

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

يُبقي Sharkly حالة المهمة وحالة عمل الوكيل منفصلتين: يمكن للمهمة المُبدَأة أن تُظهر Working، أو Waiting for human reply، أو Waiting for human review، أو Error. وتصل إشارات الانتظار والفشل إلى القسم الأساسي في صندوق الوارد الخاص بالشخص المسؤول، وردّ على المهمة يُبدأ عملية التشغيل التالية مع الخيط كسياق. فالعالق يُخبرك، بدل أن يعلق داخل انتظار لا تستطيع فحصه.

وكلاء فرعية أم مهام؟ ثنائية قرار

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

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

رفع الحد بالطريقة الآمنة

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

سعة المزوّد هي ما ينساه الناس. أربعة وستون خيطاً على مفتاح API واحد تعني أربعاً وستين طريقة لبلوغ حد المعدّل في آنٍ واحد، وخطأ 429 الذي يعني «نفاد الحصة» لا يُصلح بإعادة المحاولة. يحتفظ سجل التشغيلات الفاشلة في Sharkly باستجابة المزوّد الأصلية إلى جانب عنوان مبسّط، فيكون الفرق مرئياً قبل أن يُعيد أحد المحاولة.

الأسئلة الشائعة

ما القيمة الافتراضية لـ agents.max_concurrent_threads_per_session؟ لا يذكر مرجع الإعدادات أي قيمة. بل يقول إن Codex يختار القيمة الافتراضية عندما يكون المفتاح غير مضبوط. والأرقام المتداولة على وسائل التواصل الاجتماعي ليست من المرجع.

هل يجعل رفع الحد Codex أسرع؟ في التفرّع كثيف القراءة، تنتهي خيوط أكثر أسرع. وفي العمل كثيف الكتابة، تحذّر الوثائق من أن التحريرات المتزامنة تُنشئ تعارضات وحملاً تنسيقياً يكلّف وقتاً أكثر مما يوفّره التوازي.

هل تعمل وكلاء Codex الفرعية في أشجار عمل git منفصلة؟ لا يقول دليل الوكلاء الفرعيين ذلك. خطّط على أساس أنها تتشارك دليل العمل ما لم تكن قد أعددت العزل بنفسك.

كيف يستخدم Sharkly ‏Codex؟ كبيئة تشغيل. الحاسوب الذي يشغّل Codex يُبلّغ عنه كمتاح، والمهام المُسندة إلى وكيل على ذلك الحاسوب تُنفَّذ من خلاله، كل تشغيل في دليله أو شجرة عمله المعزولة.

هل يمكنني الاستمرار في استخدام وكلاء فرعية داخل مهمة Sharkly؟ نعم. كل ما تستطيع بيئة التشغيل فعله بمفردها يظل يعمل داخل التشغيل. ويضيف Sharkly المهمة والعزل والسجل والمراجعة حوله.

الخلاصة المختصرة

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