AWS تضيف مدفوعات الوكلاء إلى AgentCore: دعم x402 في أيام بدلاً من أشهر

أضافت Amazon Web Services إلى Bedrock AgentCore طبقة مدفوعات مُدارة لوكلاء الذكاء الاصطناعي. يتيح Amazon Bedrock AgentCore payments للوكيل أن يدفع بنفسه مقابل الخدمات لحظة استدعائها، بينما تفرض البنية التحتية حدود الإنفاق. وتستعرض AWS مثالًا على ذلك هو الجمع بين Incarna وBlockRun. فوكلاء Incarna يشترون من BlockRun خدمة تشغيل النماذج عن كل طلب على حدة عبر بروتوكول x402. وبحسب وصف AWS، تقلّصت مدة ربط دعم x402 من عدة أشهر إلى عدة أيام.

لماذا يحتاج الوكيل إلى محفظة

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

يعالج بروتوكول x402 المشكلة عبر رمز HTTP 402 Payment Required المنسي منذ زمن طويل. يردّ الخادم على الطلب بمطالبة بالدفع مع شروطه. ويدفع العميل، عادةً بالعملات المستقرة (stablecoins)، ثم يعيد الطلب مرفقًا بإثبات الدفع. ولا تسجيل ولا اشتراك في هذه السلسلة.

ماذا تفعل AgentCore payments

لا يجيب البروتوكول نفسه عن سؤالين: من يضمن ألا ينفق الوكيل أكثر من اللازم؟ ومن سيتولى لأشهر صيانة البنية المحيطة بالدفع؟ وتعالج AWS السؤالين على مستوى المنصة. تُحدَّد حدود الإنفاق من الخارج وتتحقق منها البنية التحتية. فإذا أخطأ النموذج أو دخل في حلقة تكرارية أو تلقى تعليمات ضارة في الموجّه (prompt)، فلن يتغير سقف الإنفاق بسبب ذلك. وهذا فارق جوهري في بيئة الإنتاج: فالقيد المكتوب في موجّه النظام يظل مجرد طلب، أما القيد المفروض من جانب المنصة فيعمل كقاعدة.

ويتعلق الشق الثاني من الوعد بجهد العمل. فدعم x402 يتعين تنفيذه ذاتيًا: تحليل ردود 402، وتوقيع المدفوعات، وتخزين المفاتيح، واحتساب النفقات. وتؤكد AWS أن هذا العمل في حالة Incarna تقلّص من أشهر إلى أيام.

حالة Incarna وBlockRun

تؤدي BlockRun دور البائع: فهي تقدم استدلال النماذج وتتقاضى رسومًا عن كل طلب على حدة. وتؤدي Incarna دور المشتري: إذ يدفع وكلاؤها مقابل الاستدعاءات التي يحتاجونها أثناء العمل. ولا توجد في هذا النموذج حزم رموز (tokens) مدفوعة مسبقًا ولا مفتاح مشترك بميزانية غير محددة. فالإنفاق مرتبط باستدعاء بعينه، ولذلك يسهل نسبه إلى مهمة أو وكيل أو عميل.

ما هو معروف من مادة AWS:

• نموذج الدفع: pay-per-inference، أي طلب واحد مقابل دفعة واحدة؛
• البروتوكول: x402، ويُطلب الدفع في ردّ الخادم؛
• ضبط الإنفاق: تلتزم بنية AgentCore التحتية بفرض الحدود؛
• مدة دمج x402: أيام بدلاً من أشهر، بحسب تقدير AWS؛
• الأطراف: Incarna مشتريًا، وBlockRun مزوّدًا للاستدلال.

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

ما الذي ينبغي التحقق منه قبل التطبيق

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

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

بالنسبة إلى AWS، هذه خطوة أخرى نحو أن تصبح AgentCore بيئة تشغيل متكاملة للوكلاء: تشمل الهوية وقابلية المراقبة، وأصبحت تشمل الآن المال. أما مدى تحوّل السوق على نطاق واسع إلى الدفع عند الطلب، فسيحدده عدد المزوّدين المستعدين لقبول x402.