ما هو AI Agent؟ وما الفرق بينه وبين ChatGPT؟ شرح عملي

إذا كان ChatGPT يستطيع الكتابة والتحليل والإجابة عن الأسئلة، فما الذي يجعل AI Agent مختلفًا عنه؟ الإجابة لا تتعلّق بكون أحدهما «أذكى» بالضرورة، بل ببنية النظام وما يستطيع فعله بعد فهم طلب المستخدم.

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

لذلك ينبغي التمييز بين النموذج اللغوي، والمساعد، وسير العمل، والوكيل، والنظام الوكيلي. هذه المصطلحات متداخلة في الاستخدام التجاري، كما أن تعريف «الوكيل» ليس موحّدًا تمامًا بين الشركات والأبحاث. لكن التعريف العملي المفيد هو: نظام يستخدم نموذجًا لاتخاذ قرارات حول مسار المهمة واستخدام الأدوات، بدل اتّباع خطوات ثابتة بالكامل. تعرّف Anthropic الوكيل بأنه نموذج يوجّه عملياته واستخدامه للأدوات بنفسه لإنجاز المهمة، لا أن يتبع نصًّا ثابتًا. (anthropic.com)

ما هو AI Agent؟

الوكيل الذكي (AI Agent) هو تطبيق أو نظام يحقّق هدفًا عبر معالجة المدخلات، والاستدلال باستخدام الأدوات المتاحة، واتخاذ إجراءات بناءً على قراراته. ويصف توثيق Google Cloud الوكيل بأنه تطبيق يستخدم نموذجًا بوصفه محرّكًا للاستدلال، مع أدوات للتفاعل مع الأنظمة والبيانات الخارجية، وقد يستخدم الذاكرة للحفاظ على السياق. (cloud.google.com)

يتكوّن الوكيل عادةً من مجموعة عناصر، لكن وجود كل عنصر ليس شرطًا مطلقًا في كل تعريف أو تطبيق:

• النموذج اللغوي الكبير (LLM): يفسّر اللغة، ويقدّر الخطوة التالية، ويحوّل النتيجة إلى قرار أو استجابة.
• الهدف والتعليمات: تحدّد ما الذي يحاول النظام إنجازه، وما القيود التي يجب ألّا يتجاوزها.
• السياق: يشمل طلب المستخدم، والمعلومات السابقة، ونتائج الأدوات، وحالة المهمة الحالية.
• الأدوات (Tool Use): وظائف أو واجهات برمجية تتيح البحث، وقراءة الملفات، وتشغيل الشيفرة، والاستعلام من قاعدة بيانات، أو تنفيذ إجراء في نظام خارجي.
• التخطيط (Planning): تقسيم الهدف إلى خطوات أو اختيار ترتيب مناسب لها. قد يكون التخطيط صريحًا في صورة قائمة خطوات، أو ضمنيًّا أثناء التفاعل مع الأدوات.
• الإجراءات (Actions): ما ينفّذه النظام فعليًّا، مثل إنشاء تذكرة، أو تعديل سجلّ، أو إرسال طلب.
• الذاكرة (Memory): حفظ حالة المحادثة أو معلومات تمتدّ عبر جلسات متعدّدة عند الحاجة. لا تحتاج كل مهمة إلى ذاكرة طويلة الأجل.
• شرط التوقّف: يحدّد متى يقدّم النظام النتيجة، أو يطلب توضيحًا، أو يتوقّف بسبب فشل أو نقص صلاحية.

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

أما النظام الوكيلي (Agentic System) فهو المصطلح الأوسع: قد يضمّ وكيلًا واحدًا، أو عدّة وكلاء، أو سير عمل ثابتًا يجمع بين خطوات حتمية وخطوات يقرّر فيها النموذج ما ينبغي فعله. لذلك لا توجد حدود هندسية واحدة تفصل دائمًا بين «المساعد» و«الوكيل»، لكن الاستقلالية في اختيار الخطوات والأدوات معيار عملي مهم.

ما الفرق بين AI Agent وChatGPT؟

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

في المحادثة التقليدية، يكون النمط غالبًا كالتالي:

1. يكتب المستخدم سؤالًا أو تعليمات.
2. يفسّر النموذج الطلب.
3. يولّد إجابة نصية.
4. يقرّر المستخدم ما الذي سيفعله بعد ذلك.

أما في نظام وكيل، فقد يحدث الآتي:

1. يفهم النظام الهدف.
2. يحدّد المعلومات أو الأدوات اللازمة.
3. يستدعي أداة.
4. يقرأ النتيجة.
5. يختار خطوة أخرى أو يطلب موافقة.
6. ينفّذ الإجراء أو يعرض النتيجة النهائية.

توضّح وثائق OpenAI أن الوكلاء يستطيعون التخطيط وإنجاز المهام باستخدام الأدوات، والعمل مع وكلاء آخرين، والحفاظ على السياق عبر الخطوات. كما تميّز بين تشغيل يديره النظام، وSDK يمنح التطبيق التحكّم في حلقة الوكيل، واستدعاء النموذج مباشرة عبر Responses API. (platform.openai.com)

خذ مثالًا افتراضيًّا:

«ابحث عن أفضل موعد متاح للاجتماع مع الفريق الأسبوع القادم.»

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

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

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

بعبارة مختصرة: ChatGPT اسم منتج أو واجهة مألوفة، أما AI Agent فهو وصف لبنية تشغيلية قد تستخدم ChatGPT أو نموذجًا آخر داخلها.

كيف يعمل AI Agent؟

يمكن تبسيط آلية الوكيل في صورة حلقة:

هدف المستخدم
↓
فهم المهمة
↓
اختيار الخطوة التالية
↓
استخدام أداة عند الحاجة
↓
قراءة النتيجة
↓
تحديد ما إذا كانت المهمة اكتملت
↓
إجراء آخر أو إجابة نهائية

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

