عندما تتعلم الذكاء الاصطناعي دفع الأموال بنفسه، بدأت الشركات الكبرى في التنافس سراً

المصدر: Tiger Research

المؤلف: Ekko، Ryan Yoon

العنوان الأصلي: بنية دفع الوكيل الذكي: اتجاه العملات المشفرة والتكنولوجيا الكبرى

الترجمة والتنظيم: BitpushNews

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

الرؤى الأساسية

• أصبح طرف الدفع يتحول من الإنسان إلى وكيل الذكاء الاصطناعي، مما يجعل بنية الدفع الأساسية شرطًا رئيسيًا لتحقيق الاستقلالية الحقيقية.
• تتعاون عمالقة التكنولوجيا (مثل Google AP2 وOpenAI المعينين للدفع) على تصميم أنظمة دفع آلية تعتمد على الموافقة، مبنية على البنية التحتية الحالية للمنصات.
• تستخدم العملات المشفرة (عبر ERC-8004 وx402) هوية قائمة على NFTs وعقود ذكية لتحقيق نموذج دفع بدون وسيط.
• تركز عمالقة التكنولوجيا على الراحة وحماية المستهلكين، بينما تؤكد العملات المشفرة على سيادة المستخدم وقدرة الوكيل على التنفيذ على نطاق أوسع.
• السؤال الرئيسي في المستقبل هو: هل ستتحكم المنصات في الدفع، أم ستنفذه بروتوكولات مفتوحة.

1. لم يعد الدفع حكرًا على البشر

المصدر: macstories (بتقديم Federico Viticci)

مؤخرًا، أثار “OpenClaw” اهتمامًا واسعًا. على عكس أنظمة الذكاء الاصطناعي الرئيسية مثل ChatGPT أو Gemini التي تركز على استرجاع وتنظيم المعلومات، فإن OpenClaw يتيح لوكيل الذكاء الاصطناعي تنفيذ المهام مباشرة على جهاز الكمبيوتر أو الخادم المحلي للمستخدم.

عبر منصات المراسلة الفورية مثل WhatsApp وTelegram وSlack، يمكن للمستخدمين إصدار أوامر، ويقوم الوكيل بتنفيذ مهام تشمل إدارة البريد الإلكتروني، تنسيق التقويم، وتصفح الويب بشكل مستقل.

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

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

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

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

2. عمالقة التكنولوجيا: بناء على البنية التحتية الحالية، دفع الوكيل

في يناير 2025، أطلقت Google بروتوكول الدفع الوكيل 2.0 (AP2)، موسعة بنيتها التحتية لدفع الوكيل الذكي. على الرغم من أن OpenAI وAmazon وضعا خططًا مماثلة، إلا أن Google هي الشركة الكبرى الوحيدة التي تمتلك إطارًا منظمًا ومُطبقًا بشكل هيكلي حتى الآن.

يقسم AP2 عملية المعاملة إلى ثلاثة مستويات تفويض (Mandate Layers). يتيح هذا الهيكل مراقبة وتدقيق مستقل لكل مرحلة:

1. تفويض النية (Intent Mandate): تسجيل ما يرغب المستخدم في القيام به.
2. تفويض السلة (Cart Mandate): تحديد كيفية تنفيذ الشراء وفقًا للقواعد المسبقة.
3. تفويض الدفع (Payment Mandate): تنفيذ التحويل المالي الفعلي.

مثال على السيناريو: كيف يعمل Google AP2

افترض أن Ekko يطلب من وكيل Google Shopping الذكي “البحث وشراء سترة شتوية بأقل من 200 دولار”.

• تفويض النية: يوجه Ekko الوكيل لشراء “سترة شتوية، بميزانية قصوى 200 دولار”. يُسجل هذا الأمر كعقد رقمي على السلسلة، ويُسمى تفويض النية.
• تفويض السلة: يتبع الوكيل النية الموصوفة، ويبحث في المتاجر الشريكة عن منتجات تتوافق مع “سترة شتوية” و"ميزانية قصوى 200 دولار"، ويضيف المنتجات المطابقة إلى السلة.

