SocialHub.AI
← جميع المنشورات
حدود الذكاء الاصطناعي·قراءة لمدة 10 دقائق

برمجيات كخدمة (SaaS) للذكاء الاصطناعي: عندما يكون المستخدم الأساسي لبرنامجك وكيلاً، وليس شخصًا

بواسطة SocialHub.AI الفريق

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

الادعاء دقيق، وليس ترويجياً

يُستخدم مصطلح "برمجيات كخدمة للذكاء الاصطناعي" كحيلة تسويقية، وهو أمر مؤسف، لأنه يُشير إلى تحول معماري حقيقي ومحدد. النسخة الدقيقة: برنامج يكون مستخدمه الأساسي وكيلًا وليس شخصًا، ومنتجه هو نظام إدارة القدرات بقدر ما هو القدرة نفسها. هذا البند الثاني هو الأهم. عندما يكون مستخدم برنامجك إنسانًا، يكون المنتج هو الشاشة. أما عندما يكون المستخدم وكيلًا، فالمنتج هو العقد الذي يُحدد ما إذا كان الإجراء مسموحًا به، ومن يقوم به، وباسم من، وبتكلفة. عندما يكون المستخدم وكيلًا، يكون المنتج هو العقد الذي يُحدد ما إذا كان الإجراء مسموحًا به، ومن يقوم به، وباسم من، وبتكلفة.

يسهل اختبار هذا التمييز. يُجيب API على سؤال واحد فقط: هل يُمكن تسمية هذا؟ هذا نظام ثنائي، وهو النظام الثنائي الأمثل لتكامل حتمي بين نظامين سبق للمهندس التفكير فيهما. أما برمجيات SaaS للذكاء الاصطناعي، فتواجه سؤالًا أكثر تعقيدًا وشروطًا: هل يمكن إجراء هذا الاتصال بأمان؟ من قِبَل من؟ نيابةً عن من؟ وما هي التكلفة؟ هذه ليست مجرد أسئلة مُطوّلة. يفترض السؤال الثاني وجود مُتصل لم تُوافق على نيته مُسبقًا، ويتصرف في سياق لم تتوقعه، وبحجم اتصالات لا يُمكن لأي إنسان توليده يدويًا.

إذا كانت منصة الاحتفاظ بالعملاء لديك تُظهر إمكانيات دون الإجابة على السؤال الثاني، فأنت لم تُنشئ برنامج SaaS للذكاء الاصطناعي. لقد أنشأت API بوثائق متفائلة، وستكتشف مواطن الخلل في بيئة الإنتاج بسرعة فائقة.

ثلاث طبقات، ولماذا يُعدّ دمجها خطأً.

معظم الفرق التي تحاول منح وكيلها وصولاً حقيقياً إلى منصتها تُدمج الإجراءات والقدرات والواجهات في مجموعة واحدة من تعريفات الأدوات. قد ينجح هذا في العرض التوضيحي، لكنه يفشل في أول تدقيق. النموذج الأمثل يُبقي الطبقات الثلاث متميزة، لأن كل طبقة تُجيب على سؤال مختلف، ولكل منها أسباب فشل مختلفة. في SocialHub.AI، نرسمها كطبقة امتداد AI Frontier، وهذا الفصل مقصود.

الطبقة السفلية هي واجهة سطر الأوامر (CLI): وهي عبارة عن أوامر تنفيذية أساسية، أي الأفعال التي يمكن للوكيل تنفيذها. هذا هو الإجراء. الطبقة الوسطى هي المهارات: وهي قدرات قابلة لإعادة الاستخدام، ومعزولة، وموقعة، تُركّب الأوامر الأساسية في شيء يمكن للوكيل الوثوق به لاستدعائه كوحدة واحدة. التوقيع والعزل ليسا مجرد تحسينات هنا؛ بل هما ما يسمح لك بفهم القدرة دون الحاجة إلى إعادة قراءة تنفيذها في كل مرة يستخدمها الوكيل. الطبقة العليا هي MCP، بروتوكول سياق النموذج المفتوح من أنثروبيك، والذي تم توحيده في نوفمبر 2024: وصول موحد، وموثق، وخاضع للتدقيق إلى الأدوات. MCP هي سطح الحوكمة، حيث توجد الهوية، والتفويض، وسجل التدقيق فعليًا.

