بروتوكول سياق النموذج (MCP) والخطر الخفي: استهلاك 1200% من المعالج، العمليات اليتيمة ودراسة حالة 'عاصفة إعادة المحاولة' (Retry Storm)

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

في هذه الدراسة التحليلية، نستعرض تفاصيل حادثة تقنية واقعية على محطة التطوير الخاصة بنا، حيث تسببت 12 عملية فرعية من نوع mcp-remote في شل حركة المعالج بالكامل باستهلاك تجاوز 1200% من قدرة النوى على جهاز في وضع الخمول. نكشف الأسباب المعمارية للخلل، ونناقش مخاطر "عواصف إعادة المحاولة" (Retry Storms) على خوادم MCP البعيدة، ونقدم أفضل الممارسات لبناء أنظمة وكلاء ذكاء اصطناعي مرنة ومستقرة.

---

1. العَرَض: لماذا خرج جهاز التطوير عن السيطرة وهو في وضع الخمول؟

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

عند فتح أداة مراقب النشاط (Activity Monitor) في نظام macOS، كانت الأرقام مذهلة:

Process Name      | % CPU   | CPU Time | Threads | PID   | User
---------------------------------------------------------------
node (mcp-remote) | 100.1%  | 42:15.32 | 11      | 78421 | aes
node (mcp-remote) | 99.8%   | 41:58.10 | 11      | 78425 | aes
node (mcp-remote) | 100.0%  | 40:02.44 | 11      | 78440 | aes
node (mcp-remote) | 99.6%   | 39:18.89 | 11      | 78452 | aes
node (mcp-remote) | 100.2%  | 38:45.12 | 11      | 78466 | aes
node (mcp-remote) | 99.9%   | 38:12.01 | 11      | 78480 | aes
... (إجمالي 12 عملية منفصلة)
---------------------------------------------------------------
إجمالي استهلاك المعالج : > 1200% (جميع نوى المعالج الـ 12 مشغولة بنسبة 100%!)
نسبة خمول النظام        : 1.2%

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

---

2. التشخيص العميق: البحث الجنائي في شجرة العمليات عبر الطرفية

لتحديد مصدر الخلل، قمنا بفحص شجرة العمليات (Process Tree) والمقابس الشبكية المفتوحة عبر الطرفية (Terminal):

# تصفية عمليات mcp النشطة
ps aux | grep -iE 'mcp-remote|mcp' | grep -v grep

أظهرت المخرجات قائمة بأوامر npx -y mcp-remote <endpoint> تحاول الاتصال بنقاط نهاية بعيدة ومحلية (تشمل Cloudflare و Google Stitch و Rill و Superset).

وبفحص معرفات العمليات الأصلية (PPID - Parent Process ID):

# فحص العلاقات الهرمية بين العمليات
ps -ef | grep mcp-remote

اتضح المخطط الهرمي التالي:

[نواة نظام التشغيل / launchd (PID: 1)]
    │
    ├── [خادم لغات بيئة التطوير / Language Server] ─── (عمليات mcp-remote فرعية نشطة)
    │
    └── 💀 [عمليات mcp-remote يتيمة / Orphaned] (تبنتها العملية PID 1، وتعمل دون رقيب)

1. عمليات تابعة لعميل نشط: جزء من العمليات كان مرتبطاً بخدمات خلفية نشطة في بيئة التطوير (language_server أو host الإضافات).
2. عمليات يتيمة (Zombies): جزء كبير من العمليات كان ناتجاً عن إغلاق بيئة التطوير أو إعادة تحميلها دون إنهاء العمليات الفرعية بشكل سليم؛ حيث تحولت لعمليات يتيمة تتبناها العملية رقم 1 في النظام (launchd) وتستمر في العمل واستنزاف الموارد عبر جلسات إعادة التشغيل المتتالية.

---

3. الأخطاء المعمارية الثلاثة المتشابكة خلف الكارثة

لم تكن الحادثة مجرد تسريب في الذاكرة (Memory Leak)، بل كانت نتيجة تراكم ثلاثة عيوب تصميمية في بيئة العميل وإدارة الشبكة:

