تحتوي كل خارطة طريق للمنتج على نقطة تقول "AI Agent". تبدو الكلمة وكأنها تعبير عن التقدم، فهي تعطي إشارة للقيادة بأن فريقك يبني المستقبل، وليس مجرد صيانة الحاضر. ولكن إليك الحقيقة المزعجة التي لن تظهرها لك معظم فيديوهات العروض التوضيحية: الـ agent هو الطريقة الأكثر تكلفة والأقل قابلية للتنبؤ لإنجاز المهمة. بالنسبة لغالبية مهام الأعمال، فهو الأداة الخاطئة تماماً. أفضل المهندسين ليسوا أولئك الذين يسارعون لبنائه، بل هم الذين يعرفون متى يتوقفون.
فخ التصنيف
راقب فريقاً يحدد نطاق أول agent له، وسترى عادةً شيئاً كهذا: تصل رسالة بريد إلكتروني للدعم، فيقوم نموذج لغوي كبير (LLM) بقراءة الموضوع والمحتوى، ويقرر ما إذا كان سؤالاً عن الفواتير أو خطأً تقنياً، ثم يضعه في الطابور المناسب. يطلق الفريق على هذا "agent". لكنه ليس كذلك.
ما قاموا ببنائه هو تدفق حتمي (deterministic flow) يحتوي على استدعاء نموذج واحد بداخله. الخطوات ثابتة: استلام البريد، استدعاء النموذج، التوجيه إلى الطابور. لا توجد حلقة تكرارية (loop)، ولا استخدام للأدوات (tool use)، ولا لحظة يتوقف فيها النظام لإعادة النظر في خطته لأن المحاولة الأولى فشلت. هو لا يتصفح قاعدة معرفية، ولا يكتب كوداً، ولا يتحقق من حالة الطلب أثناء التنفيذ. هو يصدر حكماً واحداً ويمضي قدماً. تغليف هذا الاستدعاء الوحيد في خدمة مصغرة (microservice) لا يجعله agent.
التكلفة الحقيقية للخلط بين التدفق والـ agent ليست مجرد البنية التحتية الإضافية، بل هي عدم الحتمية (non-determinism) التي استدعيتها دون أي فائدة. يمكن توجيه نفس البريد الإلكتروني بشكل مختلف صباح الثلاثاء مقارنة ببعد ظهر الأربعاء لأن درجة الحرارة (temperature) ليست صفراً أو لأن المطالبة (prompt) انحرفت. أنت تدفع أسعار الـ agent مقابل زمن الاستجابة (latency)، وتكاليف الرموز (token costs)، وأعباء التقييم، بينما يحل التدفق الذي يحتوي على خطوة تصنيف واحدة المشكلة بشكل أسرع وأرخص.
ابدأ من أسفل السلم
معظم المشكلات لها "أقارب" أبسط يحلونها بنفس الكفاءة. فكر في الأمر كسلم، وابدأ من الأسفل.
أصلح العملية. أحياناً توجد المهمة فقط لأن نظامين غير متوافقين. سجل عميل في نظام CRM الخاص بك لا يتزامن مع منصة التذاكر، لذا يتعين على الإنسان سد الفجوة يدوياً كل صباح. لا تقم بأتمتة هذه الفجوة باستخدام agent. بل قم بإلغائها. إذا كانت قناة البيانات (data pipeline) سليمة، فستختفي المهمة.
استخدم استعلاماً. إذا كان الجواب عبارة عن بحث بسيط أو تجميع بيانات، فتعامل معه على هذا الأساس. "كم عدد عمليات استرداد الأموال التي عالجناها الثلاثاء الماضي؟" لا تحتاج إلى استنتاج (reasoning)، بل تحتاج إلى SQL. يبدو الـ agent الذي يترجم اللغة الطبيعية إلى SQL أنيقاً حتى تدرك أن عبء الصيانة يتجاوز كتابة ثلاثة استعلامات موثقة يشغلها فريقك من لوحة تحكم.
ابنِ تدفقاً حتمياً. عندما تكون القواعد ثابتة والنتيجة قابلة للتكرار، استخدم المنطق الصريح. إذا تجاوزت قيمة الطلب حداً معيناً، فقم بتصعيده إلى القسم المالي. إذا كان المستخدم غير نشط لمدة ثلاثين يوماً، فأرسل بريداً إلكترونياً لإعادة التفاعل. يتعامل الكود مع هذا بتباين صفري وقابلية مراقبة كاملة، ويمكنك إجراء اختبار وحدة (unit-test) له. لا يمكنك إجراء اختبار وحدة لـ "vibe" (شعور).
استخدم تدفقاً باستدعاء نموذج واحد. هنا تكمن مهام التصنيف، أو وسم المشاعر (sentiment tagging)، أو استخراج البيانات. يصدر النموذج حكماً واحداً داخل نص برمجي صارم. تقوم باستلام مستند، واستخراج رقم الفاتورة، وكتابته في قاعدة بيانات. الخطوات المحيطة مبرمجة مسبقاً (hardcoded). النموذج لا يختار ما سيفعله بعد ذلك؛ هو فقط يصنف ما يراه. هذا نمط قوي، لكنه لا يزال مجرد تدفق.
ابنِ الـ agent في النهاية. احتفظ بهذه الخطوة للمهام التي تعتمد فيها الخطوة التالية حقاً على ما يكتشفه النموذج أثناء التشغيل. إذا كان يجب على النظام قراءة بريد إلكتروني، وإدراك أنه بحاجة للبحث عن شحنة في واجهة برمجة تطبيقات (API) لوجستية، واكتشاف أن الشحنة متأخرة، ثم صياغة رد مخصص بناءً على تلك البيانات الجديدة، فأنت هنا في منطقة الـ agent. لا يمكن رسم المسار مسبقاً لأن النموذج يقرر ما سيفعله بعد كل حقيقة جديدة.
اختبار السبورة البيضاء
هناك طريقة سريعة لحسم الجدل في الاجتماعات. اطلب من فريقك رسم فروع القرار على سبورة بيضاء.
إذا كان بإمكانك رسم كل مسار قبل تشغيل النموذج، فابنِ تدفقاً. ارسم الأشكال المعينة، واكتب جمل الشرط (if-statements)، وانتهِ من الأمر. القدرة على التنبؤ هي ميزة وليست عائقاً.
أما إذا كان على النموذج نفسه أن يقرر ما هي الخطوة التالية، وإذا كان هو من يختار الأداة، ويحدد المعايير، ويعود للتفكير مجدداً، فأنت بحاجة إلى agent. هذا التوجيه الديناميكي هو الخط الفاصل. لا تتجاوزه بالصدفة لمجرد أنك أردت استخدام API جديد.
الضريبة الخفية
تجعل العروض التوضيحية الـ agents تبدو سلسة وبدون عوائق. لكن الواقع في بيئة الإنتاج يكشف عن أربع ضرائب تتراكم بسرعة.
عدم الحتمية. نفس الـ