الفصل 13 — الأُطُر وتكامل السحابة
المقالة الثالثة عشرة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. حيث لا أحد يَبني MCP إنتاجياً من البروتوكول الخام، والسؤال الصادق لـ2025–2026 يَصير على أيِّ إطارٍ نُوَحِّد، والإجابة تَتبيَّن أنها تَعتمد على أيِّ سحابة يَسكن فيها بقية النظام أكثر منها على الخصائص.
لماذا يوجد هذا الفصل
حين يَنتهي الفريق من توصيل المصادقة، النقل، حالة الجلسة، إعادة محاولات الخطأ، التسجيل المهيكَل، والعشرات من التفاصيل الأصغر التي تَفصل العرض عن الخدمة القابلة للتشغيل، ما بدأ بـ«سنَتحدث MCP عبر HTTP» قد صار إطاراً صغيراً خاصاً به — عادةً أسوأ من الأُطُر القائمة. السؤال الهندسي هو على أيِّ الأُطُر العامة نُوَحِّد، ما الذي يَفعله كلٌّ صحيحاً، وكيف تَتصل بخدمات السحابة التي تَحمل الحالة. يَمشي هذا الفصل على المشهد منهجياً: Strands مع Amazon Bedrock؛ خدمات AWS المُحيطة به للحالة والاسترجاع؛ إطار وكلاء Microsoft، LangChain، وSemantic Kernel بوصفها الخيارات الإنتاجية الأخرى؛ وأنماط التكامل التي تَقاربت عليها المعماريات المرجعية. الهدف ليس تَتويج فائزٍ بل وصف ما كل إطارٍ له فعلاً.
13.1 وكلاء Strands وAmazon Bedrock
Strands إطار وكلاء مفتوح المصدر أصدرته AWS في 2025 ويَجري الآن داخل Amazon Q وAWS Support ومساعد AWS Glue. التأطير متعمَّد: Strands مدفوعٌ بالنموذج، ما يَعني أن الحلقة التي تُقَرِّر ماذا تَفعل تالياً هي حلقة استدعاء أدوات النموذج ذاته، لا رسم مُخَطِّطٍ يَفرضه الإطار فوقه. وظيفة الإطار جعل تلك الحلقة موثوقة في الإنتاج — معالجة استدعاءات الأدوات، إدارة حالة الجلسة، إدخال خوادم MCP كمصادر أداةٍ من الدرجة الأولى عبر MCPClient، وتَوجيه كل شيءٍ عبر فهرس نماذج Bedrock المُستضاف. طبقة النموذج قابلة للإقحام — API Anthropic، OpenAI، Ollama، LiteLLM — لكن Bedrock الافتراض وقصة التدقيق.
قصة الوكلاء المتعددين حيث يَكتسب Strands سُمعته الإنتاجية. ثلاثة أنماط تركيبٍ تَنطبق نظيفاً على أشكال التنسيق من الفصول السابقة: وكلاء-كأدوات (الشكل الأبسط، وكيلٌ مُغَلَّفٌ كأداةٍ يَستطيع وكيلٌ آخر استدعاءها)؛ السرب (نظيرٌ-إلى-نظير بذاكرة عملٍ مُشتركة)؛ والرسم (طوبولوجيا حتمية يَملأ النموذج كل عقدة فيها). الأنماط تَتعشَّش في الإنتاج. الضريبة التشغيلية تُدفع في قابلية الملاحظة، ويَدفعها Strands بإطلاق امتدادات OpenTelemetry لكل استدعاء وكيل، كل استدعاء أداة، كل استدعاء نموذج — فيُعاد بناء تركيبٍ بأربعة مستويات من السجلات دون أجهزة قياسٍ لكل مستوى. يُضيف Bedrock قصة حدود الوصول: IAM يَتحكَّم بأيِّ النماذج يَستطيع وكيلٌ مُعَيَّن استدعاءها؛ CloudTrail يُسَجِّل الاستخدام. حواجز Bedrock تَتولى تَرشيح المحتوى عند البوّابة، قواعد المعرفة تُعطي استرجاعاً مُداراً، وAgentCore — مجموعة أوَّليات AWS لـ2025 — تُقَنِّن الذاكرة والهوية واهتمامات وقت التشغيل للفِرَق التي تريد وقت تشغيل مُداراً كاملاً بدل مُستضاف ذاتياً.
13.2 AWS بوصفها طبقة الحالة
وكيلٌ يَجري ساعاتٍ ويَتذكَّر ما حَدَث أمس يَحتاج تخزيناً يَتجاوز عمر العملية. النمط الذي استقرَّ إنتاجياً: حالة وقت التشغيل (الجلسة الراهنة، دفتر المهام، استدعاءات الأدوات في الطيران) في DynamoDB لوصولٍ مفتاحي سريع؛ حالة القطع الأثرية (الوثائق المُنتجة، العمل الوسيط) في S3 ببنية مفتاحٍ مُسبَّقة بالجلسة تُعطي حدود IAM طبيعية وإصداراً مجانياً؛ الحالة الدلالية (الذاكرة طويلة المدى، المحادثات السابقة) في مخزنٍ متجهي — OpenSearch Service لذاكرة عملٍ ساخنة، S3 Vectors الأحدث لذاكرة باردة أو أرشيفية. الفصل ذو الطبقتَين بين S3 وDynamoDB ليس تَحسيناً قبل أوانه. يُبقي عنصر DynamoDB تحت 400 ك.ب.، يَتجنَّب تَضخيم القراءة في كل خطوة، ويَدع كل طبقةٍ تَتمدَّد مستقلَّةً.
اختيار طبقة الحالة يُحَدِّد وضعية فشل النظام كله. وكيلٌ حالته فقط في ذاكرة العملية يَفقد كل شيءٍ عند إعادة التشغيل. وكيلٌ ذاكرته متينةٌ لكن فهرسه خارج التَزامن يَستذكر مراجع لوثائق لا يَستطيع إيجادها. النشر الإنتاجي يُعامل هذه عقود اتساقٍ منفصلة: معاملات DynamoDB لذرية الحالة، قراءة قوية بعد كتابة S3 لعقد القطعة الأثرية، أنبوب فهرسة يَنشر الوثائق إلى S3 قبل تحديث متجهاتها فلا يَستطيع الاسترجاع الإشارة إلى ما لا يَوجد بعد. الحدود الأمنية تَستحقّ العناية ذاتها. توجيه Strands من AWS ذاتها يُوصي باعتمادات لكل جلسةٍ عبر STS بدلاً من إعادة استخدام دور وقت التشغيل لاستدعاءات بياناتٍ تَخصّ المستخدم النهائي — تُؤَتمت AgentCore Identity هذا — كي تكون هوية AWS وراء فعلٍ هَدّامٍ هي المستخدم النهائي الفعلي، لا دور وكيلٍ مُشترك. في البيئات المُنَظَّمة هذه الإجابة الوحيدة المقبولة.
13.3 إطار وكلاء Microsoft، LangChain، وSemantic Kernel
جانب Microsoft والمصدر المفتوح من المشهد استقرَّ بشكلٍ مختلف. وَصَل إطار وكلاء Microsoft أواخر 2025 بوصفه الدمج الصريح لـSemantic Kernel وAutoGen — نموذج مُلحقات SK وتكامل .NET مع أنماط AutoGen متعددة الوكلاء وتجربة المطوِّر الفايثونية أولاً. تكامل MCP مَبني عبر MCPStdioTool وMCPStreamableHTTPTool؛ Azure AI Foundry هو البيت المُستضاف، يُكافئ Bedrock في عالم AWS. الخاصية المُمَيِّزة عن Strands أن رسم المحادثة بين الوكلاء كائنٌ صريحٌ قابلٌ للإعادة — وهذا يَهُمّ كثيراً للتقييم، لأن محادثةً فاشلة يُمكن إعادة تشغيلها بموجِّهٍ مُعَدَّل ومقارنتها دور-بدور. الكلفة بنيةٌ أكثر مما يَفرض Strands؛ المقايضة الصحيحة في النشر الناضج، الخطأ في العمل الاستكشافي.
LangChain في 2026 حيوانٌ مختلف عنه في 2023. تَجريد السلاسل الأصلي صار ثانوياً؛ السطح الأساسي LangGraph للتنسيق وLangSmith لقابلية الملاحظة والتقييم. القوى السعة — كل نموذج، قاعدة بيانات، وأداة يَبدو أن لها مُحَوِّلاً — ونضج تقييم LangSmith. الضعف الذي يُسَمِّيه الممارسون بصدق مساحة السطح: تَجريدات الإطار العالية المستوى ممتازة لتسعين بالمئة الأولى من العمل، والعشرة بالمئة الأخيرة تُفعَل عادةً بكشط الطبقات حتى يَفهم الفريق ما تَفعله كلٌّ. الفِرَق التي تُخَطِّط لهذا الانتقال تَشحن أسرع من التي تُقاتل التَجريدات. Semantic Kernel يَبقى إطار فِرَق .NET؛ نموذج مُلحقات [KernelFunction] يَلائم مُستضيفات خدمة .NET نظيفاً. نمطٌ ظَهَر عبر الثلاثة: وكيلٌ نحيف، MCP سميك — القدرات تَسكن خلف حدود البروتوكول، الأُطُر تَصير وكلاء نَحاف، وخادم MCP ذاته يُستهلَك بـStrands على AWS، إطار وكلاء Microsoft على Azure، وLangChain على حاسوب مطوِّرٍ دون عمل نقل. هذا المسار الذي صُمِّم البروتوكول لإتاحته.
13.4 أنماط التكامل الإنتاجية
ثلاثة أنماط استقرَّت في معماريات 2025–2026 المرجعية. نمط البوّابة-وطبقة-الحالة يَضع بوّابة نموذجٍ مُدارة (Bedrock، AI Foundry، LiteLLM) أمام طبقة النموذج وطبقة حالةٍ متينةٍ منفصلة وراءها. البوّابة حيث تَسكن المصادقة وتَحديد المعدل وتَرشيح المحتوى والتدقيق؛ وطبقة الحالة حيث تَسكن المتانة. هذا النمط الافتراض الإنتاجي؛ على النشر الجديد تَبَنِّيه ما لم يَكن لديه سببٌ محدَّد لعدمه، لأن الفِرَق التي تَتخطى البوّابة وتَستدعي مُقدِّم النموذج مباشرةً تَنْدم خلال فصل. نمط شبكة خدمات MCP يُعامل خوادم MCP خدماتٍ صغرى ويَعرضها عبر شبكةٍ تُعالج mTLS، إعادات المحاولة، وقاطعات الدائرة — يَستحقّ الكلفة فقط على نطاقٍ واسع (أكثر من عشرة خوادم) أو في بيئاتٍ مُنَظَّمة تَتطلَّب تَشهيداً على طبقة الشبكة. نمط كل-شيء-مُدار يُسلِّم وقت التشغيل والذاكرة والهوية وسجل الأدوات إلى خدمة وكلاء سحابية مُدارة (Bedrock AgentCore، خدمة وكلاء Azure AI Foundry، Vertex AI Agent Builder)؛ يَفوز للأتمتة الداخلية والمساعدات حيث الوكيل ليس المنتج الأولي، ويَخسر للفِرَق حيث الوكيل هو المنتج وروافع التشغيل تَهُمّ. نمطان لم يَفوزا، جديران بالتسمية أمثلةً سلبية: كل-شيءٍ-في-سياق-LLM (وكلاء ذاكرتهم موجِّه نظامٍ دائم النمو) والإطار-كمنسِّق (DAG صلب والنموذج يَملأ معاملات العقد). كلاهما يَموت في الإنتاج للأسباب التي مَشى الفصل 9 عليها، والدرس الذي امتصَّه الميدان هو أن التوازن الصحيح بين بنية الإطار وحرية النموذج يَنزاح أبعد نحو النموذج كلما صار النموذج أكثر قدرة.
ما يُمهِّد له الفصل 13
الأُطُر وخدمات السحابة تُتيح للفِرَق شَحن وكلاء قائمين على MCP دون إعادة كتابة كومة البروتوكول كل مرة. ما لا تُخبره الفِرَق وحدها بنفسها هو هل النظام الناتج يَعمل فعلاً — هل الوكيل يَحلّ المهام التي بُني لها، كيف يَتصرَّف تحت الحِمل، أين هاويات الأداء، وكيف يُقارن معماريَّتَين متنافستَين بصدق. يَتولى الفصل 14 ذلك السؤال مباشرةً: يَمشي على معيار MCP-Universe، وضعيتَي الفشل النظاميتَين اللتَين كَشَفهما المعيار (تَدهور السياق الطويل واستكشاف الأدوات المجهولة)، وجانب الإنتاجية حيث الفجوة بين بِركة جلساتٍ مُشتركة ونمط الجلسة-لكل-طلب الساذج تقريباً من رتبة الحجم.
التالي — الفصل 14: المقارنة والاختبار والأداء. MCP-Universe على خوادمٍ حقيقية، تخفيفات السياق الطويل والأدوات المجهولة التي تَعمل، فجوة العشرة أضعاف في الإنتاجية بين الجلسة-لكل-طلب وبِرك الجلسات المُشتركة، وإلى أين تَذهب السلسلة تالياً.
