بنية وكلاء الذكاء الاصطناعي وتصميم الأنظمة

أنماط البنية الأساسية

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

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

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

مشهد أطر العمل

نعمل عبر الجيل الحالي من أطر عمل الوكلاء بدلاً من الالتزام بواحد بغض النظر عن الملاءمة. LangChain يبقى أوسع مجموعة أدوات عامة الغرض لربط استدعاءات النموذج اللغوي والأدوات معاً. LangGraph، المبني فوقه، أنسب لسير العمل الذي يحتاج آلات حالة صريحة وتفكيراً دورياً بدلاً من سلسلة خطية. CrewAI مبني خصيصاً لـ"طواقم" متعددة الوكلاء بأدوار محددة، مفيد عندما يكون نمط التنسيق نفسه، لا منطق الوكيل الفردي فقط، هو الجزء الصعب. AutoGen يركز على أنماط محادثة متعددة الوكلاء، وكلاء يتحدثون مع بعضهم لحل مشكلة بشكل تعاوني.

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

اختيار النموذج اللغوي

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

إدارة سير العمل والحالة

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

الأمن

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

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

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

الحوكمة

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

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

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