بنية الذكاء الاصطناعي: A2A, MCP, Kafka, Flink

البنية الناشئة لوكلاء الذكاء الاصطناعي: A2A, MCP, Kafka, و Flink

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

• Agent2Agent (A2A) من Google: بروتوكول مصمم لتسهيل اكتشاف الوكلاء والتفاعل.
• Model Context Protocol (MCP) من Anthropic: معيار يحدد كيف يستخدم الوكلاء الأدوات والبيانات السياقية الخارجية.
• Apache Kafka: عمود فقري قوي للاتصالات القائمة على الأحداث، مما يتيح تنسيقًا موثوقًا به وغير مرتبط.
• Apache Flink: محرك معالجة في الوقت الفعلي، حيوي لإثراء ومراقبة والتصرف بناءً على تدفقات نشاط الوكيل.

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

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

ومع ذلك، فإن الأدوات الحالية غير كافية لدعم مثل هذا المستقبل.

يتجاوز التحدي مشكلة “جزيرة الوكلاء”، حيث يعمل الوكلاء في صوامع ويفتقرون إلى قدرات الاتصال. إنه يشمل تجزئة النظام البيئي الأكثر شمولاً:

• نقص الاتصال بين الوكلاء: يعمل الوكلاء عادةً داخل بيئات معزولة. وكيل إدارة علاقات العملاء (CRM) غير مدرك للرؤى المستمدة من وكيل مستودع البيانات. لا يستطيع وكيل الدعم الاستجابة للحالات الشاذة التي اكتشفها وكيل المراقبة.
• الاستخدام الهش والمخصص للأدوات: بدون طرق موحدة للوصول إلى الأدوات أو واجهات برمجة التطبيقات (APIs) الخارجية، يعتمد الوكلاء على عمليات التكامل المبرمجة بشكل ثابت والمنطق غير القابل لإعادة الاستخدام.
• أطر عمل غير متناسقة: تستخدم أوقات تشغيل الوكيل المختلفة نماذج متنوعة، وتعامل الوكلاء على أنهم روبوتات دردشة أو رسوم بيانية دورية موجهة (DAGs) أو مخططين متكررين. ينتج عن ذلك عدم وجود طبقة تنفيذ محمولة أو حالة مشتركة.
• تصميم يركز على بيئات دفتر الملاحظات: يتم تطوير العديد من الوكلاء كنماذج أولية لمرة واحدة، وتتميز بعمليات خطية ومتزامنة وزائلة. ومع ذلك، تتطلب الأنظمة الواقعية معالجة قوية لعمليات إعادة المحاولة والفشل والتنسيق والتسجيل والتحجيم، مما يتطلب بنية تحتية داعمة.
• غياب العمود الفقري التعاوني: لا يوجد ناقل للأحداث أو ذاكرة مشتركة أو سجل قابل للتتبع لأنشطة الوكيل وأسبابه. تقتصر المعلومات على مكالمات HTTP المباشرة أو مدفونة داخل السجلات.

كما أكد مشروع 12-Factor Agents، يجب أن يلتزم الوكلاء بالمبادئ الأصلية السحابية، وإظهار القدرة على الملاحظة، والاقتران المرن، وقابلية الاستنساخ، والوعي بالبنية التحتية. لسوء الحظ، يتم إنشاء الغالبية كبرامج نصية هشة، يتم تجميعها يدويًا ويُفترض أنها تعمل بشكل مستقل.

وينتج عن ذلك أوجه قصور وازدواجية في الجهود وهشاشة.

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

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

Agent2Agent (A2A) من Google: بروتوكول عالمي للاتصال بين الوكلاء

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

بالتوازي مع الطريقة التي وحد بها HTTP الاتصال بالموقع، يحدد A2A لغة مشتركة للوكلاء، مما يمكنهم من:

