ابدأ من المشكلة

هذا ما يستحقّ أن يُقال قبل أي شيء آخر: ليست كل مشكلة تحتاج إلى وكيل. فأحيانًا تكفي نافذة محادثة. وأحيانًا تكون قاعدةٌ ونموذج إدخال أفضل وأقلّ كلفة وأكثر موثوقية. ومعرفة أيّ الحالتين أمامك هي معظم ا…

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

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

ابدأ من المشكلة، لا من التقنية

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

حدّد المشكلة

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

فريق الدعم عندنا يستهلك وقتًا طويلًا في إعادة تعيين كلمات المرور. ونريد أن يُنجَز ذلك من دونه.

محدّدة، وقابلة للقياس، ومرتبطة بنتيجة.

وضّح كيف يبدو النجاح

لمن هو، وما الذي ينبغي أن يفعله بالضبط؟ ثم قل ما معنى “أنه يعمل”:

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

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

افحص هل يحتاج الأمر إلى وكيل من الأصل

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

السؤال الرابع هو الذي يوقع أكثر الناس. المنطق المتوقَّع مكانه في برمجيات متوقَّعة. والوكيل للحالات التي لا يُعرف فيها شكل الطلب مسبقًا.

تصميم الوكيل

وحين تثبت ملاءمة المشكلة، صمّم الوكيل كما تُوجِّه زميلًا جديدًا. ما العمل؟ وما الذي يُسمح له بلمسه؟ وما الذي يحتاج إلى معرفته؟

خمسة قرارات تغطّي ذلك، وحروفها الأولى تكوّن كلمة AGENT.

A — المهمة

اكتب الوصف الوظيفي. هذا يرسم الحدود ويمنع تمدّد النطاق الذي يقتل أكثر مشاريع الوكلاء.

قاوم الرغبة في جعل وكيل واحد يفعل كل شيء. فالتكليف الضيّق هو أقوى مؤشّر منفرد على وكيل يعمل.

G — التوجيه

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

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

E — المحرّك

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

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

N — الاحتياجات

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

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

T — التتبّع

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

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

ما ينجح، وما لا ينجح

أنماط تصمد

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

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

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

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

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

أنماط تفشل

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

لا نتيجة عملية. إن لم يكن مرتبطًا بوقت موفَّر، أو كلفة مخفَّضة، أو تجربة أفضل، فلن ينجو من أول لقاء بميزانية.

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

لا مسؤول. الوكلاء ليسوا أنظمة تُبنى مرة واحدة وتُنسى. البيانات تتغيّر، والأدوات تتغيّر، والواجهات تُهمَل. ولا بدّ من شخص يُسأل عن سلوك الوكيل.

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

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