flowchart TD
    A[بدء بيئة التطوير / إعادة تحميل النافذة] --> B[قراءة ملف mcp_config.json]
    B --> C[التشغيل المسبق: إطلاق 12 عملية فرعية]
    C --> D{هل خادم الوجهة متاح وشغال؟}
    D -- لا / ECONNREFUSED --> E[mcp-remote: حلقة تكرار لانهائية بدون Backoff]
    E --> F[استهلاك 100% لكل نواة معالج]
    A -.->|إغلاق البيئة أو انهيارها| G[عدم إرسال إشارة SIGKILL للعملية الفرعية]
    G --> H[تحول العملية ليتيمة وتبنيها بواسطة PID 1]
    H --> F

أ. سلوك "التشغيل المسبق المفرط" (Eager Startup)

تقوم معظم بيئات عملاء MCP الحديثة (Antigravity IDE و Cursor و Claude Desktop وغيرها) بتشغيل كافة الخوادم المعرفة في ملف mcp_config.json كعمليات فرعية بمجرد بدء تشغيل التطبيق، حتى لو لم يطلب المستخدم استدعاء أي أداة منها.

الهدف من ذلك هو تقديم استجابة خالية من التأخير الزمني (Zero-latency) عند استدعاء الأداة. ولكن عندما يحتوي الملف على خادم محلي مغلق (مثل localhost:8085) أو خادم بعيد غير متاح، يبدأ العميل فوراً في إطلاق سيل لا ينتهي من محاولات الاتصال الفاشلة في الخلفية.

ب. حلقة الانشغال اللانهائية وغياب التراجع الأسي في mcp-remote

يكمن العيب القاتل في منطق استعادة الاتصال داخل مكتبة mcp-remote. عند فشل الاتصال بنقطة النهاية (ECONNREFUSED أو ETIMEDOUT)، تدخل المكتبة في حلقة تكرار متزامنة وضاربة (Tight Busy-Wait Loop) تحاول إعادة الاتصال آلاف المرات في جزء من الثانية دون أي تأخير زمني (sleep أو setTimeout).

هذه الحلقة الضيقة حبست مسار تنفيذ Node.js بالكامل وتسببت في تشغيل كل عملية بنسبة 100% على نواة معالج مستقلة. ومع وجود 12 عملية، كان الناتج استهلاك 1200% من طاقة المعالج.

ج. فخ خيار "disabled": true وإهمال دورة حياة العمليات

في محاولة لتعطيل بعض الخوادم التجريبية، تمت كتابة "disabled": true داخل ملف التكوين:

{
  "mcpServers": {
    "rill": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8085/sse"],
      "disabled": true
    }
  }
}

بالإضافة إلى ذلك، عند إعادة تحميل نافذة بيئة التطوير (Cmd+R)، لم يتم تمرير إشارات الإنهاء (SIGTERM/SIGKILL) إلى العمليات الفرعية؛ مما تركها معلقة كعمليات يتيمة تحت إدارة launchd، تتراكم وتتضاعف مع كل إعادة تشغيل.

---

4. منظور الأنظمة الموزعة: هل يمكن لخادم Remote MCP Server الصمود أمام هذا السلوك؟

هذه الحادثة لا تقتصر على كونها تجربة مزعجة على جهاز مطور محلي. دعونا نقلب المنظور لنرى الأمر من زاوية مهندس البنية التحتية الخلفية (Backend Architect):

"ماذا يحدث إذا كنت أنت من يستضيف خادم Remote MCP Server في بيئة الإنتاج، ودخلت آلاف بيئات الوكلاء في حلقة إعادة المحاولة العنيفة هذه؟"

في أدبيات الأنظمة الموزعة، تُعرف هذه الكارثة باسم "عاصفة إعادة المحاولة" (Retry Storm) أو "مشكلة الحشد المتدافع" (Thundering Herd).

