العودة إلى المكتبة
MCP

MCP 2026-07-28: ماذا يعني البروتوكول عديم الحالة لنشر وكلاء B2B

آخر تحديث: 2026年7月5日

لماذا يُغيّر هذا الإصدار حسابات النشر

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

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

طبقة البروتوكول عديمة الحالة

التغيير الرئيسي: تُزال مصافحة initialize / initialized وترويسة Mcp-Session-Id. أصبحت الطلبات مكتملة بذاتها. تنتقل نسخة البروتوكول، ومعلومات العميل، والقدرات في _meta مع كل طلب، لا في جلسة تفاوضية يجب أن يتذكرها الخادم.

ما يُلغيه هذا في نشر B2B:

  • موازنات الحمل للجلسات اللاصقة. يمكن لخوادم MCP البعيدة أن تعمل خلف موازنات حمل بسيطة بنظام round-robin. يستطيع أي مثيل خادم معالجة أي طلب لأنه لا تُتطلب حالة من جانب الخادم لتفسيره.
  • مخازن الجلسات المشتركة. إذا توسّعت أفقيًا اليوم، يحتاج كل مثيل خادم MCP إلى الوصول إلى حالة الجلسة ذاتها — عادةً Redis أو قاعدة بيانات. يُزيل البروتوكول عديم الحالة هذه التبعية.
  • بنية تحتية لإعادة تشغيل الجلسة. عندما تسقط جلسة وسط تدفق عمل، يجب على العميل إعادة التهيئة وإعادة تأسيس السياق. البروتوكول عديم الحالة لا توجد لديه جلسة تسقط؛ كل طلب يحمل ما يحتاجه.

تصبح بنية النشر أبسط: مجموعة من مثيلات خوادم MCP عديمة الحالة خلف موازن حمل، دون طبقة حالة مشتركة بينها. هذا هو الشكل ذاته لأي API HTTP عديم الحالة — مُختبَر في المعارك، وقابل للمراقبة، ورخيص التوسع.

نمط المقبض الصريح لتدفقات العمل ذات الحالة

عديم الحالة لا يعني اختفاء الحالة. التدفقات التي تمتد عبر استدعاءات أدوات متعددة — استقبال RFQ، والتفاوض على عرض سعر، وحجز توفّر — لا تزال تحتاج إلى استمرارية. يستبدل مرشّح الإصدار حالة الجلسة المخفية بـ نمط المقبض الصريح: تُنشئ أداة مقبضًا (order_id، أو quote_id، أو basket_id) ويُمرّره النموذج كوسيطة عادية في الاستدعاءات اللاحقة.

هذا تحوّل ذو مغزى لنشر B2B لثلاثة أسباب.

الحالة مرئية للنموذج. اليوم، تعيش حالة الجلسة في بيانات النقل الوصفية التي لا يراها النموذج اللغوي أبدًا. مع المقابض الصريحة، يحمل النموذج المقبض ويُشير إليه في تفكيره. عندما يستدعي النموذج get_quote(quote_id="q-7f3a")، فإنه يعرف أي عرض سعر يُعامله. يُحسّن ذلك دقة اختيار الأدوات في تدفقات العمل متعددة الخطوات.

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

الحالة قابلة للتخزين المؤقت من قبل الوسطاء. لأن المقبض جزء من الطلب، يستطيع بوابة أو طبقة تخزين مؤقت أن تُستند عليه. تحمل نتائج القائمة والموارد حقول ttlMs وcacheScope، لذا يمكن تقديم استعلام كتالوج بمقبض ثابت من التخزين المؤقت دون الوصول إلى النظام العلوي.

كيف يُرسم هذا إلى تدفق عمل RFQ

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

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

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

الامتدادات: من الدرجة الأولى ومُنسّقة بشكل مستقل

يُقدّم مرشّح الإصدار الامتدادات كمفهوم من الدرجة الأولى. تحصل الامتدادات على مُعرّفات DNS عكسية (مثلًا com.example.workflow)، وتمتلك مستودعات ext-* خاصة بها، ولها مُشرفون مُفوّضون، وتُنسّخ بشكل مستقل عن البروتوكول الأساسي.

