تعتمد قرارات تربية النباتات على بيانات تمتد عبر الجينوميات والتجارب الحقلية والصور والظروف البيئية ومخرجات النماذج. تشغّل Bayer Crop Science مئات من تكوينات نماذج تعلّم الآلة (ML) على هذه البيانات عبر المحاصيل والمناطق والفرق، ويحتاج كل تشغيل إلى أن يكون قابلاً للتكرار وخاضعاً للحوكمة. ولتحقيق هذا المتطلب، بنت Bayer محرك القرارات المتصل (CDE)، وهو نظام لنشر سير عمل تعلّم الآلة وترتيبها ومراقبتها وإعادة استخدامها. يمنح CDE مربّي النباتات والمحللين والباحثين وعلماء البيانات ومهندسي البيانات طريقة متسقة لتشغيل التحليلات مع الحفاظ على سجل التنفيذ والضوابط التشغيلية.
ومع نمو التبني، انتقل الاختناق من تشغيل سير العمل إلى فهمه. فتفسير نتيجة ما كان يتطلب تجميع السياق من واجهات برمجة التطبيقات (APIs) والوثائق ومخازن البيانات الوصفية ولوحات المعلومات والسجلات. وكان المستخدم الذي يرغب في معرفة سبب فشل سير عمل، أو ما فعله نموذج، أو مصدر نتيجة، لا يزال مضطراً لمعرفة النظام الذي يجب فحصه. وسدّاً لتلك الفجوة، بنت Bayer محرك القرارات الوكيلي (ADE)، وهو واجهة متعددة الوكلاء بلغة طبيعية فوق CDE. يقوم وكيل مشرف بتوجيه كل سؤال إلى وكيل متخصص، فيسترجع المتخصص السياق من النظام المعني، ويتلقى المستخدم إجابة دون الحاجة إلى التنقل في الحزمة التشغيلية. وفي مرحلته الأولى، يحل ADE نحو 80 بالمائة من أسئلة المستخدمين دون تدخل مهندس.
يعمل ADE على Amazon Bedrock AgentCore، وهي خدمة من AWS لبناء الوكلاء وربطها وتحسينها على نطاق واسع بأي إطار عمل أو نموذج. مكّنت AgentCore الفريق من التركيز على سلوك الوكلاء بدلاً من بناء وتشغيل طبقة خاصة بهم لاستضافة الوكلاء وعزل الجلسات والوصول إلى الأدوات. ثلاث قدرات من AgentCore دفعت إلى هذا الاختيار: بيئة تشغيل مُدارة تعزل كل جلسة مستخدم، ووصول إلى الأدوات محدود النطاق عبر AWS Identity and Access Management (IAM) من خلال AgentCore Gateway، وهي إحدى قدرات Amazon Bedrock AgentCore، التي تُبقي المصادقة والترخيص خارج كود الوكيل، وتصميم محايد لإطار العمل سمح للفريق بإحضار ترتيب LangGraph الخاص به واختيار النماذج.
وللتحضير للإطلاق وتشغيل ADE بعد ذلك، تعاونت Bayer مع AWS Unified Operations. وقد وفّر هذا التعاون مديراً تقنياً للحسابات (TAM) معيناً ومهندساً متخصصاً في مجال الذكاء الاصطناعي التوليدي (DSE)، عملا كامتداد لفريق ADE من مرحلة التصميم حتى الإنتاج. وقد جلب مدير الحسابات التقني، بصفته المستشار الاستراتيجي لـ Bayer، فهماً راسخاً لنموذج تشغيل Bayer وأولويات أعمالها. وجلب المهندس المتخصص خبرة في مجال الذكاء الاصطناعي التوليدي على AWS. وفي ثلاثة اجتماعات تقنية يومية أسبوعياً، راجع الفريق واتخذ قرارات التصميم. واكتسب المهندس المتخصص معرفة عملية بعبء عمل ADE وبطريقة عمل فريق Bayer، بحيث عكست التوجيهات التقنية سلوك خدمات AWS وسياق Bayer معاً. يتتبع هذا المنشور تلك الرحلة: بنية ADE، والقرارات التصميمية الخمسة المتخذة أثناء البناء، والعمل لإعداد المنصة للإنتاج، وكيفية تشغيلها بعد الإطلاق.
نظرة عامة على البنية
ينظم ADE في أربع طبقات: تجربة المستخدم، وترتيب الوكلاء، والوكلاء المتخصصون، والأدوات ومصادر البيانات التي تستدعيها تلك الوكلاء (الشكل 1). يصل المستخدمون إلى ADE من خلال واجهة ويب أمامية مبنية بـ React، وتمر الطلبات عبر وسيط هوية لـ Microsoft Entra ID قبل أن تصل إلى الوكلاء. يقوم GitHub Actions ببناء صور حاويات الوكلاء ودفعها إلى Amazon Elastic Container Registry (Amazon ECR)ونشرها على بيئة تشغيل AgentCore، وهي إحدى قدرات Amazon Bedrock AgentCore.
تستضيف بيئة تشغيل Amazon Bedrock AgentCore الوكلاء، ولأن بيئة التشغيل محايدة تجاه الأطر البرمجية، يشغّل الفريق نظام التنسيق الخاص به المبني على LangGraph عليها مباشرة. اختار الفريق LangGraph لتحكّمه الصريح في تدفق التنفيذ القائم على الرسوم البيانية ولميزة حفظ نقاط التفتيش لسير العمل متعدد الخطوات. ينسّق LangGraph سير العمل، مع وكيل مشرف (Supervisor Agent) كنقطة دخول تصنّف كل طلب، وتختار الوكيل المتخصص، وتمزج النتائج عندما يمتد السؤال لأكثر من نطاق. تُفصل مستويات البيانات حسب المسؤولية. Amazon DynamoDB يخزّن حالة نقاط تفتيش LangGraph. Amazon Aurora PostgreSQL يخزّن سجلات الجلسات وملاحظات المستخدمين والتحليلات. Amazon ElastiCache يخزّن استجابات الوكلاء مؤقتًا مع زمن صلاحية (TTL). ويُضمَّن المحتوى المجال في Amazon Simple Storage Service (Amazon S3) باستخدام Amazon Titan Text Embeddings V2 ويُفهرَس في Amazon OpenSearch Serverless لأجل التوليد المعزز بالاسترجاع (RAG). Amazon CloudWatch يلتقط القياسات التشغيلية والتطبيقية لبيئة التشغيل. ويكشف AgentCore Gateway واجهات برمجة التطبيقات الخلفية للوكلاء كأدوات بروتوكول سياق النموذج (MCP) ويُبقي المصادقة والتفويض خارج كود الوكلاء.
الشكل 1: بنية محرك القرار الوكيلي (Agentic Decision Engine) على Amazon Bedrock AgentCore
يشغّل ADE 22 وكيلًا متخصصًا في بيئة الإنتاج، كلٌّ منها محصور في نطاق واحد ولديه أدواته ومصادر بياناته الخاصة. على سبيل المثال، يجيب وكيل خبير المجال (Domain Expert Agent) عن الأسئلة المفاهيمية عبر RAG. ويسترد وكيل العمليات (Operational Agent) حالة سير العمل ونتائجه الحية من CDE. ويحلّل وكيل استكشاف الأخطاء وإصلاحها (Troubleshooting Agent) القياسات التشغيلية. ويولّد وكيل التصور (Visualization Agent) الرسوم البيانية أو يعيد لوحات المعلومات القائمة. ويحوّل نمط Models as Skill الخاص بكل عميل كود النماذج والوثائق إلى تعريفات مهارات تُخزَّن في سجل مركزي، بحيث يجيب الوكلاء عن الأسئلة الخاصة بكل نموذج انطلاقًا من تنفيذ النموذج نفسه بدلًا من المعرفة العامة عن النماذج.
عندما يسأل أحد المربّين: «لماذا فشل سير عمل القياس الظاهري (phenotyping) الخاص بي أمس؟»، يصنّف المشرف النية ويوجّه الطلب إلى وكيل استكشاف الأخطاء وإصلاحها. يقرأ ذلك الوكيل قياسات سير العمل في CloudWatch وحالته من واجهة CDE API عبر AgentCore Gateway، ويحدّد نقطة الفشل، ويعيد التشخيص عبر المشرف (الشكل 2). لم يعد المربّي يبحث في السجلات مباشرة. ومع وكيل استكشاف الأخطاء وإصلاحها، صار التشخيص الذي كان يستغرق سابقًا أكثر من ساعة من البحث اليدوي في السجلات وانتظار دعم المهندسين يستغرق الآن أقل من 10 دقائق.
الشكل 2: تدفق طلبات ADE: تصنيف النية، والبحث في الذاكرة المؤقتة، والتوجيه إلى المختص، والاستجابة
خمسة قرارات تصميمية على طريق الإنتاج
شاركت فرق Unified Operations TAM وDSE في القرارات التالية بوصفها أعضاء في فريق العمل، لا كنقطة تصعيد لاحقة. وقد مكّن ذلك شركة Bayer من اختبار كل قرار تصميمي مقابل سلوك خدمات AWS قبل الالتزام به، مع الاحتفاظ بملكية البنية والقرار النهائي.
1. إخراج حالة التنسيق خارجيًا دون اعتبار بيئة التشغيل عديمة الحالة
توفر بيئة تشغيل AgentCore جلسات معزولة تحافظ على سياق التنفيذ عبر الاستدعاءات طوال دورة حياة الجلسة. لكن ذلك السياق ليس مخزنًا دائمًا لسير عمل متعدد الخطوات. يكتب ADE نقاط تفتيش LangGraph في DynamoDB حتى يتمكن الرسم البياني من الاستئناف بعد أحداث التوسع الأفقي أو إعادة التشغيل أو حدود الجلسات دون الاعتماد على بقاء بيئة تنفيذ واحدة متاحة.
المبدأ: استخدم جلسة بيئة التشغيل للتنفيذ النشط، واحفظ الحالة اللازمة لاستئناف سير العمل أو إعادة بنائه في خدمة دائمة.
2. الفصل بين هوية المؤسسة، والوصول إلى البوابة، والتفويض للأنظمة التابعة
تعتمد Bayer على Microsoft Entra ID كمعيار لهوية المستخدمين، بينما تفوّض خدمات ADE لبعضها البعض عبر آليات AWS الأصلية. وبدلًا من فرض رمز مميز واحد عبر كل حد ثقة، منح الفريق كل حدّ آليته الخاصة.
يبقى Entra ID مصدر هوية المستخدم. ويصادق AWS Identity and Access Management (IAM) على الاتصالات بين الخدمات. ويتولى التفويض الصادر في AgentCore Gateway التعامل مع الوصول إلى خدمات CDE التابعة. وتؤدي دالة AWS Lambda كمعترض طلبات التحقق المخصص وتمرر سمات التفويض التي تتطلبها الأدوات التابعة. واشتغل الفريق على عقد الرمز المميز في كل قفزة مع فريق DSE.
المبدأ: تتركز إخفاقات الهوية في أنظمة الوكلاء عند الانتقالات بين هوية المستخدم وهوية الوكيل وهوية الأداة. حدّد جهة الإصدار والجمهور والادعاءات والنطاقات وعمر بيانات الاعتماد في كل قفزة بدلًا من إعادة استخدام رمز مميز صالح لحدّ معين عند الحدّ التالي.
3. التعامل مع اختيار النموذج كعقد واجهة برمجية
أثناء البناء، قيّم الفريق إصدارًا أحدث من النموذج مع تفعيل وضع التفكير (reasoning mode). وفي ذلك الإصدار، كان الجمع بين استخدام الأدوات والمخرجات المهيكلة الذي يعتمد عليه ADE غير متوافق مع طريقة تنفيذ وكلائه. وأكّد DSE هذا القيد، فاحتفظ الفريق بالنموذج الحالي للإصدار.
المبدأ: بالنسبة للوكلاء الذين يستخدمون الأدوات، فإن اختيار النموذج مقيّد بالواجهة الكاملة: استدعاء الأدوات، والمخرجات المهيكلة، وسلوك البث، وميزات الاستدلال، وزمن الاستجابة، وتوافر الحصة، ودلالات الطلب الخاصة بكل نموذج. النموذج الأحدث ليس تلقائيًا بديلاً فوريًا.
4. تحكّم في سطح الأدوات قبل أن يتحكم في التوجيه
يدير CDE أكثر من 500 تكوين للنماذج. إن تخصيص خادم MCP مخصص لكل واجهة برمجية كان سيضيف عبئًا في النشر والمصادقة وإدارة الإصدارات. بدلًا من ذلك، يسجّل ADE مواصفات OpenAPI مع AgentCore Gateway، والتي تعرض عمليات REST كأدوات MCP. وبذلك يصبح إضافة أو تغيير واجهة برمجية مجرد تغيير في المخطط وإعدادات البوابة بدلًا من نشر خادم جديد.
كما أن مخططات الأدوات وأوصافها تستهلك رموز الإدخال وتتنافس مع طلب المستخدم والسياق المسترجع. يحدّد ADE نطاق الأدوات حسب الوكيل المتخصص بدلًا من منح كل وكيل الكتالوج الكامل. وبالنسبة للكتالوجات الأكبر، يدعم AgentCore Gateway البحث الدلالي في الأدوات، بحيث يمكن للوكيل العثور على الأدوات ذات الصلة دون تحميل الكتالوج بأكمله في كل دورة.
المبدأ: حدّد نطاق كتالوج الأدوات لكل وكيل. فكل تعريف أداة يضيف رموزًا ويوسّع فضاء القرار المتاح للنموذج.
5. ترقية القدرات المعقدة من الأدوات إلى الوكلاء
بدأت أداة التصوّر البصري كأداة تستدعيها وكلاء آخرون. ومع نموّها، احتاجت إلى استرجاع بيانات خاص بها ومنطق اختيار المخططات وإعادة المحاولات ومعالجة الأخطاء وقرار بشأن ما إذا كان سيتم توليد مخطط أو إرجاع لوحة معلومات قائمة. نقل الفريق الأداة لتصبح وكيلًا متخصصًا في التصوّر البصري. يولّد الوكيل مخططات عند الطلب باستخدام matplotlib وPlotly داخل AgentCore Code Interpreter، وهي إمكانية من Amazon Bedrock AgentCore توفر بيئة تنفيذ تعليمات برمجية معزولة (sandbox)، ويتبادل البيانات معها عبر Amazon S3. وعندما تكون لوحة المعلومات الجاهزة هي الخيار الأفضل، يعيد الوكيل أصل Amazon Quick أو Power BI القائم بالفعل.
المبدأ: الأداة تؤدي عملية محدودة الحدود. عندما تبدأ إحدى القدرات في امتلاك حالة أو إعادة محاولات أو تخطيط أو سياسات أو قرارات عرض، نمذجها كوكيل.
تهيئة ADE للإنتاج
مع تقدّم البناء نحو الإطلاق، تحوّل التركيز من التصميم إلى قابلية التشغيل: اكتشاف أعطال الوكلاء، وإسناد تكلفة الاستدلال، وتقوية النشر.
الرصدية (Observability): قِس حالات فشل المهام، وليس الاستثناءات فقط
تحوّل بنية المشرف طلب المستخدم الواحد إلى سلسلة من استدعاءات النماذج واستدعاءات الأدوات وتسليم المهام بين الوكلاء. وقد تكون الإجابة النهائية خاطئة حتى عندما تنجح كل طلبات HTTP. واجه ADE هذا الأمر مباشرةً: كانت معالجات الاستثناءات في التطبيق تلتقط أخطاء الوكلاء وتعيد استجابات أحصاها نظام المراقبة كناجحة. بعد إعادة إنتاج المشكلة مع DSE، أضاف الفريق مقاييس CloudWatch مخصصة داخل مسارات الفشل وتنبيهات على حالات خاصة بكل وكيل: أخطاء استدعاء الأدوات، والتقييد، وانتهاء مهلة النماذج، وإخفاقات التحقق من صحة المخرجات المهيكلة. وتتبع التتبعات (traces) وسجلات الاستدعاء كل طلب عبر المشرف والوكلاء المتخصصين.
المبدأ: فرّق بين نجاح النقل ونجاح المهمة. ينبغي أن تُظهر رصدية الوكلاء ما إذا كانت المهمة قد اكتملت، وأي وكيل أو أداة غيّرت النتيجة، وما إذا كانت الاستجابة استخدمت المصدر المتوقع.
إسناد التكلفة: ادمج إسناد الفوترة مع القياس عن بُعد على مستوى الطلب
طلب واحد في ADE يمكنه استدعاء عدة نماذج وأدوات، لذا فإن إنفاق Amazon Bedrock على مستوى الحساب لا يفسر اقتصاديات الوحدة. صمّم الفريق نهج الإسناد مع DSE باستخدام ثلاث آليات تجيب عن أسئلة مختلفة. تنسب ملفات تعريف الاستدلال التطبيقي في Amazon Bedrock استخدام النماذج المفوتر إلى تطبيق أو حمل عمل. وتربط بيانات التعريف للطلبات وسجلات استدعاء النماذج استخدام الرموز بوكيل أو ميزة أو طلب محدد. ويضيف إسناد هوية IAM principal بعدًا متعلقًا بالهوية. وتمكّن هذه الآليات مجتمعةً الفريق من تقدير التكلفة لكل تفاعل، وتحديد الوكلاء المكلفين، وتحديد ما إذا كانت المطالبات أو السياق المسترجع أو تعريفات الأدوات هي ما يدفع استخدام الرموز. وفي الممارسة العملية، كان وكيلان التصوّر البصري والتشغيلي، اللذان يعتمدان على أدوات MCP واستدعاءات أدوات متعددة، يستهلكان أكبر قدر من الرموز.
كما كشفت القياسات عن بُعد نفسها عن حمل عمل أثناء التحضير للإطلاق له بادئة إدخال مكررة كبيرة ولا يوجد نشاط لذاكرة تخزين مؤقت للمطالبات. وبالنسبة للنماذج المدعومة، فإن وضع التعليمات المستقرة وتعريفات الأدوات في بادئة مطالبة قابلة للتخزين المؤقت يقلل من معالجة الإدخال المتكررة، مما يخفض زمن الاستجابة وتكلفة الرموز. وفي ADE، أدى تخزين بادئة المطالبة المستقرة مؤقتًا إلى خفض تكلفة رموز الإدخال بنسبة 20–30 بالمئة.
الأمن وجاهزية الإطلاق
أدوار IAM محددة النطاق وفق مسؤولية كل وكيل. يستطيع وكيل استكشاف الأخطاء وإصلاحها قراءة البيانات التشغيلية التي يحتاجها للتشخيص لكنه لا يستطيع تعديل سير العمل. ويستطيع وكيل الخبير المجالي الاستعلام عن فهرس الاسترجاع الخاص به لكنه لا يستطيع استدعاء واجهات CDE غير ذات الصلة. وفي الإنتاج اليوم، تخضع استجابات وكلاء ADE لمبدأ أقل صلاحية، ووصول قراءة فقط للأدوات محدد النطاق لكل وكيل، والتحقق من صحة المخرجات المهيكلة على استجابات الوكلاء، وإجابات مستندة إلى بيانات CDE المسترجعة والقياسات عن بُعد بدلًا من التوليد المفتوح. كما تخطط Bayer لتقييم Amazon Bedrock Guardrails كطبقة إضافية على هذه الضوابط، تكمل فحوصات السلامة المخصصة المستخدمة بالفعل في سير عمل CDE متعدد الأدوار.
قبل الإطلاق، أجرت Unified Operations مراجعة لأحمال العمل الحرجة ومراجعة Well-Architected بعدسة الذكاء الاصطناعي التوليدي مع فريق ADE. ولأن DSE كان يعرف حمل العمل مسبقًا، استهدفت المراجعتان أنماط الفشل المحددة لـ ADE ومخاطر السعة وفجوات النشر بدلًا من أفضل الممارسات العامة. وشملت النتائج فجوات في رؤية الأعطال عبر المشرف والوكلاء المتخصصين، ووسوم صور حاويات قابلة للتغيير، ومحدودية تتبع الصور، وغياب فحص الثغرات الأمنية. واستجاب الفريق بتنبيهات أقوى، وصور غير قابلة للتغيير مع إصدارات، وفحص عند الدفع (scan on push) في Amazon ECR، وسياسات دورة حياة للصور غير المستخدمة.
كما راجع DSE متطلبات التوسع والحصص مع الفريق. وحقّقت اختبارات التحميل صحة التطبيق وحصص خدماته، وكشفت عن نمط فشل في الشبكة كان يعيد استجابات فارغة، وأصلحه الفريق قبل حدث الإنتاج. وعند الإطلاق، كان الفريق قد تتبع 35 عائقًا حتى حلّها مع Unified Operations.
الإطلاق والتشغيل والخطوات التالية
أطلقت باير منصة ADE لمجموعة محدودة بدلاً من فتحها للمنظمة بأكملها دفعة واحدة. منذ الإطلاق، استخدم أكثر من 100 مستخدم عبر Bayer Crop Science منصة ADE، بما في ذلك مربو النباتات والمحللون والباحثون وعلماء البيانات والمهندسون. إلى جانب وكلائها الـ 22 المتخصصين، توفر ADE حوالي 20 أداة API ويمكنها استضافة وكلاء من أطراف ثالثة مع توسعها. وأدى كشف تلك الـ APIs عبر AgentCore Gateway بدلاً من خادم مخصص لكل API إلى خفض النفقات التكاملية لكل API بأكثر من 99 في المئة. في مرحلتها الأولى، حلت ADE حوالي 80 في المئة من أسئلة المستخدمين دون تدخل مهندس.
تبقى CDE طبقة التنفيذ الخاضعة للحوكمة للتحليلات. وتضيف ADE طبقة لغة طبيعية فوقها، بحيث يمكن للمستخدمين الاستعلام عن حالة سير العمل والنتائج وسلوك النماذج والإخفاقات دون الحاجة إلى تعلم موقع أو واجهة كل نظام أساسي.
ثم انتقلت المشاركة من الاستعداد للإطلاق إلى العمليات المستمرة. يستمر DSE في الاجتماع مع الفريق، بحيث يبدأ فرز المشكلات والمراجعات التشغيلية من معرفة قائمة بـ ADE بدلاً من بدء تحضير جديد. تم ضم إنذارات CloudWatch الحرجة الخاصة بـ ADE، بما في ذلك الإنذارات الخاصة بكل وكيل الموصوفة سابقاً، إلى AWS Incident Detection and Response. وعندما يُفعَّل أحد الإنذارات، يتدخل مهندسو AWS Incident Management خلال 5 دقائق ويبدؤون من سياق عبء العمل بدلاً من البداية من الصفر. وعلى صعيد الأمن، يدعم مهندسو AWS Security Incident Response الفريق أثناء الأحداث الأمنية المحتملة أو الفعلية، بحيث تمتلك ADE تغطية مراقبة واستجابة من AWS لكل من المشكلات التشغيلية والأمنية.
وبفضل وجود الاتصال بين الوكلاء بالفعل، تركز باير بعد ذلك على قابلية التشغيل البيني للوكلاء في السحابة الهجينة. ويستكشف الفريق كيف يمكن للوكلاء العاملين في بيئات مختلفة أن يكتشفوا بعضهم البعض ويتواصلوا معاً دون تكوين يدوي.
الخلاصة
لم تستبدل باير منصة التحليلات الخاصة بها بـ ADE، بل جعلت الاستعلام عن CDE وتشغيلها أسهل. وقع معظم العمل الإنتاجي خارج المطالبات: الحالة الدائمة، وحدود الهوية، ونطاق الأدوات، وقابلية المراقبة على مستوى المهام، وإسناد التكاليف، وجاهزية الإطلاق. وامتلكت باير المعمارية وكل قرار من تلك القرارات. ومن خلال العمل مع DSE وTAM معينين عبر AWS Unified Operations، اختبر الفريق تلك القرارات في مواجهة سلوك خدمات AWS أثناء التصميم ونقل السياق نفسه إلى الإنتاج.
لمعرفة المزيد، استكشف Amazon Bedrock AgentCore, وإسناد تكاليف Amazon Bedrock, ومبادئ AWS Well-Architected للذكاء الاصطناعي التوليديو AWS Unified Operations.
يود المؤلفون أن يتقدموا بالشكر إلى Sijie Shi وJorge Gomes وNaveen Reddy وIago Fonseca وMateus Silva وSushimitha Jarugula على إسهاماتهم في تصميم ADE وتطويرها وإطلاقها.