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

المؤلف: Yokiiiya

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

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

في إحدى جلسات النقاش التي شاركت فيها، طرح أحدهم مباشرة سؤالًا: هل Web3 يتطفل على الذكاء الاصطناعي؟ أعتقد أن الأمر ليس كذلك. بالطبع، هناك مشاريع تستفيد من التريند، لكن إذا فهمنا AI × Web3 فقط كنوع من سرد القصص أو تركيب القصص، فقد نفوت تغيّرًا أعمق في الأساس: فالذكاء الاصطناعي مسؤول عن الفهم، واتخاذ القرارات، والتنفيذ، وWeb3 يوفر الأصول، والحسابات، والتسوية، وبيئة التنفيذ القابلة للتحقق. هذان المفهومان ليسا مجرد تراكب بسيط، بل يعيدان تقسيم الأدوار.

في خطاب رئيس المالية في هونغ كونغ، تشن مايوبو، خلال مهرجان Web3 2026، أشار إلى أن وكلاء الذكاء الاصطناعي في المستقبل سيقومون بتحليل المعلومات بسرعة الآلة واتخاذ الإجراءات، مع الاستفادة الكاملة من بنية blockchain التحتية في الخلفية، مما يعزز كفاءة المعاملات ويعيد تشكيل مشاهدات المالية والتجارة وإدارة الثروات وسلاسل التوريد واللوجستيات. عندما يبدأ الذكاء الاصطناعي في العمل، لن يكون السؤال فقط عن “الذكاء” نفسه، بل عن كيفية تفويض هذه الأفعال، وتسويتها، وتوثيقها، ومحاسبتها.

واحدة من المواضيع التي تزداد أهميتها بشكل متزايد هي Agentic Payment. لكن في البداية، كان لدي سؤال بسيط: لماذا عندما يتحدث الناس عن Agentic Payment أو Agentic Commerce، يبدو وكأنهم يفترضون أنه مرتبط دائمًا بـ Crypto، أو العملات المستقرة، أو blockchain؟

هل لا يمكن لوكيل الذكاء الاصطناعي أن يستخدم بطاقة بنكية؟ أو بطاقة ائتمان؟ أو Apple Pay، أو Visa، أو Mastercard، أو Stripe، أو PayPal؟

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

إذن، المشكلة ليست “هل يمكن استخدام البطاقة البنكية”. بالطبع يمكن. المشكلة الحقيقية هي: هل البطاقة البنكية أو الائتمان مناسبة لحل جزء معين من Agentic Payment، وأي جزء لا يمكنها حله؟ هل سيستخدم وكيل الذكاء الاصطناعي البطاقة البنكية أم لا؟ ولماذا، عند تطور Agentic Payment إلى مرحلة معينة، يكاد يكون لا مفر من الاعتماد على العملات المستقرة و blockchain؟

أولاً، البطاقة البنكية تحل مشكلة التسوية النهائية، وليست حلًا لاقتصاد الوكيل

إذا كان Agentic Payment مجرد مساعدة لوكيل الذكاء الاصطناعي لإنهاء خطوة الدفع الأخيرة، مثل شراء تذكرة، أو حجز فندق، أو تجديد اشتراك SaaS، فإن استخدام البطاقات البنكية، أو الائتمان، أو البطاقات الافتراضية، أو Apple Pay، أو Stripe، أو PayPal، لا يواجه عائقًا جوهريًا. يمكن استخدام البطاقات البنكية، أو الائتمان، بكل سهولة.

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

لذا، فإن الشركات التقليدية مثل Visa، Mastercard، وStripe لن تختفي. بل، ستظل تمثل بوابات مهمة في بداية ظهور التجارة الوكيلة.

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

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

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

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

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

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

هذه الفجوة بين Agentic Payment ونموذج API التقليدي واضحة جدًا. اليوم، طرق الدفع لمعظم API لا تزال مصممة لتلبية احتياجات “شراء البرامج من قبل الشركات”، وليس “شراء الموارد عند الطلب بواسطة الآلات”.

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

وهذا هو الحد الذي تصل إليه أنظمة البطاقات البنكية.

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

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

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

إذن، المشكلة الأساسية في Agentic Payment ليست “من أين يُخصم المال”، بل “ما الذي يمنح الوكيل حق إنفاق هذا المال؟”

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

