وكلاء Amazon Bedrock مقابل مستوى التحكم: مراجعة معمارية

لمهندسي ومعماريي DevOps الذين يعملون ضمن نطاق AWS، وكلاء Amazon Bedrock—المعروفة معماريًا باسم AgentCore runtime—هي المسار القياسي لبناء سير عمل الوكلاء. إنها توحد الحلقات التكرارية المعقدة المطلوبة للوكلاء، وتتولى مهمة الاستدلال والذاكرة وتنسيق واجهات برمجة التطبيقات (API) التي كان المطورون يقومون بتطويرها يدويًا باستخدام مكتبات مثل LangChain.

إلا أن اعتماد إطار عمل وكيل مُدار غالبًا ما يستلزم مفاضلة بين السرعة الأولية والتحكم المعماري طويل الأمد. فهو يربط منطق التطبيق بفلسفة تنسيق مزود سحابي معين. يحلل هذا التقرير البنية التقنية لوكلاء Amazon Bedrock، ويقيّم الحقائق التشغيلية المتعلقة بقابلية المراقبة، ويقارنها بنهج مستوى تحكم محايد باستخدام منصة TrueFoundry.

تشريح بيئة تشغيل وكيل Amazon Bedrock

تعمل وكلاء Bedrock كمحرك تنسيق مصمم لتنفيذ مهام متعددة الخطوات. على عكس استدعاء واجهة برمجة التطبيقات (API) InvokeModel عديم الحالة، يعمل الوكيل كحلقة ذات حالة.

عند تعريف وكيل في Bedrock، يقوم المطورون بتكوين ثلاثة عناصر أساسية مميزة:

1. مجموعة الإجراءات: مخطط OpenAPI الذي يحدد قدرات الوكيل. وهذه عادةً ما تتوافق مع AWS Lambda وظائف، توفر طبقة الحوسبة لتنفيذ الأدوات.
2. قاعدة المعرفة: تكامل مخزن المتجهات (عادةً Amazon OpenSearch Serverless) الذي يوفر إمكانيات RAG لترسيخ النموذج.
3. قالب التنسيق: منطق هندسة الأوامر الذي يوجه النموذج حول كيفية تفسير مدخلات المستخدم، واختيار دالة Lambda الصحيحة، وتحليل المخرجات.

حلقة الاستدلال

الفائدة الأساسية هي أتمتة خطوات الاستدلال. عندما يطلب المستخدم "التحقق من المخزون للعنصر X وتحديث قاعدة البيانات"، يقوم وقت التشغيل بتفكيك هذا الطلب:

• الخطوة 1: يحدد أن دالة CheckInventory Lambda مطلوبة.
• الخطوة 2: ينشئ الحمولة.
• الخطوة 3: ينفذ دالة Lambda ويقرأ الاستجابة.
• الخطوة 4: يحدد أن UpdateDatabase هي الخطوة المنطقية التالية بناءً على المخرجات السابقة.

الشكل 1: حلقة التنسيق التكرارية التي يديرها وكلاء AWS Bedrock.

المفاضلات التشغيلية

تسرّع الخدمات المدارة النشر الأولي، لكن عمليات اليوم الثاني — تصحيح الأخطاء، والتوسع، والترحيل — غالبًا ما تكشف عن تكلفة التجريد.

اعتبارات قابلية المراقبة

في بيئة تشغيل مُدارة بالكامل، تكون حلقة المطالبة مُجردة. يتم بناء تعليمات النظام وتعريفات الأدوات بواسطة AWS وإرسالها إلى نموذج اللغة الكبير (LLM) خلف حدود الخدمة.

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

تحافظ البنى التي تستخدم بوابة ذكاء اصطناعي مثل TrueFoundry على شفافية منطق التنسيق. يعمل "عقل" الوكيل على بنيتك التحتية، مما يضمن أن كل مطالبة ورمز مميز وخطوة استدلال مرئية في أدوات التتبع مثل OpenTelemetry أو Arize.

سلسلة الأدوات المرتكزة على AWS

وكلاء Bedrock مُحسّنون لبيئة AWS. استدعاء أداة بشكل أصلي يعني عادةً أن الأداة موجودة كدالة Lambda.

إذا كانت المؤسسة تستخدم أدوات خارجية—مثل قاعدة بيانات Snowflake، أو واجهة برمجة تطبيقات Salesforce، أو خدمة مستضافة على Azure—فغالبًا ما ينسق المطورون عبر دوال Lambda المغلّفة في AWS لسد الفجوة. هذا قد يؤدي إلى زمن استجابة إضافي وتكاليف صيانة.