إذا تم دمج هذه الطبقات، ستفقد الخاصية التي تجعل النظام بأكمله قابلاً للتشغيل. إذا كانت طبقة واجهة المستخدم هي نفسها طبقة الإجراءات، فإن كل عنصر جديد يزيد من نطاق الحوكمة دون أن تشعر، ولن تتمكن من الإجابة على سؤال "من فعل هذا؟" دون البحث في الشيفرة. عند فصل الطبقات، يمكن مراجعة أي قدرة دون المساس بالعقد، ويمكن تشديد العقد دون الإخلال بالقدرة. يواصل إطار إدارة مخاطر الذكاء الاصطناعي التابع للمعهد الوطني للمعايير والتكنولوجيا (NIST) التأكيد على نفس المبدأ من جانب السياسات: رسم الخرائط، والقياس، والإدارة كوظائف منفصلة. نموذج الطبقات الثلاث هو هذا المبدأ مُجسدًا في البرمجيات.

MCP هي سطح الحوكمة، وليست موصلاً.

قد يغريك التعامل مع MCP كأداة بسيطة، طريقة سهلة لربط الوكيل ببعض الأدوات. هذا التوصيف يُقلل من شأنه وسيكلفك لاحقًا. السبب وراء اعتماد MCP ليس الراحة؛ يُتيح لك البروتوكول المفتوح والموثّق والمُدقّق إمكانية تطبيق أربعة أسئلة لا يُمكن لبروتوكول API الإجابة عليها: الهوية، والتفويض، والتدقيق، والميزانية. يُسجّل كل اتصال هوية المُستخدِم، وصلاحياته، وإثبات وقوعه، وبيانًا باستهلاكه.

الميزانية هي ما يغفل عنه الفريق، وهي التي تُسبب المشاكل. المستخدم البشري يُحدد معدل استخدامه بنفسه؛ يتعب، يذهب لتناول الغداء، يُعيد النظر في قراره. أما الوكيل فلا يفعل ذلك. سيُعاود المحاولة، وينتشر، ويُكرر العملية بكامل طاقته حتى يوقفه شيء ما. إذا لم تتمكن طبقة الوصول إلى أداتك من تحديد ميزانية وفرضها بشكل نهائي، فإن قناة الإبلاغ عن الحوادث ستُجيب على سؤال "ما هي التكلفة؟". سطح الحوكمة هو المكان الذي تُوقف فيه هذه العملية، ويجب أن يكون السطح نفسه لكل مُتصل، لأن الوكيل الذي يتجاوزه هو الذي ستقرأ عنه.

لهذا السبب أيضًا لا يمكن اعتبار واجهة المستخدم إضافة لاحقة لمنتج بشري. إذا كانت الحوكمة موجودة في طبقة واجهة المستخدم، فإن مسار الوكيل حولها ليس خطأً، بل هو الوضع الافتراضي. يجب أن تتواجد الحوكمة حيث يُجري الوكيل معاملاته فعليًا، ما يعني أن MCP يجب أن يكون نظامًا من الدرجة الأولى، يخضع للتدقيق بعد كل مكالمة، وإلا فإنه مجرد إجراء شكلي.

التحول من الدرجة الثانية: تصبح لوحة التحكم ثانوية

هذه هي الحجة التي لا تستعد لها معظم المنصات. بمجرد أن يصبح المستخدمون هم المستهلكون الرئيسيون للتحليلات، تتوقف لوحة التحكم البشرية عن كونها الواجهة الرئيسية وتصبح ثانوية. لم يعد المنتج هو الرسم البياني؛ بل الطبقة الدلالية المعتمدة الكامنة تحته، والتي تحدد معنى "العضو النشط"، وكيفية إسناد إجمالي قيمة البضائع المباعة، وأي المقاييس موثوقة وأيها تقريبية. يقرأ المستخدم لوحة التحكم ويُصدر أحكامًا على بيانات غير واضحة. numberيقوم الوكيل بالاستعلام عن تعريف ما ويتصرف بناءً عليه، لذلك يجب أن يكون التعريف صحيحًا ومُحدثًا ومعتمدًا، لأنه لا يوجد أحد في الحلقة لاكتشاف الخطأ.

