لماذا نوزّع الأدوار بين عدة وكلاء بدل وكيل واحد يحمل كل شيء

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

الوكيل الواحد الذي يحمل كل شيء يتحول إلى صندوق أسود

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

الخطأ يفقد عنوانه

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

الصلاحيات تتضخم بصمت

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

البديل: فريق وكلاء بفصل واضح للأدوار

في معظم العمليات المؤسسية، أربعة أدوار تكفي لتغطية الدورة كاملة:

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

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

فصل المهام ليس اختراعاً جديداً

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

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

مثال عملي: دورة المشتريات موزّعة على وكلاء

دورة المشتريات مثال جيد لأنها ليست محادثة، بل عملية متعددة المراحل تمسّ المال والسياسة والموردين. توزيعها على أدوار يكون كالتالي:

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

ما الذي يتغير فعلياً

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

منصات low-code تسرّع النشر ولا تعوّض الحوكمة

منصات low-code مثل Copilot Studio جعلت إطلاق الوكلاء أسرع بكثير، وهذا تطور جيد ويستحق الاستفادة منه. لكن السرعة وحدها ليست نتيجة. السرعة بلا سجل تدقيق وبلا observability لحظية تعني فوضى أسرع، لا إنتاجية أعلى.

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

قدرة النموذج نادراً ما كانت العائق. العائق كان الحوكمة، ونموذج التشغيل، وملكية القرار.

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

تحفّظات يجب قولها

توزيع الأدوار له تكلفة

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

الفصل لا يغني عن الإنسان

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

من أين تبدأ

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

الخلاصة التي أعمل بها: ابدأ بالأدوار والحدود والمساءلة، ثم أضف القدرات.

ما أول عملية في مؤسستك تستحق أن تُقسَّم إلى أدوار، بدل وكيل واحد يحمل كل شيء؟