وكيل، موجه، بوابة: ثلاث كلمات لثلاثة أشياء مختلفة

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

مشكلة المصطلحات هي مشكلة في البنية

مع تحول بروتوكول سياق النموذج (Model Context Protocol) إلى الوسيلة الافتراضية لربط وكلاء الذكاء الاصطناعي بمصادر البيانات والأدوات، أصبحت مصطلحات البنية التحتية متشابكة. يستخدم البائعون والمدونات ووثائق التصميم الداخلية مصطلحات "الوكيل" و"الموجه" و"البوابة" بالتبادل. يكون التمييز غامضًا عندما يكون كل شيء على جهاز كمبيوتر محمول للمطور، ويصبح قاتلاً عندما تبدأ في نشر وكلاء إنتاجيين — لأن الكلمات الثلاث تسمي أشياء مختلفة هيكليًا، ولا يظهر الفرق إلا عندما يطرح المدقق سؤالاً لا يستطيع أحدها الإجابة عليه.

الاستعارة من الشبكات توفر أوضح نموذج ذهني. يعمل الوكيل عند الطبقة الرابعة (L4) — فهو يعيد توجيه البايتات ولا يفسرها. يعمل الموجه عند إرسال القدرات في الطبقة السابعة (L7) — فهو يعرف الأداة، لكنه لا يعرف الكيان الذي يستدعيها. تعمل البوابة عند سياسة الطبقة السابعة (L7) — فهي تعرف الأداة، والكيان، والميزانية، ومسار التدقيق. كل طبقة أكثر قدرة بشكل صارم، وأكثر تكلفة للتشغيل بشكل صارم، وتجيب على أسئلة أكثر بشكل صارم حول كل طلب.

الوكيل: بايتات، لا أكثر

الوكيل هو أبسط جزء في المخطط. وظيفته هي وساطة البروتوكول. يستخدم بروتوكول MCP بشكل مكثف stdio للتنفيذ المحلي؛ يمكن للوكيل أن يغلف خادم MCP القائم على stdio ويعرضه عبر HTTP/SSE أو WebSockets بحيث يمكن لعميل بعيد الوصول إليه. هذه هي وظيفته بالكامل.

لا يقوم الوكيل بأي تفسير للحمولة. لا يحلل JSON-RPC، ولا يفهم استدعاءات الأدوات، ولا يعرف ما تعنيه "الأداة". إنه يعيد توجيه البايتات. وهذا يجعله سريعًا جدًا (أقل من مللي ثانية) وشبه مجاني للتشغيل. مطور واحد يربط Claude Desktop بخادم MCP داخل حاوية Docker على نفس الجهاز — هذا هو سيناريو استخدام الوكيل. لا توجد حوكمة، ولا حالة، ولا سبب لأي منهما.

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

الموجه: توزيع القدرات

مع نمو البيئات، يصبح ترميز عناوين URL للخوادم في العملاء غير قابل للصيانة. يحل الموجه مشكلة الاكتشاف: فبدلاً من أن يعرف العميل مكان وجود خادم github-mcp-server، يتصل العميل بالموجه ويسأل عن الأدوات المتاحة. يحتفظ الموجه بسجل للخوادم التابعة وخريطة للقدرات.

عندما يستدعي LLM الدالة search_repositories، يفحص الموجه حمولة JSON-RPC، ويحدد الأداة المستهدفة، ويرسل الاستدعاء إلى الواجهة الخلفية الصحيحة. إنه، ميكانيكيًا، مجمع مزود بجدول توجيه — سريع وبسيط وتجريد نظيف. تلجأ معظم الفرق الداخلية إليه بمجرد أن يكون لديها أكثر من خادمي MCP، وهم محقون في ذلك.

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

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

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

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

تفحص البوابة كل حزمة. تتكامل مع هوية الشركة (OAuth 2.0, SAML, OIDC) لتحديد هوية الوكيل الذي يعمل نيابة عنه. تفرض التحكم في الوصول المستند إلى الدور (RBAC) على مستوى الأداة. تقوم بتشغيل تنقية المخطط التي تكتشف تسمم MCP. تتتبع استخدام الرموز المميزة لتحديد الميزانية. تكتب سجلات مقاومة للتلاعب إلى أنظمة SIEMs الخارجية. إنها، هيكليًا، المكان الذي يتم فيه ترميز سياسة الذكاء الاصطناعي للمؤسسة — والمكان الوحيد الذي يتوقف فيه وكيل المقاول الذي تم إنهاء خدمته عن العمل في اللحظة المناسبة.

