دليل المطورين لأنماط الوكلاء المتعددين باستخدام ADK

الصفحة الرئيسية » Python » دليل المطورين لأنماط الوكلاء المتعددين باستخدام ADK

تتجاوز تطبيقات الوكلاء بسرعة نمط "الرسالة الضخمة الواحدة" التقليدي، ويحتاج المطورون إلى نموذج ذهني متين لتنظيم وكلاء متعددين دون الوقوع في الفوضى. صُممت مجموعة أدوات تطوير الوكلاء (ADK) من جوجل خصيصًا لهذا الغرض: فهي تتيح لك إنشاء أنظمة وكلاء متعددة موثوقة، وربط الأدوات والذاكرة، ونشر كل شيء على جوجل كلاود مع إمكانية مراقبة وأمان وتحكم في التكاليف على مستوى الإنتاج.

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

لماذا تُستخدم أنظمة متعددة العوامل في ADK؟

عندما يعتمد تطبيق ما على موجه واحد ضخم، يصبح من الصعب فهمه واختباره وتطويره. فالموجهات الضخمة هشة، ويصعب تصحيح أخطائها، ويصعب صيانتها مع ازدياد المتطلبات. يدفعك ADK ​​نحو بناء نظام متعدد الوكلاء (MAS) حيث يكون لكل وكيل مسؤولية محددة، وتكون عملية التنسيق واضحة.

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

يوفر لك ADK ​​لبنات بناء ملموسة لتحقيق ذلك: وكلاء يركزون على LLM، ووكلاء سير العمل (متسلسل، متوازي، حلقي) ووكلاء مخصصين يغلفون منطقًا غير LLM. جميعهم يرثون من أصل مشترك BaseAgentلذلك فهي تتصل بنفس نموذج التنسيق، والتسجيل، ومعالجة الحالة، ونظام الأدوات.

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

أدوات ADK الأساسية لتكوين العوامل

تُتيح ADK مجموعة صغيرة من العناصر الأساسية التي يمكنك دمجها للتعبير عن بنى متعددة العوامل غنية بشكلٍ مدهش. إن فهم هذه المفاهيم الأساسية يُسهّل كثيراً التفكير في الأنماط ذات المستوى الأعلى لاحقاً.

العنصر الأساسي الأول هو التسلسل الهرمي للوكلاء: يمكن لكل وكيل أن يعلن عن قائمة من sub_agents، لتشكيل شجرة بواحدة root_agent في القمة. عندما تُسلّم الأطفال إلى sub_agentsتقوم ADK بتوصيلها تلقائيًا parent_agent ويؤكد على أن لكل نسخة أصلًا واحدًا فقط (وإلا...). ValueError (يُثار).

إن هذا التسلسل الهرمي ليس مجرد ديكور: فهو يحدد أي الوكلاء مسموح لهم بالتفويض إلى أي وكيل، وهو النطاق الذي تستخدمه وكلاء سير العمل والنقل المدفوع بـ LLM. يمكنك الصعود من أي وكيل عبر agent.parent_agent أو العثور على أحفاد مع agent.find_agent(name)، وهو أمر مفيد للغاية لتصحيح الأخطاء.

بالإضافة إلى وكلاء إدارة دورة حياة المنتج الأساسيين، يقدم ADK وكلاء سير عمل مخصصين – SequentialAgent, ParallelAgent و LoopAgent - الذي لا تتمثل وظيفته في "التفكير" بل في تنسيق العملاء الفرعيين. جميعها تشترك في نفس الواجهة ولكنها تنفذ استراتيجيات تنفيذ مختلفة: التشغيل بالترتيب، أو التوزيع بالتوازي، أو التكرار في حلقة مع قواعد إنهاء صريحة.

أما العنصر الأساسي الثالث فهو طبقة الاتصال، التي تتمحور حول المشترك Session ولها state قاموس. تُشبه حالة الجلسة لوحة بيضاء مشتركة: يمكن لأي وكيل أو أداة كتابة نتائج أو علامات وسيطة، ويمكن للوكلاء الآخرين في نفس الاستدعاء قراءتها، غالبًا عبر قوالب المفاتيح داخل تعليماتهم (على سبيل المثال {PLOT_OUTLINE?}).

كيف يتواصل العملاء مع بعضهم البعض في ADK

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

