أربعة أنماط بسيطة للتعاون

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

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

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

واحد بعد آخر

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

مثال بسيط

تصل رسالة بريد من عميل.

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

يُسمّى هذا الترتيب عادةً سلسلة معالجة (Pipeline).

متى ينجح، وأين ينكسر

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

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

إرسال كل طلب إلى المتخصّص المناسب

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

مثال بسيط

نظام خدمات طلاب في جامعة. يسأل طالب شيئًا، فيذهب الطلب إلى من ينبغي أن يتولّاه:

• “لماذا فُرضت عليّ هذه الرسوم؟” → وكيل الشؤون المالية
• “هل أستطيع تغيير مقرّري الدراسي؟” → وكيل التسجيل
• “حسابي لا يقبل تسجيل الدخول.” → وكيل تقنية المعلومات
• أي شيء غير واضح أو غير معتاد أو حسّاس → أحد الموظفين

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

متى ينجح، وأين ينكسر

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

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

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

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

فريق يعمل في الوقت نفسه

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

مثال بسيط

لنعُد إلى الرحلة. يسأل المستخدم: “خطِّط رحلة ثلاثة أيام إلى برشلونة.”

يستنتج المنسّق أن هذا ينقسم إلى ثلاثة أسئلة مستقلة، فيسأل ثلاثة متخصّصين في الوقت نفسه:

• متخصّص الرحلات الجوية يقارن الرحلات.
• متخصّص الفنادق يقارن الفنادق.
• المتخصّص المحلي يتحقّق من الطقس ومن كيفية التنقّل.

يعملون دون حاجة إلى معرفة ما وجده الآخرون. ثم يجمع المنسّق الثلاثة في خطة رحلة واحدة.

والآن المصطلحات، وقد لقيتها كلها في الفصل 11. مَن ينسّق العمل هو المنسّق (Orchestrator). والمتخصّصون هم العاملون (Workers)، أو الوكلاء الفرعيون. وعملهم في الوقت نفسه هو التنفيذ المتوازي.

الفرق الأهمّ

يُخلط بين هذين النمطين خلطًا مستمرًّا، فيستحقّ الأمر بيانًا بأوضح ما يمكن:

موجِّه المسار يختار متخصّصًا واحدًا ليتولّى الطلب. والمنسّق يقسّم مهمة واحدة أكبر بين عدة متخصّصين ويجمع عملهم.

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

متى ينجح، وأين ينكسر

ينجح حين تكون الأجزاء مستقلة فعلًا وحين يكون هناك حجم حقيقي يجب إنجازه — وهي بالضبط حالة البحث من الفصل 11.

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

كيف تعطي تكليفًا كما يجب

التفويض الغامض هو سبب معظم خيبة الأمل من هذه الأنظمة. فـ“ابحث عن المنافس”، إذا أُعطيت لثلاثة وكلاء، تُنتج ثلاثة وكلاء يقرؤون المقالات الثلاث نفسها.

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

السطر الأخير هو ما يحذفه الناس، وهو ما يمنع التكرار. وكل عامل ينبغي أن يعرف ما ليس من عمله.

الإنسان جزءًا من التصميم

فكّر في مساعد الطيّار. الذكاء الاصطناعي ينجز العمل؛ والإنسان يتّخذ القرار الذي يهمّ.

مثال بسيط

حجز رحلة جوية، وهو ما ندور حوله منذ الفصل 1.

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

الإنسان: يراجع، ويختار، ويوافق على الشراء.

ثم الذكاء الاصطناعي: يُكمل الإجراء الذي صار مسموحًا له الآن أن يتّخذه.

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

الإنسان ليس مجرّد ملاذ للطوارئ. يمكن أن يكون جزءًا مصمَّمًا في مسار العمل.

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

تمرير العمل بين الوكلاء

تسليم المهمة (Handoff) هو أي نقطة ينتقل فيها العمل من وكيل إلى آخر. وكل نمط سابق فيه تسليمات: ثلاثة في سلسلة المعالجة، وطبقة واحدة في الفريق المنسَّق، وواحد في موجِّه المسار.

ويمكن أن يحمل التسليم أيًّا من عدة أمور، ويستحقّ الأمر أن تقرّر أيَّها:

• بيانات مهيكلة؛
• ملخّص قصير؛
• مؤشّر إلى مستند مشترك؛
• النتيجة الكاملة؛
• حالة المهمة حتى الآن.

والدرس الذي تتمسّك به، وهو ينطبق على كل واحد منها:

كل تسليم مهمة موضع يمكن أن تُفقد فيه المعلومات أو تُفهم على غير وجهها.

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

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

والصياغة التقنية لهذا هي مرِّر المراجع لا الحِمل (pass references, not payloads)، وهي من أعلى العادات قيمةً في هذا الجزء من الكتاب كله. فسياق المنسّق يبقى صافيًا. والتفاصيل لا تُفقد في التلخيص، لأنها لم تُلخَّص أصلًا. هي في مكان آخر فحسب، كاملةً، حتى يحتاجها أحد.

معرفة متى تتوقّف

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

اكتب الشرط. ومن الشروط المفيدة:

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

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

والبند الثاني يستحقّ وقفة. فـ“هل لديّ ما يكفي للإجابة؟” سؤال يمكن أن يُسأل عنه المنسّق صراحةً. أما “هل أستطيع أن أجد أكثر؟” فلا، لأن الجواب دائمًا نعم.

القدرة على رؤية ما حدث

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

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

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

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

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