ولنفترض أن المستخدم طلب: «جهّز ملخّصًا للمبيعات الشهرية وحدّد سبب الانخفاض». قد يعمل النظام على النحو التالي:

1. فهم الهدف: المطلوب ليس مجرد تلخيص ملف، بل تحليل تغيّر في المبيعات.
2. تحديد الموارد: يحتاج النظام إلى ملف المبيعات، وربما بيانات الأشهر السابقة.
3. اختيار أداة: يستدعي أداة قراءة الملفات أو الاستعلام من قاعدة البيانات.
4. تحليل النتيجة: يكتشف انخفاضًا في منطقة معيّنة أو فئة منتجات محدّدة.
5. طلب بيانات إضافية: إذا كانت البيانات غير كافية، يبحث عن تقرير آخر أو يسأل المستخدم.
6. التحقّق: يقارن النتائج، أو يشغّل عملية حسابية، أو يطلب مراجعة بشرية.
7. التوقّف: يعرض الملخّص والاستنتاج، أو ينفّذ إجراءً مثل إنشاء تقرير.

تُسمّى هذه البنية أحيانًا Agent Loop. ولا يعني ذلك أن النموذج يعمل بلا حدود؛ فالتطبيق يضع عددًا أقصى للخطوات، ويحدّد الأدوات المتاحة، ويتعامل مع الأخطاء، وقد يوقف التنفيذ عند إجراء حسّاس. وتوفّر أطر الوكلاء الحديثة آليات لإدارة الحلقة، والتسليم بين الوكلاء، والموافقات، والتتبّع. (platform.openai.com)

هل كل أتمتة تُعدّ AI Agent؟

لا. الأتمتة أوسع من الوكلاء، ويمكن بناء أتمتة كاملة دون أن يتّخذ نموذج لغوي أي قرار.

مثال على سير عمل ثابت

إذا وصل طلب دعم
→ صنّفه
→ أنشئ تذكرة
→ أرسل بريدًا للعميل

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

أما في المثال الوكيلي، فقد يُعطى النظام هدفًا مثل:

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

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

توضّح Google Cloud أن سير العمل الحتمي يناسب المهام المتوقَّعة والمتسلسلة ذات المسار المعروف، بينما تناسب الأنظمة الوكيلية المشكلات المفتوحة التي تتطلّب قرارات ذاتية وإدارة خطوات متعدّدة. كما تشير إلى أن المهام البسيطة، مثل الترجمة أو التلخيص أو تصنيف الملاحظات، لا تحتاج عادةً إلى سير عمل وكيلي. (cloud.google.com)

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

مثال عملي: من السؤال إلى تنفيذ المهمة

لنفترض أن موظفًا يقول:

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

قد تمرّ المهمة بالمراحل التالية:

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

قد يتوقّف النظام بدل التخمين إذا وجد تعارضًا بين سياسة عامة وتعليمات خاصة بقسم الموظف. وقد يرفض تنفيذ الطلب إذا كانت صلاحية الاتصال بنظام الموارد البشرية للقراءة فقط.

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

أين يمكن أن يفشل AI Agent؟

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

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

تشرح Anthropic أن الوكلاء قد يسيئون فهم نية المستخدم، وأن أدواتهم وبيئاتهم تعرّضهم لهجمات مثل حقن التعليمات (Prompt Injection)؛ فالمحتوى الذي يقرأه الوكيل قد يتضمّن تعليمات خبيثة تحاول توجيهه إلى إجراء غير مقصود. كما تؤكّد أن الحماية لا تعتمد على النموذج وحده، بل على طبقات تشمل التعليمات، والأدوات، والبيئة، والمراقبة. (anthropic.com)

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

متى تحتاج AI Agent ومتى لا تحتاجه؟

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

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

أما سير العمل الثابت فيكون غالبًا أنسب عندما تكون الخطوات معروفة مسبقًا، والشروط محدّدة وقابلة للاختبار، والمسار لا يتغيّر كثيرًا بين تشغيل وآخر، والعملية حسّاسة وتحتاج نتيجة حتمية قابلة للتدقيق، ولا تضيف حرية القرار قيمة حقيقية.

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

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

ما الذي يجب الانتباه له قبل إعطاء الوكيل صلاحيات؟

قبل ربط الوكيل بالبريد أو التقويم أو نظام الموارد البشرية أو أدوات الدفع، ينبغي بناء الحدود قبل زيادة الاستقلالية:

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

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

الأسئلة الشائعة

هل ChatGPT يُعدّ AI Agent؟

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

ما الفرق بين AI Agent وروبوت المحادثة؟

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

ما الفرق بين AI Agent وسير العمل المؤتمت؟

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

هل يحتاج AI Agent إلى نموذج لغوي؟

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

هل الوكلاء مناسبون لكل المهام؟

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

المراجع

1. Anthropic — Trustworthy agents in practice (Anthropic، أبريل ٢٠٢٦) — جهة تجارية تصف منهجها في بناء وكلائها. anthropic.com
2. Google Cloud — Choose your agentic AI architecture components (Google Cloud، أبريل ٢٠٢٦) — توثيق منتج. cloud.google.com
3. Google Cloud — Choose a design pattern for your agentic AI system (Google Cloud، دون تاريخ ظاهر) — توثيق منتج. cloud.google.com
4. OpenAI — Agents (توثيق OpenAI API، دون تاريخ ظاهر) — توثيق منتج. platform.openai.com
5. Xu Huang وآخرون — Understanding the Planning of LLM Agents: A Survey (فبراير ٢٠٢٤) — مسوّدة على arXiv، غير محكَّمة. arxiv.org

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