Salesforce تحوّل تطبيقات المؤسسات إلى قدرات جاهزة لوكلاء الذكاء الاصطناعي

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

كيف يعمل خادم Headless 360 MCP؟

صمّمت Salesforce خادم Headless 360 MCP Server بوعي بالبيانات الوصفية ليكون نقطة اتصال واحدة تغطي نطاقًا واسعًا من قدرات المنصة. وبدل عرض آلاف الوظائف المنفصلة كأدوات مستقلة، يقدّم الخادم التجريبي أربع أدوات مدعومة بمكتبة متنامية من عمليات Salesforce.

وتعتمد آلية الاكتشاف على مساعدة الوكيل في تحديد القدرة المناسبة أثناء التشغيل. ووفق وصف Salesforce، يفسّر النظام طلب الوكيل ثم يطابقه مع فهرس دلالي لواجهات API وSkills، قبل إعادة مجموعة مرشحين مرتبة ليختار الوكيل العملية التي سيستدعيها.

وهذا يميّز الخادم عن مجرد مجموعة من نقاط النهاية البرمجية الخام. فالهدف هو أن يفهم الوكيل وظيفة كل قدرة وعلاقتها بإعدادات المؤسسة وصلاحياتها وسير عملها وقواعد التحقق والحوكمة المطبقة فيها.

وتوفر Salesforce Hosted MCPs نقاط دخول مُدارة للعملاء والوكلاء وأدوات المطورين المتوافقة مع MCP، مع الاستفادة من نموذج الثقة والصلاحيات الموجود في مؤسسة Salesforce نفسها.

كما يستطيع المطورون ربط قدرات Salesforce بأدوات مثل Cursor وClaude Code، بينما تطرح Salesforce المنصة الأوسع للاستخدام مع الوكلاء والتطبيقات المتوافقة. والنتيجة العملية هي أن بيئة تطوير أو وكيلًا خارجيًا يمكنه التعامل مع البيانات الوصفية والقدرات التجارية في Salesforce من دون بناء تكامل مخصص لكل أداة.

تنبيه بشأن الإتاحة

لا ينبغي الخلط بين خادم Headless 360 MCP الشامل وقدرات MCP المستضافة المتاحة عمومًا لدى Salesforce. فوثائق المطورين تصف خادم Headless 360 MCP بأنه خدمة تجريبية (Beta) بدأت إتاحتها في يوليو 2026.

لذلك ينبغي للفرق التي تقيّم استخدامه أن تتعامل مع نطاقه وسلوكه وشروطه باعتبارها قابلة للتغيير.

ماذا تضيف Data 360؟

يركّز توسّع Data 360 MCP على تزويد الوكلاء بسياق محكوم عن العملاء خارج واجهة Salesforce. وتقول Salesforce إن Data 360 تتيح أكثر من 200 واجهة API كنقاط نهاية قابلة للبرمجة يمكن لوكلاء الذكاء الاصطناعي استخدامها.

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

والفارق بين سطحي MCP مهم:

• Headless 360 MCP Server: واجهة واسعة وواعية بالبيانات الوصفية، مصممة لمساعدة الوكلاء على اكتشاف قدرات Salesforce واستدعائها عبر المنصة؛ وهي موثقة حاليًا كخدمة تجريبية.
• Data 360 MCP: مسار أكثر تركيزًا للوصول إلى بيانات العملاء المحكومة وعمليات Data 360، بما في ذلك إعداد البيانات وتقسيمها وتفعيلها.

ويشير المساران معًا إلى نموذج يستطيع فيه الوكيل فهم سياق المؤسسة ذي الصلة واتخاذ إجراءات من خلال ضوابط Salesforce، بدل الاكتفاء باسترجاع سجلات منفردة.

توسّع أوسع عبر منظومة Salesforce

تمتد استراتيجية Headless 360 إلى أجزاء رئيسية من منظومة Salesforce، بما في ذلك Marketing وSales وService وCommerce وMuleSoft وInformatica وTableau، إضافة إلى منصة Salesforce الأوسع.

ويشمل التوسع ما يلي:

• Skills وPlugins قابلة لإعادة الاستخدام: تقول Salesforce إن أكثر من 100 أداة وSkill قابلة لإعادة الاستخدام تجمع منطق الأعمال في قدرات يمكن للمطورين والوكلاء استخدامها.
• وصول المطورين: إتاحة قدرات Salesforce الرئيسية عبر واجهات API وأدوات MCP وأوامر CLI، مع دعم بيئات التطوير المدعومة بالذكاء الاصطناعي مثل Cursor وClaude Code.
• إجراءات Slack: إضافة وصول قائم على MCP إلى Slack، بحيث يمكن تنفيذ إجراءات مؤسسية داخل سياق العمل بدل حصرها في شاشة نظام إدارة علاقات العملاء.
• تطوير تطبيقات React: يهدف Salesforce Multi-framework إلى دعم تطبيقات React الحديثة مع الاحتفاظ بالمصادقة والأمان والحوكمة الأصلية في Salesforce.
• تجارب بلا واجهة تقليدية: تتيح Headless Experience Layer بناء تجارب غنية للويب والهاتف والتطبيقات المضمّنة والقنوات الحوارية. والفكرة هي بناء القدرة مرة واحدة ثم تقديمها عبر واجهات متعددة، من دون إعادة كتابة المنطق الأساسي لكل قناة.

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

ماذا تكشف النتائج المبكرة؟

توضح أمثلة العملاء التي تستشهد بها Salesforce العائد الذي تريد Headless 360 تحقيقه. إذ تقول الشركة إن Engine أطلقت وكيل الدعم القائم على الذكاء الاصطناعي EVA خلال 12 يومًا، وإن الوكيل يحل الآن نحو نصف تفاعلات محادثات العملاء من دون موظف دعم بشري.

وتعطي هذه الأرقام مؤشرًا على سرعة النشر ومستوى الأتمتة اللذين تستهدف Salesforce تمكينهما عبر Headless 360. لكنها لا تصلح معيارًا عامًا للسوق؛ فهي نتائج أبلغت عنها الشركة ضمن حالة عميل واحدة، ولا تثبت المواد المتاحة أن النتائج نفسها ستتكرر لدى مؤسسات أخرى.

لماذا تهم هذه المعمارية فرق المؤسسات؟

تغيّر Headless 360 صياغة سؤال التكامل من: «كيف نربط أداة الذكاء الاصطناعي هذه بـSalesforce؟» إلى: «ما القدرات التي ينبغي السماح للوكلاء باستهلاكها بأمان، وأين يجب فرض قواعدها؟»

وتبرز إرشادات Salesforce للمطورين أهمية فرض منطق الأعمال، ومواءمة التكاملات، وتمكين طبقة البيانات الوصفية من تقديم السياق، والتحقق من سلوك المنصة عندما يصبح الوكيل نوعًا جديدًا من المستهلكين.

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

وبهذا ترسل Salesforce إشارة إلى انتقال من بيع التطبيقات أساسًا باعتبارها وجهات للمستخدمين إلى تقديم المنصة كبنية تحتية مؤسسية قابلة للتركيب والاستخدام من جانب الوكلاء. فـMCP هو معيار الوصول، وHeadless 360 هي المعمارية الأوسع، بينما توفر Data 360 سياق العملاء المحكوم، وتقدم طبقة التجارب طرقًا لعرض الإجراءات الناتجة عبر قنوات متعددة.

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