تنسيق وكلاء الذكاء الاصطناعي: حالات الفشل والموافقات وإعادة المحاولات

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

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

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

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

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

لنلقِ نظرة على ما يحدث بعد أن تُسند مهمة إلى المنسِّق.

لنأخذ مثالًا من ورشة عمل Computer من Perplexity: إنشاء لوحة معلومات لتحليلات الحسابات باستخدام معلومات من Salesforce وSnowflake والبريد الإلكتروني والتقويم وآخر الأخبار.

فهم الهدف وتخطيط العمل. يبدأ المنسِّق بالنتيجة المطلوبة ويقسّمها إلى مهام ذات تبعيات صريحة. وفي مثال لوحة المعلومات، يتضمن ذلك جمع المعلومات من مصادر مختلفة وتحويلها إلى منتج نهائي. ويحدد المخطِّط الخطوات التي تعتمد على غيرها وتلك التي يمكن تشغيلها باستقلالية.
توجيه المهام إلى الوكلاء المناسبين. يحدد المنسِّق المهام التي استوفيت تبعياتها ويفوّض العمل إلى وكلاء أو نماذج متخصصة. وتنتظر المهام التابعة استيفاء متطلباتها المسبقة. ويستخدم Perplexity Computer عدة نماذج رائدة، ويوجّه الأجزاء المختلفة من سير العمل إلى الأنظمة المناسبة لتلك المهام. ويتيح ذلك أيضًا تشغيل الأعمال المستقلة بالتوازي.
تنفيذ استدعاءات الأدوات داخل بيئات خاضعة للتحكم. يتفاعل الوكلاء مع بيئتهم من خلال الأدوات، مثل البحث على الويب، وواجهات برمجة التطبيقات (APIs)، والتطبيقات المتصلة، وعمليات الملفات، أو تنفيذ الشيفرة البرمجية. وتشغّل طبقة التنفيذ هذه الإجراءات وتعيد النتائج إلى الوكلاء.
تمرير النتائج والسياق بين الوكلاء. بمجرد أن ينهي الوكيل مهمته، يحتاج الوكيل التالي في المسار إلى المخرجات ذات الصلة للمتابعة. وقد يتضمن سجل التسليم معرّف المهمة، ومرجع المخرجات، وإصدار المخطط، والبيانات الوصفية للمصدر. وينسّق المنسِّق عمليات التسليم هذه مع الحفاظ على السياق اللازم للخطوات اللاحقة. والأهم من ذلك أن الوكلاء لا يحتاجون إلى حمل السجل الكامل لعمل كل وكيل آخر في نوافذ السياق الخاصة بهم.
تسجيل حالة التنفيذ بمعزل عن سياق الوكيل. مع بدء الوكلاء للمهام أو إكمالها أو إخفاقهم فيها، يحدّث محرك التنفيذ سجلًا دائمًا لسير العمل يتضمن حالات المهام، ومحاولات التنفيذ، ومراجع المخرجات، والعمل المتبقي. ويتيح هذا السجل للمنسِّق تتبّع التقدم والاستئناف بعد الانقطاعات دون الاعتماد على نموذج لغوي كبير (LLM) لإعادة بناء سير العمل من سجل المحادثة.
التحقق من النتائج وتحديد الخطوة التالية. عندما تعود مهمة، تتحقق طبقة التنسيق مما إذا كانت مخرجاتها تفي بالعقد المتوقع، وما إذا كانت تبعيات المهمة التالية مستوفاة. وإذا اكتُشفت مشكلة، يمكن أن يعود سير العمل إلى خطوة سابقة للتصحيح أو يتوقف مؤقتًا. وإلا فإنه يمضي نحو الاكتمال.

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

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

ومن ثمّ، يكون التنسيق مفيدًا في ثلاثة سيناريوهات:

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

وفيما عدا ذلك، فإن التنسيق مجرد صيحة مكلفة. فالمزيد من الوكلاء يعني أيضًا مزيدًا من التنسيق واحتمال ارتفاع تكاليف الرموز (tokens).

«عادةً ما أبدأ بأبسط خيار ثم أبني عليه. إذا كنا نعرف الخطوات وكانت قابلة للتكرار، فهذا على الأرجح سير عمل. ولا أرى سببًا لإدخال عدة وكلاء إلا عندما تكون لديهم مسؤوليات أو أذونات أو مستخدمون مختلفون»، يقول Josh Spilker، رئيس تسويق البحث في AirOps.

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

