الجميع مهووسون بصياغة الأوامر (prompts). يقومون بضبط التحية، وتعديل النبرة، والقلق بشأن ما إذا كان النموذج يبدو ودوداً بما يكفي. هذا مجرد تشتيت للانتباه. فعندما يبدأ وكيل الذكاء الاصطناعي (AI agent) في إرسال رسائل بريد إلكتروني حقيقية إلى مستخدمين حقيقيين، لا يكمن الخطر في كتابته "مع أطيب التحيات" بدلاً من "تحياتي". الخطر الحقيقي هو عدم قدرتك على معرفة ما حدث بيقين بين اتخاذ الوكيل للقرار ووصول الرسالة إلى صندوق الوارد. أنا أنظر إلى الحدود الفاصلة أولاً؛ فهناك حيث تموت أنظمة الإنتاج في صمت.
العقد هو نقطة الضعف
العروض التجريبية للذكاء الاصطناعي متسامحة. فالمحادثة السلسة في نافذة المتصفح تخفي وراءها فوضى من الافتراضات. أما في بيئة الإنتاج، فإن الثغرة الحقيقية تكمن في "العقد" القائم بين ثلاثة أشياء: قرار الوكيل، والأداة التي تنفذ الإجراء، والخطوة التي تتحقق من النتيجة. إذا كانت هذه الحدود ضبابية، سيعمل النظام بشكل رائع حتى اللحظة التي يتوقف فيها عن ذلك. عندها سيفشل بصمت، أو يرسل رسائل مكررة إلى شريحة كاملة من العملاء، أو يطلق رسائل في الوقت الخطأ دون سجل واضح للسبب. قد تبدو الأوامر (the prompt) كأنها قصيدة شعرية، لكن البنية التحتية التي تقوم عليها قد تظل متهالكة ومترابطة بخيوط واهية.
توقف عن ترك الوكيل يكتب بحرية
الخطأ الأكثر شيوعاً هو إعطاء الوكيل صفحة بيضاء. تترك الفرق للوكيل وصف رسالة البريد الإلكتروني كنص خام، ثم تثق في أداة لاحقة في النظام لتحليل القصد من هذا النثر. هذا نهج هش. قد يقترح نموذج اللغة الكبير (LLM) قصداً معقولاً، لكن بنيتك التحتية لا تحتاج إلى الإبداع، بل تحتاج إلى "عقد". تحتاج إلى حقول محددة يمكن للآلة التحقق من صحتها دون غموض.
عندما يصدر الوكيل طلباً لإرسال بريد إلكتروني، يجب أن تحمل المخرجات بالضبط ما تتطلبه العمليات التقنية:
- إصدار القالب (Template version): أي إصدار من نص البريد الإلكتروني يتم استخدامه، لتعرف ما الذي رآه المستخدم بالضبط.
- نطاق المستلم (Recipient scope): من سيتلقى هذه الرسالة، ويتم تحديده عبر معرفات المستخدمين (user IDs) أو قواعد الشرائح، وليس عبر لغة طبيعية مثل "المستخدم الذي سجل للتو".
- معرف التتبع (Trace ID): معرف فريد يتبع هذا الطلب من الوكيل عبر المنفذ (executor)، وصولاً إلى مزود خدمة البريد الإلكتروني، ثم إلى سجلاتك (logs).
- النافذة الزمنية (Time window): متى يكون هذا الإرسال صالحاً، حتى لا تؤدي قرارات الوكيل القديمة إلى إرسال رسائل في منتصف الليل بعد ساعات من اتخاذ القرار.
- خاصية التكرار المتماثل (Idempotency): مفتاح يمنع إرسال نفس العملية المنطقية مرتين في حال حاول الوكيل إعادة المحاولة أو حدث خلل في الشبكة.
النص الخام هو واجهة برمجة تطبيقات (API) سيئة للغاية؛ فهو يترك مجالاً للغموض بشأن الاستعجال، والجمهور المستهدف، والإجراء المطلوب. أما الحقول المحددة فهي قابلة للقراءة آلياً، وقابلة للتدقيق، وقابلة للاختبار. إنها تحول التعليمات الغامضة إلى أمر يمكن التحقق منه.
أفعال، لا نثراً
بدلاً من تسليم الوكيل مهمة كتابة مفتوحة، قم بتقييده بقائمة من الأفعال المسموح بها. فكر في الأمر كواجهة برمجة تطبيقات داخلية ذات تعداد (enum) ثابت. لا يقوم الوكيل بصياغة سطر الموضوع أو التفكير في التحيات، بل يختار إجراءً مثل send_review_request أو send_retry_notice. هذا هو أقصى حد لحريته الإبداعية.
بعد ذلك، يقوم منفذ حتمي (deterministic executor) بأخذ مفتاح الإجراء هذا، ويسحب القالب الصحيح من نظام التحكم في الإصدارات، ويملؤه ببيانات منقاة، ويجهز قائمة المستلمين من مصدر موثوق، ويبني الأمر النهائي. الوكيل يقرر ما الذي يجب أن يحدث، بينما يقرر الكود الممل والمتوقع كيفية حدوث ذلك.
هذا الفصل يجعل النظام سهلاً للاختبار. يمكنك التحقق من أن حالة إدخال معينة تؤدي بشكل موثوق إلى تفعيل send_retry_notice دون الحاجة إلى تشغيل استدلال نموذج اللغة الكبير (LLM) على الإطلاق. ستصبح اختبارات الوحدة (unit tests) لديك سريعة وحتمية لأنها تفحص منطق الربط، وليس درجة حرارة النموذج (model temperature). وستركز اختبارات التكامل (integration tests) على ما إذا كان المنفذ يربط الإجراء بشكل صحيح بخدمة البريد الإلكتروني، وليس ما إذا كان النموذج في حالة مزاجية جيدة.
البناء في خمس طبقات
النظام القوي لا ينبثق من أمر واحد (prompt)، بل يُبنى في طبقات، وكل طبقة تمتلك مسؤولية واحدة واضحة.
1. يقوم الجزء الخلفي (backend) باختزال الحدث إلى بيانات آمنة.
سواء كان المحفز هو "ويب هوك" (webhook)، أو تغييراً في قاعدة البيانات، أو وظيفة مجدولة، تقوم هذه الطبقة بتنقية المدخلات، وإزالة الحقول غير المتوقعة، وتسليم الوكيل فقط ما يحتاجه. إذا كانت حمولة الـ webhook تحتوي على عشرين حقلاً بينما يحتاج الوكيل إلى اثنين فقط، فقم بتمرير الاثنين فقط. لا ينبغي لأي نص خام من المستخدم أن يصل إلى طبقة اتخاذ القرار دون فحص.
2. يختار الوكيل إجراءً من المخطط (schema) الثابت.
يرى الوكيل السياق، ويتخذ قراراً، ويخرج أحد مفاتيح الإجراءات المحددة مسبقاً مع البيانات الوصفية (metadata) المطلوبة. هو لا يصيغ نثراً، ولا يخمن المستلمين، بل يعيد حمولة (payload) مهيكلة يمكن للطبقة التالية التحقق من صحتها مقابل مخطط JSON.
3. تقوم الأداة بالتحقق من الأذونات والحقول المطلوبة.
هل يمتلك سياق هذا الوكيل (agent context) الحق في تشغيل send_review_request لهذا المستخدم؟ هل نطاق المستلم غير فارغ وضمن الحدود المسموح بها؟ هل مفتاح التكرارية (idempotency key) موجود وفريد في سجلاتك؟ هل معرف التتبع (trace ID) منسق بشكل صحيح؟ افشل هنا، وبشكل صريح، قبل المساس بأي خدمة بريد إلكتروني.
4. تقوم خدمة البريد الإلكتروني بتسجيل عملية الإرسال مع معرف تتبع (trace ID).
يجب أن تحمل كل رسالة تغادر نظامك معرف التتبع هذا عبر واجهة برمجة تطبيقات (API) المزود وصولاً إلى حزمة المراقبة (observability stack) الخاصة بك. إذا اشتكى مستخدم من استلام نسختين، فيجب أن تكون قادرًا على الاستعلام عن معرف واحد ومعرفة مصدر التكرار بالضبط: هل هو استدعاء معاد للوكيل، أم منفذ (executor) غير مستقر، أم استدعاء رد (callback) غير منضبط؟
5. يتحقق اختبار الطرف إلى الطرف (end-to-end test) من صندوق الوارد الفعلي من حيث المحتوى والتأثير.
افتح الرسالة المعروضة في صندوق بريد حقيقي. هل تم ملء سطر الموضوع بشكل صحيح؟ هل يعمل رابط إلغاء الاشتراك؟ هل يؤدي النقر على زر الإجراء الرئيسي (call-to-action) إلى الصفحة الصحيحة مع حالة المستخدم الصحيحة؟ نجاح اختبار الوحدة (unit test) يعني أن الكود قد تم تشغيله، ولكن اختبار صندوق الوارد هو الوحيد الذي يخبرك بأن البريد الإلكتروني يعمل فعليًا بالنسبة للبشر.
الأدلة بدلاً من التخمين
عندما يفشل اختبار في هذا المسار (pipeline)، فأنت بحاجة إلى أربعة أدلة محددة. لا تقبل بأقل من ذلك.
- القرار الأصلي من الوكيل (agent). ما هو الإجراء الذي اختاره، وما هو سياق المدخلات الكامل؟
- الأمر الموحد (normalized command) من الأداة. ماذا بنى المنفذ الحتمي (deterministic executor) بعد تطبيق القالب، ومنطق التزويد بالبيانات (hydration logic)، وقواعد التحقق؟
- الرسالة في صندوق الوارد المعزول. ليس مجرد سجل لما تعتقد أنك أرسلته، بل رسالة MIME الحقيقية، مع كافة الرؤوس (headers) وكل شيء، كما تم التقاطها في صندوق بريد مخصص للاختبار.
- التأثير النهائي بعد النقر على الرابط. حالة الصفحة الناتجة، أو التغيير في قاعدة البيانات، أو الحدث الخارجي الذي يثبت أن البريد الإلكتروني قد حقق غرضه.
إذا فُقد جزء واحد، فسيقوم فريقك بملء الفجوة بالافتراضات. سوف يخمنون. التخمين في الأتمتة مكلف؛ فهو يهدر الساعات، ويقوض الثقة، ويحول كل حادثة إلى لغز جنائي بدلاً من