بناء وكلاء ذكاء اصطناعي ينجزون عملاً حقيقياً

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

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

متى تحتاج فعلاً إلى وكيل (ومتى لا تحتاج إليه)

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

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

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

تشريح وكيل يصمد في بيئة الإنتاج

تحت الغطاء، يتكوّن الوكيل العامل من عدد قليل من الأجزاء، ويستحق كل جزء منها العناية.

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

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

صمّم أدواتك مثل API يعشقه المطورون

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

قواعد عملية تؤتي ثمارها:

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

اجعل الاستدعاءات الخاطئة رخيصة وقابلة للتراجع

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

ضوابط الأمان هي المنتج، وليست الأوراق الروتينية

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

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

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

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

قائمة تحقق للبناء خطوة بخطوة

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

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

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

التقييم هو ما يفصل الهواية عن المنتج

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

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

مفاضلات التكلفة والموثوقية التي يجب التخطيط لها

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

• وجّه حسب الصعوبة. استخدم نموذجاً قوياً للتخطيط ونموذجاً أرخص للخطوات الآلية.
• خزّن في الذاكرة المؤقتة بقوة. أعِد استخدام prompts النظام والسياق المستقر كي لا تدفع مقابل إعادة إرسال التعليمات نفسها.
• افشل بسرعة. حد الخطوات الصارم يمنع وكيلاً مشوشاً من إنفاق ميزانيتك في حلقة.

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

كيف يمكن لـ Innovation T أن تساعد

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

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

الوكلاء الذين ينتصرون في عام 2026 ليسوا الأكثر بريقاً. بل هم الذين ينهون العمل بهدوء ويبقون داخل الحدود. وهذا بالضبط النوع الذي نحب أن نبنيه.