MCP

منصة Archestra للذكاء الاصطناعي المؤسسي: لمن تناسب ودليل أول تشغيل عبر Docker

الفرق التي تريد توحيد دخول MCP في بيئة مستضافة ذاتيًا مناسبة لتجربة Docker quickstart من Archestra مرة واحدة؛ لكن أمر التشغيل يركّب /var/run/docker.sock الخاص بالمضيف ويكتب في أحجام بيانات محلية، وarchestra/platform:latest يشغّل عادة release candidate — اقبل النقطتين قبل التجربة.

Official source · Archestra

Install

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

لمن تناسب هذه المنصة

  • التصنيف الرسمي أنها «منصة مفتوحة المصدر شاملة للذكاء الاصطناعي المؤسسي»: تجمع في آن واحد أدوار MCP registry وgateway وorchestrator، وليست خادم MCP لغرض واحد. الشكل الملائم: فريق يستضيف المنصة بنفسه على أجهزته ويوجّه المستخدمين والوكلاء (agent) وعملاء Claude / Codex / Cursor إلى رابط URL واحد؛ تتولى المنصة نداءات الأدوات كلها، ولا يعرف العملاء سوى مدخل واحد.
  • يعتمد MCP gateway لديها على OAuth + On-Behalf-Of بحيث تعمل الأدوات بهوية المستخدم نفسه لا بحساب خدمة مشترك؛ والفرق الواضح لصالح الفرق التي يعنيها إسناد كل نداء إلى شخص بعينه.
  • معيار الحكم: إن كانت مشكلتك مجرد «أداة ناقصة عند عميل واحد»، فخادم MCP واحد يكفي؛ أما طبقة المنصة فلا تجيء إلا عند إدارة خدمات متعددة وعملاء متعددين وهويات متعددة في مكان واحد.
  • البيئة الملائمة: فرق تستطيع تشغيل Docker محليًا أو على الشبكة الداخلية وتقبل تقييم كلفة تركيب الـsocket؛ يربط quickstart المنافذ بعنوان الاسترجاع (loopback)، ما يناسب التجربة أولًا على جهاز واحد ثم التشغيل الطويل بعد قبول التبعات.
  • شرط التشغيل: وجود Docker على الجهاز. لا تذكر الأدلة حدًّا أدنى للموارد ولا نطاق أنظمة التشغيل المدعومة ولا طريقة تشغيل خارج Docker، وكل ذلك غير مؤكد.

أول تجربة في 3 دقائق

  • قبل التنفيذ تأكد أنك تقبل تبعتين صرحت بهما الوثيقة الرسمية: الأولى أن الأمر يركّب /var/run/docker.sock الخاص بالجهاز المضيف، فيصبح بوسع الحاوية التحكم في Docker daemon الخاص بالمضيف؛ والثانية أن وسم latest في الصورة يشير إلى أحدث release ويشغّل عادة release candidate. هاتان النقطتان مكتوبتان في الوصف الرسمي وتدخلان في التقييم من البداية، وليستا تفصيلًا يؤجل إلى ما بعد النشر.
  • والتشغيل الأول ليس عملية قراءة فقط: الحجمان المسمّيان archestra-postgres-data وarchestra-app-data يكتبان بيانات قاعدة البيانات والتطبيق في أحجام Docker محلية؛ لا يوجد أمر رسمي للتنظيف أو التراجع، والأدلة لا توضح إن كانت البيانات القديمة تؤثر في التشغيلات الجديدة بين التجارب المتكررة، فلا تجرب على مضيف يضم بيانات مهمة.
  • بعد القبول نفّذ أمر التشغيل السريع الرسمي:
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • إشارة النجاح القابلة للتأكد تقف عند هذا الحد: الحاوية تبقى تعمل، والمنفذان لا يرتبطان إلا بعنوان الاسترجاع 127.0.0.1؛ والإعداد الذي يطلبه quickstart صراحةً هو ARCHESTRA_QUICKSTART=true مع هذه المنافذ والأحجام المركبة. ولأن الربط على الاسترجاع فقط، فالوصول افتراضيًا من الجهاز المحلي وحده، وطرق إعداد الوصول البعيد غير مذكورة في الأدلة.
  • الخطوة التالية توجيه Claude / Codex / Cursor إلى هذا الـURL الواحد؛ قيمة الـURL تحديدًا ليست في الأمر وتُستكشف من جهة المنصة بعد إقلاعها. وكيف تتم أول عملية تسجيل دخول، كذلك لم تُذكر.

