الانتقال إلى المحتوى الرئيسي

المنسّق مُوزّع مهام: لماذا تفشل أسر الوكلاء في الطوابير لا في الاستدلال

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

A thematic Star Wars droids display at Disney's Hollywood Studios in Bay Lake, Florida.

العَرَض والتشخيص الخاطئ

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

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

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

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

التحكم في القبول كأول قرار تصميمي

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

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

A close-up view of a DJ mixer, showcasing its knobs and controls.

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

آلية ملموسة: مثّل حالة المنسّق كدفتر أستاذ لا كمحادثة. كل مهمة مقبولة تحمل إجارة — (task_id, worker_slot, budget_slice, deadline). تُحرَّر الإجارة عند الإكمال، أو عند الفشل الصريح، أو عند انتهاء الأجل. ومهمة المجدول في كل نبضة هي مطابقة المهام المنتظرة مع الإجارات الحرة. هذا غير مبهر وهو اللعبة كلها.

الضغط العكسي بين الوكلاء

ينبغي أن يكون الوكلاء الفرعيون قادرين على الإشارة بـ«ليس الآن» بدلًا من استيعاب العمل والفشل متأخرًا. الفشل المتأخر مكلف: فقد استهلك العمل بالفعل سياقًا ورموزًا ووقتًا، ويظهر الفشل عند نقطة يكون فيها الأصل قد فقد المعلومات اللازمة للتعافي بتكلفة زهيدة.

آليتان تجعلان الرفض المبكر آمنًا.

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

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

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

أربعة قياسات لكل نوع مهمة تغطي معظم أرض التشخيص:

Close-up of an automated can filling machine in a beverage production line.

  • عمق الطابور — مقدار العمل المنتظر، مُقاسًا عبر الزمن.
  • زمن الانتظار — زمن استجابة القبول، من الإدراج في الطابور إلى منح الإجارة.
  • زمن المطالبة إلى الإكمال — زمن التنفيذ، مفصولًا عن زمن الانتظار حتى يمكن نسب كل منهما.
  • معامل تضخّم إعادة المحاولة — إجمالي المحاولات مقسومًا على وحدات العمل المتمايزة.

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

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

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

قاعدة تصميمية

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

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

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

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

مشاركةXLinkedInرابط دائم5 دقيقة قراءة

قراءات ذات صلة

الأسئلة التي يجيب عنها هذا

Why are multi-agent failures usually misdiagnosed as reasoning errors?

Incident reports describe symptoms that look cognitive — looping, contradiction, duplicated work — so the first hypothesis is prompt or model quality. Trace inspection usually shows those symptoms are downstream of a queue: a slow tool call causes siblings to time out, retry, and re-enter the same work. The reasoning is often adequate; the system simply has no mechanism to shed or defer load.

What does admission control mean for an agent swarm?

Every fan-out edge declares a maximum width and a maximum depth at design time. A task is admitted only when a worker slot and a budget slice are both available; otherwise it is queued with a deadline or dropped with a recorded reason. Dropping is a legitimate outcome. Silent unbounded expansion is not.

How does backpressure work between agents?

Sub-agents signal 'not now' instead of absorbing work and failing late. A shared queue with visibility timeouts ensures only one worker claims a unit of work at a time, and idempotency keys make retries safe, which is what allows refusal to be aggressive rather than risky.

What should be instrumented in a multi-agent system?

Queue depth, wait time, claim-to-completion time, and retry amplification factor per task type. A run should be reconstructable as a timeline of admissions rather than a list of messages. Alert on amplification factor, not on agent count.

Should the orchestrator be a planner or a dispatcher?

A dispatcher with a scheduler, a budget ledger, and a dead-letter path. Planner output should be a task graph with declared widths and depths, not free-form delegation. The swarm should be measured on throughput and completion under load, not on the elegance of its dialogue.