هناك ثلاث طرق شائعة لهيكلة تنسيق الوكلاء: التنسيق المركزي، واللامركزي، والهرمي. ويتلخص اختيار البنية المناسبة في سؤال واحد: من يتحكم في العمل، وكيف ينسّق الوكلاء فيما بينهم؟

في التنسيق المركزي، يدير منسِّق واحد العملية. فهو يقسّم المهمة، ويفوّض العمل إلى وكلاء متخصصين، ويتتبّع تقدمهم، ويجمع نتائجهم معًا.

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

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

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

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

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

يوسّع التنسيق الهرمي نهج المدير عبر مستويات متعددة. إذ يفوّض منسِّق في المستوى الأعلى المسؤولية إلى منسِّقين تابعين، ينسّق كل منهم مجموعاته الخاصة من الوكلاء المتخصصين.

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

يمكن أن تساعد هذه البنية عندما تكون عمليات سير العمل أوسع من أن يديرها منسِّق واحد بفعالية.

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

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

مقارنة بين هذه البنيات:

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

ثمة فرق آخر جدير بالفهم. فالبنية تحدد من ينسّق بين الوكلاء، بينما يحدد نمط التنفيذ كيف تتقدم مهامهم.

فيما يلي ثلاثة أنماط للتنفيذ:

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

هذه الأنماط ليست متنافية، ولا يقابل كلٌّ منها بنية تنسيق واحدة بعينها. والهدف هو اختيار أبسط هيكل يدعم تبعيات سير العمل لديك، ومتطلبات التنسيق، والعبء التشغيلي المقبول.

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

عمليات تسليم تفقد المعلومات بين الوكلاء. يمرر المنسِّق خطة ملخصة إلى وكيل متخصص، لكن الملخص يُسقط قيودًا أو تبعيات أو تفاصيل تنفيذ.
تنفيذ التجميع (fan-in) قبل أوانه. يبدأ وكيل في مرحلة لاحقة في تجميع النتائج قبل اكتمال جميع المهام في المراحل السابقة.
تحديثات غير حتمية للحالة المشتركة. يكتب وكلاء متوازيون إلى مفاتيح الحالة نفسها دون دلالات دمج محددة جيدًا. وبحسب طريقة تعامل إطار العمل مع التحديثات، قد يؤدي ذلك إلى فقدان عمليات الكتابة، أو تكرار البيانات، أو مخرجات تعتمد على الترتيب، أو تغييرات متعارضة.
التباين بين نقاط الحفظ والآثار الجانبية. تنفّذ مهمة عملية خارجية، لكن نجاح تنفيذها لا يُسجَّل بشكل دائم قبل تعطل العامل. وعند الاستعادة، يرى المنسِّق مهمة غير مكتملة فيعيد تشغيلها.
حالات التسابق عند الاستئناف بعد الموافقة البشرية. يؤدي إيقاف التنفيذ مؤقتًا واستئنافه إلى مشكلات مزامنة خاصة به.
حلقات التفويض وتضخم إعادة المحاولة. يسلّم الوكلاء العمل بعضهم لبعض مرارًا لأن مسؤولياتهم متداخلة، أو لأن التبعيات دائرية، أو لأن شروط الإكمال غامضة.
الخلط بين الضوابط على مستوى التعليمات وأمان التنفيذ. قد يطلب المنسِّق من الوكلاء عدم الوصول إلى موارد معينة أو عدم تنفيذ إجراءات حساسة، لكن تعليمات النموذج لا تفرض أذونات نظام التشغيل أو قيود الشبكة أو حدود التفويض. وتسلّط أبحاث هندسة الأمان لدى Perplexity الضوء على أسباب تجاوز الوكلاء للحدود الأمنية أثناء سعيهم إلى تحقيق أهداف مشروعة، حتى دون تعليمات خبيثة

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

غالبًا ما تؤدي الأهداف المبهمة وعدم وضوح تعريف الإنجاز إلى نتائج مخيبة للآمال من الوكلاء. والحل هو عقد الموجّه (نطاق عمل للوكيل): اتفق على الهدف والقيود وتنسيق المخرجات وشروط الفشل قبل بدء التنفيذ.