Visa أيضًا تتجه في هذا الاتجاه. بروتوكولها للذكاء التجاري والثقة في الوكيل (Trusted Agent Protocol) يهدف إلى تمكين التعرف على الوكيل الذكي في شبكة التجار الحالية، ومنحه الثقة، والسماح له بالتمثيل نيابة عن المستهلكين أو الشركات. وصف مطورين Visa لبروتوكول الوكيل الموثوق واضح جدًا: أن الوكلاء الذكيين سيساعدون المستخدمين على تصفح مواقع التجار، واكتشاف المنتجات، ومقارنة الأسعار، واتخاذ القرارات، قبل أن تبدأ رحلة الشراء؛ حيث أن هذه الزيارات التلقائية كانت غالبًا تُعتبر بوت وتُحظر من قبل خدمات الحماية من البوتات.

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

إذن، ليست مشكلة أن تكون أنظمة البطاقات غير قادرة، بل أن حل Agentic Commerce يقتضي بروتوكول دفع أعمق وأساس أكثر مرونة.

وهذا يقودنا إلى مستوى آخر: إذا كانت المعاملة ليست مع تاجر تقليدي، بل مع API، أو نموذج، أو واجهة بيانات، أو حتى وكيل آخر، فكيف يمكن للآلات أن تبدأ وتُكمل عملية دفع واحدة؟

وهذا هو السبب في أن بروتوكولات مثل x402، وL402، وT402 بدأت تُناقش.

ثانيًا، ما يحتاجه الوكيل حقًا هو بروتوكول دفع يمكن قراءته آليًا

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

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

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

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

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

إعادة تفعيل رمز الحالة HTTP 402 “Payment Required” الذي كان موجودًا منذ زمن، لكنه نادر الاستخدام، هو خطوة مهمة. يتيح للطرف المقدم للخدمة أن يخبر العميل مباشرة على مستوى HTTP: أن الوصول لهذا المورد يتطلب دفعًا. يمكن أن يكون العميل إنسانًا أو آلة. بعد الدفع، يتحقق الطرف المقدم من الدفع، ويعيد تقديم API، أو المحتوى، أو الخدمة الرقمية.

المهم هنا ليس “هل أستخدم Coinbase” أو “هل أستخدم USDC”. الأهم هو أن x402 يعيد دمج الدفع في دورة الطلب-الاستجابة على الإنترنت.

السابق كان:

• تسجيل حساب.
• شراء باقة.
• الحصول على API key.
• استدعاء الخدمة.
• التسوية في نهاية الشهر.

أما الآن، فالصورة تتغير إلى:

• طلب المورد.
• استلام 402 Payment Required.
• إتمام الدفع.
• الحصول على المورد.

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

مثلاً، وكيل كتابة قد يشتري استعلام بيانات مرة واحدة لمقالة واحدة.
وكيل أبحاث قد يستدعي خدمة تحليل على السلسلة لمشكلة واحدة.
وكيل سفر قد يستعلم عن أسعار من عدة APIs.
وكيل تطوير قد يشتري نماذج، أو بيئة اختبار، أو مراجعة الكود بشكل كل مرة.
وكيل تحليل حركة المرور قد يشتري بيانات Semrush لموقع واحد، وليس باقة SaaS كاملة.

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

الطريق نفسه يتكرر مع L402، الذي يعتمد على شبكة Lightning، وmacaroons، وطرق دفع صغيرة، ويهدف إلى تسهيل التوثيق والمعاملات على API وموارد الحوسبة.

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

وهذا هو السبب في أن ظهور الوكيل الذكي جعل مسار الدفع الأصلي على الإنترنت يصبح ذا معنى.

حتى في سياق USDT / Tether، بدأ يظهر اتجاه مماثل.
وثائق x402 الخاصة بـ Tether WDK تؤكد أن البروتوكول مهم جدًا للوكيلات، لأنها تحتاج إلى برمجية للدفع للمصادر، وx402 يجعل الدفع جزءًا من طبقة الويب، بحيث يمكن للوكيل أن يكتشف الأسعار، ويوقع على الدفع، ويحصل على الموارد في دورة طلب-رد.
وفي الوقت نفسه، تصف Tether T402 بأنها معيار مفتوح للدفع الأصلي على الإنترنت، يدعم العملات المشفرة، والعملات المستقرة، والرموز، ويهدف إلى التوافق مع Tether WDK.
لكن، من المهم أن نكون حذرين: لا أقول إنه أصبح معيارًا رسميًا من Tether، بل أن هناك استكشافات لبروتوكولات مماثلة حول USDT / Tether.

