عندما يفتح السوق أبوابه للوكلاء: إضافة الذكاء الاصطناعي في Amazon Seller Central وطبقة عمليات جانب البائع

النقاط الرئيسية

• فتحت Amazon سطح API الخاص بجانب البائع في Seller Central أمام وكلاء الذكاء الاصطناعي الخارجيين في 23 سبتمبر 2026 — نسخة بيتا في الولايات المتحدة من إضافة Selling Partner لـAmazon Quick وClaude من Anthropic تغطي المخزون والأسعار والقوائم وتحليلات المبيعات.
• 90% من شركاء البيع لدى Amazon يستخدمون بالفعل أدوات ذكاء اصطناعي من أطراف ثالثة، ويقبل البائعون توصيات Seller Assistant في أكثر من 90% من الحالات — Amazon تتبع بائعيها نحو سير عمل بوساطة الوكلاء موجود أصلاً.
• اختارت Amazon مسار الإضافة، لا مسار البروتوكول المفتوح — يبقى UCP وACP وAP2 وx402 معايير لجانب المشتري، وتقرر Amazon هي من يتصل من المساعدين، وقد حظرت وكيل التسوق Muse من Meta من متجرها قبل أيام من الإعلان.
• نموذج الأذونات هو سطح التقييم: أنواع بيانات محددة النطاق، وموافقة بشرية لكل إجراء، ومسارات تدقيق كاملة — يختار البائعون البيانات التي تصل إليها الإضافة، ويوافقون على كل إجراء قبل تنفيذه.
• الإضافة تربط بيانات Amazon بالمساعد — لا حزمة أنظمة البائع نفسها — بائع B2B يشغّل NetSuite أو BigCommerce أو ShipStation ما زال يحتاج طبقة وحدات وكيل خاصة به لتسعير المستويات، ومخزون القنوات المتعددة، والكتابة العكسية للطلبات.

كل معيار تجارة وكلاء تتبّعناه هذا العام — UCP وACP وAP2 وx402 وCheckout MCP — يصف جانب المشتري: كيف يكتشف الوكيل منتجاً، ويتفاوض على سعر، ويُتمّ الدفع، ويسدد. (عرضنا ذلك المكدّس في بروتوكولات التجارة لوكلاء الذكاء الاصطناعي.) في 23 سبتمبر 2026، وفي مؤتمر Accelerate للبائعين، فتحت Amazon الجهة الأخرى من المعاملة. تضع إضافة Selling Partner الجديدة عمليات جانب البائع في أكبر سوق — المخزون والأسعار والقوائم وتحليلات المبيعات — داخل Amazon Quick وClaude من Anthropic، في نسخة بيتا في الولايات المتحدة. والجاذبية قابلة للقياس: 90% من شركاء البيع لدى Amazon يستخدمون بالفعل أدوات ذكاء اصطناعي من أطراف ثالثة لإدارة أجزاء من أعمالهم، والرسوم التي دفعها هؤلاء البائعون إلى Amazon جلبت 46.8 مليار دولار في الربع الثاني من 2026 — أكثر من إيرادات AWS، كما تشير إلى ذلك GeekWire في تغطيتها.

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

ما أطلقته Amazon فعلياً

ثلاثة أشياء أُطلقت في 23 سبتمبر، ويستحق الأمر التمييز بينها لأن لكل منها ملف تقييم مختلف.

Seller Assistant بنسخة مطوّرة. يحمل الرفيق الذكي داخل Seller Central الآن ذاكرة دائمة بأنماط تسعير كل بائع ودورات مخزونه وأهداف نموه، ويعمل على Amazon Bedrock بنماذج Claude. تشير Amazon إلى أنه انتشر لدى أكثر من 90% من شركاء البيع مع مئات الآلاف من المستخدمين النشطين، وأن البائعين يقبلون توصياته في أكثر من 90% من الحالات. هذا الرقم الأخير أهم من ميزة الذاكرة: محرك توصيات تقبله الأغلبية داخل Seller Central هو خط الأساس السلوكي الذي توسّع الإضافة لتغطيته.

سير عمل Seller Assistant. أتمتة تعمل باستمرار تراقب الشروط وتتصرف بإذن — «نبّهني إذا هبط أيٌّ من منتجاتي العشرة الأولى عن تقييم 4 نجوم، واصنع خطة استجابة»، أو «راقب فئتي الأولى بحثاً عن فرص تنافسية؛ إذا رأيت واحدة، فاضبط أسعاري وحدّث القوائم». يضع البائعون الضوابط بلغة طبيعية ويختارون ما إذا كان سير العمل يعرض التوصيات فقط أم ينفّذ الإجراءات. كل إجراء يُسجَّل بمسار تدقيق كامل.

