تُعد منظومات التقييم الأخف والوكلاء المنفذون للتعليمات البرمجية أنسب للمهام المفتوحة، إذ قد يحد التنسيق المفرط في صرامته من أداء النموذج.
وبذلك، أصبح تنفيذ التعليمات البرمجية والعزل في بيئات آمنة من الاعتبارات المعمارية الأساسية لأنظمة الوكلاء.
تقلل حزمة تطوير وكلاء OpenAI مقدار التعقيد والتعليمات البرمجية اللازمة لبناء وكلاء منفذين للتعليمات البرمجية بما يصل إلى ستة أضعاف في اختباراتنا.
لفترة طويلة، كان التقدم في أنظمة الوكلاء نابعًا من تحسين التنسيق: صياغة مطالبات أفضل، وتحسين واجهات الأدوات وإدارة السياق، وتشديد التحكم في سير العمل. لكن مع ازدياد قدرات وكلاء البرمجة، بدأ هذا التوازن يتغير.
في كثير من مسارات العمل المفتوحة، لم تعد حلقة الوكيل نفسها هي موطن الاختناق، بل طبقة التنفيذ: البيئة المعزولة التي يكتب فيها النموذج التعليمات البرمجية وينفذ الأوامر ويفحص المخرجات ويكرر المحاولة. ومع انتقال مزيد من الاستدلال على مستوى المهمة إلى تلك البيئة، ينبغي تبسيط التنسيق المحيط بها حتى يتمكن النموذج من إظهار كامل قدراته.
وهذا التحول تحديدًا هو ما يتيحه الإصدار الجديد من حزمة تطوير وكلاء OpenAI. ومن خلال اختباراتنا أثناء مرحلة الوصول المبكر، وجدنا أنه بدلًا من إضافة طبقة أخرى من منطق إطار العمل، يجعل هذا الإصدار طبقة التنفيذ أكثر نمطية وقابلية للتركيب، لتظل بقية المنظومة خفيفة.
أصبح تقليص منظومة التقييم إلى أبسط صورة فعالة لها توجهًا رائجًا في هندسة منظومة التقييم. بوجه عام، منظومة التقييم هي البرمجيات المحيطة بالنموذج: أي الطبقة التي تدير السياق والأدوات وسير التحكم وحلقات الملاحظات، ليتمكن النموذج من إنجاز العمل بموثوقية.
على مدار السنوات القليلة الماضية، تحققت تحسينات كثيرة في أداء الوكلاء بفضل تعزيز تلك الطبقة. كثيرًا ما ساهمت الأدوات الأفضل، وتحسين الذاكرة والاسترجاع، وتفكيك المهام بصورة أوضح، وتشديد التنسيق في زيادة موثوقية الأنظمة وقدراتها. في هذا النهج، كان التقدم يعني إلى حد كبير تضمين مزيد من منطق المهام في البرمجيات المحيطة بالنموذج.
لكن هذا النمط آخذ في التراجع الآن، على الأقل في فئة من المهام المفتوحة. يشير عدد متزايد من المشاريع والأبحاث إلى أن الأداء لا يتحسن دائمًا عندما تصبح منظومة التقييم أكثر إملاءً للخطوات. في البرمجة بمساعدة الذكاء الاصطناعي، والمهام طويلة الأمد، واستخدام المتصفح، والمهام ذات السياق الطويل، يتكرر النمط نفسه: ما إن يبلغ النموذج مستوى كافيًا من الذكاء، قد يصبح فرض بنية مفرطة للمهام ضمن البرمجيات المحيطة قيدًا بدلًا من أن يكون ميزة.
وهكذا يتغير دور منظومة التقييم. فبدلًا من محاولة توقع المهمة مسبقًا عبر تنسيق صارم، يتجه دور منظومة التقييم إلى توفير بيئة تنفيذ واضحة: بيئة معزولة يستطيع فيها النموذج فحص الحالة وتشغيل التعليمات البرمجية والتعافي من الأخطاء وتكييف نهجه بنفسه، مع بقائه ضمن حدود واجهات النظام وضوابطه الوقائية. يشبه هذا التحول ما وصفه أندريه كارباثي في «مهندس البرمجيات 3.0»: إذ ينتقل بعض المنطق الذي كان مضمنًا في البرمجيات إلى مستوى أعلى، هو «المطالبة».
ولا يعني ذلك أن على أنظمة الوكلاء إزالة البنية من كل شيء. فلا تزال مهام كثيرة تستفيد من مسارات العمل الصريحة والأساليب الاستدلالية والحواجز الحتمية، لا سيما حين تكون المهمة محدودة النطاق أو كثيفة الحجم أو ذات معيار نجاح واضح. وكما أوضحنا في منشورنا السابق عن الأساليب الاستدلالية لتصميم أنظمة الوكلاء، يظل التنسيق المحكم مهمًا عندما يكون التدفق المنطقي الموثوق ممكنًا ومرغوبًا فيه.
أما في المهام المفتوحة، فمحور التركيز آخذ في التحول. فالتحدي لم يعد يتمثل في تصميم طبقات تنسيق متزايدة التعقيد بقدر ما يتمثل في بناء بيئات تنفيذ بسيطة وقابلة للمراقبة ونمطية بما يكفي ليعمل النموذج داخلها بفعالية.
بمجرد أن يتمكن الوكيل من قراءة الملفات وكتابة التعليمات البرمجية وتشغيل أوامر الصدفة وبدء مهام طويلة الأمد، يتغير التحدي الهندسي. فلم يعد الجزء الأصعب يقتصر على تحسين المطالبات أو توجيه الأدوات. إن عمل الوكيل الآن على نظام حقيقي يجعل هؤلاء الوكلاء أقوى بكثير، لكنه يزيد أيضًا من حساسيتهم لأنهم يوسعون نطاق المخاطر المتعلقة بالسلامة والأمن. فعلى سبيل المثال، يمكن لوكيل قادر على تنفيذ التعليمات البرمجية اتخاذ إجراءات ضارة إذا لم تكن بيئته معزولة جيدًا (انظر معيار Sandbox Bench من AISI).
لذلك، أصبح العزل في بيئات آمنة من الاعتبارات الحاسمة في أطر عمل الوكلاء. في الأنظمة السابقة، كان التنفيذ يُعامل غالبًا بوصفه إضافة: أداة ملحقة بمنظومة التقييم. لكن هذا النهج يبدأ في التعثر ما إن يصبح التنفيذ محتفظًا بالحالة، أو طويل الأمد، أو عن بُعد. وسرعان ما تصبح إدارة البيئة المعزولة نفسها، ودورة حياتها وحالتها وواجهاتها وربطها بحلقة الوكيل، مسألة مستقلة في تصميم الأنظمة. وهذا أحد أسباب تزايد عدد المزودين الذين يقدمون الآن بيئات مُدارة لتنفيذ التعليمات البرمجية، ومنهم واجهة الحاويات وأداة الصدفة من OpenAI، وModal، وCloudflare، وDaytona، وE2B، وغيرهم.
هذا الفصل مهم لأن تنفيذ التعليمات البرمجية يتطلب عزلًا أقوى وتحكمًا أدق في وقت التشغيل مقارنة ببقية منظومة التقييم. عمليًا، قد ينشأ عن سوء تنفيذ الوكلاء المنفذين للتعليمات البرمجية ثلاثة مخاطر جوهرية للأعمال: إنفاق غير منضبط على الحوسبة، وإجراءات مدمرة في الأنظمة الداخلية، وكشف معلومات حساسة. ويمكن احتواء هذه المخاطر عند مستوى مقبول لعمليات النشر الفعلية باستخدام الحاويات والعزل وضوابط وقت التشغيل على نحو سليم.
يمكن تصور الأمر على أنه منح الوكيل مساحة عمل خاصة ومحكمة الإغلاق بدلًا من مفاتيح المكتب بأكمله. سيظل قادرًا على إنجاز عمل مفيد داخل تلك المساحة، ولكن ضمن حدود واضحة فقط. يمكنك وضع حد لمقدار الحوسبة التي يستخدمها، وتقييد الأنظمة والملفات التي يستطيع الوصول إليها، والتحكم منذ البداية في المعلومات المتاحة له.
لا يزيل ذلك المخاطر تمامًا، لكنه يحول المسألة من «وكيل طليق داخل بنيتك التحتية» إلى «وكيل يعمل في بيئة خاضعة للرقابة». وإذا كانت هذه الطبقة ستصبح جزءًا قياسيًا من أنظمة الوكلاء، فلا بد أن يدعمها إطار العمل نفسه دعمًا أصيلًا. وبذلك تصبح البيئة المعزولة طبقة تنفيذ نمطية ذات مكونات أولية قابلة للنقل، يستطيع المطورون اعتمادها بسرعة والتبديل بين مزوديها وتوسيع نطاقها دون إعادة صياغة منطق الوكيل باستمرار.
بمجرد أن ينفذ الوكيل تعليمات برمجية، تصبح البيئة المعزولة نفسها بحاجة إلى التنسيق. يؤدي الانتقال من نموذج أولي محلي إلى التنفيذ عن بُعد أو إلى واجهات خلفية متعددة أو جلسات طويلة الأمد إلى زيادة العبء التشغيلي زيادة هائلة. تحتاج إلى طريقة موحدة لإنشاء البيئات وإيقافها مؤقتًا أو نهائيًا واستئنافها، وحفظ لقطات من حالتها، وإعادة الاتصال بها لاحقًا، وإدارة كل ذلك عبر مختلف المزودين.
قد لا يبدو أي من ذلك جذابًا من الناحية النظرية، لكنه مهم عمليًا. هذا تحديدًا هو نوع البنية التحتية الذي يتحول إلى عبء حين يعيد كل فريق بناء مسار عمل للوكلاء من الصفر، لا سيما عندما لا يكون مدمجًا في إطار عمل الوكيل…
وهنا تبرز أهمية توفير دعم أفضل في إطار العمل. حصلنا على وصول مبكر إلى الإصدار الأحدث من حزمة تطوير وكلاء OpenAI واستخدمناه بأنفسنا لبناء وكلاء يعملون في بيئات معزولة. وكان أبرز ما لاحظناه هو تحول موضع التركيز المعماري: إذ تتعامل حزمة التطوير مع التنفيذ بوصفه طبقة أساسية لا أداة هامشية. عمليًا، يعني ذلك إمكانية تشغيل وكيل في بيئة معزولة، أو حفظ لقطة من البيئة، أو استئناف التنفيذ باستخدام تعليمات برمجية أقل بنحو ستة أضعاف في بعض اختباراتنا، ثم تبديل الواجهة الخلفية دون إعادة كتابة منطق الوكيل المحيط.
يتيح هذا الفصل الأوضح للمسؤوليات أن تظل منظومة التقييم مركزة على الاستدلال والسياق ومسار العمل. ويمكن لطبقة التنفيذ أن تركز على العزل وقابلية النقل وحالة وقت التشغيل. يسهّل هذا التجريد بناء وكلاء برمجة أكثر قدرة وأسهل تطويرًا، يمكنهم الانتقال بين التنفيذ المحلي والبعيد، ودعم المهام الأطول أمدًا، وتغيير واجهات التنفيذ الخلفية دون الاضطرار إلى إعادة تصميم النظام بأكمله.
مع انتقال مزيد من المنطق المرتبط بالمهام من منظومة التقييم إلى النموذج، ينتقل معه جانب من تعقيد النظام إلى طبقة التنفيذ الأعمق. أصبح تنفيذ التعليمات البرمجية والعزل في بيئات آمنة من الاعتبارات المعمارية الأساسية لأنظمة الوكلاء، لا سيما في المهام المفتوحة والكثيفة برمجيًا. أصبح تصميم البيئة التي يستطيع الوكيل العمل فيها بأمان وموثوقية وعلى مدى زمني طويل لا يقل أهمية عن تصميم مسار عمل الوكلاء نفسه.
لهذا تكتسب التجريدات عالية المستوى المحيطة بالتنفيذ المعزول أهمية كبيرة. تمضي حزمة تطوير وكلاء OpenAI الأحدث في هذا الاتجاه، إذ تتعامل مع التنفيذ بوصفه طبقة نمطية في النظام: قابلة للنقل بين الواجهات الخلفية، ومحتفظة بالحالة عبر المهام طويلة الأمد، وبسيطة بما يكفي للاستخدام دون إعادة بناء البنية التحتية ذاتها مع كل إعداد جديد.
والدرس الأوسع هو أن الجيل المقبل من أطر عمل الوكلاء لن يُعرّف على الأرجح بمقدار منطق التنسيق الذي يضيفه، بل بمدى جودة تنظيمه لبيئات التنفيذ التي يعتمد عليها الوكلاء بصورة متزايدة.