حالات الاستخدام

  • الحالة الأولى: مدخل واحد لعملاء متعددين. المشهد: فريق يضم من يستخدم Claude وCodex وCursor ولا يريد توصيل MCP لكل عميل على حدة. العملية: شغّل المنصة بالتشغيل السريع أعلاه ووجّه العملاء إلى رابط Archestra نفسه. المتوقع: تمر نداءات الأدوات عبر MCP gateway وتنفّذ بهوية المستخدم نفسه، وتصل الأدوات نفسها إلى العملاء الثلاثة من المدخل نفسه. الحد: الأدلة لا تعطي قائمة بالخدمات التي تقبلها جهة المنصة، فتأكد قبل التوصيل أن الخدمات التي تحتاجها مدرجة.
  • الحالة الثانية: دون حساب خدمة مشترك. المشهد: فريق لا يقبل أن تُسجَّل كل نداءات الأدوات باسم حساب خدمة مشترك. تعتمد على آلية الهوية نفسها في الـgateway. العملية: بعد التوصيل تحقق أن الأدوات تعمل بهوية المستخدم نفسه؛ وإن كانت أتمتتك الحالية تعمل بحساب مشترك فيمكن المقارنة قبل وبعد. المؤكد: النص الرسمي يقول ذلك؛ أما شكل واجهة إعداد الحسابات وسجلات النداءات فلم تذكره الأدلة، فلا تفترض وجودهما.
  • الفرق بين الحالتين: الأولى تختبر توحيد المدخل والثانية تختبر إسناد الهوية، ويمكن تجربة كل منهما مرة بالتتابع.

حدود الاستخدام

  • طبيعة القراءة والكتابة: التشغيل الأول يكتب حالة محلية فورًا (حجمان مسمّيان)؛ وتركيب الـsocket يمنح الحاوية قدرة على التحكم بحاويات المضيف، وهو أثقل تبعات العملية ويستحق تقييمًا مستقلًا.
  • بيانات الاعتماد والهوية: يعتمد الـgateway على OAuth؛ وكيفية إعداد المزوّد وما إذا كان لا بد من توصيل مصدر هوية أولًا أمر لم توضحه الأدلة، وهو غير مؤكد.
  • علاقة العملاء بالمنصة: الخطاب الرسمي هو توجيه المستخدمين أو الوكلاء أو العملاء إلى URL واحد وتولي المنصة الباقي؛ أما الإصدارات أو الإضافات التي يحتاجها كل عميل فغير مذكورة.
  • حد الإصدار: الخطاب الرسمي أن نشر الإنتاج يجب أن يثبّت وسم إصدار محددًا؛ فوسم latest يقابل عادة release candidate، فلا تحمّله عبء الإنتاج مباشرة.
  • ترتيب الأفعال: اقبل أولًا تركيب الـsocket ومسألة الإصدار ثم نفّذ الأمر؛ وأنجز أول تجربة في بيئة الاسترجاع المحلية ولا تفتحها على الشبكة العامة مباشرة.
  • معلومات جوهرية غير مؤكدة: استهلاك الموارد، وخطوات الترقية والتراجع، وطريقة النسخ الاحتياطي، وتصريحات القراءة/الكتابة لأدوات MCP داخل المنصة، وسياسة بيانات الاعتماد المبدئية — كلها غير مشمولة بالأدلة؛ ولا تضع بيانات حقيقية في بيئة أول تجربة. عدم وجود شرح لا يعني عدم وجود خطر، والمرجع هو الوثائق الرسمية.