كيف نبني نظام وكلاء احترافي؟ من مشهد الكارثة إلى المدير والوكلاء المتخصصين

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

“حلّ مشاكل العملاء… ولا تزعل حدا.”

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

لكن من هذه الجملة نفسها بدأت الكارثة.

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

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

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

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

رح تعرف كيف تتجنب كارثة الوكيل الواحد؟ وتصمم Agentic System قابلًا للتوسع؟

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

كيف تبدأ الكارثة؟ عندما تعطي وكيلًا واحدًا هدفًا غامضًا وصلاحيات واسعة

المشهد الكارثي لا يبدأ عادة من خطأ تقني معقد.
ولا من خلل نادر في النموذج.
ولا من خوارزمية غامضة في العمق.

غالبًا يبدأ من شيء يبدو بسيطًا جدًا:
هدف غامض + صلاحيات واسعة + غياب طبقة توقف أو مراجعة.

وهذا بالضبط ما حدث مع عامر.

هو لم يقل للوكيل:

• راجع الشكاوى فقط
• ضمن سياسة واضحة
• ولا ترسل شيئًا نهائيًا من دون مراجعة
• ولا تقدم تعويضًا إلا إذا تحققت من حالة الطلب
• ولا تتعامل مع تغيير العنوان من دون موافقة

بل أعطاه جملة عامة:
“حل مشاكل العملاء… ولا تزعل حدا.”

لو كانت هذه جملة بين موظفين يعرفان بعضهما جيدًا، فقد تمر.
لكن داخل نظام وكيل، هذه الجملة ليست ذكية. هي غامضة جدًا.

لأن “حل المشكلة” قد يعني أشياء كثيرة:

• هل الحل هو تهدئة العميل؟
• أم تطبيق السياسة؟
• أم تقديم تعويض؟
• أم تصعيد الحالة؟
• أم مجرد تجهيز مسودة رد؟

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

وهنا يبدأ الانحراف.

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

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

في المحادثة العادية، الغموض قد ينتج سوء تفاهم.
أما في الأنظمة الذكية الموصولة بأدوات، فقد ينتج:

• رسالة أُرسلت
• قرارًا اعتمد
• حالة عُدلت
• أثرًا تراكم
• أو سلسلة أخطاء بدأت من نية طيبة جدًا

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

• الفهم
• القرار
• التنفيذ
• التقدير
• والسياسة

وكلما كبرت هذه النقطة، صار الخطأ فيها أكثر تضخيمًا.

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

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

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

أنماط الفشل: كيف يخطئ الوكيل عندما يكون غير مضبوط؟

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

1) صلاحيات زائدة: عندما تكون العصا مفتوحة أكثر من اللازم

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

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

المشكلة هنا ليست في أن الوكيل “يريد” أن يخطئ، بل في أن النظام لم يميز بين:

• ما يجوز قراءته
• ما يجوز اقتراحه
• ما يجوز تحديثه
• وما يجب أن يبقى خلف موافقة بشرية

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

2) خرق السياسة: عندما يفسّر النجاح بشكل لا يشبه نجاحك

من أخطر ما يحدث في الأنظمة الوكيلة أن يكون للوكيل هدف “جميل” لكنه غير منضبط.
مثل:

• أرضِ العميل
• حل المشكلة بسرعة
• لا تعقد الأمور
• سهّل العملية

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

عامر مثلًا لديه سياسة واضحة:

• الإرجاع خلال 14 يومًا
• لا تغيير عنوان بعد دخول الطلب إلى مرحلة الشحن
• لا تعويض من دون تحقق
• ولا استثناءات من دون مراجعة

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

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

3) الافتراض أو الهلوسة: عندما يملأ الفراغ بثقة

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

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

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

• اعتماد حالة دفع غير مؤكدة
• ربط رسالة بعميل خطأ
• اعتبار طلب جاهزًا للشحن لأنه “يبدو كذلك”
• أو افتراض أن السياسة تسمح بما لم يثبت أصلًا أنها تسمح به

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

ولهذا كانت إحدى علامات النضج الأساسية في المقال السابق هي:
متى يجب على الوكيل أن يسأل بدل أن يخمّن؟