• الإعلان عن القدرات: عبر AgentCard، واصف JSON يحدد قدرات الوكيل وطرق التفاعل.
• إرسال واستقبال المهام: من خلال تفاعلات منظمة باستخدام JSON-RPC، حيث يطلب أحد الوكلاء المساعدة ويستجيب وكيل آخر بالنتائج أو “التحف”.
• تحديثات التدفق مع أحداث مرسلة من الخادم (SSEs): تسهيل الملاحظات في الوقت الفعلي أثناء المهام المطولة أو التعاونية.
• تبادل المحتوى المنسق: دعم تبادل الملفات والبيانات المنظمة والنماذج، بالإضافة إلى النص البسيط.
• الحفاظ على الأمان بشكل افتراضي: دمج الدعم المدمج لـ HTTPS والمصادقة والأذونات.

تكمن قوة A2A في تجنب إعادة اختراع الحلول المعمول بها. إنه يستفيد من معايير الويب الراسخة، على غرار HTTP و SMTP، مما يسهل التبني الأسهل والتكامل الأسرع.

ومع ذلك، فإن A2A يمثل جانبًا واحدًا فقط من الحل الشامل.

Model Context Protocol (MCP) من Anthropic: توحيد استخدام الأدوات والوصول إلى السياق

يعالج MCP من Anthropic الجانب الحاسم لكيفية استخدام الوكلاء للأدوات والوصول إلى المعلومات السياقية. يوحد MCP العملية التي يستدعي بها الوكلاء واجهات برمجة التطبيقات (APIs)، ويستدعي الوظائف، ويتكامل مع الأنظمة الخارجية، ويحدد بشكل أساسي كيف تعمل داخل بيئتهم. بينما يحكم A2A الاتصال بين الوكلاء، يركز MCP على تفاعل الوكيل مع العالم الخارجي.

في جوهره:

• MCP يمكّن ذكاء الوكيل الفردي.
• A2A يمكّن الذكاء الجماعي.

على غرار الطريقة التي احتاج بها HTTP و SMTP إلى اعتماد واسع النطاق وبنية تحتية وأدوات مطورين لتحقيق نجاح واسع النطاق، سيتطلب A2A و MCP نظامًا بيئيًا قويًا لتحقيق إمكاناتهما الكاملة.

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

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

سيؤدي توسيع نطاق هذا النظام إلى مئات الموظفين إلى الفوضى.

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

يوفر A2A و MCP للوكلاء اللغة والبنية للاتصال والعمل. ومع ذلك، فإن اللغة وحدها غير كافية. لتنسيق عدد كبير من الوكلاء عبر مؤسسة، هناك حاجة إلى بنية تحتية لإدارة تدفق الرسائل واستجابات الوكيل.

Kafka و Flink: العمود الفقري للتعاون القابل للتطوير بين الوكلاء

يوفر Apache Kafka و Apache Flink هذه البنية التحتية الحاسمة.

شرح Kafka و Flink

Apache Kafka، الذي تم تطويره في الأصل في LinkedIn وهو الآن مشروع Apache Software Foundation، هو نظام أساسي لتدفق الأحداث الموزعة. إنه يعمل كناقل رسائل متين وعالي الإنتاجية، مما يتيح للأنظمة نشر الأحداث في الوقت الفعلي والاشتراك فيها. يستخدم Kafka على نطاق واسع في تطبيقات مختلفة، بما في ذلك الأنظمة المالية واكتشاف الاحتيال وخطوط أنابيب القياس عن بعد، نظرًا لقدرته على فصل المنتجين عن المستهلكين وضمان متانة البيانات وقابليتها لإعادة التشغيل وقابليتها للتطوير.

Flink، وهو مشروع Apache آخر، هو محرك معالجة تدفق في الوقت الفعلي مصمم لمعالجة الأحداث ذات الحالة وعالية الإنتاجية ومنخفضة الكمون. بينما يدير Kafka حركة البيانات، يتعامل Flink مع تحويل البيانات وإثرائها ومراقبتها وتنظيمها أثناء تدفقها عبر النظام.

يشكل Kafka و Flink معًا مزيجًا قويًا. يعمل Kafka بمثابة مجرى الدم، بينما يعمل Flink كنظام رد الفعل.

