كلمة "الوكيل" تفقد معناها. تصف أي إعلانات عن منتج الآن أي ميزة ذكاء اصطناعي بأنها وكيل. أداة بسيطة تنشئ مسودات بريد إلكتروني؟ وكيل. بوت دعم يقرأ قاعدة معرفتك؟ وكيل. نص برمجي يستدعي API ويعيد JSON؟ وكيل أيضاً. هذا ليس مجرد تسويق عشوائي، بل هو تصميم خطير. عندما تطلق على كل شيء وصف "وكيل"، فإنك تتوقف عن فهم ما تبنيه حقاً. تبدأ في السعي وراء بنيات معقدة قبل أن تحدد الوظيفة المطلوبة. والنتيجة هي كود برمجي هش، وتكاليف tokens خارجة عن السيطرة، وأنظمة تتصرف بطرق لا يمكنك تفسيرها أو إعادة إنتاجها.
روبوتات الدردشة تنتظر، ولا تفعل
تشغل روبوتات الدردشة المستوى الأبسط. فهي تفاعلية؛ يكتب المستخدم سؤالاً، فيقوم النموذج بإنشاء رد، وتنتهي المحادثة عند هذا الحد ما لم يصل طلب بشري آخر. هذه الأنظمة لا تقرر فحص تقويمك، أو تحديث سجل قاعدة بيانات، أو التوقف لطلب توضيح. فكر في أداة المساعدة المدمجة في صفحة تسعير SaaS. إنها تجيب على الأسئلة المتعلقة بدورات الفوترة وحدود الميزات، لكنها لا تقوم برد الأموال للعميل، أو ترقية خطة، أو الإبلاغ عن حساب مشبوه. ليس لديها أدوات، ولا حالة مستمرة تتجاوز نافذة الدردشة، ولا هدف سوى إنتاج جملة ذات صلة. هذا هو روبوت الدردشة؛ فهو يستجيب، لكنه لا يفعل.
المساعدون يساعدون داخل نافذة
يضيف المساعدون مستوى من الرقي دون إضافة القدرة على التصرف المستقل. فهم يستخدمون مطالبات النظام (system prompts) لتبني شخصية معينة، ويحتفظون بالسياق عبر محادثات أطول. قد يقومون بتلخيص مستند قمت بتحميله أو إعادة كتابة فقرتك بنبرة مختلفة. المساعد في الكتابة الذي يدقق قواعدك النحوية ويقترح صياغة أوضح هو أمر مفيد، وهو يتذكر أنك تفضل الإملاء البريطاني، لكنه لا يتخذ إجراءً نيابة عنك. هو لا يقرر إرسال بريد إلكتروني إلى محرر النصوص الخاص بك، أو تحديد موعد نهائي، أو البحث في الويب دون طلب. إنه يساعد داخل النافذة التي توفرها له؛ هو لا يقود السيارة، بل يقترح مساراً أفضل بينما تبقي أنت يديك على المقود.
سير العمل يتبع الخريطة التي رسمتها
تشغل سير العمل المنطقة الوسطى حيث تنتمي معظم أنظمة الذكاء الاصطناعي الإنتاجية في الواقع. هنا، أنت من يحدد المسار. تقوم ببناء سلسلة من الخطوات: استخراج تاريخ الفاتورة، البحث عن معرف المورد، مقارنة المبلغ بأمر الشراء، تحديث جدول البيانات المحاسبي، وإرسال إشعار إلى القسم المالي إذا لم تتطابق الأرقام. قد يقرأ النموذج الفاتورة أو يصنف وجود تعارض، لكنه يتبع المخطط الذي وضعته. أنت تعرف بالضبط ما سيحدث لأنك رسمت الخريطة.
سير العمل أسهل في الاختبار. يمكنك إجراء اختبار الوحدة (unit-test) لكل خطوة بشكل منعزل، ويمكنك تسجيل المدخلات والمخرجات عند كل عقدة. عندما ينكسر شيء ما، ستعرف أي فرع قد فشل دون الحاجة إلى البحث في سلسلة تفكير غامضة. قابلية المراقبة مباشرة لأن النظام لا يفاجئك بانحراف عن المسار. إذا كانت عملية عملك تحتوي على قواعد واضحة واستثناءات معروفة، فإن سير العمل عادة ما يكون هو الخيار الأفضل. ستحصل على السرعة والموثوقية وتكاليف أقل دون التظاهر بأن الآلة لديها نوايا.
الوكلاء يختارون المسار
الوكلاء مختلفون؛ فهم ديناميكيون. أنت تعطيهم هدفاً، وهم يكتشفون كيفية الوصول إليه. يتلقى الوكيل مهمة، ويحلل ما يجب القيام به، ويختار الأدوات، وينفذ، ويلاحظ النتيجة، ثم يقرر ما سيأتي بعد ذلك. هذه الحلقة — التفكير، الفعل، الملاحظة، ثم التفكير مجدداً — هي ما يميز الوكيل عن أي فئة أخرى.
تخيل نظاماً يتعامل مع طلبات استرداد الأموال. قد يقوم سير العمل بالتحقق من ثلاثة شروط والموافقة أو الرفض بناءً على قواعد ثابتة. أما الوكيل، إذا أُعطي هدف "معالجة عملية استرداد الأموال هذه بإنصاف مع التحقق من الاحتيال"، فقد يستعلم عن سجل مشتريات العميل، ويتحقق من سياسة الإرجاع لفئة ذلك المنتج، ويبحث في نشاط الحساب الأخير، وينشئ تذكرة دعم للمراجعة اليدوية إذا بدا النمط غير معتاد، ثم يصيغ بريداً إلكترونياً يشرح فيه قراره. لقد اختار الأدوات التي سيستخدمها وبالترتيب الذي يراه مناسباً بناءً على تفاصيل الحالة.
الوكيل هو نظام، وليس مجرد نموذج
الوكيل ليس مجرد نموذج يعمل في نافذة دردشة، بل هو نظام كامل. إنه يجمع بين:
- نماذج للتفكير وتوليد اللغة
- تعليمات تقيد مساحة عمله
- أدوات ذات مخططات (schemas) صارمة للتفاعل مع العالم الخارجي
- سياق حول المهمة الحالية والبيئة
- حالة ليتذكر أين وصل في عملية متعددة الخطوات
- عمليات تحقق لفحص المدخلات قبل دخولها إلى الأداة والمخرجات قبل وصولها إلى المستخدم
- قيود على الميزانية أو الخطوات أو النطاق لمنع السلوك الجامح
- قابلية المراقبة لتتمكن من إعادة بناء سبب اختيار المسار (أ) بدلاً من المسار (ب)
إذا كان نظامك يفتقر إلى معظم هذه العناصر، فأنت لا تملك عميلًا (agent). بل تملك نموذجًا مع استدعاءات إضافية لواجهة برمجة التطبيقات (API).
الاستقلالية بدون تحكم هي مجرد مخاطرة
إذا كان العميل الخاص بك يمكنه الاستعلام من قاعدة بيانات الإنتاج الخاصة بك، أو إنشاء سجلات في نظام إدارة علاقات العملاء (CRM)، أو إرسال رسائل للمستخدمين، فبإمكانه أيضًا إفساد البيانات، أو تكرار المدخلات، أو إغراق العملاء بالرسائل المزعجة. تعتمد بنية العميل الجيدة على افتراض حدوث الفشل؛ فهو يطلب الإذن قبل القيام بأي إجراءات تدميرية، ويجري عمليات التحقق قبل اعتماد النتائج، ويكشف عن منطقه (reasoning) حتى يتمكن البشر من التدخل عندما ترتفع التكاليف أو المخاطر.
إذا تجاهلت هذه القيود لأن العرض التجريبي بدا مثيرًا، فستقضي عطلات نهاية الأسبوع في تصحيح الأخطاء (debugging) لمعرفة سبب إنشاء العميل لأربعمائة تذكرة دعم خلال الليل أو استرداد مبلغ طلب لا ينبغي له المساس به. إن عدم القدرة على التنبؤ التي كنت تخشاها في الأنظمة "الصندوق الأسود" (black-box) تصبح حقيقة في اللحظة التي تمنح فيها الذكاء الاصطناعي هدفًا ومجموعة غير خاضعة للإشراف من الأدوات.
ابدأ بالمشكلة، وليس بالتكنولوجيا
لا تبدأ بالعميل. ابدأ بالألم (المشكلة). أحيانًا يكون الحل هو "أمر" (prompt) أفضل. وأحيانًا يكون دالة حتمية (deterministic function) في نظامك الخلفي (backend) الحالي. وأحيانًا يكون سير عمل (workflow) يتضمن خطوة ذكاء اصطناعي واحدة وخمس استدعاءات تقليدية لواجهة برمجة التطبيقات (API).
لا تلجأ إلى العملاء إلا عندما تتطلب المهمة حقًا:
- خطوات متعددة تعتمد على بعضها البعض
- اتخاذ قرارات ديناميكية بين تلك الخطوات
- التفاعل مع أدوات خارجية
- التفكير في النتائج الوسيطة التي لا يمكنك رسم مسارها بالكامل مسبقًا
إذا كان المسار معروفًا، فقم ببناء سير عمل (workflow). وإذا كان التفاعل بسيطًا، فقم ببناء روبوت دردشة (chatbot) أو مساعد. لا تضف "القدرة على التصرف" (agency) لمجرد أن المصطلح يبدو عصريًا.
ابنِ النضج، لا التعقيد
عندما يكون العميل هو الخيار المناسب حقًا، فقم ببنائه على طبقات. ابدأ بأداة واحدة وقرار مبرمج مسبقًا (hardcoded). أضف اختبارات تتحقق من استدعاء الأداة بالوسائط (arguments) الصحيحة. أضف سجلات (logging) لتتمكن من رؤية التتبع الكامل. أضف إدارة الحالة (state management) ليعرف النظام أين توقف. أضف عمليات التحقق عند كل حد فاصل. أضف لوحات تحكم للمراقبة (observability dashboards) حتى يتمكن فريقك من مراقبة السلوك في الوقت الفعلي. وأخيرًا، أضف الاستقلالية بعناية — أي الحرية في الاختيار بين الخيارات. لا تفعل ذلك بالعكس؛ فالاستقلالية المبنية فوق الفوضى تنتج حوادث مكلفة.
الخلاصة الحقيقية
الكلمات تشكل الأنظمة. احتفظ بمصطلح "عميل" (agent) للبنيات التي تستحقه: الموجهة نحو الأهداف، والمستخدمة للأدوات، والمتكيفة ديناميكيًا، ولكنها محاطة بحدود صارمة وإشراف بشري. أي شيء آخر هو مجرد روبوت دردشة، أو مساعد، أو سير عمل. ابنِ أبسط شيء يحل المشكلة. ستشكرك سجلات الإنتاج الخاصة بك، وفريقك المالي، ونفسك في المستقبل.
المصدر: https://dev.to/leandrolayerle/no-todo-chatbot-es-un-agente-de-ia-3oec
انضم إلى مجتمع GyaanSetu التعليمي: https://t.me/GyaanSetuAi