الفرق الحقيقي بين روبوت المحادثة والوكيل

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

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

ماذا يفعل روبوت المحادثة فعلًا

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

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

ماذا يفعل الوكيل فعلًا

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

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

الطلب نفسه، يُنفَّذ بطريقتين

هكذا يبدو هذا الفرق حين يُسلَّم نظامان تعليمات تبدو متشابهة.

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

لماذا هذا ليس مجرد جدال دلالي

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

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

لا تثق إلا بما تستطيع رؤيته

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

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

السوق يسعّر هذا بالمقلوب، باستمرار

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

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