DigitalOcean Agent Learning Services: كيف تكتشف أين يفشل وكيلك قبل أن يشتكي المستخدم؟

أغلب الفرق التي تنشر وكيلاً ذكياً في الإنتاج تواجه المشكلة نفسها بعد الأسبوع الأول: الوكيل يعمل في العروض التجريبية، لكنه في الواقع يتعثر أحياناً، ويدخل في حلقات، ويستدعي أدوات بمعاملات خاطئة، والمستخدم لا يخبرك بشيء، بل يغادر. في 12 أكتوبر 2026 أعلنت DigitalOcean عن مجموعتين من الخدمات تحاولان سدّ هذه الفجوة: Agent Data Services وAgent Learning Services، وهما متاحتان في معاينة عامة أو خاصة.

في هذا المقال نشرح ما تتكوّن منه الحلقة، وكيف تعمل أجزاؤها معاً، وما الذي ينبغي أن تحسبه قبل تجربتها.

ما الذي أُعلن؟

الإعلان يضم مجموعتين:

• Agent Data Services: طبقة بيانات مُدارة لسياق الوكلاء، تتولى الإدخال والمعالجة متعددة الوسائط والفهرسة وتتبع التنفيذ، وتخزّن كل شيء في فهرس واحد معزول منطقياً يمكن الاستعلام عنه بـ SQL أو بحث المتجهات أو واجهات المطورين. هي حالياً في معاينة خاصة.
• Agent Learning Services: ثلاثة منتجات تعمل كحلقة واحدة هي Insights وSignals وEvaluations & Simulations.

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

الحلقة الثلاثية خطوة بخطوة

Insights: تتبع كل خطوة

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

Signals: اكتشاف الجلسات المهمة

من بين آلاف الجلسات لا يمكن لأي فريق قراءتها جميعاً. يقوم Signals بمراقبة حركة الإنتاج على Managed Agents وServerless Inference، ويضع علامة على الجلسات التي توقف فيها الوكيل أو دخل في حلقة أو فقد المستخدم أو فشلت فيها استدعاءات الأدوات، دون الحاجة إلى تجهيز إضافي. ويمكن تحويل أي جلسة مُعلَّمة إلى اختبار تقييم بنقرة واحدة. وتذكر الشركة في ورقة مرافقة أن نسبة الإفادة بلغت 82% وأن الكفاءة تفوقت 1.52 مرة على أخذ العينات العشوائي على معيار τ-bench، وهي أرقام من الشركة نفسها ويحسن التحقق منها على بياناتك.

Simulations: اختبار الإصلاح قبل الشحن

يشغّل Simulations الإصلاح المقترح على سيناريوهات متعددة الأدوار مبنية من جلسات حقيقية، داخل بيئة معزولة بالأدوات والإطار نفسه المستخدم في الإنتاج، ويقيّم قاضٍ من نموذج لغوي النتائج بمقاييس مثل إتمام الهدف. عند الإطلاق يدعم Claude Code وCodex وOpenCode، أما LangChain وCrewAI فلم تُدعما بعد.

الوكيل الذي لا تقيس إخفاقاته يشبه موقعاً بلا سجلات أخطاء: يبدو سليماً إلى أن يغادره الزوار.

جدول سريع للمقارنة

المنتج	السؤال الذي يجيب عنه	حالته
Insights	ماذا فعل الوكيل بالضبط؟	معاينة
Signals	أين أخفق؟	معاينة
Evaluations & Simulations	هل يحلّ الإصلاح المشكلة؟	معاينة
Agent Data Services	أين تُخزَّن بيانات الوكيل وسياقه؟	معاينة خاصة

لماذا يهم هذا النموذج؟

تغيّر هذه الحلقة طريقة التفكير في تطوير الوكلاء من ثلاث زوايا:

1. من الحدس إلى الدليل: بدل تعديل التعليمات والانتظار، يصبح لديك سجل لما حدث فعلاً.
2. من الاختبار اليدوي إلى اختبار مبني على الواقع: السيناريوهات تأتي من جلسات حقيقية لا من أمثلة اخترعتها.
3. من الإصلاح المتفائل إلى الإصلاح المُتحقَّق منه: لا يُشحن تعديل قبل أن يثبت أنه لا يكسر شيئاً آخر.

وهذه هي الدورة التي تسميها الشركة تحسين الوكيل ذاتياً بشكل متكرر، لكن الأدق أن تفهمها كدورة هندسية منضبطة يشرف عليها بشر.

ما الذي ينبغي أن تحسبه قبل التجربة؟

الخصوصية والامتثال

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

الارتباط بالمنصة

الخدمات مصممة للعمل بأفضل صورة على منصة DigitalOcean نفسها. إن كان وكيلك يعمل في مكان آخر فاسأل عن حدود التكامل، وحافظ على التتبع بصيغة OpenTelemetry القياسية كي تبقى قادراً على نقله.

حدود الدعم الحالية

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

الاعتماد على قاضٍ آلي

تقييم النتائج بنموذج لغوي مفيد وسريع لكنه ليس معصوماً. أبقِ عينة من الجلسات تُراجع يدوياً لتعايِر ثقتك بالقاضي.

أمثلة على أنماط الفشل التي يلتقطها هذا النوع من الأدوات

لتتضح الفائدة، إليك أنماطاً شائعة في وكلاء الإنتاج يصعب رؤيتها دون تتبع منظم:

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

في كل حالة من هذه، المشكلة ليست في النموذج وحده بل في طريقة تركيب التعليمات والأدوات والسياق معاً. والتتبع هو ما يكشف أي طبقة مسؤولة.

كيف تربط هذا بما تفعله اليوم؟

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

خطة تجربة مقترحة من أسبوع

1. فعّل التتبع على وكيل واحد منخفض المخاطر.
2. اجمع حركة أسبوع كامل دون تغيير شيء.
3. راجع الجلسات التي علّمها Signals وصنّفها: حلقات أو أخطاء أدوات أو سوء فهم.
4. اختر نمط الفشل الأكثر تكراراً وصغ إصلاحاً واحداً له.
5. شغّل الإصلاح في Simulations وقارن إتمام الهدف قبله وبعده.
6. انشر الإصلاح تدريجياً وراقب هل انخفض ذلك النمط فعلاً.

أسئلة شائعة

هل أحتاج إلى استضافة وكيلي على DigitalOcean؟

المراقبة التلقائية في Signals مرتبطة بحركة Managed Agents وServerless Inference. للتفاصيل الدقيقة حول الوكلاء المستضافين خارجها راجع الوثائق الرسمية.

هل الخدمات متاحة للجميع الآن؟

هي في معاينة عامة أو خاصة بحسب المنتج، وبعضها كـ Agent Data Services في معاينة خاصة، فقد تحتاج إلى طلب وصول.

هل يغني هذا عن كتابة اختبارات للوكيل؟

لا. هو يسهّل بناء الاختبارات من جلسات حقيقية، لكن الاختبارات الأساسية التي تحمي سلوكاً لا يجوز أن ينكسر تبقى مسؤوليتك.

الخلاصة

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

المصادر: DigitalOcean: Agent Data Services، DigitalOcean Insights، AIwire، daily.dev