من Assistant إلى Agent: كيف ينتقل LLM من الكلام إلى التنفيذ؟

كم مرة طلبت من نموذج لغوي أن “يشتغل”، ففعل كل شيء… إلا الشغل نفسه؟

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

وهنا يبدأ سوء الفهم الكبير.

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

هذا المقال هو لحظة الانتقال من فهم العقل اللغوي إلى فهم النظام الذي يعمل. 

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

رح نعرف الفرق بين المساعد الذكي والوكيل الذكي: متى يبدأ الذكاء الاصطناعي بالعمل؟
وكيف يتحول LLM من مساعد يشرح إلى وكيل ينفذ؟

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

وهنا بالضبط يبدأ الفرق بين Assistant وAgent.
ليس فرقًا في البلاغة.
ولا في الواجهة.
ولا حتى في الاسم التسويقي.
بل فرق في البنية التشغيلية نفسها:
هدف واضح، أدوات، ذاكرة، تنفيذ، ومراجعة.

لماذا يبدو ذكيًا… لكنه لا يشتغل من تلقاء نفسه؟

السبب الذي يجعل الناس يسيئون تقدير LLM غالبًا هو أن اللغة نفسها تخدعنا قليلًا. عندما يشرح لك النظام خطة جيدة، أو يكتب لك ردًا أنيقًا، أو يحلل مشكلة معقدة بطريقة تبدو منطقية، فمن السهل أن تشعر أنه “يعرف” ما الذي يجب فعله تاليًا، بل وأنه قادر على فعله أيضًا. لكن هذه القفزة الذهنية من الفهم اللغوي إلى القدرة التشغيلية هي بالضبط المكان الذي يولد فيه الالتباس.

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

هذا فرق جوهري، وليس تفصيلًا تقنيًا صغيرًا.

خذ مثالًا بسيطًا من حياة عامر صاحب المتجر. لو قال للنموذج:
“راجع آخر 100 طلب، اكتشف المشكلات، وحدّث ما يلزم.”
فالنموذج قد يفهم المقصود، ويقترح منطقًا جيدًا، وربما يكتب له حتى pseudo-workflow جميلًا. لكن هذا كله لا يعني أنه راجع فعلًا الطلبات، أو فتح فعلًا الملف أو الجدول، أو عرف فعلًا أي السجلات صحيحة وأيها متضارب، أو نفذ أي تحديث. ما لم تكن هناك طبقة تربطه بالأدوات والبيانات وتحدد له كيف ومتى وماذا يفعل، سيظل في النهاية يصف الشغل بدل أن يقوم به.

وهنا يمكن تلخيص الفارق بجملة واحدة مهمة جدًا:
الـ LLM يعرف كيف يتكلم عن المهمة. الوكيل يعرف كيف يدخل في دورة عمل عليها.

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

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

الساحر والعصا وكتاب التعاويذ: كيف نفهم الوكيل بطريقة أبسط؟

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

لكن مهما كان هذا الساحر بارعًا، سيبقى محدودًا ما لم تضع في يده شيئين:

أولًا: العصا
وهي الأدوات التي تمكنه من لمس العالم الخارجي:
ملف، جدول، قاعدة بيانات، بريد، متجر، API، خدمة شحن، نظام دفع، أو أي تكامل يسمح له بالخروج من النص إلى الفعل.

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

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

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

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

هنا لم نغير “ذكاء” الساحر فقط.
نحن أعطيناه:

• هدفًا أوضح
  
• أداة يصل بها إلى البيانات
  
• وكتابًا يحدد له كيف يشتغل، وما الذي يمنعه من الانزلاق إلى تصرف خاطئ
  

ومن هذه النقطة بالضبط، يبدأ الانتقال من مجرد مساعد يجيب… إلى شيء أقرب إلى وكيل يعمل.

خريطة القدرات: الإدراك والتفكير والتنفيذ

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

يمكننا تبسيط المشهد عبر ثلاث طبقات رئيسية: الإدراك، والتفكير، والتنفيذ.

الإدراك: ماذا يوجد أمامي أصلًا؟

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

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

التفكير واتخاذ القرار: ماذا أفعل بهذا الفهم؟

بعد أن يفهم النظام ما أمامه، يدخل إلى طبقة ثانية:
كيف يربط هذا الفهم بهدف؟
كيف يحدد الأولوية؟
كيف يبني خطة؟
كيف يقرر إن كان عليه أن يسأل، أو يتابع، أو يتوقف؟

