٧ دروس من بناء وكيل دردشة بالذكاء الاصطناعي: تجربة مهندسي Trigger.dev

بنى مهندو Trigger.dev وكيل دردشة للوحة تحكم منتجهم: يساعد في تشخيص المهام الفاشلة، ويرسم المخططات من البيانات، ويبحث في الوثائق. وبعد أشهر من التشغيل الفعلي نشروا في مدونتهم مراجعة صريحة بعنوان «سبعة أشياء تمنّينا معرفتها قبل بناء وكيل الدردشة»، مع روابط إلى الكود الحقيقي. في هذا المقال نعيد سرد الدروس السبعة بالعربية: من «أول رد يجب أن يصل بسرعة» إلى التقييم الآلي للإجابات عبر نموذج حَكَم. المصدر الأصلي: 7 things we wish we'd known before building an AI chat agent.

أول رد يصل فورًا، حتى لو لم يجهز الوكيل بعد

إذا كان الوكيل يقوم بعمل حقيقي (تشغيل أدوات، قراءة ملفات، إقامة بيئة معزولة) فهو لا يبدأ في لحظة. لكن المستخدم الذي يحدّق في شاشة تحميل فارغة سيظن أن كل شيء تعطّل. حلّ Trigger.dev: تقسيم الرد إلى مرحلتين — أول استدعاء للنموذج يخرج مباشرة من معالج الطلب ويُبَثّ للمستخدم فورًا، بينما يُقلَع الوكيل الثقيل بالتوازي في الخلفية. أول رد يكون عادةً استدعاء أداة، وهذا وحده يُظهر للإنسان أن العملية حيّة: يرى الوكيل يستدعي get_run("abc123") قبل أن يجهز الوكيل نفسه.

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

ولماذا هذا مهم؟ تُجيب أرقامنا: على 4912 عملية توليد صورة مكتملة خلال 14 يومًا (1–14 أكتوبر 2026، قاعدة بيانات الخدمة) كان الوسيط من بدء الطلب حتى الملف الجاهز 78 ثانية، والنسبة المئوية 95 بلغت 236 ثانية. لو بقيت الواجهة صامتة طوال هذا الوقت لظن نصف المستخدمين أن النظام معلّق. أظهِر التقدم، حتى لو كان مجرد «أستدعي الأداة الآن».

احسب التوكنات بدقة — وإلا سيعمل ضغط المحادثة بلا داعٍ

المحادثات الطويلة تُضغط: تُلخَّص وتُقصّ لتدخل في نافذة السياق. ولا ينبغي أن يحدث هذا إلا إذا كانت المحادثة طويلة فعلًا، وهذا يتطلب عدًّا دقيقًا للتوكنات. النسخة الأولى عند Trigger.dev كانت تجمع توكنات الإدخال لكل خطوة — لكن كل خطوة تتضمن أصلًا كل المحادثة السابقة. النتيجة: سؤال واحد بخمس استدعاءات أدوات حُسب على أنه 178,926 توكن إدخال بينما الحقيقي 39,557، فبدأ الضغط قبل الحاجة بوقت طويل. العلاج بسيط: خذ توكنات الإدخال للخطوة الأخيرة فقط — كل ما أخرجه النموذج سابقًا يصبح إدخالًا في الخطوة التالية أصلًا.

ضع حدًّا للمحاولات — فالنموذج سيضرب الأداة الفاشلة بلا توقف

إذا فشل استدعاء أداة، فسيجرب النموذج مرة أخرى على الأرجح. ثم مرة. ثم مرة. عُدّ الإخفاقات المتتالية وضع حدًّا أقصى، وداخل الأداة نفسها: انقطاعات الشبكة لا تُحتسب — الأداة تعيد المحاولة بنفسها مع backoff قصير. في تطبيق Trigger.dev، بعد ثلاثة استعلامات فاشلة متتالية لا يتلقى الوكيل خطأً جديدًا بل رسالة واضحة: «بلغنا الحد، أجب بما لديك».

وبالمناسبة عن المحاولات: على 5301 عملية توليد صورة في خدمتنا خلال الأيام الأربعة عشر نفسها، احتاجت 89 عملية فقط إلى إعادة محاولة — أي 1.7% من الطلبات. النماذج لا تضرب الأداة الساقطة إلى الأبد إذا قلت لها صراحةً «توقف».

المحادثة يجب أن تنجو من انقطاع الاتصال

