تطبيقات ومهام MCP: إدارة إضافات MCP الجديدة الأساسية

الشيء نفسه إصدار MCP 2026-07-28 الذي جعل البروتوكول عديم الحالة، رفع أيضًا امتدادين إلى مستوى الدرجة الأولى: تطبيقات MCP، التي تسمح للأداة بإرجاع واجهة مستخدم تفاعلية معروضة في إطار iframe معزول، والمهام، التي تحاكي العمل طويل الأمد كآلة حالة دائمة يديرها العميل باستخدام tasks/get و tasks/update و tasks/cancel. إنها مفيدة حقًا — وهي أسطح حوكمة وأمان جديدة تمامًا. تشرح هذه المقالة كيفية عمل كل منها، وأين تكمن المخاطر الجديدة، ولماذا تعتبر البوابة هي المكان المناسب لحوكمتها.

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

لم يكن أي منهما خطأً في كود هانا. كانت هذه الأسطح الجديدة تفعل بالضبط ما تسمح به المواصفات، في نظام كان لديه حوكمة لمكالمات الأدوات ولكن ليس لواجهات المستخدم المعروضة أو المهام طويلة الأمد. لم يقتصر إصدار 2026-07-28 على تبسيط النقل فحسب؛ بل أضاف مكانين حيث تكمن القيمة — والمخاطر — الآن. تشرح هذه المقالة كيفية البناء عليها دون تكرار تجربة هانا الصعبة.

1. ما هي تطبيقات ومهام MCP، ولماذا أصبحت الآن من الدرجة الأولى

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

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

2. تطبيقات MCP: واجهة المستخدم المعروضة من الخادم كسطح جديد

يسمح تطبيق MCP للأداة بإرجاع مورد واجهة مستخدم تفاعلي يعرضه المضيف في إطار iframe معزول. التشبيه من مناقشة المواصفات مناسب: إنه يعزز الأداة بالطريقة التي تعزز بها لوحة المعلومات المستضافة واجهة برمجة التطبيقات. عقد JSON الخاص بالأداة لم يتغير؛ التطبيق هو الواجهة التفاعلية التي يمكن للمضيف عرضها للمستخدم. بالنسبة لأداة تقرير هانا، التطبيق هو لوحة المعاينة.

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

3. سطح الأمان للتطبيقات: يقرأه كل من المستخدم والنموذج

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

الموقف العملي هو التعامل مع محتوى التطبيق كمخرجات غير موثوق بها تحتاج إلى نفس الفحص مثل أي محتوى آخر مجاور للنموذج: فحص وتنقية ما يتم عرضه، وعدم إدراج بيانات خام غير موثوق بها في الواجهة دون معالجة، والحفاظ على بيئة التطبيق المعزولة (sandbox) صارمة. حقل اسم المورد الخاص بـ Hana هو الخطأ النموذجي — بيانات غير موثوق بها يتم إدراجها في واجهة معروضة يستهلكها كل من المستخدم والنموذج، بدون أي حواجز حماية بينهما.

4. المهام: عمل طويل الأمد في بروتوكول أصبح عديم الحالة

كانت المهام تجريبية في الإصدار الأساسي 2025-11-25؛ ينقلها إصدار 2026-07-28 إلى إضافة رسمية ذات دورة حياة مصممة للعالم عديم الحالة. النموذج مدفوع بالطلب: يمكن للخادم الرد على استدعاء أداة (tools/call) بمعرف مهمة بدلاً من نتيجة فورية، ثم يدير العميل العمل باستخدام tasks/get و tasks/update و tasks/cancel. (تضمنت الواجهة التجريبية السابقة 2025-11-25 أيضًا tasks/list و tasks/result؛ يعيد الإصدار المرشح (RC) تشكيل دورة الحياة حول get/update/cancel ويزيل tasks/list، التي لا يمكن تحديد نطاقها بأمان بمجرد أن يصبح البروتوكول عديم الحالة. تعامل مع مجموعة الطرق المحددة على أنها خاصة بالإصدار المرشح وتأكد من تسليم النتائج مقابل المواصفات النهائية.) المهمة هي، في الواقع، آلة حالة صغيرة دائمة بالإضافة إلى مؤشر لنتيجتها.

يتم التفاوض على الدعم بشكل دقيق — لا يكتفي النظير بالقول "أنا أدعم المهام"، بل يحدد الطلبات التي يمكن تعزيزها بالمهام. خريطة الإمكانيات واضحة بشأن ذلك:

التفاوض على المهام في الإصدار المرشح 2026-07-28 — توضيحي؛ تأكيد معرف الإضافة والمخطط الدقيقين مقابل المواصفات النهائية

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol.tasks": {   // reverse-DNS extension identifier
        "requests": {
          "tools": { "call": {} }          // only tools/call may be task-augmented here
        }
      }
    }
  }
}

