يجب أن يبدأ تكامل وكلاء الذكاء الاصطناعي عبر السحابات المتعددة كتجربة سير عمل محدودة، وليس كبرنامج لقابلية التشغيل البيني. الهدف من التجربة التجريبية هو تحديد ما إذا كان الوكيل البعيد يحسّن سير عمل تجاري محدد بما يكفي لتبرير التبعيات الإضافية في الشبكة والهوية والتشغيل. ربط جميع النماذج والأدوات ومصادر البيانات وأطر عمل الوكلاء قبل الإجابة عن هذا السؤال يخلق طبقة تكامل كاملة قبل وجود أي دليل على الحاجة إليها.
تعتمد التجربة التجريبية العملية على خمسة حدود: سير عمل تجاري واحد، وعقد وكيل صغير، وبيانات اعتماد محلية لكل سحابة، ومعالجة صريحة للأخطاء، ومعايير خروج قابلة للقياس. يمكن لبروتوكولات الاتصال بين الوكلاء أن تساعد الوكلاء المبنيين بشكل مستقل على اكتشاف قدرات بعضهم البعض وتبادل العمل دون كشف ذاكرتهم الداخلية أو أدواتهم. توضح مواصفات بروتوكول A2A اكتشاف القدرات والتفاوض على الأنماط وإدارة المهام والتبادلات الآمنة باعتبارها من اهتمامات البروتوكول.
حدد أولاً ما إذا كان سير العمل يحتاج فعلاً إلى سحابتين
لا يُبرَّر التصميم متعدد السحابات إلا عندما يكون لكل سحابة دور دائم في سير العمل. قد يكون ذلك حدًا راسخًا للبيانات، أو خدمة مُدارة قائمة يكلف استبدالها، أو متطلبًا إقليميًا، أو قدرة اختارت المؤسسة توحيدها عمدًا. كون الشركة تشغّل بالفعل أعباء عمل على سحابتين لا يُعد بحد ذاته سببًا لخلق تبعية بين السحابات.
توصي إرشادات Google Cloud حول السحابات المتعددة المجزأة بالبدء بحمل عمل غير حرج للمهمة وتقليل التبعيات بين السحابات، خصوصًا التبعيات المتزامنة. وتحدد الأداء والتوافر وتكلفة نقل البيانات كعوامل يجب مراعاتها. يُذكّر نمط السحابات المتعددة المجزأة بشكل مفيد بأن الاستدعاء البعيد يجب ألا يُعامل كأنه استدعاء دالة داخل نفس العملية.
اختر سير عمل تجريبي بمدخل واضح ومخرج قابل للتحقق وبديل آمن. يمكن أن يكون المستدعي الذي يرسل طلبًا محدودًا إلى متخصص مستضاف عن بُعد مرشحًا معقولًا. أما المسار المعاملاتي الفوري الذي يتطلب استجابة عدة وكلاء متعددي السحابات بالتتابع فهو مرشح أولي ضعيف، لأنه يركّز تبعيات الشبكة والخدمة في مسار واحد.
اختبار تبرير من خمسة أسئلة
- هل تحتوي إحدى السحابتين على قدرة أو حد بيانات أو التزام تشغيلي لا يمكن نقله بشكل معقول لهذا السير العمل؟
- هل يمكن لسير العمل أن ينتهي بأمان إذا كان الوكيل البعيد بطيئًا أو غير متاح أو أعاد نتيجة غير قابلة للاستخدام؟
- هل يمكن للمستدعي تمرير حمولة مهمة صغيرة بدلاً من نسخ مجموعات بيانات واسعة بين السحابات؟
- هل يمكن للوكيل البعيد إعادة نتيجة محدودة يستطيع المستدعي التحقق منها؟
- هل سيقلل التنفيذ في سحابة واحدة بشكل جوهري من قيمة النتيجة التجارية؟
إذا كانت الإجابة النهائية لا، فأبقِ سير العمل في سحابة واحدة. هذه نتيجة مفيدة: فقد منعت التجربة التجريبية تبعية تكامل غير ضرورية.
استخدم عقد وكيل بدلاً من الارتباط بإطار عمل معين
الحد المهم في تكامل وكلاء الذكاء الاصطناعي متعدد السحابات هو عقد الوكيل. يجب أن يعرف الوكيل المستدعي ما يمكن للمتخصص البعيد فعله، والمدخلات التي يقبلها، وكيف يتقدم العمل، وكيف تُمثَّل الأخطاء. ويجب ألا يعتمد على تخطيط موجّهات الوكيل البعيد (prompt)، أو رسم التنسيق الداخلي، أو سجل الأدوات، أو مزود النموذج، أو الذاكرة الخاصة.
صُمم A2A للتواصل بين وكلاء مبنيين بشكل مستقل. تُظهر إرشادات Google ADK مستدعيًا يكتشف وكيلاً بعيدًا عبر بطاقة الوكيل الخاصة به ويستخدم نموذج مهام يدعم العمل المتزامن وغير المتزامن. يدعم دليل Google لـ ADK وA2A فكرة وضع الاكتشاف وحالة المهام عند حدود التكامل بدلاً من دمجها في محولات خاصة بإطار عمل معين.
اكتب العقد قبل تنفيذ الاتصال. عامله كاتفاقية API بمتطلبات خاصة بالوكلاء:
- القدرة: إجراء تجاري واحد مسمى بدقة.
- المدخلات: مخطط مُرقّم بالإصدارات، وقيود الحقول، وتصنيف البيانات، وحدود حجم الحمولة.
- المخرجات: حقول نتائج منظمة، وحالة التحقق، وأي تمثيل لعدم اليقين يستطيع المستدعي تفسيره.
- سلوك المهمة: ما إذا كان العمل فوريًا أو غير متزامن أو قابلاً للإلغاء أو قابلاً للاستئناف.
- الأخطاء: معالجة منفصلة لرفض التفويض، والمدخلات غير الصالحة، وعدم التوفر، وانتهاء المهلة، ورفض السياسة، وفشل التحقق من النتيجة.
- التوافق: إصدار للعقد، وعملية إيقاف تدريجي، وحالات اختبار للإصدارات المدعومة.
نقطة نهاية مفتوحة من نوع “اسأل الوكيل عن أي شيء” تُعد بداية ضعيفة لتكامل ذي طابع إنتاجي. فهي تجعل قواعد التحقق ومشاركة البيانات غامضة، ويمكن أن تحوّل تغييرات الموجّه إلى تغييرات توافق غير متتبعة.
اختر سطح التكامل بعناية
يمكن أن يظهر A2A وبروتوكول سياق النموذج (MCP) وأدوات OpenAPI والدوال المخصصة جميعها في قائمة أدوات الوكيل، لكنها تلبي احتياجات مختلفة. توثّق Microsoft Foundry A2A وMCP وOpenAPI والأدوات المخصصة كخيارات تكامل منفصلة. يمكن لقدرة Toolbox الخاصة بها توفير نقاط نهاية MCP منسّقة ومُرقّمة بالإصدارات. تساعد نظرة Microsoft Foundry العامة على الأدوات في إبقاء هذه الحدود واضحة.
| خيار التكامل | استخدمه عندما | نقطة اهتمام للتجربة التجريبية |
|---|---|---|
| A2A | النظام البعيد وكيل متخصص بقدرات قابلة للاكتشاف واحتياجات دورة حياة للمهام. | قدرات أو مخرجات مهام غامضة. |
| MCP | يحتاج الوكيل إلى وصول متحكَّم فيه إلى مجموعة منسّقة من الأدوات أو الموارد. | نمو الأدوات والتفويض غير المتسق عبر الخوادم. |
| OpenAPI أو API مخصصة | الإجراء البعيد حتمي ولا يحتاج إلى دلالات تفويض بين الوكلاء. | إدخال تعقيد الوكلاء حول استدعاء خدمة تقليدي. |
استخدم A2A للتفويض إلى وكيل، وMCP لحدود أدوات مُدارة، وواجهة برمجة تطبيقات تقليدية عندما تبقى العملية عملية خدمة تقليدية. يحافظ هذا التمييز على تركيز التجربة التجريبية على الحاجة الفعلية للتكامل.
أبقِ الهوية مع السحابة المالكة للمورد
يجب أن يوثّق الوكيل المستدعي هويته عند حدود الوكيل البعيد. ويجب أن يستخدم الوكيل البعيد هويته المحلية الخاصة لأدواته وبياناته. يتجنب هذا توزيع بيانات اعتماد واسعة عبر السحابات، ويسهّل تتبع مسؤولية التفويض.
تمتلك الوكلاء المستضافون في Microsoft Foundry نقاط نهاية مخصصة وهويات Microsoft Entra خاصة بكل وكيل. يمكن أن يكون للوكيل المستضاف نقطة نهاية A2A عند الإعلان عنها، مما يدعم متخصصًا على جانب Azure معزولًا عن بيانات اعتماده الداخلية. تصف وثائق Microsoft حول الوكلاء المستضافين خصائص نقاط النهاية والهوية هذه.
تصف إرشادات Microsoft لمصادقة A2A خيارات هوية الوكيل المُدار والمشروع، إلى جانب إسناد أدوار RBAC للخدمات اللاحقة. تدعم وثائق مصادقة A2A في Foundry استخدام هوية وتفويض من Azure ضيقَي النطاق عند الاقتضاء.
قاعدة الملكية
تمتلك كل سحابة بيانات اعتمادها وضوابط شبكتها وسجل التدقيق الخاص بها والوصول إلى بياناتها المحلية. تحمل حدود السحابات المتعددة طلبًا موثقًا بأصغر حمولة مفيدة ومعرّف ارتباط. يجب ألا يتلقى الوكيل البعيد بيانات اعتماد عامة الغرض تسمح له بالتصرف بشكل واسع في سحابة المستدعي.
يجعل هذا الفصل أيضًا التحقيق في الحوادث أكثر مباشرة. يمكن للمشغّلين التمييز بين مشكلة في بناء المهمة، وتفويض الحدود، وتنفيذ الوكيل البعيد، أو مشكلة أداة محلية لاحقة، دون الاعتماد على مجموعة بيانات اعتماد مشتركة.
صمّم للعمل غير المتزامن والاستعادة
يمكن أن يشمل استدعاء وكيل بعيد تبادل الهوية، والعبور عبر الشبكة، والانتظار في طابور، والتحقق من السياسات، وتنفيذ الأدوات، وإعادة المحاولات، والتحقق من النتيجة. تغطي إرشادات Google حول الشبكات الهجينة ومتعددة السحابات الاتصال المرن والاهتمامات ذات الصلة بما فيها زمن الاستجابة والإنتاجية والتوافر. توفر معماريات Google Cloud المرجعية للشبكات الهجينة ومتعددة السحابات سياقًا بنيويًا مهمًا لتصاميم الوكلاء على مستوى التطبيق.
استخدم التفويض غير المتزامن عندما يمكن أن تتجاوز المهمة مهلة انتظار طلب مواجه للمستخدم. يمكن للمستدعي تقديم مهمة، وتسجيل حالتها، واستئنافها عند وصول نتيجة نهائية. تناسب الاستدعاءات المتزامنة فقط العمل القصير والمحدود، عندما يستطيع المستدعي إعادة بديل مفيد إذا لم تستجب التبعية البعيدة.
ضع سلوك الاستعادة في العقد. قد يؤدي عدم توفر متخصص بعيد إلى مهمة منتظرة في طابور، أو مراجعة بشرية، أو بديل حتمي، أو استجابة موسومة بوضوح كغير مكتملة. يجب أن يكون سلوك إعادة المحاولة محدودًا وألا يكرر الإجراءات اللاحقة بصمت.
قِس التجربة التجريبية كسير عمل تشغيلي
يُظهر العرض التوضيحي أن وكيلين يمكنهما تبادل رسالة. يجب أن تُظهر التجربة التجريبية أن سير العمل يمكن تشغيله وتشخيصه وإيقافه. عندما يوجد مسار مماثل في سحابة واحدة، أنشئ خط أساس بمدخلات تمثيلية وقارنه بالمسار متعدد السحابات.
تتبّع زمن الإنجاز الكلي، وزمن تنفيذ الوكيل البعيد، وتكرار انتهاء المهلة، وحالات فشل التحقق من العقد، وحالات فشل التفويض، وعدد إعادة المحاولات، ومعدل المهام غير المكتملة، ونتيجة الاستعادة. قسّم النتائج حسب إصدار العقد وفئة الفشل. يشير فشل تفويض سريع وانتهاء مهلة بطيء قابل للاستعادة إلى عملَي هندسة مختلفَين.
سجل المراقبة الأدنى
- معرّف ارتباط ينشئه المستدعي ويُحمل عبر الطلبات والاستدعاءات الراجعة.
- إصدار العقد والقدرة البعيدة المعلنة.
- انتقالات حالة المهمة، بما في ذلك قرارات الإلغاء وإعادة المحاولة.
- نتيجة المصادقة عند الحدود، دون تسجيل الأسرار أو الرموز الحساسة.
- فترات زمن الاستجابة للعبور عبر الشبكة، والتنسيق البعيد، والمعالجة اللاحقة المحلية.
- مراجع مدخلات ومخرجات منقّاة تتوافق مع سياسة تصنيف البيانات المعمول بها.
- تصرف نهائي: مكتمل، مؤجل، موجَّه يدويًا، أو فاشل.
اختبر الظروف المتدهورة قبل توسيع النطاق. في بيئة اختبار، جرّب فشل التفويض، والاستجابة المتأخرة، والمخرج المنظم غير الصالح، والاستدعاء الراجع غير المتاح، وحدث إتمام مكرر، وعدم توفر الطرف البعيد. الهدف هو سلوك يمكن التنبؤ به، وقياس عن بُعد مفيد، وعدم وجود أي إجراء غير مصرح به.
مخطط تجريبي من أربع مراحل
- أثبت مهمة واحدة: اربط مستدعيًا واحدًا بوكيل متخصص واحد بمجموعة ثابتة من حالات اختبار غير حساسة. تأكد من الاكتشاف والمصادقة والمخرج المنظم وقابلية التتبع.
- عزّز الحدود: رقّم العقد بالإصدارات، وتحقق من المدخلات، وطبّق مبدأ الامتياز الأقل، وأضف معرّفات ارتباط، ووثّق تصرفات الفشل.
- اختبر التشغيل المتدهور: شغّل سيناريوهات زمن الاستجابة، وانتهاء المهلة، والنتيجة غير الصالحة، والتفويض، والتسليم المكرر، وعدم توفر الطرف البعيد. تأكد من بقاء سير العمل التجاري آمنًا.
- اتخذ قرار المعمارية: احتفظ بحدود السحابات المتعددة فقط عندما تفوق قيمتها المقاسة المسؤولية التشغيلية الإضافية. وإلا، وحّد سير العمل أو احتفظ بتكامل API أبسط.
أبقِ التجربة التجريبية غير حرجة للمهمة حتى تكتمل هذه المراحل. البدء بحمل عمل أقل خطورة يتبع إرشادات السحابات المتعددة المجزأة ويترك مجالًا لتحديد فجوات الشبكة والتشغيل والحوكمة قبل أن تعتمد عملية أساسية على هذا الحد.
قائمة تحقق التنفيذ
- اكتب نتيجة تجارية في جملة واحدة وسببًا في جملة واحدة يوضح لماذا يمتد سير العمل عبر السحابات.
- عيّن مسؤولاً عن المستدعي، والوكيل البعيد، والعقد، ودليل التعامل مع الحوادث.
- انشر قدرة مُرقّمة بالإصدارات ومخطط مهام مع أمثلة صالحة وغير صالحة.
- قصر الوكيل البعيد على الأدوات والبيانات اللازمة لتلك القدرة.
- استخدم هوية مُدارة محلية للسحابة وRBAC عند توفرهما.
- حدد مهلات صريحة، وسلوك إلغاء، وحدود إعادة محاولة، وقواعد للتكرار الآمن (idempotency).
- اختر التنفيذ المتزامن أو غير المتزامن بناءً على مدة المهمة واحتياجات البديل.
- سجّل معرّفات الارتباط، وانتقالات المهام، وحالات فشل الحدود، والنتائج الكلية.
- شغّل اختبارات فشل مضبوطة وتحقق من أن سير العمل لا يكرر أو يفوّض إجراءات غير مقصودة.
- وثّق مسار خروج نحو تصميم بسحابة واحدة أو API تقليدية.
الأسئلة الشائعة
هل A2A ضروري لتكامل وكلاء الذكاء الاصطناعي متعدد السحابات؟
لا. يفيد A2A عندما يفوّض وكيل إلى وكيل آخر ويحتاج إلى اكتشاف القدرات أو دلالات دورة حياة المهام. يمكن أن تكون واجهة برمجة تطبيقات تقليدية أنسب للعمليات البعيدة الحتمية، بينما يناسب MCP كشف أدوات وموارد متحكَّم فيها.
ما هو أهم خطر في المراحل المبكرة؟
قد يُصمَّم وكيل بعيد عن طريق الخطأ وكأنه دالة محلية. تُدخل الاستدعاءات متعددة السحابات اهتمامات تتعلق بالشبكة والهوية والتوافر والمراقبة. يجعل العقد الضيق وسلوك البديل الصريح هذه الاهتمامات قابلة للاختبار.
هل يجب أن تستخدم التجربة التجريبية طلبات متزامنة؟
استخدمها فقط للمهام القصيرة والمحدودة مع بديل آمن. أما للعمل الأطول، فيمكن للمعالجة غير المتزامنة للمهام أن تحافظ على حالة المهمة عبر زمن الاستجابة وانقطاعات الخدمة دون إبقاء طلب تفاعلي مفتوحًا.
متى يجب على فريق تجنب تصميم وكيل متعدد السحابات؟
تجنّبه عندما لا توجد حاجة دائمة لسحابتين، أو عندما لا يستطيع سير العمل تحمّل إخفاقات التبعية البعيدة، أو عندما يتطلب تنسيقًا تتابعيًا منخفض زمن الاستجابة، أو عندما تستطيع خدمة بسحابة واحدة أو واجهة برمجة تطبيقات عادية تلبية الحاجة بشكل نظيف.
المصادر
- A2A Protocol Official Specification
- Hosted Agents in Microsoft Foundry Agent Service
- Agent2Agent Authentication in Microsoft Foundry
- Agent Tools Overview for Microsoft Foundry Agent Service
- Partitioned Multicloud Pattern
- Networking for Hybrid and Multi-Cloud Workloads
- Build a Cross-Language Multi-Agent Team with Google’s ADK and A2A
ملاحظة تحريرية: ساهم الذكاء الاصطناعي في البحث والصياغة. تم اختيار المصادر بغرض التحقق.
Full-Stack Developer & Solutions Architect · Casablanca, Morocco
8+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.