الامتدادان الأوّلان ملموسان:

  • MCP Apps — واجهات HTML يُولّدها الخادم تُسلَّم في iframe معزول. يستطيع خادم MCP أن يُسلّم واجهة يعرضها العميل، ما يُتيح سطوح موافقة بشرية في الحلقة دون أن يبني العميل واجهة أمامية مخصصة.
  • Tasks — أعمال طويلة التشغيل بمقابض مهام. تستطيع أداة أن تُعيد مقبض مهمة فورًا ويستطلع العميل اكتمالها، بدلًا من إبقاء الاتصال مفتوحًا لدقائق.

بالنسبة لنشر B2B، تهم MCP Apps حيث يجب أن يوافق إنسان على معاملة قبل أن يُكمل الوكيل — أمر شراء فوق حدّ، أو عرض سعر بخصم غير قياسي. يمكن أن يُسلَّم سطح الموافقة مع وحدة MCP بدلًا من طلب واجهة أمامية منفصلة. وتهم Tasks للتدفقات التي تتجاوز مهلة طلب واحد: عرض سعر مورّد يستغرق 90 ثانية لتوليده، أو مزامنة كتالوج تستغرق دقائق.

الإلغاءات: Roots وSampling وLogging

ثلاث ميزات مُلغاة (تُترك للتعليقات فقط لمدة 12 شهرًا؛ الإزالة تتطلب عملية معايير منفصلة):

  • Roots ← استُبدلت بوسائط الأدوات و URIs للموارد. كانت Roots طريقة يُخبر بها العملاء الخوادم بمواضع نظام الملفات؛ يُعبَّر عن القصد ذاته الآن كوسائط لأدوات تقرأ الملفات.
  • Sampling ← استُبدل بالتكامل المباشر مع مزوّد LLM. الخوادم التي تحتاج استدعاءات LLM تُجرئها مباشرة إلى المزوّد، بدلًا من طلب العميل إجراء ذهاب-وإياع sampling.
  • Logging ← استُبدل بـ stderr و OpenTelemetry. ينتقل تسجيل الخادم إلى المخرجات القياسية للعملية والتتبّع الموزّع، لا إلى قناة تسجيل MCP.

إلغاء Logging هو الأكثر صلة بنشر B2B. نمط تسجيل التدقيق — حيث يُسجَّل كل استدعاء أداة مع الطلب والاستجابة والكمون والنتيجة — يتماشى الآن مع OpenTelemetry بدلًا من قناة تسجيل خاصة بالبروتوكول. يعني هذا أن سجلات خادم MCP تتكامل مع خطوط أنابيب المراقبة القائمة (Datadog، وCloudWatch، وHoneycomb) دون نقل مخصص.

قابل للتوجيه والتخزين المؤقت والتتبّع

ثلاث إضافات تؤثر على عمليات الإنتاج:

  • ترويسات Mcp-Method و Mcp-Name تُتيح توجيه البوابات دون فحص المتن. تستطيع بوابة التوجيه حسب الطريقة واسم الأداة على مستوى الترويسة — دون تحليل JSON في طبقة التوجيه.
  • ttlMs و cacheScope على نتائج القائمة/الموارد تمنح الوسطاء عقد تخزين مؤقت قياسي. تستطيع استجابة قائمة كتالوج أن تُعلن TTL مدته 5 دقائق، وأي بوابة في المسار تستطيع احترامه.
  • انتشار W3C Trace Context موثّق لتوافق OpenTelemetry. ينتشر التتبّع الذي يبدأه عميل الوكيل عبر خادم MCP إلى استدعاءات النظام العلوي، فيظهر تدفق عمل RFQ واحد كتتبّع واحد عبر كل نظام يلامسه.

بالنسبة لنشر B2B يُشغّل خوادم MCP لـ NetSuite وHubSpot وكتالوج مورّد، يعني هذا: تستطيع بوابة التوجيه حسب اسم الأداة دون تحليل المتن، وتخزين استجابات الكتالوج مؤقتًا لـ TTL مُعلن، وتتبّع طلب عرض سعر واحد من الوكيل إلى ERP إلى API المورّد في شجرة spans واحدة.

تعزيز التفويض للشكل واحد-إلى-متعدد

