AWS شرحت كيفية نشر وكلاء AI الصوتيين من Pipecat في Bedrock AgentCore Runtime

أطلقت AWS الجزء الأول من دليل عملي حول كيفية نشر وكلاء الصوت Pipecat في Amazon Bedrock AgentCore Runtime. لا ينصب التركيز على النماذج نفسها، بل على طبقة النقل، التي تحدد ما إذا كانت المحادثة ستبدو طبيعية أم أن المستخدم سيواجه فترات توقف وتأخيرات.

لماذا يهم التأخير

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

للتخفيف من هذا الخطر، تقترح AWS تشغيل وكلاء Pipecat في Bedrock AgentCore Runtime — بيئة serverless آمنة لوكلاء الذكاء الاصطناعي. تعمل كل جلسة في microVM معزولة، وتتسع المنصة تلقائياً لارتفاعات حركة المرور ويمكنها الحفاظ على محادثات مستمرة لمدة تصل إلى ثماني ساعات. هذا مهم للمكالمات الطويلة والمتعددة الخطوات حيث لا يمكنك ببساطة قطع السياق. فائدة أخرى هي الدفع فقط مقابل الموارد المستخدمة فعلياً، دون الحاجة إلى الاحتفاظ بحجوزات الخادم لأقصى حمل.

يمكن تجميع Pipecat نفسه في حاوية ونشره بالحد الأدنى من النفقات إذا تم بناء الصورة لـ ARM64.

ما هي الخيارات الموجودة

في الجزء الأول، تراجع AWS المسار من العميل إلى الوكيل — هذا "القفزة الأولى" التي تؤثر بشكل أقوى على إدراك السرعة. تقارن الشركة أربع طرق: WebSockets العادي و WebRTC مع ترحيل TURN و WebRTC المُدار من خلال موفري متخصصين والهاتفية للعمل مع PSTN ومراكز الاتصال. لكل خيار توازن خاص به بين البساطة والموثوقية وجودة الاتصال.

الفكرة بسيطة: لا يوجد نقل أفضل واحد لجميع السيناريوهات، لكن هناك حالات استخدام واضحة حيث يبدو كل منها نقطة بداية معقولة.

• WebSockets — الخيار الأبسط للنماذج الأولية والسيناريوهات الخفيفة في تطبيقات الويب والجوال.
• WebRTC مع TURN — الخيار الأفضل إذا كنت بحاجة إلى زمن انتقال أقل وصمود على الشبكات الضعيفة.
• WebRTC المُدار — المسار إلى الإنتاج عندما تريد تفريغ شبكة الوسائط العالمية والتحليلات وبنية البنية التحتية للترحيل إلى خدمة خارجية.
• الهاتفية — خيار للمكالمات واستبدال IVR والحملات الخارجة والتكامل مع مراكز الاتصال.

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

ما يجب مراعاته في الإنتاج

إذا كان الهدف ليس عرضاً توضيحياً بل واجهة حوار مستقرة، توصي AWS بالنظر نحو WebRTC. يعمل هذا النقل عادة على UDP، ويتعامل بشكل أفضل مع ظروف الشبكة المتقلبة ويسلم الصوت بسرعة أكبر في كلا الاتجاهين. لكن AgentCore لديها دقائق معمارية.

الاتصال المباشر peer-to-peer لا يعمل هنا لأن بيئة runtime لا تتلقى عنوان IP عام. سيناريو STUN أيضاً لا يعمل كمسار أساسي: تشير AWS إلى أن NAT Gateway يستخدم NAT متماثل، مما يكسر ثقب الاتصال المباشر. لذلك التوصية العملية هي ترحيل TURN وتكوين VPC للوقت التشغيلي.

في المخطط العامل، تحتاج إلى تكوين متغير ICE_SERVER_URLS على كل من الخادم الوسيط وفي بيئة الوكيل، ثم وضع AgentCore Runtime في شبكة فرعية خاصة بـ VPC وإعطاؤه الوصول الخارج عبر NAT Gateway.

بصفتها الخيار AWS الأصلي لـ TURN، تقدم الشركة Amazon Kinesis Video Streams: توفر الخدمة بيانات اعتماد ICE مؤقتة ومُدارة تلقائياً عبر API GetIceServerConfig. هذا يزيل الاعتماديات الخارجية، لكن هناك قيود: قناة الإشارة النشطة تكلف 0.03 دولار شهرياً، الحد هو 5 TPS لكل قناة، مما يعني بأحجام عالية من الجلسات الجديدة ستحتاج إلى توزيع الحمل عبر قنوات متعددة. بالإضافة إلى ذلك، تحتاج لا تزال إلى الوصول إلى الإنترنت للوصول إلى KVS.

تذكر AWS أيضاً بشكل منفصل موفري WebRTC المُدارين من AWS Marketplace. هذا الخيار مفيد إذا كنت بحاجة إلى جانب النقل إلى عقد SFU/TURN الموزعة عالمياً والمراقبة المدمجة ودعم الغرف متعددة المستخدمين، وليس فقط الحوار من شخص لآخر.

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

ماذا يعني هذا

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