إضافة Selling Partner. السطح الجديد. تربط الإضافة مساهمات القوائم لدى البائع، ومقاييس الأداء اللحظية، ومستويات المخزون، وتحليلات المبيعات بوكيل خارجي — Amazon Quick عند الإطلاق، وClaude في البيتا — ويمكن للوكيل الخارجي التصرف في الحساب كما يفعل Seller Assistant داخل Seller Central. تقول Amazon إن ربط Claude يستغرق نحو 60 ثانية دون أي برمجة، إلى جانب اتصالات بيانات المحاسبة والموردين القائمة لدى البائع.

الصياغة التي جاءت من نائبة رئيس Amazon نفسها هي العنوان الاستراتيجي: «كانت رؤيتنا ألا يضطروا يوماً إلى تسجيل الدخول إلى Seller Central»، قالت ماري بيث وستمورلاند، نائبة رئيس تجربة شركاء البيع على مستوى العالم، في مقابلة مع GeekWire. «نحن ببساطة نوصلها إليهم حيث يعملون.»

لماذا مسار الإضافة لا مسار البروتوكول

بروتوكولات جانب المشتري مفتوحة بالتصميم: UCP لديه مواصفة عامة وشركاء تطوير، وACP يعيش على GitHub، وأي تاجر يمكنه عرض نقطة نهاية. أما فتح جانب البائع فشكله عكس ذلك تماماً. تنشر Amazon إضافة للمساعدين الذين تختارهم — Quick خاصتها أولاً، ثم Claude من Anthropic، الشركة التي استثمرت فيها Amazon مليارات والتي تشغّل نماذجها Seller Assistant أصلاً — وتقول إن تكاملات أخرى ستتبع، مبنية بطريقة «معيارية بما يكفي لنا لمواصلة نشر الإضافات». لا شيء في الإعلان يصف مواصفة يمكن لمنصات أخرى تنفيذها.

يزيد السياق التباين حدة. قبل أيام من مؤتمر Accelerate، حظرت Amazon من متجرها Muse من Meta، وهو وكيل تسوق استهلاكي — معتمدةً الموقف المُعلَن بأن الوكلاء الخارجيين يجب أن يعرّفوا عن أنفسهم ويلتزموا بقواعد المواقع التي يستخدمونها (GeekWire). على جانب البائع، تكون Amazon في الوقت نفسه المضيف وواضع القواعد وناشر الإضافة. سطح الوكلاء لجانب البائع موجود حيث تقول Amazon إنه موجود.

بالنسبة إلى البائعين، هذا ليس مبرراً للامتناع. إنه مبرر لتقييم الشروط بالصرامة نفسها التي تُقيَّم بها القدرات — لأن الطرف المقابل الذي يملك السوق يستطيع أن يوسّع هذا السطح أو يسعّره من جديد أو يضيّقه. رسوم البائعين هي أصلاً موضوع قضية مكافحة الاحتكار التي ترفعها FTC ضد Amazon والمحددة للمحاكمة في مارس 2027 (GeekWire)؛ واقتصاديات أدوات البائعين ليست خلفية محايدة.

يضع المخطط أدناه الإضافة في مواجهة مكدّس بروتوكولات جانب المشتري وبوابات الأذونات التي يفرضها.

ما الذي يضبطه نموذج الأذونات

وصف Amazon نفسها للسلامة دقيق بما يكفي لتقييمه: تفاعلات الإضافة محمية بـ«حدود واضحة لما يمكنها الوصول إليه، وموافقة بشرية على الإجراءات، ومسارات تدقيق كاملة». عملياً، إنها أربع بوابات.

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

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

الموافقة البشرية. تتطلب الإجراءات موافقة البائع قبل تنفيذها، بما يطابق النمط الذي تستخدمه سير عمل Seller Assistant أصلاً: توصية فقط، أو تنفيذ بموافقة.

مسار التدقيق. كل إجراء يُسجَّل. تذكر Amazon أيضاً أنها لا ترى بيانات الأعمال الأخرى في مساعد البائع — اتصالات المحاسبة والموردين التي يحتفظ بها البائع في Claude. هذا تصريح من Amazon عن إنفاذها الذاتي، وليس خاصية قابلة للتحقق بشكل مستقل؛ فتعامل معه على هذا الأساس.

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

الفجوة: الإضافة تربط بيانات Amazon، لا حزمة أنظمة البائع

الربط الذي يستغرق 60 ثانية يربط Amazon بالمساعد. لا يفعل شيئاً للأنظمة التي تُدار فيها فعلياً عملية بائع B2B.

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

المخزون. ترى الإضافة مستويات مخزون Amazon. المخزون عبر القنوات — الرقم SKU نفسه في BigCommerce، وفي مستودع Brightpearl، والمخصص لشحنة ShipStation — هو مسألة مزامنة منفصلة لا تلمسها الإضافة.

الطلبات والكتابة العكسية. طلبات السوق ما زالت تحتاج إلى تحقق، ومنطق ضرائب وشحن، وإدخال إلى ERP. تلك هي طبقة إدارة الطلبات — الطبقة التي خفّض فيها موزّع يضم 380 موظفاً يعالج 1,800 طلب أسبوعياً معدل أخطاء الإدخال من 12% إلى أقل من 2% بفضل التحقق بمخططات مكتوبة النوع عبر NetSuite وBigCommerce وShipStation.