الشكل أعلاه يوضح إطار عمل الإضافات الخاص بالإصدار المرشح، وليس مخططًا حرفيًا. كان نموذج capabilities.tasks السابق مع tasks/list ينتمي إلى إصدار 2025-11-25 التجريبي لواجهة برمجة تطبيقات المهام؛ ينقل الإصدار المرشح التفاوض تحت خريطة إضافات معرفة بواسطة DNS العكسي. تأكد من المعرف والحقول النهائية مقابل مواصفات 28 يوليو قبل التنفيذ.

أي شيء غير مدرج ضمن الطلبات يبقى متزامنًا؛ يجب ألا يحاول العميل تعزيز طلب لم يعلن عنه الخادم بمهمة. هذه هي الطريقة النظيفة والأصلية لـ MCP لتحقيق التزامن دون اختراع قنوات جانبية — وهي تتوافق مع النواة عديمة الحالة لأن معرف المهمة هو معرف صريح صادر عن الخادم يعيده العميل، وهو بالضبط نمط الحالة الصريحة الذي يشجعه النموذج عديم الحالة.

5. مراقبة مهمة: دورة الحياة والتقدم والتكلفة

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

إنجاز مهمة مع رؤية واضحة في كل خطوة (حلقة عميل توضيحية)

resp = call_tool("generate_report", args, task_augmented=True)
task_id = resp.task_id                       # server-minted handle

while True:
    state = tasks_get(task_id)                # poll; gateway records each transition
    emit_progress(task_id, state.status, state.progress, state.tokens_so_far)
    if state.status == "input_required":
        tasks_update(task_id, provide_input())
    elif state.status in ("completed", "failed", "cancelled"):
        break
    sleep(backoff())                          # respect the server's polling guidance

result = state.result if state.status == "completed" else None  # final result shape is RC-specific

هذه هي نفس قصة المراقبة كما في بقية السلسلة، مطبقة على كائن جديد. الـ تتبع الذي يلتقط طلبًا عاديًا يجب أن يتعامل مع المهمة (Task) كنطاق (span) يبقى مفتوحًا طوال دورة حياتها، مع نسب محاسبة الرموز والتكلفة إليها. بوابة MCP من TrueFoundry تتتبع بالفعل كل استدعاء لخادم MCP وتنسب الاستخدام حسب المستخدم والأداة والفريق؛ المهمة (Task) هي نفس القياس عن بعد الممتد عبر الزمن بدلاً من التقاطه في لحظة واحدة — وهو بالضبط الجزء المفقود في أداة تقارير هانا.

6. الحوكمة: من يمكنه تشغيل التطبيقات والمهام، وبأي ميزانية

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

سياسة البوابة التوضيحية للواجهات الجديدة (المخطط خاص بالبوابة)

tasks:
  allow_launch:
    roles: ["agent:report-writer", "team:finance"]   # default-deny otherwise
  limits:
    max_runtime_seconds: 300                           # force-cancel past this
    max_tokens: 200000                                 # budget ceiling per task
  observability: trace_lifecycle                       # record every state transition

apps:
  output_guardrails: [pii, injection, toxicity]        # scan rendered content
  sandbox: strict                                      # host renders in a locked-down iframe

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

الحواجز الوقائية هي حيث يصبح هذا ملموسًا، لأن البوابة تقوم بالفعل بفحص المحتوى بناءً على مجموعة موثقة من نقاط الربط (hooks). تكشف بوابة TrueFoundry عن أربعة — llm_input و llm_output على حركة مرور النموذج، و mcp_pre_tool و mcp_post_tool على حركة مرور الأدوات — ويرتبط بكل منها أي عدد من أدوات التحقق (اكتشاف معلومات التعريف الشخصية PII، فحص الأسرار، مصنفات حقن الأوامر والسمية، أدوات تنقية SQL، فحوصات السياسة عبر Cedar أو OPA). تتفرع هذه الأدوات بالتوازي على نفس الطلب، لذا فإن حاجز الإدخال يعمل بالتزامن مع استدعاء النموذج ويمكنه إلغاؤه قبل فوترة الرموز إذا قام بالحظر. الانضباط التشغيلي الذي يحافظ على سلامة هذا في الإنتاج هو طرح تدريجي — تدقيق (تسجيل الانتهاكات، السماح بمرور حركة المرور)، ثم فرض (الحظر عند الفشل، الفشل المفتوح عند أخطاء المزود)، ثم صارم — لذلك فإن انقطاع مزود الحواجز الوقائية لا يعطل المسار بأكمله في اليوم الأول أبدًا.