يُقلب هذا الوضع افتراضات عقدٍ كامل. كانت لوحة التحكم هي النظام المرجعي، وكل شيء آخر يُغذيها. في عالمٍ يُعطي الأولوية للوكلاء، تُصبح الطبقة الدلالية المعتمدة هي النظام المرجعي، ولوحة التحكم هي إحدى تجلياته، مفيدة للبشر، لكنها لم تعد مرجعًا نهائيًا. المنصات التي تنجو من هذا التحول هي تلك التي تُعامل الطبقة الدلالية كمنتج، ولوحة التحكم كواجهة عرض. أما المنصات التي لا تفعل ذلك، فستستمر في إصدار لوحات التحكم بينما يستعلم وكلاؤها بهدوء عن أي شيء يُمكنهم الوصول إليه.

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

لماذا لم يكن التفكير المنطقي عائقًا أبدًا؟

أظهر بحث ديلويت حول حالة الذكاء الاصطناعي في المؤسسات بوضوحٍ تامٍّ أين يكمن الخلل الحقيقي في الذكاء الاصطناعي المؤسسي، وهو ما لا يُركّز عليه معظم نقاشات المشتريات. تتمثل عوائق التوسع في جاهزية البيانات، والحوكمة، والتفعيل التنظيمي. النموذج الأساسي ليس هو العائق. فقد أصبح الاستدلال متاحًا بكثرة وبأسعار معقولة؛ ويمكن للنماذج المتقدمة تخطيط تدخلات الاحتفاظ بالعملاء متعددة الخطوات بسهولة تامة. لكن ما لا تستطيع هذه النماذج فعله هو منح نفسها صلاحية التصرف على أعضائك، أو حصر إنفاقهم، أو ضمان استعلامهم عن المقياس المعتمد.

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

هذا يُعيد صياغة ما يجب عليك شراؤه. إن سؤال "ما مدى ذكاء الوكيل؟" هو سؤال من العام الماضي. السؤال الذي يُحدد ما إذا كان الاحتفاظ بالوكلاء فعالاً في بيئتك هو "ماذا يحدث في الإجراء الألف، الذي لم يراجعه أي إنسان، عندما يكون الوكيل مخطئًا؟" إذا كانت إجابة المنصة عبارة عن سرد متماسك حول الهوية والنطاق والتدقيق وميزانية لم يتم إغلاقها، فأنت تنظر إلى SaaS للذكاء الاصطناعي. إذا كانت الإجابة هي هز الكتفين ومعيار نموذجي، فأنت تنظر إلى روبوت محادثة لديه إمكانية الوصول إلى قاعدة بيانات.

كيف يبدو هذا عمليًا في مجال الاحتفاظ بالبيانات

يُصبح مفهوم الاحتفاظ بالبيانات ذا أهمية بالغة، لأن الإجراءات التي يتخذها الوكيل ليست للقراءة فقط. إصدار قسيمة، أو ترقية مستوى العضوية، أو إرسالها إلى شريحة معينة، أو استبدال النقاط: كل ذلك يُحرك الأموال ويؤثر على علاقة العضو بالعلامة التجارية. هذا أسوأ مكان ممكن للكشف عن قدرات غير مُدارة، وأفضل مكان ممكن لإثبات جدوى فرضية الحوكمة كمنتج. تكتمل حلقة الاحتفاظ الآلية، من جمع البيانات، واتخاذ القرار، والتفعيل، والتجميع، فقط إذا كانت خطوتا اتخاذ القرار والتفعيل موثوقتين بما يكفي للعمل دون إشراف بشري.

النطاق الذي يجب أن يعمل عليه هذا ليس نظريًا. ساهم عمل SocialHub.AI مع McDonald's China في رفع إجمالي قيمة الزيارات المنسوبة للأعضاء من 5% إلى 85%، وزيادة معدل تكرار زيارات الأعضاء من 5.1 إلى 6.7 زيارات، أي بزيادة قدرها 37% في إجمالي قيمة الزيارات المتكررة، في حين نمت قاعدة الأعضاء من 5 ملايين إلى 200 مليون. لا يقوم أي شخص بمراجعة قرارات الاحتفاظ بـ 200 مليون عضو بشكل فردي. عند هذا الحجم الهائل من البيانات، فإن الطريقة الوحيدة التي يتصرف بها النظام بأمان هي أن يمر كل إجراء يقوم به عبر نفس عملية التحقق من الهوية والتفويض والتدقيق والميزانية، في كل مرة، دون أي مسار مميز لتجاوز هذه العملية.

