عرضت AWS كيفية ربط Amazon Bedrock AgentCore بـ Slack عبر CDK وLambda

أظهرت AWS كيفية دمج Amazon Bedrock AgentCore مباشرة في Slack دون كتابة التكامل من الصفر لكل وكيل جديد. تفصل الشركة نموذج AWS CDK الجاهز الذي يغطي التحقق من webhooks ومعالجة الرسائل غير المتزامنة والحفاظ على سياق المحادثة.

كيفية عمل المخطط

يتم تقسيم الحل إلى جزأين. الأول هو طبقة البنية الأساسية بين Slack والوكيل: API Gateway يستقبل webhooks، AWS Lambda يعالج الأحداث، Secrets Manager يخزن الرموز، و Amazon SQS يساعد في فصل استقبال الطلب عن المعالجة الفعلية. الثاني هو الوكيل نفسه في Amazon Bedrock AgentCore Runtime. في العرض التوضيحي، هذا عبارة عن روبوت الطقس المبني على Strands Agents SDK، لكن AWS تؤكد أن هذه الطبقة يمكن استبدالها بأي منطق عملي دون إعادة صياغة التكامل مع Slack.

يتم النشر من خلال ثلاث أكوام CDK. يقوم أحدها بإنشاء ونشر صورة الحاوية للوكيل، والثاني ينشئ Runtime و Gateway و Memory، والثالث ينشئ البنية الأساسية لـ Slack مع API Gateway وورقات Lambda. وفقاً لـ AWS، يستغرق النشر الكامل حوالي 10-15 دقيقة. بعد ذلك، يتعين عليك فقط توصيل عنوان URL الخاص بـ webhook في إعدادات تطبيق Slack وتفعيل اشتراكات الأحداث وإعادة تثبيت التطبيق في مساحة العمل. هذا ليس مفهوماً على مستوى الرسم التخطيطي، بل نموذج عملي يمكن تكراره تقريباً خطوة بخطوة.

لماذا ثلاث وظائف Lambda

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

• وظيفة التحقق Lambda تتحقق من توقيع Slack وتسترجع الأسرار من Secrets Manager وتعود فوراً برمز 200 OK.
• وظيفة تكامل SQS Lambda تصفي الأحداث وتتجاهل رسائل الروبوت وترسل للمستخدم رسالة وسيطة وتضع المهمة في قائمة انتظار FIFO.
• وظيفة تكامل الوكيل Lambda تستقبل الرسالة من قائمة الانتظار وتستدعي AgentCore Runtime وتحدث المحادثة برسالة الإجابة النهائية.

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

الذاكرة والجلسات

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

داخل Runtime، يكون AgentCore Memory مسؤولاً عن الذاكرة، والوصول إلى الأدوات يتم من خلال AgentCore Gateway، واستدعاءات الأدوات يتم تنفيذها عبر MCP. في المثال، يقرر نموذج Amazon Nova Pro متى يكون هناك حاجة لاستدعاء أداة إضافي ويستمر في الإجابة بنتيجته. تلاحظ AWS بشكل منفصل أن طبقة التكامل يمكن إعادة استخدامها دون تغييرات: يكفي استبدال أدوات الطقس بأدواتك الخاصة - البحث في قاعدة المعرفة والتنظيمات الداخلية وإجراءات CRM أو العمليات الخدمية. إذا كان تحتاج للوصول نيابة عن موظف معين، يدعم AgentCore أيضاً سيناريوهات ترخيص مخصصة من خلال IdP الشركاتي.

ماذا يعني هذا

بالنسبة للفرق التي تريد وضع وكيل ذكاء اصطناعي في Slack، تقدم AWS فعلياً بنية مرجعية بدلاً من مجموعة من النصائح المتفرقة. الأساسي فيها ليس Bedrock فقط، بل إطار عمل قابل لإعادة الاستخدام: التحقق الآمن من الأحداث وتجاوز انتهاء المهلة الزمنية في Slack وذاكرة محادثة سليمة. هذا يقلل الوقت اللازم لإطلاق وكلاء جدد ويزيل جزءاً من عمل البنية الأساسية الروتيني.