لماذا تهم حلقات الوكلاء الأسرع
تقول OpenAI إنها أعادت بناء البنية التحتية خلف Responses API لجعل سير العمل بنمط الوكيل أسرع بشكل ملحوظ، في خطوة تهدف إلى تقليل الوقت الذي يقضيه المستخدمون في الانتظار بينما تتبادل الأدوات والنماذج وطلبات API الرسائل ذهاباً وإياباً أثناء المهام المعقدة.
في منشور تقني نُشر في 22 أبريل، وصفت الشركة كيف يمكن لأنظمة مثل Codex أن تحتاج إلى عشرات الطلبات المتسلسلة لإكمال مهمة واحدة: يقرر النموذج ما الذي يجب فعله بعد ذلك، وتعمل أداة على جانب العميل، ثم يُرسل الناتج إلى API، وتُكرَّر الدورة. هذا النمط يجعل حتى الكميات الصغيرة من الحمل الزائد تتراكم بسرعة.
وبحسب OpenAI، أصبح مشكلة الأداء أكثر وضوحاً مع تسارع الاستدلال نفسه. وقالت الشركة إن النماذج الرائدة السابقة في Responses API كانت تعمل بمعدل نحو 65 رمزاً في الثانية. أما بالنسبة إلى GPT-5.3-Codex-Spark، فقد استهدفت OpenAI أكثر من 1,000 رمز في الثانية باستخدام عتاد Cerebras. وبمجرد أن أصبحت عملية توليد النموذج بهذه السرعة، لم يعد من السهل إخفاء الأجزاء الأبطأ من الحلقة.
من عنق زجاجة الاستدلال إلى عنق زجاجة API
تقسّم OpenAI زمن استجابة الوكيل إلى ثلاث مراحل واسعة: عمل خدمة API، واستدلال النموذج، ووقت جانب العميل. ولا يزال جانب العميل مهماً لأن الأدوات تحتاج إلى التنفيذ ويجب تجميع السياق، لكن الشركة قالت إن طبقة API نفسها أصبحت عنق زجاجة ذا أثر ملموس.
هذا التحول فرض استراتيجية تحسين مختلفة. فبدلاً من التركيز فقط على إنتاجية GPU، تقول OpenAI إنها بدأت إزالة الاحتكاك عبر مسار الطلب. وحول نوفمبر 2025، أطلقت الشركة ما وصفته بسباق أداء على Responses API. وشمل العمل تخزين الرموز المولَّدة وإعدادات النموذج في الذاكرة المؤقتة، وتقليل القفزات الشبكية الإضافية عبر استدعاء خدمات الاستدلال بشكل أكثر مباشرة، وتسريع أجزاء من طبقة الأمان حتى يمكن تصنيف بعض المحادثات بسرعة أكبر.
ووفقاً للشركة، حسّنت تلك التغييرات زمن الوصول إلى أول رمز بنحو 45%. لكن OpenAI تقول إن ذلك لم يكن كافياً بعد لإظهار مكاسب السرعة التي توفرها بنية الاستدلال الأحدث بالكامل.
الانتقال إلى WebSocket
كان التغيير الأكبر معمارياً: استبدال سلسلة من طلبات API المتزامنة المنفصلة باتصال مستمر مع Responses API باستخدام WebSockets. عملياً، يعني ذلك أن العميل وAPI يمكنهما البقاء متصلين عبر حلقة الوكيل كاملة بدلاً من تفكيك حالة الطلب وإعادة بنائها باستمرار.
تقول OpenAI إن الجلسات المستمرة سمحت لها بإبقاء معلومات مفيدة مرتبطة بالاتصال نفسه. وقد قلّل ذلك من أعمال الإعداد المتكررة وساعد النظام على إعادة استخدام السياق بكفاءة أكبر عبر الجولات. وذكرت الشركة أن النتيجة كانت تحسناً بنحو 40% في سرعة حلقة الوكيل من البداية إلى النهاية.
بالنسبة إلى المستخدمين، فإن الدلالة واضحة. إذا كان وكيل برمجة أو بحث يحتاج إلى العديد من استدعاءات الأدوات لإنهاء مهمة، فإن تقليص الحمل الزائد في كل دورة يمكن أن يكون تأثيره أكبر من تسريع مرحلة واحدة فقط. ويمكن لسير عمل كان يبدو متوقفاً بين الخطوات أن يبدأ في الشعور بأنه أقرب إلى تفاعل مباشر.
ما الذي حسّنته OpenAI
- تخزين مؤقت مرتبط بالاتصال لتجنب تكرار أعمال الإعداد المكلفة.
- تقليل القفزات الشبكية غير الضرورية بين خدمات API وخدمات الاستدلال.
- فحوصات أمان أسرع في أجزاء من خط المعالجة الخاصة بالاعتدال والتصنيف.
- قناة WebSocket مستمرة لتقليل كلفة استخدام الأدوات عبر جولات متعددة.
وصفت OpenAI هذا العمل بأنه استجابة لتحول أوسع في الصناعة: فسرعة الاستدلال أصبحت كافية إلى حد أن الأنظمة المحيطة بها تحدد بصورة متزايدة جودة المنتج كما يشعر بها المستخدم. وفي مثل هذه البيئة، قد يكون النموذج قادراً على التفكير بسرعة، لكن التجربة قد تظل بطيئة إذا تأخرت طبقات التنسيق.
لماذا يهم ذلك خارج Codex
على الرغم من أن OpenAI أوضحت المشكلة باستخدام Codex، فإن الدلالات تمتد إلى أي وكيل يستخدم أدوات. فالمساعدون المؤسسيون، وأنظمة خدمة العملاء، ومساعدو البحث، ووكلاء البرمجيات كلها تعتمد على كثير من التفاعلات الصغيرة بدلاً من إكمال واحد طويل للنموذج. لذلك قد تكون الجلسات المستمرة وتقليل عبء التنسيق مهمين بقدر أهمية الأداء الخام في الاختبارات المعيارية.
ويقدم المنشور أيضاً لمحة عن مشهد تنافسي يتغير. فقد أمضى مزودو النماذج سنوات في التركيز على تحسين الاستدلال وتوسيع نوافذ السياق. لكنهم باتوا يتنافسون أيضاً على هندسة الأنظمة: الإنتاجية، والاستجابة، وزمن تأخير الأمان، ومدى كفاءة بقاء النموذج ضمن الحلقة مع الأدوات الخارجية.
ورسالة OpenAI هي أن البنية التحتية المحيطة بالنموذج أصبحت الآن ميزة منتج بحد ذاتها. وإذا استمرت سرعات الاستدلال في الارتفاع، فمن المرجح أن يصبح ذلك أكثر صحة.
الإشارة الأعمق
الخلاصة الأعمق ليست فقط أن WebSockets أسرع من الطلبات المتزامنة المتكررة. بل إن منتجات الوكلاء تنضج لتصبح أنظمة برمجية في الوقت الحقيقي يعتمد أداؤها على التنسيق بين API وذاكرات التخزين المؤقت وطبقات الأمان وبيئات تشغيل الأدوات.
وهذا يجعل هذا التحديث أكثر من مجرد هامش هندسي. فهو علامة على أن المكاسب المقبلة في قابلية استخدام الذكاء الاصطناعي قد تأتي من تقليل الاحتكاك بين خطوات النموذج، وليس فقط من جعل كل خطوة منفردة أذكى. ومع تولي الأنظمة الوكيلة مهام أطول وأكثر تعقيداً، قد يحدد هذا الفرق ما إذا كانت تبدو تجريبية أم تشغيلية.
تستند هذه المقالة إلى تغطية OpenAI. اقرأ المقال الأصلي.
Originally published on openai.com