sequenceDiagram
    autonumber
    actor Dev as عميل MCP (mcp-remote)
    participant Edge as Cloudflare / API Gateway
    participant Backend as Remote MCP Server (FastAPI/Node)
    
    Note over Dev, Backend: سيناريو 1: خادم خلفي غير محمي (انهيار كامل)
    Dev->>Backend: طلب اتصال TCP / HTTP (المحاولة 1)
    Backend-->>Dev: ECONNREFUSED
    Dev->>Backend: طلب اتصال (بعد 0 ملي ثانية - المحاولة 2)
    Dev->>Backend: طلب اتصال (بعد 0 ملي ثانية - المحاولة 3)
    Note over Backend: آلاف المقابس المفتوحة! استنزاف ulimit -n. اختناق Event Loop. انهيار 502/504!
    
    Note over Dev, Backend: سيناريو 2: بنية تحتية محمية ومرنة
    Dev->>Edge: طلب اتصال TCP / HTTP
    Edge->>Backend: توجيه الطلب
    Backend-->>Edge: 503 Unavailable
    Edge-->>Dev: HTTP 429 Too Many Requests (Retry-After: 30)
    Note over Edge: تفعيل حماية المعدل على الحافة. الخادم الخلفي في أمان تام!

🛑 الخادم غير المحمي (FastAPI / Express / Node.js القياسي):

1. استنزاف واصفات الملفات والمقابس: يطلق العملاء آلاف مصافحات TCP ومحاولات فتح قنوات SSE في الثانية الواحدة. تمتلئ حدود الملفات المفتوحة في نظام التشغيل (ulimit -n) وجداول TIME_WAIT خلال دقائق معدودة.
2. شلل مجموعة خيوط المعالجة (Worker Pools): تضيع كامل طاقة الخادم غير المتزامن ومسارات المعالجة في الاستجابة لمحاولات اتصال شبحية.
3. حجب الخدمة الذاتي (Self-Inflicted DoS): يبدأ الخادم في إرجاع أخطاء 502 Bad Gateway و 504 Gateway Timeout للمستخدمين الفعليين؛ حيث تقوم أدواتك نفسها بإسقاط بنيتك التحتية.

🛡️ بنية الخادم المحمية والمرنة (Cloudflare / API Gateway / Nginx):

1. تقييد المعدل وجدار الحماية (Rate Limiting & WAF): تكتشف البوابة الذكية الانفجار غير الطبيعي في الطلبات القادمة من نفس عنوان الـ IP أو الجلسة، وتقطع الاتصال فوراً برمز HTTP 429 Too Many Requests أو HTTP 403 Forbidden قبل وصوله إلى الخادم الأصلي.
2. قاطع الدائرة الكهربائية (Circuit Breaker): عندما تنخفض صحة الخوادم، تقوم البوابة بإرجاع رمز 503 Service Unavailable مع رأس Retry-After: 60 لإلزام العملاء بالانتظار.

---

5. خطوات حل المشكلة وتنظيف بيئة التطوير

الخطوة 1: إنهاء كافة العمليات العالقة إجبارياً

قمنا بإنهاء جميع العمليات النشطة واليتيمة لمكتبة mcp-remote دفعة واحدة:

# إنهاء كافة عمليات mcp-remote قسرياً
pkill -9 -f "mcp-remote"

الخطوة 2: عزل الخوادم المعطلة في ملف التكوين

بدلاً من الاعتماد على خيار "disabled": true، قمنا بنقل جميع الخوادم غير المستخدمة أو التجريبية خارج كائن mcpServers ووضعها تحت كائن مخصص باسم disabledMcpServers:

{
  "mcpServers": {
    "notebooks": {
      "command": "node",
      "args": ["/Users/aes/tools/notebooks/dist/index.js"]
    }
  },
  "disabledMcpServers": {
    "cloudflare": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.cloudflare.com/mcp"]
    },
    "superset": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:5008/sse"]
    },
    "rill": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8085/sse"]
    }
  }
}

مقارنة الأداء قبل المعالجة وبعدها

عادت مؤشرات النظام وحرارته إلى الوضع الطبيعي فور تطبيق التعديل:

