Claude يفتح مخطط وكلاء التجارة، لكن الدفع يبقى خارج الوكيل
أطلقت Anthropic في 2 سبتمبر 2026 مخططًا مفتوحًا لبناء وكلاء تجارة عبر Claude، يضم تطبيقين مرجعيين: وكيل تسوق داخل موقع التاجر أو تطبيقه، ووكيل تاجر لفرق التشغيل. وينص إعلان Anthropic عن المخطط على أن وكيل التسوق يبحث ويقارن ويبني السلة ثم يسلمها إلى مسار الخروج، بينما يظل تنفيذ الدفع لدى التاجر أو مزود الدفع الذي يختاره.
وفي التاريخ نفسه، وصفت تغطية Digital Commerce 360 الإطلاق بأنه تصميمان مسبقا البناء لدوري التسوق والتشغيل، وأكدت أن دور وكيل المتسوق ينتهي عند إضافة المنتجات وتسليم السلة لبدء الخروج. النتيجة أن المتاح هو مرجع برمجي قابل للتخصيص، لا متجر مكتملًا ولا بوابة دفع يديرها Claude.
ما الذي أصبح متاحًا للفرق؟
يتضمن المستودع تنفيذين عاملين يمكن تكييفهما بدل البدء من وصف معماري فارغ. ويمكن بناء الوكيل باستخدام Messages API أو Claude Agent SDK أو Claude Managed Agents، مع بقاء الخيار الأخير في المرحلة التجريبية، ثم تشغيل الكود حيث تستخدم الشركة Claude API أو Amazon Bedrock أو Microsoft Foundry أو Google Cloud Vertex AI.
وكيل التسوق مخصص للواجهة التي يتعامل معها العميل. وتشمل نقاط ربطه الكتالوج والسلة والخروج وتفضيلات العميل وسجل الطلبات؛ ويمكنه معالجة طلبات تشمل عدة منتجات، وعرض المقارنات، وتذكر التفضيلات، والإجابة عن حالة الطلب وسياسة الإرجاع.
أما وكيل التاجر فيعمل على جانب التشغيل: تحليل المبيعات، ومراقبة المخزون، واقتراح الأسعار والعروض، وصياغة الحملات. الاقتراح التشغيلي لا يتحول تلقائيًا إلى تغيير منشور؛ فالنمط المعروض يبقي الموافقة النهائية لدى شخص قبل دخول التغيير حيز التنفيذ.
تغطي التطبيقات المرجعية التجزئة والسفر والاتصالات والتذاكر، ويصاحبها ملحق لـClaude Code لتوليد الهيكل الأولي وتخصيص التدفقات. لكن صفة «مرجعي» تحدد حدود المنتج: الفريق ينسخ الكود ويربطه بأنظمته ويصبح مسؤولًا عن تشغيل النسخة الناتجة، بدل الحصول على خدمة تجارة مُدارة جاهزة.
خريطة التكامل تنتهي عند أنظمة التاجر
تبدأ رحلة الشراء من بيانات التاجر. يستدعي الوكيل موصل الكتالوج للحصول على المنتجات والسمات والسعر والتوفر، ثم يستخدم أدوات السلة لإضافة العناصر أو حذفها أو تغيير كمياتها، قبل تسليم السلة إلى الخروج. لا يمنح المخطط النموذج حق إنشاء منتج أو سعر من ذاكرته، لكنه لا يستطيع أيضًا تصحيح بيانات قديمة أو ناقصة تعيدها أنظمة المتجر.
توضح مراجعة CommerceClarity للمستودع أن واجهة StorefrontBackend هي الطبقة التي يتعين على كل شركة وصلها بأنظمة المنتجات والسلة والطلبات والسياسات الخاصة بها. وهذا يعني أن الكتالوج الحقيقي، وقواعد السوق والقناة، ومنطق الحجز، وحالة الطلب ليست مكونات يوفرها المخطط للشركة.
عند اكتمال السلة، ينتقل التنفيذ إلى مسار الخروج الذي يملكه التاجر أو إلى مزود دفع يختاره. ومن ثم تبقى المصادقة على العميل، والتفويض المالي، وتسجيل نجاح العملية أو فشلها، ومعالجة الاستثناءات والتسوية خارج مسؤولية وكيل Claude المرجعي.
يستمر الفصل نفسه بعد الشراء. يستطيع الوكيل قراءة حالة الطلب أو شرح سياسة الإرجاع إذا وفرت الواجهة تلك البيانات، لكن شرح السياسة لا يمنحه تلقائيًا سلطة إلغاء طلب أو تحويل مبلغ. أي صلاحية للتعديل أو الاسترداد تحتاج إلى أداة خادمية محددة الحدود، وإلى قرار صريح بشأن الحالات التي تتوقف عندها العملية لتنتقل إلى موظف.
الضوابط لا تصلح سعرًا أو مخزونًا غير دقيق
يتضمن الحل أنماطًا لتقييد الأسعار والمنتجات بما يرد من بيانات الكتالوج، ولضبط سلطة السلة والإجراءات الحساسة والتصعيد إلى إنسان. فائدتها أنها تمنع الوكيل من تجاوز عقد الأداة المسموح به؛ لكنها لا تجعل البيانات المدخلة صحيحة من تلقاء نفسها.
إذا أعاد موصل الكتالوج سعرًا قديمًا، فقد يلتزم الوكيل بهذا السعر ويظل الناتج خاطئًا لحظة الشراء. وينطبق ذلك على المخزون أيضًا: التوفر قد يختلف بحسب الفرع أو مخزن التنفيذ أو القناة، وقد يتغير بين الاقتراح وتسليم السلة، خصوصًا في السفر والتذاكر والاتصالات حيث تكون مدة صلاحية العرض أو الحجز جزءًا من المعاملة.
لذلك يجب تنفيذ حدود السلطة في الخادم لا في صياغة التعليمات وحدها. يشمل ذلك المنتجات التي يمكن إضافتها، وإمكان تطبيق قسيمة، والحدود المسموح بها لتعديل الطلب أو الاسترداد، والبيانات التي ترافق التصعيد البشري، مثل السلة ورقم الطلب وسبب توقف الإجراء.
ما الذي يحتاجه النشر في سوق عربي؟
لا تتضمن الصفحات المفتوحة وعدًا بدعم جاهز لسوق عربي محدد، ولذلك لا يصح استنتاج تغطية عملة أو ضريبة أو سياسة استرجاع محلية من وجود مثال لقطاع التجارة. الملاءمة المحلية تتحدد في العقود التي يبنيها التاجر حول الوكيل وفي البيانات التي تعيدها أنظمته.
قبل النشر، تحتاج خريطة التكامل إلى تغطية أربع طبقات مترابطة:
- الكتالوج واللغة: سمات عربية منظمة وقابلة للمقارنة، مرتبطة بمعرف المنتج والنسخة الصحيحة لكل سوق وقناة، لا معلومات مهمة مدفونة في وصف حر فقط.
- السعر والضريبة: العملة الصحيحة، وقاعدة التقريب، والتمييز بين السعر الأساسي والسعر الشامل للضريبة، وعدم عرض إجمالي نهائي قبل معرفة بلد التسليم والرسوم اللازمة.
- المخزون: توفر مرتبط بموقع التنفيذ، ومدة واضحة لصلاحية الحجز، وإعادة فحص الكمية والسعر عند تسليم السلة إلى الخروج.
- الطلب والاسترداد: حالات الطلب المحلية، ومهل الإلغاء والإرجاع، وحدود المبلغ والصلاحية، ومسار بشري للحالات المتنازع عليها.
هذه الطبقات ليست وظائف إضافية داخل Claude؛ إنها مدخلات وقيود تظل مملوكة للتاجر. المخطط يقلل العمل المطلوب لبناء حلقة الوكيل وواجهات أدواته، لكنه لا ينقل مسؤولية صحة العرض أو قانونية المعاملة أو تنفيذ المال إلى النموذج.
الوضع بعد الإطلاق
المتاح منذ 2 سبتمبر 2026 هو مستودع مفتوح قابل للنسخ، وتطبيقان مرجعيان، وأمثلة قطاعية، وملحق يساعد على تهيئة وكيل مخصص. كما تتعدد طرق البناء والاستضافة، لكن Claude Managed Agents ما زالت تجريبية وليست مساوية لمسار إنتاج مستقر مثبت لجميع المتاجر.
أما الجزء الذي لم يتحول إلى حل جاهز فهو البنية التجارية الخاصة بكل شركة: الكتالوج الحي، والأسعار والضرائب والعملات، والمخزون اللحظي، والدفع، وسياسات الطلب والاسترداد، والمراقبة التشغيلية. لذلك يفتح Claude مخطط البناء فعلًا، لكن صلاحية استخدامه في متاجر المنطقة ستعتمد على الموصلات والبيانات وحدود الصلاحيات التي تضيفها الفرق، وعلى ما ستوثقه Anthropic لاحقًا بشأن الدعم والتوفر بعد الإطلاق.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.