الاتصال ينقطع لأسباب كثيرة، والتنفيذ الساذج بعد إعادة الاتصال يُظهر ردًا «يتولّد» إلى الأبد. الحل: امنح كل حدث في البثّ معرّفًا؛ عند إعادة الاتصال يقول العميل «آخر جزء عندي هو 43»، فيعيد الخادم كل شيء من 44 وما بعده ثم يكمل البثّ مباشرة. لهذا لا يكفي أن يكون الرد مجرد استجابة HTTP — تحتاج حالة دائمة (عندهم فوق تخزين الكائنات، وهناك مكتبات جاهزة فوق Redis مثل resumable-stream).

كما ينصحون بإظهار استدعاءات الأدوات أثناء حدوثها — جمهورهم مطورون ويقدّرون ذلك. والوجه الآخر: رسائل المستخدم الواردة تُكتَب في صندوق وارد دائم مرتَّب. يفحص الوكيل الصندوق بين الخطوات (رسالة «توجيه» تدخل في الدور الحالي) وبين الأدوار (الأقدم يُدرج في الطابور للدور التالي). في Claude Code هذا الفرق بين Enter وCtrl+Enter.

ترقيم إصدارات البرومبتات ممل، لكنه ضروري

البرومبت كود، ويجب أن تكون التعديلات عليه رخيصة، وإلا ستُجري تعديلات أقل مما ينبغي. نظام Trigger.dev: البرومبت معرَّف في الكود، كل إصدار يُحفظ، والتبديل إلى إصدار جديد يتم من لوحة التحكم دون نشر جديد. كل إصدار موسوم بالنموذج — فترى فورًا إذا كان نموذج معيّن يولّد إجابات سيئة كثيرًا. وبدمج هذا مع التقييم الآلي تتحول هندسة البرومبتات من شعوذة إلى عمل قابل للقياس.

أدوات مصممة للوكيل لا للإنسان

هذه قائمة نصائح قصيرة لكنها دقيقة:

• أظهر للأداة حدودها: إذا كانت النتائج تُقتطع، فيجب أن يكون ذلك واضحًا في الوصف وفي استجابة الـAPI نفسها.
• دع الوكيل يرسم: أداة render_view ببطاقات الأخطاء والمخططات وزر «الخطوات التالية» ثبت أنها مطلوبة بشكل غير متوقع.
• امنحه أداة تغذية راجعة — نقطة API عادية يرسل إليها الوكيل تقريرًا. حلقة التصحيح تقصر كثيرًا.
• امنحه سياق المستخدم: أداة get_current_page («ما الذي يشاهده المستخدم الآن») مكلفة لكنها تعوّض سريعًا.
• الوكلاء الفرعيون يوازون المهام ولا ينفخون سياق الوكيل الرئيسي.
• وامنح الوكيل آلة: إمكانية تنزيل كود المستخدم وتشغيل سكربت وإعادة إنتاج الفشل.

التقييم الآلي: نموذج حَكَم يفحص 10% من المحادثات

كل دور مكتمل يُرسَل بنسبة 10% إلى مهمة تقييم في الخلفية: يتلقى نموذج الحَكَم السؤال ونتائج الأدوات والإجابة، ويضع درجات من 1 إلى 5 على ثلاثة محاور (متماسك من حيث المعلومات، أجاب عن الجوهر، موجز)، ويشير إلى أداة مفقودة أو فجوة في الوثائق أو هلوسة. تُخزَّن الدرجات مع إصدار البرومبت — لا مع السؤال ولا الإجابة. وعندما تُوسَم محادثة بأنها سيئة، يفتح المهندس تتبع الخطوات ويرى أين انحرف كل شيء بالضبط.

والمبدأ نفسه — تصنيف الإخفاقات بدل مجرد عدّها — يوفر أعصابنا نحن أيضًا: بحسب سجل أخطاء التوليد خلال 14 يومًا (1–14 أكتوبر 2026)، من بين 297 عملية فاشلة كان نحو 40% بسبب تفعيل مرشحات المحتوى، وجزء ملحوظ آخر بسبب برومبت طويل جدًا أو نسبة أبعاد غير مدعومة. يتضح فورًا أن ما يحتاج إصلاحًا هو إرشادات المستخدمين حول المرشحات والحدود، لا البنية التحتية.

إن كنت تبني وكيل دردشة بنفسك، فابدأ بالدرس الأول: أول رد سريع يمنحك أكبر أثر «واو» مقابل ساعة عمل واحدة. وعلى مدونتنا مقال يشرح الفرق بين الوكيل وروبوت الدردشة وكيف تبني وكيلك الأول.