هنا يبدأ LLM في الظهور كشيء أكبر من مجرد قارئ للنص. لأنه لا يكتفي غالبًا بقول “هذه رسالة شكوى”، بل يستطيع أيضًا أن يقترح:
ما المسار الأنسب؟
ما المعلومات الناقصة؟
ما الخطوات التالية؟
ما الرد الأفضل؟
ما المخاطر؟
ومتى يجب الحذر؟

لكن حتى هنا، ما زلنا داخل عالم “العقل”. داخل الفهم، والاستدلال، والتخطيط، والاقتراح. أي أننا ما زلنا نتحرك داخل مساحة اللغة والمنطق، لا داخل التنفيذ الفعلي.

التنفيذ: متى يخرج الذكاء من النص إلى العالم؟

هذه هي الطبقة التي يبدأ عندها الفرق الحقيقي بين Assistant وAgent.
التنفيذ يعني أن يتحول القرار إلى فعل:
فتح ملف،
قراءة جدول،
استدعاء خدمة،
تحديث سجل،
إرسال مسودة،
أو إطلاق سير عمل داخل نظام ما.

وهنا تظهر الحقيقة التي يخطئ كثيرون في تقديرها:
الـ LLM قوي في الإدراك والتفكير اللغوي، لكنه لا يملك التنفيذ تلقائيًا.
لا لأنه غير ذكي، بل لأنه ليس موصولًا بالعالم من تلقاء نفسه. لا توجد له “يد” إلا إذا بنيت له هذه اليد. ولا توجد له “صلاحية” إلا إذا منحتها له. ولا يوجد له “مسار عمل” إلا إذا صممته أنت أو صممه النظام الذي يعمل داخله.

بالنسبة لعامر صاحب المتجر، الفرق واضح جدًا:
إذا وصلته رسالة تقول:
“وصلني المنتج بلون غير الذي طلبته، وبدي أرجعه.”
فالـ LLM يستطيع أن:

• يفهم الرسالة
• يحدد أنها تتعلق بالإرجاع
• يلتقط أن هناك شكوى في الطلب
• يقترح ردًا مناسبًا
• بل وقد يحدد أيضًا أن هناك معلومات ناقصة

لكن التنفيذ يبدأ فقط عندما يصبح النظام قادرًا على:

• قراءة الطلب الحقيقي
• مطابقة رقم الطلب
• التحقق من سياسة الإرجاع
• فتح سجل العميل
• تجهيز خطوة عملية أو مسودة قرار
• أو رفع الحالة لمسار مناسب

هنا فقط ننتقل من “الذكاء الذي يفهم” إلى “الذكاء الذي يدخل في الشغل”.

وهذه الخريطة مهمة جدًا لأن المقال كله يقوم عليها.
لو نسيتها، سيبدو لك كل شيء متشابهًا:
chatbot، assistant، AI workflow، AI agent.
لكن عندما تراها بوضوح، تبدأ الفروق الحقيقية في الظهور:

• بعض الأنظمة تفهم فقط
• بعض الأنظمة تفهم وتقترح
• وبعضها يدخل فعلًا في طبقة التنفيذ

ومن هنا يصبح الحديث عن الأتمتة ضروريًا. لأننا لا نستطيع أن نفهم الوكيل الذكي من دون أن نفهم أولًا ما الذي كان يفعله الناس قبل الوكلاء أصلًا، وكيف ظهرت فكرة “الطريق الثابت”، ولماذا لم يعد هذا الطريق كافيًا وحده.

ما الفرق بين الأتمتة التقليدية والأتمتة الذكية والوكيل؟

حين يسمع الناس عبارة “وكيل ذكي”، يتخيل بعضهم أننا نتحدث عن شيء ظهر من العدم. لكن الوكيل لم يظهر في فراغ أيضًا. هو خرج من عالم أقدم منه: الأتمتة.

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

بهذا المعنى، الأتمتة ليست “ذكاءً” بالضرورة. هي تنظيم.
Trigger → Workflow → Output
مثير يبدأ العملية،
خطوات تمشي بترتيب محدد،
ثم نتيجة تخرج في النهاية.

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

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

الأتمتة التقليدية: الطريق الثابت

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

إذا كتب العميل رقم الطلب بصيغة خاطئة، أو شرح مشكلته بطريقته الخاصة، أو جمع بين مشكلتين مختلفتين في رسالة واحدة، فالأتمتة التقليدية تتوتر سريعًا. لأنها لم تُبنَ لتفهم، بل لتنفذ ضمن مسارات محددة.

