لماذا تفشل وكلاء الذكاء الاصطناعي في الإنتاج (وكيفية اختبار كل نمط فشل)

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

جرّب Apidog اليوم

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

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

الوكلاء يفشلون عند حدود API، وليس في التوجيه فقط

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

تسلسل تنفيذ خطوة واحدة للوكيل يبدو عادةً هكذا:

1. يختار النموذج أداة.
2. يحوّل كودك الاختيار إلى طلب HTTP.
3. تستجيب خدمة خارجية.
4. يعيد كودك النتيجة إلى النموذج.

ثلاثة من هذه التسليمات الأربعة هي تكامل API تقليدي. لذلك يجب التعامل معها بعقلية اختبار التكامل: عقود واضحة، ومحاكاة للأخطاء، وتأكيدات على الطلبات والاستجابات.

السؤال الصحيح ليس: هل النموذج ذكي بما يكفي؟

بل: هل اختبرت كل طريقة قد تفشل بها استدعاءات أدوات الوكيل؟

وضع الفشل الأول: استدعاء أداة يخالف العقد

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

POST /reservations
Content-Type: application/json

{
  "guests": "two"
}

بينما يتطلب العقد:

{
  "guests": 2
}

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

ما يجب تنفيذه

1. عرّف مخططًا لكل أداة يستطيع الوكيل استدعاءها.
2. تحقّق من الطلب الصادر قبل إرساله أو عند التقاطه في الاختبار.
3. اجعل مخالفة العقد تفشل الاختبار بوضوح.
4. تحقّق من الحقول المطلوبة والأنواع والقيم المسموحة.

مثال تأكيد مبسط:

expect(request.body).toMatchObject({
  guests: expect.any(Number),
});

expect(request.body.guests).toBeGreaterThan(0);

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

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

وضع الفشل الثاني: أخطاء المصدر وقيود المعدل

كل تبعية خارجية قد تعيد:

• 429 Too Many Requests
• 500 Internal Server Error
• مهلة اتصال
• استجابة فارغة أو مشوهة

الوكيل الجيد لا يعيد المحاولة بلا حدود. يجب أن يطبق تراجعًا تدريجيًا، ويحترم Retry-After، ويتوقف بعد عدد واضح من المحاولات.

توضح مناقشة أنماط استعادة خطأ الوكيل مدى شيوع هذه المشكلة.

سيناريو محاكاة يجب اختباره

برمج تبعية الوكيل لتعيد التسلسل التالي:

1. 429 مع ترويسة Retry-After
2. 500
3. استجابة نجاح

ثم تحقق من الآتي:

expect(retryCount).toBeLessThanOrEqual(3);
expect(backoffDelay).toBeGreaterThan(0);
expect(requests).toHaveLength(3);

اسأل أيضًا:

• هل يحترم الوكيل ترويسة Retry-After؟
• هل يضيف تذبذبًا (jitter) إلى التراجع؟
• هل يفتح قاطع دائرة (circuit breaker) عند استمرار الفشل؟
• هل تؤدي إعادة المحاولة إلى تنفيذ العملية مرتين؟

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

راجع أيضًا ما تعنيه استجابة تجاوز حد المعدل ودليل استعادة خطأ وكيل الذكاء الاصطناعي.

وضع الفشل الثالث: المخرجات غير الحتمية

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

لذلك، تجنب اختبارات مثل:

expect(answer).toBe("إجمالي الطلب هو 42 دولارًا");

هذا النوع من الاختبارات متقلب (flaky) وسيتجاهله الفريق سريعًا.

اختبر الهيكل والمعنى بدل النص الحرفي

استخدم تأكيدات مثل:

expect(response).toMatchObject({
  total: expect.any(Number),
  currency: "USD",
});

expect(response.total).toBeGreaterThanOrEqual(0);
expect(response.total).toBeLessThanOrEqual(cartTotal);

تحقق من:

• صحة JSON مقابل المخطط.
• وجود المفاتيح المطلوبة.
• غياب الحقول المحظورة.
• شكل استدعاء الأداة.
• نطاق القيم الرقمية.
• اختيار الأداة أو الهدف المناسب.

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

وضع الفشل الرابع: التكلفة الجامحة

الوكلاء يعملون في حلقات، والحلقات تستهلك الرموز المميزة والوقت والمال. يمكن لوكيل يعيد محاولة استدعاء فاشل آلاف المرات أن يحول تكلفة صغيرة إلى فاتورة كبيرة خلال ساعات.

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

أضف ميزانيات قابلة للاختبار

سجل لكل تشغيل:

• عدد استدعاءات الأدوات.
• عدد المحاولات لكل تبعية.
• استهلاك الرموز المميزة.
• مدة التنفيذ.
• سبب الإيقاف.

مثال:

expect(run.toolCalls).toBeLessThanOrEqual(10);
expect(run.tokenUsage).toBeLessThanOrEqual(TOKEN_BUDGET);
expect(run.durationMs).toBeLessThan(MAX_DURATION_MS);