إذا لم تُبنَ هذه اللحظة داخل النظام، فالفراغ غالبًا لن يبقى فراغًا. سيتحول إلى افتراض.

4) تسريب البيانات: عندما يختلط السياق والهوية والمعلومة

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

قد يبدو هذا نظريًا في البداية، لكنه عملي جدًا:

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

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

5) تضخيم الأثر: عندما يسرّع الذكاء الخطأ بدل أن يخففه

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

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

أي أن المشكلة لا تعود:
“هل سيخطئ؟”
بل:
إذا أخطأ، كم حالة سيلمس؟ وكم أثرًا سيضاعف قبل أن ننتبه؟

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

ماذا تكشف لنا هذه الأنماط كلها؟

تكشف شيئًا مهمًا جدًا:
الكارثة لا تبدأ عادة من “نموذج سيئ”.
بل من تصميم يسمح للخطأ بأن يتحول من انحراف صغير إلى أثر نظامي.

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

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

لماذا لا تحل المشكلة بوكيل واحد “أذكى”؟

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

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

لأن المشكلة ليست دائمًا أن الوكيل الفردي لا يعرف ما يكفي.
أحيانًا تكون المشكلة أنه يحمل أكثر مما ينبغي.

يحمل:

• أكثر من نوع مهمة
• وأكثر من سياسة
• وأكثر من مستوى صلاحية
• وأكثر من مصدر حقيقة
• وأكثر من حساسية تشغيلية
• وأكثر من معيار نجاح

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

هذه هي فكرة Single Point of Failure في أبسط صورها.
حين تضع كل شيء في يد وكيل واحد، فأنت لا تبني فقط “مساعدًا شاملًا”، بل تبني أيضًا نقطة مركزية إذا انحرفت، انحرف معها كل شيء.

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

وهنا نصل إلى نقطة دقيقة جدًا:
الأنظمة لا تنهار فقط لأن أحد مكوناتها “غبي”، بل لأنها أحيانًا مركزة أكثر مما ينبغي.

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

• كلما زاد التركيز في نقطة واحدة
• وكلما اتسع نطاق السلطة في جهة واحدة
• وكلما غاب الفصل بين الأدوار
• زادت تكلفة الخطأ عندما يحدث

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

عامر لا يحتاج دائمًا إلى وكيل واحد يعرف كل شيء عن:

• الشحن
• والدفع
• والمرتجعات
• والردود
• والمخزون
• والسياسات
• والتعويضات
• والحالات الحساسة

الأذكى غالبًا أن يكون عنده نظام يوزع هذه المسؤوليات بدل أن يراكمها في جهة واحدة.

وهنا بالضبط تظهر الترقية الطبيعية.
ليست الترقية من وكيل ضعيف إلى وكيل أقوى فقط،
بل من وكيل واحد إلى منظومة وكلاء.

الترقية الطبيعية: من وكيل واحد إلى Agentic System

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

وهذا هو التحول الحقيقي من “الوكيل” إلى “النظام الوكيلي”.

الفكرة ببساطة ليست أن نلغي الذكاء، بل أن نوزعه بشكل أفضل.

بدل أن نقول:
“لدينا وكيل واحد لكل شيء”
نقول:
“لدينا منظومة فيها من يفهم الهدف الكبير، ثم يوزع المهام، ثم يجمع النتائج، بينما يعمل كل وكيل مختص ضمن نطاق أضيق وصلاحيات أوضح.”

وهذا التحول مهم لثلاثة أسباب كبيرة:

1) تقليل نطاق الخطأ

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

2) وضوح الأدوار والصلاحيات

عندما يعرف كل وكيل:

• ما الذي يخصه
• وما الذي لا يخصه
• وما الذي يستطيع لمسه
• وما الذي يجب أن يرفعه لغيره
  يصبح النظام أوضح وأكثر قابلية للضبط.

3) سهولة التطوير والتحسين

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

بالنسبة لعامر، هذه النقلة قد تبدو هكذا:

بدل وكيل واحد يقول له:
“أنا سأحل كل شيء في المتجر.”

يصبح عنده نظام أقرب إلى هذا:

• وكيل لخدمة العملاء
• وكيل للشحن
• وكيل للدفع والفواتير
• وكيل للمخزون والمنتجات
• وفوقهم Supervisor Agent يفهم الهدف العام، ويوزع، ويجمع، ويطلب الموافقة عند الحاجة