“المنتج المختار: سترة شتوية”، “التحقق من السعر: 199 دولار (يتوافق مع الميزانية ✓)”

“تمت الإضافة إلى السلة”، “عنوان الشحن مؤكد”.

• تفويض الدفع: يوافق Ekko على اختيار الوكيل للمنتج، ويضغط على زر الموافقة على الدفع. يتم دفع 199 دولار عبر Google Pay. أو يمكن للوكيل أن يكمل الدفع تلقائيًا ضمن المعايير المحددة مسبقًا.

خلال العملية، لا يحتاج المستخدم إلى إدخال معلومات إضافية. يعتمد نظام Google AP2 على Google Pay، ويستخدم تفاصيل البطاقة وعنوان الشحن المسجل مسبقًا. نظرًا لاعتماده على بيانات الاعتماد الحالية للمستخدم، يقلل من عوائق الإدخال ويُسهل الانتشار.

المصدر: Google

ومع ذلك، تدعم Google حاليًا فقط الشركات ضمن شبكة شركائها لتنفيذ عمليات دفع تعتمد على الوكيل، مما يحد من نطاق الاستخدام ليقتصر على نظام بيئي محكوم، ويقيد التفاعل المفتوح والوصول الواسع.

3. العملات المشفرة: الحفظ الذاتي والتبادل المفتوح

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

هناك معياران رئيسيان يهدفان لتحقيق ذلك: ERC-8004 الخاص بإيثريوم وx402 الخاص بـ Coinbase.

الدمج بين الهوية والدفع

أولاً، نركز على طبقة الهوية. تمامًا كما يحتاج البشر إلى هوية للوصول إلى الخدمات الرقمية، يجب أن يكون الوكيل الذكي الذي يعمل على شبكة البلوكشين معرفًا بشكل يمكن التحقق منه. يلعب ERC-8004 هذا الدور.

يصدر على شكل NFT، لكنه ليس كقطعة فنية أو مجموعة رقمية، بل كشهادة هوية منظمة تحتوي على بيانات هوية مُهيكلة. يتضمن كل رمز مميز ثلاثة مكونات:

1. الهوية (Identity)
2. السمعة (Reputation)
3. التحقق (Validation)

تُشكل هذه العناصر معًا شهادة هوية قابلة للتحقق على السلسلة. في التجارة الإلكترونية، يراجع المشاركون تقييمات وسجلات المعاملات قبل إتمام الصفقة، وينطبق نفس المنطق على الوكيل الذكي. يوفر ERC-8004 شهادة يمكن التحقق منها، تسمح لوكلاء آخرين بتقييم مدى ملاءمة الصفقة استنادًا إلى البيانات الشفافة.

لكن، وجود الهوية وحده لا يكفي لنقل القيمة، بل يلزم وجود آلية دفع. هنا يأتي دور x402.

إذا كانت ERC-8004 هوية رقمية، فإن x402 هو مسار الدفع. طورته Coinbase، وهو معيار دفع أصلي للعملات المشفرة للوكيل الذكي. يتيح للوكيل إجراء معاملات مستقلة باستخدام العملات المستقرة.

وظيفته الأساسية هي تنفيذ العقود الذكية بشكل تلقائي. مثل “التحقق من استيفاء المعايير المسبقة ثم التحويل تلقائيًا”، حيث تُدمج المنطق الشرطي مباشرة في الكود. بمجرد استيفاء الشروط، يتم التسوية دون تدخل بشري.

عند دمج ERC-8004 للهوية وx402 للدفع، يمكن للوكيل الذكي التحقق من طرفي المعاملة وتنفيذها دون الاعتماد على منصة مركزية. يتم التعامل مع الثقة والتسوية على مستوى البروتوكول، وليس عبر منصة تحكم.