مصفوفة القدرات

المقارنة نفسها في شكل جدولي، لمراجعي وثائق التصميم الذين سيلقون نظرة سريعة. اقرأ الأعمدة؛ كل عمود يجيب على سؤال حول طلب.

الجدول 1 — مصفوفة القدرات. العمود الأيمن هو ما سيسأل عنه مدقق الحسابات الخاص بك؛ العمود الأوسط هو ما سيلجأ إليه فريقك أولاً؛ العمود الأيسر هو ما يعمل على جهاز الكمبيوتر المحمول الخاص بك.

إطار عمل اتخاذ القرار

شجرة قرار قصيرة، مكتوبة بالترتيب الذي تجيب به فرق الإنتاج على الأسئلة فعليًا:

• استخدم وكيلًا (proxy) عندما تكون مطورًا منفردًا يربط أدوات محلية عبر مساحات أسماء الشبكة — من WSL إلى مضيف Windows، ومن المضيف إلى حاوية Docker. نطاق التأثير يقتصر على جهازك.
• استخدم موجهًا (router) عندما تكون فريقًا صغيرًا يدير عددًا قليلاً من الوكلاء الداخليين الذين يحتاجون إلى نقطة اكتشاف موحدة، وتثق ضمنيًا بكل شخص على الشبكة، ويمكن التراجع عن أسوأ إجراء للأداة.
• استخدم بوابة (gateway) عندما تقوم بنشر الوكلاء في بيئة الإنتاج، أو طرح Claude Code لأكثر من عشرة مطورين، أو تتعامل مع قواعد بيانات من أي نوع، أو تعمل ضمن أي إطار امتثال يتطلب مسارات تدقيق (audit trails) والوصول بأقل امتيازات.

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

كيف تطبق TrueFoundry طبقة البوابة

تم بناء TrueFoundry كبوابة موحدة (federated gateway). يتم فصل مستوى التحكم (حيث يتم صياغة السياسات وتسجيل النماذج وتعيش قابلية المراقبة) عن مستوى البوابة (حيث تتدفق حركة المرور). مستوى البوابة عديم الحالة تمامًا — تشترك كل وحدة بوابة (pod) في مستوى التحكم عبر NATS لتحديثات التكوين، وكل فحص تجريه يكون في الذاكرة مقابل تلك الحالة المتزامنة. لا توجد نقطة فشل واحدة بين الوكيل والواجهة الخلفية. إذا تعطل مستوى التحكم، تستمر البوابات في الخدمة بتكوينها الأخير المعروف؛ وعندما يعود مستوى التحكم، يقوم NATS بالمصالحة. كإجراء أمان أخير، يعيد مستوى التحكم نشر التكوين بالكامل كل 10 دقائق — يتم ضمان الاتساق النهائي حتى لو فات تحديث وسيط.

‍

تم بناء مستوى البيانات على Hono — وهو إطار عمل متوافق مع Web Fetch API ومُحسّن للحافة — ويقوم بإجراء جميع فحوصات حدود المعدل والمصادقة والتوجيه في ذاكرة العملية. يقوم مستوى التحكم بمزامنة التكوين عبر NATS بوتيرة أقل من الثانية؛ مسار الطلب نفسه لا يقوم أبدًا بإجراء مكالمة خارجية ما لم يتم استدعاء ذاكرة التخزين المؤقت أو حاجز حماية قائم على الشبكة. الخاصية الهيكلية المهمة هي عدم الحالة (statelessness): يمكن إنهاء وحدة بوابة (pod) في أي لحظة دون فقدان قرارات السياسة قيد التنفيذ، لأنه لا توجد قرارات سياسة قيد التنفيذ — كل قرار يتم اتخاذه من الذاكرة المحلية مقابل التكوين الذي وصل بشكل غير متزامن.

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

نفس العميل، نفس الواجهات الخلفية، وسط مختلف تمامًا. الوسط هو الجزء الذي يصمد جيدًا مع مرور الوقت.

النقطة الأعمق

الهندسة المعمارية هي في الغالب ممارسة اختيار مكان الحدود، وتكلفة الخطأ في هذا الاختيار لا تُدفع وقت التصميم، بل عند الحادث التالي، أو التدقيق التالي، أو الترحيل التالي. التمييز بين الوكيل (proxy) والموجه (router) والبوابة (gateway) ليس مشكلة مصطلحات. إنه سؤال حول ما إذا كانت منصتك تحتوي على نقطة تحكم عند نقطة التقاء هوية الشركة بحلقة الوكيل، أو ما إذا كانت تحتوي على جدول توجيه حيث يجب أن تكون نقطة تحكم.

