وكيل قائم على LLM: كيف حلّت حلقة من النموذج والأدوات محل روبوت الدردشة

تحدد ثلاثة تواريخ ملامح وكيل LLM الحديث: عام 2022 الذي صدرت فيه الورقة البحثية عن نهج ReAct، ويونيو 2023 الذي أضافت فيه OpenAI استدعاء الدوال إلى API، ونوفمبر 2024 الذي قدّمت فيه Anthropic بروتوكول MCP لربط الأدوات. نُشرت على Habr مادة تشرح بنية الوكيل المبني فوق LLM. يوضح الكاتب منذ البداية أنه لن يناقش بنية المحولات (transformers)، وينظر إلى النظام من الجانب التطبيقي. لا يتوفر في إعلان RSS سوى المقدمة، لذا نعرض أدناه المخطط العام الذي يقوم عليه معظم الوكلاء، دون إعادة سرد تفاصيل المقال نفسه.

حلقة بدلًا من إجابة واحدة

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

ولا ينفّذ النموذج نفسه أي شيء في هذه العملية. فهو يُصدر طلبًا منظّمًا، مثل اسم الدالة ووسائطها بصيغة JSON. وينفّذ هذا الطلب برنامج عادي يسمى المنسّق (orchestrator) أو بيئة التشغيل (runtime). وفي هذا البرنامج تحديدًا يوجد منطق إعادة المحاولة والمهلات الزمنية والقيود.

مكونات الوكيل

تتشابه مجموعة المكونات في معظم التطبيقات، سواء كانت كودًا مكتوبًا يدويًا أو إطار عمل جاهزًا:

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

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

أين يتعطل الوكلاء

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

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

كيف تبني وكيلك

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