الآن بعد أن عرفت ما الذي سيقوم به وكيلك وأين سيعمل، حان الوقت لطرح سؤال مهم.
هل هذه المشكلة تحتاج فعلاً إلى وكيل؟
ليس كل مشروع يحتاج إلى وكيل؛ حتى مشاريع الأتمتة ليست جميعها بحاجة إليه. أحيانًا يكون سير العمل البسيط أو البرنامج النصي أو العملية القائمة على القواعد كافيًا لإنجاز المهمة بشكل أفضل. فهم الفرق يوفر الوقت والمال ويقلل الالتباس لاحقًا.
تم تصميم وكيل الذكاء الاصطناعي للقيام بأكثر من تنفيذ التعليمات فقط. فهو يقرأ ويكتب ويتحدث بلغة طبيعية. يفسر النوايا، ويطبق المعرفة، ويتخذ قرارات في مواقف غير مؤكدة. هذه المرونة تمنحه القوة، لكنها تضيف أيضًا بعض التعقيد. كل استدعاء لنموذج اللغة الكبير يكلف رموزًا ووقتًا ويحمل بعض المخاطر. لذا من المنطقي استخدام وكيل فقط عندما يتطلب العمل فعلاً منطقًا أو فهمًا لغويًا.
إذا كانت المهمة حتمية (أي لها مدخل واحد متوقع ومخرج واحد متوقع)، فعادةً ما يكون سير العمل أو أداة الأتمتة أفضل. (ملاحظة سريعة: Botpress يدعم كلا الخيارين!)
إذا كانت المهمة تتطلب سياقًا أو تفسيرًا أو محادثة، فإن وكيل الذكاء الاصطناعي هو الخيار المناسب.
لنرَ كيف تتعامل Terminal Roast مع هذا الأمر.
حدد فريق تيرين أول مهمة لهم: جمع آراء العملاء حول نكهات ووصفات القهوة الجديدة. يقترح أدريان، رئيس الباريستا، طريقتين يمكن للوكيل أن يتعامل بهما مع هذه المهمة.
الأولى محادثية. يسأل الوكيل العميل عن سبب إعجابه أو عدم إعجابه بمشروب معين ويحاول فهم منطقه. هذا يتطلب دقة وتفسيرًا وذاكرة. وهو مناسب تمامًا للوكيل.
الثانية برمجية. يعرض الوكيل قائمة بسيطة بالوصفات الجديدة ويطلب من العملاء الرد بـ "نعم" أو "لا". هذا التفاعل لا يتطلب منطقًا. وهو مرشح مثالي للأتمتة.
من خلال فصل هذين المسارين، يجعل الفريق النظام أكثر كفاءة. يستخدمون وكيلًا عندما يكون فهم اللغة ضروريًا، وسير عمل عندما يكون المنطق وحده كافيًا.
كثير من الفرق تخلط بين هذين الأمرين. يحاولون بناء وكيل يقوم بكل شيء: الإجابة على الأسئلة، جلب البيانات، تحديث السجلات، وإدارة المعاملات. لكن كل وظيفة إضافية تزيد التكلفة والبطء وصعوبة الصيانة. النهج الأفضل هو الجمع بين الوكلاء وسير العمل.
استخدم سير العمل من أجل الهيكلية والموثوقية. استخدم الوكلاء من أجل الذكاء والقدرة على التكيف.
فكر في الوكيل كواجهة "خط المواجهة" التي تفهم المستخدمين، ثم ترسل الإجراءات المنظمة إلى أنظمة الأتمتة لتنفيذها بدقة. عندما يتم تحديد هذين النظامين بوضوح، تكون النتيجة أكثر استقرارًا وقابلية للتوسع وشفافية.
إليك اختبار سريع.
اسأل نفسك: هل تتطلب هذه المهمة فهم اللغة الطبيعية، أم يمكن التعامل معها بمجموعة قواعد بسيطة؟ إذا كانت تتطلب فهمًا — مثل تحديد النية أو التعامل مع الغموض أو الرجوع إلى المعرفة — فهي بحاجة إلى وكيل. إذا لم يكن كذلك، أنشئها كسير عمل.
يمكنك دائمًا إضافة وكيل لاحقًا عندما يكون لديك منطق وبيانات واضحة. من الأسهل بكثير تطوير سير عمل فعال ليصبح ذكيًا من تصحيح وكيل معقد ومبالغ في بنائه.
نهج Terminal Roast (فصل المهام المحادثية عن البرمجية) هو نموذج جيد. ينتهي بهم الأمر بنظام أكثر بساطة يؤدي كل جزء فيه ما هو مناسب له تمامًا.
الوضوح في هذه المرحلة يعود بالنفع لاحقًا في سهولة الصيانة والتكلفة والأداء.
إجراء: راجع مهام وكيلك المقترحة وحدد أيها يتطلب فهمًا حقيقيًا للغة.
احتفظ فقط بتلك المهام التي تقع ضمن نطاق سيطرة الوكيل، وخطط لأتمتة الباقي من خلال سير العمل القياسي.