تكتشف معظم الفرق هذا التمييز بالطريقة الصعبة. يكتشفه البعض أثناء تحليل ما بعد الحادث (postmortem)؛ والبعض الآخر أثناء مراجعة الامتثال؛ والبعض عندما يستمر وكيل مقاول تم إنهاء خدمته في العمل لمدة أسبوع أطول مما ينبغي. لحظة الاكتشاف هي نفسها في جميع الحالات الثلاث. تكلفة الاكتشاف هي ما يختلف.

الأسئلة الشائعة

هل يمكنني تشغيل موجه اليوم وإضافة بوابة لاحقًا؟

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

كيف تتصرف البوابة إذا كان مستوى التحكم معطلاً؟

تستمر البوابات في خدمة حركة المرور بناءً على آخر تكوين جلبته، إلى أجل غير مسمى. تشترك في NATS للحصول على تحديثات مباشرة، وكإجراء احتياطي، تعيد محاولة جلب التكوين عبر HTTP من خدمة الواجهة الخلفية لمستوى التحكم. إذا كان كل من NATS والواجهة الخلفية معطلين، تستمر حاويات البوابة الحالية في العمل بالتكوين المعروف الأخير؛ والحاويات الجديدة التي تحاول البدء أثناء الانقطاع ستفشل في فحص الجاهزية ولن تستقبل حركة المرور. التوصية هي تشغيل نسخ متعددة من البوابة — فرصة إعادة تشغيلها جميعًا أثناء انقطاع مستوى التحكم هي الفرصة التي يجب عليك العمل على تجنبها، وهي صغيرة.

لماذا Hono تحديدًا؟ ما المزايا التي قدمها Hono مقارنة بـ Express أو Fastify؟

تم بناء Hono على واجهة برمجة تطبيقات Web Fetch ومصمم لبيئات التشغيل الطرفية (Cloudflare Workers, Deno, Bun, Node). إنه صغير وسريع ويعمل بشكل متطابق عبر بيئات التشغيل — وهذا مهم لأن البوابة يجب أن تكون قابلة للنقل عبر SaaS، و Kubernetes المحلية، والبيئات المعزولة التي تستخدم وكيل Squid. يتمتع Express بمساحة سطح كبيرة جدًا؛ Fastify جيد ولكنه مرتبط بخصائص Node. الخاصية المهمة هي الحمل الزائد المنخفض المتسق عند التزامن العالي، وهو ما يقدمه Hono بشكل موثوق.

هل تركيب MCP الافتراضي مجرد دمج ثابت، أم أنه يحدد النطاق لكل متصل فعليًا؟

يحدد النطاق لكل متصل. تقوم البوابة بتقييم سمات IAM و ABAC للمستخدم الرئيسي مقابل حزمة السياسات في كل مرة تقدم فيها قائمة أدوات (tools/list)، وتصدر اتحادًا مصفى من واصفات الأدوات. يمكن لمطورين يسجلان الدخول بفارق ثوانٍ أن يستقبلا قوائم أدوات مختلفة من نفس نقطة نهاية البوابة. لا يعرف النموذج أبدًا أن هناك واجهات خلفية متعددة، ولا يعرف أبدًا أن هناك أدوات لا يمكن للمتصل الحالي الوصول إليها. هذه هي أيضًا الطريقة التي تحصل بها على عمليات نشر متعددة المستأجرين نظيفة — نفس البوابة تخدم مستأجرين مختلفين عوالم مختلفة.

كيف تمنع البوابة انحراف التكوين بين مستوى التحكم والحاويات؟

ثلاث آليات. حمولات التكوين متطابقة (idempotent) — ينشر مستوى التحكم الحالة الحالية بأكملها إلى NATS عند كل تغيير، لذا فإن استلام نفس الرسالة مرتين ليس له أي تأثير. يوفر NATS تسليمًا مرة واحدة على الأقل، لذا سترى البوابة كل تحديث مرة واحدة على الأقل. وكإجراء احترازي إضافي، يعيد مستوى التحكم نشر التكوين الكامل كل 10 دقائق — حتى لو فات تحديث وسيط، تتقارب البوابة إلى الحالة الصحيحة في غضون 10 دقائق في أسوأ الأحوال. الانحراف محدود بالتصميم.

‍