قد يكون مهندس التكامل التالي وكيل ذكاء اصطناعي
المطوّر الذي يقوم حاليًا بتصحيح تكامل الـ API الخاص بك على الأرجح لا يفعل ذلك وحده. إنه يبرمج بالمشاركة مع Claude في Cursor، أو يطلب من Copilot شرح تدفق المصادقة لديك، أو يطلب من ChatGPT تحليل تنسيق حمولة الـ webhook. إن المساعد القائم على الذكاء الاصطناعي لديه يحاول فهم منصتك — وفي معظم الحالات، يعمل دون رؤية.
هذه هي مشكلة المستخدم غير المرئي. إن الفئة الأسرع نموًا من مستهلكي معرفة منصتك ليسوا بشرًا يتصفحون مركز المساعدة. إنهم وكلاء ذكاء اصطناعي يعملون نيابة عن البشر — وهم لا يستطيعون رؤية معظم ما قمت ببنائه.
كيف وصلنا إلى هنا دون أن ننتبه
حدث تحول في الثمانية عشر شهرًا الأخيرة، ولا تزال معظم منصات B2B تفتقر إليه.
لقد توقف المطورون عن قراءة المستندات بالطريقة التي صممت بها للقراءة. سير العمل القديم — فتح المستندات في تبويب، البحث عن الـ endpoint، قراءة المعلمات، الرجوع إلى المحرر، كتابة الكود — يفسح الطريق لشيء أسرع. يسأل مطور يعمل في Cursor: "كيف تعمل المصادقة المستندة إلى الجلسة في هذا الـ API؟" ويتوقع إجابة صحيحة دون مغادرة المحرر. يطلب مهندس حلول من Claude مقارنة قدرات geofence لثلاث منصات ويتوقع إجابة تستند إلى معلومات سليمة وليست مجرد هلوسة.
البشر لا يزالون هم من يتخذ القرارات. لكنهم فوضوا مهمة استرجاع المعرفة إلى وكلاء الذكاء الاصطناعي. وهؤلاء الوكلاء يصطدمون بجدار: معظم معرفة المنصة محجوبة خلف واجهات مصممة لأعين بشرية. مراكز مساعدة ثابتة. صفحات Swagger تتطلب متصفحًا. ملفات PDF تحتاج إلى تنزيل. روبوتات دردشة تتطلب زيارة عنوان URL معين.
المعرفة موجودة. إنها فقط غير قابلة للوصول من قِبل الأدوات التي تستهلكها أكثر فأكثر.
البروتوكول الذي يغير المعادلة
برز Model Context Protocol — MCP — من Anthropic في أواخر عام 2024 كمعيار يسمح للأدوات المعتمدة على الذكاء الاصطناعي باستعلام مصادر المعرفة الخارجية مباشرة. وفي غضون بضعة أشهر، تبنته OpenAI. وتبعتها Google. وبحلول نهاية عام 2025، تبرعت به Anthropic إلى Linux Foundation من خلال Agentic AI Foundation، بدعم من جميع المختبرات الكبرى في مجال الذكاء الاصطناعي.
إن سرعة الاعتماد تخبرك بشيء ما. لم يكن هذا ميزة لدى بائع واحد. بل كان اعترافًا من الصناعة بأن وكلاء الذكاء الاصطناعي يحتاجون إلى طريقة موحدة للوصول إلى المعلومات الموثوقة — وليس عن طريق تتبع الويب، وليس بالاعتماد على بيانات تدريب قد تكون قديمة لأشهر، بل بالاستعلام من المصدر مباشرة، وفي الوقت الفعلي.
بالنسبة للمنصات، يغير MCP معادلة إتاحة الوصول. إن الـ API خاصتك يجعل وظائفك قابلة للبرمجة. أما MCP فيجعل معرفتك قابلة للبرمجة. الآن يمكن لوكيل الذكاء الاصطناعي الاستعلام عن توثيقك بنفس المباشرة التي يستدعي بها سكربت الـ API خاصتك — إذا أتيحت تلك المعرفة عبر البروتوكول.
معظم المنصات لم تفعل ذلك.
المعرفة باعتبارها طبقة قابلة للتجزئة
هناك فلسفة تصميمية تتنبأ بأي المنصات ستتكيف مع هذا التغيير بشكل طبيعي وأيها ستواجه صعوبة.
في Navixy، بنينا ما نطلق عليه composable telematics — فكرة مفادها أن المنصة ينبغي أن تكون مجموعة من الوحدات القابلة للدمج والعمل معًا بدلاً من أن تكون تطبيقًا أحاديًا. واجهات API للوصول برمجيًا. Webhooks لتدفقات العمل القائمة على الأحداث. واجهات White-label للتخصيص من قبل الشركاء. كل طبقة توسع نطاق المنصة دون أن تتطلب من المستخدمين البقاء داخل نظام البائع.
MCP هو ما يحدث عندما تطبق نفس المبدأ على المعرفة نفسها.
فكر في ذلك على شكل طبقات. إن منصة التليماتيك التقليدية توفر لك واجهة مستخدم لتشغيلها، وواجهة API للبناء عليها، ومركز مساعدة للتعلم منها. الطبقتان الأوليان قابلتان للوصول آليًا — يمكن للبرمجيات الأخرى التفاعل معهما بالبرمجة. أما الثالثة فلا. إنها موقع إلكتروني مصمم ليتصفحه الإنسان.
يحول MCP تلك الطبقة الثالثة إلى شيء يمكن لوكيل الذكاء الاصطناعي الاستعلام منه مباشرة. يتوقف التوثيق عن كونه وجهة ويصبح موردًا حيًا وقابلاً للتجزئة — متاحًا حيثما يجري العمل، وبأي أداة يستخدمها الشخص.
لقد قمنا بنشر هذا بالفعل. إن توثيق Navixy الكامل — API reference، أدلة التكامل، إمكانيات المنصة — متاح عبر MCP لـClaude Desktop، وCursor، وأي أداة متوافقة. يحصل المطور الذي يكتب للـ tracking API على المعلمات الخاصة بنقطة النهاية معروضة في محرره. وتحصل فرق التسويق لدى الشركاء التي تتحقق من وصف ميزة ما على إجابة تستند إلى المستندات في أداة الكتابة لديهم. ويحصل مهندس الدعم الذي يجيب عن سؤال تقني للعميل على رد موثوق دون الانتقال بين الألسنة.
لكن الجانب المثير للاهتمام ليس فيما فعلناه فحسب، بل فيما يكشفه هذا عن اختيارات بنيوية.
مشكلة المعرفة الأحادية
المنصات التي صُممت للتحكم في تجربة المستخدم بالكامل تواجه تحديًا هيكليًا فيما يتعلق بإمكانية الوصول إلى الذكاء الاصطناعي — وهو التحدي نفسه الذي تواجهه مع قابلية التوسع في واجهات API، ومرونة webhooks، وإمكانية التخصيص للشركاء.
عندما يفترض تصميمك أن المستخدمين سيعملون داخل واجهتك، فإن هياكل المعرفة لديك تكون مُحسّنة لتلك الواجهة. تم تصميم مركز المساعدة للمستخدمين الذين يتنقلون عبر الأقسام. وتم تنظيم التوثيق حول بنية قوائم منتجاتك. وتم ضبط البحث ليتناسب مع استفسارات المستخدم البشرية في المتصفح.
جعل هذه المعرفة قابلة للوصول إلى وكلاء الذكاء الاصطناعي ليس ميزة يمكن إضافتها بسهولة. إنها تتطلب الكشف عن البنى المعرفية الداخلية لتلائم أنماط الاستهلاك الخارجية التي لم تُصمم من أجلها. إنه تغيير هيكلي، ولدى المنصات الأحادية، تكون هذه التغييرات مكلفة — ليس لأن التكنولوجيا صعبة، بل لأن الافتراضات التصميمية جذرية.
لا تواجه المنصات القابلة للتجزئة هذه المشكلة بالطريقة نفسها. عندما تفترض البنية لديك مسبقًا وجود استهلاك خارجي — لأن الشركاء يبنون على واجهات API الخاصة بك، ولأن المدمجين يوسّعون تدفقات عملك، ولأن عمليات النشر White-label توائم واجهتك — فإن جعل المعرفة متاحة خارجيًا يعد امتدادًا طبيعيًا، وليس تحولًا فلسفيًا.
هذا النمط نفسه يتكرر مع واجهات API ومع تكامل الأجهزة ومع نظم الشركاء. إن الاختيارات الهندسية التي اتخذتها قبل سنوات بشأن الانفتاح والطبيعة المعيارية تواصل مضاعفة تأثيرها في سياقات جديدة. إن MCP ليس إلا أحدث هذه السياقات.
السؤال الذي يجب طرحه على منصتك
إذا كنت مزود خدمة تتبع (TSP) تقيّم شركاء المنصة — أو بصراحة، إذا كنت أي مشتري B2B يقيّم منصات تقنية — أضف هذا إلى معاييرك:
هل يمكن لوكيل ذكاء اصطناعي العمل مع معرفة هذه المنصة بشكل مستقل؟
ليس عبر روبوت دردشة يبحث في مركز المساعدة. وليس من خلال تتبع الويب الذي قد يعيد معلومات قديمة. بل عبر وصول مباشر على مستوى البروتوكول إلى التوثيق المُتحقق منه والحديث.
إن الإجابة تخبرك بشيء عن البنية الخاصة بالمنصة يتجاوز الميزة بعينها. المنصات التي يمكنها القول "نعم" اليوم بُنيت مع قابلية الوصول الخارجي كمبدأ تصميمي. أما المنصات التي لا تستطيع فتكشف عن طريقة تفكيرها بشأن الانفتاح — وهذا التفكير سيظهر في سياقات أخرى أيضًا، من تصميم واجهات API إلى دعم الشركاء إلى مرونة التكامل.
المطور الذي يعمل مع مساعد ذكي في بيئة تطويره المتكاملة (IDE) لن يختفي. مهندس الحلول الذي يستخدم Claude لمقارنة المنصات لن يختفي. مهندس الدعم الذي يطلب من أداة ذكاء اصطناعي إيجاد التوثيق المناسب لن يختفي. هذه الأساليب آخذة في التسارع.
المنصات التي تكون مرئية أمام هذه الأساليب — والتي يمكن اكتشافها والاستعلام عنها وفهمها بواسطة وكلاء الذكاء الاصطناعي — ستتمتع بميزة متزايدة. أما تلك التي تبقى غير مرئية للوكلاء الذكاء الاصطناعي فستصبح غير مرئية تدريجيًا للبشر الذين يخدمونهم.
لدى منصتك جمهور لم تصممه أبدًا. يبقى السؤال إن كنت ستلتقي بهم أم لا.
إن توثيق Navixy متاح عبر MCP على https://www.navixy.com/docs/~gitbook/mcp — ومتوافق مع Claude Desktop وCursor وأي أداة مفعلة بـ MCP. اطلع على المزيد حول فلسفة التليماتيك القابلة للتجزئة التي تجعل ذلك امتدادًا طبيعيًا لا مجرد إضافة ميزة.