من النموذج إلى الوكيل: تعزيز واجهة Responses API ببيئة حاسوبية

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

وتظهر بعض التحديات العملية عند محاولة بناء وكلاء: أين تُحفَظ الملفات الوسيطة، وكيف يمكن تجنب إدراج كميات كبيرة من البيانات في مطالبة واحدة، وكيفية إتاحة الوصول إلى الشبكة من دون التسبب في أعباء أمنية، وكيفية التعامل مع مهلات التنفيذ والانتظار وعمليات إعادة المحاولة من دون الحاجة إلى بناء نظام سير عمل كامل بنفسك.

وبدلًا من ترك المطورين يبنون بيئات التنفيذ الخاصة بهم من الصفر، أنشأنا المكوّنات اللازمة لتزويد واجهة Responses API⁠(يفتح في نافذة جديدة) ببيئة حاسوبية تتيح تنفيذ المهام الواقعية بصورة موثوقة.

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

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

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

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

تعزز أداة shell قدرات النموذج بشكل كبير، إذ تتيح له التفاعل مع جهاز كمبيوتر عبر سطر الأوامر لتنفيذ مجموعة واسعة من المهام، من البحث عن النصوص إلى إرسال طلبات API على جهازك. وبفضل اعتمادها على أدوات Unix المألوفة، تستطيع أداة shell لدينا تنفيذ ما تتوقعه عادةً، مع إتاحة أدوات مثل grep وcurl وawk من البداية.

وبالمقارنة مع مفسّر الشيفرة البرمجية الحالي لدينا، الذي يقتصر على تنفيذ Python فقط، تتيح أداة shell نطاقًا أوسع بكثير من حالات الاستخدام، مثل تشغيل برامج Go أو Java أو بدء تشغيل خادم NodeJS. وتمنح هذه المرونة النموذج القدرة على إنجاز مهام وكيلية معقدة.

بمفرده، لا يستطيع النموذج سوى اقتراح أوامر shell، لكن كيف تُنفَّذ هذه الأوامر؟ نحتاج إلى منسّق يقرأ مخرجات النموذج، ويستدعي الأداة، ثم يعيد الاستجابة إلى النموذج ضمن حلقة تتكرر حتى تكتمل المهمة.

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

عندما تتلقى واجهة برمجة Responses API مطالبة، فإنها تجمع سياق النموذج، بما في ذلك مطالبة النظام، وسجل المحادثة السابق، وتعليمات الأداة. ولكي يعمل تنفيذ shell على النحو المطلوب، يجب أن تتضمن المطالبة الأداة المطلوبة والنموذج المُخصَّص لتوليد أوامر shell، إذ دُرّبت نماذج مثل GPT‑5.2 والإصدارات اللاحقة على ذلك. ومع اكتمال هذا السياق، يقرر النموذج الإجراء التالي. فإذا اختار تنفيذ الـ shell، فإنه يعيد أمرًا واحدًا أو أكثر من أوامر shell إلى واجهة Responses API. ثم تُمرِّر الواجهة هذه الأوامر إلى بيئة تشغيل الحاوية، وتعيد مخرجات shell إلى النموذج ضمن سياق الخطوة التالية. ويمكن للنموذج بعد ذلك فحص هذه المخرجات، أو إصدار أوامر متابعة مفيدة، أو تقديم إجابة نهائية. وتواصل واجهة Responses API تكرار هذه الحلقة إلى أن يعيد النموذج استجابة مكتملة من دون أوامر shell إضافية.

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

ويمكن للنموذج اقتراح عدة أوامر shell في خطوة واحدة، كما تستطيع واجهة Responses API تنفيذها بالتوازي باستخدام مسارات حاويات منفصلة. ويُنتج كل تشغيل مخرجاته على نحو مستقل، بينما تجمع الواجهة هذه المسارات في مخرجات أدوات منظَّمة وغنية. وبذلك يمكن لحلقة الوكيل تنفيذ أعمال متوازية، مثل البحث في الملفات، وجلب البيانات، والتحقق من النتائج الوسيطة.

عندما يتضمن الأمر عمليات على الملفات أو معالجة للبيانات، قد تصبح مخرجات shell كبيرة جدًا وتستهلك ميزانيات السياق من دون أن تضيف فائدة كبيرة. وللتحكم في ذلك، يحدّد هذا النموذج حدًا أقصى للمخرجات لكل أمر. وتفرض واجهة Responses API هذا الحد، ثم تعيد مخرجات مقيدة تحتفظ ببداية المخرجات ونهايتها، مع الإشارة بوضوح إلى الأجزاء المحذوفة. فعلى سبيل المثال، يمكن قصر المخرجات على 1,000 حرف، مع الإبقاء على البداية والنهاية:

نص في البداية ... تم اقتطاع 1000 حرف ... نص في النهاية

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

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

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

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

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

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

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

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

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

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

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

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

تتمتع أوامر shell بقدرات كبيرة، لكن العديد من المهام تكرر الأنماط نفسها متعددة الخطوات. ويضطر الوكلاء إلى إعادة اكتشاف سير العمل في كل تشغيل، من خلال إعادة التخطيط، وإعادة إصدار الأوامر، وإعادة تعلّم الاصطلاحات، مما يؤدي إلى نتائج غير متسقة وهدر في التنفيذ. وتجمع مهارات الوكيل⁠(يفتح في نافذة جديدة) هذه الأنماط في وحدات بناء قابلة لإعادة الاستخدام والتركيب. وعادةً ما تكون المهارة مجلدًا يتضمن SKILL.md⁠(يفتح في نافذة جديدة) يحتوي على بيانات وصفية وتعليمات، إلى جانب أي موارد داعمة، مثل واجهات برمجة التطبيقات والنصوص البرمجية وأدوات واجهة المستخدم.

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

نوفّر واجهات برمجة التطبيقات (APIs)⁠(يفتح في نافذة جديدة) لإدارة المهارات على منصة OpenAI. ويمكن للمطورين تحميل مهارات وتخزين مجلدات المهارات على هيئة حِزم مُعنونة بالإصدارات، بحيث يمكن استرجاعها لاحقًا بواسطة skill ID. وقبل إرسال المطالبة إلى النموذج، تحمّل واجهة Responses API المهارة وتضمّنها في سياق النموذج. ويتبع هذا التسلسل خطوات محددة:

1. جلب بيانات التعريف للمهارة، بما في ذلك الاسم والوصف.
2. جلب حزمة المهارة، ونسخها إلى الحاوية، وفكّها.
3. تحديث سياق النموذج ببيانات المهارة الوصفية ومسارها داخل الحاوية.

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

ولجمع هذه العناصر معًا، توفّر واجهة Responses API آلية التنسيق، وتوفّر أداة shell إجراءات قابلة للتنفيذ، كما توفّر الحاوية المستضافة سياق تشغيل دائمًا، وتقدّم skills منطقًا قابلًا لإعادة الاستخدام، في حين يتيح compaction للوكيل مواصلة العمل مدة أطول مع الاحتفاظ بالسياق الذي يحتاج إليه.

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

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

للاطلاع على مثال مفصل يوضح كيفية الجمع بين أداة shell وبيئة الكمبيوتر لبناء مسارات عمل متكاملة من البداية إلى النهاية، راجع تدوينة المطورين⁠(يفتح في نافذة جديدة) ودليل Cookbook⁠(يفتح في نافذة جديدة) اللذين يشرحان كيفية حزم مهارة وتشغيلها عبر واجهة Responses API.

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