هنا لم نصنع “ذكاءً أكثر” فقط.
بل صنعنا بنية أكثر نضجًا.

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

ومن هنا، نصل إلى السؤال الأهم في هذا الجزء:
إذا كنا سنوزع العمل، فمن الذي يدير المشهد؟
ومن الذي ينفذ؟
وهنا يدخل أول عنصر معماري فعلي في المنظومة: المدير.

Supervisor Agent: المدير الذي لا ينفذ كل شيء بنفسه

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

هذا هو معنى Supervisor Agent.

المدير هنا لا ينبغي أن يتحول إلى “وكيل خارق” جديد يعيد جمع كل السلطات داخله.
وظيفته الأساسية أقرب إلى:

• قراءة الهدف العام
• تفكيكه إلى مهام فرعية
• تحديد من الأنسب لكل مهمة
• تنسيق التسلسل أو التوازي
• جمع النتائج
• ورفع نقاط القرار أو الموافقة عند الحاجة

بمعنى آخر:
هو لا يحمل كل الأدوات، بل يحمل منطق الأوركسترا.

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

• ما المطلوب
• ما الأقسام المعنية
• من يقرأ ماذا
• من ينفذ ماذا
• أين توجد نقطة حساسة
• ومتى يجب أن يتوقف كل شيء ليعود القرار إلى الإنسان

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

هنا المدير لا ينفذ هذه الأشياء كلها بنفسه.
بل يفهم أن عنده ثلاث مسارات:

• شحن
• خدمة عملاء
• دفع

ثم يوزع:

• الحالات المتعلقة بالشحن إلى وكيل الشحن
• الرسائل إلى وكيل خدمة العملاء
• المشاكل المالية إلى وكيل الدفع
• ثم يجمع الناتج في تقرير واحد:
  • ما الذي تم
  • ما الذي توقف
  • ما الذي يحتاج موافقة
  • وما الذي يحتاج قرارًا بشريًا

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

هذه النقطة مهمة جدًا لأن الناس أحيانًا تحوّل فكرة المدير إلى مجرد “موجه prompts”.
بينما دوره في الأنظمة الجيدة أعمق من ذلك:

• هو منطق توزيع
• ومنطق جمع
• ومنطق تصعيد
• ومنطق إعادة تركيب

ولهذا، فإن المدير الجيد لا يلغي المتخصصين، بل يجعلهم يعملون كنظام.

Specialist Agents: لماذا تحتاج عمالًا مهرة لا ساحرًا واحدًا؟

إذا كان المدير هو من يفهم المشهد ويوزع العمل، فالمتخصصون هم من يمنحون النظام التركيز والانضباط.

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

هذا هو معنى Specialist Agents.

بدل أن نجعل وكيلًا واحدًا يتعامل مع:

• الشحن
• والدفع
• والمرتجعات
• وخدمة العملاء
• والمخزون
• والسياسات
• والتعويضات

نقسم هذه المجالات إلى وكلاء مختصين.
كل واحد منهم يعرف:

• ما الذي يخصه
• ما الأدوات التي يحق له استخدامها
• ما السياسة المرجعية الخاصة به
• وما الحالات التي يجب أن يرفعها للمدير أو للبشر

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

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

هذه الحدود ليست تقييدًا للذكاء، بل نضج في التصميم.

وبالنسبة لعامر، يمكن أن يكون عنده مثلًا:

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

هنا صار عنده فريق، لا بطلًا خارقًا.

وهذا يعطيه ثلاث مكاسب ذهبية:

1) أخطاء أقل

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

2) تتبع أسهل

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

3) أمان أعلى

لأن الصلاحيات يمكن أن تُوزع حسب الدور، لا حسب الحلم الكبير لوكيل شامل.
وهنا تظهر أهمية:

• Role-Based Access
• وSeparation of Duties

أي أن الوصول إلى الأدوات والبيانات لا يُعطى بناء على “ذكاء الوكيل”، بل بناء على وظيفته.

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

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

أنماط التشغيل الخمسة: كيف ينسّق النظام بين الوكلاء؟

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

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

1) Prompt Chaining: سلسلة الخطوات الواضحة

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