حالة الجلسة المشتركة (session.state) هي الآلية الأبسط والأكثر انتشاراً. في عملية استدعاء واحدة، يرى جميع العملاء نفس الشيء Session الكائن عبر InvocationContextيمكن لأداة أو دالة رد نداء القيام بذلك. context.state = valueويمكن لوكيل لاحق استعادته باستخدام context.state.get("data_key")بالنسبة لوكلاء إدارة التعلم، يتم ضبط output_key يتم حفظ إجابتهم النهائية تلقائيًا تحت هذا المفتاح.

تتيح عملية التفويض التي يقودها مديرو التعلم القانوني، والتي تسمى أحيانًا "نقل الوكيل"، لمدير التعلم القانوني تحديد متى يتم تسليم المهمة إلى وكيل آخر بناءً على التعليمات وأوصاف الوكيل. داخليًا، يُصدر النموذج استدعاء دالة خاصة مثل transfer_to_agent(agent_name="screenwriter"). ADK's AutoFlow يعترض هذا الاستدعاء ويعيد توجيه التنفيذ إلى الوكيل المختار ضمن النطاق المسموح به (الأصل، والأبناء، والأشقاء حسب التكوين).

استدعاء صريح مع AgentTool يمنحك طريقة أكثر تحكمًا ووظيفية لاستدعاء وكيل من وكيل آخر. تقوم بتغليف مثيل الوكيل المستهدف في AgentToolأضفها إلى المتصل tools القائمة، ويمكن لبرنامج إدارة التعلم (LLM) بعد ذلك تحديد تلك الأداة كأي وظيفة أخرى. عند استدعائها، AgentTool.run_async يقوم بتنفيذ الوكيل الفرعي، ودمج الحالة والقطع الأثرية مرة أخرى، وإرجاع استجابة الوكيل الفرعي كنتيجة للأداة.

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

المكونات الأساسية: وكلاء إدارة دورة حياة المنتج، ووكلاء سير العمل، والوكلاء المخصصون

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

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

تعمل وكلاء سير العمل كمديرين بدلاً من عمال: فهم لا يفكرون بأنفسهم، لكنهم يتحكمون في ترتيب وتوازي وتكرار تنفيذ الوكلاء الفرعيين. SequentialAgent يدير أطفاله واحداً تلو الآخر بينما يتشاركون نفس InvocationContext, ParallelAgent تتوزع الفروع عبر فروع متعددة تشترك في الولاية ولكن لكل منها تاريخها الخاص، و LoopAgent ينفذ التسلسل بشكل متكرر حتى يتم استيفاء شرط التوقف.

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

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

حالة الجلسة وأنماط الذاكرة

تُشكل حالة الجلسة في ADK أساسًا لكل من الذاكرة الحوارية قصيرة المدى ونقل البيانات المنظمة بين الوكلاء. كل محادثة تستخدم Session كائن يحتوي على سجل الرسائل وقابل للتغيير state قاموس متاح لجميع الوكلاء في هذا الاستدعاء.

تتم كتابة البيانات إلى الحالة عادةً داخل الأدوات أو ردود الاتصال، باستخدام ToolContext or CallbackContext موضوع. على سبيل المثال، أداة مثل save_attractions_to_state(tool_context, attractions: List) يمكن دمج مناطق الجذب الجديدة مع تلك المخزنة بالفعل تحت state، حيث يقوم بإعادة رسالة حالة بسيطة إلى الوكيل بينما يحتفظ ADK بتغيرات الحالة في الجلسة.

تتم عملية القراءة من خلال قوالب المفاتيح المضمنة في التعليمات، مما يجعلها مريحة للاستخدام. عندما تحتوي التعليمات على {my_key?}سيقوم ADK بالحقن state إذا كان موجودًا؛ علامة الاستفهام تجعله اختياريًا حتى لا يفشل البرنامج عند فقدان المفتاح. هذا أمر بالغ الأهمية في سير العمل مثل "بحث ← كتابة ← مراجعة" حيث تقرأ كل خطوة ما تم حفظه في الخطوة السابقة.

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

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

SequentialAgent: سير العمل الخطي أصبح واضحًا

SequentialAgent هذا هو النمط الذي تلجأ إليه عندما يكون لديك سلسلة من الخطوات التي يجب أن تحدث بترتيب ثابت. فكر في مسارات مثل "تحليل الطلب ← البحث ← المسودة ← الحفظ في ملف" أو "تحديد الوجهة ← تخطيط المسار ← حجز وسيلة النقل".

في ADK، أ SequentialAgent تحتوي على قائمة بـ sub_agents ويجريها واحدة تلو الأخرى، ويمررها بنفس الطريقة InvocationContext عبر السلسلة بأكملها. لأن Session و state إذا تمت مشاركتها، يمكنك جعل الوكيل الأول يخزن نتيجته تحت output_key="destination" ثم قرأها الوكيل التالي عبر {destination} في تعليماتها بدون أي رمز ربط.

