اختبار خمسة مكونات MCP لـ MODX في حالات الفشل: الوكيل يعلن النجاح رغم حفظ نصف التعديلات فقط

المهمة المعتادة هي اختيار مكون MCP لإسناد الأعمال الروتينية على المواقع إلى وكيل ذكاء اصطناعي. لكن مطورًا في استوديو ويب يعمل مع MODX 2 و3 تفحص الشيفرة، ورأى حلقة تحدّث الحقول الإضافية للصفحة من دون التحقق من نتيجة setTVValue(). حُفظ الحقل الأول ولم يُحفظ الثاني، ومع ذلك أعلن المعالج نجاح العملية. سيصدق الوكيل هذه الاستجابة ويخبر المستخدم بأن كل شيء أصبح جاهزًا.

تحولت هذه الملاحظة إلى دراسة صغيرة. اختار المؤلف خمسة مشاريع: karamble/modxmcp وdampilov94/mcp-component وrumata-estor/modx3-mcp وmodxcms/modAI وShevArtV/mxBoard. وثبّت نسخ الشيفرة المصدرية بتاريخ 26 أكتوبر 2026، وأجرى 25 اختبارًا باستخدام PHP 8.3.6. استُخدمت الفئات الحقيقية للمكونات، لكن كائنات اختبار حلت محل MODX حقيقي وقاعدة بيانات فعلية. وقد صُمم بعض الاختبارات خصيصًا لإعادة إنتاج الأخطاء، ولذلك لا تعني نتيجة PASS دائمًا أن المكون يتصرف على النحو الصحيح.

بصلاحيات من يعمل الوكيل؟

تخيل مدير محتوى لا يُسمح له إلا بالتعامل مع الأخبار. إذا مُنح مساعدًا بالذكاء الاصطناعي، فما الصلاحيات التي سيحصل عليها المساعد نفسه؟ كشف فحص الشيفرة المصدرية عن نموذجين. في karamble، يجري التحقق من الإذن بتنفيذ العملية ومن صلاحية الوصول إلى المورد المحدد. بل إن issue رقم 11 وثّقت خطأً حقيقيًا: كان مستخدم محدود الصلاحيات يستطيع عبر MCP الحصول على بيانات لا يمكنه رؤيتها في لوحة الإدارة. وقد أُصلح الخطأ في الإصدار 1.2.0.

في dampilov94 وrumata-estor يمكن تقييد مجموعات الأوامر، لكنها تُنفذ من خلال مستخدم خدمة يتمتع بصلاحيات إدارية. هذا مقبول لمهام المسؤول، لكنه غير مناسب للمساعدين الشخصيين للموظفين الذين يخضع كل منهم لقيوده الخاصة.

البيانات المتقادمة والاستجابات المفقودة

السعر المعروض في الصفحة هو 1,000 روبل. قرأه الوكيل، وفي هذه الأثناء غيّره موظف إلى 1,100. بعد ذلك يكتب الوكيل 1,200، فيختفي تعديل الموظف. في شيفرة dampilov94 لا تجري مقارنة القيمة القديمة. أما rumata-estor فيتحقق من القيمة المتوقعة ويعيد الحالة STALE_STATE، وقد حافظ هذا التحقق في الاختبار على التعديل البشري. لكن التحقق اختياري: إذا لم يرسل العميل الشرط المسبق، فستتم الكتابة. إضافة إلى ذلك، يجري التحقق والكتابة كل على حدة، ولا توجد مقارنة ذرية على مستوى قاعدة البيانات.

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

أجبر قفل الملف في rumata-estor العملية الثانية على الانتظار 350 مللي ثانية. لكن عملية ثالثة لم تكن على علم بالقفل عدّلت الملف بهدوء. وستتصرف لوحة إدارة MODX العادية بالطريقة نفسها. يعالج معرّف الطلب والقفل والتحقق من القيمة المتوقعة مشكلات مختلفة، ولا يحل أحدها محل الآخر.

الكتابة الجزئية والتحقق من القبول

يغلّف rumata-estor كتابة قيم TV داخل معاملة: إذا أعادت setTVValue() القيمة false، يُستدعى rollback. وفي الاختبار عادت القيم إلى حالتها الأصلية. لا يتحقق modAI من نتيجة تحديث ذاكرة التخزين المؤقت، وخلال الاختبار أبلغت الأداة عن النجاح رغم أن النتيجة كانت false. أما karamble فيعيد قراءة المورد بعد تعديله. ويفصل mxBoard بين تنفيذ المهمة وقبولها: لم يتمكن المنفذ من إغلاق مهمة تخص شخصًا آخر.

ما العمل؟

حدود الدراسة واضحة: لم يشغّل المؤلف حتى الآن بيئة MODX حقيقية مع MySQL ونموذج لغوي، ولم يُختبر rollback إلا باستخدام mock. ومع ذلك، تنطبق الخلاصة على أي CMS وأي تطبيق يُسمح فيه للوكيل بتعديل بيانات العمل. قبل الإطلاق، حدد باسم من يعمل الوكيل. اشترط أن يرسل العميل معرّف الطلب والقيمة المتوقعة. تحقق من نتيجة كل عملية كتابة، وليس من نتيجة الاستدعاء الأخير فقط. ولا تعتبر إشارة «النجاح» الصادرة عن الوكيل دليلًا على أن كل شيء قد حُفظ فعلًا على الموقع.