على سبيل المثال، إليك كيف يمكنك تحديد عقد لوكيل مسؤول عن إصلاح اختبار تكامل يفشل بشكل متقطع:

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

لكن هناك جزء مهم آخر: متى يجب أن يتوقف الوكيل؟

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

لنعد إلى مثال CI. يمكنك تحديد شروط التوقف التالية:

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

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

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

تأمل هذا المثال: تشير status: completed إلى العمل المسند إلى الوكيل، لا إلى سير العمل بأكمله. ولأن الاختبارات لا تزال pending، فلا ينبغي للمنسِّق اعتماد النتيجة النهائية.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

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

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

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

لنفترض أن وكيل CI لديك يشغّل عملية اختبار، لكن طلب واجهة برمجة التطبيقات تنتهي مهلته. هل فشلت عملية الاختبار في البدء، أم أن خدمة CI وضعتها في قائمة الانتظار وفقدت الاستجابة؟

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

الأخطاء العابرة (429، 503): أعد المحاولة باستخدام تراجع أُسّي محدود مع تذبذب عشوائي (jitter)، مع احترام Retry-After عند توفيره.
أخطاء التحقق أو الأذونات (400، 403): توقف أو صحّح المشكلة الأساسية بدلًا من تكرار الطلب نفسه.
النتائج الغامضة (انتهاء المهلة بعد عملية كتابة محتملة): تحقق مما إذا كانت العملية قد نجحت قبل محاولتها مرة أخرى.

ملاحظة: حتى الأخطاء القابلة لإعادة المحاولة تحتاج إلى حدود. اضبط مهلة لكل استدعاء أداة، وحدّد سقفًا لمحاولات الإعادة ولإجمالي وقت الإعادة، وافرض موعدًا نهائيًا شاملًا لسير العمل حتى لا يتمكن الوكلاء المتداخلون من إعادة تشغيل العملية نفسها باستمرار. وإذا فشلت إحدى التبعيات مرارًا، فاستخدم قاطع دائرة (circuit breaker) لإيقاف الطلبات مؤقتًا.

بالنسبة إلى العمليات ذات الآثار الجانبية الخارجية، خصّص مفتاح عدم تكرار ثابتًا (idempotency key) لكل إجراء منطقي وأعد استخدامه عبر محاولات الإعادة. فإذا كانت واجهة برمجة التطبيقات تدعم إزالة التكرار من جانب الخادم، فيمكنها التعرف على الطلبات المكررة دون تنفيذ الإجراء مرتين. وإن لم تكن تدعم ذلك، فاستعلم من النظام الخارجي باستخدام معرّف ارتباط أو مرجع موثوق آخر.

عندما يتعذر عليك تحديد ما حدث، توقف وصعّد المشكلة.

مثال على منطق إعادة المحاولة لوكيل CI الخاص بنا، معبَّرًا عنه بشيفرة زائفة:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

ملاحظة حول الشيفرة: يفترض المثال أن واجهة برمجة تطبيقات CI تدعم البحث عن عمليات التشغيل حسب معرّف الطلب. ولا يمنع request_id التكرار إلا إذا كان المزود يضمن صراحةً عدم التكرار (idempotency). bounded_retry() شيفرة زائفة توضيحية. وفي بيئة الإنتاج، يجب أن تكون عمليات إعادة المحاولة محدودة بميزانية إعادة محاولة لكل عملية (الحد الأقصى للمحاولات أو الوقت المنقضي) وبالموعد النهائي الشامل لسير العمل.

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

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

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

على سبيل المثال، يتيح لك وضع الجهد (Effort Mode) في Perplexity Computer اختيار مقدار الجهد الذي تستحقه المهمة دون تحديد نموذج يدويًا. اختر Light أو Standard أو High أو Ultra، وسيختار Perplexity تلقائيًا النموذج المنسِّق ومستوى الاستدلال الخاص به. ثم يفوّض هذا المنسِّق المهام الفرعية إلى وكلاء مساعدين، يمكنهم استخدام نماذج من مزودين مختلفين.

يقيّم Perplexity تكوينات النماذج من حيث الجودة والتكلفة، مفضلًا الخيارات الأقل تكلفة التي تقدم نتائج مماثلة. ويمكنك أيضًا استخدام عناصر التحكم المخصصة (Custom) إذا كنت تفضل اختيار النموذج ومستوى الاستدلال بنفسك.

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