الأتمتة الذكية: طريق ثابت فيه محطة فهم

هنا جاءت AI Automation كطبقة وسطى.
الفكرة ليست أن نهدم الأتمتة ونبدأ من الصفر، بل أن نزرع داخلها عقدة ذكاء تفهم ما يدخل إليها قبل أن يُدفع إلى المسار المناسب.

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

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

لاحظ الفرق هنا:
المسار ما يزال موجودًا.
لكننا أضفنا إليه عقلًا صغيرًا في المنتصف يساعده على فهم الفوضى قبل أن يكمل الطريق.

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

هذه قفزة كبيرة، لكنها ما تزال ليست الوكيل الكامل.

الوكيل: عندما لا يعود المسار ثابتًا بالكامل

هنا نصل إلى AI Agent.

الوكيل ليس مجرد أتمتة فيها محطة ذكاء.
هو نظام يأخذ هدفًا، ثم:

• يفهمه
• يقسمه
• يقرر ماذا يحتاج
• يختار الأدوات
• ينفذ
• ويراجع النتيجة

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

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

بالنسبة لعامر، تخيل الفرق بين الحالتين:

في AI Automation

النظام يقرأ الرسالة، يصنفها “مرتجعات”، ثم يفتح تذكرة ويرسلها إلى المسار المناسب.

في AI Agent

النظام قد:

• يقرأ الرسالة
• يتحقق من رقم الطلب
• يراجع السياسة
• يرى أن المدة ما تزال ضمن الإرجاع
• يجهز مسودة رد
• ينبه إلى أن العنوان يحتاج تحققًا
• ويوقف التنفيذ عند نقطة تحتاج موافقة بشرية

هذا ليس “ردًا أفضل” فقط.
هذا دخول في حلقة عمل.

ولهذا، فالفرق بين هذه الطبقات ليس فرق أسماء حديثة، بل فرق في مستوى الذكاء التشغيلي:

• الأتمتة = تنفيذ ثابت
• الأتمتة الذكية = تنفيذ ثابت مع فهم أفضل للمدخلات
• الوكيل = فهم + تخطيط + أدوات + تنفيذ + مراجعة

ومن هنا يصبح السؤال الذي لا يمكن تجنبه:
إذا كان هذا هو الفارق، فما الفرق إذن بين Assistant وAgent بشكل مباشر وصريح؟
هنا نصل إلى قلب المقال فعلًا.

Assistant vs Agent: الفرق الذي يغيّر كل شيء

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

المساعد: عقل يحاورك

المساعد الذكي، في صورته الأساسية، هو نظام لغوي ممتاز في:

• فهم السؤال
• تفسير المقصود
• تقديم جواب
• اقتراح خطوات
• إعادة ترتيب الفكرة
• وربما متابعة الحوار معك بشكل جيد

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

لكن المساعد، مهما كان ممتازًا، يظل في النهاية واقفًا عند عتبة معينة:
هو يرد، ثم ينتظر الجولة التالية منك.

بمعنى آخر، هو لا يحمل المهمة على كتفه.
هو يساعدك داخلها.
أنت ما تزال من يحدد التالي، ويفتح الملفات، ويستدعي الأنظمة، ويتحقق من الشروط، ويقرر متى يكمل ومتى يوقف.

الوكيل: عقل يعمل على هدف

أما الوكيل، فهنا تتغير صياغة العلاقة نفسها.

الوكيل لا يتعامل مع ما تعطيه له فقط بوصفه سؤالًا يحتاج إلى جواب، بل بوصفه هدفًا يحتاج إلى مسار عمل.
وهذا فرق هائل.

عندما تقول للمساعد:
“ساعدني في مراجعة آخر 200 منتج.”
فهو قد يقترح عليك كيف تفعل ذلك.

لكن عندما تقول لوكيل مضبوط:
“راجع آخر 200 منتج، طابق الصور مع الأوصاف، حدّث الأسعار من الجدول، وأعطني تقريرًا بما يحتاج موافقتي.”
فهنا يبدأ التفكير من نوع آخر:

• ما الذي أحتاجه؟
• ما الأدوات التي أستخدمها؟
• ما الترتيب؟
• ما الذي أستطيع تنفيذه؟
• ما الذي يجب أن أتوقف عنده؟
• وما النتيجة التي أعيدها في النهاية؟

