تصميم وكلاء الذكاء الاصطناعي

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

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

يتناول هذا الفصل أمرين:

1. كيف تحدّد ما إذا كان النهج الوكيلي مناسبًا لمشكلتك.
2. كيف تصمّم نموذجًا أوليًا عاملًا — وهو ما يُعرف بـ«إثبات المفهوم» (POC).

دورة حياة الوكيل: المشكلة والمتطلّبات والجدوى

قبل أن تبدأ ببناء وكيل، هناك قاعدة عملية أوصي بها دائمًا: لا تبدأ من التقنية، بل ابدأ من المشكلة.

الأمر يشبه تعيين مساعد جديد. لن تقول له «اذهب وساعد أحدًا» ثم تدفعه إلى المكتب. بل ستبدأ بأسئلة:

• ما العمل الذي يجب إنجازه؟
• من يحتاج المساعدة؟
• هل هذا عمل يحتاج مساعدًا فعلًا، أم أن قائمة مراجعة بسيطة تكفي؟

وبالطريقة نفسها ينبغي أن تقارب بناء الوكيل.

الخطوة 1: حدّد المشكلة

اسأل نفسك: ما المهمة أو نقطة الألم التي نحاول حلّها تحديدًا؟

لا تقل «نحتاج مساعدًا ذكيًا»؛ فهذا غامض جدًا.

بل قل شيئًا مثل: «فريق دعم العملاء يستهلك وقتًا طويلًا في إعادة تعيين كلمات مرور المستخدمين. نريد أتمتة ذلك.»

هذه مشكلة حقيقية: محدّدة، وقابلة للقياس، ومرتبطة بهدف عملي.

الخطوة 2: وضّح المتطلّبات

ثم اسأل: لمن هذا الوكيل؟ وما الذي تريده أن يفعله بالضبط؟

هل يساعد العملاء؟ هل يعمل مع فريق الموارد البشرية؟ هل يتعامل مع بيانات المبيعات؟

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

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

الخطوة 3: افحص الجدوى بسرعة

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

قائمة المراجعة التالية تساعدك في التحقّق.

قرارك السريع

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

مخطّط AGENT: الدور والنموذج والموجّهات والأدوات والذاكرة

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

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

لنفصّل كل عنصر بأمثلة.

A — المهمة والدور

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

وتجنّب أن تجعل وكيلًا واحدًا يفعل كل شيء. أبقِ المهمة واضحة ومحدّدة.

G — التوجيه والموجّهات

هنا تحدّد كيف يتصرّف الوكيل. وستحتاج إلى:

• موجّه النظام يحدّد شخصية الوكيل وأهدافه وحدوده.
• موجّهات إضافية للاستدلال والتخطيط وتنفيذ المهام.

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

E — المحرّك أو النموذج

هذا هو محرّك الاستدلال في وكيلك. اختر نموذجًا يناسب احتياجك وقيودك.

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

N — الأدوات والبيانات الخارجية

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

أمثلة:

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

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

T — ذاكرة العمل

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

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

أنماط التصميم: ما ينجح وما لا ينجح

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

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

ما ينجح: أنماط التصميم

وكلاء بغرض محدّد

ابدأ بمهمة واحدة واضحة يقوم بها الوكيل — لا أكثر ولا أقل. هذا يوحّد فهم الجميع (المستخدمين والمطوّرين وأصحاب القرار) ويجعل قياس النجاح سهلًا.

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

مدخلات ومخرجات واضحة

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

مثال: وكيل مبيعات يحوّل ملاحظات المكالمات إلى ملخّصات وخطوات متابعة مقترحة.

مراجعة بشرية افتراضية

في الإصدارات الأولى، اجعل المراجعة البشرية جزءًا من سير العمل — خصوصًا في المهام الحسّاسة كالتمويل والقانون ودعم العملاء. وهذا ما نسمّيه وجود الإنسان ضمن مسار القرار (Human-in-the-Loop): أن يمرّ الإجراء المؤثّر على موافقة إنسان قبل تنفيذه. الفائدة مزدوجة: تبني الثقة، وتمنحك شبكة أمان، وتوفّر تغذية راجعة تحسّن الوكيل.

ابدأ ضيّقًا ثم توسّع

قاوم الرغبة في جعل وكيلك «يفعل كل شيء». ابدأ بحالة استخدام مركّزة تقدّم قيمة ظاهرة، وبعد أن تنجح، ابنِ عليها قدرات إضافية.

مثال: ابدأ بوكيل يرتّب مقابلات العمل، ثم أضف متابعة المرشّحين لاحقًا.

اذهب إلى حيث يوجد المستخدم

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

ما لا ينجح: الأنماط المضادّة

وكيل «يفعل كل شيء» دون تركيز

تجنّب بناء وكلاء بأهداف غامضة أو واسعة جدًا مثل «يساعد في كل شيء». هؤلاء يصعب اختبارهم وتدريبهم والاعتماد عليهم، ولا يعرف المستخدم متى يستعملهم ولا كيف.

لا نتيجة عملية واضحة

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

الأتمتة الكاملة للمهام الحرجة مبكرًا جدًا

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

غياب المسؤولية وخطة الصيانة

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

تجاهل اختبار المستخدم

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

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