وكيل من 30 خطوة مع 1% من الإخفاقات يفشل في مهمة من كل أربع: كيف تجهّزه للإنتاج

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

حسابات تفسّر الفارق بين العرض التجريبي والإنتاج

تخيّل مهمة تتكوّن من 30 خطوة، تخفق كل خطوة فيها مرة من كل مئة: انقطاع عابر في الشبكة، أو رد من API يفيد بأن الخدمة «تحت ضغط زائد». عندها ستكتمل المهمة في 74% من الحالات. وستفشل مهمة من كل أربع. وعند 3% من الإخفاقات لكل خطوة، لن تكتمل سوى 40% من المهام. ويوضح الكاتب بصراحة أن هذا حساب افتراضي يفترض إخفاقات مؤقتة مستقلة بعضها عن بعض. إذا تعطلت خدمة المزوّد بالكامل، فلن تفيد ثلاث محاولات سريعة؛ بل يلزم انتظار أطول أو مزوّد احتياطي.

الأدوات والسياق: أقل عدداً وأكثر دقة

لا يعرف النموذج عن الأداة سوى اسمها ووصفها ومخطط معلماتها وما أعادته من نتائج. لذلك تُصمَّم أداة الوكيل بطريقة تختلف عن API الموجّهة للمبرمج. لا تنشئ أداة لكل نقطة نهاية: فبدلاً من list_users وlist_events وcreate_event، يُفضَّل استخدام أداة واحدة باسم schedule_event تعثر بنفسها على موعد وتنشئ الاجتماع. اجعل الردود موجزة، واستخدم أسماء مفهومة بدلاً من uuid. في مثال Anthropic، أعاد الوضع الموجز لأداة Slack ما مجموعه 72 توكناً بدلاً من 206. وصُغ رسائل الأخطاء بما يساعد النموذج: فرسالة «يجب أن يكون التاريخ بالصيغة 2026-11-09، لكن الوارد هو 09.11» تتيح له تصحيح الخطأ تلقائياً في الجولة التالية، بينما لا يخبره الرمز 400 وحده بشيء.

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

RAG: حدّد أولاً ما إذا كنت تحتاج إليه

إذا كانت قاعدة المعرفة أصغر من 200 ألف توكن (نحو 500 صفحة)، فيمكن وضعها بالكامل في البرومبت وتخزينها مؤقتاً. عندها لا حاجة إلى البحث. أما إذا كانت أكبر، فتشير قياسات Anthropic إلى فاعلية الجمع بين البحث الدلالي والبحث بالكلمات (BM25)، مع إضافة سياق من 50–100 توكن لكل مقطع قبل الفهرسة، ثم إعادة ترتيب النتائج. انخفضت نسبة الإخفاقات التي لم يظهر فيها المقطع المطلوب ضمن أفضل 20 نتيجة من 5,7% إلى 1,9%. اختبر البحث بمعزل عن الإجابة: أعدّ أسئلة تعرف موضع إجاباتها، وقِس مدى تكرار ظهور المقطع في النتائج. وإلا فلن يتضح ما إذا كان الخلل في البحث أم في النموذج.

حلقة تنفيذ تحت السيطرة: الجولات والمال وإعادة المحاولة

ابدأ بسلسلة خطوات، لا بوكيل: فحرية الوكيل لها ثمن من زمن الاستجابة والمال. وإذا كنت تحتاج إليه فعلاً، فضع ثلاثة قيود: حداً للجولات، وميزانية بالدولار، ومهلة زمنية للمهمة كاملة. ترتفع التكلفة أسرع من عدد الجولات، لأن كل جولة تعيد قراءة السجل. وبحسب حساب الكاتب، تبلغ تكلفة مهمة من 30 جولة $0,51، بينما يكلف الوكيل العالق عند 100 جولة $2,68: عدد الجولات أكبر بمقدار 3,3 مرات، والتكلفة أكبر بمقدار 5,3 مرات. حدّد مسبقاً إلى أين تُحال المهمة عند نفاد المحاولات: إلى نموذج احتياطي، أو سلسلة خطوات بسيطة، أو شخص.

ينبغي قصر إعادة المحاولة على الإخفاقات المؤقتة، مثل 429 و500 و504 و529، مع زيادة فترة الانتظار تدريجياً. لكن التفصيل الدقيق هنا أن 429 قد يظهر أيضاً عند استنفاد سقف الإنفاق الشهري (بالرمز enforced_spend_limit_reached). عندها تكون إعادة المحاولة بلا جدوى، وسيظل نظام إعادة المحاولة الذي لا يميّز بين الحالتين يرسل طلبات متواصلة إلى API لساعات.

الخطر في التكرار، لا في التعطل

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

إذا تعطلت العملية نفسها، فلا يوجد ما يمكن إعادة محاولته: فقد كان السجل والنتائج محفوظين في الذاكرة. هنا يلزم تنفيذ قادر على الاستمرار بعد التعطل، مثل Temporal. تعمل حلقة الوكيل داخل workflow، وتصبح استدعاءات النموذج والأدوات activities، وتُدوَّن الأحداث في سجل، ثم يتابع عامل آخر التنفيذ من موضع التعطل. الشرط: أن تكون شيفرة workflow حتمية، وأن تكون activities قابلة لإعادة التنفيذ دون تكرار الأثر. أما التكلفة: فالتعطل في الجولة 25 ثم إعادة التشغيل من الصفر يرفعها إلى $0,93 بدلاً من $0,51، أي +81%.

ما الذي ينبغي فعله عملياً

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

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