نطاق مهم قبل البدء

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

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

لذلك يركز هذا الشرح على بنية معمارية بدلاً من الادعاء بدعم SDK أو نموذج أو مزود طقس أو إصدار إطار عمل أو عقد endpoint محدد. قبل تنفيذ أي كود، تحقق من وثائق المزودين الحالية لإصدار Next.js الذي اخترته، وOpenAI API، ومزود بيانات الطقس، ونظام المصادقة، وبيئة النشر، والمتطلبات التنظيمية المعمول بها.

ما الذي تصممه

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

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

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

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

الخطوة ١: اكتب سياسات ملموسة أولاً

لا تبدأ بـPrompt عام مثل «ساعد المستخدمين في أمور الطقس». ابدأ بسياسة يمكن للمهندس تنفيذها واختبارها. وهذا مهم لأن أبحاث الحواجز الوقائية الرمزية الموثقة وجدت أن ٨٥٪ من معايير سلامة وأمن الوكلاء التي تمت مراجعتها تفتقر إلى سياسات ملموسة. الأهداف عالية المستوى والحس السليم ليسا دقيقين بما يكفي لفرض موثوق.

بالنسبة إلى مساعد طقس للقراءة فقط، يمكن أن تنص سياسة عملية على ما يلي:

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

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

الخطوة ٢: حدّد قدرة طقس ضيقة النطاق

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

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

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

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

الخطوة ٣: أنشئ حلقة وكيل يملكها الخادم

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

تتبع الحلقة الآمنة هذا التسلسل:

1. تحقق من الطلب الوارد: حدّ من عدد الرسائل، وقيم الأدوار، وطول الأحرف، والحجم الإجمالي للطلب.
2. أضف تعليمات يتحكم بها الخادم تصف دور المساعد ومتطلب استخدام الأدوات المعتمدة للادعاءات الواقعية عن الطقس.
3. اطلب من النموذج استجابة مع إتاحة قدرة الطقس المعتمدة فقط.
4. إذا أعاد النموذج نصاً عادياً ولم تكن هناك حاجة إلى بيانات طقس واقعية، فأعد النص بعد تطبيق سياسة الاستجابة لديك.
5. إذا طلب قدرة الطقس المعتمدة، فحلل الوسائط المقترحة بحذر وتحقق منها مقابل Schema الخادم.
6. نفّذ التطبيق الثابت على الخادم فقط عندما يجتاز اسم القدرة والوسائط السياسة.
7. وحّد نتيجة المزود وتحقق منها قبل إتاحتها للنموذج.
8. أعد النتيجة المتحقق منها إلى النموذج بوصفها بيانات، ثم اطلب إجابة نهائية موجهة للمستخدم.
9. توقف عندما يحصل المساعد على إجابة أو عند استنفاد ميزانية التنفيذ المضبوطة.

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

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

الخطوة ٤: تحقق قبل الإبلاغ عن النتيجة

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

يجب أن يتحقق المدقق لديك من الشروط التالية على الأقل:

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

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

الخطوة ٥: اجعل الواجهة صادقة بشأن الاسترجاع الحي

يجب أن تعكس تجربة المستخدم الحالة الفعلية للنظام. أثناء استرجاع الخادم للبيانات والتحقق منها، اعرض حالة تحميل مثل «جارٍ التحقق من بيانات التوقعات». عطّل عمليات الإرسال المكررة لمحادثة واحدة مرتبة، أو نفّذ عمداً معرّفات للطلبات وقواعد للمطابقة إذا كان منتجك يدعم الأسئلة المتوازية.

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

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

الخطوة ٦: اختبر الثوابت لا صياغة النموذج

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

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

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

قائمة التحقق قبل النشر

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

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

الخلاصة الأساسية

لا يُعرّف وكيل طقس موثوق مبني على Next.js وOpenAI بصندوق محادثة أو باستدعاء أداة واحد. بل يعرّفه سير عمل مرتكز إلى الحلول: تنتج الأدوات الموثوقة قيماً واقعية، وتتحقق الفحوصات الصريحة من تلك القيم، ويشرح النموذج اللغوي فقط ما يسمح له سير العمل المتحقق منه بشرحه. يمنح هذا النمط الفرق نقطة انطلاق متينة لتجارب الطقس ولتطبيقات الوكلاء الأكثر حساسية.

المصادر: LLMs and Agentic AI Systems for Smart Grids: A Tutorial on Architectures and Applications؛ Symbolic Guardrails for Domain-Specific Agents.