في هذه الحالة، لا يكون الذكاء في “القفز إلى النتيجة”، بل في تقسيم الطريق نفسه.
مثلًا عند عامر:

1. اسحب طلبات اليوم
2. صفِّ المدفوع منها
3. تحقق من العناوين
4. أنشئ البوالص
5. ابنِ قائمة الطباعة
6. أخرج الاستثناءات للمراجعة

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

ولهذا، فـ Prompt Chaining ممتاز عندما:

• تكون المهمة مركبة لكنها قابلة للتفكيك
• يكون الترتيب مهمًا
• وتريد تحكمًا أعلى ومراجعة أوضح

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

2) Routing: بوابة توزيع المسارات

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

هذا هو منطق Routing.

تصل رسالة، أو طلب، أو مهمة، فيقف عند “بوابة” تصنيف أولية:

• هل هذه مشكلة شحن؟
• أم استرجاع؟
• أم دفع؟
• أم مخزون؟
• أم شيء يحتاج مراجعة بشرية أصلًا؟

ثم بعد التصنيف، يُرسل الإدخال إلى الوكيل أو المسار الأنسب.

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

بالنسبة لعامر، يمكن أن تبدو هكذا:

• “وين طلبي؟” → مسار الشحن
• “بدي أرجّع المنتج” → مسار الإرجاع والسياسة
• “انخصم المبلغ مرتين” → مسار الدفع
• “المنتج غير متوفر” → مسار المخزون

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

3) Parallelization: عندما لا يجب أن ننتظر خطوة واحدة فقط

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

له صورتان مفيدتان جدًا:

أ) Sectioning — تقسيم المهمة إلى أجزاء مستقلة

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

في حالة عامر مثلًا، لو أراد تجهيز شحنات اليوم، يمكن تشغيل:

• وكيل يتحقق من العناوين
• وكيل يطابق الدفع
• وكيل يبني المسودات أو الرسائل المتعلقة بالحالات المتأخرة

ثم يجمع المدير النتائج بعد ذلك.

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

ب) Voting — تشغيل عدة محاولات ثم اختيار الأفضل

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

هذا مفيد مثلًا عندما:

• تكون الصياغة حساسة
• أو القرار يحتاج أكثر من منظور
• أو تريد تقليل أثر الانحياز في مخرج واحد

في متجر عامر، لو كانت هناك رسالة اعتذار حساسة جدًا لعميل مهم، فقد يكون من الأفضل:

• توليد ثلاث مسودات
• ثم تمريرها إلى مقيّم أو قاعدة فحص
• ثم اختيار النسخة الأنسب من حيث السياسة والنبرة والوضوح

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

4) Orchestrator–Workers: المدير الذي يقرر من الذي يعمل ومتى

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

هذا مهم جدًا في الحالات التي لا يمكن توقعها بشكل ثابت.

مثلًا، لو كتب عميل لعامر:
“وصلني منتج ناقص، والفاتورة فيها مشكلة، وأنا أصلًا غيرت العنوان من قبل.”

هذه ليست رسالة شحن فقط، ولا دفع فقط، ولا سياسة فقط.
هنا المدير يحتاج أن يقول:

• هذه الحالة تحتاج وكيل شحن
• ووكيل دفع
• وربما وكيل سياسة أو خدمة عملاء
• ثم تُجمع النتيجة لاحقًا في صورة واحدة

هذا هو قلب Orchestrator–Workers:

• المدير يفهم الهدف أو المشكلة
• يقرر ما المهام الفرعية اللازمة
• يوزعها على العمّال المناسبين
• ثم يعيد تركيب الناتج

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

5) Evaluator–Optimizer: وكيل يكتب… وآخر يراجع

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

فكرته بسيطة وقوية:

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

الفرق بين هذا وبين “التدقيق العادي” أن التقييم هنا ليس ذوقيًا فقط، بل مبني على معايير:

• هل النص متوافق مع السياسة؟
• هل المعلومات مكتملة؟
• هل النبرة مناسبة؟
• هل هناك افتراضات غير موثقة؟
• هل كشف المخرج شيئًا لا ينبغي كشفه؟

في متجر عامر، لو كان المطلوب ردًا حساسًا على شكوى تتضمن احتمال تعويض، فيمكن أن يعمل هذا النمط هكذا:

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

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