للحفاظ على استهلاك الموارد قابلًا للتنبؤ، افرض حدودًا للموارد وضوابط للجدولة:

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

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

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

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

بالنسبة إلى الإجراءات التي تتطلب موافقة بشرية، أوقف التنفيذ مؤقتًا واحفظ العملية المقترحة كما هي تمامًا:

معلماتها
موردها المستهدف
الإيداع أو إصدار الحالة الخاص بها
قرار المراجِع

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

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

كما لا يؤيد Spilker فكرة الوكلاء المستقلين تمامًا من البداية إلى النهاية الذين يُنظر إليهم باعتبارهم الهدف. ويختتم قائلًا: «بالنسبة لي، النهج الأفضل هو بناء عدد قليل من الوكلاء المركّزين ذوي المسؤوليات الواضحة والأذونات المحددة، مع مراجعة بشرية في المواضع المناسبة. فبهذا تظل تحقق الكفاءة دون التخلي عن السيطرة الكاملة».

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

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

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

توفر اصطلاحات GenAI الدلالية في OpenTelemetry طريقة موحدة لوصف هذه العمليات. على سبيل المثال، يحدد invoke_workflow تنفيذ سير العمل، وinvoke_agent استدعاء الوكيل، وexecute_tool استدعاء الأداة. ويمكن تسجيل كل عملية على أنها span مع توقيتها وحالتها والبيانات الوصفية ذات الصلة.

تمنحك هذه الخطوة تتبّعًا لمسار التنفيذ، لتتمكن من تحديد المواضع التي تعثّر فيها الوكيل.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

مثال توضيحي لتتبّع التنفيذ.

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

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

لا يزال عليك التحقق من صحة نتائج المراجِع حيثما أمكن، وإذا كنت تستخدم مقيّمين قائمين على النماذج اللغوية الكبيرة (LLM) لإجراء تقييمات متكررة، فعايِر أحكامهم مقابل أمثلة راجعها البشر.

حتى الآن، تتبّعتَ ما نفّذه الوكلاء وتحققتَ مما إذا كانت مخرجاتهم صحيحة. ولكن ماذا يحدث عندما يتعطّل عامل في منتصف مهمة ما، أو عندما تنتهي مهلة واجهة برمجة التطبيقات (API) بعد قبولها طلبًا؟ قد يفاجئك أن سير العمل لديك قد يعمل بشكل ممتاز في الظروف العادية، لكنه يفشل أثناء التعافي.

لاختبار ذلك، احقن الأعطال عمدًا في بيئة اختبار:

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

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

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

لهذا السبب، ينبغي لك التحقق من كلٍّ من الحالة المسجّلة لسير العمل والتغييرات الفعلية في الأنظمة الخارجية. ويجب ألا يجتاز اختبار التعافي إلا عندما يصل سير العمل إلى الحالة المتوقعة دون آثار جانبية غير مقصودة.

أضف الأعطال التي تكتشفها إلى اختبارات الانحدار لديك حتى لا تعيد التغييرات المستقبلية إدخالها.

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

يمكن للوكلاء المنعزلة إكمال مهامها الفردية بشكل صحيح، لكنها تُنتج معًا نتائج غير متسقة. تخيّل وكيل مبيعات يسترجع شروط العميل في الساعة 10:00، ووكيل تسعير يحسب عرض سعر باستخدام أسعار محدّثة في الساعة 10:05، ووكيلًا قانونيًا يراجع عقدًا تغيّر في الساعة 10:07. يعمل كل وكيل على لقطة مختلفة من وضع النشاط التجاري، لذا قد تتعارض مخرجاتها بعضها مع بعض.

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

ضع حدودًا على مستويات متعددة: الحد الأقصى لإعادة محاولات استدعاء الأدوات، والحد الأقصى لتكرارات الوكيل، وعمق التفويض، ومهلة نهائية شاملة لسير العمل. صنّف حالات الفشل قبل إعادة المحاولة. بالنسبة إلى استجابات 429 المؤقتة، التزم بقيمة Retry-After عند توفرها. وإلا، فاستخدم التراجع الأُسّي المحدود مع التذبذب العشوائي (jitter).

