الرئيسية / مقالات

قد يكون الـ AI Agent جيداً، لكنه لا يحقق ما توقعت

كمال الحريبي · نُشر أول مرة على لينكدإن في 12 يوليو 2026 · قراءة 4 دقائق

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

أصبح من السهل اليوم أن تسمع مديراً يقول: "نريد وكيل ذكاء اصطناعي (AI Agent) ينفذ هذه المهمة". ثم تبدأ المنشأة مباشرة بالبحث عن مبرمج، أو شركة تقنية، أو منصة لبناء الوكلاء.

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

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

الوكيل ليس نقطة البداية

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

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

المبرمج قد يبني ما طلبته بالضبط، وهذه قد تكون المشكلة

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

هنا لم نعد نتحدث عن النماذج (Models) أو الربط البرمجي (APIs) أو صياغة الأوامر (Prompts)، بل عن فهم الأعمال (Business Understanding). الشخص التقني يستطيع بناء المنطق الذي نطلبه منه، لكن ليس من العدل أن نتوقع منه دائماً أن يفهم جذور المشكلة الإدارية أو التشغيلية، أو أن يكتشف أن المشكلة التي وصفناها له ليست المشكلة الحقيقية.

التقنية تحتاج إلى من يفهم ما وراء الطلب

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

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

لا تظلم المبرمج

أحياناً نحمّل الفريق التقني مسؤولية نتيجة لم يكن من المفترض أن يصل إليها وحده. نعطيه تصورنا للمشكلة، ونشرح له ما نريد، ثم نقول: "ابنِ لنا وكيل ذكاء اصطناعي". فيبني ما طلبناه، وقد يبنيه بشكل جيد جداً. لكن جودة البناء التقني لا تعني بالضرورة أننا طلبنا الحل الصحيح. هناك فجوة بين مشكلة العمل (Business Problem) والبناء التقني (Technical Build)، والكود وحده لا يغلقها.

الوكيل يحتاج أكثر من تعليمات جيدة

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

والمشكلة تبدأ عندما نحاول نقل هذه المعرفة إلى وكيل دون أن نفهمها نحن بشكل كافٍ. فنحصل على وكيل جيد، لكنه لا يصل إلى المستوى الذي كنا نتوقعه.

الذكاء الاصطناعي لا يصلح الغموض تلقائياً

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

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

قبل أن تبني وكيل ذكاء اصطناعي

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

نُشر هذا المقال أيضاً على لينكدإن.

تواصل معي