مطوّر ينقل الوكيل خارج OpenWebUI بعد طلب بلغ 1.67 مليون رمز

إذا كان وكيلك يقرأ ملفًا كبيرًا، فقد يُرسَل محتواه إلى النموذج من جديد مع كل رسالة تالية. بهذه الطريقة وصل المساعد الداخلي لفريق صغير، المبني على OpenWebUI، إلى طلب بحجم 1 674 813 رمزًا ورفضٍ من API. بدأ مؤلف التحليل المنشور على Habr بتنظيف السجل بمرشّح، ثم نقل تنفيذ المهام إلى خدمة منفصلة. الدرس العملي: قبل توسيع نافذة السياق، اعرف أي البيانات تعود إلى النموذج مرة أخرى، وأي مكوّن يحتفظ بحالة المحادثة.

ملف واحد يبقى في المحادثة طويلًا

بحسب المؤلف، أعاد استدعاء واحد لـ read_file ما مقداره 66 871 حرفًا. وأنتجت أحد عشر استدعاءً للأدوات نحو 130 ألف حرف، أي نحو 32 ألف رمز بتقديره. واصلت هذه النتائج السفر مع السجل. كان الوكيل يطلب فحوصات جديدة، ويكبر السياق، وينتهي الأمر بأن يلغي المستخدم المهمة.

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

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

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

انتقلت ذاكرة الوكيل إلى خدمة منفصلة

واصطدم التلخيص كذلك بحجم المدخلات. وفق تقرير المؤلف، بلغت طلبات الضغط 161–170 ألف رمز، في حين أن حدّ النموذج المختار 128 ألفًا. وكانت الآلية تفشل في أطول المحادثات، حيث كانت الحاجة إليها أشد.

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

بحلول يوليو غيّر المؤلف البنية. احتفظت OpenWebUI بالمستخدمين وتحميل الملفات وعرض الردود. وصارت دالة pipe تمرّر آخر رسالة وقواعد النظام والمرفقات إلى Agent Runtime خارجي. أما حالة المحادثة فصار المنفّذ نفسه يحتفظ بها، مستخدمًا Agents SDK أو Codex SDK.

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

كان لا بد من فحص الرد المتدفق عبر الأحداث

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

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

بعد تحديث الاعتماديات أبلغ المؤلف عن ستة سيناريوهات ناجحة عبر API دون تراجع خفي إلى Chat Completions. وفي الوقت نفسه بقي الفحص عبر المتصفح، والحمل المتوازي الطويل، وجزء من سيناريوهات استعادة الحالة خارج نطاق الاختبار النهائي.

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