إذا نجح الوكيل بعد 40 استدعاءً بدل 4، فهذا ليس نجاحًا كاملًا؛ إنه حادث تكلفة محتمل. راجع تقليل تكاليف الرموز المميزة للوكيل لإجراءات عملية إضافية.

وضع الفشل الخامس: غياب الحواجز الوقائية

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

الحواجز الوقائية هي طبقة الأمان بين قرار النموذج والإجراء ذي الأثر الحقيقي.

طبّق طبقات حماية واضحة

1. ضع قائمة بيضاء بالأدوات التي يمكن للوكيل استدعاؤها تلقائيًا.
2. اطلب موافقة بشرية للإجراءات المدمرة أو غير القابلة للعكس.
3. وفّر وضع تشغيل تجريبي (dry run) يعرض ما سيحدث دون تنفيذه.
4. قيّد نطاق التأثير: حساب واحد، مورد واحد، أو عدد محدود من العناصر.
5. اختبر أن الحاجز يعمل عند توجيه الوكيل نحو نقطة نهاية ذات آثار جانبية.

مثال منطقي مبسط:

if (tool.name === "delete_customer" && !userApproved) {
  return {
    status: "requires_approval",
    message: "يلزم تأكيد بشري قبل الحذف",
  };
}

في الاختبار، حاكي نقطة نهاية الحذف ثم تحقق من أن الوكيل يطلب الموافقة بدل تنفيذ الطلب مباشرة.

توفر OWASP Top 10 لتطبيقات نماذج اللغة الكبيرة قائمة تحقق جيدة للمخاطر، بينما يشرح دليل الحواجز الوقائية لوكيل الذكاء الاصطناعي بوابات الموافقة والتحكم في نطاق التأثير بالتفصيل.

كيفية بناء اختبار للوكيل

يمكنك إعادة استخدام شكل الاختبار التالي مع كل أداة:

1. التقط العقد: وثّق مخطط الإدخال والإخراج لكل أداة.
2. حاكي التبعيات: تحكم في رموز الحالة والتأخير وأجسام الاستجابة.
3. شغّل سيناريوهات الفشل: لا تختبر مسار النجاح فقط.
4. التقط الطلبات الصادرة: افحص المسار والترويسات والجسم وعدد المحاولات.
5. تحقق من السلوك النهائي: هل تعافى الوكيل؟ هل توقف؟ هل طلب موافقة؟ هل تجاوز الميزانية؟

مثال لمصفوفة سيناريوهات:

السيناريو	استجابة التبعية	السلوك المتوقع
عقد غير صالح	400	فشل واضح وعدم متابعة التدفق
تقييد معدل	429 + Retry-After	تراجع وإعادة محاولة محدودة
خطأ خادم	500	إعادة محاولة أو إيقاف منظم
مهلة	لا استجابة	انتهاء مهلة ومعالجة آمنة
عملية مدمرة	200 محتمل	طلب موافقة قبل التنفيذ

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

قائمة التحقق لموثوقية الوكيل

قبل نقل الوكيل إلى الإنتاج، تأكد من الآتي:

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

أين يتناسب Apidog، وأين لا يتناسب

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

دوره هو إدارة واختبار طبقة API التي يعتمد عليها الوكيل:

• تصميم وحفظ عقود الأدوات.
• التحقق من صحة الطلبات الصادرة.
• محاكاة أخطاء مثل 429 و500 والمهلات والاستجابات المشوهة.
• كتابة تأكيدات على المخططات والمفاتيح المطلوبة والنطاقات.
• اختبار مسارات الاستعادة والحماية دون آثار جانبية حقيقية.

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

أسئلة مكررة

هل موثوقية الوكيل مشكلة نموذج أم مشكلة هندسية؟

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

هل يمكن اختبار وكيل دون الوصول إلى واجهات API الحقيقية؟

نعم، ويُفضّل ذلك. حاكِ التبعيات حتى تفرض الأخطاء وتتحكم في التوقيت وتتجنب الآثار الجانبية الفعلية.

كيف أختبر وكيلًا تتغير مخرجاته في كل تشغيل؟

اختبر المخطط والشكل والنطاقات والمعنى. لا تعتمد على تطابق النص الحرفي. راجع اختبار وكلاء الذكاء الاصطناعي غير الحتميين للتفاصيل.

ما أول شيء يجب اختباره؟

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

ابدأ بوضع فشل واحد

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

هذا الأسبوع:

1. حاكِ فشلًا واحدًا.
2. شغّل الوكيل.
3. التقط الطلبات وعدد المحاولات.
4. تحقق من سلوكه.
5. أضف تأكيدًا يمنع عودة الخطأ.

عندما ترى وكيلك يتعامل مع 429 محاكى بتراجع منظم بدل الدخول في حلقة تستنزف الميزانية، ستثق به لسبب أفضل من مجرد عرض توضيحي أخضر.

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