مثال على السيناريو: التبادل التجاري بين وكلاء يعتمد على ERC-8004 وx402

افترض بيئة مستقبلية لوكلاء الذكاء الاصطناعي: يوجه Ekko وكيله (الوكيل A) لشراء لابتوب مستعمل بميزانية قصوى 800 دولار. هناك وكيل سوق خاص به (الوكيل B) يتواصل مباشرة مع وكيل Ekko لتنفيذ الصفقة.

1. التحقق المتبادل:

قبل إتمام الصفقة، يتحقق الوكيلان من شهاداتهما ويؤكدان أن المنتج يطابق المتطلبات.

• التحقق من الهوية: عبر NFT ERC-8004
• وكيل Ekko: تقييم السمعة 72، وتأكيد الرصيد 800 دولار
• وكيل البائع: تقييم السمعة 70، وتأكيد توفر اللابتوب المطلوب
• النتيجة: الموافقة على إجراء المعاملة من قبل كلا الوكيلين.

• إدارة العقود الذكية:

بعد التحقق، تبدأ المعاملة. يتواصل الوكيلان عبر بروتوكول x402 لنقل وتأكيد الأموال.

• الحجز: يتم نقل 800 دولار من محفظة وكيل Ekko إلى العقد الذكي.
• قفل الشرط: تظل الأموال مقفلة حتى يتم تأكيد الاستلام.
• الإفراج: بعد تأكيد التسليم، يتم تحويل 800 دولار تلقائيًا إلى البائع.

• التسوية وتحديث السمعة (تحديث NFT الخاص بـ x402 وERC-8004):

بعد التسوية، يتم تحديث سجلات السمعة لكل من الوكيلين.

• وكيل Ekko: السمعة 72 → 80 (+5 للتسليم السريع، +3 لمطابقة الوصف)
• وكيل البائع: السمعة 70 → 78 (+5 للتسليم السريع، +3 لمطابقة الوصف)
• تُكتب التقييمات المحدثة في NFT ERC-8004 الخاص بكل وكيل.

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

4. عمالقة التكنولوجيا مقابل العملات المشفرة: اختلاف مجالات تشغيل وكيل الذكاء الاصطناعي

السيطرة مقابل الانفتاح

يمثل بروتوكول Google AP2 نموذجًا مقيدًا مصممًا للشركاء المعتمدين.

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

إذا ارتبط الوكيل بشريك غير موثوق وحدث خطأ في المعاملة، قد تقع المسؤولية في النهاية على مزود بنية الدفع. ولتقليل احتمالية حدوث خطأ حتى بنسبة 0.01%، تميل Google إلى تقليل نطاق نظامها البيئي. هذا النظام المقيد يعزز الاستقرار والرقابة، لكنه قد يحد من قدرة الوكيل على العمل بشكل مستقل في سوق أوسع وتحسين الخيارات المتعددة.

على النقيض، يعكس ERC-8004 وx402 بنية أكثر انفتاحًا. يهدف النموذج المشفر إلى تحقيق عدم الترخيص والتشغيل البيني، وليس الاعتماد على منصة واحدة.

الكفاءة والحالات الاستخدامية

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

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

علاوة على ذلك، مع تزايد المحتوى الرقمي المدفوع، قد يحتاج الوكيل إلى تنفيذ مدفوعات صغيرة ومتكررة. قد توفر المعايير المفتوحة في التشفير ميزة هيكلية، مثل شراء 1000 صورة منشأة بواسطة المبدعين بسعر 0.01 دولار لكل واحدة، أو دفع 1 دولار للوصول إلى مقال بحثي. بالنسبة للمدفوعات الصغيرة والقابلة للبرمجة، قد توفر البنية التحتية الأصلية للعملات المشفرة كفاءة أعلى.

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

الخلاصة

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

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