ومن الأمثلة الكلاسيكية على ذلك مولد عروض الأفلام: حيث يتحدث وكيل رئيسي مع المستخدم، ثم يسلم العمل إلى... SequentialAgent وهذا يستدعي باحثاً، ثم كاتب سيناريو، ثم كاتب ملفات. لا يرى المستخدم سوى النتيجة النهائية، لكن مخطط الأحداث في ADK Web يكشف عن الشجرة الداخلية: greeter → film_concept_team → .

بالمقارنة مع التنسيق اليدوي مع التنسيق الصريح if/elif الكتل واستدعاءات الدوال، SequentialAgent يحافظ على تدفق التحكم تصريحيًا ويقلل من التعليمات البرمجية المتكررة. تقوم بتعريف التسلسل مرة واحدة وتتعامل معه كعامل واحد قابل للاستدعاء في برنامج التشغيل أو واجهة المستخدم الخاصة بك، مع الاستفادة من حالة الجلسة لتمرير البيانات بين الخطوات.

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

LoopAgent: التحسين التكراري وغرف الكتابة

LoopAgent تم تصميمه للمهام التي تستفيد من عدة تمريرات على العمل حتى يتم استيفاء عتبة الجودة. بدلاً من اتباع نهج "التوليد مرة واحدة والأمل في الأفضل"، يمكنك ترميز عملية الاقتراح والنقد والتحسين.

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

تتوقف الحلقات في ظل شرطين: الوصول إلى max_iterations أو وكيل فرعي يشير إلى أن العمل قد تم إنجازه. يوفر ADK أداة مدمجة مثل exit_loop أن بإمكان الناقد الاتصال عندما تجتاز خطة أو مخطط أو تصميم قائمة التحقق الداخلية الخاصة به. LoopAgent كما يحترم escalate=True العلم في Event إجراءات تمنحك طريقة أخرى للانطلاق مبكراً.

تُعد حالة الجلسة المستمرة أساسية هنا: تقرأ الوكلاء المفاتيح مثل PLOT_OUTLINE, research or CRITICAL_FEEDBACK واكتب نسخًا محسّنة أو تعليقات إضافية في كل مراجعة. يحاكي هذا النمط بشكل فعال "غرفة الكتابة" حيث يقوم المتخصصون بتبادل الأفكار والنقد والصقل حتى يعلن أحدهم أن العمل جاهز.

من خلال الجمع بين LoopAgent مع SequentialAgentيمكنك وضع الحلقة التكرارية بأكملها كخطوة واحدة فقط في سير عمل شامل من البداية إلى النهاية. على سبيل المثال، writers_room قد يتم تشغيل (LoopAgent) أولاً لإنتاج مخطط تفصيلي متين، وبعد ذلك... file_writer يقوم البرنامج بحفظ النتيجة وإرفاق التقارير الأخرى.

ParallelAgent: انتشر واجمع لإنجاز المهام المستقلة

ParallelAgent يطبق نمط "التفرع / التجميع" الكلاسيكي للمهام المستقلة ولكنها تشترك في السياق. بدلاً من تشغيل N خطوة بحثية على التوالي، تقوم بتشغيلها جميعًا في وقت واحد وتنتظر حتى تكتمل جميعها، ثم تجمع مخرجاتها.

داخليا، ParallelAgent يمنح كل عميل فرعي سمة مميزة InvocationContext.branch - مثل ParentBranch.ChildName - مع الاستمرار في مشاركة نفس session.state. هذا يعني أنه بإمكانهم جميعًا قراءة السياق الأولي مثل PLOT_OUTLINEولكن ينبغي كتابة المخرجات إلى مفاتيح حالة مميزة (على سبيل المثال box_office_report, casting_report) لتجنب الصراعات.

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

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

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

أنماط التنسيق باستخدام عناصر ADK الأساسية

بمجرد فهمك للتسلسل الهرمي، ووكلاء سير العمل، والحالة، يمكنك تطبيق العديد من أنماط الوكلاء المتعددين الكلاسيكية مباشرة في ADK. هذه الأنماط ليست بدائيات مبرمجة مسبقًا، بل هي تركيبات مبنية باستخدام نفس اللبنات الأساسية.

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

