إذا كانت نماذج اللغة الكبيرة مثل ChatGPT تستطيع فهم التعليمات وكتابة النصوص وتحليل المعلومات، فإن الوكلاء الذكيين AI Agents يأخذون هذه القدرة خطوة أبعد بكثير: بدل أن يكتفي النظام بإعطائك إجابة، يمكنه أن يحاول تنفيذ سلسلة من الإجراءات للوصول إلى هدف محدد. فقد يبحث عن معلومات، ويقارن بين نتائج، ويستخدم أداة حساب، ويقرأ ملفًا، ويستدعي API، ويسجل نتيجة، ثم يقرر ما الخطوة التالية بناءً على ما حدث في الخطوة السابقة.
وهنا يظهر الفرق الحقيقي بين استخدام نموذج لغوي كأداة محادثة واستخدامه داخل نظام Agentic. إذا قلت لنموذج عادي: "ابحث عن أفضل طريقة لتنظيم هذه البيانات"، فقد يعطيك شرحًا. أما الوكيل الذكي المصمم للمهمة فقد يقرأ البيانات نفسها، ويقرر طريقة التنظيف، ويشغل كودًا للتحليل، ويكتشف القيم الناقصة، ويعيد المحاولة عند وجود خطأ، ثم يخرج لك تقريرًا نهائيًا. لم يعد الذكاء الاصطناعي هنا مجرد مولد للنصوص، بل أصبح جزءًا من نظام يخطط ويستخدم الأدوات ويتابع حالة المهمة حتى يصل إلى نتيجة.
لكن هذا لا يعني أن AI Agent يمتلك إرادة مستقلة أو وعيًا. من الناحية التقنية، نحن نتحدث عن برنامج يجمع نموذجًا ذكيًا مع أدوات وذاكرة وتعليمات وقواعد تنفيذ. قوة النظام تأتي من قدرة هذه الأجزاء على العمل معًا، ومن السماح للنموذج باختيار الخطوة التالية من بين مجموعة محددة من الأفعال.
 |
