بعد المدفوعات، ساحة المعركة التالية لاقتصاد الوكلاء: أسواق المهام

PanewslabPanewslab

بقلم: Delphi

ترجمة: AididiaoJP، Foresight News

 

بعد عامين من النقاش حول اقتصاد الوكلاء، أصبحت المدفوعات أول مجال نضج. Stripe مكّن الوكلاء من الدفع للتجار، وx402 من Coinbase وفّر قناة تسوية بالعملات المستقرة، وأصبح شراء البيانات وخدمات الاستدلال بالدفع لكل استخدام أمرًا واقعًا. لكن بمجرد أن تتجاوز المهمة "استدعاء واجهة برمجة التطبيقات (API) مرة واحدة"، تتغير المشكلة: لا يستطيع الوكيل الذكي (AI agent) إنجازها بمفرده، ويحتاج إلى الاستعانة بمصادر خارجية لبعض الخطوات والتأكد من أن الطرف الآخر أنجز العمل المتفق عليه فعلًا.

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

 

شراء المدخلات ليس كشراء النتائج

عندما يفحص المؤجر المستأجرين المحتملين، يمكن للوكيل سحب تقارير الائتمان وسجلات الإخلاء من مزود خدمة جاهز. يعيد الطرف الآخر مواد قياسية، ويبني المؤجر قراره عليها. هنا يكون المشترى مدخلات للقرار، وتبقى نهاية المهمة بيد المؤجر.

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

النموذج الأول أقرب إلى نموذج الدفع لكل استخدام الحالي: السعر واضح، والمُخرَج موحد، والتحقق شبه تلقائي. أما الثاني فيشتري إنجاز أمر كامل. تقديم المستندات لا يعني أن القضية جاهزة، والإيصال لا يعني القبول. يجب ربط شروط الدفع بـ"نتيجة قابلة للتحقق"، لا بما "يدّعي الطرف الآخر أنه فعله".

هذا هو الخط الفاصل بين سوق المهام وسوق واجهات برمجة التطبيقات التقليدي: سوق الواجهات يبيع الاستدعاءات؛ وسوق المهام يبيع وحدات إنجاز مؤكدة.

 

إذا لم تُعرَّف المهمة بوضوح، يتعذر على السوق العمل

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

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

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

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

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

 

المدفوعات تحل الدفع فقط، والتوظيف ما زال يفتقر إلى التحقق

بين إرسال المال وتكليف شخص بمهمة، توجد مراحل الإيداع الضماني والتسليم والتحقق والاعتراض. Stripe وx402 يغطيان النصف الأول فقط. ما زال الوكيل بحاجة إلى العثور على شخص يقدم الاعتراض ويمثل المالك. بدون تحقق، كلما أصبح الدفع أسهل، زادت سرعة مرور الطلبات الخاطئة.

المنتجات الحالية مصممة وفق هذا الهيكل.

في "TaskMarket" من Daydreams، يصدر المشتري الطلب ويتقدم الوكيل لقبول الطلب. يودع المشتري الأموال أولًا، ويمكنه السماح للعامل بالمطالبة المباشرة أو مراجعة المقترحات قبل الاختيار. تبقى الأموال في حساب ضمان، ولا تُصرف إلا بعد قبول التسليم.

في "Agent Commerce Protocol" من Virtuals، يتفق الوكيل المكلف والوكيل المنفذ على المهمة، وتدخل الأموال في حساب ضمان، وتُصرف بعد التسليم واجتياز الموافقة. يمكن أيضًا إضافة مقيمين خارجيين للتحقق من مطابقة النتائج للاتفاق المسبق. وعلى جانب NEAR (منصة بلوكتشين)، يجري دمج المهام والميزانيات والعطاءات والتحقق في عملية واحدة، والاتجاه نفسه هو "تسعير المهمة المنجزة"، لا تسعير الاستدعاء الواحد فقط.

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

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

 

خطوة إضافية واحدة تضخم الأخطاء

طُرحت أسواق المهام ليس فقط لأن الاستعانة بمصادر خارجية تبدو متقدمة، بل لأن العمليات متعددة الخطوات تضخم الأخطاء. في مهمة من عشر خطوات، إذا كانت دقة كل خطوة 95%، فإن احتمال إتمامها كلها دون خطأ يبلغ نحو 60% فقط. ومع كل تسليم دون تحقق، تنتقل الأخطاء السابقة إلى الخطوة التالية.

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

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

 

ما نراه الآن هو الهيكل، لا الحجم

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

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

إذا اجتمعت هذه الثلاثة، سيتمكن الوكيل من إنجاز المهمة، بدلًا من إنجاز نصفها ثم استدعاء المستخدم ليواصل لعب دور مدير المشروع.

هذا المحتوى لأغراض معلوماتية وتعليمية فقط، ولا يمثل نصيحة استثمارية تتعلق بـ BTCC. تبذل BTCC قصارى جهدها ولكنها لا تضمن صحة أو دقة أو أصالة المحتوى المذكور أعلاه.

موصى بها

من مساعد تدريس في جامعة نيويورك إلى قلب البيت الأبيض: مؤسس تشين لينك لم يسلك أي طريق مختصرإيثريوم تستهدف 6 أكتوبر لتفعيل غلامستردام على سيبيولياسردية جديدة من Hyperliquid: انطلاق HIP-4 رسميًاقانون الوضوح يضيف قواعد جديدة للتمويل اللامركزي قبل تصويت مجلس الشيوخإحياء نظام Solana: Pump.fun تدخل ساحة أزواج Meme بين العملات والأسهم