لاحظ ما يتطلبه ذلك من الطبقة الدلالية. "إرسال إلى الأعضاء ذوي القيمة العالية المعرضين لخطر الإلغاء" جملةٌ يُمكن للوكيل التخطيط لها في أجزاء من الثانية، ولكن تنفيذها قد يُؤدي إلى نتائج كارثية إذا لم تكن عبارتا "ذوي القيمة العالية" و"المعرضين للخطر" مُعرّفتين مُعتمدتين يستعلم عنهما بدلاً من الارتجال. لا تُمثل الحوكمة عائقًا إضافيًا أمام الإمكانية، بل هي أساسها الذي يجعلها قابلة للتطبيق.

التأليف والتشغيل بدون وجود مُستخدم فعلي

إذا كان الوكيل هو المستخدم الأساسي، فإن الأسطح التي يتفاعل معها الإنسان تظل مهمة، لكن دورها يتغير. تُعدّ كتابة التعليمات البرمجية بدون كتابة أكواد الطريقة التي يُعلن بها الإنسان عن نيته، أو حملته، أو رحلته، أو قاعدته، بصيغة تتوافق مع نفس العناصر الأساسية التي يستخدمها الوكيل. إنها ليست مسارًا منفصلاً أو أقل فعالية. تكمن أهمية توحيدها في أن الإجراء الذي يُنشئه الإنسان والإجراء الذي يُنفذه الوكيل يمران عبر نفس واجهة سطر الأوامر، ونفس المهارات الموقعة، ونفس عقد MCP، وبالتالي يوجد مكان واحد فقط تُفرض فيه الصلاحيات والتدقيق، وليس مكانين منفصلين.

يتبع تشغيل المنصة نفس المنطق. يُمكّن SoCode الفريق من تشغيل SocialHub.AI مباشرةً من أماكن عمل مهندسيهم ومحلليهم، Claude Code، Claude Desktop، Cursor، عبر نفس الواجهة المُدارة بدلاً من قناة جانبية مُخصصة. هذا مُتاح اليوم، ويمكنك الاطلاع على التفاصيل في /resources/socode. يكمن جوهر النظام في الاتساق: المُشغّل في Cursor والوكيل المُستقل في الرحلة هما نفس المُتصل المُدار بواجهة مختلفة.

SoTag يوسّع نطاق نفس الوكيل المُدار ليشمل Slack، بحيث تتم عمليات الاحتفاظ بالبيانات حيث تنسق الفرق بالفعل. لا يزال العمل جارياً، ولم يتم إطلاقه بعد، ولن نتظاهر بغير ذلك، لأن المبالغة في وصف مدى التوافر هي تحديداً نوع تآكل الثقة الذي وُجدت هذه البنية بأكملها لمنعه. يبقى المبدأ سارياً بغض النظر عن الواجهات المستخدمة: كل واجهة تمر عبر عقد إدارة واحد، وإلا فإن هذا العقد مجرد وهم.

ما يجب السؤال عنه قبل الشراء

إذا كان هناك شيء واحد يجب أن تستفيده من هذا، فليكن سؤالاً أساسياً عند الشراء، وليس مجرد شعار. عندما يقول البائع "الاحتفاظ بالعملاء المدعوم بالذكاء الاصطناعي"، اطلب منه شرح آلية الفصل بين الطبقات الثلاث. أين يوجد الإجراء، وأين توجد القدرة، وأين يوجد عقد الإدارة، وهل يمكن تغييرها بشكل مستقل؟ إذا كانت الإجابة طبقة واحدة غير متمايزة من تعريفات الأدوات، فإن الحوكمة تكمن حيث يوجد الخلل.

ثم اطرح اختبار الأسئلة الأربعة مباشرةً. وضح لي كيف تُجيب المنصة على سؤال "هل يمكن استدعاء هذا الإجراء بأمان؟"، ومن يقوم بذلك، وباسم من، وبتكلفة ما، وذلك بالنسبة لإجراء واحد من قِبل وكيل واحد ضد عضو واحد. اسأل عن مكان تطبيق الميزانية، وما إذا كانت تفشل عند الإغلاق. اسأل عما إذا كانت الطبقة الدلالية مُعتمدة ومُرقّمة، أو ما إذا كان الوكيل يستعلم عن أي شيء يمكنه الوصول إليه. اسأل عن الأسطح، البشرية والآلية، التي تشترك في المسار المُدقّق، وأيها يتجاوزه. الثغرات في الإجابات هي الثغرات التي ستعمل على معالجتها.

