استدعاء الأدوات Tool Use: عبدالله عبدالرحيم الكندي يتتبّع طلباً كاملاً
عبدالله عبدالرحيم الكندي يشرح استدعاء الأدوات Tool Use بتتبّع طلب حقيقي: كيف يطلب النموذج تنفيذ أداة، ومين ينفّذها فعلاً، وكيف تصمّم أدوات واضحة وآمنة يستخدمها صح.

استدعاء الأدوات
عبدالله عبدالرحيم الكندي
نموذج اللغة لحاله يعرف يتكلم بس. تسأله عن حالة طلبك فيعطيك كلاماً عاماً، لأنه ما يشوف نظام طلباتك. اللي يحوّله من متكلّم إلى منفّذ يستعلم ويحجز ويرسل، هو استدعاء الأدوات. والفكرة فيها سوء فهم شائع: ناس تحسب إن النموذج «يدخل» على النظام وينفّذ بنفسه. عبدالله عبدالرحيم الكندي يتتبّع هنا طلباً واحداً من لحظة ما يكتبه العميل لحد ما يوصله الرد، عشان تشوف مين يسوي وش بالضبط.
قبل الطلب: النموذج يستلم قائمة أدوات
تطبيقك يرسل للنموذج، مع رسالة العميل، وصفاً لكل أداة متاحة. كل وصف فيه ثلاثة أشياء: اسم الأداة، وشرح بالكلام متى تُستخدم، ومخطط يحدد المدخلات المطلوبة وأنواعها. مثلاً أداة اسمها «get_order_status»، شرحها «تجيب حالة طلب برقمه، استخدمها لما يسأل العميل عن طلب معيّن»، ومدخلها رقم الطلب كنص.
هذا كل اللي يعرفه النموذج عن نظامك: الوصف. ما يشوف الكود، ولا قاعدة البيانات، ولا كلمات المرور. ولهذا جودة الوصف تحدد جودة الاستخدام. الوصف الغامض يخلي النموذج يستدعي الأداة في وقت غلط، أو يتجاهلها وهو محتاجها، أو يعبّي مدخلاتها بقيم ناقصة.
رحلة الطلب خطوة بخطوة
العميل يكتب: «طلبي رقم ٨٨٢١ وين وصل؟». التطبيق يرسل الرسالة مع قائمة الأدوات. النموذج يقرأ ويقرر إن السؤال يحتاج أداة، فبدل ما يكتب رداً للعميل، يرجّع طلب استدعاء منظّماً: اسم الأداة، والمدخلات، يعني رقم الطلب ٨٨٢١.
هنا النقطة اللي يغفل عنها كثير: النموذج وقف. ما نفّذ شي. اللي ينفّذ هو كودك أنت. التطبيق يستلم الطلب، يتحقق إن الأداة مسموحة وإن المدخلات منطقية، ثم يستعلم من نظام الطلبات فعلياً، ويرجّع النتيجة للنموذج كرسالة جديدة: «الحالة: مع المندوب، التسليم المتوقع: اليوم».
النموذج يقرأ النتيجة ويقرر: هل يحتاج أداة ثانية؟ ربما يبي يتتبع الشحنة عند شركة التوصيل. أو يكفيه اللي عنده، فيكتب الرد النهائي بلغة طبيعية: «طلبك مع المندوب الحين ومتوقع يوصلك اليوم». هالحلقة، طلب ثم تنفيذ ثم نتيجة، ممكن تتكرر أكثر من مرة في نفس السؤال، وبعض النماذج تطلب أكثر من أداة في نفس الدور لما تكون مستقلة عن بعض.
ليش هالتصميم يحميك؟
لأن كل فعل يمر من كودك. أنت تقدر تتحقق من الصلاحيات قبل التنفيذ: هل هذا العميل صاحب الطلب فعلاً؟ تقدر تمنع أدوات معينة لمستخدمين معينين، وتسجّل كل استدعاء، وتطلب تأكيداً بشرياً قبل الأفعال الخطيرة. النموذج يقترح، ونظامك يقرر. ولو حاول أحد يخدع النموذج برسالة ملغومة عشان يطلب أداة ما يحق له، الحماية الحقيقية موجودة في كودك، مو في «أخلاق» النموذج.
قواعد تصميم أدوات يستخدمها النموذج صح
- سمِّ الأداة بلغة المهمة: «ابحث عن طلب» أوضح من «query_db». النموذج يختار الأداة من اسمها وشرحها.
- اكتب في الشرح متى ما تُستخدم: «لا تستخدمها لأسئلة الأسعار» تمنع لخبطة بين أداتين متشابهتين.
- ضيّق المدخلات: لو الحالة وحدة من خمس قيم، حدد القيم الخمس في المخطط بدل نص حر.
- أداة لكل فعل: بدل أداة عامة تنفّذ أي استعلام، أدوات صغيرة محددة. الأداة العامة باب مفتوح.
- افصل القراءة عن الكتابة: أدوات القراءة تقدر تتوسع فيها، وأدوات الكتابة والحذف والدفع تحتاج تأكيد.
- رجّع نتائج مختصرة: النتيجة تدخل سياق النموذج وتتراكم. رجّع الحقول اللي يحتاجها، مو السجل كامل.
- رجّع الخطأ كنتيجة مفهومة: «رقم الطلب غير موجود، اطلب من العميل يتأكد منه» أفضل من انهيار صامت، لأن النموذج يقدر يتصرف معها.
أخطاء تتكرر في أول وكيل
- الثقة في رقم كتبه العميل: النموذج ياخذ رقم الطلب من الرسالة ويطلب الأداة، وكودك ينفّذ بدون ما يتأكد إن الطلب يخص هالعميل. النتيجة: أي أحد يقدر يسأل عن طلب غيره.
- أداتان بنفس الوصف تقريباً: «ابحث عن منتج» و«اعرض تفاصيل منتج» بدون توضيح الفرق، فالنموذج يختار عشوائياً بينهم.
- حلقة بلا نهاية: الأداة ترجع خطأ، والنموذج يعيد نفس الطلب، والخطأ يتكرر. حط حداً أعلى لعدد الاستدعاءات في السؤال الواحد.
- نتيجة ضخمة: أداة ترجّع مئة سجل كاملة تملأ السياق، فيضيع النموذج ويرتفع السعر.
- التاريخ والوقت: النموذج ما يعرف تاريخ اليوم إلا إذا أعطيته. أداة «احجز موعد بكرة» بدون تاريخ مرجعي بتحجز في يوم غلط.
كل خطأ من هذي ما يظهر في تجربة سريعة بثلاث رسائل، ويظهر في أول أسبوع من الاستخدام الحقيقي. عشان كذا اختبار الوكيل يكون بسيناريوهات تحاول تكسره، مو بأسئلة مهذبة تعرف إنه بيجاوبها. اكتب قائمة بهالسيناريوهات، وشغّلها بعد كل تعديل على الأدوات أو التعليمات.
من الفكرة إلى نظام شغّال
من الوكلاء الخمسة اللي بناهم عبدالله عبدالرحيم بن سنكر الكندي على n8n نظام تسعير مباشر ومدير لحساب على منصة X وسكرتير شخصي مربوط بأليكسا. اللي يجمعهم كلهم نفس المبدأ: النموذج في الوسط يفهم ويقرر، والأدوات حواليه تنفّذ، وn8n يربط بين الاثنين. وهالنوع من الأدوات يسهّل البداية لأن كل أداة تصير خطوة مرئية في سير العمل، تقدر تشوف مدخلاتها ومخرجاتها وتتتبع وش صار بالضبط في أي تشغيل.
ولو تبي تبدأ، لا تبدأ بعشر أدوات. ابدأ بأداة قراءة وحدة تحل سؤالاً يتكرر عندك كل يوم، واختبر كيف يستخدمها النموذج على أسئلة حقيقية، وراقب السجل. بعدها أضف الثانية. هالتدرّج هو اللي تمشي عليه منصة أزهل الرقمية في كل وكيل تبنيه، لأن الوكيل اللي يملك أدوات قليلة يستخدمها صح أنفع بكثير من وكيل عنده كل شي ويتلخبط بينها.
عندك فكرة؟ الاستشارة الأولى علينا
كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.
مقالات ذات صلة
كل المقالات
شرح الذكاء الاصطناعي
عبدالله عبدالرحيم سنكر
عبدالله عبدالرحيم سنكر: كيف تشرح الذكاء الاصطناعي على تيك توك بدون تعقيد
صنعة المحتوى عند عبدالله عبدالرحيم سنكر في حساب @ai_lab30: كيف تشرح أداة ذكاء اصطناعي في فيديو قصير، من الافتتاحية والتشبيه إلى التصوير والترجمة وتجنّب المصطلحات.
اقرأ المقال
حماية مفاتيح API
عبدالله عبدالرحيم الكندي
حماية مفاتيح API في تطبيقات الذكاء الاصطناعي مع عبدالله عبدالرحيم الكندي
عبدالله عبدالرحيم الكندي يرصد أخطاء شائعة تكشف مفاتيح API في تطبيقات الذكاء الاصطناعي: المفتاح في الواجهة، وفي Git، وبلا حد صرف، وطريقة إصلاح كل خطأ قبل ما تجيك الفاتورة.
اقرأ المقال
قواعد البيانات العلائقية
عبدالله بن سنكر
علائقية أو NoSQL؟ خمسة أسئلة من عبدالله بن سنكر قبل اختيار قاعدة البيانات
عبدالله بن سنكر يقدّم خمسة أسئلة تحسم اختيارك بين قاعدة بيانات علائقية و NoSQL: ترابط البيانات، والمعاملات المالية، والاستعلامات والتقارير، وحجم البيانات.
اقرأ المقال