Bayer تطلق محركًا متعدد الوكلاء على AgentCore: 80% من الأسئلة دون مهندسين

عرضت Bayer Crop Science نموذجًا لطبقة وكلاء صناعية تعمل فوق منصة ML المؤسسية. يجيب نظام Agentic Decision Engine (ADE) عن أسئلة مربّي النباتات والمحللين ومهندسي البيانات حول مسارات العمل والنماذج والنتائج. وفي المرحلة الأولى يغطي نحو 80% من الطلبات دون مهندس. أما تشخيص الأعطال، الذي كان يستغرق أكثر من ساعة من البحث اليدوي في السجلات وانتظار المساعدة، فيستغرق الآن أقل من 10 دقائق. ويضم النظام 22 وكيلًا متخصصًا يعملون على Amazon Bedrock AgentCore.

لماذا احتاجت المنصة إلى طبقة وكلاء؟

بدأت Bayer ببناء Connected Decision Engine (CDE)، وهو نظام لنشر مسارات عمل ML وتنسيقها ومراقبتها وإعادة استخدامها. والبيانات في مجال التربية الزراعية متنوعة: الجينوميات، والتجارب الحقلية، والصور، والظروف البيئية، ومخرجات النماذج. وتُشغَّل مئات التكوينات بحسب المحاصيل والمناطق والفرق، ويجب أن يكون كل تشغيل قابلًا لإعادة الإنتاج وخاضعًا للرقابة.

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

البنية المعمارية وخمسة قرارات تستحق التذكر

الواجهة الأمامية مبنية على React، وتمر الطلبات عبر وكيل هوية (identity proxy) من Microsoft Entra ID. تبني GitHub Actions صور الوكلاء وتخزنها في Amazon ECR ثم تنشرها في AgentCore Runtime. أما التنسيق فيعتمد على LangGraph، التي اختارها الفريق لأنها توفر رسمًا بيانيًا صريحًا للتحكم ونقاط تحقق للسيناريوهات متعددة الخطوات. وقد وُزّعت البيانات بحسب المسؤولية:

• Amazon DynamoDB — نقاط تحقق LangGraph؛
• Amazon Aurora PostgreSQL — الجلسات والملاحظات والتحليلات؛
• Amazon ElastiCache — ذاكرة مؤقتة لإجابات الوكلاء مع TTL؛
• Amazon S3 + Titan Text Embeddings V2 + OpenSearch Serverless — RAG على المحتوى المتخصص؛
• Amazon CloudWatch — قياسات بيئة التشغيل والتطبيق؛
• AgentCore Gateway — واجهات API الخلفية بوصفها أدوات MCP، مع المصادقة والتفويض خارج شيفرة الوكلاء.

ومن بين الوكلاء الـ22: Domain Expert (الأسئلة المفاهيمية عبر RAG)، وOperational Agent (الحالة الحية والنتائج من CDE)، وTroubleshooting Agent (تحليل القياسات)، وVisualization Agent (الرسوم البيانية أو لوحات المعلومات الجاهزة). ويحوّل نمط Models as Skill شيفرة النموذج ووثائقه إلى أوصاف مهارات (skills) في سجل مركزي، بحيث يجيب الوكيل استنادًا إلى التنفيذ الفعلي لا إلى المعرفة العامة.

وفيما يلي خمسة قرارات تصميمية اتُّخذت بالتعاون مع مدير الحساب التقني ومهندس الذكاء الاصطناعي التوليدي من AWS Unified Operations:

• الحالة خارج بيئة التشغيل. تحتفظ جلسة AgentCore بالسياق طوال عمرها، لكنها ليست مخزنًا موثوقًا. لذلك تُحفظ نقاط التحقق في DynamoDB كي يستأنف الرسم البياني عمله بعد التوسيع وإعادة التشغيل.
• آلية مستقلة عند كل حدّ ثقة. يتولى Entra ID هوية المستخدم، وIAM الاستدعاءات بين الخدمات، والتفويض الصادر في Gateway الوصول إلى CDE، بينما يتحقق معترض (interceptor) من نوع Lambda من السمات ويمررها. ولم يُمرَّر رمز مصادقة واحد عبر جميع الحدود.
• النموذج بوصفه عقد الواجهة. لم يكن الإصدار الجديد ذو وضع reasoning متوافقًا مع tool use والمخرجات المنظمة في تنفيذ الوكلاء، فبقي الفريق على النموذج الحالي.
• التحكم في مجموعة الأدوات. مع أكثر من 500 تكوين، كان إنشاء خادم MCP مستقل لكل API سيعني عمليات نشر وإصدارات زائدة. وبدلًا من ذلك تُسجَّل مواصفات OpenAPI في Gateway، وتُمنح الأدوات للوكلاء بشكل مخصص. فكل وصف أداة يستهلك رموز إدخال.
• من أداة إلى وكيل. توسعت مهمة التصوير البياني حتى احتاجت إلى بحث خاص عن البيانات، ومنطق لاختيار نوع الرسم، وإعادة محاولات، وقرار بين بناء مخطط أو إعادة لوحة معلومات جاهزة. فأُفردت في وكيل يستخدم matplotlib وPlotly داخل AgentCore Code Interpreter (تبادل البيانات عبر S3)، بينما تُعاد الأصول الجاهزة من Amazon Quick أو Power BI.

قابلية المراقبة والتكلفة والإطلاق

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

وتُنسب التكلفة بثلاث آليات: application inference profiles في Bedrock، وبيانات وصفية للطلبات مع تسجيل استدعاءات النماذج، والنسب بحسب مبدأ IAM (IAM principal). ويستهلك وكيلا Visualization وOperational أكبر عدد من الرموز بسبب كثرة استدعاءات أدوات MCP. وكشفت القياسات حملًا ببادئة طويلة متكررة دون تخزين مؤقت للـ prompt. وبفضل التخزين المؤقت للتعليمات الثابتة وأوصاف الأدوات، انخفضت تكلفة رموز الإدخال بنسبة 20–30%.

وبُني الأمان على مبدأ الحد الأدنى من الصلاحيات: يقرأ Troubleshooting Agent البيانات التشغيلية لكنه لا يغيّر مسارات العمل، ولا يستدعي Domain Expert أي واجهات API غير ذات صلة في CDE. والوصول إلى الأدوات للقراءة فقط، وتُتحقق صحة المخرجات، وتستند الإجابات إلى بيانات CDE والقياسات. وتخطط Bayer لتقييم Amazon Bedrock Guardrails بوصفها طبقة إضافية. وقبل الإطلاق أجرت AWS مراجعة Critical Workload Review ومراجعة Well-Architected مع Generative AI Lens، وكان من بين النتائج ثغرات في رؤية الإخفاقات بين المشرف والوكلاء المتخصصين.

والخلاصة العملية لمن يبني أنظمة مشابهة: احفظ الحالة خارج الجلسة، وحدّد issuer وaudience وscopes عند كل انتقال للهوية، وقيّد كتالوج الأدوات لكل وكيل، وقِس نجاح المهمة لا نجاح النقل، وانظر إلى التخزين المؤقت للبادئة منذ البداية. وهذه النقاط تحديدًا حققت لـ Bayer الوفر وقابلية الإدارة معًا.