يُحسّن مرشّح الإصدار OAuth و OpenID Connect لشكل النشر الذي تستخدمه أنظمة وكلاء B2B فعلًا: عميل واحد (الوكيل) يتصل بخوادم متعددة (NetSuite، وHubSpot، وBigCommerce، وكتالوج مورّد). تُعالَج إعادة تحميل الرموز، وإدارة النطاقات، ومعالجة بيانات اعتماد الخوادم المتعددة في المواصفات بدلًا من تركها لكل تكامل يحلّها بشكل مستقل.

يهم هذا لأن أنظمة وكلاء B2B لا تتصل بنظام واحد. يربط وكيل RFQ نموذجيًا بـ ERP (NetSuite)، و CRM (HubSpot)، ومنصة تجارة إلكترونية (BigCommerce)، وكتالوجين أو ثلاثة لمورّدين — لكل منها تدفق OAuth خاص به، وعمر رمز، ومجموعة نطاقات. يُقدّم البروتوكول الآن نمطًا قياسيًا لإدارة هذا التعقيد، بدلًا من أن تُطبّق كل وحدة MCP دورة حياة بيانات اعتماد خاصة بها.

ما الذي يتغيّر لوحدات MCP القائمة

إذا كنت تُسلّم وحدات MCP بالفعل — مثلًا نمط مُعالِج RFQ بـ 38 أداة حيث تُسجَّل الأدوات عبر MCP_CONFIGURATION وتُكوّن mixins النطاقات فوق عميل GraphQL مشترك — فإن البروتوكول عديم الحالة يُغيّر النشر، لا كود الوحدة.

تبقى تسجيل أدوات الوحدة، ومخططات الإدخال/الإخراج، وتحديد المعدل، وتسجيل التدقيق كما هي. ما يتغيّر:

  • لا تهيئة جلسة عند الإقلاع. لا تشارك الوحدة في مصافحة initialize. تستقبل الطلبات مع _meta يحمل نسخة البروتوكول والقدرات، وتستجيب.
  • الأدوات ذات الحالة تُنشئ مقابض. إذا كانت أداة اليوم تعتمد على جلسة من جانب الخادم لتتبّع تدفق عمل متعدد الخطوات، فعليها أن تُنشئ مقبضًا صريحًا وتُعيده. يُمرّره العميل في الاستدعاء التالي. بالنسبة لمُعالِج RFQ، فإن request_id وquote_id وhold_id هي المقابض بالفعل — النمط طبيعي للنطاق.
  • ينتقل التسجيل إلى OpenTelemetry. إذا كانت الوحدة تسجّل عبر قناة تسجيل MCP، فانتقل إلى stderr و spans لـ OpenTelemetry. يبقى محتوى التدقيق (الطلب، والاستجابة، والكمون، والنتيجة)؛ يتغيّر النقل.
  • التخزين المؤقت تصريحي. تستطيع نقاط نهاية القائمة والموارد أن تُعلن ttlMs وcacheScope على استجاباتها، ما يُتيح للوسطاء التخزين المؤقت دون تخمين.

الخلاصة لفِرق B2B

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

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

موزّع يُشغّل NetSuite وBigCommerce وثلاثة كتالوجات مورّدين يحصل على وكيل يستقبل RFQ بالبريد الإلكتروني أو البوابة، ويحلّ المنتجات والبدائل مقابل رسم الكتالوج، ويسعّر حسب طبقة العميل، ويحجز المخزون مع انتهاء صلاحية، ويكتب عرض السعر المقبول إلى NetSuite — مع تسجيل كل خطوة. هذا البناء هو المرحلة 2-3 من المنهجية ذات الأربع خطوات ويُسلّم عادةً خلال 5-8 أسابيع.

اطلب بناءًا محدّد النطاق. اكتشاف في أسبوع واحد. تحصل على جرد نظام، وخريطة تدفق عمل، ونطاق ثابت — سواء بنيت معنا أم لا.

هل تريد هذا مبنياً لأنظمتك؟

كل وثيقة هنا من عمل إنتاجي حقيقي. إذا كان لديك نظام مُستهدَف وسير عمل في الذهن، نستطيع تحديد نطاق بناء في أسبوع واحد.

اطلب بناءً محدد النطاق

اكتشاف مدته أسبوع واحد. تحصل على جرد للأنظمة وخريطة لسير العمل ونطاق ثابت — سواء بنيت معنا أم لا.