كيف تصمّم أدوات وكلاء الذكاء الاصطناعي: ممارسات عملية وأخطاء شائعة

لا تتحدد جودة وكيل الذكاء الاصطناعي بقوة النموذج اللغوي وحدها، بل بمدى إحكام تصميم أدواته أيضًا. حلّل Machine Learning Mastery ما الذي يجعل أدوات (tools) الوكلاء فعّالة، وما الأخطاء التي تحوّل وكيلًا ذكيًا إلى وكيل فوضوي.

الاسم والوصف يحسمان كل شيء

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

مثال على أداة ضعيفة: `get_data()` بوصف «تجلب البيانات». ومثال على أداة قوية: `get_user_purchase_history(user_id)` بوصف «تُرجع قائمة المشتريات خلال آخر 90 يومًا مرتبة حسب التاريخ. استخدمها عند الحاجة إلى تحليل الإنفاق أو بناء تخصيص للمستخدم».

يشرح الوصف الثاني ما تفعله الأداة ومتى تُستدعى. وهذا فارق جوهري في مستوى الفائدة التي يجنيها الوكيل.

الاسم يحمل دلالة: `process_file` واسع أكثر من اللازم، أما `extract_invoice_line_items` فيفهم النموذج منه السياق وقابلية التطبيق فورًا. والصيغة الجيدة: فعل + مفعول به + توضيح.

«وصف الأداة هو موجّه (prompt) للأداة نفسها. إذا كان غامضًا، سيختلق

الوكيل وسائط وهمية (hallucinate) أو يستدعي أداة خاطئة».

أداة واحدة، مسؤولية واحدة

أشيع خطأ هو «السكين السويسرية»: دالة بعشرات المعاملات تؤدي خمس مهام مختلفة بحسب تركيبة الخيارات المفعّلة.

علامات الأداة سيئة التصميم:

• معامل `mode` أو `action` بمجموعة قيم نصية
• أكثر من 5–6 معاملات في دالة واحدة
• وجود أداة العطف «أو» في الوصف، مثل «تبحث عن جهة اتصال أو تنشئ جهة جديدة»
• إرجاع أنواع بيانات مختلفة بحسب الوسائط المُدخلة
• معاملات اختيارية تغيّر السلوك جذريًا

إذا كانت الأداة تؤدي عدة مهام، فقسّمها إلى أدوات منفصلة. يسهل على الوكيل الاختيار بين `search_contact` و`create_contact` أكثر من تخمين التركيبة الصحيحة للخيارات في `manage_contact`.

عندما يتجاوز عدد الأدوات في السياق 20 أداة، تتراجع دقة اختيار الأداة المناسبة لدى النماذج بشكل ملحوظ، لذا أبقِ المجموعة مختصرة.

المعاملات والقيم المُرجَعة

يؤثر نوع المعامل في جودة التوليد. فالمعامل من نوع `string` بلا وصف مصدر للاختلاق، أما `enum` بقائمة صريحة من القيم المسموحة فليس كذلك. وفي المعاملات الرقمية، حدّد النطاق ووحدة القياس: لا `timeout`، بل `timeout_seconds: integer, 1–30`.

يجب أن تكون القيمة المُرجَعة متوقعة ومختصرة، لأن الوكيل يضيف كامل ناتج الأداة إلى السياق. وإذا أرجعت الأداة آلاف الرموز (tokens) من HTML خام، فسيصبح ذلك عنق زجاجة لسلسلة الاستدعاءات كلها.

مبادئ القيمة المُرجَعة الجيدة:

• JSON ببنية ثابتة، فالنموذج يحلّل الصيغ المتوقعة بشكل أفضل
• الأخطاء بيانات منظّمة، لا استثناءات غير ملتقطة
• حقول وصفية (meta) مثل: `total_results` و`truncated: true` و`next_cursor`
• ما يحتاجه الوكيل للخطوة التالية فقط، دون زيادة
• عند الخطأ، رسالة واضحة مع تعليمات للإجراءات اللاحقة

ما معنى ذلك

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

لن يُصلح الوكيل أداة سيئة التصميم، بل سيستدعيها بشكل خاطئ مرارًا وتكرارًا.