بالتوازي مع دور A2A باعتباره HTTP لعالم الوكيل، يوفر Kafka و Flinkأساسًا قائمًا على الأحداث للاتصال والحساب القابلين للتطوير للوكلاء، ومعالجة التحديات التي لا يمكن للاتصال المباشر من نقطة إلى نقطة معالجتها:

• الفصل: مع Kafka، لا يحتاج الوكلاء إلى معرفة مستهلكي مخرجاتهم. يقومون بنشر الأحداث (مثل TaskCompleted و InsightGenerated) في موضوع، مما يسمح لأي وكيل أو نظام مهتم بالاشتراك.
• القدرة على الملاحظة وإعادة التشغيل: يحتفظ Kafka بسجل دائم ومرتب زمنيًا لجميع الأحداث، مما يضمن أن سلوك الوكيل قابل للتتبع والتدقيق وإعادة التشغيل بالكامل.
• اتخاذ القرارات في الوقت الفعلي: يسمح Flink للوكلاء بالتفاعل في الوقت الفعلي مع تدفقات الأحداث، وتصفية الإجراءات أو إثرائها أو ضمها أو تشغيلها بناءً على الظروف الديناميكية.
• المرونة والتحجيم: يمكن أن تتوسع وظائف Flink بشكل مستقل وتتعافى من حالات الفشل وتحافظ على الحالة عبر مهام سير العمل طويلة الأمد، وهو أمر ضروري للوكلاء الذين يؤدون مهام معقدة ومتعددة الخطوات.
• التنسيق الأصلي للتدفق: بدلاً من انتظار الاستجابات المتزامنة، يمكن للوكلاء التنسيق من خلال تدفقات الأحداث ونشر التحديثات والاشتراك في مهام سير العمل والتقدم بشكل تعاوني في الحالة.

باختصار:

• يحدد A2A كيفية تواصل الوكلاء.
• يحدد MCP كيفية تفاعلهم مع الأدوات الخارجية.
• يحدد Kafka كيفية تدفق رسائلهم.
• يحدد Flink كيفية معالجة هذه التدفقات وتحويلها واستخدامها لاتخاذ القرارات.

تعتبر البروتوكولات مثل A2A و MCP ضرورية لتوحيد سلوك الوكيل والاتصال. ومع ذلك، بدون طبقة أساسية قائمة على الأحداث مثل Kafka ووقت تشغيل أصلي للتدفق مثل Flink، يظل الوكلاء معزولين وغير قادرين على التنسيق بشكل فعال أو التوسع بكفاءة أو التفكير بمرور الوقت.

بنية الطبقات الأربع لوكلاء الذكاء الاصطناعي على مستوى المؤسسات

لتحقيق الرؤية الكاملة لوكلاء الذكاء الاصطناعي القابلين للتشغيل البيني على مستوى المؤسسات، يلزم وجود بنية ذات أربع طبقات:

• البروتوكولات: A2A، MCP - تحديد ماذا.
• أطر العمل: LangGraph، CrewAI، ADK - تحديد كيف.
• بنية المراسلة التحتية: Apache Kafka - دعم التدفق.
• الحساب في الوقت الفعلي: Apache Flink - دعم التفكير.

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

نحن حاليًا في نقطة حاسمة في تطور البرامج.

تمامًا كما أدى مكدس الإنترنت الأصلي - الذي يتكون من بروتوكولات مثل HTTP و SMTP وبنية تحتية مثل TCP/IP - إلى ظهور حقبة من الاتصال العالمي، يظهر مكدس جديد لوكلاء الذكاء الاصطناعي. ومع ذلك، بدلاً من تنقل البشر في صفحات الويب أو إرسال رسائل البريد الإلكتروني، تم تصميم هذا المكدس لأنظمة مستقلة تتعاون للتفكير واتخاذ القرارات والعمل.

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

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

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

لذلك، عند تطوير وكيل، من الضروري مراعاة تكامله داخل النظام الأوسع. هل يمكنه التواصل بفعالية؟ هل يمكنه التنسيق مع وكلاء آخرين؟ هل يمكن أن يتطور ويتكيف مع الظروف المتغيرة؟

المستقبل ليس مدعومًا بالوكيل فحسب؛ بل هو متصل بالوكيل.