لقد طورنا طبقة امتداد AI Frontier، وواجهة سطر الأوامر، والمهارات، وMCP، وطبقة دلالية معتمدة، لأن التفكير المنطقي لم يعد الجزء الصعب، وأصبح التفعيل المُدار هو المنتج. إذا كنت تفكر في متطلبات الاحتفاظ بالعملاء التي تعتمد على الوكلاء في بيئة متعددة المستأجرين ومنظمة، فستجد التفاصيل في /platform/ai-frontier، ويسعدنا أن نشرح لك سيناريو محددًا من منظومتك. احجز عرضًا توضيحيًا، وأحضر معك أصعب مهمة لديك، المهمة الألف، التي لن يراجعها أي إنسان، ودعنا نريك أين يكمن جوهر العقد. لا تحسب مرتين اطلب عرضًا توضيحيًا

قراءات ذات صلة

استمر في استكشاف الصفحات الأكثر صلة بهذه الصفحة.

مقالة

MCP ليس مجرد موصل، بل هو واجهة إدارة لعصر الوكلاء

يُصوّر معظم التغطية بروتوكول سياق النموذج على أنه مجرد بنية تحتية. أما إعادة الصياغة الأكثر أهمية على مستوى المؤسسة فهي: MCP هو المكان الوحيد القابل للتدقيق حيث يتم تحديد الهوية، والتفويض، والتسجيل، والتحكم في التكاليف لاستخدام أدوات الذكاء الاصطناعي.

اقرأ المزيد
مقالة

قم بتشغيل منصة عملائك من Claude Code — و Slack

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

اقرأ المزيد
مقالة

خط الأنابيب ليس حلقة مفرغة: لماذا يُضاعف "التجميع" فقط من معدل الاحتفاظ بالعملاء؟

تعتمد معظم تقنيات التسويق على مسار أحادي الاتجاه، وتُطلق عليه اسم "حلقة". الفرق يكمن في عقدة واحدة - الكتابة العكسية - وهذا هو الفرق بين بنية بيانات قابلة للنسخ وميزة لا يُمكن نسخها. معظم تقنيات التسويق تعمل بنظام أحادي الاتجاه وتُسمّيه "حلقة". الفرق يكمن في عقدة واحدة - الكتابة العكسية - وهو الفرق بين بنية بيانات يُمكن نسخها وميزة لا يُمكن نسخها.

اقرأ المزيد
مقالة

مفردات واحدة، جمهوران: لماذا يجب أن يشترك الذكاء الاصطناعي ولوحات المعلومات في طبقة دلالية مشتركة؟

الأدوات هي الأفعال التي يستخدمها الوكيل. الطبقة الدلالية هي المفردات المشتركة التي تضمن دقة هذه الأفعال. أنشئها مرة واحدة، واستخدمها لخدمة المستخدمين والوكلاء، وسيحمل رمز number نفس المعنى بغض النظر عمن يسأل.

اقرأ المزيد
مقالة

هوية واحدة، ألف حوار: صوت العلامة التجارية في عصر التخصيص المفرط

التخصيص بدون وحدة العلامة التجارية مجرد ضجيج لا معنى له. هوية ثابتة بدون تخصيص مجرد بث غير ذي صلة. يجمع هذا النظام بين الأمرين معًا.

اقرأ المزيد
مقالة

ما ورثته تقنيات التسويق في أمريكا الشمالية من عصر البريد الإلكتروني — ولماذا يُجبر عصر الوكلاء على دمجها

نشأت تقاليد تقنية في مجال البيع بالتجزئة لحل مشكلات مختلفة في مناطق متباعدة من العالم. كل منها متميز حقًا. والوكيل المستقل هو أول ما يحتاج إلى كليهما معًا.

اقرأ المزيد

هل ترغب بمعرفة المزيد؟

حدد موعدًا لمحادثة مع خبراء الاحتفاظ بالعملاء لدينا.