تمكنت Forter من إشراك نحو 200 شخص في بناء وكلاء ذكاء اصطناعي خلال سباق عملي استمر أسبوعين، بعدما صممت بيئة تقلل الحاجة إلى الخبرة البرمجية وتتيح للمحللين والمهندسين تجربة أفكارهم بسرعة. ويعرض Ben Maraney، المهندس الرئيسي في الشركة، التجربة بوصفها درساً في إزالة التعقيد غير الضروري بدلاً من محاولة حل جميع تحديات بناء الوكلاء دفعة واحدة.
البداية: سباق عملي بمهلة خمسة أسابيع
كان الهدف تدريب فرق البحث والتطوير على إنشاء وكلائها، بما في ذلك محللون من خلفيات قانونية ونفسية وعلمية لم يسبق لبعضهم كتابة SQL. احتاج الفريق إلى تجهيز البيئة خلال خمسة أسابيع، ثم تشغيل سباق بناء مدته أسبوعان. لذلك ركز التصميم على ثلاثة محاور: الأدوات، والمنصات، وإزالة العوائق أمام المستخدمين.
خادم MCP مركزي بدلاً من أدوات مبعثرة
اعتمدت Forter على خادم داخلي قائم على بروتوكول MCP أطلقت عليه Toolchain. وفر الخادم واجهة واحدة لاكتشاف الأدوات وتجربتها وإنشاء الاتصالات الخاصة بكل وكيل. كما أتاح للمستخدم اختيار الأدوات التي يحتاجها الوكيل فقط، بدلاً من منحه وصولاً واسعاً قد يربكه أو يقوده إلى استخدام أدوات غير مناسبة.
نما عدد الأدوات من نحو 20 عند تأسيس الفريق إلى قرابة 60 عند بدء السباق، ثم إلى ما يقارب 100 بعد انتهائه بأسبوعين. وساعد توحيد المستودع ووجود أمثلة وملفات إعداد واضحة على إضافة أدوات جديدة بسرعة، مع توفير إمكانات حوكمة مثل مراقبة استهلاك الرموز واستخدام الأدوات.
بدلاً من بناء نظام بحث معزز بالاسترجاع (RAG) مخصص خلال فترة قصيرة، ربطت الشركة Toolchain بمنصة Glean المستخدمة للبحث في مصادر داخلية مثل Confluence وAsana وJira وSlack وSalesforce. وأتاحت ثلاثة أنواع من الأدوات: البحث عن المستندات والمقاطع ذات الصلة، قراءة المستند كاملاً، وتلخيصه وفق سؤال أو محور يحدده الوكيل.
منصة بلا برمجة إلى حلول قابلة للتخصيص
استخدمت Forter LibreChat لتوفير تجربة محادثة سريعة وقليلة البرمجة. وتمكن المستخدمون من رؤية الأدوات التي استدعاها الوكيل، والاستعلامات والمعاملات التي أرسلها، والنتائج التي تلقاها. ساعد ذلك على فهم سلوك الوكلاء واكتشاف المشكلات مبكراً، رغم أن تكامل MCP كان غير مستقر أحياناً، مع محدودية التحكم في الإصدارات والتخصيص.
للحالات الأكثر تعقيداً، وفرت الشركة مستودعات نموذجية تمنح المطورين التحكم الكامل في الشيفرة، وإضافة الأدوات والوكلاء الفرعيين، لكنها كانت أبطأ في الإعداد والنشر، خصوصاً للمحللين. لاحقاً أنشأت Forter واجهة داخلية باسم AI Hub تتيح اختيار النموذج، وكتابة رسالة النظام، وتحديد الأدوات، ثم مشاركة الوكيل خلال خطوات قليلة.
أما الوكلاء غير التفاعليين، فاستُخدم إطار Strands مع Argo Workflows لتشغيلهم وفق جداول زمنية أو أحداث مثل إنشاء تذاكر Jira وAsana. ويشير Maraney إلى أن وجود نظام جدولة وتشغيل قائم قد يلغي الحاجة إلى بنية جديدة خاصة بالوكلاء.
ما الذي بُني فعلياً؟
شملت الاستخدامات وكلاء يساعدون المحللين على صياغة فرضيات وتجارب أفضل، ويراجعون تقارير ما بعد الحوادث، ويحللون تراجع أداء التجار باستخدام Snowflake ودفاتر Databricks. كما طورت الشركة وكلاء خبراء مثل Layla وPenny للوصول إلى الشيفرة والإعدادات والبيانات، والإجابة عن أسئلة تتعلق بقرارات المعاملات والفوترة. وامتد استخدام Layla إلى فرق نجاح العملاء والدعم بعدما أصبحت معرفتها بالنظام أوسع من معرفة أي فرد منفرد.
ومن أمثلة الوكلاء غير التفاعليين اقتراح إعدادات أولية لتاجر جديد اعتماداً على تجار مشابهين، وتجهيز أبحاث أولية عند وصول تذكرة دعم، وتحليل تنبيهات الحالات الشاذة وربطها بتغييرات الشيفرة. كما اختبرت Forter وكيلاً للاستجابة للحوادث، لكنها اكتشفت أن نتائجه الممتازة ظاهرياً كانت تعتمد أساساً على نسخ تحليل سبب جذري كتبه البشر سابقاً في تقارير BetterNext.
ما الذي يتغير عملياً؟
توضح هذه التجربة أن قابلية المراقبة ليست ميزة ثانوية. فإظهار الأدوات والمعاملات والنتائج التي يعتمد عليها الوكيل كان ضرورياً لاكتشاف أن وكيل الاستجابة للحوادث لم يكن يستنتج السبب الجذري فعلياً. ولهذا أضافت Forter لاحقاً Langfuse لتتبع جلسات الوكلاء واستدعاءات الأدوات ومسار العمل.
كما تبيّن التجربة أن تعدد المنصات قد يكون مقصوداً: منصة بلا برمجة للتجربة السريعة، وحلول برمجية للتخصيص، ووكلاء يعملون بالأحداث أو الجداول. في المقابل، واجهت الشركة مشكلات في نموذج إنشاء مستودع منفصل لكل وكيل، ثم عادت إلى عدد أقل من المستودعات التي تضم وكلاء مرتبطين، لتسهيل إدخال قدرات مشتركة مثل التتبع.
ينبه Maraney أيضاً إلى أن مقاييس التقييم العامة مثل الملاءمة والترابط والسلامة قد تمنح انطباعاً زائفاً بالجودة. فالتقييم المفيد يجب أن يختبر صحة الإجابة، واستخدام الأدوات المناسبة، واسترجاع السياق الصحيح، وهي أمور أصعب وتتطلب معرفة دقيقة بما تعنيه الإجابة الجيدة. لذلك يمكن تأجيل التقييمات المتقدمة في التجارب الداخلية التي يبقى فيها الإنسان ضمن حلقة اتخاذ القرار، لكن لا ينبغي اعتبار ذلك بديلاً دائماً عن التقييم.
وتحتاج مبادرات التوسع كذلك إلى إشراك الفرق القانونية والأمنية مبكراً، خصوصاً بشأن مكان معالجة البيانات والاحتفاظ بها. ويذكر Maraney أن استخدام خدمة سحابية مثل Amazon Bedrock، مع توثيق سياسات عدم الاحتفاظ بالبيانات، ساعد على التعامل مع هذه المخاوف ضمن ضوابط المؤسسة بدلاً من تحويل كل وكيل إلى حالة موافقة منفصلة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.