M365Con 2027 – مؤتمر مجاني عبر الإنترنت · 11–22 Jan 2027 · 120 sessions→ m365con.net

المدونة · Mirko Peters

ما وراء هندسة الأوامر: لماذا يحتاج الذكاء الاصطناعي في المؤسسات إلى مهندسين معماريين

By ·

أهلاً بكم في المدونة المرافقة الرسمية لبودكاست M365 FM. في منشور اليوم، نتعمّق في الأسس التقنية للذكاء الاصطناعي المؤسسي الحديث…

Automatically translated with AI from the original post. Read the English original

Cover: Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

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

لاستكشاف هذا الموضوع بتفصيل أكبر، جلسنا مؤخرًا مع خبير Microsoft MVP وقائد تقني للذكاء الاصطناعي، Yves Habersaat، في البودكاست. إذا أردتم الاستماع إلى الحوار الكامل حول قابلية توسيع Microsoft 365 Copilot، والبنى متعددة الوكلاء، وبروتوكول سياق النموذج (Model Context Protocol)، فتأكدوا من الاطلاع على الحلقة Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP].

مقدمة: ما وراء هندسة الأوامر

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

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

لماذا يتطلب الذكاء الاصطناعي المؤسسي مهندسين معماريين من البشر

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

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

تطور Microsoft 365 Copilot وقابلية التوسيع

لقد تطور Microsoft 365 Copilot كثيرًا منذ بداياته الأولى. فكثير من القدرات التي كانت تتطلب في السابق امتدادات مخصصة معقدة أصبحت اليوم مدمجة مباشرة في المنصة. وتغطي هذه الوظائف الأصلية مجموعة واسعة من احتياجات الإنتاجية والتعاون المعيارية.

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

لماذا يفشل Copilot واحد ضخم: البنى متعددة الوكلاء

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

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

تشريح وكيل ذكاء اصطناعي للمؤسسات

لفهم طريقة عمل هذه الأنظمة، من المفيد تفكيك بنية وكيل الذكاء الاصطناعي المعياري في المؤسسات. يبدأ كل وكيل قوي بهدف محدد بوضوح. ومن هذا الهدف، يعتمد الوكيل على عدة مكونات أساسية:

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

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

Copilot Studio مقابل التطوير المخصص

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

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

فهم بروتوكول سياق النموذج (MCP)

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

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

دمج الأنظمة: MCP مقابل واجهات برمجة التطبيقات التقليدية

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

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

الأمان والحوكمة والمعرفة المؤسسية

تحتوي بيئات Microsoft 365 على كمّ هائل من السياق المؤسسي القيّم، بما في ذلك المستندات، ونصوص الاجتماعات، ورسائل البريد الإلكتروني، والمخططات التنظيمية، وسجلات الدردشة في Teams، وملفات OneDrive، ومستودعات SharePoint. إن ربط وكلاء الذكاء الاصطناعي القادرين بهذا الكنز من البيانات دون حوكمة متينة يُدخل مخاطر أمنية جسيمة.

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

أهمية جودة البيانات والجاهزية للذكاء الاصطناعي

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

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

إدارة الأذونات المفوَّضة مقابل أذونات التطبيقات

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

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

التوليد المعزَّز بالاسترجاع (RAG) في المؤسسات

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

يمكن أن يأتي هذا المحتوى المسترجَع من قواعد المعرفة الداخلية، ومواقع SharePoint، ومستودعات المستندات المتخصصة، أو قواعد البيانات الخارجية. وفي منصات حديثة كثيرة، مثل Copilot Studio، تتم آليات الاسترجاع الأساسية خلف الكواليس بالكامل، فتُخفي التعقيد عن المستخدم النهائي، مع الاستمرار في تقديم إجابات دقيقة ومدركة للسياق ومستندة إلى بيانات مؤسسية موثوقة.

الخاتمة: بناء حلول ذكاء اصطناعي جاهزة للإنتاج

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

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

للتعمق أكثر في هذه الاستراتيجيات المعمارية والاستماع إلى رؤى الخبراء مباشرةً من الميدان، لا تفوّت الاستماع إلى الحوار الصوتي الكامل. زُر Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP] وشارك في النقاش حول العمل الحديث والأمان والإنتاجية!

Entities in this article

Prompt engineering Model Context Protocol (MCP) Yves Habersaat Copilot Studio SharePoint AI agent Microsoft 365 Copilot AI readiness Microsoft 365 Copilot extensibility Generative AI

Related articles

RSS