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

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

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

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

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

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

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

أنتظر أن أرى أول وكيل يدفع لوكيل آخر من دون أن يضغط أحدهم على زر الموافقة.
#KiteBBW $KITE