نمط المساعد المختار يقطع في الاتجاهين. إن أطروحة Amazon هي أن البائعين يشغّلون Claude بالفعل «إلى جانب اتصالات بيانات المحاسبة والموردين القائمة لديهم». وحالما تستقر بيانات Amazon في المساعد نفسه، سيطلب البائع منها أن تطابق أسعار Amazon مع تكاليف ERP، ومخزون السوق مع مخزون المستودع. هذا الاستدلال عبر الأنظمة هو بالضبط التكامل الذي لا توفره الإضافة — وطبقة الوكلاء الخاصة بالبائع هي ما يجعله آمناً: وحدات محكومة لكل نظام، ومقابض صريحة لما يمكن للوكيل قراءته وكتابته، ومسار تدقيق يصل إلى الأنظمة التي تدققها الشركة أصلاً.

ما يجب تقييمه قبل تمكين البيتا

أربعة أسئلة، بالترتيب:

1. ما الذي تستطيع الإضافة كتابته، لا قراءته فقط؟ تغييرات الأسعار، وتعديلات القوائم، وتعديلات المخزون فئات مخاطر مختلفة. يميّز سير عمل Amazon بين التوصية فقط والتنفيذ بموافقة — صِنِّف كل سير عمل في فئته الصحيحة قبل تفعيله.
2. أين تقع الموافقة؟ لكل إجراء، أم لكل سير عمل، أم لكل جلسة. الموافقة لكل إجراء على وكيل تسعير هي نموذج تشغيل مختلف عن منح يمتد إلى الجلسة كلها.
3. ماذا يلتقط مسار التدقيق، وإلى أين يمكن أن يصل؟ إذا كان مدقّقك يقرأ NetSuite أو مستودع امتثال، فيجب أن يصل المسار إلى النظام الذي يقرؤه مدقّقك أصلاً.
4. ماذا يحتاج جانب البائع؟ أيٌّ من أنظمتك يجب أن يرى ما فعله الوكيل — ERP، وواجهة المتجر، والمستودع — وكيف تنتقل تلك البيانات؟ هذا هو التكامل الذي تملكه.

طبقة عمليات جانب البائع صارت الآن سطحاً للوكلاء. نفّذت Amazon حركتها بإضافة ونموذج أذونات؛ والجزء الذي يملكه بائع B2B في السوق المتوسطة فعلياً هو كل ما لا تربطه الإضافة.

قراءات ذات صلة

• بروتوكولات التجارة لوكلاء الذكاء الاصطناعي: UCP وACP وAP2 وMCP — كيف تتلاءم مع بعضها — مكدّس بروتوكولات جانب المشتري الذي تكمّله هذه الإضافة: الاكتشاف، وإتمام الدفع، وتفويضات السداد، وفجوة الطبقة الدلالية لقطاع الأعمال
• المزيد من طلبات العروض، فرص حقيقية أقل: طبقة تأهيل من جانب البائع للطلب المُولّد بواسطة الوكلاء — المقابل على جانب الطلب: عندما يولّد الوكلاء التدفقات الواردة، كيف يؤهّلها فريق عروض الأسعار لدى المورّد
• إدارة الطلبات: كيف يتحقق الوكيل من 1,800 طلب B2B أسبوعياً ويخفض معدل الأخطاء من 12% إلى أقل من 2% — كيف تبدو طبقة تكامل جانب البائع خارج حدود السوق: التحقق، وتوجيه التنفيذ، والكتابة العكسية إلى ERP

بناء تمثيلي

بائع B2B في السوق المتوسطة يشغّل Amazon إلى جانب واجهة متجر BigCommerce الخاصة به وNetSuite، ولا يستطيع فريق العمليات لديه مطابقة ما فعله وكيل قناة واحدة مع ما تعتقده الأنظمة الأخرى. يبدأ البناء بجرد الأنظمة (الأسطح التي تغطيها إضافة Selling Partner، وما تكشفه NetSuite وBigCommerce)، وخريطة سير عمل (تعديلات الأسعار، ومزامنة المخزون، واستقبال الطلبات)، ونطاق ثابت: الإضافة من الطرف الأول حيث تناسب، ووحدات MCP مخصصة لـNetSuite وBigCommerce، وسياسة تنسيق تحدد نطاق عمليات الكتابة، وتتطلب موافقة لكل إجراء على تغييرات الأسعار فوق حد معيّن، وتُسقط كل إجراء ينفّذه الوكيل في سجل تدقيق يستطيع كلٌّ من ERP وسير العمل الامتثالي قراءته. أول تدفق متكامل — تغيير سعر على Amazon يتحقق من قائمة المستويات في NetSuite ويعيد كتابة مسار القرار — يعمل خلال 5–8 أسابيع.

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