نمط خط الأنابيب المتسلسل هو ببساطة SequentialAgent يقوم كل طفل من أطفالهم بتنفيذ خطوة محددة النطاق من عملية ما. تُعدّ تدفقات المُولِّد والناقد نوعًا كلاسيكيًا: يقوم العامل الأول بكتابة مسودة وحفظها تحت output_keyيقوم الوكيل الثاني بتحليلها وحفظ التعليقات، وربما يقوم وكيل ثالث بتحسين النتيجة بناءً على تلك التعليقات.

يُعبَّر عن نمط التفرع/التجميع المتوازي على النحو التالي: ParallelAgent متداخلة داخل سير عمل متسلسل. تقوم العمليات الفرعية المتوازية بكتابة النتائج في مفاتيح حالة منفصلة؛ ثم يقوم وكيل توليف لاحق بقراءتها مرة أخرى وتقديم إجابة مجمعة.

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

التحسين التكراري مع LoopAgent يُضفي الطابع الرسمي على حلقة المولد-الناقد في نمط قابل لإعادة الاستخدام. تقوم الحلقة بتنفيذ عوامل التخطيط والنقد والتنقيح عدة مرات، باستخدام مفاتيح الحالة للاحتفاظ بأحدث خطة والتعليقات المقابلة، وتتوقف عند الوصول إلى معيار الجودة أو الحد الأقصى للتكرار.

بنية مرجعية لأنظمة متعددة الوكلاء على جوجل كلاود

إلى جانب منطق الوكلاء، لا يزال عليك تشغيل نظامك في مكان ما، وتوفر Google Cloud بنية مرجعية محددة جيدًا لعمليات نشر متعددة الوكلاء على مستوى الإنتاج. بشكل عام، يجمع الحل بين واجهة أمامية، وبيئات تشغيل الوكلاء، ونماذج Vertex AI، وخدمات الأمان، وأطر عمل أدوات اختيارية مثل MCP.

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

يمكن تشغيل الوكلاء أنفسهم في بيئات متعددة: خدمات Cloud Run، أو Google Kubernetes Engine (GKE)، أو Vertex AI Agent Engine. يغطي ADK هذه الخيارات، حيث يُخفي بعض تفاصيل وقت التشغيل، مما يسمح للمطور بالتركيز على منطق الوكيل بدلاً من بنية التحتية.

تعتمد جميع استدعاءات الوكلاء على Vertex AI أو بيئات تشغيل نماذج أخرى للاستدلال، وغالبًا ما تُغلّف بـ Model Armor لتنقية المطالبات والاستجابات. يساعد Model Armor في تصفية محاولات حقن المطالبات، أو تسريبات البيانات الحساسة، أو المحتوى الضار قبل أو بعد استدعاءات النموذج، ويعمل كحاجز أمان حول المكونات التوليدية.

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

الأمن والحوكمة لتطبيقات الوكلاء

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

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

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

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

تُكمّل ميزات الأمان القياسية في Google Cloud الصورة: عناصر تحكم خدمة VPC للحد من مخاطر تسريب البيانات، وCMEK لمفاتيح التشفير التي يديرها العميل، وCloud Armor لجدار حماية تطبيقات الويب (WAF) وحماية DDoS، وIAP أو منصة الهوية لمصادقة المستخدمين، وIAM دقيق للوصول إلى الموارد. للتواصل بين الوكلاء عبر A2A، يُشترط أو يُوصى باستخدام TLS 1.2+ والمصادقة المستندة إلى OAuth في بيئة الإنتاج.

الموثوقية، وإمكانية المراقبة، وتحسين التكلفة

يجب أن تكون عمليات نشر MAS الإنتاجية موثوقة وقابلة للمراقبة وفعالة من حيث التكلفة؛ ويتكامل ADK بسلاسة مع أدوات التشغيل في Google Cloud لتحقيق ذلك. يمكنك تجهيز الوكلاء والجلسات والأدوات بحيث تظهر سجلاتها وآثارها في Cloud Logging وCloud Trace.

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

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

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

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

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

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

بدمج أساسيات الوكلاء وأنماط سير العمل وآليات الحالة في ADK مع بنية Google Cloud المرجعية ومجموعة أدوات الأمان والتشغيل، يمكنك تصميم أنظمة متعددة الوكلاء لا تقتصر روعتها على الجانب النظري فحسب، بل تتعداه إلى سهولة النشر والإدارة والجدوى الاقتصادية في بيئة الإنتاج. بدءًا من وكلاء الأب/الفرع البسيطين، مرورًا بعمليات التنسيق التسلسلي والحلقي والمتوازي، ستحصل على مجموعة أدوات لتحويل أفكار الوكلاء إلى تطبيقات قوية وقابلة للصيانة تُحقق قيمة مضافة حقيقية للأعمال.