أصبح من السهل اليوم إضافة نموذج ذكاء اصطناعي إلى نافذة محادثة ثم كتابة AI Agent فوقها.
قد تكون الردود ممتازة. النظام يفهم اللغة، يتذكر سياق المحادثة ويكتب بطريقة طبيعية جدًا. لكن بعد عشر دقائق من الحوار، يخرج العميل من الموقع ولم يحدث أي شيء مختلف في البزنس.
لا Lead تم تأهيله. لا مشكلة تم حلها. لا موعد تم حجزه. ولا خطوة واضحة حدثت بعد المحادثة.
إذا كانت هذه هي النتيجة، فالمشكلة ليست أن الـAI سيئ. المشكلة أن النظام غالبًا Chatbot ممتاز وليس Agent مصممًا لتحقيق نتيجة.
لا تقيس جودة الـAgent بجمال الكلام
نماذج اللغة الحديثة جعلت الكلام الجيد سهلًا نسبيًا. يمكن للنظام أن يكون مهذبًا، سريعًا، يفهم اللهجات ويعيد صياغة المعلومات بطريقة ممتازة.
لكن الشركة لا تستثمر في Agent لأنها تريد محادثة جميلة فقط.
هي تريد شيئًا يحدث في الواقع.
إذا كان Agent لخدمة العملاء، يجب أن يقلل الوقت اللازم لحل المشكلة أو يحل نسبة من الحالات. إذا كان Agent للمبيعات، يجب أن يساعد في اكتشاف العملاء المناسبين وتحريكهم إلى الخطوة التالية. وإذا كان Agent داخليًا، يجب أن يقلل الوقت الذي يحتاجه الفريق للوصول إلى المعلومات أو تنفيذ مهمة.
النتيجة هي الوحدة الصحيحة لقياس الـAgent، وليس عدد الرسائل التي أرسلها.
أول عنصر: وظيفة واضحة
OpenAI Presence، وهي منصة مخصصة لتشغيل Agents داخل الشركات، تبدأ كل Deployment بوظيفة محددة مثل معالجة مشكلة Billing أو دعم Claims أو التعامل مع طلبات IT الداخلية.
هذه نقطة مهمة جدًا. قبل اختيار Model أو تصميم Prompt، يجب أن تعرف الوظيفة.
"أريد AI في شركتي" ليست وظيفة.
"أريد Agent يستقبل زوار الموقع، يفهم نوع المشروع والميزانية والموعد المتوقع، ثم يحول الـLeads المناسبة إلى فريق المبيعات" هي وظيفة.
كلما كانت الوظيفة أوضح، أصبح من الممكن تحديد المعرفة المطلوبة، الأدوات، الحدود ومعيار النجاح.
ثاني عنصر: معرفة حقيقية عن الشركة
Agent لا يستطيع تمثيل شركتك اعتمادًا على ذكائه العام فقط.
يجب أن يعرف خدماتك، منتجاتك، سياساتك، طريقة عملك، الأسعار أو طريقة التسعير، الأسئلة المتكررة والحدود التي لا يجب أن يتجاوزها.
وهذا يفسر لماذا أصبحت Business Context عنصرًا مركزيًا في منصات Agents الجديدة. OpenAI Frontier، مثلًا، تتحدث عن ربط مستودعات البيانات وأنظمة CRM والتطبيقات الداخلية حتى يعمل الـAgent مع نفس السياق الذي يعمل به الموظف.
النموذج يعطيك القدرة على التفكير باللغة. معرفة الشركة تعطيه القدرة على التفكير داخل سياق البزنس.
ثالث عنصر: هدف للمحادثة
يمكن أن يمتلك النظام جميع معلومات شركتك، ومع ذلك يبقى مجرد FAQ ذكي إذا لم يعرف ماذا تريد منه أن يحقق.
تخيل عميلًا يسأل عن خدمة تطوير تطبيق. Agent يعرف جميع الخدمات فيستطيع إعطاء وصف رائع لكل واحدة. لكن Agent مبيعات جيد يجب أن يفهم أيضًا ما الذي يحتاج معرفته عن العميل، وما السؤال التالي المناسب، ومتى يصبح Lead مؤهلًا، وما الخطوة التي يجب اقتراحها بعد ذلك.
الفرق هنا في تصميم المحادثة حول Outcome وليس حول كمية المعلومات التي يستطيع النظام استرجاعها.
رابع عنصر: القدرة على اتخاذ خطوة
ليس كل Agent يحتاج عشرات Integrations، لكن كلما كانت المهمة تحتاج تنفيذًا، يجب أن توجد وسيلة للوصول إلى الأداة المناسبة.
Agent للحجوزات يحتاج الوصول إلى نظام المواعيد. Agent لمتابعة الطلبات يحتاج قراءة حالة الطلب. Agent داخلي قد يحتاج الوصول إلى CRM أو قاعدة معرفة.
وهنا تنتقل المحادثة من "هذه هي الطريقة التي يمكنك تنفيذ الشيء بها" إلى "أستطيع مساعدتك في تنفيذه الآن".
لكن هذه القدرة يجب أن تأتي مع حدود واضحة.
خامس عنصر: يعرف متى لا يتصرف
واحدة من أكثر خصائص الـAgent نضجًا ليست قدرته على فعل المزيد، بل معرفته بالوقت الذي يجب أن يتوقف فيه.
هناك حالة لا يعرفها. سياسة لا تسمح له بالتصرف. عميل غاضب يحتاج شخصًا. إجراء حساس يحتاج موافقة. أو معلومة غير مؤكدة لا يجب أن يخمنها.
Agent جيد يجب أن يعرف متى يقول: هذه الحالة تحتاج أحد أعضاء الفريق.
OpenAI Presence تضع الـPolicies وGuardrails وEscalation Rules كجزء أساسي من تشغيل Agents في الإنتاج. هذا ليس تفصيلًا أمنيًا جانبيًا؛ هو جزء من جودة تجربة العميل نفسها.
سادس عنصر: القياس
إذا لم تعرف ما الذي تقيسه، لن تعرف إن كان الـAgent مفيدًا أم مجرد Demo جميل.
Agent دعم يمكن قياسه بنسبة الحالات التي حلها، سرعة الوصول إلى الحل، معدل التحويل إلى موظف ورضا المستخدم. Agent مبيعات يمكن قياسه بعدد الـLeads المؤهلة، نسبة الوصول إلى الحجز أو Conversion Rate من المحادثات.
ولا يجب أن تكون جميع الأرقام معقدة. أحيانًا يكفي أن تبدأ بسؤال واضح: هل هذه العملية أصبحت أفضل بعد Agent أم لا؟
إذا لم تستطع الإجابة، تحتاج إلى إعادة تعريف الوظيفة.
مثال: Agent في شركة خدمات
لنفترض أن شركة تطوير برمجيات تستقبل زوارًا من الموقع.
Chatbot قد يقول: "نحن نقدم تطوير مواقع، تطبيقات، SaaS وحلول AI. كيف أستطيع مساعدتك؟"
Agent مصمم للمبيعات يتصرف بطريقة مختلفة. يفهم نوع المشروع، يسأل عن المرحلة الحالية، الميزانية والموعد، يشرح الخدمة المناسبة فقط بدل عرض كل شيء، يجيب عن الاعتراضات الموجودة، ثم يقود العميل المؤهل إلى نموذج المشروع أو حجز مكالمة.
قد يستخدم الاثنان نفس Model تقريبًا.
لكن واحدًا يتحدث، والثاني يقوم بوظيفة.
كيف ننظر إلى هذا في Blakode؟
في Blakode، الفكرة الأساسية هي أن إنشاء Agent لا يجب أن يتوقف عند إضافة مصادر بيانات وتحديد Tone of Voice.
معرفة الشركة هي الأساس، لكنها ليست النهاية. يجب أن يفهم Agent ماذا تريد الشركة من المحادثة وكيف يوجه المستخدم نحو هذه النتيجة ضمن الحدود التي تحددها.
لهذا نهتم بفكرة أن يتحول موقع الشركة وملفاتها ومعرفتها إلى Agent يستطيع استخدامها ضمن سياق حقيقي، وليس مجرد Search Box أكثر ذكاءً.
الاختبار الذي يجب أن تطبقه على أي AI Agent
قبل أن تشتري أي منصة أو تبني أي نظام، حاول إكمال هذه الجملة:
وظيفة هذا الـAgent هي ______، وسنعرف أنه نجح عندما ______.
إذا لم تستطع ملء الفراغين بوضوح، فمن المبكر الحديث عن الأدوات والنماذج.
قد تكتشف أنك تحتاج Chatbot فقط، وهذا جيد. وقد تكتشف أن لديك فعلًا Workflow يمكن تحويل جزء منه إلى Agent.
المهم ألا تقع في فخ الاسم.
لأن وضع كلمة Agent على نافذة محادثة لا يجعلها Agent.
الفرق الحقيقي يظهر عندما تنتهي المحادثة ويكون هناك شيء مفيد حدث في البزنس بسببها.
جاهز لأتمتة خدمة العملاء وزيادة مبيعاتك؟
أنشئ وكيل ذكاء اصطناعي يفهم محتوى عملك، يرد على استفسارات العملاء 24/7، ويحول المحادثات إلى طلبات بدون كود في 3 دقائق فقط.