توقّف عن إعادة محاولة الطلبات غير المعدّلة بعد أخطاء التحقق من الصحة أو الأذونات. وإذا فشلت خدمة تابعة بشكل متكرر، فيمكن لقاطع الدائرة (circuit breaker) منع الوكلاء من توليد حمل إضافي.

تعتمد آلية التعافي على بيئة التشغيل التي تستخدمها. مع LangGraph، تخزّن أداة دائمة لحفظ نقاط الحفظ مثل PostgresSaver حالة الرسم البياني تحت المعرّف thread_id، مما يسمح باستئناف التنفيذ من الحالة المحفوظة. ومع Temporal، يمكن لعامل آخر إعادة بناء سير العمل عن طريق إعادة تشغيل سجل أحداثه. وأثناء إعادة التشغيل، يعيد استخدام نتائج الأنشطة المسجّلة سابقًا.

إذا أُعيد نشر التطبيق بينما لا تزال عمليات سير العمل قيد التشغيل، فقد لا تعود الحالة المحفوظة وسجلات التنفيذ متوافقة. يعالج Temporal ذلك من خلال Worker Versioning وتصحيح سير العمل (workflow patching). أما بالنسبة إلى الأنظمة القائمة على نقاط الحفظ، فخطّط لعمليات ترحيل المخطط، واختبر التعافي على الحالات المحفوظة الموجودة قبل طرح تغييرات غير متوافقة.

شغّل المهام التمثيلية نفسها عدة مرات، وميّز بين pass@k (ما إذا كانت محاولة واحدة على الأقل من أصل k محاولات تنجح) وpass^k (ما إذا كانت جميع المحاولات البالغ عددها k تنجح)

قِس النتائج حسب فئة المهمة وإصدار سير العمل بدلًا من الاعتماد على معدل نجاح إجمالي واحد. تتبّع نجاح المحاولة الأولى، والاتساق عبر عمليات التشغيل المتكررة، وزمن الاستجابة عند المئين 95 (p95)، والتكلفة لكل مهمة مكتملة، ونسبة المهام التي تتطلب تدخلًا بشريًا. وأبلغ عن أحجام العينات وفترات عدم اليقين لمعدلات النجاح.

ما تنسيق وكلاء الذكاء الاصطناعي؟

كيف يعمل تنسيق وكلاء الذكاء الاصطناعي: نظرة داخل محرك التنفيذ

متى ينبغي استخدام تنسيق وكلاء الذكاء الاصطناعي؟

بنيات تنسيق وكلاء الذكاء الاصطناعي ومفاضلاتها

التنسيق المركزي

التنسيق اللامركزي

التنسيق الهرمي

التنفيذ التسلسلي والمتوازي والقائم على التسليم

إخفاقات شائعة في تنسيق وكلاء الذكاء الاصطناعي

7 ممارسات مثلى لتنسيق وكلاء الذكاء الاصطناعي لضمان الموثوقية في بيئة الإنتاج

1. حدِّد عقود مهام صريحة ومعايير قبول وشروط توقف

2. حافظ على بساطة المنسِّقات وافرض عمليات تسليم منظمة

3. احفظ حالة سير العمل بشكل دائم وتحكّم في نمو السياق

4. صمّم عمليات إعادة محاولة تراعي أنواع الفشل وتنفيذًا للأدوات قابلًا للاستعادة

5. وجّه العمل ووزّعه على مسارات متوازية بميزانيات موارد صريحة

6. افرض الموافقات واعزل تنفيذ الوكلاء

7. تحقّق من المخرجات بشكل مستقل واختبر سلوك الاستعادة

تتبّع سير العمل لتحديد موضع الخطأ

راجع المخرجات بشكل مستقل

احقن حالات فشل لاختبار الاستعادة

الأسئلة الشائعة حول تنسيق وكلاء الذكاء الاصطناعي

لماذا تتعثّر وكلاء الذكاء الاصطناعي المنعزلة على مستوى المؤسسات؟

كيف تمنع حلقات إعادة المحاولة اللانهائية في وكلاء الذكاء الاصطناعي؟

كيف تستأنف سير عمل وكيل الذكاء الاصطناعي بعد حدوث عطل؟

كيف تختبر موثوقية تنسيق وكلاء الذكاء الاصطناعي؟