هذه كلها تشير إلى اتجاه مهم:
Agentic Payment ليست مجرد منتج لشركة واحدة، أو بروتوكول واحد، بل هي بنية تحتية لبروتوكولات جديدة.

• AP2 يجيب على سؤال: ما الذي يمنح الوكيل حق الدفع؟
• x402، L402، T402 يجيبون على سؤال: عندما يطلب الوكيل موردًا رقميًا، كيف يطلق الطرف المقدم للدفع طلب الدفع، وكيف يكمل الوكيل الدفع ويحصل على المورد؟
• العملات المستقرة و blockchain يجيبون على سؤال: ما هو الأصل الذي يتم التسوية به، وأين يتم التحقق، وكيف يمكن أن يكون منخفض التكلفة، وواقعيًا، وقابل للبرمجة، وعابر للمنصات؟

لذا، فإن Agentic Payment وCrypto يُناقشان معًا، ليس لأن Web3 يريد أن يتطفل على الذكاء الاصطناعي، بل لأن Agentic Payment يعيد طرح مشكلة “الطبيعة الأصلية للدفع” التي لم تحلها الإنترنت سابقًا.

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

ولهذا، فإن بروتوكولات مثل x402، وL402، وT402 تستحق الاهتمام. فهي ليست مجرد محاولة لجعل AI يدفع باستخدام العملات المشفرة، بل هي محاولة لتعريف نمط تفاعل جديد:
الآلة تطلب موردًا، وتفهم السعر، وتتحقق من التفويض، وتدفع، وتحصل على الخدمة.

إذا كانت البطاقات البنكية تحل مشكلة التسوية عند الدفع، فإن هذه البروتوكولات تحل مشكلة: كيف تبدأ وتُكمل عملية دفع بين الآلات.
وبمجرد أن نصل إلى هذا المستوى، فإن العملات المستقرة و blockchain لن تكون مجرد أدوات دفع، بل ستصبح لغة التسوية الأساسية وبيئة التنفيذ لــ Agentic Payment.

ثالثًا، لماذا العملات المستقرة؟: الوكيل يحتاج إلى وحدة قياس مستقرة، وليس أصول متقلبة

إذا كان الوكيل يحتاج حقًا إلى بروتوكول دفع يمكن قراءته آليًا وتنفيذه تلقائيًا، فلماذا يتحدث الجميع عن العملات المستقرة أكثر من BTC؟
ولماذا لا يتحدثون عن ETH أو البطاقات البنكية التقليدية؟

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

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

في هذه السيناريوهات، الوكيل ليس يتاجر، وليس يضارب.
هو ينفذ مهمة.
لذا، يحتاج إلى معرفة: كم تكلفة المورد؟
هل ستتجاوز هذه المرة الميزانية؟
هل الدفع ضمن تفويض المستخدم؟
هل يمكن تتبع التكاليف بعد التسليم؟

إذا كانت قيمة الأصول المتداولة يوميًا متقلبة بشكل كبير، فإن إدارة الميزانية تصبح معقدة جدًا.
اليوم، طلب API بقيمة 0.1 دولار قد يتغير إلى 0.12 أو 0.08 بسبب تقلبات السعر، وهذا قد لا يهم السوق، لكنه يسبب تعقيدات للشراء عند الطلب بواسطة الآلات.

لهذا السبب، تظهر العملات المستقرة بشكل طبيعي أكثر من الأصول الرقمية المتقلبة في Agentic Payment.

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

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

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

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

الوكيل يطلب موردًا.
الخدمة ترد بـ 402 Payment Required.
الوكيل يقرر السعر والتفويض.
ويدفع بالعملة المستقرة.
وبعد التحقق، يطلق المورد الموارد.

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

وهذا يختلف تمامًا عن استخدام البطاقات البنكية.
البطاقات البنكية أكثر ملاءمة لسيناريوهات استهلاك الإنسان، حيث يمر المستخدم عبر عملية تسوية كاملة.
أما العملات المستقرة فهي أكثر ملاءمة للتسوية الفورية عند استدعاء الموارد بواسطة الآلات.
بالطبع، هذا لا يعني أن البطاقات ستختفي.
بروتوكول MPP من Stripe وTempo يدعم كلا المسارين:

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

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

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

ما يحتاجه هو نوع من الأصول يمكن الاعتماد عليه، ومتاحة دائمًا، وقابلة للتنفيذ التلقائي، ويمكن التحقق منها.