وهذا هو جوهر الفرق.
المساعد يعينك داخل المهمة.
الوكيل يدخل في دورة عمل على المهمة نفسها.

الفرق ليس في “الذكاء”، بل في البنية

هذه النقطة شديدة الأهمية لأن كثيرًا من الناس يتخيل أن الوكيل هو فقط “Assistant أقوى”.
لكن الأدق أن نقول:
الوكيل هو Assistant + هدف + أدوات + ذاكرة + دورة قرار + تنفيذ + مراجعة.

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

• حالة يبدأ منها
• أدوات يتحرك بها
• خطوات يتبعها
• نتيجة يحاول الوصول إليها
• ومعايير يراجع نفسه على أساسها

لهذا السبب، قد يكون عندك نموذج لغوي ممتاز جدًا، لكنه ما يزال مساعدًا فقط.
وقد يكون عندك نموذج ليس “الأذكى على الورق”، لكنه داخل إطار وكيل مضبوط يقدم قيمة تشغيلية أعلى بكثير في الواقع.

لماذا يهم هذا الفرق عمليًا؟

لأن الخلط بين الاثنين يولد نوعين من الأخطاء:

الخطأ الأول

أن يحمّل الناس المساعد ما لا يستطيع فعله، ثم يصفوه بأنه “غبي” أو “غير عملي” لأنه لم ينفذ ما لم يُبنَ له أصلًا كي ينفذه.

الخطأ الثاني

أن يعطوا نظامًا مزودًا ببعض الأدوات صلاحيات أكبر مما ينبغي، ظانين أنه “وكيل ذكي” بما يكفي ليتصرف وحده، بينما هو في الحقيقة يحتاج ضبطًا أوضح وحدودًا أقسى.

وبالعودة إلى عامر:

• المساعد يمكن أن يكتب له ردًا على شكوى
• الوكيل يمكن أن يقرأ الشكوى، يراجع الطلب، يتحقق من السياسة، يجهز الرد، ثم يوقف التنفيذ عند الحالات الحساسة

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

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

لماذا لا يكفي LLM وحده؟

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

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

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

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

هذا يعني أن الذكاء الظاهر لا يساوي القدرة التشغيلية.

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

بالنسبة لعامر، هذا الفرق هو الفارق بين:

• “أعطني أفضل طريقة لمعالجة شكاوى العملاء”
• و
• “اقرأ شكاوى اليوم، صنّفها، راجع الطلبات المرتبطة بها، جهّز الردود، وارفع لي فقط الحالات التي تحتاج قرارًا”

الأولى مهمة لغوية.
الثانية سير عمل.

في الأولى، يكفي عقل يشرح.
في الثانية، نحتاج عقلًا + وصولًا + ذاكرة + قواعد + دورة مراجعة.

وهذا هو السبب الحقيقي في أن الحديث عن AI Agents لا يبدأ من “نموذج أقوى”، بل من نظام أوسع.
النموذج وحده لا يكفي لأنه:

• لا يملك أدوات من تلقاء نفسه
• لا يملك ذاكرة تشغيلية ثابتة من تلقاء نفسه
• لا يملك صلاحيات إلا إذا مُنحت له
• ولا يعرف حدود المؤسسة أو المشروع أو السياسة إلا إذا زُوّد بها بطريقة واضحة

لهذا، فالانتقال من Assistant إلى Agent ليس تحسينًا في الذكاء اللغوي فقط، بل إضافة لطبقات كان النموذج يفتقدها أصلًا.

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

ما الذي نضيفه ليبدأ بالعمل؟ الأدوات والذاكرة

إذا أردت تلخيص الفرق بين الـ LLM كمخ والوكيل كنظام في كلمتين فقط، فهما غالبًا:
أدوات وذاكرة.

من دون الأدوات، يبقى النموذج يفكر بصوت مرتفع.
ومن دون الذاكرة، يبقى ذكيًا… لكنه يبدأ من الصفر كل مرة.

الأدوات: كيف يمدّ يده إلى العالم؟

الأداة هنا لا تعني أداة بالمعنى البسيط فقط، بل أي واجهة تسمح للنظام بأن يتعامل مع شيء خارج النص:

• ملف
• جدول
• قاعدة بيانات
• بريد
• تقويم
• متجر
• CRM
• API
• محرك بحث
• خدمة شحن
• نظام دفع

هذه كلها، في منطق الوكيل، ليست “معرفة” فقط، بل منافذ فعل.

