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

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

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

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

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

أما القسم التقني الأخير فيجمع كل ذلك في الصنف GLM5Agent. يُضاف إليه عدة أدوات دفعة واحدة: الطقس، والآلة الحاسبة، والوقت الحالي، وتحويل الوحدات. يعمل الوكيل بشكل تكراري، ويستدعي الدوال اللازمة بنفسه أثناء حل المهمة، ويواصل الحلقة حتى يحصل على الجواب النهائي أو يبلغ حدّ عدد الخطوات. وفي مثال منفصل يقارن المؤلفون أداء النموذج في مسألة منطقية مخادعة مع تفعيل وضع التفكير وإيقافه، مع قياس زمن الاستجابة وحجم الرموز المولَّدة. وفي الختام يوضحون أنه يمكن استخدام GLM-5 عبر OpenAI Python SDK القياسي أيضًا: يكفي تغيير base_url ليواصل المعتاد chat.completions العمل. ووفق الوثائق الرسمية لـ Z.AI، يبلغ سياق GLM-5 حتى 200K رمز، مع حد أقصى 128K رمز في المخرجات، مما يجعل هذا السيناريو مثيرًا للاهتمام خصوصًا للمهام الطويلة متعددة الخطوات.

ما الذي يعنيه ذلك عمليًا؟ تحاول Z.AI خفض عتبة الانتقال للفرق التي لديها شيفرة متوافقة مع OpenAI، لكنها تحتاج إلى سير عمل وكيلي (agentic workflow) أوضح: أدوات، وJSON، وبث مباشر، وذاكرة حوار، وحلقات تنفيذ قابلة للتحكم. ومن المهم أن الدليل لا يغرق في التجريد، بل يعرض الحد الأدنى من المنظومة العاملة حول النموذج. ومع ذلك، لا ينبغي الوقوع في الأوهام: فمثالا الطقس والآلة الحاسبة يبقيان تعليميين، وسيظل الإنتاج بحاجة إلى المصادقة والتسجيل (logging) وإعادة المحاولة (retries) وقيود على الأدوات وحماية من الاستدعاءات غير الآمنة. لكن بوصفه خريطة لإمكانات GLM-5، فهذا المحتوى مفيد: إذ يُظهر أن نموذج Z.AI بات يُقدَّم لا كمجرد LLM للمحادثة، بل كلبنة بناء لوكلاء الذكاء الاصطناعي التطبيقيين.