| الوكلاء الذكيون AI Agents كيف تنفذ الأنظمة المهام تلقائيًا؟ |
ما هو الوكيل الذكي AI Agent؟
يمكن تعريف AI Agent بأنه نظام برمجي يستقبل هدفًا أو مهمة، ويراقب المعلومات المتاحة له، ثم يختار أفعالًا تساعده على التقدم نحو الهدف. قد يعتمد هذا النظام على نموذج لغوي كبير، لكنه لا يقتصر عليه. فالنموذج يكون غالبًا جزء اتخاذ القرار أو تفسير اللغة، بينما توجد حوله أدوات تسمح له بالفعل الحقيقي.
تخيل أنك طلبت من وكيل: "راجع هذه الفواتير واستخرج الفواتير التي تحتوي على أخطاء في الإجمالي". لكي ينفذ المهمة، قد يحتاج إلى قراءة الملفات، واستخراج البيانات، وإجراء عمليات حسابية، ومقارنة الإجماليات، ثم كتابة تقرير. النموذج اللغوي وحده قد يعرف كيف يشرح ذلك، لكن الوكيل يملك حلقة تنفيذ تسمح له بالانتقال من التفكير في المهمة إلى استخدامها فعليًا مع الأدوات.
الوكيل ليس مجرد Chatbot أكثر ذكاءً
الفرق الأساسي أن Chatbot يركز عادة على المحادثة وتوليد الرد، بينما Agent يستطيع أن يحتفظ بهدف ممتد عبر عدة خطوات ويتفاعل مع بيئة خارجية. وقد تكون هذه البيئة ملفات، أو قاعدة بيانات، أو متصفحًا، أو برنامجًا، أو خدمة عبر API.
لذلك السؤال الذي يحدد هل النظام Agent أم مجرد نموذج محادثة هو: هل يستطيع اتخاذ إجراءات ومتابعة نتائجها لاتخاذ الخطوة التالية؟
ما الفرق بين LLM وAI Agent؟
نموذج اللغة الكبير LLM هو المحرك الذي يستطيع فهم النص، والتنبؤ بالمخرجات، والتحليل، واختيار الاستجابة. أما AI Agent فهو النظام الأكبر الذي يمكن أن يستخدم LLM بالإضافة إلى أدوات ومعلومات وحالة تشغيل.
يمكن تشبيه LLM بعقل خبير يستطيع اقتراح ما يجب فعله، بينما الوكيل هو هذا العقل وقد أعطي حاسوبًا وهاتفًا ومجلدات وأدوات يستطيع استخدامها ضمن حدود معينة.
النموذج يقترح والوكيل ينفذ
في نظام بسيط، قد تسأل النموذج: "ما الملفات التي يجب أن أراجعها؟" فيعطيك قائمة. في نظام Agentic، قد يقرر بنفسه فتح الملفات ذات الصلة وقراءتها ثم اختيار ما يحتاج إلى مزيد من الفحص.
لكن عملية التنفيذ لا تحدث لأن النموذج "مد يده" إلى الكمبيوتر، بل لأن التطبيق المحيط به يوفر وظائف يمكنه استدعاؤها.
ما العناصر الأساسية لأي وكيل ذكي؟
رغم اختلاف التصميمات، تتكرر مجموعة من المكونات داخل أغلب الأنظمة الوكيلة: الهدف، النموذج، الأدوات، الذاكرة أو حالة المهمة، حلقة التنفيذ، وآلية التوقف أو التحقق.
يمكن أن يكون النظام بسيطًا جدًا، مثل Agent يستخدم أداة واحدة للبحث، أو معقدًا بحيث يدير عشرات الأدوات ويتعاون مع وكلاء آخرين.
الهدف Goal
الهدف هو ما يريد النظام الوصول إليه. كلما كان الهدف واضحًا وقابلًا للتحقق، كان تصميم الوكيل أسهل.
"ساعدني في العمل" هدف غامض، بينما "اقرأ ملفات المبيعات لهذا الشهر وحدد أكبر خمسة انخفاضات مقارنة بالشهر السابق" هدف أكثر قابلية للتنفيذ.
النموذج Model
النموذج يفهم التعليمات، ويحلل حالة المهمة، ويختار الخطوة التالية. قد يكون نموذج لغة كبيرًا أو نموذجًا متخصصًا.
الأدوات Tools
هي الوظائف التي يستطيع الوكيل استخدامها، مثل البحث، وتشغيل الكود، وقواعد البيانات، والبريد، والتقويم، والملفات، والحاسبة، وواجهات APIs.
بدون أدوات يبقى الوكيل محدودًا في الكلام
النموذج قد يعرف ما ينبغي فعله، لكنه لن يستطيع الوصول إلى بياناتك الخاصة أو تنفيذ عملية خارجية إذا لم تمنحه النظام الأدوات المناسبة.
كيف يعرف Agent متى يستخدم أداة؟
في الأنظمة المبنية على LLM، يتم عادة تعريف الأدوات للنموذج بطريقة منظمة. قد يقال له إن لديه أداة تسمى Search تستقبل استعلامًا، وأداة Calculator تستقبل عملية حسابية، وأداة DatabaseQuery تستقبل استعلامًا معينًا.
عندما يحلل النموذج المهمة، يمكنه اختيار إحدى هذه الأدوات وإنتاج طلب منظم لاستخدامها.
Function Calling هو جسر بين اللغة والتنفيذ
من أشهر الأفكار المستخدمة هنا ما يسمى Function Calling أو Tool Calling. بدل أن يكتب النموذج عبارة "سأبحث الآن"، ينتج طلبًا منظمًا لاستدعاء وظيفة محددة بمعاملات معينة.
التطبيق يشغل الوظيفة بالفعل، ثم يعيد النتيجة إلى النموذج.
مثال عملي على Tool Calling
إذا قلت لوكيل سفر: "اعرف لي حالة الطقس ثم اقترح ملابس مناسبة"، فقد يقرر أولًا استدعاء أداة الطقس باستخدام المدينة والتاريخ. تعود الأداة بدرجة الحرارة واحتمال المطر، ثم تدخل النتيجة إلى السياق. بعد ذلك يكتب النموذج توصية مناسبة.
المهم أن النموذج لم يخمن حالة الطقس. هو أدرك أنه يحتاج إلى بيانات خارجية، واختار الأداة، ثم استخدم نتيجتها.
هذا يقلل الحاجة إلى الاعتماد على ذاكرة النموذج
الأدوات تسمح للنظام بالحصول على بيانات حديثة أو دقيقة أو خاصة بدل الاعتماد فقط على ما تعلمه أثناء التدريب.
حلقة Agent Loop: قلب الوكيل الذكي
الفرق الأكبر بين طلب واحد وسلوك Agent يظهر في ما يسمى حلقة الوكيل Agent Loop. بدل مسار "سؤال → إجابة"، يصبح المسار أقرب إلى:
هدف → تحليل الحالة → اختيار فعل → تنفيذ → ملاحظة النتيجة → اختيار الفعل التالي → تكرار حتى الاكتمال.
هذه الحلقة تجعل النظام قادرًا على تعديل مساره أثناء العمل.
لماذا يحتاج الوكيل إلى التكرار؟
لأن بعض المهام لا يمكن حلها في خطوة واحدة. قد يبحث في قاعدة بيانات ثم يكتشف أن معلومة ناقصة، فيحتاج إلى مصدر ثانٍ. وقد يشغل كودًا فيفشل بسبب خطأ في البيانات، فيقوم بتعديل الطريقة ثم يعيد التنفيذ.
هذا النوع من التفاعل هو ما يمنح النظام مظهرًا أكثر استقلالية.
ما المقصود بالتخطيط Planning؟
المهمة المعقدة قد تحتاج إلى تقسيم قبل التنفيذ. يمكن للوكيل إنشاء خطة أولية مثل: جمع البيانات، ثم التحقق منها، ثم تحليلها، ثم إعداد التقرير.
يسمى هذا Planning.
هل يجب أن يلتزم بالخطة حرفيًا؟
ليس دائمًا. من المفيد أن تكون الخطة قابلة للتعديل. إذا وجد النظام أن البيانات غير موجودة، يجب أن يغير المسار بدل الاستمرار في خطوات لم تعد منطقية.
الخطة وسيلة وليست هدفًا
أفضل Agent ليس الذي يكتب أطول خطة، بل الذي يعرف متى يحتاج إلى خطة ومتى يستطيع تنفيذ خطوة مباشرة.
كيف يستخدم الوكيل الذاكرة؟
يمكن أن نميز بين أكثر من نوع من "الذاكرة". هناك السياق الحالي الذي يحتوي على تفاصيل المهمة والخطوات السابقة، وهناك حالة محفوظة خارج النموذج، مثل قاعدة بيانات تحتوي على نتائج أو تفضيلات أو مهام مكتملة.
Short-Term Memory
تمثل المعلومات اللازمة للمهمة الحالية، مثل النتائج التي تم جمعها والخطوات التي نفذت.
Long-Term Memory
قد تشير إلى معلومات يتم تخزينها لاستخدامها في مهام مستقبلية، إذا كان النظام مصممًا لذلك.
الذاكرة ليست جزءًا سحريًا من LLM
غالبًا توجد كنظام تخزين خارجي، ثم يتم استرجاع المعلومات المناسبة وإدخالها إلى السياق عندما يحتاجها الوكيل.
ما علاقة RAG بالوكلاء الذكيين؟
تقنية RAG التي تربط النموذج بالمستندات يمكن أن تصبح إحدى أدوات Agent. فإذا احتاج الوكيل إلى معرفة سياسة داخلية، يستدعي نظام RAG، وإذا احتاج إلى عملية حسابية يستخدم Calculator، وإذا احتاج إلى بيانات حديثة يستخدم Search أو API.
بهذا يصبح RAG جزءًا من منظومة أكبر بدل أن يكون كل النظام.
Agentic RAG
في RAG التقليدي قد ننفذ بحثًا واحدًا ثم نجيب. أما Agentic RAG فيمكن للوكيل أن يقرر هل البحث الأول كافٍ، أو يحتاج إلى إعادة صياغة السؤال، أو البحث في مصدر آخر.
وهذا يجعل الاسترجاع أكثر ديناميكية.
كيف يختلف Agent عن Workflow ثابت؟
لنفرض أن لديك برنامجًا ينفذ دائمًا خمس خطوات بالترتيب نفسه. هذا يسمى Workflow أو Pipeline، حتى لو استخدم الذكاء الاصطناعي في إحدى الخطوات.
أما Agent فيملك عادة قدرة أكبر على اختيار المسار. قد يقرر استخدام الأداة A أو B حسب الحالة، أو تخطي خطوة، أو إعادة خطوة.
متى يكون Workflow أفضل؟
إذا كانت المهمة ثابتة وقواعدها واضحة، فقد يكون Workflow التقليدي أكثر أمانًا وأقل تكلفة وأسهل في الاختبار.
لا تحتاج إلى Agent لكي ترسل فاتورة تلقائيًا كل يوم إذا كان التسلسل ثابتًا.
متى يصبح Agent مفيدًا فعلًا؟
يصبح مفيدًا عندما تكون المهمة متغيرة ولا يمكن كتابة كل مساراتها مسبقًا بسهولة، أو عندما تحتاج إلى تفسير معلومات ثم اختيار أدوات مختلفة بناءً عليها.
مثلًا، معالجة طلب دعم فني معقد قد تتطلب البحث في دليل، ثم فحص بيانات حساب، ثم طرح سؤال إضافي، ثم تنفيذ إجراء مختلف حسب المشكلة.
مثال عملي: وكيل يحلل بيانات المبيعات
تخيل Agent استلم الأمر: "حلل مبيعات هذا الشهر وحدد أسباب التراجع المحتملة من البيانات المتاحة."
يمكن أن يبدأ بفتح ملف المبيعات، ثم يكتشف أن البيانات تحتوي على عدة مناطق. يشغل تحليلًا لحساب التغير لكل منطقة، ثم يجد أن أكبر هبوط في منطقة معينة. بعد ذلك يقرأ بيانات المنتجات في هذه المنطقة، ويكتشف أن منتجين يمثلان معظم الانخفاض. ثم ينشئ تقريرًا يوضح النتائج.
النقطة المهمة هي أن المسار لم يُكتب بالكامل مسبقًا
ربما في شهر آخر تكون المشكلة مختلفة، فيختار Agent تحليل قناة المبيعات بدل المناطق.
هذه المرونة هي القيمة الرئيسية.
مثال آخر: وكيل دعم فني
يمكن أن يستقبل الوكيل رسالة مثل: "لا أستطيع تسجيل الدخول منذ تحديث التطبيق."
يستخرج نوع الجهاز والإصدار من المعلومات المتاحة، ثم يبحث في قاعدة المعرفة، ويفحص حالة الخدمة إن كانت لديه أداة مناسبة، ثم يحدد الخطوات التي ينبغي تجربتها.
إذا كانت المشكلة تحتاج إلى موظف بشري، يمكن أن ينشئ ملخصًا للحالة ويرسلها للتصعيد.
هنا يعمل Agent كمنسق بين مصادر متعددة
القوة ليست فقط في كتابة الرد، بل في الجمع بين المعلومات والقرار والتنفيذ.
كيف يعمل AI Agent تقنيًا خطوة بخطوة؟
لنفترض أن الوكيل لديه ثلاث أدوات: البحث، والحاسبة، وقاعدة بيانات. يدخل طلب المستخدم إلى LLM مع وصف الأدوات المتاحة وقواعد استخدامها.
يحلل النموذج الهدف ويقرر مثلًا أنه يحتاج أولًا إلى قاعدة البيانات. يصدر Tool Call. ينفذ البرنامج الاستعلام ويعيد النتائج. تدخل النتائج إلى النموذج في دورة جديدة. يرى النموذج أن هناك أرقامًا تحتاج إلى حساب، فيستدعي Calculator. بعد الحصول على الناتج، يقرر أن المعلومات كافية ويكتب الجواب النهائي.
كل دورة تضيف Observation جديدة
في أدبيات الوكلاء يشار أحيانًا إلى نتيجة الأداة باسم Observation، لأنها تمثل ما "شاهده" النظام بعد تنفيذ الفعل.
يتغير القرار التالي وفق هذه الملاحظة.
ما هو نمط ReAct؟
هناك فكرة شائعة في تصميم الأنظمة الوكيلة تسمى ReAct، وهي تقوم على المزج بين الاستدلال واتخاذ الأفعال. عمليًا، الفكرة أن النظام يحلل ما يحتاج إليه، ينفذ فعلًا، يقرأ النتيجة، ثم يقرر ما بعد ذلك.
المهم للمبتدئ ليس حفظ الاسم، بل فهم المبدأ: القرار والتنفيذ والملاحظة تتكرر في حلقة.
كيف يعرف Agent أنه انتهى؟
هذه نقطة أساسية. يجب أن تكون هناك Stopping Condition أو قاعدة تحدد متى أصبحت المهمة مكتملة.
قد يكون الشرط أن جميع الحقول المطلوبة أصبحت موجودة، أو تم إنشاء الملف النهائي، أو وصلت الثقة إلى مستوى معين، أو لم تعد هناك أدوات ضرورية.
بدون شرط توقف قد يدور النظام بلا نهاية
لذلك غالبًا توضع حدود مثل أقصى عدد من الخطوات أو مدة التنفيذ أو التكلفة.
هذه ليست تفاصيل ثانوية، بل جزء مهم من هندسة Agent موثوق.
ما معنى Autonomy في الوكلاء؟
الاستقلالية لا تعني أن النظام حر بلا حدود. تعني مقدار الحرية التي تمنحه له لاختيار الخطوات.
يمكن أن يكون Agent منخفض الاستقلالية بحيث يقترح كل خطوة وينتظر موافقة المستخدم، أو مرتفع الاستقلالية بحيث ينفذ عدة خطوات متتالية داخل حدود واضحة.
الاستقلالية يجب أن تتناسب مع المخاطر
البحث في ملفات عامة أقل حساسية من إرسال أموال أو حذف بيانات أو إرسال رسالة إلى عميل.
كلما زادت خطورة الفعل، زادت أهمية الموافقة البشرية والقيود التقنية.
Human-in-the-Loop: لماذا يحتاج Agent إلى الإنسان؟
في بعض مراحل التنفيذ، من الأفضل أن يتوقف النظام ويطلب موافقة المستخدم أو الموظف قبل الاستمرار.
يسمى ذلك Human-in-the-Loop.
مثال واضح
يمكن للوكيل تحليل فاتورة واكتشاف خطأ واقتراح تعديلها تلقائيًا، لكنه لا يرسل فاتورة جديدة للعميل إلا بعد موافقة الموظف.
بهذا نستفيد من السرعة مع الحفاظ على التحكم البشري.
ما هي Permissions ولماذا تعد جوهرية؟
إذا أعطيت Agent أداة بريد إلكتروني، فلا يعني أنه يجب أن يستطيع قراءة وإرسال أي رسالة بلا قيود. يجب تحديد الصلاحيات بوضوح.
ينطبق الأمر نفسه على الملفات وقواعد البيانات والأنظمة المالية.
مبدأ أقل صلاحية Least Privilege
أحد أهم مبادئ الأمان هو إعطاء الوكيل أقل قدر من الصلاحيات اللازمة لتنفيذ المهمة.
إذا كان يحتاج إلى قراءة جدول فقط، لا تمنحه إذن الحذف.
ماذا يحدث إذا اتخذ Agent قرارًا خاطئًا؟
قد يستخدم أداة غير مناسبة، أو يسيء فهم نتيجة، أو ينفذ سلسلة من الخطوات بناءً على افتراض غير صحيح.
لذلك تحتاج الأنظمة إلى Validation، أي التحقق من صحة بعض النتائج قبل استخدامها في الخطوة التالية.
يمكن وضع قواعد حتمية حول النموذج
مثل منع عملية إذا تجاوز المبلغ حدًا معينًا، أو التحقق من وجود الحقول المطلوبة قبل إرسال طلب.
هذه القواعد تقلل الاعتماد على قرار النموذج وحده.
Prompt Injection أخطر مع Agents
إذا كان الوكيل يقرأ صفحات ويب أو مستندات، فقد يحتوي المحتوى على تعليمات خبيثة تحاول جعل النظام يتجاهل قواعده أو يستخدم أداة بطريقة غير مرغوبة.
هذه مشكلة Prompt Injection.
الفرق أن Agent يستطيع التنفيذ
في Chatbot عادي قد يؤدي الهجوم إلى إجابة سيئة. أما في Agent متصل بأدوات، فقد تكون النتائج أكثر خطورة إذا لم توجد قيود.
لهذا يجب التعامل مع المحتوى الخارجي كبيانات غير موثوقة.
كيف تحمي Agent من المحتوى غير الموثوق؟
الأمان الحقيقي لا يعتمد على Prompt فقط. يجب أن توجد طبقات تحكم خارج النموذج، مثل الصلاحيات، والتحقق من المدخلات، وقواعد التنفيذ، وموافقة المستخدم للعمليات الحساسة.
يمكن أيضًا فصل الأدوات الخطرة عن الأدوات منخفضة المخاطر.
لا تجعل النموذج هو الحارس الوحيد
إذا كانت هناك عملية لا يجب تنفيذها في ظروف معينة، اكتب قاعدة برمجية تمنعها، بدل الاعتماد فقط على طلب لغوي مثل "لا تفعل ذلك".
ما هو Agent متعدد الأدوات؟
يمكن لوكيل واحد امتلاك عدة أدوات. قد يبحث على الويب، ويقرأ قاعدة بيانات، ويكتب في جدول، ويستخدم تقويمًا.
التحدي هنا هو Tool Selection: كيف يعرف النظام أي أداة مناسبة للمهمة؟
وصف الأدوات يؤثر في الاختيار
إذا كانت وظائف الأدوات متشابهة أو أوصافها غامضة، قد يختار النموذج الأداة الخطأ.
لذلك تصميم واجهة الأدوات جزء من هندسة Agent.
ما هي الأنظمة متعددة الوكلاء Multi-Agent Systems؟
بدل Agent واحد يحاول القيام بكل شيء، يمكن بناء عدة وكلاء، لكل واحد دور معين.
مثلًا قد يوجد Agent للبحث، وآخر للتحليل، وثالث للمراجعة.
هل عدة Agents أفضل دائمًا؟
لا. قد تزيد التعقيد والتكلفة وصعوبة تتبع الأخطاء.
إذا كان Agent واحد قادرًا على حل المهمة جيدًا، فقد يكون أبسط وأكثر موثوقية.
التقسيم مفيد عندما توجد أدوار حقيقية منفصلة
لا تستخدم Multi-Agent فقط لأن الفكرة تبدو متقدمة.
كيف يتواصل عدة Agents؟
يمكن لكل وكيل إنتاج نتيجة منظمة يقرأها الآخر، أو يمكن وجود منسق مركزي يوزع المهام.
لكن كل طبقة اتصال تزيد فرصة الخطأ، لذلك تحتاج إلى تعريف واضح لما يدخل وما يخرج من كل وكيل.
ما الفرق بين AI Agent والأتمتة التقليدية؟
الأتمتة التقليدية ممتازة عندما تكون القواعد واضحة: إذا حدث A، نفذ B. أما Agent فيضيف القدرة على فهم مدخلات غير منظمة واتخاذ قرار بين عدة مسارات.
مثال بسيط
قاعدة "إذا وصلت فاتورة، خزّنها في مجلد الفواتير" أتمتة تقليدية.
أما "اقرأ الفاتورة، حدد نوعها، تحقق من الرقم الضريبي، قارنها بأمر الشراء، وإذا وجد اختلاف فأنشئ تقريرًا" فقد تستفيد من Agent.
هل يمكن لوكيل أن يستخدم الكود؟
نعم. يمكن تزويد Agent ببيئة تشغيل كود ليحلل بيانات أو يجري حسابات أو ينشئ ملفات.
هذا مفيد لأن النموذج اللغوي ليس دائمًا أفضل أداة للحسابات الدقيقة.
استخدم النموذج للقرار والكود للحساب
هذه قاعدة عملية مهمة. بدل أن تجعل LLM يحسب يدويًا آلاف الصفوف، اجعله يكتب أو يستدعي كودًا ينفذ العملية ثم يحلل النتيجة.
كيف يستخدم Agent APIs؟
واجهة API تسمح للبرنامج بالتواصل مع خدمة أخرى بطريقة منظمة. يمكن للوكيل استخدامها للحصول على أسعار أو بيانات أو تنفيذ إجراء.
لكن يجب التحقق من المعاملات قبل إرسال الطلبات.
الـ API يحول Agent من قارئ إلى منفذ
من هنا تأتي قوة الوكلاء، ومن هنا تأتي المخاطر أيضًا.
ما المقصود بحالة Agent State؟
خلال مهمة طويلة، يحتاج النظام إلى معرفة ما الذي تم إنجازه وما الذي بقي. هذه المعلومات تسمى غالبًا State.
قد تتضمن الخطوات المكتملة، والملفات التي تم فحصها، ونتائج الأدوات، وحالة الموافقات.
State يمنع فقدان مسار المهمة
من دونها قد يكرر الوكيل نفس الخطوة أو ينسى نتيجة مهمة من دورة سابقة.
لماذا تحتاج الأنظمة إلى Logs؟
يجب تسجيل ما فعله Agent: أي أداة استخدم، ومتى، وما النتيجة، وما الأخطاء التي حدثت.
هذا يسمى Logging أو Tracing.
لا يمكنك تحسين ما لا تستطيع رؤيته
إذا أخطأ الوكيل ولم تعرف أي خطوة سببت الخطأ، يصبح الإصلاح صعبًا جدًا.
ولهذا فإن أنظمة الإنتاج تحتاج إلى مراقبة أفضل بكثير من Demo بسيط.
كيف نقيم Agent؟
لا يكفي أن نقول إن النتيجة تبدو جيدة. يجب قياس عدة أمور: هل أكمل المهمة؟ هل استخدم الأدوات الصحيحة؟ كم خطوة أخذ؟ هل ارتكب أخطاء؟ ما التكلفة؟ وهل كانت النتيجة قابلة للتحقق؟
يمكن إنشاء مجموعة من المهام التجريبية وتشغيل الوكيل عليها مرارًا.
النجاح ليس جودة النص فقط
Agent قد يكتب تقريرًا ممتازًا لكنه نسي تنفيذ الإجراء المطلوب، وبالتالي فشل في المهمة.
ما معنى Task Success Rate؟
هي نسبة المهام التي يتمكن الوكيل من إكمالها بالشروط المحددة.
هذا مقياس مهم لأنه أقرب إلى الهدف الحقيقي من تقييم جمال الإجابة.
كيف تقلل تكلفة Agent؟
كل خطوة قد تستدعي نموذجًا أو أداة، لذلك يمكن أن تتراكم التكلفة بسرعة. من الأفضل ألا تجعل الوكيل يعيد التفكير والبحث بلا نهاية.
يمكن استخدام قواعد تحد من عدد الخطوات، واختيار نماذج أصغر لبعض القرارات البسيطة، وتجنب إرسال سياق ضخم كل مرة.
الذكاء في التصميم يوفر الحوسبة
أفضل Agent ليس الذي يستخدم أكبر نموذج في كل خطوة، بل الذي يستخدم المورد المناسب لكل جزء من المهمة.
هل الوكيل يحتاج دائمًا إلى LLM؟
ليس بالضرورة وفق التعريف العام للوكيل، لكن معظم الحديث الحالي عن AI Agents يشير إلى أنظمة تستخدم نماذج لغوية كطبقة أساسية لاتخاذ القرار والتعامل مع التعليمات الطبيعية.
هناك وكلاء أقدم في الذكاء الاصطناعي لا يعتمدون على نماذج اللغة بالطريقة نفسها.
ما الفرق بين Assistant وAgent؟
يمكن أن يكون المساعد نظامًا يرد على المستخدم وينتظر طلبه التالي، بينما Agent يستطيع متابعة هدف متعدد الخطوات.
لكن الحدود بين المصطلحين ليست صارمة دائمًا، وقد تستخدم الشركات الكلمات بطرق مختلفة.
ركز على القدرات لا الاسم
اسأل: هل يستطيع النظام استخدام أدوات؟ هل يحتفظ بحالة المهمة؟ هل يختار الخطوة التالية؟ هل ينفذ إجراءات؟
هذه الأسئلة أهم من الاسم التجاري.
مثال كامل: وكيل لإعداد تقرير أسبوعي
لنفترض أن الهدف هو: "أنشئ تقريرًا أسبوعيًا عن أداء المتجر."
يمكن للوكيل تنفيذ المسار التالي:
الحصول على بيانات المبيعات من قاعدة البيانات.
حساب التغير مقارنة بالأسبوع السابق.
تحديد أكثر المنتجات نموًا وتراجعًا.
فحص بيانات المخزون للمنتجات المتراجعة.
كتابة تفسير قائم على البيانات المتاحة.
إنشاء التقرير في ملف.
عرضه للمستخدم للمراجعة قبل الإرسال.
هذا مثال حقيقي على انتقال AI من مجرد كتابة التقرير إلى تنسيق عملية إنتاج التقرير كاملة.
لماذا يجب التمييز بين الاستنتاج والحقيقة؟
إذا اكتشف Agent أن مبيعات منتج انخفضت وأن المخزون كان منخفضًا، يمكنه القول إن هناك ارتباطًا محتملًا، لكنه لا يجب أن يحول ذلك تلقائيًا إلى حقيقة سببية.
هذه القاعدة مهمة لأن الوكلاء قد يجمعون معلومات من مصادر متعددة ثم يبنون استنتاجات تبدو قوية.
التنفيذ لا يجعل الاستنتاج صحيحًا تلقائيًا
كلما كانت المهمة حساسة، زادت الحاجة إلى توثيق الأدلة التي بني عليها القرار.
كيف تبني أول Agent بسيط؟
ابدأ بهدف ضيق جدًا. مثل: "اقرأ سؤال المستخدم، وإذا كان يحتاج حسابًا استخدم الحاسبة، وإذا كان يحتاج معلومة من الملفات استخدم البحث، ثم أجب."
لا تبدأ بعشرين أداة وذاكرة طويلة ووكلاء متعددين.
ابنِ الحلقة الأساسية أولًا
النسخة الأولى تحتاج إلى:
نموذج يفهم السؤال.
أداتين أو ثلاث بأوصاف واضحة.
حلقة تسمح باستدعاء الأداة وإعادة النتيجة للنموذج.
حد أقصى للخطوات.
سجل يوضح كل عملية.
شرط توقف واضح.
هذه العناصر وحدها تكفي لتتعلم معظم الفكرة الأساسية.
قالب عملي لتصميم سلوك AI Agent
يمكنك استخدام القالب التالي كنقطة بداية عند تصميم تعليمات وكيل بسيط:
الدور:
أنت وكيل ذكي مسؤول عن [اكتب المهمة الرئيسية].
الهدف النهائي:
يجب أن تصل إلى [عرّف النتيجة النهائية القابلة للتحقق].
الأدوات المتاحة:
لديك الأدوات التالية:
[اسم الأداة الأولى + وظيفتها]
[اسم الأداة الثانية + وظيفتها]
[اسم الأداة الثالثة + وظيفتها]
قواعد التنفيذ:
استخدم الأداة فقط عندما تكون ضرورية. لا تخمن معلومة يمكن الحصول عليها من أداة متاحة. افحص نتيجة كل أداة قبل الانتقال إلى الخطوة التالية. إذا فشلت أداة، جرّب مسارًا بديلًا آمنًا إن كان متاحًا. لا تنفذ أي إجراء حساس أو غير قابل للعكس دون موافقة المستخدم.
معيار الاكتمال:
اعتبر المهمة مكتملة فقط عندما [حدد شروط النجاح].
عند نقص المعلومات:
إذا كانت البيانات غير كافية لاتخاذ خطوة آمنة، توقف واطلب المعلومات الضرورية بدل اختراعها.
النتيجة النهائية:
اعرض للمستخدم ما تم إنجازه، وأهم النتائج، وأي خطوة لم تتم وسبب ذلك.
هذا القالب وحده لا يصنع Agent كاملًا، لأن التنفيذ يحتاج إلى كود وأدوات وصلاحيات، لكنه يعطيك نموذجًا واضحًا لكيفية فصل الهدف عن الأدوات والقيود وشروط النجاح.
مثال Prompt لوكيل تحليل ملفات
أنت وكيل لتحليل ملفات المبيعات. هدفك تحديد أكبر ثلاثة أسباب رقمية لتغير المبيعات مقارنة بالفترة السابقة. ابدأ بقراءة الملفات المتاحة، ثم تحقق من أن الفترات الزمنية قابلة للمقارنة. استخدم أداة الحساب عند تنفيذ العمليات الرقمية، ولا تحسب المجاميع الكبيرة يدويًا. إذا كان ملف ضروري مفقودًا، توقف واذكر ما ينقص. لا تنسب سببًا لتغير المبيعات ما لم تدعمه البيانات. بعد الانتهاء، قدم تقريرًا يذكر النتيجة والأرقام الداعمة ومصدر كل رقم.
هذا المثال يوضح أن Prompt Agent الجيد لا يحدد فقط المطلوب، بل يحدد كيف يتعامل النظام مع الأدوات والأخطاء وعدم اليقين.
متى يجب ألا تستخدم Agent؟
إذا كانت العملية بسيطة ومحددة بالكامل، فقد تكون الأتمتة التقليدية أفضل. وإذا كانت المخاطر عالية جدًا ولا يمكن ضمان التحقق البشري، قد يكون السماح للنظام بتنفيذ أفعال مستقلة قرارًا غير مناسب.
كذلك لا تجعل Agent يقرر في موضوع لا يملك بيانات كافية عنه.
Agents ليست حلًا لكل مشكلة
أحيانًا Function واحدة أو Workflow من ثلاث خطوات أفضل بكثير من نظام Agentic معقد.
الهدف هو حل المشكلة بأقل تعقيد ممكن.
كيف تختار مستوى الاستقلالية المناسب؟
فكر في نتيجتين: تكلفة الخطأ وإمكانية التراجع عنه. إذا كانت النتيجة مجرد إنشاء مسودة، يمكن السماح بمرونة عالية. إذا كان الإجراء حذف ملفات أو إرسال أموال أو نشر محتوى رسمي، يجب أن تكون الموافقة البشرية أقوى.
يمكن بناء مستويات واضحة:
قراءة وتحليل تلقائي.
اقتراح إجراءات دون تنفيذ.
تنفيذ إجراءات منخفضة المخاطر.
طلب موافقة قبل الإجراءات الحساسة.
منع بعض العمليات بالكامل.
بهذا تصبح الاستقلالية قرارًا هندسيًا وليست مجرد ميزة تسويقية.
هل يمكن لـ AI Agents أن تعمل لساعات؟
تقنيًا يمكن تصميم الأنظمة لمهام طويلة، لكن زيادة المدة تزيد فرص تراكم الأخطاء وفقدان السياق وارتفاع التكلفة.
لذلك تحتاج المهام الطويلة إلى State جيدة، ونقاط تحقق، وإمكانية استئناف، ومراقبة.
كل خطوة مستقلة هي فرصة جديدة للخطأ
ولهذا فإن الموثوقية تصبح أصعب كلما زاد عدد الخطوات.
كيف تمنع الخطأ من الانتشار عبر المهمة؟
يمكن وضع Checkpoints. بعد مرحلة مهمة، يتحقق النظام من صحة النتائج قبل الاستمرار.
مثلًا بعد استخراج بيانات مالية، يمكن تشغيل قواعد تحقق من مجموع الأعمدة وتوافق التواريخ قبل السماح للوكيل بإنشاء التقرير.
هذا يمنع خطأ صغيرًا في البداية من التحول إلى سلسلة كاملة من القرارات الخاطئة.
ما مستقبل الوكلاء الذكيين؟
الاتجاه الواضح هو انتقال عدد متزايد من تطبيقات AI من مجرد الإجابة إلى تنفيذ العمل. سنرى أنظمة أكثر قدرة على استخدام البرامج والملفات والخدمات الرقمية ضمن صلاحيات محددة، وأنظمة تجمع بين RAG والأدوات والذاكرة والتخطيط.
لكن التحدي الحقيقي لن يكون في جعل Agent ينفذ خطوات أكثر فقط، بل في جعله أكثر موثوقية وقابلية للمراجعة والتحكم.
كلما اقترب النظام من اتخاذ أفعال حقيقية، أصبحت هندسة الأمان والتقييم والصلاحيات أهم من مجرد تحسين أسلوب الإجابات.
الخلاصة: AI Agents تحول الذكاء الاصطناعي من مجيب إلى منفذ
الوكلاء الذكيون AI Agents يمثلون مرحلة مهمة في تطور تطبيقات الذكاء الاصطناعي. نموذج اللغة في حد ذاته يستطيع فهم التعليمات وتوليد النصوص، لكن Agent يضع هذا النموذج داخل منظومة تمنحه أدوات وذاكرة وحالة تشغيل وقدرة على متابعة هدف عبر عدة خطوات.
يبدأ الوكيل من هدف، ثم يحلل الحالة، ويختار فعلًا، ويستخدم أداة، ويقرأ النتيجة، ثم يقرر ما يجب فعله بعد ذلك. هذه الحلقة يمكن أن تتكرر حتى تكتمل المهمة. وقد تكون الأدوات محرك بحث، أو قاعدة بيانات، أو حاسبة، أو نظام ملفات، أو API، أو برنامجًا آخر.
وهنا نرى بوضوح العلاقة بين التقنيات التي تعلمناها في المقالات السابقة: LLM يفهم اللغة ويتخذ القرار، وPrompt Engineering يحدد الهدف والقواعد، وRAG يمنحه المعرفة المناسبة، وTools تمنحه القدرة على الفعل، بينما تمثل Agent Loop الآلية التي تربط كل هذه الأجزاء ببعضها.
لكن زيادة القدرة على التنفيذ تعني زيادة المسؤولية. يجب ألا نعطي Agent صلاحيات واسعة بلا حدود، ولا نعتمد على Prompt كوسيلة الأمان الوحيدة. نحتاج إلى Permissions، وقواعد برمجية، وموافقات بشرية، وLogs، واختبارات، وشروط توقف واضحة.
وعندما تصمم كل هذه الأجزاء بصورة صحيحة، يتحول الذكاء الاصطناعي من أداة تنتظر سؤالًا ثم تكتب إجابة، إلى نظام قادر على استلام هدف، والبحث عن الطريق المناسب، واستخدام الأدوات، وتصحيح المسار، ثم تنفيذ المهمة ضمن الحدود التي حددها الإنسان. وهنا تبدأ فعليًا مرحلة جديدة من الأتمتة الذكية.
0 تعليقات