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