التحدي المتمثل في الأنظمة البيئية المجزأة للوكلاء
يواجه تطوير وكلاء الذكاء الاصطناعي حاليًا تحديات كبيرة تتعلق بالتجزئة وعدم إمكانية التشغيل البيني. هذه التحديات تعيق إنشاء أنظمة ذكاء اصطناعي قوية وقابلة للتطوير:
- الوكلاء المعزولون: غالبًا ما يعمل الوكلاء في صوامع، غير قادرين على التواصل أو تبادل المعلومات. قد يكون وكيل إدارة علاقات العملاء (CRM) على سبيل المثال غير مدرك للرؤى التي اكتشفها وكيل مستودع البيانات، مما يؤدي إلى ضياع الفرص وعدم الكفاءة.
- استخدام الأدوات الهشة: بدون بروتوكولات موحدة لاستدعاء الأدوات وواجهات برمجة التطبيقات (APIs)، يعتمد الوكلاء على عمليات تكامل مبرمجة بشكل ثابت يصعب صيانتها وإعادة استخدامها. وهذا يحد من قدرتهم على التكيف مع البيئات المتغيرة والاندماج مع الأنظمة الجديدة.
- أطر عمل غير متسقة: تستخدم أوقات تشغيل الوكلاء المختلفة نماذج متنوعة، وتعامل الوكلاء كبرامج دردشة آلية أو رسوم بيانية دورية موجهة (DAGs) أو مخططين متكررين. هذا النقص في الاتساق يجعل من الصعب إنشاء وكلاء محمولة وقابلة للتشغيل البيني.
- التطوير الذي يركز على النماذج الأولية: تم تصميم العديد من الوكلاء كنماذج أولية لمرة واحدة، تفتقر إلى المتانة وقابلية التوسع المطلوبة لعمليات النشر في العالم الحقيقي. غالبًا ما يفشلون في معالجة القضايا الهامة مثل إعادة المحاولات والفشل والتنسيق والتسجيل والتحجيم.
- الافتقار إلى العمود الفقري للتعاون: إن عدم وجود ناقل أحداث مركزي أو ذاكرة مشتركة أو سجل قابل للتتبع لإجراءات الوكيل يعيق التعاون والتنسيق. غالبًا ما تكون المعلومات محصورة في مكالمات HTTP مباشرة أو مدفونة في السجلات، مما يجعل من الصعب فهم سلوك الوكيل وتصحيحه.
يكمن الحل ليس في دمج جميع الوكلاء في نظام أساسي متجانس، ولكن في بناء مجموعة مشتركة تعتمد على بروتوكولات مفتوحة وهندسة موجهة للأحداث ومعالجة في الوقت الفعلي. يعزز هذا النهج إمكانية التشغيل البيني وقابلية التوسع والمرونة.
Agent2Agent: توحيد معايير اتصالات الوكيل
بروتوكول A2A من Google هو خطوة مهمة نحو معالجة مشكلة قابلية التشغيل البيني للوكلاء. يوفر بروتوكولًا عالميًا لتوصيل الوكلاء، بغض النظر عن أصلهم أو بيئة وقت التشغيل. من خلال تحديد لغة مشتركة للوكلاء، يمكّنهم A2A من:
- الإعلان عن القدرات: يمكن للوكلاء الإعلان عن قدراتهم من خلال
AgentCard، وهو واصف JSON يحدد ما يمكن للوكيل القيام به وكيفية التفاعل معه. يتيح ذلك للوكلاء الآخرين اكتشاف خدماتهم واستخدامها. - تبادل المهام: يسهل A2A التفاعلات المنظمة بين الوكلاء من خلال JSON-RPC، حيث يطلب أحد الوكلاء المساعدة من وكيل آخر ويتلقى النتائج أو المصنوعات اليدوية ردًا على ذلك. يتيح ذلك للوكلاء التعاون في المهام المعقدة.
- تحديثات البث: يمكن للوكلاء بث تعليقات في الوقت الفعلي أثناء المهام طويلة الأمد أو التعاونية باستخدام أحداث مرسلة من الخادم (SSEs). يوفر هذا الشفافية ويسمح للوكلاء بمراقبة التقدم المحرز والتفاعل مع التغييرات.
- تبادل المحتوى الغني: يدعم A2A تبادل الملفات والبيانات المنظمة والنماذج، وليس النصوص العادية فقط. يتيح ذلك للوكلاء تبادل المعلومات المعقدة والتعاون في مجموعة واسعة من المهام.
- ضمان الأمان: يتضمن A2A دعمًا مدمجًا لـ HTTPS والمصادقة والأذونات، مما يضمن الاتصال الآمن بين الوكلاء. هذا أمر بالغ الأهمية لحماية البيانات الحساسة ومنع الوصول غير المصرح به.
بروتوكول سياق النموذج: تمكين استخدام الأدوات والوعي بالسياق
يكمل MCP الخاص بـ Anthropic A2A من خلال توحيد كيفية استخدام الوكلاء للأدوات والوصول إلى السياق الخارجي. يحدد كيفية قيام الوكلاء باستدعاء واجهات برمجة التطبيقات واستدعاء الوظائف والاندماج مع الأنظمة الخارجية، مما يمكنهم من التفاعل مع العالم الحقيقي.
في حين أن A2A يركز على كيفية تواصل الوكلاء مع بعضهم البعض، فإن MCP يركز على كيفية تفاعل الوكلاء مع بيئتهم. يوفر هذان البروتوكولان معًا مخططًا شاملاً لنظام بيئي متصل للوكلاء:
- MCP يمكّن ذكاء الوكيل الفردي من خلال توفير الوصول إلى الأدوات والمعلومات.
- A2A يمكّن الذكاء الجماعي من خلال تسهيل التواصل والتعاون بين الوكلاء.
الحاجة إلى بنية تحتية قوية للاتصالات
تخيل شركة يمكن للموظفين فيها التواصل فقط من خلال رسائل مباشرة فردية. سيتطلب تبادل التحديثات إرسال رسائل إلى كل شخص على حدة، وسيتضمن تنسيق المشاريع عبر فرق متعددة نقل المعلومات يدويًا بين المجموعات. مع نمو الشركة، يصبح هذا النهج فوضويًا وغير مستدام بشكل متزايد.
وبالمثل، تصبح الأنظمة البيئية للوكلاء المبنية على اتصالات مباشرة هشة ويصعب توسيع نطاقها. يجب أن يعرف كل وكيل من يتحدث إليه وكيفية الوصول إليه ومتى يكون متاحًا. مع زيادة عدد الوكلاء، يزداد عدد الاتصالات المطلوبة بشكل كبير، مما يجعل النظام غير قابل للإدارة.
يوفر A2A و MCP للوكلاء اللغة والبنية للتواصل والتصرف، لكن اللغة وحدها لا تكفي. لتنسيق عدد كبير من الوكلاء عبر مؤسسة، هناك حاجة إلى بنية تحتية قوية لإدارة تدفق الرسائل وردود أفعال الوكيل.
Apache Kafka و Apache Flink: العمود الفقري لتنسيق الوكيل
توفر Apache Kafka و Apache Flink البنية التحتية اللازمة لدعم اتصالات الوكيل وحساباته القابلة للتطوير. يعمل Kafka كمنصة بث أحداث موزعة، بينما Flink هو محرك معالجة تدفق في الوقت الفعلي.
يعمل Kafka، الذي تم تطويره في الأصل في LinkedIn، كناقل رسائل دائم وعالي الإنتاجية، مما يسمح للأنظمة بنشر والاشتراك في تدفقات الأحداث في الوقت الفعلي. إنه يفصل المنتجين عن المستهلكين ويضمن أن البيانات متينة وقابلة للإعادة وقابلة للتطوير. يستخدم 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 التفكير من خلال معالجة وتحويل تدفقات البيانات في الوقت الفعلي.
تمثل هذه المجموعة المكونة من أربع طبقات مجموعة الإنترنت الجديدة لوكلاء الذكاء الاصطناعي، مما يوفر أساسًا لبناء أنظمة ليست ذكية فحسب، بل أيضًا تعاونية وقابلة للمراقبة وجاهزة للإنتاج.
التحرك نحو نظام بيئي متصل للوكلاء
نحن في لحظة محورية في تطور البرامج. تمامًا كما أطلقت مجموعة الإنترنت الأصلية حقبة جديدة من الاتصال العالمي، تظهر مجموعة جديدة لوكلاء الذكاء الاصطناعي. تم تصميم هذه المجموعة للأنظمة المستقلة التي تعمل معًا للتفكير واتخاذ القرارات والتصرف.
يوفر A2A و MCP البروتوكولات لاتصال الوكيل واستخدام الأدوات، بينما يوفر Kafka و Flink البنية التحتية للتنسيق في الوقت الفعلي والمراقبة والمرونة. إنهم يجعلون من الممكن الانتقال من عروض الوكيل المنفصلة إلى أنظمة بيئية ذكية وقابلة للتطوير على مستوى الإنتاج.
لا يتعلق الأمر فقط بحل التحديات الهندسية؛ يتعلق الأمر بتمكين نوع جديد من البرامج حيث يتعاون الوكلاء عبر الحدود، ويوفرون رؤى وتدفقات إجراءات في الوقت الفعلي، والسماح للذكاء بأن يصبح نظامًا موزعًا.
لتحقيق هذه الرؤية، نحتاج إلى البناء بشكل مفتوح وقابل للتشغيل البيني ومع وضع دروس ثورة الإنترنت الأخيرة في الاعتبار. في المرة القادمة التي تقوم فيها ببناء وكيل، لا تسأل فقط عما يمكنه فعله. اسأل كيف يتناسب مع النظام الأكبر:
- هل يمكنه التواصل مع الوكلاء الآخرين؟
- هل يمكنه تنسيق أفعاله مع الآخرين؟
- هل يمكنه التطور والتكيف مع الظروف المتغيرة؟
المستقبل ليس مدعومًا بالوكلاء فحسب؛ بل إنه متصل بالوكلاء.