هناك خطأ يتكرر كثيرًا عندما يبدأ الناس في بناء وكيل ذكي:
يرون أن النموذج ممتاز في الشرح، ثم يربطونه بأداة أو اثنتين، وبعد أول تجربة ناجحة يشعرون أن كل شيء صار جاهزًا. وهنا تبدأ المشكلة الحقيقية، لا نهايتها.
لأن الوكيل القوي من دون ضبط، يشبه تمامًا ساحرًا يعرف تعاويذ كثيرة، ويحمل عصا سحرية حقيقية، لكنه لا يملك صياغة دقيقة لما هو مطلوب منه، ولا حدودًا واضحة لما يجب ألا يفعله، ولا ذاكرة تمنعه من التناقض، ولا طريقة تثبت لك أن ما فعله كان صحيحًا أصلًا. في هذه الحالة، المشكلة لا تكون أنه ضعيف. المشكلة أنه قد يكون مفيدًا بما يكفي كي تثق به… وخطرًا بما يكفي كي يفاجئك.
وهذا فرق مهم جدًا عن المساعد اللغوي العادي.
المساعد الضعيف يزعجك بإجابات سطحية أو اقتراحات غير كافية.
أما الوكيل غير المضبوط فقد يذهب أبعد من ذلك:
قد يقرأ بشكل ناقص،
وينفذ باندفاع،
ويفترض من عنده،
ثم يرجع لك بنتيجة تبدو مرتبة وواثقة، بينما الخطأ الحقيقي صار داخل الفعل نفسه، لا داخل الكلام فقط.
لهذا السبب، بناء الوكيل لا يبدأ من السؤال:
“ما أقوى نموذج؟”
بل من سؤال أكثر نضجًا بكثير:
ما الذي يجب أن يكون واضحًا، ومقيدًا، ومراقبًا، قبل أن أسمح لهذا النظام أن يعمل؟
في المقال السابق، رأينا كيف ينتقل LLM من مجرد عقل لغوي إلى شيء أقرب إلى وكيل عبر الأدوات والذاكرة والتنفيذ. لكن ذلك كان شرحًا للانتقال نفسه. أما هنا، فنحن ندخل إلى مرحلة أكثر حساسية: كيف نضبط هذا الانتقال؟ كيف نبني وكيلًا لا يبدو فقط ذكيًا في العرض، بل يكون قابلًا للاستخدام الحقيقي بثقة معقولة؟
سنتعرف على بناء وكيل ذكي: من الهدف إلى التنفيذ | وكيف تضبط AI Agent بشكل صحيح؟
حيث سنعود هنا إلى استعارتنا مرة أخرى، لكن بشكل أدق.
إذا كان LLM هو الساحر،
وكانت الأدوات هي العصا،
فما الذي يمنع هذا الساحر من أن يحوّل السحر إلى فوضى؟
الجواب ليس شيئًا واحدًا، بل أربع دعائم أساسية:
- الهدف: ماذا تريد منه بالضبط؟
- الفعل: ما الأدوات المسموحة له؟ وبأي ترتيب؟
- الذاكرة: كيف لا يبدأ من الصفر كل مرة؟
- الإثبات: كيف تتحقق مما فعله، وتراجع أثره، وتثق أنه لم يتصرف بثقة زائدة؟
هذا هو قلب المقال كله.
ليس لأن هذه الكلمات تبدو مرتبة على الورق، بل لأن أي وكيل ينهار عمليًا إذا اختل فيه واحد منها:
هدف غامض،
أداة مفتوحة أكثر من اللازم،
ذاكرة مرتجلة،
أو تنفيذ بلا تحقق.
ومن هنا نبدأ بأخطر تعويذة في الكتاب كله: الهدف.
لأن كثيرًا من الكوارث لا تبدأ من أداة سيئة، بل من طلب غامض ظن صاحبه أنه “واضح بما يكفي”.
تعويذة الهدف: كيف تمنع الغموض قبل أن يتحول إلى خطأ؟
أكبر خطأ يقع فيه الناس عند التعامل مع الوكلاء أنهم يظنون أن الغموض البشري العادي مقبول كما هو. في المحادثات اليومية بين البشر، كثير من الأشياء تُفهم من السياق أو من الخبرة المشتركة أو من النبرة. تقول لشخص يعمل معك منذ زمن: “رتّب لي هذا الموضوع”، فيفهم تقريبًا ما الذي تقصده لأن بينكما تاريخًا مشتركًا وعالمًا ضمنيًا كاملًا. لكن الوكيل لا يعيش داخل هذا العالم كما نعيش نحن. وإذا كان يملك قدرة تنفيذية، فإن الغموض لا يعود مجرد ضعف لغوي محتمل، بل يتحول إلى خطر تشغيلي.
خذ مثالًا بسيطًا جدًا:
عامر يقول لوكيله:
“اشتغل على طلبات اليوم.”
بالنسبة لعامر، الجملة قد تبدو مفهومة. لكن إذا توقفنا عندها قليلًا، سنكتشف أنها مليئة بالفراغات:
- ما المقصود بـ “اشتغل”؟
- هل المطلوب مراجعة الطلبات فقط أم تحديثها؟
- هل المطلوب تجهيز الشحن أم الرد على الرسائل أم التحقق من الدفع؟
- ما الذي يُسمح بتعديله وما الذي لا يُسمح؟
- وما الذي يجب التوقف عنده بدل تنفيذه مباشرة؟
هنا يظهر الدور الأول للهدف:
ليس أن يكون “عنوانًا عامًا” للمهمة، بل أن يكون تعريفًا تشغيليًا واضحًا لها.
وأفضل طريقة لفهم هذا هي أن الهدف الجيد ليس جملة واحدة فقط، بل ثلاثة أعمدة رئيسية على الأقل:
1) النتيجة المطلوبة فعلًا: ماذا تريد أن يخرج في النهاية؟
هذا هو Objective الحقيقي.
ليس “اشتغل”، بل:
ما الذي يجب أن يوجد عند نهاية المهمة؟
هل تريد قائمة جاهزة للشحن؟
تقريرًا بالمشكلات؟
مسودات ردود؟
ترتيبًا للمنتجات؟
أو تحديثًا فعليًا لحقول معينة؟
إذا لم تكن النتيجة النهائية محددة، فسيبدأ الوكيل في ملء الفراغ بافتراضات من عنده. وربما تكون هذه الافتراضات منطقية من داخله، لكنها لا تطابق ما تريده أنت.
لو قال عامر مثلًا:
“جهّز لي قائمة شحنات اليوم، مرتبة، وجاهزة للطباعة، وتشمل الطلبات المدفوعة فقط.”
فهنا صرنا أمام نتيجة أوضح بكثير. لم يعد الهدف “افعل شيئًا مفيدًا”، بل صار “أنتج هذا المخرج المحدد”.
وهنا نلاحظ فرقًا مهمًا:
المشكلة ليست في البلاغة، بل في قابلية التنفيذ.
كلما كان الهدف أقرب إلى نتيجة قابلة للفحص، كان الوكيل أقل ميلًا إلى التخمين.
2) الحدود والسياسات: ما المسموح وما الممنوع؟
كثير من الناس يظنون أن الوكيل إذا كان “ذكيًا” فسيعرف وحده ما ينبغي وما لا ينبغي. وهذا غير صحيح.
الوكيل لا يعرف سياسة متجرك إلا إذا أعطيتها له.
ولا يعرف ما تعتبره أنت “حالة حساسة” إلا إذا حددت ذلك بوضوح.
لهذا، لا يكفي أن تحدد النتيجة. يجب أن تحدد أيضًا القيود.
مثلًا:
- لا تعدّل عنوان الشحن دون موافقتي
- لا تتعامل مع طلب غير مدفوع على أنه جاهز للشحن
- لا تقترح تعويضًا من دون مراجعة
- لا ترسل شيئًا نهائيًا، فقط جهّز مسودة
هذه الشروط ليست ملحقًا صغيرًا بجانب الهدف.
هي جزء من الهدف نفسه.
لأن التنفيذ من دون سياسة، ليس ذكاءً تشغيليًا، بل مخاطرة مغلّفة بالثقة.
وبالنسبة لعامر، هذا فارق حاسم.
إذا قال فقط: “حل مشكلات العملاء”، فقد يفسر الوكيل “الحل” على أنه إرضاء العميل بأي ثمن.
لكن إذا قال:
“حل مشكلات العملاء ضمن سياسة الإرجاع المعتمدة، ولا تعتمد أي تعويض أو تغيير عنوان إلا بعد مراجعتي”،
فهو هنا لم يكتفِ بطلب النتيجة، بل حدد الإطار الذي يجب ألا يُكسر.
3) السياق: ماذا يجب أن يعرف قبل أن يبدأ؟
حتى لو كان الهدف واضحًا، وحتى لو كانت القيود موجودة، قد يظل الوكيل عاجزًا عن الأداء الجيد إذا لم يعرف أين الحقيقة.
ما الملف المرجعي؟
ما الجدول الذي نعمل عليه؟
ما هي السياسة المعتمدة؟
ما المثال الصحيح؟
ما هي البيانات الحالية؟
هنا يأتي Context بوصفه المادة التي تمنع الوكيل من التخمين.
لا يكفي أن تقول: “طبّق سياسة الإرجاع.”
بل يجب أن يعرف:
- أين السياسة؟
- ما النسخة المعتمدة؟
- هل توجد استثناءات؟
- ما مصدر الحقيقة النهائي؟
وبالنسبة لعامر، السياق قد يكون مثلًا:
- الطلبات موجودة في Google Sheet
- حالات الدفع في النظام الفلاني
- سياسة الإرجاع في هذا المستند
- لا نعتبر الطلب جاهزًا للشحن إلا إذا كانت الحالة “confirmed”
- وهذا مثال على شكل المخرج المطلوب
لاحظ ماذا يحدث هنا.
الساحر لم يعد يعمل في الهواء.
صار عنده خريطة.
يعرف:
- ما الذي يجب أن يصل إليه
- ما الذي يمنعه من الانحراف
- وأين يعود حين يحتاج إلى حقيقة مؤكدة
ومتى يجب أن يسأل بدل أن يخمّن؟
هذه النقطة غالبًا ما تُهمل، مع أنها واحدة من أكثر علامات النضج في تصميم الوكيل.
الهدف الجيد لا يكتفي بوضع المهمة، بل يحدد أيضًا متى يجب على الوكيل أن يتوقف ويسأل.
لأن غياب المعلومة ليس دائمًا دعوة للتخمين.
أحيانًا يكون الغموض بحد ذاته إشارة توقف.
مثلًا، إذا قال عامر:
“جهّز لي شحنات اليوم”
لكن لم يحدد هل يريد الترتيب حسب وقت الطلب أو حسب حالة الدفع أو حسب أولوية العميل،
فهنا الأفضل أن يسأل الوكيل سؤالًا توضيحيًا قصيرًا بدل أن “يفترض” من عنده.
وهذا يميز الوكيل المضبوط عن الوكيل المتهور:
الأول يرى الفراغ ويقول: “أحتاج معلومة قبل أن أكمل.”
الثاني يرى الفراغ ويملؤه بثقة.
وفي الحقيقة، كثير من الأخطاء المكلفة لا تأتي من أن النموذج “لم يفهم اللغة”، بل من أنه فهمها بدرجة كافية ليتحرك، لكن بدرجة غير كافية ليتحرك بأمان.
خلاصة تعويذة الهدف
إذا أردنا ضغط هذه الدعامة كلها في صورة واحدة، فهي كالتالي:
الهدف الجيد ليس:
- جملة عامة
- ولا عنوانًا أنيقًا
- ولا أمنية فضفاضة
الهدف الجيد هو شيء يحدد:
- النتيجة
- الحدود
- السياق
- ومتى يجب السؤال بدل التخمين
وهذا بالضبط ما يمنع الوكيل من أن يتحول من “مساعد يبدو ذكيًا” إلى “منفذ يتصرف من تلقاء نفسه بطريقة لا تشبه ما كنت تقصده أصلًا”.
لكن حتى مع هدف ممتاز، هناك مشكلة أخرى لا تقل خطورة:
يمكنك أن تكتب تعويذة دقيقة جدًا، ثم تعطي الساحر عصا مفتوحة على كل شيء.
وهنا تبدأ فوضى من نوع آخر.
لذلك، بعد الهدف مباشرة، نحتاج إلى الدعامة الثانية: الفعل.
أي: كيف تعطي الوكيل أدوات وتنفيذًا… من دون أن تعطيه الفوضى؟
تعويذة الفعل: كيف تعطيه أدوات من دون أن تعطيه الفوضى؟
بعد أن يصبح الهدف واضحًا، يظن بعض الناس أن أصعب جزء انتهى. الحقيقة أن الخطر التالي يبدأ هنا بالضبط: التنفيذ. لأن الوكيل قد يفهم المطلوب جيدًا، لكن ما إن تعطيه أدوات غير مضبوطة أو ترتيبًا رخوًا أو صلاحيات أوسع مما ينبغي، حتى تتحول الفكرة من “نظام ذكي يساعدني” إلى “نظام يتحرك بثقة في مساحة أكبر من فهمه”.
لهذا السبب، تعويذة الفعل لا تعني فقط “أعطه أدوات”.
بل تعني:
- ما الأدوات التي يحق له استخدامها أصلًا؟
- بأي ترتيب؟
- وما الذي يجب أن يحدث إذا ظهرت حالة ناقصة أو متضاربة أو حساسة؟
هذه ليست تفاصيل تشغيلية ثانوية.
هي جزء من صلب تصميم الوكيل.
لأن الأداة في عالم الوكلاء ليست مجرد منفذ محايد، بل قناة تأثير. وكل قناة تأثير تفتحها للنظام يجب أن تكون مرتبطة بحدود ومسار وشروط توقف.
أولًا: ما الذي يستطيع لمسه أصلًا؟
هنا نصل إلى أول مبدأ ذهبي في بناء الوكيل:
الوكيل لا ينبغي أن يلمس كل ما يستطيع تقنيًا لمسه، بل فقط ما يحتاجه وظيفيًا.
هذا فرق شديد الأهمية.
تقنيًا، قد يكون من السهل أن توصله بملفات كثيرة، أو بقاعدة بيانات كاملة، أو بواجهة إرسال وتحديث وحذف. لكن التصميم الجيد لا يبدأ من السؤال: “ما الذي يمكن وصله؟” بل من سؤال: “ما الذي يجب أن يُسمح له باستخدامه؟”
ولهذا من الأفضل دائمًا التفكير في الأدوات ضمن ثلاث دوائر:
- أدوات قراءة فقط
- أدوات إنشاء أو تجهيز مسودات
- أدوات كتابة أو تحديث حساسة
والقاعدة العملية الأفضل غالبًا هي:
اجعل الوكيل يقرأ أكثر مما يكتب، ويكتب أكثر مما يرسل، ويرسل أقل ما يمكن من دون مراجعة عند الحساسية.
بالنسبة لعامر، هذا يعني مثلًا:
- يمكن للوكيل أن يقرأ جدول الطلبات
- ويمكنه أن يقرأ حالة الدفع
- ويمكنه أن يجهز مسودة رسالة
- وربما يمكنه إنشاء بوليصة شحن
- لكن لا ينبغي أن يغيّر عنوان الطلب، أو يرسل تعويضًا، أو يعتمد إرجاعًا نهائيًا من دون ضوابط واضحة
هذه الفكرة مهمة لأنها تمنع الخلط بين “القدرة” و”الحق”.
الوكيل قد يستطيع تقنيًا تنفيذ أشياء كثيرة. لكن القدرة التقنية ليست تصريحًا تشغيليًا.
ثانيًا: لماذا ترتيب التنفيذ مهم؟
الأداة وحدها لا تكفي.
حتى لو كانت الصلاحيات مضبوطة، فإن التنفيذ نفسه يمكن أن ينحرف إذا كان ترتيب الخطوات سيئًا. كثير من الأخطاء لا تأتي من أداة خاطئة، بل من خطوة صحيحة جاءت في التوقيت الخطأ.
خذ حالة بسيطة من متجر عامر:
المطلوب تجهيز شحنات اليوم.
قد يبدو المسار بديهيًا، لكنه ليس عشوائيًا.
الترتيب المنطقي هنا قد يكون:
- قراءة الطلبات
- التحقق من حالة الدفع
- التحقق من العنوان
- إنشاء بوليصة الشحن
- تحديث رقم التتبع
- تجهيز مخرج نهائي للطباعة أو للمراجعة
لو عكست هذا الترتيب، فقد تصنع بوليصة شحن لطلب لم يُدفع أصلًا، أو تحدث رقم تتبع قبل التأكد من صحة العنوان، أو تبني رسالة للعميل قبل أن تتأكد من أن الحالة تسمح بها.
وهنا يظهر الفارق بين الوكيل الذي “ينفذ” والوكيل الذي “يعمل بمنطق”.
الترتيب ليس شكليات، بل جزء من سلامة التنفيذ.
ولهذا، حين نقول إن الوكيل يحتاج Action Design، فنحن لا نعني فقط ربطه بالأدوات، بل أيضًا بناء سير عمل معقول يحدد:
- من أين يبدأ
- وما الذي يأتي بعد ماذا
- وما الذي يجب أن يتأكد منه قبل الخطوة التالية
وهنا أيضًا نرى أن الوكيل لا يولد من فراغ. هو لا يخلق ترتيب العمل من الصفر في كل مرة بوصفه عبقريًا حرًا، بل يعمل أفضل عندما يجد بنية واضحة يتحرك داخلها.
ثالثًا: متى يجب أن يتوقف؟
هذه واحدة من أكثر النقاط التي يستهين بها الناس، مع أنها من أوضح الفروق بين Demo جميل ونظام يمكن الوثوق به نسبيًا.
الوكيل الذكي ليس فقط من يعرف كيف يكمل.
بل من يعرف متى لا يكمل.
وهذا يقودنا إلى مفهوم شديد الأهمية: شروط التوقف والتصعيد.
لا يكفي أن تقول:
“إذا فهمت الهدف، نفّذ.”
بل يجب أن تقول أيضًا:
- إذا كانت حالة الدفع غير مؤكدة → توقف
- إذا كان العنوان ناقصًا → توقف
- إذا وُجد تعارض بين مصدرين → توقف
- إذا كانت الحالة حساسة ماليًا أو قانونيًا → صعّدها للبشر
- إذا كان المخرج غير مكتمل أو منخفض الثقة → لا تكمل وكأن كل شيء طبيعي
هذه الشروط ليست قيدًا على الذكاء، بل حماية له وللنظام حوله.
لأن الذكاء الاصطناعي، خصوصًا حين يُترك مع أدوات، قد يميل إلى إكمال الحلقة حتى عندما يجب أن يقطعها. وهذه نزعة خطرة جدًا إذا لم تُضبط.
بالنسبة لعامر، قد تبدو هذه الحالات بسيطة:
- دفعة غير مؤكدة
- عنوان ناقص
- طلب عليه ملاحظة خاصة
- تعويض محتمل
- اختلاف بين حالة الجدول وحالة النظام
لكن هذه البساطة الظاهرة تخدع. لأن هذه هي بالضبط الحالات التي تصنع المشاكل عندما يُسمح للنظام أن “يتصرف بثقة”.
ولهذا، فإن السؤال الجيد عند تصميم الوكيل ليس فقط:
“ماذا يفعل؟”
بل أيضًا:
“متى يتوقف؟ ومتى يقول لا أعرف؟ ومتى يطلب تدخلًا بشريًا؟”
أين ينتهي الـ Workflow وأين يبدأ الـ Agent؟
في هذه النقطة تحديدًا، يختلط الأمر على كثير من الناس.
لأنهم يرون سلسلة خطوات وأداة ذكاء داخلها، فيقولون: ممتاز، عندنا وكيل.
لكن ليس كل مسار فيه AI هو Agent بالمعنى الدقيق.
إذا كانت العملية كلها ثابتة تقريبًا:
- نفس الخطوات
- نفس الترتيب
- نفس التفرعات المعروفة مسبقًا
- ولا يوجد إلا قدر محدود جدًا من القرار
فهذا أقرب إلى Workflow ذكي أو AI Automation.
أما إذا صار النظام:
- يختار بين مسارات
- يقرر أي أداة يستخدم أولًا
- يسأل عند الغموض
- يتوقف عند الخطر
- يراجع الناتج
- ويعدل خطته بحسب الحالة
فهنا تبدأ روح الوكيل فعلًا.
هذا التفريق مهم لأن الناس كثيرًا ما تعطي اسم “Agent” لأي شيء فيه نموذج لغوي.
والأدق أن نقول:
الـ Workflow الذكي مفيد جدًا، بل ربما يكون أنسب في حالات كثيرة.
أما الوكيل فيدخل عندما تصبح المرونة واتخاذ القرار جزءًا من المهمة نفسها.
وبالنسبة لعامر:
- إذا كانت الرسائل كلها منظمة وتدخل من نماذج ثابتة، فقد يكفي Workflow ذكي
- أما إذا كانت الرسائل فوضوية، والحالات متنوعة، والاستثناءات كثيرة، والتصرف يتطلب قراءة هدف وسياق وسياسة، فهنا يبدأ الوكيل في اكتساب قيمته
لماذا لا تحتاج كل خطوة إلى “العقل الأثقل”؟
وهنا نصل إلى نقطة عملية جدًا يغفلها كثيرون عندما يبنون وكلاءهم: ليس كل جزء من النظام يحتاج إلى أقوى نموذج، ولا إلى أغلى تشغيل، ولا إلى أعمق reasoning.
هناك مهام بسيطة جدًا:
- تصنيف نية رسالة
- استخراج رقم طلب
- التحقق من وجود حقل
- تحويل نص قصير إلى صيغة مهيكلة
وهناك مهام أثقل:
- حل تعارض بين مصدرين
- التعامل مع حالة حساسة
- بناء تقرير تفسيري
- اقتراح إجراء مع مراجعة سياسية أو تشغيلية
إذا عاملت كل هذا على أنه يحتاج إلى “العقل الكامل” نفسه في كل مرة، فستدفع ثمنًا أعلى في الكلفة والوقت، وقد لا تحصل بالضرورة على نتيجة أفضل. هذه هي الفكرة التي يشار إليها أحيانًا عمليًا بـ Token Economics أو اقتصاد التوكن/الاستدعاء: طابق وزن النموذج مع وزن المهمة.
هذه ليست نصيحة مالية فقط، بل تصميمية أيضًا.
لأن الوكيل الجيد لا يكون “ثقيلًا” في كل لحظة، بل موزونًا.
يعرف متى يكفي إجراء بسيط.
ومتى يحتاج فعلًا إلى طبقة استدلال أقوى.
خلاصة تعويذة الفعل
إذا أردنا تلخيص هذه الدعامة كلها بوضوح، فهي لا تعني:
“أعط الوكيل أدوات.”
بل تعني:
- حدّد له ما الذي يلمسه وما الذي لا يلمسه
- رتّب له منطق التنفيذ
- ضع له شروط توقف وتصعيد واضحة
- فرّق بين الطريق الثابت والقرار المرن
- ولا تجعل كل خطوة أثقل مما تحتاج
بعبارة أخرى:
الفعل الجيد ليس قدرة على الحركة فقط، بل قدرة على الحركة داخل حدود صحيحة.
وهذا يقودنا إلى الدعامة الثالثة.
لأنك قد تكتب هدفًا ممتازًا، وتبني فعلًا ممتازًا، ثم ينهار كل شيء لسبب محبط جدًا:
الوكيل ببساطة… نسي.
نسي من هو العميل.
نسي ما الذي حدث في الخطوة السابقة.
نسي السياسة التي أكدت عليها قبل قليل.
أو بدأ كل مرة كأنه وُلد الآن.
وهنا تدخل تعويذة لا ينتبه لها كثيرون إلا بعد أول انهيار فعلي: الذاكرة.
تعويذة الذاكرة: كيف تمنع الوكيل من أن يبدأ من الصفر كل مرة؟
الناس غالبًا تخلط بين شعورها أن النموذج “يتذكّر” في واجهة المحادثة، وبين ما يحدث فعلًا عندما تبني وكيلًا يعمل عبر API أو داخل نظام تشغيل خاص. في الواجهة، قد يبدو لك أن النموذج يتابعك بسلاسة: تتكلم معه، ثم تعود لجملة سابقة، فيلتقط الخيط. وهذا الانطباع يوحي بسهولة أن الذاكرة موجودة طبيعيًا. لكن ما إن تبدأ ببناء وكيل عملي، حتى تظهر الحقيقة المزعجة: الذاكرة ليست افتراضًا مجانيًا.
الـ API، في كثير من الأنماط العملية، Stateless بطبيعته.
أي أن كل طلب جديد لا يحمل معه تلقائيًا تاريخ ما قبله، إلا إذا مررته أنت أو بنيت طبقة تحفظه وتلخّصه وتسترجعه. هذا يعني أن الوكيل قد يبدو ذكيًا جدًا في خطوة، ثم يتصرف في الخطوة التالية كما لو أنه بدأ الآن، إذا لم يكن هناك تصميم واضح للذاكرة.
خذ مثالًا بسيطًا من متجر عامر:
العميل كتب أولًا:
“طلبي متأخر.”
ففهم الوكيل الرسالة وصنفها وربما راجع الحالة وجهز ردًا مناسبًا.
بعد قليل كتب العميل:
“طيب إذا ما وصل بكرا، بدي أغيّر العنوان.”
إذا لم يكن لدى الوكيل حالة محفوظة، فقد يتعامل مع هذه الرسالة الثانية كأنها قطعة كلام مستقلة:
أي طلب؟
أي عنوان؟
ما الحالة الحالية؟
هل الطلب أصلاً خرج للشحن؟
هل تغيير العنوان مسموح في هذه المرحلة؟
ليس لأنه “غبي”، بل لأنه لم يُعطَ ذاكرة تشغيلية مناسبة.
1) سجل المحادثة: أبسط شكل للذاكرة
أول حل يخطر في البال عادة هو تمرير سجل المحادثة السابق مع كل طلب.
وهذا حل فعّال إلى حد ما في الحالات البسيطة، لأنه يمنح النموذج سياقًا مستمرًا: من قال ماذا؟ وما الذي جرى قبل لحظة؟
لكن هذا الحل يحمل مشكلتين واضحتين:
- يستهلك التوكنات بسرعة
- ويجعل الاعتماد على التاريخ الكامل مرهقًا كلما طال الحوار أو كثر العمل
بمعنى آخر: هو يعمل، لكنه لا يتوسع جيدًا دائمًا.
وإذا اعتمدت عليه وحده، فقد تجد نفسك ترسل للنموذج كمية كبيرة من “الماضي” لكي يحافظ فقط على خيط الحاضر.
2) ملخص حالة الجلسة: الحل العملي الأذكى غالبًا
ولهذا، في كثير من الأنظمة العملية، يكون الحل الأفضل هو Session State Summary:
بدل أن ترسل كل ما حدث بالتفصيل، تبني ملخصًا تشغيليًا قصيرًا يلتقط ما لا يجب أن يُنسى.
مثلًا:
- العميل: فلان
- رقم الطلب: كذا
- الحالة الحالية: تأخير بالشحن
- آخر خطوة: تم التحقق من شركة الشحن
- القيود: لا تغيير عنوان بدون موافقة
- الخطوة التالية: متابعة حالة التسليم أو التصعيد
هذا النوع من الملخصات ليس مجرد اختصار، بل هو طريقة لتحويل الفوضى الزمنية إلى حالة تشغيلية واضحة.
وبالنسبة لعامر، هذا فرق هائل. لأن الوكيل لم يعد مضطرًا إلى إعادة قراءة محادثة كاملة لكي يفهم أين يقف. صار عنده “بطاقة حالة” تخبره بما يلزم كي يكمل من النقطة الصحيحة.
3) الذاكرة الخارجية + الاسترجاع: عندما يكبر النظام
لكن حتى ملخص الجلسة لا يكفي دائمًا.
لأن الوكيل لا يحتاج فقط إلى تذكر ما حدث في هذه المحادثة، بل قد يحتاج أيضًا إلى الرجوع إلى أشياء أكبر وأكثر ثباتًا:
- سياسات الإرجاع
- أسلوب العلامة التجارية
- قائمة المنتجات
- تاريخ العميل
- قواعد التعويض
- مصادر الحقيقة المعتمدة
هنا تدخل الذاكرة الخارجية مع الاسترجاع.
الفكرة ليست أن “تحشر” كل شيء في الطلب كل مرة، بل أن تجعل الوكيل قادرًا على استدعاء ما يحتاجه وقت الحاجة من مكان موثوق.
هذا مهم جدًا، لأنك بذلك تنقل المعرفة الثابتة أو شبه الثابتة إلى طبقة مناسبة بدل أن تستهلك سياق المحادثة كلها. كما أنك تقلل من التخمين، لأن الوكيل لا يعتمد على ما “يبدو له” منطقيًا فقط، بل يرجع إلى مرجع محدد.
وبالنسبة لعامر، هذا يعني مثلًا أن سياسة الإرجاع لا تكون محفوظة داخل Prompt طويل يُعاد كل مرة، بل محفوظة في مصدر واضح يمكن الاسترجاع منه. وكذلك أسلوب الرد، وقائمة الاستثناءات، وبعض معلومات العملاء أو الطلبات.
لماذا الذاكرة ليست رفاهية؟
لأن غياب الذاكرة لا يجعل الوكيل أقل راحة فقط، بل أقل استقرارًا واتساقًا.
الوكيل بلا ذاكرة قد:
- يكرر نفس السؤال أكثر من مرة
- يغيّر موقفه لأن السياق ضاع
- ينسى قيدًا حساسًا
- يعالج الرسائل كأنها منفصلة بينما هي سلسلة واحدة
- أو يضطر إلى التخمين لملء فراغات كان يفترض أصلًا ألا توجد
وهذا يعني أن الذاكرة ليست شيئًا “جميلًا” نضيفه لاحقًا إذا تحسّن الوقت، بل جزء من سلامة التشغيل نفسها.
لكن الذاكرة وحدها لا تضمن الثقة
قد يكون عندك:
- هدف جيد
- أدوات مضبوطة
- وذاكرة ممتازة
ومع ذلك، يظل هناك سؤال لم نجب عنه بعد:
كيف تعرف أن ما فعله الوكيل صحيح؟
كيف تعرف أنه لم يلتزم بالخطة شكلًا فقط بينما النتيجة نفسها غير مناسبة؟
كيف تراجع أثره؟
كيف تراقب ما حدث؟
وكيف تمنع “الثقة المرتبة” من أن تخدعك؟
هنا نصل إلى التعويذة الرابعة، وربما الأهم على المدى العملي: الإثبات.
تعويذة الإثبات: كيف تجعل التنفيذ قابلًا للثقة والمراجعة؟
هذه هي الدعامة التي يتأخر كثيرون في الانتباه إليها، مع أنها غالبًا ما تفصل بين وكيل “مثير للإعجاب” ووكيل “يمكنك أن تنام وهو يعمل”.
لأن الذكاء الاصطناعي، مهما كان قويًا، يبقى في جوهره نظامًا احتماليًا. هو لا يعمل مثل برنامج حتمي بسيط يعطي دائمًا المخرج نفسه عند كل إدخال بنفس الطريقة الصارمة. وهذه ليست تهمة، بل طبيعة البنية نفسها. لكن ما دام الأمر كذلك، فلا يمكنك أن تبني فوقه عملًا حساسًا وتكتفي بقول: “يبدو الجواب جيدًا.”
هنا تأتي فكرة الإثبات.
ليس بالمعنى الفلسفي، بل بالمعنى العملي جدًا:
كيف تتحقق مما حدث؟
كيف تعرف أن التنفيذ كان صحيحًا؟
كيف تعرف أن النتيجة نفسها مناسبة؟
كيف تستطيع مراجعة ما جرى خطوة بخطوة إذا ظهرت مشكلة؟
بمعنى آخر: إذا كان قلب النظام احتماليًا، فلابد أن تغلفه من الخارج بطبقة أكثر حتمية وانضباطًا.
وهذا هو جوهر هذه الدعامة كلها:
أن تبني غلافًا من التحقق والمراقبة والوضوح فوق عقل احتمالي قوي.
1) التحقق من التنفيذ: هل فعلنا ما كان يجب فعله أصلًا؟
أول مستوى هنا هو ما يمكن تسميته Verification.
السؤال ليس: “هل النتيجة جميلة؟”
بل: “هل الخطوات نفسها نُفذت كما ينبغي؟”
خذ مثال عامر.
الوكيل كان مطلوبًا منه أن:
- يراجع الطلبات المدفوعة فقط
- ينشئ بوالص الشحن
- يربط أرقام التتبع الصحيحة
- ولا يلمس العناوين من دون موافقة
هنا التحقق لا يحتاج رأيًا إنشائيًا، بل فحوصًا واضحة:
- هل عدد الطلبات التي عالجها يساوي عدد الطلبات المدفوعة المطلوب شحنها؟
- هل يوجد طلب غير مدفوع دخل بالغلط؟
- هل كل Tracking ID مرتبط بالطلب الصحيح؟
- هل لم تُجرَ أي تعديلات في حقول ممنوعة؟
هذه الطبقة أساسية لأنها تمنعنا من الانبهار بالنص النهائي ونسيان ما إذا كان التنفيذ قد انحرف في المنتصف. قد يرجع لك الوكيل بتقرير مرتب جدًا، لكنه ارتكب في داخله سلسلة أخطاء صغيرة لم تكن لتظهر لو لم يكن لديك فحص واضح.
وهنا تظهر أيضًا قيمة المخرجات المهيكلة.
كثير من الأنظمة لا تحتاج من الوكيل فقرة بلاغية، بل تحتاج شيئًا قابلًا للقراءة الآلية والمراجعة الآلية أيضًا:
- قائمة طلبات
- حالات
- استثناءات
- حقول واضحة
ولهذا تكون صيغة مثل JSON أو أي شكل Structured Output مفيدة جدًا. ليس لأنها “تقنية أنيقة”، بل لأنها تجعل ما خرج من الوكيل قابلًا للفحص. بدل أن يكتب:
“أعتقد أن معظم الطلبات جاهزة تقريبًا”،
يصبح مضطرًا إلى إخراج حقول مثل:
- order_id
- status
- tracking_id
- exception_reason
وهنا يتحول التحقق من الانطباع إلى الفحص.
2) التحقق من النتيجة: هل المخرج نفسه مناسب؟
لكن حتى لو نفّذ الوكيل الخطوات كما ينبغي، يبقى سؤال آخر:
هل النتيجة نفسها صحيحة بالمعنى الذي نريده؟
هذا هو مستوى Validation.
التحقق من التنفيذ يقول لك:
هل مشينا المسار كما يجب؟
أما التحقق من النتيجة فيقول لك:
هل خرجنا أصلًا بالشيء المناسب؟
قد يكون النظام قد:
- قرأ الجدول
- وتحقق من الدفع
- وأنشأ بوالص
- وربط الحقول
لكن المخرج النهائي قد يظل غير مناسب لسبب آخر:
- ربما اختار أولوية ترتيب لا تناسب عامر
- ربما أخرج تقريرًا ناقصًا
- ربما التزم بالخطوات لكنه خالف أسلوب الرد المطلوب
- ربما بنى قرارًا “صحيحًا” تقنيًا لكنه لا يحترم السياسة التجارية
وهنا لا يكفي أن تقول: “نفّذ كما قلت له.”
بل يجب أن يكون لديك معيار تقييم:
- هل التزم بالسياسة؟
- هل المعلومات دقيقة؟
- هل كل الحقول المهمة مكتملة؟
- هل النص مناسب للأسلوب المعتمد؟
- هل ظهرت استثناءات كان يجب إبرازها؟
هذه الطبقة مهمة جدًا لأنها تذكّرنا أن التنفيذ الجيد ليس فقط تنفيذًا ميكانيكيًا، بل تنفيذًا مناسبًا للغرض.
3) القابلية للمراقبة: هل أستطيع فهم ما الذي حدث؟
هنا نصل إلى شيء يفرق جدًا بين النظام الذي “يعمل غالبًا” والنظام الذي يمكن تشغيله بثقة داخل عمل حقيقي: Observability أو القابلية للمراقبة.
السؤال هنا ليس فقط:
هل نفّذ؟
بل أيضًا:
هل أستطيع أن أعرف كيف نفّذ؟
إذا حدث خطأ، هل أملك أثرًا أرجع إليه؟
هل يوجد سجل يشرح:
- ما الذي قرأه
- ما الأداة التي استدعاها
- ما النتيجة التي رجعت
- أين توقف
- ما الذي صعّده
- ما الذي تجاهله
- وما الذي حدث في كل خطوة؟
هذه الطبقة مهمة جدًا لأن الأنظمة الذكية، خصوصًا عندما تصبح متداخلة مع أدوات وبيانات خارجية، قد تفشل بطرق لا تظهر فورًا. وإذا لم يكن عندك أثر واضح لما حدث، فستتحول عملية التصحيح إلى تخمين.
بالنسبة لعامر، القابلية للمراقبة قد تعني مثلًا:
- سجل لوقت معالجة كل طلب
- السطر أو المرجع الذي استُخدم من الجدول
- رابط البوليصة التي أُنشئت
- حالة الدفع التي بُني عليها القرار
- سبب إدراج الطلب ضمن الاستثناءات
- ما إذا كان هناك تصعيد أو توقف
هذا ليس تعقيدًا بيروقراطيًا، بل هو ما يجعل الوكيل قابلًا للإدارة لا مجرد قابل للتشغيل.
4) مصدر الحقيقة: إذا تعارضت البيانات، من نصدق؟
هذه نقطة صغيرة في شكلها، لكنها واحدة من أخطر النقاط في الأنظمة العملية:
ما هو المرجع النهائي؟
أحيانًا تكون لديك أكثر من طبقة معلومات:
- جدول يدوي
- CRM
- بريد
- نظام دفع
- منصة شحن
والوكيل قد يجد تعارضًا بينها:
- الطلب في الجدول “مدفوع”
- لكن في بوابة الدفع “معلّق”
- أو العنوان في الرسالة مختلف عن العنوان في الطلب
- أو حالة الشحن في النظام تختلف عن الملخص اليدوي
إذا لم تحدد Source of Truth، فسيبدأ الوكيل في الترجيح أو التخمين أو بناء منطق خاص به لحل التعارض. وهنا قد تنتج أخطاء تبدو “معقولة” من داخله لكنها غير مقبولة من داخلك أنت.
ولهذا، ضمن تعويذة الإثبات، يجب أن يكون واضحًا دائمًا:
- ما المرجع النهائي لكل نوع من البيانات؟
- من يفوز إذا وقع التعارض؟
- ومتى يجب أن يتوقف الوكيل بدل أن يقرّر من تلقاء نفسه؟
5) الموافقة البشرية وحدّ المخاطر
هذه واحدة من أكثر النقاط التي تكشف نضج النظام:
الاستقلالية لا تعني أن الوكيل يجب أن يعمل وحده في كل شيء.
الاستقلالية الجيدة تعني أنه يعرف أين ينتهي دوره ويبدأ دور الإنسان.
وهنا يأتي مفهوم:
- Human Approval
- وRisk Threshold
بعض الأشياء يمكن للوكيل أن ينفذها بثقة نسبية:
- تصنيف رسالة
- تجهيز مسودة
- تحديث حقل بسيط غير حساس
- استخراج تقرير
لكن بعض الأشياء يجب أن تُرفع لموافقة بشرية:
- تغيير عنوان
- استرجاع مالي
- تعويض
- استثناء من السياسة
- قرار غامض ذو أثر كبير
هذه ليست “قلة ثقة” في الوكيل.
هذه هي الثقة الصحيحة.
لأن الأنظمة الذكية لا تصبح أقوى حين تُترك بلا حدود، بل حين يُعرف بوضوح أين يجب أن تكمل، وأين يجب أن تسأل، وأين يجب أن تقف.
لماذا هذه الدعامة هي الأهم عمليًا؟
لأن الناس كثيرًا ما تبني:
- Goal جيد
- وأدوات جيدة
- وذاكرة معقولة
ثم تسقط في الفخ الأخير:
تفترض أن التنفيذ ما دام خرج بشكل مرتب، فهو “تمام”.
وهنا يبدأ الخطر الحقيقي.
لأن أخطر ما في الوكلاء ليس الخطأ الفجّ.
بل الخطأ الذي يخرج لك بشكل مرتب وواثق.
ولهذا، فإن الإثبات ليس شيئًا نضيفه بعد أن “يشتغل النظام”.
بل هو جزء من تعريف كلمة “يشتغل” نفسها.
إذا لم تستطع التحقق، والمراجعة، والمراقبة، وإيقاف الأثر عند الحاجة… فأنت لا تملك نظامًا ناضجًا، بل تملك قدرة مثيرة قد تعمل أحيانًا وتفاجئك أحيانًا أخرى.
كيف تعمل هذه الدعائم الأربع معًا؟
من السهل أن نقرأ Goal وAction وMemory وProof كأنها أربع وحدات منفصلة: واحدة للغرض، واحدة للأدوات، واحدة للسياق، وواحدة للمراجعة. لكن في الواقع، قيمة هذه الدعائم لا تظهر حين تعمل منفردة، بل حين تشكل دائرة واحدة.
الهدف يمنع الغموض.
الفعل يمنع الفوضى في التنفيذ.
الذاكرة تمنع النسيان والتناقض.
والإثبات يمنع الثقة غير المستحقة.
وإذا اختل واحد منها، يبدأ الباقي بالترنح:
- هدف جيد بلا فعل مضبوط = ذكاء يعرف ماذا يريد، لكنه يتحرك بشكل خطر
- فعل مضبوط بلا ذاكرة = نظام ينفذ، لكنه ينسى من أين بدأ وإلى أين وصل
- ذاكرة جيدة بلا إثبات = نظام يبدو متماسكًا، لكن لا يمكنك الوثوق بنتائجه
- إثبات قوي بلا هدف واضح = تراقب شيئًا غير واضح أصلًا
لهذا، فالطريقة الأصح لفهم الوكيل العملي هي أنه ليس “نموذجًا + أداة”، بل نظام قرار مبني على هذه الأربعة معًا. وكل واحدة منها لا تزين الأخرى، بل تصححها.
مثال كامل: كيف يبني صاحب متجر وكيله خطوة بخطوة؟
لنأخذ عامر من البداية إلى النهاية، لكن هذه المرة كمنظومة كاملة لا كأمثلة متفرقة.
عامر يريد وكيلًا يساعده يوميًا في شحن الطلبات والرد على المشكلات الشائعة.
لو بدأ بطريقة سطحية، قد يقول:
“اجعل الوكيل يراجع الطلبات ويحل المشكلات.”
هذا يبدو جيدًا على الورق، لكنه غامض وخطر.
أما إذا بدأ ببناء الوكيل وفق الدعائم الأربع، فالمشهد يتغير:
1) الهدف
يحدد بوضوح:
- المطلوب: تجهيز قائمة شحنات اليوم + مسودات الردود على الحالات المرتبطة بها
- القيود: لا تعديل على العنوان، لا اعتماد استرجاع، لا إرسال نهائي بدون مراجعة
- السياق: الطلبات في الجدول الفلاني، الدفع من النظام الفلاني، السياسة في المستند الفلاني
2) الفعل
يضبط الأدوات:
- قراءة الطلبات
- قراءة حالة الدفع
- إنشاء بوليصة
- تحديث tracking_id فقط
- تجهيز draft reply
- لا إرسال مباشر
ويحدد الترتيب:
تحقق الدفع → تحقق العنوان → إنشاء البوليصة → تحديث التتبع → إخراج التقرير
ويحدد التوقف:
- إذا الدفع غير مؤكد → توقف
- إذا العنوان ناقص → توقف
- إذا تعارضت البيانات → صعّد
3) الذاكرة
يبني طبقة حالة:
- من هو العميل؟
- ما آخر حالة للطلب؟
- هل هناك مشكلة مفتوحة؟
- هل توجد نقطة تحتاج موافقة عامر؟
- ما الخطوة التالية؟
ويضيف ذاكرة خارجية:
- سياسة الإرجاع
- أسلوب الرد
- قائمة الحالات الحساسة
4) الإثبات
يفرض فحوصًا:
- هل عولجت الطلبات المدفوعة فقط؟
- هل أنشئت البوالص بشكل صحيح؟
- هل رُبطت أرقام التتبع بالطلبات الصحيحة؟
- هل يوجد استثناءات واضحة؟
- هل المخرج منظم وقابل للمراجعة؟
في النهاية، لا يرجع الوكيل لعامر بـ “مقال” عن الحالة.
يرجع له بشيء قابل للعمل:
- قائمة جاهزة
- استثناءات
- مسودات
- ونقاط تحتاج توقيعًا بشريًا
هنا فقط يصبح لدينا وكيل عملي.
لا لأنه “يفهم اللغة جيدًا” فقط، بل لأنه صار يعمل داخل نظام مضبوط.
من هنا يبدأ الاختبار الحقيقي
إذا كان المقال السابق شرح لك كيف ينتقل LLM من الكلام إلى التنفيذ، فهذا المقال يوضح لك شيئًا أهم: الانتقال وحده لا يكفي.
الوكيل لا يصبح مفيدًا لأنه صار يملك أدوات فقط، بل لأنه صار محكومًا بهدف واضح، وفعل مضبوط، وذاكرة تمنعه من التشتت، وإثبات يضمن أنك لا تعمل داخل ضباب جميل الشكل.
وهنا تبدأ الحقيقة التي كثيرًا ما يهرب منها الناس:
الوكيل ليس “سحرًا جاهزًا”، بل نظام يحتاج تصميمًا واعيًا.
وكلما صار أقرب إلى العالم الحقيقي، صار التصميم أهم من الانبهار.
لكن حتى لو صممت وكيلًا جيدًا، قد يقع شيء آخر:
قد تحاول أن تحمله أكثر مما يحتمل.
قد تعطيه غموضًا أكبر من اللازم.
أو صلاحيات أكثر من اللازم.
أو تستخدم وكيلًا واحدًا لمشهد أعقد من أن يحمله وحده.
وهنا يبدأ الاختبار الحقيقي فعلًا.
ليس في سؤال: “هل يعمل؟”
بل في سؤال أخطر:
ماذا يحدث عندما يخطئ؟ وكيف نمنع أن يتحول الخطأ إلى كارثة؟
هذا هو المكان الذي يفتح عليه المقال السادس طبيعيًا:
من مشهد الكارثة… إلى المدير والوكلاء المتخصصين… إلى الأنظمة الوكيلة الاحترافية.
