مدفوعات وكلاء الذكاء الاصطناعي على Android: المحافظ والحدود والنية القابلة للتحقق

لماذا أصبحت مدفوعات الوكلاء مسألة تفويض ومساءلة؟

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

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

أما إعلان Google عن AP2 v0.2 الصادر في 28 أبريل 2026 فيوسع النقاش إلى معاملات Human Not Present، أي الحالات التي لا يكون فيها المستخدم حاضرًا في لحظة الدفع. تعتمد الفكرة على تعليمات فوّضها المستخدم مسبقًا، لا على صلاحية مفتوحة يتخذ بها الوكيل أي قرار شرائي.

يقدم AP2 مفهوم Verifiable Intent، أو النية القابلة للتحقق، بوصفه سجلًا مقاومًا للعبث يثبت أن المستخدم أجاز للوكيل إجراءً محددًا. قيمة هذا السجل تظهر عند سؤال التاجر أو المحفظة أو المستخدم لاحقًا: ما التعليمات الأصلية؟ هل كان المبلغ ضمن الحد؟ وهل كانت السلعة والتاجر والوقت متوافقة مع التفويض؟

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

الفرق بين المحفظة الرقمية ومساعد التسوق ووكيل الدفع

تختلط أربعة أدوار عندما نستخدم عبارة «محفظة وكيل ذكاء اصطناعي». أولها المحفظة الرقمية التقليدية التي تحفظ وسيلة دفع أو رمزًا مرتبطًا بها وتوفر طريقة آمنة لاستخدامها. لا تختار المحفظة عادةً ما ينبغي شراؤه؛ فهي تنفذ الدفع الذي وصل إليها ضمن قواعدها ومصادقتها.

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

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

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

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

كيف تعمل حدود الإنفاق والدفع بحضور المستخدم أو بدونه؟

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

في نموذج Human Not Present، يضع المستخدم تعليمات قبل غيابه عن لحظة الشراء. مثال ذلك: «اشتر مرشح المياه نفسه من التاجر المعتمد إذا انخفض المخزون، على ألا يتجاوز الإجمالي 40 دولارًا، وينتهي التفويض بعد شهر». يستطيع الوكيل التصرف فقط إذا طابقت السلعة والتاجر والمبلغ والوقت الشروط المسجلة.

ينبغي أن يحتوي التفويض السابق على عناصر عملية، منها:

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

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

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

يوفر هذا النموذج جوابًا أدق عن سؤال «هل يستطيع الوكيل الدفع دون وجود المستخدم؟». يمكن ذلك عندما تدعم المنظومة معاملات Human Not Present ويكون التفويض السابق محددًا وقابلًا للتحقق وساريًا، مع بقاء الحدود والاستثناءات والإلغاء جزءًا من العملية.

سلسلة المعاملة على Android من النية إلى الإيصال

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

بعد ذلك تأتي بيانات التاجر. يحتاج الوكيل إلى منتج معرف بوضوح، وسعر حالي، وتوفر، ورسوم شحن أو خدمة، وسياسة إلغاء أو إرجاع، وطبيعة الدفع إن كان مرة واحدة أو اشتراكًا. يهدف Universal Commerce Protocol الذي عرضته Google في يناير 2026 إلى توحيد تفاعل التجارة عبر APIs وA2A وMCP، مع توافقه مع AP2. هذه البنية تساعد على نقل بيانات منظمة، لكن توفرها يعتمد على تبني التجار والمنصات.

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

تقدم المحفظة وسيلة الدفع من دون كشف رقم البطاقة الأساسي للتاجر عند استخدام الترميز المدعوم. يشرح شرح Google لرموز الجهاز في Google Wallet أن رمز الجهاز يحل محل رقم البطاقة الأساسي في المعاملة. ويضيف Android تحقق الجهاز لحماية استخدام المحفظة.

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

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

كيف يتعامل FoneClaw مع مسار يصل إلى الدفع؟

في FoneClaw، يبدأ المسار بنموذج مهيأ يفهم ما يريده المستخدم ويستخرج المنتج والميزانية والتاجر والتوقيت ويقترح الخطوات. بعد التخطيط، يتولى FoneClaw إجراءات Android التي يدعمها، مع إبقاء حالة الهاتف والوجهة والنتائج مرئية للمستخدم.

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

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

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

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

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

قائمة تقييم للمستخدمين ومطوري مدفوعات الوكلاء

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

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

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

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

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