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