تتجمع الصناعة حاليًا حول Model Context Protocol (MCP)، وهو معيار مفتوح يسمح للوكلاء بالاتصال بمصادر البيانات عالميًا. تم تصميم TrueFoundry ليكون متوافقًا أصلاً مع MCP، ليعمل كمركز محايد حيث يمكن للوكيل الاتصال بخادم Google Drive MCP، وقاعدة بيانات Postgres محلية، ودالة AWS Lambda في وقت واحد، دون الحاجة إلى أغلفة بنية تحتية مخصصة.

TrueFoundry: بنية مستوى التحكم

تقترح TrueFoundry بنية مستوى التحكم . فبدلاً من تجميع النموذج ووقت التشغيل والأدوات في خدمة سحابية عمودية واحدة، يفصل هذا النهج بينها.

هنا، يعمل مزود السحابة (AWS، Azure، GCP) كواجهة خلفية قابلة للتوسع للحوسبة والنماذج، بينما تظل بوابة TrueFoundry هي الواجهة القابلة للإدارة للتطبيقات.

التوجيه والكفاءة الاقتصادية

من السمات المميزة لوكلاء Bedrock هو الارتباط المعماري بنماذج Bedrock (Titan، Claude، Llama على Bedrock). تنفذ الوكلاء المعقدة العديد من الخطوات، واستخدام نموذج متطور مثل Claude 3.5 Sonnet لكل خطوة في حلقة تكرارية يمكن أن يزيد التكاليف.

تسهل TrueFoundry التوجيه الدلالي. تحلل البوابة تعقيد الخطوة؛ فإذا كان الوكيل يحتاج فقط إلى استخراج تاريخ من سلسلة نصية، يتم توجيه الطلب إلى نموذج أكثر فعالية من حيث التكلفة (مثل Meta Llama) مستضاف على AWS Spot Instances. إذا كانت الخطوة تتطلب استدلالًا معقدًا، يتم توجيهها إلى GPT-4o أو Claude 3.5 Opus.

الشكل 2: يحسن منطق توجيه TrueFoundry اقتصاديات الوحدة عن طريق مطابقة تعقيد المهمة مع المزود الأكثر فعالية من حيث التكلفة.

مقارنة الميزات: الخدمة المدارة مقابل مستوى التحكم

تقارن هذه الطاولة بين قدرات خدمة AWS المدارة ومستوى التحكم في TrueFoundry.

حجة البنية التحتية الهجينة

بالنسبة للعديد من الشركات، لا يكمن المستقبل في "الاعتماد الكلي على AWS" أو "الاعتماد الكلي على Azure"، بل في حالة هجينة تمليها جاذبية البيانات والتكلفة.

تتفوق AgentCore عندما تتم دورة حياة البيانات بأكملها - من الاستيعاب إلى الاستدلال - داخل AWS. ومع ذلك، مع توسع سير العمل القائمة على الوكلاء، فإنها غالبًا ما تتطلب الوصول إلى البيانات في Microsoft SharePoint، أو منصات بيانات العملاء على Google Cloud، أو المستودعات المحلية.

تسهل TrueFoundry نمط توجيه عبر السحابات. يقيم منطق الوكيل في مستوى التحكم، مما يسمح له بالوصول إلى الأدوات عبر السحابات المختلفة دون الحاجة إلى اجتياز شبكات VPN معقدة أو تكوين بوابات API يدويًا. هذا يجعل البنية التحتية جاهزة للمستقبل؛ فإذا Azure OpenAI Service أصدرت نموذجًا جديدًا يتفوق على Claude، أو إذا أصبح Llama 3 قابلاً للتطبيق لحالة استخدام معينة، فإن تبديل المحرك الأساسي هو تغيير في التكوين وليس إعادة كتابة للكود.

الشكل 3: بنية توجيه TrueFoundry التي تتيح الوصول إلى البيانات عبر السحابات.

ملخص التوصيات

إن الاختيار بين خدمة AWS المدارة ومستوى التحكم في TrueFoundry هو في الواقع اختيار بين سرعة التكامل و المرونة المعمارية.

• اعتمد على وكلاء AWS Bedrock إذا: كان فريق الهندسة لديك صغيرًا، ويتكون منطق التطبيق بشكل كبير من دوال AWS Lambda، ولا يوجد متطلب لاستخدام نماذج خارج محفظة Bedrock.
• اختر TrueFoundry إذا: كنت تبني منصة يجب أن تخدم فرقًا داخلية متعددة ذات احتياجات مختلفة. تتطلب حوكمة مركزية لإدارة الميزانيات وسياسات الأمان عبر AWS و Azure، أو تنوي الاستفادة من النماذج مفتوحة المصدر على مثيلات Spot للتحكم في اقتصاديات الوحدة لأعباء عمل الوكلاء عالية الحجم.

‍