وكلاء الذكاء الاصطناعي لا يحتاجون إلى الذكاء فحسب، بل يحتاجون أيضًا إلى طريقة للعمل بكفاءة اقتصادية.
أعود دائمًا إلى سؤال واحد عن اقتصاد الوكلاء: إذا كان الذكاء الاصطناعي قادرًا بالفعل على تحليل سوق، والتخطيط لسير العمل، واختيار الخطوة التالية، فما الذي يمنعه من إنجاز المهمة كاملةً بمفرده؟
غالبًا ما لا يكون للجواب علاقة تُذكر بالذكاء.
قد يعرف الوكيل البيانات التي يحتاج إليها، وواجهة API التي ينبغي أن يستدعيها، وكيفية تفسير النتائج. لكن إذا لم يتمكن من الوصول إلى خدمة مدفوعة، أو إثبات هوية من فوّضه، أو دفع تكلفة كل طلب ضمن ميزانية محددة، فسيظل سير العمل معتمدًا على تدخل بشري.
هذه الفجوة مهمة. تفترض الأنظمة الرقمية اليوم، إلى حد كبير، أن شخصًا ما سيسجل الدخول، ويدير بيانات الاعتماد، ويوافق على الوصول، ويسوّي المدفوعات. أما الوكلاء المستقلون، فيحتاجون إلى تنفيذ هذه الإجراءات وفق قواعد يستطيع مالكوهم التحقق منها والتحكم فيها.
ثمة ثلاثة عناصر تفتقر إليها كثير من الأنظمة الحالية.
الهوية: تحتاج الخدمة إلى معرفة الوكيل الذي يرسل الطلب، ومن يملكه، وما التفويض الذي يحمله. وتزداد صعوبة إدارة مفاتيح API ورموز OAuth عبر عدة وكلاء ومنصات عند غياب رابط واضح يمكن التحقق منه بين المستخدم والوكيل وجلسته النشطة.
السلطة: قد يؤدي منح الوكيل صلاحيات واسعة إلى تعريض المالك لمخاطر لا داعي لها، بينما يجعل اشتراط الموافقة اليدوية على كل إجراء الأتمتة مرهقة. يحتاج المستخدمون إلى حدود قابلة للإنفاذ، مثل ميزانية يومية، وحد أقصى للدفع في كل معاملة، وخدمات معتمدة، ومدة محددة للجلسة.
المدفوعات: قد تحتاج الوكلاء إلى الدفع مقابل البيانات أو خدمات الحوسبة مع كل طلب. وقد تجعل وسائل الدفع التقليدية هذه المعاملات الصغيرة غير مجدية اقتصاديًا عندما تكون الرسوم مرتفعة. ومن دون مدفوعات قابلة للبرمجة وآليات عملية للمدفوعات الصغيرة، قد يتمكن الوكيل من تحديد الخدمة المناسبة، لكنه يظل عاجزًا عن استخدامها بشكل مستقل.
أرى أن هذه العناصر أجزاء مترابطة من المشكلة نفسها. يحتاج الوكيل إلى هوية يمكن التحقق منها لإرساء الثقة، وسلطة محدودة للتحكم فيما يمكنه فعله، وآلية دفع تتيح له التصرف ضمن تلك الحدود.
هذه هي المشكلة التي تسعى Kite إلى معالجتها ببنية تحتية مصممة لاقتصاد الوكلاء.
يجمع إطار SPACE بين خمسة عناصر: مدفوعات قائمة على العملات المستقرة، وقيود إنفاق قابلة للبرمجة، ومصادقة مصممة للوكلاء أولًا، وسجلات تدقيق جاهزة للامتثال مع الإفصاح الانتقائي، ومدفوعات صغيرة تجعل خدمات الدفع مقابل كل طلب مجدية اقتصاديًا.
تتألف بنية الهوية من ثلاث طبقات:
المستخدم (السلطة الجذرية): يحتفظ المالك بالتحكم في المفتاح الجذري، الذي تحميه بيئة تنفيذ آمنة ولا يُكشف للوكيل.
الوكيل (السلطة المفوّضة): يحصل كل وكيل على هوية مميزة مشتقة من محفظة المستخدم، وفق نهج شبيه بـ BIP-32. ويمكن التحقق من صلته بالمالك من دون منحه إمكانية الوصول إلى المفتاح الجذري.
الجلسة (السلطة المؤقتة): يُستخدم مفتاح مؤقت لجلسة محددة، ويمكن أن تنتهي صلاحيته بعدها، ما يحد من نطاق التعرض للمخاطر.
أكثر ما يثير اهتمامي هو الفصل بين هذه الطبقات. إذ يمكن منح الوكيل الإذن بتنفيذ مهمة من دون منحه سيطرة غير مقيدة على محفظة المالك.
صُمم Kite Agent Passport لتطبيق هذا النموذج عمليًا. ينشئ المستخدم جوازًا، ويموله بـ USDC، ويوافق على جلسة إنفاق باستخدام مفتاح مرور. وتحدد الجلسة الميزانية الإجمالية، والحد الأقصى للمبلغ في كل معاملة، والفترة الزمنية المسموح بها.
بعد التفويض، يستطيع الوكيل العثور على الخدمات عبر دليل يدعم x402، وطلب الخدمات المدفوعة، وإجراء المدفوعات ضمن الحدود الموقّعة، من دون أن يطلب من المستخدم الموافقة على كل معاملة على حدة. وتربط أدلة التفويض كل معاملة بالمستخدم والوكيل المعنيين، ما ينشئ سجلًا يمكن التحقق منه.
لنتناول مهمة في أبحاث السوق.
لنفترض أن وكيلًا طُلب منه دراسة ترميز الأصول الحقيقية في أنحاء آسيا خلال الساعات الثماني والأربعين المقبلة، باستخدام خمسة مصادر بيانات مدفوعة على الأقل ونموذجين تحليليين متخصصين.
قد يُعدّ مساعد تقليدي تقريرًا استنادًا إلى البيانات العامة ومعرفته الحالية. لكن إنجاز المهمة وفق المواصفات أمر مختلف؛ إذ يجب على الوكيل الوصول إلى واجهات برمجة تطبيقات مدفوعة للبيانات على السلسلة وخارجها، والحصول على تحليلات متخصصة، والدفع مقابل هذه الخدمات أثناء العمل.
من دون تفويض يمكن التحقق منه، لا تملك الجهات المقدمة للخدمات أساسًا يُذكر لقبول المدفوعات من وكيل مجهول. ومن دون ميزانية إنفاق وحدود للجلسة، لا يجد المالك سببًا يُذكر للسماح له بإنفاق المال بشكل مستقل. وينتهي الأمر بشخص يتولى المعاملات يدويًا، فتفقد آلية العمل قدرًا كبيرًا من استقلاليتها.
باستخدام إعداد مثل الذي تصفه Kite، يمكن للوكيل العمل ضمن ميزانية معتمدة مسبقًا، والعثور على الخدمات المتوافقة، والدفع مقابل البيانات اللازمة، ومواصلة تحليله. يحدد المستخدم الحدود أولًا، ثم يتولى الوكيل تنفيذ الإجراءات المسموح بها.
لكن يظل هناك فرق بين تصميم سليم ونظام يعمل بموثوقية في الممارسة. فحماية المفاتيح، وإنفاذ حدود الإنفاق، والتعامل مع الجلسات المخترقة، والتحقق من المدفوعات، كلها أمور مهمة. يجب أن تصمد البنية عند استخدامها فعليًا، لا أن تبدو معقولة على الورق فحسب.
مع ذلك، أعتقد أن المشكلة الأساسية تستحق اهتمامًا أكبر من نقاش آخر حول مدى ذكاء نماذج الذكاء الاصطناعي التي يمكن تطويرها.
فالوكيل الذي يستطيع التفكير في مهمة، لكنه لا يستطيع الدفع بأمان مقابل الموارد اللازمة لإنجازها، يظل معتمدًا على شخص آخر ليتصرف.
يتمثل نهج Kite في ربط الهوية والسلطة المفوّضة ومدفوعات USDC، لكي تتمكن الوكلاء من المشاركة في النشاط الاقتصادي ضمن القواعد التي يحددها مالكوها. وإذا عملت هذه البنية التحتية كما هو مقصود، فقد تكون النتيجة ذكاءً اصطناعيًا لا يكتفي بالتوصية بالخطوة التالية، بل ينفذ المهمة بنفسه، مع وضع حدود للإنفاق وتوفير تفويض يمكن التحقق منه.