حين نعطي النموذج أداة، فنحن لا نجعله “ساحرًا خارقًا” فجأة. ما نفعله في الحقيقة هو أننا نمنحه قناة يمكنه من خلالها أن يطلب تنفيذ خطوة خارج عالم اللغة. مثلًا:

• اقرأ هذا الملف
• اسحب هذه البيانات
• تحقق من هذا السجل
• أرسل هذه المسودة
• احسب هذا الفرق
• حدّث هذا الحقل

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

هذه النقطة مهمة جدًا لأنها تمنع تضخيم الفكرة.
الوكيل ليس “كائنًا مستقلًا” بمعنى غامض، بل عقل لغوي موصول بوسائط عمل.

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

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

الذاكرة: كيف لا يبدأ من الصفر كل مرة؟

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

وهنا تأتي الذاكرة.

يجب أن ننتبه أولًا إلى أن كلمة “ذاكرة” هنا يمكن أن تعني أكثر من شيء.
هناك ذاكرة مؤقتة داخل السياق نفسه، وهي التي شرحنا حدودها في مقال ما هو LLM؟ كيف يتدرّب، وكيف يقرأ، ولماذا يبدو كأنه يفهم؟ عندما تحدثنا عن نافذة السياق. هذه ذاكرة مؤقتة، نافعة، لكنها محدودة.
وهناك شيء آخر أكثر عملية: ذاكرة خارجية أو تشغيلية تجعل النظام لا يبدأ من الصفر كل مرة.

هذه الذاكرة قد تحتوي مثلًا على:

• أسلوب العلامة التجارية
• سياسة الاسترجاع
• قائمة المنتجات
• الحالات الحساسة
• تفضيلات عامر
• قواعد يجب ألا تُخرق
• أو ملخص حالة العميل في الجلسة الحالية

وهنا تظهر قيمة الذاكرة بشكل واضح جدًا.
بدل أن يكرر عامر على النظام كل يوم:

• أسلوبي رسمي لكن لطيف
• لا تَعِد بتعويض قبل التحقق
• لا تغيّر عنوان الشحن دون موافقتي
• استخدم هذا القالب في الردود
• هذه هي سياسة الإرجاع
• هذه هي طريقة تسمية المنتجات

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

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

وبالنسبة لعامر، هذا فارق حاسم.
لو عاد العميل في رسالة ثانية وقال:
“طيب إذا ما وصل بكرا، بدي أغيّر العنوان.”
فالنظام من دون ذاكرة سيبدأ بالتعامل مع الجملة كأنها قطعة كلام منفصلة.
أما الوكيل الذي يملك حالة تشغيلية جيدة، فسيربطها فورًا بـ:

• من هو العميل
• أي طلب هذا
• ما الذي حدث في الخطوة السابقة
• وهل تغيير العنوان أصلًا مسموح في هذه المرحلة

الأدوات والذاكرة لا يكفيان أيضًا… إذا غابت الحلقة

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

وهذا يقودنا إلى الصيغة الأبسط والأوضح لفهم الوكيل في العمل اليومي:

خطة → أداة → تنفيذ → مراجعة

هذه ليست كل هندسة الوكلاء طبعًا، لكنها أفضل وصف عملي سريع لما يميّز الوكيل عن المساعد:

• يفهم الهدف
• يبني أو يلتقط خطة
• يستخدم الأداة المناسبة
• ينفذ خطوة
• يراجع الناتج
• ثم يقرر: هل يكمل؟ أم يتوقف؟ أم يرفع الأمر للبشر؟

ومن هنا يمكننا أن نرى بوضوح أن الانتقال من Assistant إلى Agent لم يكن قفزة واحدة غامضة.
بل كان إضافة تدريجية لأشياء كان النموذج يفتقدها:

• أيدٍ للوصول
• ذاكرة للاستمرارية
• وحلقة عمل تنظّم الحركة

وهنا نقترب من الخلاصة العملية الأكثر فائدة في المقال كله.

الوصفة الذهبية: خطة → أداة → تنفيذ → مراجعة

إذا أردنا أن نضغط كل ما سبق في وصف واحد يمكن للقارئ أن يحتفظ به بسهولة، فهذه هي الصيغة الأفضل:

الوكيل الذكي ليس مجرد نموذج يجيبك، بل نظام يمر بهذه الدورة:
خطة → أداة → تنفيذ → مراجعة

