Z.AI أظهرت كيفية بناء أنظمة agentic جاهزة للإنتاج على GLM-5 باستخدام tool calling

نشرت Z.AI تحليلاً تقنياً نادراً في فائدته، حيث يتم تقديم GLM-5 ليس كواجهة دردشة أخرى، بل كأساس لأنظمة وكلاء جاهزة للإنتاج. يتابع المادة بشكل منهجي المسار من أول طلب للنموذج إلى وكيل متعدد الخطوات كامل مع استدعاء الأدوات، والإخراج المتدفق، وضع التفكير، ودعم الحوار متعدد الأدوار.

بالنسبة للمطورين، هذه إشارة مهمة: الرهان يتم على جودة الإجابات فحسب، بل أيضاً على نضج التكامل في كومة منتج حقيقية. في البداية، يعد المؤلفون بيئة أساسية من خلال zai-sdk و openai و rich، ويحصلون على مفتاح API من متغيرات البيئة أو من خلال إدخال مخفي في الطرفية، وينطلقون ZaiClient للاستدعاءات الأولى للنموذج. بعد ذلك، يتم عرض سيناريو بسيط لإكمال الدردشة: يجيب GLM-5 على سؤال تقني بسيط، وبعده يتم استخدام نفس الواجهة في وضع البث، حيث تصل الرموز أثناء توليدها.

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

في المثال الخاص بـ GLM-5، يتم تمكين التفكير بوضوح باستخدام معامل enabled، وفي الاستجابة المتدفقة، يتم قراءة reasoning_content بشكل منفصل، متبوعاً بالإجابة النهائية للنموذج. بعد ذلك، ينشئ المؤلفون سلسلة من عدة رسائل: أولاً يسألون عن الفرق بين list و tuple في Python، ثم يوضحون متى يكون NamedTuple مناسباً، وأخيراً يطلبون مثالاً عملياً مع type hints. النقطة في هذا القسم ليست الأسئلة نفسها، بل إظهار أن النموذج يحتفظ بالسياق بين الأدوار، وأن المطور يمكنه تتبع نمو سجل الرسائل واستهلاك الرموز.

بالنسبة لأنظمة الوكلاء، هذا متطلب أساسي: بدون ذاكرة حوار مستقرة، تنهار السلاسل المعقدة بسرعة. يبدأ الجزء الأكثر عملية حيث يتم توصيل GLM-5 بالدوال الخارجية. يصف البرنامج التعليمي أداتين: البحث عن الطقس وآلة حاسبة لتقييم آمن للتعبيرات.

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

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

في مثال منفصل، يقارن المؤلفون كيفية عمل مشكلة منطقية صعبة مع تمكين وتعطيل وضع التفكير، قياس وقت الاستجابة وحجم الرموز المولدة. وفي الختام، يوضحون أن GLM-5 يمكن استخدامه أيضاً من خلال SDK Python OpenAI القياسي: يكفي تغيير base_url، والواجهة المألوفة chat.completions تستمر في العمل.

وفقاً للتوثيق الرسمي لـ Z.AI، يتمتع GLM-5 بسياق يصل إلى 200K رموز وحد أقصى 128K رموز للإخراج، مما يجعل هذا السيناريو مثيراً للاهتمام بشكل خاص للمهام متعددة الخطوات الطويلة. ماذا يعني هذا عملياً؟ تحاول Z.

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

لكن كخريطة لقدرات GLM-5، هذه المادة مفيدة: فهي تظهر أن نموذج Z.AI معبأ بالفعل ليس فقط كـ LLM للدردشة، بل كعنصر بناء لوكلاء ذكاء اصطناعي مطبقة.