المقياس	أثناء الأزمة (قبل المعالجة)	بعد المعالجة (استقرار كامل)	نسبة التحسن
إجمالي استهلاك المعالج	1200.4%	2.3%	-99.8% 🟢
خمول المعالج (Idle)	1.2%	91.7%	+90.5% 🟢
سرعة المراوح (RPM)	6200 دورة/دقيقة (الحد الأقصى)	0 - 1400 دورة/دقيقة (صامت)	هدوء تام 🟢
العمليات اليتيمة النشطة	12 عملية زومبي	0 عملية	نظيف تماماً 🟢

---

6. أفضل الممارسات المعمارية لمطوري منظومة الـ MCP

سواء كنت تبني أدوات جهة العميل أو تستضيف خوادم Remote MCP Server، يجب تطبيق المبادئ الهندسية التالية:

1. تطبيق خوارزمية التراجع الأسي مع التشتت العشوائي (Exponential Backoff + Full Jitter)

تجنب محاولة الاتصال الفورية والمتكررة دون فاصل زمني. استخدم النموذج الرياضي والنمط البرمجي التالي:

$$t_{\text{wait}} = \min(t_{\text{max}}, t_{\text{base}} \times 2^{\text{attempt}}) + \text{random_jitter}$$

// نمط إعادة الاتصال المرن لعملاء MCP
async function connectWithExponentialBackoff(
  endpoint: string,
  maxAttempts = 10,
  baseDelayMs = 1000,
  maxDelayMs = 30000
) {
  let attempt = 0;

  while (attempt < maxAttempts) {
    try {
      return await establishMcpConnection(endpoint);
    } catch (error) {
      attempt++;
      if (attempt >= maxAttempts) {
        console.error(`[MCP] فشل الاتصال بنقطة النهاية (${endpoint}). توقفت المحاولات.`);
        throw error;
      }

      // حساب التراجع الأسي والتشتت العشوائي
      const exponentialDelay = Math.min(maxDelayMs, baseDelayMs * Math.pow(2, attempt));
      const jitter = Math.random() * exponentialDelay;
      const sleepTime = Math.floor(jitter);

      console.warn(`[MCP] انقطع الاتصال. ستتم المحاولة بعد ${sleepTime} ملي ثانية (محاولة: ${attempt}/${maxAttempts})...`);
      await new Promise((resolve) => setTimeout(resolve, sleepTime));
    }
  }
}

2. إدارة مجموعات العمليات (PGID) وإشارات نظام التشغيل

يجب على مطوري تطبيقات عملاء MCP تتبع العمليات الفرعية ضمن مجموعات العمليات (Process Groups) والتأكد من تمرير إشارات SIGTERM و SIGKILL إلى كامل الشجرة عند إغلاق النوافذ أو إنهاء التطبيق لتفادي تراكم العمليات اليتيمة.

// إغلاق العمليات الفرعية بنظافة
const child = spawn('npx', ['-y', 'mcp-remote', url], { detached: false });

process.on('SIGTERM', () => {
  child.kill('SIGTERM');
  process.exit(0);
});

process.on('exit', () => {
  child.kill('SIGKILL');
});

3. الحماية من جهة الخادم: تجميع الاتصالات وتحديد المعدل

لمطوري خوادم Remote MCP Server:

• ضع خوادمك خلف Cloudflare WAF / API Gateway.
• حدد الحد الأقصى لاتصالات SSE المتزامنة لكل جلسة أو عميل.
• اعتمد إرسال نبضات دورية (Heartbeat / Ping-Pong) لاكتشاف الاتصالات المنقطعة فوراً وتحرير موارد المقابس.

---

7. الخاتمة: الانضباط الهندسي في عصر الوكلاء الأذكياء

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

في رحلتك لبناء وكلاء أكثر ذكاءً، لا تغفل عن تأمين البنية التحتية التي تحافظ على استقرار أنظمتك.

---

مختبر Onmartech التقني | أبحاث بروتوكول سياق النموذج، وكلاء الذكاء الاصطناعي وهندسة الأنظمة السحابية الموزعة