الذكاء الاصطناعي
وكلاء الذكاء الاصطناعي وMCP: كيف يعمل الذكاء الاصطناعي داخل أنظمة Frappe بأمان؟
يعمل وكيل الذكاء الاصطناعي داخل أنظمة Frappe وERPNext بأمان عندما لا يصل إلى قاعدة البيانات مباشرة، بل يستدعي أدوات محددة مسبقاً عبر بروتوكول MCP أو واجهة REST API، بصلاحيات المستخدم الذي يعمل باسمه، مع تسجيل كل إجراء وطلب موافقة بشرية على العمليات الحساسة. بهذا يبقى النظام هو مصدر الأرقام والقواعد، ويبقى النموذج اللغوي وسيطاً يفهم الطلب وينفّذه ضمن حدود واضحة. في هذا المقال نشرح المفهوم بلغة بسيطة، ونعرض مثالاً عملياً، وكيف تجرّبه مؤسسة في اليمن.
ما هو MCP بلغة بسيطة؟
MCP اختصار Model Context Protocol، وهو بروتوكول مفتوح يحدد طريقة موحدة يعرض بها النظام «أدواته» على نموذج الذكاء الاصطناعي. الأداة هنا وظيفة محددة لها اسم ووصف ومدخلات واضحة، مثل «ابحث عن عميل» أو «أنشئ مسودة طلب شراء» أو «اعرض الغرف المتاحة بين تاريخين».
يمكن تشبيه MCP بقائمة خدمات في شباك مؤسسة: الموظف (النموذج) لا يدخل إلى المخزن ليأخذ ما يريد، بل يطلب من الشباك خدمة مسماة، والشباك يتحقق من هويته وصلاحيته ثم ينفذ. ميزة البروتوكول أن الأدوات تُكتب مرة واحدة، ثم يمكن استخدامها من أكثر من نموذج أو تطبيق محادثة دون إعادة بناء الربط.
الفرق بين روبوت المحادثة والوكيل الذي ينفّذ
روبوت المحادثة التقليدي يجيب من نص مكتوب مسبقاً أو من معرفة عامة، ولا يغيّر شيئاً في النظام. أما الوكيل فيقرأ بيانات حية ويتخذ إجراءات: ينشئ مستنداً، أو يحدّث حالة، أو يرسل رسالة. هذا الفرق هو ما يجعل الوكيل مفيداً، وهو أيضاً ما يجعله خطراً إذا صُمّم بلا ضوابط.
| الجانب | روبوت المحادثة | الوكيل المرتبط بالنظام |
|---|---|---|
| مصدر الإجابة | نص ثابت أو معرفة عامة | بيانات ERPNext الحالية |
| القدرة على التنفيذ | لا ينفّذ شيئاً | ينشئ ويعدّل عبر أدوات محددة |
| الصلاحيات | غير مرتبطة بالمستخدم | صلاحيات دور المستخدم نفسه |
| المراجعة | لا يوجد أثر في النظام | كل إجراء مسجَّل وقابل للتدقيق |
نموذج الأمان: أربع قواعد لا تُكسر
عند تصميم وكيل داخل نظام إداري نلتزم بأربع قواعد:
- أدوات محكومة لا وصول مفتوح: الوكيل لا يكتب استعلامات SQL حرة، بل يستدعي أدوات محددة، لكل منها مدخلات مضبوطة.
- صلاحيات المستخدم نفسه: يعمل الوكيل بدور المستخدم الذي يحادثه، فموظف المخزن لا يرى الرواتب ولو طلبها بصياغة ذكية.
- الحسابات في الكود لا في النموذج: الأسعار والأرصدة والتوفر والضرائب تُحسب بكود النظام. النموذج اللغوي قد يخطئ في عملية حسابية بثقة، لذلك لا يُترك له قرار مالي.
- موافقة بشرية على الحساس: اعتماد فاتورة أو صرف مبلغ أو إلغاء حجز يُنشأ كمسودة أو طلب موافقة، ويعتمده موظف مسؤول.
ويُسجَّل كل إجراء، سواء نفذه إنسان أو وكيل، حتى يمكن الرجوع إليه عند أي خلاف.
لبنات Frappe التي تجعل ذلك ممكناً
لا يحتاج بناء وكيل آمن إلى اختراع طبقة أمان جديدة، فمنصة Frappe توفر معظمها:
- REST API: كل نوع مستند متاح للقراءة والإنشاء والتعديل عبر واجهة موحدة تحترم الصلاحيات. التفاصيل في توثيق Frappe.
- الأدوار والصلاحيات: صلاحيات على مستوى نوع المستند والحقل والسجل، تنطبق على الوكيل كما تنطبق على المستخدم.
- سير العمل (Workflow): حالات وانتقالات وموافقات تمنع الوكيل من تجاوز مرحلة الاعتماد.
- سجل الإصدارات والتعديلات: كل تغيير على مستند يُحفظ مع اسم من غيّره ومتى.
- API Request Log في Frappe 16: سجل جديد لطلبات الواجهة البرمجية يسهّل تتبع ما فعلته التكاملات والوكلاء.
نبني فوق هذه اللبنات خادم MCP يعرض أدوات مختارة فقط، وهو جزء من عملنا في تكامل الأنظمة.
مثال عملي: HotelPMS
تطبيق HotelPMS لإدارة الفنادق الذي تنشره يمن فرابي مفتوح المصدر يطبق هذا النموذج فعلياً. فهو يتضمن خادم MCP بأكثر من 50 أداة محكومة، كل أداة مقيّدة بالدور ومتحقَّق من صلاحيتها ومسجَّلة، إضافة إلى أكثر من 170 نقطة REST API. الأسعار والتوفر وحدود الحجز الزائد تأتي من كود النظام لا من النموذج اللغوي، ويحتفظ النظام بسجل تدقيق كامل لإجراءات البشر والذكاء الاصطناعي معاً. عملياً يمكن لموظف الاستقبال أن يسأل عن الغرف المتاحة أو حالة حجز، فيستدعي الوكيل الأداة المناسبة ويعرض النتيجة كما يحسبها النظام.
استخدامات واقعية للمؤسسات في اليمن
- الإجابة عن أسئلة الموظفين من بيانات النظام: رصيد صنف في مخزن معين، أو حالة طلب شراء، أو رصيد إجازة موظف، دون البحث في القوائم.
- صياغة مستندات للمراجعة: يجهّز الوكيل مسودة عرض سعر أو طلب شراء أو رد على مراسلة، ويعتمدها الموظف بعد مراجعتها.
- طلبات واتساب: يستقبل الوكيل استفساراً أو طلباً من عميل عبر واتساب، فيتحقق من البيانات وينشئ طلباً أو يحيله إلى موظف.
- المنظمات غير الربحية والجهات الحكومية: متابعة حالة الطلبات والمعاملات وتلخيصها للمسؤول مع بقاء الاعتماد بيد الإنسان.
ولمزيد من الاستخدامات العامة راجع مقال الذكاء الاصطناعي في أنظمة ERP.
أين تبقى البيانات، والحدود، وكيف تبدأ
اختيار النموذج قرار الجهة نفسها: يمكن تشغيل نموذج محلي على سيرفر داخل المؤسسة فلا تخرج البيانات منها، أو استخدام نموذج عبر API من مزود خارجي بقدرات أعلى مع إرسال جزء من البيانات إليه. كثير من الجهات في اليمن تفضّل البدء بنموذج محلي للبيانات الحساسة. ويجب الاعتراف بالحدود: النماذج قد تسيء فهم طلب غامض، والنماذج المحلية أضعف من الكبيرة، والوكيل لا يصلح بيانات غير منظمة.
للتجربة نقترح:
- اختيار عملية واحدة قليلة المخاطر، كالاستعلام عن المخزون.
- تحديد أدوات قراءة فقط في البداية.
- تجربتها مع مجموعة صغيرة من الموظفين ومراجعة السجل.
- إضافة أدوات إنشاء المسودات بعد الثقة بالنتائج.
تقدم يمن فرابي هذا النوع من المشاريع ضمن حلول الذكاء الاصطناعي.
أسئلة شائعة
هل يمكن ربط ChatGPT أو غيره بنظام ERPNext؟
نعم، يمكن ربط نموذج لغوي بـ ERPNext عبر واجهة REST API أو خادم MCP يعرض أدوات محددة. المهم ألا يُعطى النموذج وصولاً مباشراً إلى قاعدة البيانات، وأن يعمل بصلاحيات المستخدم وتُسجَّل إجراءاته.
هل يستطيع الوكيل اعتماد الفواتير أو صرف المبالغ بنفسه؟
لا ننصح بذلك. التصميم الآمن أن ينشئ الوكيل مسودة أو طلب موافقة، ثم يعتمدها موظف مسؤول عبر سير العمل المعتاد في النظام.
هل تخرج بيانات مؤسستي إلى خارج اليمن عند استخدام الذكاء الاصطناعي؟
يعتمد ذلك على اختيار النموذج. النموذج المحلي يعمل على سيرفر المؤسسة فلا تخرج البيانات، أما النموذج عبر API فيستقبل البيانات المرسلة إليه، والقرار بيد الجهة نفسها.
ما الفرق بين MCP وREST API؟
REST API واجهة عامة للقراءة والكتابة تستخدمها التطبيقات والتكاملات. أما MCP فطبقة مصممة للنماذج اللغوية تعرض أدوات مسماة وموصوفة يفهمها النموذج، وغالباً تعمل فوق REST API وصلاحيات النظام نفسها.