ولهذا، فإن دعم x402، وTether WDK، واستكشافات T402 حول USDT / Tether، كلها تتجه نحو نفس الهدف:
تحويل المدفوعات باستخدام العملات المستقرة إلى مكونات يمكن للآلات استدعاؤها مباشرة على الويب، بدلاً من أن يدخل الوكيل إلى صفحة دفع مخصصة للبشر.

لكن، هناك تحذير مهم:
العملات المستقرة ليست خالية من المشاكل.

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

الأصح أن نقول:
العملات المستقرة ليست عملات مثالية، لكنها واحدة من أقرب الأصول التي تلبي احتياجات Agentic Payment على الإنترنت.

قيمتها ليست في “السرد اللامركزي”، بل في أنها تلبي عدة شروط:

• سعر مستقر نسبيًا،
• يمكن استدعاؤها برمجياً،
• تنتقل عبر المنصات،
• تُسوى على مدار الساعة،
• يمكن دمجها مع الدفع عبر HTTP-native، والمحافظ، والعقود الذكية، والتسوية على السلسلة.

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

إذا كانت بطاقة الائتمان موجهة للبشر، فإن العملات المستقرة تشبه لغة تسوية مخصصة للاقتصاد الآلي.

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

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

وهذا هو السبب في أن العملات المستقرة لا يمكن تجاهلها في Agentic Payment.
ليس لأنها ستجعل كل المدفوعات عملات مشفرة، بل لأنها، عندما يتحول موضوع المعاملة من “مستهلك بشري” إلى “نظام برمجي”، تجعل “المال” أقرب إلى جزء من بروتوكول الإنترنت.

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

رابعًا، لماذا نحتاج إلى blockchain: ليس من أجل التوثيق على السلسلة، بل لجعل سلوك الوكيل قابلًا للتحقق

حتى لو كان الوكيل يحتاج إلى الدفع بالعملات المستقرة، لماذا يجب أن يكون ذلك عبر blockchain؟
هل لا يمكن أن يكون عبر سجل مركزي؟ أو Stripe، أو Visa، أو بنك، أو منصة تدير الحسابات بنفسها؟

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

لكن، عندما يتعلق الأمر بـ Agentic Payment الحقيقي، فإن الأمر ليس فقط أن الوكيل ينقر زر الدفع على منصة مغلقة، بل أنه قد يعمل عبر منصات، وخدمات، ومحافظ، وبلدان، وحتى مع وكيل آخر لإنجاز مهمة واحدة.
وفي هذه الحالة، تصبح الأسئلة:
لماذا تم الدفع؟
من الذي منح التفويض؟
هل تجاوز الوكيل الصلاحيات؟
هل تم تسليم الخدمة؟
هل يتحمل أحد المسؤولية إذا أخطأ الوكيل أو تم التلاعب به؟

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

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

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

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

لهذا السبب، عند مناقشة Agentic Payment، فإن مراجعة White Paper الخاص بـ Bitcoin ليست من أجل التمجيد،
بل لأنها كانت تحل مشكلة أساسية: كيف يمكن لنقل الأموال الإلكتروني أن يُوثق ويُسجل بدون طرف ثالث موثوق.
الورقة تقول بوضوح: أن الشبكة ستكتب المعاملات في سلسلة من البلوكات، وتثبت صحتها عبر إثبات العمل، بحيث لا يمكن تعديلها إلا بعد إعادة العمل.

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

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

لأنه ليس إنسانًا، ولا يمكنه الاعتماد على “أتذكر أنني كنت أعتقد كذا”.
بل يحتاج إلى سلسلة أدلة يمكن التحقق منها خارجيًا.

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

إذن، المشكلة الأساسية في Agentic Payment ليست “من أين يُخصم المال”، بل “ما الذي يمنح الوكيل حق إنفاق هذا المال؟”

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

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

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

إذن، ليست مشكلة أن أنظمة البطاقات غير قادرة، بل أن حل Agentic Commerce يقتضي بروتوكول دفع أعمق وأساس أكثر مرونة.

وهذا يقودنا إلى مستوى آخر:
إذا كانت المعاملة ليست مع تاجر تقليدي، بل مع API، أو نموذج، أو واجهة بيانات، أو حتى وكيل آخر،
فكيف يمكن للآلات أن تبدأ وتُكمل عملية دفع واحدة؟

وهذا هو السبب في أن بروتوكولات