تتبّع أعطال الوكلاء المتعددين: شرح تطبيقي

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

نظام الوكلاء المتعددين هو عدة وكلاء LLM بأدوار متمايزة — مُخطِّط، ومُبرمِج، ومُراجِع — يتبادلون الرسائل ويسلّمون الزمام. وجدت الأبحاث في أسباب تعطّل هذه الأنظمة، أي تصنيف MAST (Why Do Multi-Agent LLM Systems Fail?)، أن معظم الأعطال تقع بين الوكلاء: قيد سقط عند التسليم، أو فريق لا يتحقق من عمله قط، أو وكلاء يتحدثون دون أن يفهم بعضهم بعضًا. ويخفي نص الدردشة المسطّح هذه الأمور بالضبط، لأن ما حدث من خطأ يكمن في الفراغ بين رسالتين، لا داخل أيٍّ منهما.

الفشل يقع بين الوكلاء، عند التسليم، لا داخل نص واحد

كيف أرى بنية تشغيل متعدد الوكلاء؟

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

علّم المسار الحرج وأشِر إلى عمليات التسليم المُشكِلة

annotation_schemes:
  - annotation_type: agent_interaction_graph
    name: graph
    description: "Mark the critical path and flag any problematic handoffs."
    steps_key: steps
    agent_key: agent

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

كيف أُسنِد فشل متعدد الوكلاء إلى وكيل واحد؟

بمجرد أن ترى التشغيل، ثبّت موضع الفشل. يطلب مخطط failure_attribution الثلاثي من أدبيات إسناد الفشل (Zhang وآخرون، Which Agent Causes Task Failures and When?، ICML 2025، مجموعة بيانات Who&When): الوكيل المسؤول، والخطوة الحاسمة، والسبب. تُملأ قائمة الوكلاء ومنتقي الخطوات من أدوار الأثر نفسه، فلا يمكنك إسناد الفشل إلا إلى وكيل وخطوة حدثا فعلًا.

أسنِد الفشل إلى الوكيل المسؤول، والخطوة الحاسمة، والسبب

annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

يعني اقتران الإسناد بزرّ نجاح/فشل أن الثلاثي لا يُجمَع إلا في التشغيلات التي فشلت، ما يُبقي وقت المُوسِّم على الحالات التي تحمل إشارة.

ماذا عن عمليات التسليم نفسها؟

يسمّي الإسناد خطوة حاسمة واحدة. أما مراجعة التسليم فتنظر في كل نقل للزمام. حيثما يتغيّر الوكيل العامل بين دورين متتاليين، يُصدر Potato بطاقة تسليم A → B، فتُعلِّم ما حدث من خطأ في التمرير — فقدان معلومات، أو قيد ساقط، أو تشويش، أو انحراف عن الهدف — وتقيّم الجودة. تأتي أنماط الفشل من فئة MAST بين الوكلاء وظاهرة «الترديد» (Zhang وآخرون، 2025).

أشِر إلى عدم الاتساق بين الوكلاء في كل تسليم وقيّم جودته

annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

تُشتق عمليات التسليم وقت العرض، فلا إعداد يدوي. وهنا عادةً تُحلّ حالات «بدا كل وكيل سليمًا ومع ذلك فشل الفريق»: كان القيد حيًّا عند الوكيل A وغاب عند الوكيل B.

كيف أُقيّم الوكلاء والفريق؟

يخبرك الفشل بما تعطّل مرة واحدة. أما بطاقة الأداء فتخبرك بما إذا كان التصميم جيدًا عبر تشغيلات كثيرة. يُقيّم مخطط agent_scorecard مستويين في آن واحد (MultiAgentBench، Zhou وآخرون، ACL 2025): كل وكيل على الوفاء بالدور والإسهام والتنسيق، والفريق على أبعاده المشتركة الخاصة، مع معالم اختيارية. تأتي صفوف الوكلاء من الأثر، فتطابق المصفوفة من شارك فعلًا.

قيّم كل وكيل على الوفاء بالدور والإسهام والتنسيق، إضافة إلى الفريق

annotation_schemes:
  - annotation_type: agent_scorecard
    name: scorecard
    description: "Score each agent, the team, and which milestones were reached."
    steps_key: steps
    agent_key: agent
    scale: 5
    agent_dimensions: [role fidelity, contribution, coordination]
    team_dimensions: [coordination, communication, efficiency]
    milestones: [plan produced, task delegated correctly, result verified]

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

ماذا عن التزامن والأعطال الجماعية؟

سطحان آخران يلتقطان أعطالًا لا تكشفها قراءة دورًا بدور. يضع خط tool_contention الزمني كل وكيل في مساره الخاص ويُبرز المناطق التي يلمس فيها نداءان المورد نفسه في أوقات متداخلة، فتصنّفها جمودًا، أو انتظارًا دائريًا، أو حالة تسابق، أو حميدة (DPBench، 2026).

ارصد حالات الجمود والتسابق على خط زمني لنداءات الأدوات لكل وكيل

ويتولّى emergent_behavior الأعطال الجماعية بدلًا من تلك الواقعة عند خطوة واحدة — التواطؤ، وتفكير القطيع، والأخطاء المتتالية، وانحراف الدور. السلوك الناشئ ليس مدى متصلًا؛ بل مجموعة من الأدوار المشاركة، ربما من وكلاء مختلفين، فتؤشّر الأدوار التي تشارك وتضيف ملاحظة.

وسّم التواطؤ وتفكير القطيع والأخطاء المتتالية عبر الوكلاء والأدوار

annotation_schemes:
  - annotation_type: tool_contention
    name: contention
    description: "Classify each shared-resource contention region."
    calls_key: calls
    agent_key: agent
    resource_key: resource
    contention_labels: [deadlock, circular_wait, race_condition, benign]
  - annotation_type: emergent_behavior
    name: emergent
    description: "For each collective behavior, check the turns that participate."
    steps_key: steps
    agent_key: agent
    behaviors: [collusion, groupthink, cascading_error, role_drift]
    allow_note: true

ترتيبها في تسلسل

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

قراءات إضافية

• تقييم فرق الوكلاء المتعددين — المرجع الكامل للمخطط مع صيغة YAML لكل سطح
• كيفية تقييم أنظمة الوكلاء المتعددين — دليل القرار حول أي طريقة تستخدم ومتى
• Potato 2.6.2: مجموعة كاملة مفتوحة المصدر لتقييم الوكلاء — كل ما صدر عبر خط الإصدار 2.6.x
• توسيم مسارات الوكلاء — تصنيفات الأخطاء لكل خطوة، بما في ذلك توسيم MAST بدقة الخطوة