من الأسئلة التي غالبًا ما تُغفل بشأن وكلاء الذكاء الاصطناعي: من يدفع ثمن كل قراراتهم الصغيرة؟
قد يحتاج الوكيل إلى معلومة، أو استدعاء لواجهة برمجة التطبيقات (API)، أو بضع ثوانٍ من القدرة الحاسوبية لإنجاز مهمة. وعندما يتكرر ذلك عبر مئات الخطوات، تبدأ الاشتراكات أو المدفوعات اليدوية في الظهور كخيار غير عملي. فأحيانًا لا تكون وحدة القيمة خطة شهرية، بل طلبًا واحدًا مفيدًا.
لهذا لفت انتباهي تصميم المدفوعات لدى Kite. تصف ورقتها التقنية مدفوعات قائمة على العملات المستقرة وقنوات الحالة: إذ يمكن تخصيص الأموال على السلسلة، بينما تُجرى التحديثات الموقّعة خارج السلسلة قبل التسوية النهائية. ومن حيث المبدأ، قد يجعل ذلك المدفوعات الصغيرة المتكررة أكثر عملية، من دون تسوية كل تفاعل على السلسلة بشكل منفصل.
الفكرة الأوسع لا تقتصر على تسريع المدفوعات. إذ يمكن لواجهة برمجة تطبيقات أو مجموعة بيانات أو خدمة حوسبة أن تتقاضى من الوكيل مقابل الاستخدام الفعلي، بينما يدفع الوكيل وفقًا للقواعد التي يحددها مالكه. وتذكر Kite أيضًا توافقها مع x402، وهو بروتوكول صُمم لتوحيد طلبات الدفع بين الوكلاء والخدمات.
أرى تحولًا يلوح في الأفق: قد تحتاج الخدمات إلى التعامل مع الوكلاء لا باعتبارهم أدوات فحسب، بل كعملاء قادرين على طلب الخدمات والدفع مقابلها.
لكن هذا لا ينجح إلا إذا كانت آليات التفويض والموثوقية وتسوية النزاعات قوية. فالمدفوعات السهلة مفيدة، أما الأخطاء التي يسهل ارتكابها فليست كذلك.
أي نموذج هو الأنسب للخدمات التي يديرها الوكلاء: الاشتراكات، أم الأرصدة المدفوعة مسبقًا، أم الدفع مقابل كل طلب؟ وما الحد الأقصى للإنفاق الذي ستحدده قبل السماح لوكيل بالدفع تلقائيًا؟
#KiteBBW $KITE @KITE AI
قد يحتاج الوكيل إلى معلومة، أو استدعاء لواجهة برمجة التطبيقات (API)، أو بضع ثوانٍ من القدرة الحاسوبية لإنجاز مهمة. وعندما يتكرر ذلك عبر مئات الخطوات، تبدأ الاشتراكات أو المدفوعات اليدوية في الظهور كخيار غير عملي. فأحيانًا لا تكون وحدة القيمة خطة شهرية، بل طلبًا واحدًا مفيدًا.
لهذا لفت انتباهي تصميم المدفوعات لدى Kite. تصف ورقتها التقنية مدفوعات قائمة على العملات المستقرة وقنوات الحالة: إذ يمكن تخصيص الأموال على السلسلة، بينما تُجرى التحديثات الموقّعة خارج السلسلة قبل التسوية النهائية. ومن حيث المبدأ، قد يجعل ذلك المدفوعات الصغيرة المتكررة أكثر عملية، من دون تسوية كل تفاعل على السلسلة بشكل منفصل.
الفكرة الأوسع لا تقتصر على تسريع المدفوعات. إذ يمكن لواجهة برمجة تطبيقات أو مجموعة بيانات أو خدمة حوسبة أن تتقاضى من الوكيل مقابل الاستخدام الفعلي، بينما يدفع الوكيل وفقًا للقواعد التي يحددها مالكه. وتذكر Kite أيضًا توافقها مع x402، وهو بروتوكول صُمم لتوحيد طلبات الدفع بين الوكلاء والخدمات.
أرى تحولًا يلوح في الأفق: قد تحتاج الخدمات إلى التعامل مع الوكلاء لا باعتبارهم أدوات فحسب، بل كعملاء قادرين على طلب الخدمات والدفع مقابلها.
لكن هذا لا ينجح إلا إذا كانت آليات التفويض والموثوقية وتسوية النزاعات قوية. فالمدفوعات السهلة مفيدة، أما الأخطاء التي يسهل ارتكابها فليست كذلك.
أي نموذج هو الأنسب للخدمات التي يديرها الوكلاء: الاشتراكات، أم الأرصدة المدفوعة مسبقًا، أم الدفع مقابل كل طلب؟ وما الحد الأقصى للإنفاق الذي ستحدده قبل السماح لوكيل بالدفع تلقائيًا؟
#KiteBBW $KITE @KITE AI