لفترة طويلة، كان التفاعل عبر المحادثة هو الوسيلة الأساسية التي يتواصل بها الناس مع الذكاء الاصطناعي. كنا نطرح الأسئلة ونتلقى الإجابات وننشئ المحتوى، ثم نستخدم النتائج لاتخاذ القرارات بأنفسنا.
بدأت هذه العلاقة تتغير مع تطور وكلاء الذكاء الاصطناعي.
صُمِّم وكلاء الذكاء الاصطناعي لإنجاز ما هو أكثر من مجرد الرد. فبحسب قدراتهم والأدوات المتاحة لهم، يمكنهم تخطيط المهام والتفاعل مع الخدمات الخارجية واستخدام البرامج واتخاذ الإجراءات مع تدخل بشري محدود.
هذا التحول مهم، لأن نظام الذكاء الاصطناعي القادر على التصرف في العالم يثير مجموعة مختلفة من الأسئلة عن نظام يكتفي بتوليد النصوص.
إذا قدم مساعد ذكاء اصطناعي توصية سيئة، فيمكن للناس تجاهلها. أما إذا أجرى وكيل ذكاء اصطناعي عملية شراء أو دفع مقابل خدمة أو نفذ معاملة نيابةً عن شخص، فلن تقتصر العواقب على المحادثة.
يقوم اقتصاد الوكلاء على هذا التحول. فقد يصبح الوكلاء على نحو متزايد مستهلكين ومزودين للخدمات الرقمية، ويتفاعلون مع وكلاء وتطبيقات وأنظمة دفع أخرى.
لكن الذكاء وحده لا يكفي.
يجب أن يكون الوكيل قادرًا على التصرف. ويحتاج الأطراف الأخرى إلى وسائل تحدد هويته، وما يُسمح له بفعله، وما إذا كان من الممكن الوثوق بأفعاله.
وهنا يبدأ التحدي الحقيقي.
المشكلة ليست الثقة وحدها، بل الاستقلالية المنضبطة.
هناك توتر مهم في صميم الذكاء الاصطناعي المستقل.
إذا منحت الوكيل صلاحيات أقل مما يحتاج، فلن يعود أكثر من مساعد يطلب الإذن مرارًا. فقد يكون قادرًا على التخطيط لمهمة كاملة، لكنه يظل معتمدًا على الإنسان للموافقة على كل خطوة صغيرة.
أما إذا منحت الوكيل صلاحيات أكثر مما ينبغي، فسيصبح احتواء عواقب الخطأ أصعب. فقد يؤدي اختراق الوكيل أو سوء تصميم التعليمات أو اتخاذ قرار غير متوقع إلى أفعال لم يقصد المستخدم قط تفويضها.
ولا يفيد أي من الطرفين المتطرفين على نحو خاص.
لا ينبغي أن يكون الهدف جعل الوكلاء مستقلين تمامًا، ولا إبقاءهم معتمدين دائمًا على موافقة البشر. بل ينبغي منحهم حرية كافية لإنجاز المهمة، مع إبقاء تلك الحرية ضمن حدود محددة بوضوح.
في الاقتصاد الرقمي التقليدي، يبدأ الشخص عادةً عملية الدفع أو يوافق على معاملة. أما في اقتصاد تقوده الوكلاء، فقد يحدد الشخص الهدف بينما يقرر الوكيل الإجراءات اللازمة لتحقيقه.
وهذا يخلق متطلبًا جديدًا: يجب أن تكون السلطة المفوضة محدودة ومفهومة وقابلة للسحب.
ينبغي ألا يحتاج الوكيل إلى وصول غير محدود لمجرد أنه يحتاج إلى إتمام مهمة واحدة. بل ينبغي أن تعكس صلاحياته ما ينوي المستخدم تفويضه، والتكلفة المحتملة للمهمة، والمدة التي يحتاج خلالها الوكيل إلى العمل باستقلالية.
هذه هي المشكلة التي تجعل البنية التحتية لهوية الوكلاء والتفويض والمدفوعات جديرة بالبحث.
أين يقع دور Kite AI
تعمل Kite AI على بناء بنية تحتية تهدف إلى دعم اقتصاد تستطيع فيه وكلاء الذكاء الاصطناعي التفاعل مع الخدمات وإجراء المعاملات.
بدلًا من التعامل مع الوكلاء بوصفهم مجرد أدوات برمجية يشغّلها الناس، يتناول نهج Kite البنية التحتية اللازمة لمشاركة الوكلاء في المعاملات الرقمية. ويشمل ذلك هوية الوكيل، والصلاحيات المفوضة، وآليات الدفع.
وهذا تمييز مهم.
قد يعرف الوكيل الذكي كيفية إنجاز مهمة، لكن معرفة ما ينبغي فعله لا تمنحه تلقائيًا طريقة آمنة أو موثوقة لتنفيذه. فما زال يحتاج إلى إثبات هويته، والحصول على التفويض المناسب، والتفاعل مع الخدمات، وإجراء المدفوعات عند الحاجة.
هذه مشكلات منفصلة، وحل إحداها لا يعني تلقائيًا حل المشكلات الأخرى.
تكتسب Kite Passport أهمية خاصة لأن تصميمها الموثق يتيح للوكيل الدفع مقابل الخدمات المدعومة نيابةً عن المستخدم، ضمن حدود إنفاق يوافق عليها المستخدم. ويربط سير العمل الموثق بين إعداد الحساب، وتمويل المحفظة، وصلاحيات الإنفاق المرتبطة بالجلسة، ومدفوعات الخدمات.
هنا تصبح رؤية Kite الأوسع ملموسة. فبدلًا من منح الوكيل وصولًا ماليًا غير مقيد، يستطيع المستخدم تفويضه للعمل خلال فترة محددة وبميزانية محددة.
الفكرة المثيرة للاهتمام ليست مجرد أن الوكلاء قد يتمكنون من إجراء المدفوعات، بل أن قدرتهم على إجراء المعاملات يمكن ربطها بالصلاحيات التي يمنحها لهم المستخدم صراحةً.
لفهم أهمية ذلك، يجدر النظر في كيفية تصميم سير العمل الموثق في Kite Passport.
الهويات الهرمية: ربط الوكلاء بمالكيهم
لا تقتصر أهمية البنية التحتية للوكلاء على تحديد هوية الوكيل، بل تشمل أيضًا إثبات علاقته بالجهة التي تفوضه.
تصف وثائق Kite نموذجًا للهوية من ثلاث طبقات: هوية المستخدم أو الهوية الجذرية، وهوية وكيل يتمتع بسلطة مفوضة، وهوية جلسة لفترة نشاط محددة. تخبرنا هوية الوكيل المستقلة عن الوكيل الذي يتفاعل مع الخدمة. أما التسلسل الهرمي فيضيف سياقًا، إذ يربط الوكيل بالمستخدم الذي فوضه وبالجلسة الأكثر تقييدًا التي يعمل ضمنها.
قد يكون هذا مفيدًا عندما يدير شخص أو مؤسسة عدة وكلاء، يتولى كل منهم مهام مختلفة. فبدلًا من التعامل مع كل وكيل على أنه هوية منفصلة تمامًا بصلاحيات لا صلة لها بغيرها، يمكن للتسلسل الهرمي أن يجسد العلاقة بين المالك والوكلاء الذين يعملون تحت سلطته. كما تصف وثائق Kite عناوين للوكلاء مشتقة من محفظة المستخدم، ومفاتيح جلسات مُصممة لتكون قصيرة الأجل. وهذه تفاصيل تصميمية للبنية الموثقة، وليست ضمانًا بأن كل اختراق أو خطأ في التنفيذ سيكون بلا ضرر.
يشبه الأمر التمييز بين هوية من يقوم بالفعل والجهة التي يستند إليها في القيام به. وكلا السؤالين مهم عندما يبدأ البرنامج باتخاذ القرارات وإجراء المعاملات بصورة مستقلة.
على سبيل المثال، قد تدير شركة وكلاء منفصلين للبحث والوصول إلى البيانات والشراء. وقد يحتاج كل وكيل إلى صلاحيات مختلفة، لكن سلطته تعود في نهاية المطاف إلى المؤسسة التي نشرته. ويمكن لبنية الهوية الهرمية أن توضح هذه العلاقات بدلًا من تركها ضمنية في منطق التطبيق.
لهذه البنية أيضًا آثار أمنية مهمة. فإذا تعرض وكيل أو جلسة للاختراق، ينبغي للنظام المصمم جيدًا أن يحد من الضرر المحتمل ضمن الصلاحيات والموارد المتاحة لذلك الوكيل أو تلك الجلسة. وينبغي ألا يمنح اختراق وكيل واحد تلقائيًا وصولًا غير مقيد إلى السلطة الأساسية للمستخدم أو إلى جميع الوكلاء الآخرين العاملين ضمن المنظومة نفسها.
ومع بدء الوكلاء بتفويض المهام إلى وكلاء آخرين، تزداد أهمية الحفاظ على علاقات واضحة بين الهويات وحدود السلطة المفوضة. فمن دون ذلك، قد تتجاوز عواقب الاختراق على مستوى ما نطاق المهمة الأصلية. والهدف هو جعل السلطة قابلة للتتبع ومجزأة، بحيث يحصل كل وكيل على ما يحتاج إليه فقط، بدلًا من أن يرث تحكمًا غير مقيد من الهوية الأعلى منه.
هذا هدف أمني، وليس ضمانًا ضد كل إخفاق محتمل. وتعتمد فعاليته على التنفيذ، وأمن المفاتيح الأساسية، وفرض الضوابط المعنية على النحو الصحيح.
في نهاية المطاف، تتعلق الهوية الهرمية بأكثر من تنظيم عدة وكلاء. فهي تهدف إلى الحفاظ على علاقة واضحة بين الوكيل الذي ينفذ إجراءً، والسلطة التي يعمل بموجبها، وحدود تلك السلطة. ومع ازدياد ترابط الأنظمة المستقلة، قد يصبح هذا الفصل أساسًا مهمًا لجعل التفاعلات التي تقودها الوكلاء أكثر أمانًا وأسهل في الإدارة.
Kite Passport: من الإعداد إلى المدفوعات المستقلة
صُممت Kite Passport لتمكين وكيل الذكاء الاصطناعي من الدفع مقابل الخدمات المدعومة نيابةً عن المستخدم، من دون الحاجة إلى موافقة المستخدم يدويًا على كل معاملة. يبدأ المستخدم بإعداد Passport، وتمويل محفظتها، والموافقة على جلسة إنفاق. بعد ذلك يستطيع الوكيل اكتشاف الخدمات وإجراء المدفوعات وتلقي النتائج ضمن حدود الجلسة.
تكمن أهمية سير العمل في أنه يفصل بين ثلاثة أمور كثيرًا ما تختلط: منح الوكيل إمكانية الوصول إلى نظام دفع، وتزويده بالأموال، وتفويضه بإنفاق تلك الأموال.
هذه ليست الصلاحية نفسها.
1. تثبيت Passport وربط وكيل بها
تبدأ العملية الموثقة بواجهة سطر الأوامر الخاصة بـKite Passport، أو CLI، وبمهارات الوكيل التي تتيح لوكيل ذكاء اصطناعي متوافق التفاعل مع Passport.
تغطي وثائق Kite وكلاء البرمجة الذين يعملون على حاسوب المستخدم والوكلاء السحابيين الذين يعملون على حواسيب مستضافة. وتختلف طريقة التثبيت، لكن عملية تسجيل الدخول إلى الحساب تتبع النمط العام نفسه.
بالنسبة إلى إعدادات وكلاء البرمجة المدعومة، مثل Claude Desktop أو Codex، تتضمن العملية الموثقة تشغيل أمر تثبيت Passport من خلال بيئة تطوير الوكيل، واتباع إرشادات الإعداد للتسجيل في Passport وضبط المهارات المناسبة.
أما في إعدادات الوكلاء السحابيين المدعومة، فيتبع المستخدم إرشادات الإعداد المقابلة لربط الوكيل المستضاف بـPassport.
بعد التثبيت والتسجيل، يتلقى المستخدم رسالتين إلكترونيتين: رابط تحقق يفتح لوحة معلومات Passport ورمزًا من ثمانية أحرف يجب إعادته إلى الوكيل. يفتح المستخدم رابط التحقق، وينشئ مفتاح مرور باستخدام طريقة مدعومة مثل Touch ID أو Face ID أو Windows Hello أو مفتاح أمان مادي، ثم يزوّد الوكيل بالرمز لإكمال تسجيل الدخول.
يشكل مفتاح المرور جزءًا مهمًا من هذه العملية، لأن الموافقة على جلسة الإنفاق لا يُفترض أن تكون قرارًا غير مقيد يتخذه الوكيل في الخفاء. إذ يمر المستخدم بخطوة موافقة صريحة قبل أن يحصل الوكيل على صلاحية الإنفاق المطلوبة.
وثمة اعتبار عملي مهم عند استخدام وكيل مستضاف: ربطه بـPassport يمنحه إمكانية الوصول إلى حساب Passport الخاص بالمستخدم. وتنصح وثائق Kite المستخدمين تحديدًا بمراجعة حدود الجلسة قبل الموافقة. ينبغي ألا تعني الراحة الوثوق الأعمى بأي صلاحيات يطلبها الوكيل.
بعد ربط الحساب والوكيل، تأتي الحاجة إلى التمويل.
2. تمويل محفظة Passport
تحتاج Passport إلى أموال قبل أن يتمكن الوكيل من إجراء طلبات مدفوعة. ووفقًا لوثائق Kite، يستخدم سير عمل الدفع مقابل الخدمات عملة USDC.e على Kite Chain.
توفر لوحة المعلومات عدة طرق لإضافة الأموال، بحسب نقطة البداية لدى المستخدم.
الشراء بالبطاقة: يمكن للمستخدمين الذين لا يملكون عملات مشفرة مسبقًا شراء USDC على Base من قسم إضافة الأموال في لوحة معلومات Passport. يختارون المبلغ وطريقة الدفع، ويكملون عملية الشراء، ثم ينتظرون تحديث الرصيد بعد تسوية المعاملة.
إيداع العملات المستقرة: يمكن للمستخدمين الذين يملكون بالفعل عملات مستقرة مدعومة استخدام علامة تبويب العملات المشفرة للوصول إلى عنوان الإيداع المناسب. تسرد الوثائق خيارات الإيداع المدعومة عبر شبكات وأصول متعددة، بما فيها USDC على Base وPolygon وAvalanche وTempo وSolana وArc وغيرها من الخيارات المذكورة. ويجب على المستخدمين إرسال العملة المستقرة الصحيحة إلى العنوان المرتبط بشبكتها. وقد يؤدي إرسال أصل خاطئ أو استخدام شبكة غير صحيحة إلى عدم ظهور الأموال كما هو متوقع.
استخدام Kite Bridge: يمكن للمستخدمين أيضًا نقل USDC إلى Kite Chain عبر Kite Bridge. يربطون المحفظة التي تحتوي على أموالهم، ويختارون الشبكة المصدر والرمز، ويحددون Kite وجهةً، ثم يضعون عنوان محفظة Passport الخاصة بهم عنوانًا للمستلم. بعد تأكيد المعاملات وانتظار اكتمال التحويل عبر الجسر، ينبغي أن يتحدث رصيد Passport.
التحويل من محفظة موجودة أصلًا على Kite: إذا كان المستخدم يملك USDC.e على Kite Chain بالفعل، فيمكنه إرسالها مباشرةً من محفظة خارجية إلى عنوان محفظة Passport. وتذكر وثائق Kite أن المحفظة الخارجية تحتاج إلى $KITE tokens لدفع رسوم الغاز الخاصة بهذا التحويل.
يمكن للمستخدم التحقق من الرصيد الناتج في لوحة المعلومات أو باستخدام أمر رصيد محفظة kpass. كما يمكن للوكيل التحقق من الرصيد عند الطلب منه.
توفر طرق التمويل هذه خيارات مختلفة للمستخدمين لإعداد المحفظة، لكن تمويلها لا يعني تلقائيًا أن الوكيل يملك إذنًا غير مقيد بإنفاق الرصيد.
هذا التمييز جوهري في نموذج Passport. فالمحفظة تحتفظ بالأموال، بينما تحدد جلسة الإنفاق الصلاحيات التي يحصل عليها الوكيل لاستخدامها.
3. إنشاء جلسة إنفاق
لعل هذه أهم خطوة في سير العمل بأكمله.
بعد تمويل المحفظة، يستطيع الوكيل طلب جلسة إنفاق. وبدلًا من طلب وصول عام إلى المحفظة، تحدد الجلسة المهمة والحدود التي يُسمح للوكيل بالإنفاق ضمنها.
تشمل معلمات الجلسة الموثقة لدى Kite ما يلي:
ملخص المهمة: وصف لما يحاول الوكيل إنجازه.
الحد الأقصى للمبلغ لكل معاملة: الحد الأعلى للدفعة الواحدة.
الحد الأقصى للمبلغ الإجمالي: الميزانية الكلية المتاحة خلال الجلسة.
مدة الصلاحية (TTL): الفترة التي تظل الجلسة خلالها سارية.
الأصول المعتمدة: الأصول التي يمكن للجلسة استخدامها.
على سبيل المثال، تخيل وكيلًا يحتاج إلى إجراء طلب مدفوع واحد لواجهة برمجة تطبيقات للطقس. يمكن للمستخدم تفويض جلسة بحد أقصى يبلغ دولارين لكل معاملة، وميزانية إجمالية قدرها 10 دولارات، ومدة صلاحية تبلغ 24 ساعة.
يطلب الوكيل الجلسة ويتلقى رابط موافقة. يفتح المستخدم الرابط على جهاز يتوفر عليه مفتاح المرور الخاص به، ثم يوافق على الطلب صراحةً.
ولا تصبح الجلسة نشطة إلا بعد تلك الموافقة.
ويفيد التمييز بين الحد الأقصى لكل معاملة والميزانية الإجمالية على نحو خاص. فالحد الأقصى لكل معاملة يقيّد قيمة أي دفعة منفردة، بينما تحد الميزانية الإجمالية الإنفاق التراكمي خلال الجلسة. وتضيف مدة الصلاحية حدًا زمنيًا يمنع بقاء الجلسة سارية إلى أجل غير مسمى.
بعد الموافقة، يستطيع الوكيل إجراء المدفوعات المؤهلة ضمن حدود الجلسة دون طلب موافقة جديدة لكل دفعة على حدة. وتنتهي صلاحية الجلسة عند بلوغ حدها الزمني أو استنفاد ميزانيتها.
هذه هي المفاضلة الأساسية التي تحاول Passport إدارتها: يحتفظ المستخدم بالتحكم في نطاق التفويض، بينما يحصل الوكيل على ما يكفي من الاستقلالية لإنجاز المهمة.
من دون هذا الفصل، قد تعني الاستقلالية منح الوكيل وصولًا ماليًا واسعًا. أما الصلاحيات القائمة على الجلسات فتهدف إلى منح الوكيل السلطة اللازمة لفترة عمل محددة فحسب.
وبالطبع، لا يكون نظام الصلاحيات مفيدًا إلا بقدر جودة تنفيذه. إذ يجب أن يفهم المستخدم ما الذي يوافق عليه، وأن يفرض النظام الحدود على النحو الصحيح. ولا تضمن الجلسة أن يختار الوكيل الخدمة المناسبة أو يتخذ القرار الصحيح؛ بل هي وسيلة لتقييد الأفعال المصرح له باتخاذها.
4. اكتشاف الخدمات وإجراء المدفوعات
بعد تمويل المحفظة والموافقة على جلسة الإنفاق، يستطيع الوكيل البحث عن خدمة مدفوعة مناسبة في دليل Kite.
تدعم واجهة سطر الأوامر الموثقة اكتشاف الخدمات باستخدام الأمر ksearch. ويمكن للمستخدم أيضًا أن يطلب من وكيل متوافق البحث عن خدمات متاحة تلائم مهمة معينة، مثل العثور على واجهة برمجة تطبيقات للطقس.
بعد أن يحدد الوكيل خدمة مناسبة، يمكنه إجراء طلب مدفوع عبر مسار الدفع المدعوم.
من الآليات التي توثقها Kite بروتوكول x402، وهو بروتوكول دفع يعتمد على استجابة HTTP 402 Payment Required. وتتمثل الفكرة الأساسية في أن الخدمة تستطيع الإشارة إلى أن الطلب يتطلب دفعًا، وتقديم الشروط اللازمة للمتابعة.
يمكن فهم التفاعل بوصفه سلسلة من الخطوات:
يطلب الوكيل موردًا من خدمة.
إذا كان الدفع مطلوبًا، تعيد الخدمة تحديًا للدفع يوضح الشروط.
يحصل وكيل Passport على تفويض بالدفع ضمن جلسة الإنفاق التي وافق عليها المستخدم.
يعيد الوكيل إرسال الطلب مع معلومات الدفع المطلوبة.
تتحقق الخدمة من الدفع وتسويه عبر بنية الدفع التحتية التي تدعمها.
بعد تأكيد الدفع، تعيد الخدمة المورد أو الاستجابة المطلوبة.
يمكن للوكيل بعد ذلك استخدام تلك الاستجابة كجزء من المهمة الأكبر التي ينفذها.
تكمن أهمية ذلك في أن الدفع قد يصبح جزءًا من تفاعل البرنامج نفسه. فلا يحتاج الوكيل بالضرورة إلى التوقف وإرسال المستخدم إلى صفحة دفع تقليدية وانتظار إتمامه يدويًا لكل عملية شراء صغيرة.
تحدد الخدمة متطلبات الدفع الخاصة بها، وتطبق Passport صلاحيات الإنفاق التي وافق عليها المستخدم، ثم تقدم الخدمة المورد بعد معالجة الدفع.
وتصف وثائق مزودي الخدمات لدى Kite أيضًا دعم بروتوكول مدفوعات الآلات (MPP) بوصفه مسارًا آخر لقبول الخدمات مدفوعات من وكلاء Passport. وتختلف التفاصيل باختلاف البروتوكول، لكن الهدف الأوسع متشابه: تمكين الخدمات من تحديد متطلبات الدفع بطريقة تستطيع وكلاء البرمجيات التعامل معها.
كما توثق Passport دعم التحويلات المباشرة بعملة USDC التي يبدأها الوكيل ضمن حدود الجلسة المعتمدة. وهذا يختلف عن الدفع مقابل خدمة عبر طلب قائم على بروتوكول، رغم أن كليهما يعتمد على الصلاحيات الممنوحة للوكيل.
يجدر توضيح ما يعنيه هذا وما لا يعنيه. فليس كل موقع أو واجهة برمجة تطبيقات متاحًا تلقائيًا لوكلاء Passport. يجب أن تدعم الخدمة مسار دفع متوافقًا، وأن يتفاعل الوكيل معها على نحو صحيح. يوفر النظام طريقة لربط التفويض بالدفع، لكنه لا يلغي الحاجة إلى تكامل الخدمات.
5. مراقبة النشاط والاحتفاظ بالتحكم
لا ينبغي أن تعني الاستقلالية فقدان القدرة على المتابعة.
بعد أن يبدأ الوكيل بالإنفاق، يستطيع المستخدمون مراجعة المدفوعات المكتملة ونشاط الجلسة عبر لوحة معلومات Passport. كما توفر واجهة سطر الأوامر أوامر لسرد الجلسات النشطة وعرض النشاط الأخير.
هذا مهم لأن السلطة المفوضة ينبغي أن تظل مفهومة بعد منحها. يحتاج المستخدمون إلى إمكانية فحص ما فعله وكلاؤهم، والمبلغ الذي أنفقوه، وما إذا كانت الجلسة لا تزال نشطة.
توفر ميزانية الجلسة وموعد انتهائها حدودًا مسبقة، بينما توفر سجلات النشاط إمكانية الاطلاع لاحقًا. وكلاهما مهم، لكن لكل منهما غرض مختلف.
تقيّد حدود الإنفاق ما يُسمح للوكيل بفعله، فيما يساعد سجل النشاط المستخدم على فهم ما فعله الوكيل فعليًا.
لا يضمن أي منهما أن كل معاملة كانت حكيمة أو أن كل خدمة كانت موثوقة. فالمراقبة ليست بديلًا عن الأمن، كما أن سجل المعاملات لا يثبت وحده أن البرنامج الأساسي تصرف على نحو صحيح.
مع ذلك، فإن الجمع بين الأمرين أنفع من مجرد منح الوكيل محفظة والأمل في أن يتصرف كما هو متوقع.
المبدأ الأوسع هو أن الاستقلالية المفوضة تحتاج إلى حدود وإمكانية الاطلاع معًا. ينبغي ألا يضطر المستخدمون إلى الاختيار بين الموافقة على كل إجراء صغير والتخلي عن التحكم الفعلي في العملية.
6. سحب التفويض: تحكم يستحق التحقق منه
تفويض السلطة نصف المعادلة فقط. وينبغي لنموذج الصلاحيات المتين أن يوضح أيضًا كيف يمكن للمستخدم سحب السلطة عند تغير الظروف. فقد تكون المهمة قد اكتملت، أو لم تعد هناك حاجة إلى الوكيل، أو قد يدفع سلوكه المستخدم إلى إيقافه.
في تفويض الوكلاء، يعني سحب التفويض إبطال السلطة الممنوحة سابقًا بدلًا من انتظار انتهاء صلاحيتها طبيعيًا. توفر الجلسات محدودة المدة حدًا تلقائيًا، لكن قد لا يحين ذلك الحد بالسرعة الكافية إذا أراد المستخدم إيقاف المهمة مبكرًا.
يحل سقف الميزانية وآلية سحب التفويض مشكلتين مختلفتين. فالميزانية تحد من الإنفاق المحتمل، بينما يحدد سحب التفويض ما إذا كان ينبغي السماح للوكيل بمواصلة العمل. وكلاهما سؤال مهم عند تقييم الاستقلالية المفوضة.
في نهاية المطاف، يتطلب التحكم الفعلي أكثر من وضع الحدود في البداية. يحتاج المستخدمون إلى معلومات واضحة عن الضوابط المتاحة والضوابط التي ما زال ينبغي التحقق منها.
يصبح من الأسهل الوثوق بالاستقلالية عندما يكون نطاق السلطة المفوضة واضحًا ومحددًا بزمن، وعندما يكون سحبها ممكنًا، حيثما كان ذلك مدعومًا.
ما الذي يغيره سير العمل هذا فعليًا
عند جمع عناصر سير عمل Passport، يتكون مسار محدد يمتد من تفويض المستخدم إلى الدفع الذي ينفذه الوكيل.
يربط المستخدم وكيلًا، ويمول محفظة، ويوافق على جلسة بمعلمات إنفاق صريحة، ثم يتيح للوكيل التفاعل مع الخدمات المدفوعة المدعومة. وبعد ذلك يستطيع المستخدم مراجعة النشاط الناتج.
وهذا نهج أكثر واقعية لاستقلالية الوكلاء من مجرد منح نظام ذكاء اصطناعي إمكانية الوصول إلى وسيلة دفع.
كما يكشف هذا النهج مواضع استمرار الأسئلة الصعبة. ما مدى سهولة فهم المستخدمين للصلاحيات التي يوافقون عليها؟ وما مدى موثوقية فرض هذه الحدود؟ ماذا يحدث عندما يتخذ الوكيل خيارًا سيئًا ضمن الميزانية المصرح بها؟ وما مدى أمان بيئة الوكيل والمحفظة والخدمة التي تتلقى الدفع؟
تعالج Passport جزءًا من مشكلة التفويض والدفع، لكنها لا تستطيع إزالة كل المخاطر المرتبطة بالبرمجيات المستقلة.
ولا يدعو ذلك إلى رفض هذا النهج، بل إلى تقييمه بناءً على ما يقدمه فعليًا.
النصف الآخر: يجب أن تقبل الخدمات مدفوعات الوكلاء
هناك جانب آخر من هذا النظام يسهل إغفاله.
قد يمتلك الوكيل محفظة وهوية وصلاحيات إنفاق معتمدة، لكنه يظل بحاجة إلى مكان ينفق فيه أمواله. ولكي يعمل اقتصاد الوكلاء، يجب أن يتمكن مزودو الخدمات من قبول المدفوعات من الوكلاء كما يقبلونها من الناس.
لهذا السبب تُعد وثائق مزودي الخدمات لدى Kite مهمة لفهم الصورة الأوسع.
تصف Kite مسارين لدمج الدفع لدى مزودي الخدمات: x402 وMPP. باستخدام x402، يستطيع مزود الخدمة إرجاع استجابة HTTP 402 Payment Required تتضمن شروط الدفع. ويحصل وكيل Passport عندئذ على التفويض المناسب من جلسة المستخدم المعتمدة، ثم يعيد إرسال الطلب مصحوبًا بمعلومات الدفع. ويتحقق مزود الخدمة من الدفع ويسويه عبر وسيط متوافق قبل تقديم الخدمة.
يتبع MPP نمطًا عامًا مشابهًا يقوم على طلب مورد، وعرض شروط الدفع، واستلام بيانات اعتماد الدفع، والتحقق من الدفع، ثم تقديم المورد؛ لكنه يدعم مجموعة مختلفة من آليات الدفع وأنماط التفاعل.
النقطة المهمة هي أن النظام لا يقتصر على مساعدة الوكلاء في إنفاق الأموال، بل يهدف أيضًا إلى إتاحة الخدمات لهم عبر مسارات دفع مصممة للبرمجيات.
تخيل مطورًا يتيح الوصول إلى واجهة برمجة تطبيقات متخصصة. إذا استطاع الوكيل اكتشاف الخدمة وفهم متطلبات الدفع فيها والحصول على تفويض ضمن ميزانية المستخدم وتلقي استجابة الواجهة بعد الدفع، فسيكون أمام المطور مسار محتمل لخدمة العملاء الآليين دون إنشاء تجربة دفع يدوية منفصلة بالكامل.
ولا يضمن ذلك وجود طلب أو يجعل التكامل سهلًا. فما زال على مزودي الخدمات تنفيذ البروتوكول المعني وتهيئة بنيتهم التحتية للدفع والتأكد من أن خدمتهم تعالج الطلبات بأمان. كما يحتاج الوكلاء إلى وسيلة موثوقة لاكتشاف الخدمة وفهمها.
لكن أهمية هذا الهيكل ذي الطرفين لا يمكن إغفالها. يزداد نفع نظام مدفوعات الوكلاء كلما زاد عدد الخدمات المناسبة التي تقبل المدفوعات، وتزداد دوافع الخدمات لدعم مدفوعات الوكلاء عندما يتوفر وكلاء وعملاء مفيدون ومستعدون لاستخدامها.
بعبارة أخرى، يجب أن تربط البنية التحتية طرفي المعاملة.
لماذا تهم المدفوعات اقتصاد الوكلاء
تصبح الاستقلالية أكثر نفعًا عندما يستطيع الوكلاء الدفع مقابل الموارد التي يحتاجون إليها.
قد يحتاج الوكيل إلى الوصول إلى واجهة برمجة تطبيقات أو مصدر بيانات أو خدمة حوسبة أو قدرات وكيل آخر. وإذا تطلب كل تفاعل من الإنسان التفاوض على الدفع وإتمامه يدويًا، فقد تصبح الأتمتة مرهقة بسرعة.
وهذا أحد أسباب أهمية البنية التحتية للدفع للاقتصاد الناشئ للوكلاء.
تُعد العملات المستقرة مفيدة في هذه الحالات لأنها مصممة لتتبع قيمة عملة مرجعية، ما يجعل فهم قيم المعاملات أسهل من الأصول التي تتقلب أسعارها بشدة. وفي مسار الدفع الموثق في Kite Passport، تكون USDC.e على Kite Chain هي العملة المطلوبة لتمويل محفظة Passport.
لا تتمثل الفائدة المحتملة في أن كل تفاعل للذكاء الاصطناعي يحتاج إلى دفعة؛ فمعظم التفاعلات لا تحتاج إليها. بل تكمن الفائدة في أن الدفع، عندما يحتاج الوكيل فعلًا إلى شراء مورد، يمكن دمجه في سير عمله بدلًا من أن يتحول إلى مقاطعة يدوية.
لكن نجاح المعاملة من الناحية التقنية لا يجعلها بالضرورة معاملة مفيدة. فرسوم الشبكة وأسعار الخدمات والطلبات الفاشلة والمخاطر الأمنية وتعقيد التفويض كلها عوامل تؤثر في جدوى المدفوعات الآلية عمليًا.
يحتاج اقتصاد الوكلاء إلى أكثر من القدرة على نقل الأموال. إنه يحتاج إلى أنظمة دفع مثل Kite Passport تكون عملية الاستخدام للبرمجيات وآمنة بما يكفي لتفويض الناس بها.
إطار مفيد لتقييم البنية التحتية للوكلاء
عند النظر إلى المشاريع التي تبني بنية تحتية لاقتصاد الوكلاء، أرى أن طرح خمسة أسئلة أكثر فائدة من الاكتفاء بالسؤال عما إذا كان المشروع يدعم وكلاء الذكاء الاصطناعي.
1. مدفوعات قائمة على العملات المستقرة
هل يستطيع الوكلاء الدفع مقابل الخدمات باستخدام أصول وآليات دفع مناسبة للمعاملات الرقمية؟ المهم هو مدى فائدة مسار الدفع عمليًا، لا مجرد وجود رمز أو محفظة.
2. صلاحيات قابلة للبرمجة
هل يستطيع المستخدمون تحديد السلطة التي يحصل عليها الوكيل؟ يمكن لحدود الإنفاق والإجراءات المقيّدة والصلاحيات المحددة بزمن أن تساعد في إبقاء الوصول المفوض متناسبًا مع المهمة.
3. مصادقة مصممة للوكلاء أولًا
هل يستطيع الوكيل إثبات هويته والتفاعل مع الخدمة عبر عملية مصممة للبرمجيات، مع احترام التفويض الذي منحه له مالكه؟
4. نشاط قابل للتدقيق
هل يستطيع المستخدمون فحص الإجراءات والمعاملات ذات الصلة؟ تعد إمكانية الاطلاع مهمة عندما يتصرف الوكيل نيابةً عن شخص، لكن سجل المعاملات وحده لا يثبت صحة كل قرار أو أمان كل عملية أساسية.
5. معاملات مجدية اقتصاديًا
هل يستطيع النظام دعم معاملات بتكلفة وسرعة مناسبتين للخدمات المعنية؟ إذا كانت المدفوعات الصغيرة باهظة أو صعبة التنفيذ، فقد يظل كثير من الاستخدامات المحتملة غير عملي.
توفر هذه الأسئلة مجتمعةً طريقة مفيدة لتقييم البنية التحتية للوكلاء المستقلين. كما توضح لماذا لا ينبغي اعتبار أي ميزة منفردة حلًا كاملًا.
المحفظة لا تحل مشكلة التفويض. ونظام الهوية لا يضمن اتخاذ قرارات جيدة. ومسار التدقيق لا يقضي على الثغرات الأمنية. وبروتوكول الدفع لا يخلق طلبًا مستدامًا تلقائيًا.
تحتاج الأنظمة الأقوى إلى عمل هذه العناصر معًا. وتعرض Kite نهجها من خلال إطار مترابط يُسمى SPACE: المدفوعات القائمة على العملات المستقرة، والقيود القابلة للبرمجة، والمصادقة المصممة للوكلاء أولًا، والبنية التحتية الجاهزة للامتثال، والمدفوعات الصغيرة المجدية اقتصاديًا. ويعبّر هذا الإطار عن أهداف المشروع، لكن لا ينبغي اعتباره دليلًا على أن جميع التحديات في كل فئة قد حُلّت بالفعل. والاختبار العملي هو مدى تكامل هذه العناصر في التطبيقات الواقعية.
ما الذي يمكن أن يتيحه هذا؟
إذا أصبحت هوية الوكلاء وصلاحياتهم ومدفوعاتهم موثوقة بما يكفي، فقد يسهل أتمتة عدة أنواع من التفاعلات.
قد يشتري الوكلاء إمكانية الوصول إلى واجهات برمجة التطبيقات أو البيانات، ويدفعوا مقابل الموارد الحاسوبية، وينسقوا مع وكلاء متخصصين يقدمون خدمات لا يستطيعون تنفيذها بأنفسهم. وقد تنشر الشركات أيضًا وكلاء ينجزون أجزاءً من سير العمل عبر خدمات متعددة دون الحاجة إلى موافقة بشرية على كل تفاعل على حدة.
هذه مسارات محتملة لاقتصاد الوكلاء، وليست دليلًا على أن كل استخدام يعمل بالفعل على نطاق واسع.
وسيعتمد نجاحها على أكثر من توافر البنية التحتية. إذ يحتاج المطورون إلى إنشاء خدمات مفيدة، ويحتاج المستخدمون إلى أسباب تدفعهم إلى تفويض المهام، كما تحتاج الشركات إلى الوثوق بالأنظمة التي تتعامل مع مواردها.
يمكن للتقنية تقليل الاحتكاك، لكنها لا تستطيع خلق الطلب من تلقاء نفسها.
دور رمز KITE
لدى Kite أيضًا رمز أصلي هو $KITE ، وينبغي النظر إليه على نحو منفصل عن العملات المستقرة المستخدمة لدفع تكاليف خدمات Passport. ففي مسار التمويل الموثق، تُستخدم USDC.e لمدفوعات الوكلاء على Kite Chain، بينما يلزم $KITE لدفع رسوم الغاز عند تحويل الأموال من محفظة خارجية موجودة أصلًا على Kite Chain.
ولا ينبغي الخلط بين دور الرمز الموثق في دفع رسوم الغاز وبين وصف كامل لاستخداماته الأوسع. وينبغي تقييم أي دور إضافي بالرجوع إلى وثائق المشروع الحالية، مع التمييز بين الوظائف المتاحة فعليًا وتلك المخطط لها. ولا ينبغي استنتاج فائدة الرمز من الرؤية الأوسع وحدها.
الاختبار الحقيقي هو ما إذا كان بإمكاننا التفويض بأمان
من السهل فهم وعود وكلاء الذكاء الاصطناعي. إذ يمكنهم تولي مزيد من العمل بين تحديد ما نريده وإنجازه فعليًا.
لكن كلما زادت السلطة التي نمنحهم إياها، زادت أهمية تحديد النقطة التي تنتهي عندها تلك السلطة.
أرى أن هذا أحد التحديات المحورية في اقتصاد الوكلاء. فالمطورون لا يحاولون بناء أنظمة قادرة على العمل باستقلالية فحسب، بل يحاولون بناء أنظمة يستطيع الناس الوثوق بها على نحو معقول لتتصرف نيابةً عنهم.
يتناول تركيز Kite على هوية الوكلاء والصلاحيات المفوضة والبنية التحتية للدفع جوانب من هذا التحدي. وتجعل Passport الفكرة ملموسة على نحو خاص بربط حدود إنفاق المستخدم بالأفعال التي يستطيع الوكيل تنفيذها ضمن جلسة معتمدة. وستعتمد أهميتها على المدى الطويل على مدى موثوقية عمل هذه الضوابط، وسهولة دمج الخدمات مع مسارات الدفع، ومدى فائدة التجربة للمستخدمين بما يكفي لاعتمادها.
ما زالت هناك أسئلة مفتوحة بشأن الأمن والمساءلة وسهولة الاستخدام والاعتماد. ولا ينبغي تجاهلها لمجرد أن التقنية واعدة؛ فهي تحديدًا ما سيقرر ما إذا كانت هذه الوعود ستصبح مفيدة عمليًا.
الوكيل القادر على تنفيذ مهمة هو وكيل مفيد. والوكيل القادر على تنفيذها ضمن حدود محددة بوضوح أكثر فائدة. أما الوكيل الذي يمكن فهم أفعاله ومراقبتها وإيقافه عبر ضوابط مدعومة فعليًا، فمن الأسهل الوثوق به. هذا هو التوجه الأوسع الذي تعمل Kite على تحقيقه، مع أن الاختبار الحقيقي سيكون مدى كفاءة هذه الضوابط عمليًا.
لا ينبغي قياس مستقبل الذكاء الاصطناعي المستقل بمقدار الحرية التي نمنحها للوكلاء، بل بمدى ذكائنا في تحديد الحرية التي يحتاجون إليها.