تحتاج تطبيقات الذكاء الاصطناعي التي تعتمد على الوكلاء إلى تصميم مختلف عن واجهات الويب التقليدية، ليس بسبب بروتوكول جديد بالضرورة، بل لأن نمط الحركة نفسه مختلف. فالمحادثة الواحدة قد تمتد إلى عشرات الطلبات المستقلة، بينما يواصل الوكيل العمل بسرعة آلية ومن دون فترات انتظار بشرية تُخفف الضغط على البنية التحتية.
تقترح المادة، المنشورة في The New Stack ضمن مادة برعاية Oracle، إعادة استخدام مبادئ قديمة في الخدمات المصغرة لبناء واجهات متوافقة مع OpenAI وقادرة على التوسع، مع الاستناد في نموذج إثبات المفهوم إلى Oracle AI Database Free.
لماذا تختلف حركة الوكلاء عن تطبيقات الويب؟
المتصفح قد يحافظ على الجلسة عبر خادم واحد بفضل ثبات التوجيه وفترات تفكير المستخدم. أما الوكيل، فقد ينفذ 40 دورة متتالية، وكل دورة تصل كطلب HTTP مستقل لا يضمن البروتوكول توجيهه إلى الخادم نفسه. وإذا بقي سجل المحادثة داخل ذاكرة عملية محلية، فقد يفقد الطلب التالي السياق بمجرد انتقاله إلى نسخة أخرى من الخدمة.
كما أن استدعاءات الأدوات قد تتشعب بصورة غير متوقعة؛ فقد يؤدي طلب واحد إلى عدم استدعاء أي خدمة إضافية أو إلى عدة استدعاءات، بينها عمليات بحث متجهي قد تستغرق 400 مللي ثانية. وتزيد الوكلاء الضغط عبر سياسات إعادة المحاولة الخاصة بها، بينما تأتي الحركة على شكل دفعات متواصلة تحددها حدود التزامن والعتاد أكثر مما يحددها سلوك المستخدم.
المشكلة الصامتة في التصميم الأولي
يعرض الكاتب نموذجاً أولياً يحتفظ بتاريخ المحادثة في قاموس داخل العملية، ويستخدم مجموعة واحدة للتحكم في التزامن، وينفذ استدعاءات الأدوات ضمن مسار الطلب نفسه. يعمل هذا التصميم في الاختبارات، لكنه يعتمد عملياً على وصول كل أدوار المحادثة إلى الجهاز ذاته.
عند توزيع 200 محادثة، لكل منها أربعة أدوار، بالتناوب على نسخ متعددة، قد تظل الخوادم تعيد رموز HTTP 200، بينما يجيب النموذج من دون سجل المحادثة الصحيح. لذلك لا يظهر الخلل بالضرورة كعطل تقني واضح؛ بل يظهر كسلوك غير صحيح من منظور المستخدم.
ثلاثة مبادئ لمعالجة الخلل
- إخراج الحالة من العملية: تُخزَّن حالة المحادثة وسجل استدعاءات الأدوات في مخزن مشترك، بحيث تستطيع أي نسخة خدمة أي دور من أدوار المحادثة.
- العزل أو الحواجز: تُمنح المسارات والاعتماديات المختلفة، مثل إكمال المحادثة وتنفيذ الأدوات، حدود تزامن ومهلات مستقلة لمنع فشل أحدها من استنزاف النظام كله.
- نقاط نهاية ذكية وأنابيب بسيطة: يبقى بروتوكول OpenAI-compatible طبقة نقل مستقرة، بينما تُوضع منطقية التوجيه وإدارة الميزانية والذاكرة وسياسات استدعاء الأدوات فوقه.
ما الذي يتغير عملياً؟
يقسم نموذج إثبات المفهوم النظام إلى بوابة تتحدث ببروتوكول OpenAI ولا تحتفظ بالحالة، وخدمة ذاكرة تملك سجل المحادثة والتدقيق، وخدمة أدوات مستقلة بحدود تزامن ومهلات خاصة، وقاعدة Oracle AI Database Free بوصفها مخزناً مشتركاً. ويستخدم التصميم إشارات تحكم مستقلة، مثل 24 فتحة لتزامن المحادثة و8 لاستدعاءات الأدوات.
يسمح هذا التقسيم بالتوسع الأفقي من دون الاعتماد على نظام الملفات المحلي أو ثبات توجيه الطلبات. كما يمكن للعميل الرسمي من OpenAI استخدام الواجهة من دون تعديل SDK، ما دام البروتوكول متوافقاً.
تتمثل الخلاصة التحريرية في أن قابلية توسع وكلاء الذكاء الاصطناعي لا تُحل بزيادة عدد النسخ وحدها. فالاختبار الحقيقي هو الحفاظ على الحالة، والتحكم في الاعتماديات البطيئة، ومنع إعادة المحاولة أو استدعاءات الأدوات من تحويل دفعات الوكلاء إلى فشل متسلسل. وتظل المادة، بحكم كونها محتوى برعاية Oracle، عرضاً لمقاربة معمارية ونموذج إثبات مفهوم، لا مقارنة مستقلة بين قواعد بيانات أو ضماناً لأداء معين في كل بيئة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.