كيف يعمل عملاء الذكاء الاصطناعي المدير والمنفّذون معًا

#لماذا يصطدم العميل الواحد بجدار

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

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

#النمط الأساسي: مدير واحد، عدة عمال منفّذين

النمط الذي يتكرر ظهوره — في أنظمة دعم العملاء، ومساعدات البرمجة، وأدوات البحث — هو نمط المدير والعمال المنفّذين (manager/worker)، ويُعرف أيضًا بنمط المنسّق والعملاء الفرعيين، أو المشرف والمتخصصين. يتكوّن من ثلاثة عناصر:

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

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

#تشريح عميل مدير

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

من الناحية العملية، تبدو حلقة المدير كالتالي:

1. قراءة الهدف الفعلي للمستخدم.
2. تحديد ما إذا كان يمكن معالجته مباشرة، أو أنه يحتاج إلى تقسيم إلى مهام فرعية.
3. في حال التقسيم، كتابة وصف مهمة مستقل لكل مهمة فرعية — واضح بما يكفي ليتمكن عامل منفّذ لا يملك أي سجل محادثة سابق من استلامه فورًا ومعرفة المطلوب بدقة.
4. إرسال أوصاف المهام، إما واحدة تلو الأخرى (تسلسليًا) أو دفعة واحدة (بالتوازي).
5. استلام نتيجة كل عامل منفّذ — إجابته النهائية المهيكلة فقط، وليس نصّه الخام أو تفكيره الوسيط.
6. تحديد ما إذا كانت النتيجة كافية، أو تحتاج إلى مهمة متابعة، أو يجب إعادة إسنادها بتوجيه مصحَّح.
7. بمجرد حل جميع المهام الفرعية، تركيب الإجابة النهائية للمستخدم.

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

#تشريح عميل منفّذ

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

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

#كيف تتحدث العملاء فعليًا مع بعضها البعض

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

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

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

#كيف يبدو التسليم فعليًا

يُرسم المخطط

كل تبادل في هذا المخطط هو، في العمق، رسالة على غرار JSON-RPC تُنقل عبر stdio أو HTTP أو ناقل أحداث. المدير لا يتحدث مباشرة إلى الأدوات الأساسية لعمل قام بتفويضه — هو لا يرى إلا النتيجة المهيكلة التي يختار كل عامل منفّذ إعادتها إليه.

#دورة حياة المهمة، خطوة بخطوة

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

يُرسم المخطط

1. التقسيم. يحوّل المدير هدفًا واسعًا إلى مهام فرعية قابلة للإنجاز بشكل مستقل — لا ينبغي لأي مهمة فرعية أن تعتمد بصمت على نتيجة مهمة أخرى لا تنتظرها صراحةً.
2. التحديد. تحصل كل مهمة فرعية على وصف مستقل بذاته: الهدف، القيود، شكل الإخراج المتوقع، وأي مدخلات يحتاجها العامل المنفّذ فعليًا — ليس "اذهب واعرف عن كذا"، بل "اقرأ هذا الرابط واستخرج هذه الحقول الأربعة، بهذا الشكل".
3. الإسناد. يختار المدير عاملًا منفّذًا. أحيانًا لا يوجد سوى نوع واحد من العمال لكل مهارة؛ وأحيانًا يختار المدير من مجموعة بناءً على الحمل الحالي أو التخصص.
4. التنفيذ. يشغّل العامل المنفّذ حلقته الخاصة، باستخدام أدواته الخاصة، بشكل معتم تمامًا أمام المدير حتى ينتهي.
5. رفع التقرير. يعيد العامل المنفّذ نتيجة مهيكلة، يُفضَّل أن تكون مُتحقَّقًا منها وفق مخطط معيّن، حتى لا يضطر المدير إلى تحليل نص حر بحثًا عمّا يحتاجه.
6. التحقق. يتحقق المدير، أو عميل مُتحقِّق مخصَّص، من النتيجة مقابل الوصف الأصلي. هذه هي الخطوة التي تتجاهلها معظم الأنظمة في البداية ثم تندم لاحقًا — فبدونها، يمكن لنتيجة خاطئة لكن واثقة من عامل منفّذ أن تُفسد بصمت الإجابة النهائية.
7. الدمج أو إعادة المحاولة. كافٍ ← دمجها في الإجابة قيد البناء. غير كافٍ ← إعادة الإسناد بوصف مصحَّح، أو تصعيد الأمر إلى المستخدم بدلًا من التخمين.

#أربع طرق لتنسيق العمال المنفّذين

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

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

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

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

#متى لا تلجأ إلى عدة عملاء

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

#ما الذي قد يخطئ، وكيف يُعالَج

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

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

#السياق والذاكرة: ما يحتفظ به المدير، وما يحتفظ به العامل المنفّذ

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

هذا الفصل هو أيضًا ما يجعل الأنظمة متعددة العملاء مقاومة إلى حد كبير لمشكلة "الضياع في المنتصف" (lost in the middle) التي تصيب السياقات الطويلة جدًا لعميل واحد — فلا يحتاج سياق أي عميل فردي إلى أن ينمو أكثر مما تتطلبه مهمة فرعية واحدة مركّزة، مهما كبرت المهمة الإجمالية.

#مثال تفصيلي: فريق عملاء لإعداد تقرير بحثي

لنفترض أن الهدف هو "إعداد تقرير يقارن أسعار ثلاثة مزوّدي خدمات سحابية لحمل عمل محدد". قد يبدو تقسيم المدير/العمال المنفّذين على النحو التالي:

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

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

#مبادئ تصميم لبناء نظام كهذا بنفسك

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

#في الختام

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