متى تستخدم كل نمط؟ ومتى لا تحتاجه أصلًا؟

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

ليست القضية أن تعرف أسماء الأنماط الخمسة فقط. القضية أن تعرف:

• متى يكفيك النمط الأبسط
• ومتى تكون الزيادة في التعقيد تضيف قيمة فعلًا
• ومتى تكون مجرد زخرفة هندسية

القاعدة الذهبية هنا بسيطة جدًا:

استخدم Prompt Chaining عندما:

• تكون الخطوات واضحة ومتتابعة
• وتريد تحكمًا عاليًا
• وتريد أن تفحص الناتج بين مرحلة وأخرى

استخدم Routing عندما:

• تكون المشكلة الأولى هي: “إلى أي مسار يجب أن تذهب هذه الحالة؟”
• وتكون الأنواع مختلفة بوضوح
• وتريد فصل الصلاحيات والمنطق حسب نوع الطلب

استخدم Parallelization عندما:

• تكون أجزاء من العمل مستقلة
• أو تريد السرعة
• أو تريد عدة محاولات لمقارنة الجودة

استخدم Orchestrator–Workers عندما:

• لا يمكنك تحديد المهام الفرعية مسبقًا دائمًا
• والحالات مركبة أو غير متوقعة
• وتحتاج إلى مدير يفككها ثم يوزعها

استخدم Evaluator–Optimizer عندما:

• تكون الجودة أو السلامة أو الامتثال نفسه جزءًا من المهمة
• ويكون التحسين المتكرر يضيف قيمة حقيقية

لكن الأهم من هذا كله هو ما يلي:
ليس كل نظام يحتاج كل الأنماط.

بل إن أغلب الأنظمة الجيدة تبدأ غالبًا بشكل أبسط كثيرًا مما يتخيله الناس:

• ربما Routing بسيط
• أو Chaining من ثلاث مراحل
• أو وكيل واحد مع مسار تصعيد واضح

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

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

كيف يطبق عامر هذا على متجره؟

لنعد إلى عامر، لكن هذه المرة لا كصاحب متجر يملك “وكيلًا ذكيًا”، بل كصاحب متجر بنى نظامًا وكيليًا فعليًا.

بدل أن يقول:
“عندي وكيل يحل كل شيء.”
صار عنده تصميم أقرب إلى هذا:

المدير

وكيل مشرف يفهم الأهداف اليومية العامة:

• جهّز شحنات اليوم
• خفف ضغط رسائل العملاء
• راقب الحالات المعلقة في الدفع
• وارجع لي بما يحتاج قراري

الوكلاء المختصون

• وكيل خدمة العملاء
• وكيل الشحن
• وكيل الدفع
• وكيل المخزون

الأنماط المستخدمة

• Routing لتوجيه الرسائل حسب نوعها
• Prompt Chaining في تجهيز الشحنات
• Parallelization في التحقق من الدفع والعناوين والحالات النصية
• Evaluator–Optimizer في الردود الحساسة أو العروض التعويضية
• وOrchestrator–Workers عندما تكون الحالة مركبة وتجمع أكثر من نوع مشكلة

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

وهذا هو جوهر النظام الجيد:
ليس أن يبدو “ذكيًا” فقط، بل أن يكون قابلًا للإدارة والتطوير والتشخيص.

القاعدة الذهبية: ابدأ بالأبسط، ثم ابنِ التعقيد عندما يضيف قيمة

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

أفضل قاعدة في هذا العالم ليست:
“ابنِ النظام الأكثر تعقيدًا الذي تستطيع تخيله.”

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

لماذا؟ لأن كل طبقة تضيفها لها كلفة:

• في البناء
• في الفهم
• في المراقبة
• في الصيانة
• في الاختبار
• وفي احتمالات الفشل أيضًا

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

الذكاء الحقيقي هنا ليس أن تبني الأكثر إبهارًا.
بل أن تبني الأكثر ملاءمة.

فهرس الكتاب: القواعد الذهبية لبناء الأنظمة الوكيلة

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

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

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

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

ما نوع الذكاء الذي أحتاجه هنا؟
وما البنية التي تجعل هذا الذكاء مفيدًا… لا فوضويًا؟