يعرض سيرجيو بانييغو في مقال مجتمعي على مدونة Hugging Face طريقة متكاملة لتدريب وكيل برمجي باستخدام OpenCode، مع تشغيل كل تجربة في صندوق Hugging Face بعيد ومعزول. وتعتمد الطريقة على دمج TRL وOpenEnv وAsyncGRPO، بحيث يدير الوكيل حلقة استخدام الأدوات بنفسه كما يعمل في التطبيق الفعلي، بينما يقرأ المدرب ما حدث ويستخدم الرموز التي أنتجها الوكيل مباشرة في التدريب.
الفكرة الأساسية هي ما يسميه المقال نمط «الحلقة التي يملكها الوكيل». ففي الأسلوب المعتاد لتدريب وكيل عبر التعلم المعزز، يقود المدرب الحلقة بنفسه: يولد دوراً، ويفسر استدعاءات الأدوات، وينفذها، ثم يعيد النتائج إلى النموذج. أما في هذا النمط، فيشغّل OpenCode حلقته الكاملة دون أن يقود TRL الأدوار المتعاقبة. وبعد انتهاء المهمة، يدرب TRL النموذج على الرموز الفعلية التي أنتجها الـ harness، بدلاً من تدريب نسخة موازية من الحلقة.
البنية المكونة من أربعة أجزاء
تتصل أربعة مكونات رئيسية عبر TRL وOpenEnv. أولها الـ harness، وهو OpenCode داخل جلسة OpenEnv معزولة؛ إذ يحصل كل rollout على حاوية لها نظام ملفات وعمليات خاصة بها، وتبدأ من صورة Docker تتضمن الـ harness، ثم تنفذ حلقة الأدوات كاملة على مساحة عمل حقيقية.
المكون الثاني هو وكيل وسيط شفاف بين الـ harness وخادم vLLM. يسجل هذا الوكيل كل استدعاء للنموذج مع معرّفات الرموز واحتمالاتها اللوغاريتمية لكل دور. ووفق المقال، تتيح هذه الآلية التدريب على الرموز الحقيقية التي أصدرتها السياسة، من دون إعادة ترميزها أو تخمينها.
أما المكون الثالث فهو أداة تحقق تعتمد على اختبارات مخفية لحساب المكافأة. يعرّف المستخدم دالة verify() تفحص مساحة العمل النهائية وتعيد المكافأة. وفي المثال المعروض، تأتي مسائل البرمجة من مجموعة agentica-org/DeepCoder-Preview-Dataset، بينما تُستخدم الاختبارات المخفية الخاصة بكل مسألة لتقييم الملف solution.py ومنح الوكيل مكافأة بحسب نسبة الاختبارات التي ينجح فيها.
المكون الأخير هو المدرب. بعد انتهاء الـ harness، يعيد TRL بناء عينات التدريب من الأدوار المسجلة، ثم يشغّل GRPO وينقل المكافأة إلى كل رمز مدرَّب عبر أفضلية نسبية داخل المجموعة. ويستخدم المثال عاملاً واحداً مع ضبط harness_adapter=None لتفعيل نمط امتلاك الوكيل للحلقة، كما يحدد دالة المكافأة ودالة لاختيار أدوار الأفعال بدلاً من النثر النصي.
صندوق بعيد لكل تجربة
يمكن تشغيل الـ harness محلياً عبر عملية فرعية، لكن ذلك يقيّد عمليات التشغيل بجهاز واحد. وللتوسع، يستخدم المثال الواجهة HFSandboxBackend من خلال صورة ghcr.io/huggingface/openenv-opencode-sandbox:latest. وتحتوي الصورة مسبقاً على الـ harness والوكيل الوسيط، ما يلغي الحاجة إلى تثبيت بارد في كل تجربة.
بهذا الإعداد، يحصل كل rollout على صندوق نظيف ومعزول، ويمكن تشغيل الصناديق بالتوازي عبر السحابة، مع بقاء منطق التدريب نفسه. ولتشغيل المكونات الثلاثة في مهمة واحدة على Hugging Face Jobs، يلفّ المشغّل خدمة vLLM، ونفق الوصول إليها، والمدرب داخل مهمة واحدة. ويعرض المقال مثالاً يستخدم النموذج Qwen/Qwen3-8B، و32 مسألة، و10 خطوات تدريب.
عنوانان لخادم vLLM
يحتاج الإعداد البعيد إلى التمييز بين عنوانين لخادم vLLM. يستخدم المدرب العنوان المحلي، مثل http://localhost:8000، لأن المدرب وvLLM يعملان على العقدة نفسها ويتزامنان عبر NCCL. في المقابل، تحتاج الصناديق البعيدة إلى عنوان يمكن الوصول إليه من خارج العقدة، ويُمرر في المتغير sandbox-vllm-url. ويمكن أن يكون هذا العنوان خادماً عاماً أو نفقاً إلى الخادم المحلي.
يشير المقال إلى أن الصناديق البعيدة تعمل على نكهة cpu-basic بتكلفة تقارب 0.01 دولار في الساعة لكل instance، ولذلك تبقى آلاف عمليات التشغيل منخفضة التكلفة نسبياً. أما التكلفة الرئيسية فتأتي من مهمة GPU واحدة تشغّل vLLM والتدريب.
التحذيرات والنتائج
يتطلب التشغيل البعيد عناية تشغيلية أكبر من العملية المحلية؛ فقد يتأخر بدء الصندوق، أو يفشل أثناء التنفيذ، أو يظل قيد التشغيل بعد انتهاء المهمة. لذلك يوصي المقال بمتابعة الصناديق المتروكة وإغلاقها ومعالجة الصناديق الفاشلة. كما يحذر من أن النفق العام المستخدم في العرض غير موثق، وينبغي في الاستخدام الذي يتجاوز التجارب المؤقتة توجيه sandbox-vllm-url إلى خادم يمكن الوصول إليه مع ضوابط وصول مناسبة.
في تجربة قصيرة باستخدام Qwen3-8B و10 خطوات على 32 مسألة، ارتفعت المكافأة من نحو 0.27 إلى نحو 0.71، مع تذبذب وreward_std بين 0.4 و0.5 تقريباً. ويؤكد المقال أن هذه النتيجة لا تمثل تدريباً طويلاً، لكنها تشير إلى اكتمال المسار وقدرة GRPO على التعلم من الرموز التي أنتجها الوكيل.
كما يذكر بانييغو أن تجربة سابقة باستخدام Qwen3-4B-Instruct-2507 والصناديق البعيدة لم تستقر؛ فقد ارتفعت المكافأة لخطوات قليلة ثم انهارت، بينما بدأ الوكيل بإرسال استدعاءات أدوات متكررة دون حل المسائل. ويرجح المقال أن السبب مزيج من قِصر التدريب، وتأخر التشغيل غير المتزامن عن بعد، وفشل بعض الصناديق، وصعوبة النموذج الأصغر في اكتساب نقطة انطلاق على هذه المسائل. وكان الانتقال إلى Qwen3-8B هو ما جعل التجربة اللاحقة قابلة للتعلم.
ويصف الكاتب التكامل الحالي بأنه إصدار أولي يتطلب اختيار الواجهة الخلفية للصندوق وربط عنواني vLLM يدوياً. أما الخطوة التالية فتتمثل في إعادة هيكلة حول Harbor لتدريب مجموعة من وكلاء البرمجة، مثل Claude Code وPi وCodex وOpenCode وCursor، عبر مسار واحد مع واجهات خلفية متعددة للصناديق.