وهذه الصيغة مفيدة لأنها تعيد ترتيب المشهد كله بطريقة عملية جدًا.

1) خطة

في البداية، لا يتعامل النظام مع طلبك كسؤال يحتاج ردًا فقط، بل كهدف يحتاج إلى مسار.
ما المطلوب؟
ما الخطوات؟
ما النواقص؟
ما الأولوية؟
ما المخاطر؟

2) أداة

بعد أن يفهم الهدف، لا يكفي أن يشرح ما يجب فعله.
يجب أن يحدد:
ما الأداة التي أحتاجها الآن؟
هل أقرأ ملفًا؟
هل أراجع قاعدة بيانات؟
هل أبحث؟
هل أرسل مسودة؟
هل أتحقق من سياسة؟

3) تنفيذ

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

4) مراجعة

وهذه هي الخطوة التي تمنع الذكاء من التحول إلى فوضى.
بعد التنفيذ، يجب أن يعود النظام ليراجع:

• هل حصل ما كان يجب أن يحصل؟
• هل توجد فجوة؟
• هل هناك تعارض؟
• هل ينبغي التوقف؟
• هل النتيجة صالحة أم تحتاج تصعيدًا أو موافقة؟

بالنسبة لعامر، هذه الصيغة ليست مجرد نظرية.
لو طلب من الوكيل:
“راجع آخر 200 منتج، طابق الصور مع الأوصاف، حدّث الأسعار من الجدول، وأعطني تقريرًا بما يحتاج تأكيدي.”

فالوكيل الجيد لا يرد عليه بمقال جميل عن أفضل طريقة لفعل ذلك.
بل يدخل في الحلقة:

• يفهم الهدف
• يختار الأدوات
• يقرأ البيانات
• يطابق
• يحدث ما هو مسموح
• يرفع ما يحتاج قرارًا
• ثم يرجع بنتيجة قابلة للمراجعة

وهنا تتبدل قيمة الذكاء الاصطناعي نفسها.
لم يعد مجرد “واجهة حوار ذكية”، بل صار جزءًا من العمل الفعلي.

لماذا هذه النقلة أخطر مما تبدو؟

لأننا، ببساطة، لم نعد نتحدث عن نظام يخطئ داخل فقرة فقط.
أصبحنا نتحدث عن نظام يمكن أن يخطئ داخل فعل.

وهذا فرق جوهري.

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

• رسالة قد تُرسل
• سجل قد يُعدل
• قرار قد يُمرر
• تعويض قد يُقترح
• أو سياسة قد تُطبق بشكل ناقص

ولهذا بالضبط، الانتقال من Assistant إلى Agent ليس مجرد ترقية تقنية لطيفة.
إنه انتقال من مساحة “الكلام الذكي” إلى مساحة “الفعل المقيد”.
وهنا تبدأ الحاجة الحقيقية إلى الضبط، والقيود، والذاكرة، والتوقف، والمراجعة البشرية عند اللزوم.

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

من هنا يبدأ الوكيل الحقيقي

إذا خرجت من هذا المقال بصورة واحدة واضحة، فلتكن هذه:

الـ LLM هو العقل.
الأدوات هي الأيدي.
الذاكرة هي الاستمرارية.
والوكيل هو الطريقة التي تجمع كل ذلك داخل حلقة عمل.

هذه هي النقلة كلها.

ليست المسألة أن النموذج صار “أكثر ذكاءً” فجأة.
بل أن أحدًا أخيرًا بدأ يعطي هذا الذكاء اللغوي:

• هدفًا أوضح
• أيدي تصل إلى الأنظمة
• ذاكرة تمنعه من البدء من الصفر
• ومسارًا يجعله يشتغل بدل أن يكتفي بالشرح

لكن من هنا تبدأ المشكلة الأكبر أيضًا:
كيف نضبط هذا كله؟
كيف نمنع الغموض؟
كيف نحدد ما الذي يفعله وما الذي لا يفعله؟
كيف نمنحه الأدوات من دون أن نفتح له كل الأبواب؟
كيف نمنعه من النسيان، ومن التخمين، ومن العمل بثقة زائدة في المكان الخطأ؟

هذا هو المكان الذي يبدأ فيه الوكيل الحقيقي فعلًا.
ولهذا، فالمقال التالي لن يكون عن “ما هو الوكيل؟” بل عن شيء أهم:
كيف نبني وكيلًا عمليًا؟ الهدف، الأدوات، الذاكرة، والإثبات.