تلجأ معظم فرق الذكاء الاصطناعي الساعية إلى تحسين أداء الوكيل إلى الأدوات نفسها: نطاقات سياق أكبر، ووثائق أكثر، ومطالبات أذكى. لكن هذا المقال يرى أن هذا التوجه خاطئ تمامًا. العنصر المفقود ليس مزيدًا من المعلومات. بل التحكم. طبقة التحكم المصممة جيدًا هي ما يفصل بين وكيل ينجح في العرض التجريبي وآخر ينجح في بيئة الإنتاج.
إن منح وكيل ذكاء اصطناعي ذاكرة أكبر أو وثائق أكثر أو نطاق سياق أطول لا يجعله أذكى، بل أبطأ وأعلى تكلفة. تأتي المكاسب الحقيقية من تعليم الوكيل أن يختار ما يحتاج إليه وقتما يحتاج إليه، بدلًا من استهلاك كل شيء دفعة واحدة.
الموثوقية مصدرها الحلقة، لا النموذج. الفارق بين وكيل يثير الإعجاب في عرض تجريبي وآخر يصمد في بيئة الإنتاج ليس جودة الذكاء الاصطناعي، بل ما إذا كان النظام يراجع عمله بنفسه. الوكلاء الذين يخططون وينفذون ويراقبون ويتحققون في كل خطوة يكتشفون أخطاءهم بأنفسهم، بدلًا من ارتكابها بثقة.
معظم وكلاء الذكاء الاصطناعي اليوم ليسوا في جوهرهم سوى روبوتات محادثة بخطوات إضافية؛ إذ يفتقرون إلى آلية لمعرفة ما إذا كانوا على المسار الصحيح، أو متى يتوقفون، أو متى يجربون نهجًا مختلفًا. إضافة طبقة تحكم سليمة، تشمل معايير نجاح واضحة وحالة منظمة وفحوص تحقق، هي ما يحوّل كيانًا يتخذ شكل الوكيل إلى شيء يمكنك الوثوق به فعلًا.
What did you have for lunch yesterday?
ربما لم تستعرض كل ذكرى مررت بها حتى تصل إلى «الأمس + الغداء»، بل انتقلت مباشرةً إلى الجزء من تجربتك الذي يضم هذين المفهومين. وهذا نموذج ذهني مفيد لبناء الوكلاء:
نطاق السياق الهائل ليس ذاكرة.
كومة الوثائق المسترجعة ليست فهمًا.
سلسلة الاستدلال الطويلة ليست موثوقية.
تلك مجرد مكوّنات. لكن ما يجعل الوكيل يبدو وكيلًا هو نفسه ما يمنع دماغك من البحث الشامل في تاريخ حياتك كله: التحكم.
نجحت دراسة حديثة بعنوان الاستدلال القائم على الوكلاء لنماذج اللغة الكبيرة في تلخيص (وتسمية) التحول الذي شعر به كثير منا أثناء البناء: من الاستدلال داخل النموذج إلى الاستدلال عبر التفاعل. هذه التدوينة ليست ملخصًا لتلك الورقة. بل محاولة لترجمة هذا التحول إلى تصميم عملي للأنظمة:
إذا بنيت الوكلاء كروبوتات محادثة مزودة بأدوات، فستظل تواجه أنماط فشل روبوتات المحادثة نفسها، لكن بأخطاء أعلى تكلفة.
لفترة من الزمن، كانت خطتنا الافتراضية «لجعل النموذج أذكى» تتمثل أساسًا في مطالبات أفضل، وسلسلة الاستدلال، والاتساق الذاتي أو التحسينات القائمة على أخذ العينات، وربما بعض البحث.
كان ReAct نقطة تحول لأنه جعل تسلسل «فكرة ← إجراء ← ملاحظة» يبدو طبيعيًا. لكن لاحظ القيد الضمني: لا يزال الكثير من ذلك ينتهي إلى «استدلال بمثال واحد، لكن برموز أكثر». أما صياغة الدراسة فأدق: يركز الاستدلال القائم على الوكلاء على توسيع نطاق التفاعل وقت الاختبار، أي تحويل الاستدلال إلى عملية تكرارية يظل فيها النموذج والذاكرة والبيئة جميعًا ضمن الحلقة.
إذا سبق أن بنيت (أو استخدمت) وكلاء يبدون مبهرين في العروض التجريبية لكنهم هشّون في سير العمل الفعلي، فهذا المقال لك.
دعني أصف نمطًا رأيته كثيرًا (وقد بنيت بنفسي نسخًا منه بالتأكيد):
خذ نموذج محادثة جيدًا
أضف بضع أدوات (البحث، والاستعلام من قاعدة بيانات، وربما تنفيذ التعليمات البرمجية)
أضف RAG
أضف مطالبة نظام تقول: «أنت وكيل مستقل»
ضع كل ذلك داخل حلقة while حتى يتوقف أو تنتهي المهلة
تهانينا، أصبح لديك كيان يتخذ شكل الوكيل. لكنه يميل إلى الفشل بطرق يمكن توقعها:
تضخم السياق: تُلحَق كل ملاحظة به، فتتحول المطالبات إلى طبقات أثرية.
التخبط بين الأدوات: يصبح «استخدام الأداة الخطأ بثقة» نمط الفشل الافتراضي.
غياب شروط التوقف: يواصل العمل لأنه يستطيع، لا لأنه ينبغي له ذلك.
غياب منهجية الربط بمصادر موثوقة: لا يدرك أنه مخطئ ما لم تجبره على ذلك.
الذاكرة = سجل المحادثة: أي كتابة سجلات تشغيل وتسميتها تعلّمًا.
لهذا تبدو «الوكلاء» ساحرة في العروض التجريبية وفوضوية في بيئة الإنتاج. وتؤكد تجربتنا في تشغيل الأنظمة القائمة على الوكلاء في بيئة الإنتاج ذلك أيضًا: فبمجرد أن تنتقل من تقييم نموذج إلى تقييم نظام، تشمل أنماط الفشل التنقل، وحسن استخدام الأدوات، وتنقيح السياق، وتصميم التقييم، لا مجرد سؤال: «هل أجاب النموذج إجابة صحيحة؟»
وهكذا يصبح السؤال: ما الوكيل المقصود؟
لجعل الأمر أقل تجريدًا، إليك سير عمل مبسطًا يمكن لمعظم الناس تصوره: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
يبدو أحد التطبيقات الشائعة التي تتخذ شكل الوكيل هكذا:
يسترجع فورًا مجموعة من وثائق سياسات شركات الطيران والسفر (حتى إن لم تكن أي منها مطلوبة بعد).
يستدعي أداة بحث، ويلصق قائمة طويلة من النتائج في المطالبة، ثم «يختار واحدة».
يحجز قبل الأوان من دون التحقق من القيود (وقت الوصول، والأمتعة، والمقعد، والسياسة).
وإذا فشل، يعيد المحاولة بطريقة مختلفة قليلًا، لكن من دون تصور واضح لما تغيّر أو لما تعلّمه.
لا يكمن نمط الفشل في عجز النموذج عن الاستدلال، بل في أن النظام لا يتحكم في سير العمل.
تتعامل النسخة الأكثر اعتمادًا على الوكيل مع المهمة بوصفها عملية تفاعلية ذات حالة صريحة وفحوص واضحة:
التخطيط: إعادة صياغة القيود وتحديد المعلومات الناقصة (مثل: “which airport preference?” / “is 1 stop ok?”).
التنفيذ: استدعاء البحث عن الرحلات باستعلام منظم (نطاق التاريخ، وقيد الوصول، والميزانية).
المراقبة: تخزين النتائج في كائن حالة موجز (أفضل خمسة خيارات مع السعر وموعد الوصول والتوقفات)، بدلًا من كتلة نصية ضخمة منسوخة.
التحديث: تحسين الاستعلام إن لم تُستوفَ القيود (مثل: “arrival before 6pm is too strict—widen time window or raise budget?”).
التحقق: تشغيل أدوات التحقق (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
التوقف: لا يحدث إلا بعد أن تعيد واجهة API للحجز تأكيدًا وتجتاز النتيجة جميع عمليات التحقق.
التغيير دقيق، لكنه حاسم. فالاسترجاع مشروط (لا انعكاسي)، والسياق يُدار (الحالة منظمة لا متراكمة)، والتحقق جزء من الحلقة (ولا يُترك للمستخدم). استبدل «حجز رحلة جوية» بـ«إنشاء أمر شراء» أو «إصدار مبلغ مسترد» أو «تغيير إعدادات بيئة الإنتاج» أو «إطلاق طلب دمج»، وستبقى القصة نفسها: ما إن يستطيع الوكيل التنفيذ، تصبح الحلقة أهم من المطالبة.
تنظّم الدراسة المذكورة أعلاه الاستدلال القائم على الوكلاء في ثلاث طبقات: تأسيسية (التخطيط واستخدام الأدوات والبحث)، ومتطورة ذاتيًا (الملاحظات والذاكرة)، وجماعية (التنسيق بين عدة وكلاء).
لكن الفكرة الأعمق هي أن الاستدلال يصبح المبدأ المنظّم للتخطيط واتخاذ القرار والتحقق، لا مجرد توليد سلسلة استدلال تبدو معقولة. يبدو ذلك مجردًا إلى أن تربطه بالتغييرات التي تطرأ على بنيتك التقنية. هناك ثلاث نقاط أساسية ينبغي تذكّرها:
ينبغي ألا يتعامل الوكيل الجيد مع الاسترجاع بمنطق «افعله دائمًا». فالاسترجاع قرار، لا رد فعل تلقائي.
إليك قاعدة عملية إرشادية:
إذا كان نظامك يسترجع المعلومات في كل جولة، فأنت لم تبنِ استرجاعًا، بل فرضت ضريبة على السياق.
ويظهر ذلك طوال الوقت في العمل الفعلي. عند تصحيح حادثة في بيئة الإنتاج، لا تُفرغ كل السجلات في السياق؛ بل تحدد المقاييس والسجلات التالية التي ستجلبها بناءً على فرضيتك الحالية. هذا هو «الاسترجاع القائم على الوكيل». وإليك نمطًا أكثر تحديدًا:
حدّد هل تحتاج إلى الاسترجاع
إن احتجت إليه: صُغ استعلامًا، واجلب النتائج، وتصفّحها، واستخلص المطلوب
إذا تعارضت الأدلة: اجلب المزيد
وبعد ذلك فقط، ركّب النتيجة
وهنا أيضًا يبدأ «التوليد المعزز بالاسترجاع القائم على الوكيل» في الاختلاف عن RAG التقليدي: إذ يصبح الاسترجاع خطوة استدلال مقصودة، لا مرحلة افتراضية ضمن مسار المعالجة.
بمجرد أن تتوقف عن تقييم «نموذج» وتبدأ تقييم «نظام»، يصبح تتبّع الحالة ومسار التنفيذ مهمًّا.
أصبح القطاع الآن أكثر وضوحًا بشأن قابلية مراقبة سير عمل الوكيل. على سبيل المثال، تتضمن حزمة Agents SDK من OpenAI ميزة مدمجة لتتبّع مسار التنفيذ ولوحة معلومات Traces تسجّل عمليات تشغيل الوكيل (عمليات التوليد، واستدعاءات الأدوات، وعمليات التسليم، وضوابط الحماية، والأحداث المخصصة)، كي تتمكن تحديدًا من تصحيح ما حدث ومراجعته خطوة بخطوة.
هذه ليست «ميزة إضافية محبّذة»، بل هي الفارق بين نظام يمكنك تصحيح أخطائه ونظام لا يمكنك سوى الحكم عليه بالانطباع.
أكثر أجزاء الدراسة الاستقصائية قابليةً للتطبيق، في رأيي، هو صراحتها بشأن الملاحظات التصحيحية. وتقسّمها إلى ثلاثة أنماط: الملاحظات التأملية (ولّد ← انتقد ← راجع)، والتكيّف البارامتري (التعلّم عبر الضبط الدقيق أو التعلّم المعزز)، والملاحظات القائمة على أدوات التحقق (أعد المحاولة حتى يجتاز التحقق).
ينبغي لمعظم الفرق أن تبدأ بالملاحظات القائمة على أدوات التحقق، لأنها تقليدية وفعّالة. إذا استطعت كتابة أي أداة تحقق تُجري اختبارات وحدات، أو تتحقق من المخطط، أو تفرض قواعد وقيود العمل («لا مبالغ مستردة تتجاوز X دون تصعيد»)، أو تثبت صحة المعلومات («المراجع مطلوبة»)، فيمكنك تحويل مخرجات النموذج غير الحتمية إلى شيء يمكنك الوثوق به فعلًا.
أحد التحولات البسيطة ضمن «المجهول الذي نجهل وجوده» هو أن الموثوقية في عالم الوكلاء تأتي غالبًا من الحلقة أكثر من النموذج.
هذا أبسط نظام للحلقات وجدته قادرًا على تحسين السلوك بموثوقية من دون تدريب:
اعمل على مراحل: خطّط ← نفّذ ← راقب ← حدّث،
بعد كل تنفيذ، لخّص الملاحظة في نقطة إلى ثلاث نقاط،
توقّف عند استيفاء معايير النجاح أو بلوغ حد الميزانية؛ وأعِد أفضل نتيجة معروفة مع أوجه عدم اليقين المتبقية.
لا يتعلق الأمر بجعل النموذج مسهبًا. بل بجعل النظام واضحًا ومفهومًا، وإجباره على «الاحتكام إلى الواقع» في كل خطوة. ومن الأمثلة المألوفة جدًا للمهندسين الربط بمصادر موثوقة ضمن حلقة مغلقة على غرار التكامل المستمر (CI):
خطّط: اقترح قائمة بالتغييرات
نفّذ: شغّل الاختبارات وأداة التدقيق البرمجي
راقب: حلّل حالات الفشل
حدّث: طبّق التصحيح وأعد المحاولة
إليك بعض الأسئلة التي تكشف عادةً تصاميم الوكلاء غير المقصودة:
«هل يختار وكيلي ما يسترجعه، أم أنني أسترجع دائمًا؟»
إذا كان الاسترجاع غير مشروط، فستدفع الثمن في صورة زمن استجابة أطول، وتكلفة أعلى، وتشتيت للسياق، وزيادة خطر أن تؤدي المدخلات الرديئة إلى مخرجات رديئة.
«هل يستطيع وكيلي إدراك أنه مخطئ؟»
إذا كانت إشارة الملاحظات الوحيدة لدى وكيلك هي «انزعاج المستخدم»، فأنت تطبّق التعلّم المعزز عبر معاناة البشر. حلقة إعادة المحاولة القائمة على أداة تحقق هي أنظف وسيلة لإجباره على الاحتكام إلى الواقع.
«هل يمكن الكتابة في الذاكرة، وهل تتحسن بمرور الوقت؟»
إذا كانت «ذاكرتك» لا تفعل سوى إلحاق سجل المحادثة، فأنت لا تكتب سوى سجلات تشغيل. إن تصور الدراسة للذاكرة مهم: فالذاكرة تصبح سياقًا متناميًا وديناميكيًا تصقله الوكلاء بمرور الوقت، لا مجرد نص للمحادثة.
تخبرك السجلات بما حدث، بينما تخبرك الذاكرة بما ينبغي فعله في المرة المقبلة. سجل المحادثة نصٌّ لما دار فيها. أما الذاكرة فهي سياسة متطورة تحدد ما يستحق الاحتفاظ به للمستقبل.
يمكن البدء عمليًا بجدول صغير «للدروس المستفادة»، يستخدم نوع المهمة والأداة ونمط الفشل مفتاحًا، ويسجّل ما نجح وما ينبغي تجنبه قيمةً. ليس الهدف بناء رسم بياني معرفي مثالي. بل إنشاء سلوك يتراكم أثره: فالذاكرة والملاحظات تحوّلان الوكلاء من «مساعدين بلا حالة» إلى أنظمة تتحسن بمرور الوقت.
قد يغريك إقحام مزيد من الوكلاء لحل المشكلة، لكن ذلك غالبًا ما يضاعف أعباء التنسيق. نمط جيد «لفريق بالحد الأدنى القابل للتطبيق»:
المنسّق: يقسّم المهام ويوزعها
المنفّذ: يستدعي الأدوات ويُجري التغييرات
الناقد/المقيّم: يتحقق من الصحة والمخاطر
أمين الذاكرة: يدوّن الدروس وينقحها
إذا لم تستطع توضيح مسؤولية كل وكيل، فربما لا تحتاج إلى عدة وكلاء بعد.
إذا اقتنعنا فعلًا بهذا التحول في النموذج الفكري، فالأرجح أن نتوقف عن حشر كل شيء في المطالبات، والتعامل مع حالات الفشل كمخرجات نهائية، وتقييم الوكلاء كما لو كانوا روبوتات محادثة. ونبدأ في التعامل مع الوكلاء وفق حقيقتهم: أنظمة برمجية تشكّل فيها اللغة مستوى التحكم، وتأتي موثوقيتها من الحلقة.
قبل إضافة نموذج آخر، أضف حلقة تقييم أخرى. قبل استرجاع كل شيء، اجعل الاسترجاع مشروطًا. أطلق أداة تحقق واحدة قبل أن تطلق عشرًا. تعامل مع الذاكرة كقرارات سياسة، لا كقاعدة بيانات. وعند الانتقال إلى تعدد الوكلاء، ابدأ بوكيلين لا بعشرين. هذه ليست قواعد، بل أنماط أثبتت جدواها في بيئة الإنتاج.