KTern.AI تبني منصة وكلاء لـ SAP على Amazon Bedrock AgentCore

كشفت KTern.AI عن بنية منصة AI قائمة على الوكلاء لـ SAP، مبنية على Amazon Bedrock AgentCore وStrands Agents SDK. يُنسّق النظام بين عدة وكلاء متخصصين لخدمة البرامج المؤسسية الطويلة، مع الحفاظ على السياق والتحكم في الوصول إلى الأدوات.

كيف تعمل المنصة

تطوّر KTern.AI منصتها السابقة، وهي خدمة SaaS، إلى نظام قائم على الوكلاء، لا يحاول فيه روبوت دردشة واحد شامل حلّ كل المهام. وبدلاً من ذلك، يتولى وكلاء متخصصون كل جزء من العملية المؤسسية. وهذا النهج مهم في بيئة SAP، لأن الطلبات فيها لا ترتبط عادةً بإجابة واحدة، بل ببرنامج طويل ينبغي فيه مراعاة القرارات المتخذة سلفاً، وحالة العمليات، والبيانات المؤسسية المتاحة.

تقوم البنية التحتية على Amazon Bedrock AgentCore، وهي منصة مُدارة من AWS لنشر وكلاء AI وتشغيلهم. أما لتنسيق سلوك الوكلاء فتستخدم KTern.AI حزمة Strands Agents SDK. وتتيح هذه المكونات مجتمعةً توزيع العمل بين الوكلاء، دون الحاجة إلى بناء بنية تحتية من الصفر لحفظ الحالة، وربط الأدوات، وتشغيل الخدمات بموثوقية.

• تستخدم KTern.AI منصة Amazon Bedrock AgentCore بنيةً تحتيةً لمنصة وكلاء موجّهة إلى SAP.
• تتولى Strands Agents SDK تنسيق عمل وكلاء AI المتخصصين.
• صُمّم الوكلاء للبرامج المؤسسية الطويلة، لا للطلبات المنفردة في الدردشة فحسب.
• تنص البنية على سياق دائم لكل وكيل.
• ينبغي أن يبقى الوصول إلى الأدوات الخارجية آمناً وخاضعاً للتحكم.

لماذا لا يكفي وكيل واحد؟

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

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

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

ما الذي تغيّر في التشغيل

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

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

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

ماذا يعني ذلك

تُظهر حالة KTern.AI تحوّلاً عملياً من مساعدي AI المنفردين إلى أنظمة مُدارة تضم عدة وكلاء. وقيمة هذه البنية للمنصات المؤسسية لا تكمن في الحوار نفسه، بل في القدرة على إدارة العمليات الطويلة بأمان، واستخدام أدوات الأعمال، وعدم فقدان السياق بين مراحل العمل.