7. الترحيل: من المهام التجريبية إلى دورة الحياة الجديدة

إذا اعتمدت واجهة برمجة تطبيقات المهام التجريبية (Tasks API) من الإصدار الأساسي 2025-11-25، فإن الانتقال إلى الامتداد هو ترحيل حقيقي، وليس مجرد إعادة تسمية. تمت إعادة تنظيم دورة الحياة والأساليب حول tasks/get و tasks/update و tasks/cancel، وأصبح التفاوض على القدرات الآن صريحًا ومفصلاً. الخبر السار هو أن سياسة الإهمال المعتمدة في هذا الإصدار تضمن تداخلًا لمدة اثني عشر شهرًا على الأقل بين إهمال أي شيء وإزالته، لذلك تستمر الواجهة القديمة في العمل أثناء انتقالك بدلاً من التوقف في تاريخ معين.

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

8. مكان هذا: البوابة كنقطة حوكمة

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

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

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

هل تطبيقات MCP مجرد طريقة لإرجاع HTML؟

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

هل البروتوكول عديم الحالة يجعل المهام غير ضرورية؟

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

ما هو أكبر خطر جديد يجب الاستعداد له؟

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

هل أحتاج إلى الترحيل الآن؟

خطط الآن؛ تم تثبيت الإصدار المرشح في 21 مايو 2026 ومن المتوقع الانتهاء منه في 28 يوليو، مع تغييرات جذرية إذا كنت قد استخدمت واجهة برمجة تطبيقات المهام التجريبية (Tasks API). تداخل فترة الإهمال لمدة اثني عشر شهرًا يعني أنه لن يتعطل أي شيء في التاريخ المحدد، ولكن العمل الجديد يجب أن يستهدف دورة حياة الامتداد ويتفاوض على القدرات بشكل صريح. تعامل مع الإصدار المرشح (RC) على أنه مؤقت حتى التصديق.

حوكمة التطبيق أو المهمة — البوابة أم التطبيق؟

البوابة للتحكمات الشاملة: أي الوكلاء يمكنهم تشغيل التطبيقات والمهام، وحدود المهلة والميزانية، وحواجز حماية المخرجات على المحتوى المعروض، وتتبع دورة الحياة — تُطبق بشكل موحد عبر كل خادم MCP. لا يزال التطبيق يمتلك منطق المجال لما يعرضه التطبيق وما تفعله المهمة، لأن ذلك يتطلب معرفة لا تملكها البوابة.

يُذكر إصدار 28-07-2026 بأنه أصبح عديم الحالة، لكن التطبيقات والمهام هي الجزء الذي يغير ما تبنيه. إنها تضيف واجهة عرض وواجهة تشغيل طويلة الأمد، وتوفر المواصفات الآلية وتترك الحوكمة مفتوحة. سد هذه الفجوة عند البوابة — افحص ما يُعرض، حدد ما يُشغل، تتبع كلاهما — وسيصبح العرض التوضيحي الجيد لهانا نظام إنتاج جيدًا.

إذا كانت البوابة هي المكان الذي تحكم فيه هذه الواجهات، فمن المفيد أن تكون نفس لوحة التحكم هي أيضًا المكان الذي تعمل فيه الوكلاء الذين يستخدمونها. TrueFoundry's بوابة الذكاء الاصطناعي هي نقطة الدخول الموحدة لحركة مرور النماذج وMCP والأدوات، و نظام إدارة الوكيل هو بيئة التشغيل التي تنسق حلقة التخطيط-التنفيذ-المراقبة للوكيل، والعزل (sandboxing)، والموافقات، والتتبع فوق ذلك — لذا يتم فحص محتوى التطبيق الذي يعرضه الوكيل والمهام التي يطلقها، وتحديد حدودها، وتتبعها بواسطة نفس المستوى الذي يدير الوكيل، بدلاً من طبقة حوكمة تُضاف بعد ذلك.

المراجع

• بروتوكول سياق النموذج — المرشح للإصدار بتاريخ 28-07-2026 (الإضافات، تطبيقات MCP، المهام)
• MCP 25-11-2025 — واجهة برمجة تطبيقات المهام التجريبية (الواجهة السابقة؛ المرشح للإصدار بتاريخ 28-07-2026 يعيد تشكيلها كإضافة)
• تروفاوندري — بوابة MCP (الاكتشاف، RBAC، قابلية المراقبة)
• منشوراتنا حقن الأوامر و OpenTelemetry للنماذج اللغوية الكبيرة — حواجز حماية المخرجات والتتبع، مطبقة على الواجهات الجديدة.

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

‍