هذه الوثيقة هي تقرير عميق من إنتاج OKX Ventures. نظرًا لطول المحتوى، سيتم نشره في جزئين: الجزء الأول يركز على الخلفية الكلية، بروتوكول x402، ERC-8004 وبروتوكول Virtuals؛ الجزء الثاني سيحلل OpenClaw واتجاهات الصناعة بشكل عام، ترقبوا.
ملخص
يتطور AI Agent من مساعد سلبي إلى مشارك نشط في الاقتصاد. يتكون هذا التقرير من ستة فصول، ويستعرض بشكل منهجي البنية التحتية الأساسية للاقتصاد القائم على الوكلاء، انفجار التطبيقات وتطور الصناعة: تحليل على المستوى الكلي لتوقعات السوق والفجوات في البنية التحتية للتجارة الوكلائية؛ تحليل عميق على مستوى البروتوكول لثلاثة بروتوكولات تكميلية وهي x402، ERC-8004، وبروتوكول Virtuals؛ على مستوى التطبيق، يتم دراسة OpenClaw كحالة لدراسة المسار الحقيقي لاقتصاد الوكلاء؛ وأخيرًا، يتم تقديم تقييم شامل للصناعة من خلال أبعاد هيكل المنافسة، مسارات الدفع، التهديدات الأمنية ونماذج الأعمال.
تم تقديم x402 (طبقة الدفع) بواسطة Coinbase وCloudflare معًا. يتم تضمين المدفوعات الدقيقة بالعملات المستقرة في طبقة بروتوكول HTTP. وبنهاية 2025، تمت معالجة أكثر من 100 مليون معاملة، ووصل حجم الدفع السنوي إلى 600 مليون دولار.
ERC-8004 (طبقة الثقة) قدمته بالتعاون فرق dAI التابعة لمؤسسة Ethereum مع MetaMask وGoogle وCoinbase. يوفر لوكلاء AI ثلاث سجلات رئيسية على السلسلة: الهوية والسمعة والتحقق، وتم إطلاقه على الشبكة الرئيسية Ethereum في 29 يناير 2026.
يُنشئ Virtuals Protocol (الطبقة التجارية) منصة كاملة لتجارية الوكلاء، ويُمكّن عبر ACP التداول المستقل بين الوكلاء. تم نشر أكثر من 18,000 وكيل، وبلغت aGDP أكثر من 479 مليون دولار.
OpenClaw (طبقة التطبيق) طوّرها المطور النمساوي Peter Steinberger؛ خلال أربعة أشهر تجاوز 250 ألف+ GitHub Stars متفوقًا على React، ليصبح أسرع مشروع مفتوح المصدر نموًا في تاريخ GitHub. يقوم بإدماج AI «أصيل» داخل منصات الرسائل الموجودة لدى المستخدمين (أكثر من 20 منصة)، ويحفز مجتمع Crypto على بناء بنية تحتية اقتصادية on-chain بشكل تلقائي فوقه. هذا هو نموذج العينة الأساسي الذي يراقبه هذا التقرير لتفاعل الوكلاء مع بروتوكولات on-chain بشكل فعلي.
الفصل الأول: خلفية الاقتصاد الكلي
1.1 توقع حجم السوق
سوق Agentic Payment في مرحلة توسع سريع، ولدى عدة جهات توقعات متفائلة لحجم السوق:
1.2 فجوة البنية التحتية
البنية التحتية الحالية معادية لاقتصاد الوكلاء: OAuth يحتاج إلى نقر بشري، ونماذج بطاقات الائتمان تتطلب إدخالًا يدويًا، كما أن جزر البيانات تعيق الوصول الذاتي. يستطيع الوكيل التفكير والتنفيذ بشكل مستقل على «طبقة القدرة»، لكن على «طبقة الاقتصاد» ما يزال محبوسًا داخل البنية التحتية التي صُممت للإنسان (الهوية / التنسيق / النشاط الاقتصادي).
حاليًا تظهر مساران للتطور:
مسار امتثال مركزي: اتصال A2A + تكامل الأدوات عبر MCP + دفع AP2/ACP (برعاية OpenAI وStripe، وبالأساس Web2 خالص)
مسار لا مركزي غير مُرَخَّص: x402 + ERC-8004 /8183+ ACP (إطار تعاون الوكلاء)
1.3 خط زمني محوري
ملاحظة: حتى مارس 2026، انخفض متوسط عدد المعاملات يوميًا بشكل كبير من ذروة ديسمبر، وأكبر هبوط كان في مشاريع البنية التحتية (\u003e80%).
الفصل الثاني x402 بروتوكول: طبقة دفع الوكلاء
x402 هو بروتوكول دفع مفتوح المصدر يتيح، عبر إحياء رمز حالة HTTP 402، لأي طلب HTTP أن يحمل دفعًا بالعملة المستقرة بشكل أصلي، بحيث يستطيع وكيل AI إجراء صفقات pay-per-use بشكل فوري.
لا ينبغي فهم x402 على أنه مجرد بروتوكول دفع آخر. ما يمثله هو إعادة تصميم «الوحدة الأساسية للنشاط الاقتصادي»: من «التسجيل → المراجعة → التفويض → الاستخدام» إلى «الدفع → الاستخدام». x402 = «Swift للوكلاء».
تدور اقتصاديات واجهات API حاليًا اعتمادًا على افتراض ضمني: وجود بشر يتدخلون في المنتصف. عملية الحصول على API Key — تسجيل → إدخال البريد الإلكتروني → مراجعة → نسخ المفتاح → لصقه في الكود — تفترض وجود إنسان يشارك في كل خطوة. أما في اقتصاد الوكلاء فلا تعمل هذه السلسلة، لأن وكيل AI لا يمكنه أن يسجل بنفسه، يملأ الاستمارات، أو يتولى إدارة الـ Key. يستخدم x402 كود حالة HTTP 402 لتحقيق دفع مستقر/عملة مستقرة بشكل مستقر «أصلي». بعد أن يستقبل الوكيل رد 402، يدفع مباشرةً على السلسلة (USDC) ويأخذ إيصال/شهادة الدفع.
2.1 نظرة عامة على البروتوكول وسير العمل
الأدوار الأساسية
خطوات المعاملة الخمس
طلب موارد: يرسل العميل Client طلب HTTP معياري إلى خادم الموارد Resource Server (مثل GET /api/weather)
إرجاع عرض السعر: يعيد الخادم Server رمز الحالة HTTP 402، وتحتوي رؤوس الاستجابة على متطلبات دفع مُهيكلة (العملة، المبلغ، عنوان المحفظة، الشبكة)
الدفع المُوقَّع: يقوم Client ببناء وتوقيع تفويض الدفع باستخدام المفتاح الخاص للمحفظة، ثم يعيد إرسال حمولة payload الموقعة داخل رأس طلب X-PAYMENT
التحقق والتسوية: يقوم Server بإعادة توجيه معلومات الدفع إلى Facilitator للتحقق، وبعد تأكيد Facilitator يتم تنفيذ تحويل العملة المستقرة على السلسلة
تسليم الموارد: بعد تلقي التأكيد، يعيد Server البيانات/المحتوى/نتيجة الحوسبة إلى Client
يُنجز المسار الكامل من بدء الطلب إلى استلام الموارد خلال نحو ثانيتين
مقارنة مع طرق الدفع التقليدية
السمات الأساسية: لا حاجة لتسجيل حساب، ولا حاجة لـ API Key، ولا حاجة للاشتراك، ولا حاجة لتدخل بشري. يصبح الدفع طبيعيًا مثل إرسال طلب HTTP. وهذا بالضبط هو سبب تسميته «طبقة دفع أصلية للإنترنت».
2.2 بيانات محورية
إيضاح جودة البيانات: وفقًا لتحليل Artemis، في معاملات x402 تبلغ نسبة Real إلى Gamed قرابة 1:1 (مثل 520,000 Real مقابل 518,000 Gamed بتاريخ 2026.01.11)، ويجب فهم حجم الإنتاج الحقيقي العضوي على أنه مُخفَّض/مُخصَّم.
حسب توزيع السلسلة
تصنيف حسب الاستخدام (لقطة على السلسلة بتاريخ 2026.01.11)
2.3 ترتيب استخدام المشاريع الرئيسية (حتى مارس 2026)
مصدر البيانات: لوحة Dune Analytics الخاصة بـ x402 Transactions per Project
2.4 ترقية V2 الأساسية
هوية المحفظة + جلسات قابلة لإعادة الاستخدام
في V1، كل استدعاء لواجهة API يستلزم المرور الكامل عبر سلسلة معاملات on-chain. في V2 تم تقديم آلية Sign-In-With-X (SIWx): بعد تحقق الوكيل مرة واحدة من هوية المحفظة، يمكن إعادة استخدام الجلسة لاحقًا دون تأكيد على السلسلة في كل مرة. جوهريًا، يحول pay-per-call إلى نموذج اشتراك، ما يعالج عنق الزجاجة في الأداء في سيناريوهات الاستخدام عالي التكرار.
توحيد متعدد السلاسل + التوافق مع الدفعات التقليدية
قامت V2 بتوحيد طريقة تحديد الشبكات والأصول، وأنشأت تنسيق دفع موحد X402 يمكنه التشغيل ضمن مسارات دفع عبر السلاسل والدفعات التقليدية. تم إدراج Base وSolana وباقي L2 إضافةً إلى شبكات ACH وSEPA وشبكات البطاقات ضمن نموذج دفع واحد. هذه هي أهم ترقية: لم يعد x402 «بروتوكول دفع تشفيري»، بل صار طبقة دفع محايدة تربط بين Crypto والتمويل التقليدي.
اكتشاف الخدمة تلقائيًا
قدمت V2 توسعة Discovery؛ يمكن لخدمة x402 كشف بيانات وصفية مُهيكلة بحيث يقوم Facilitator بالزحف تلقائيًا لبناء الفهرس، ويمكن لوكلاء AI اكتشاف الخدمات تلقائيًا وفهم التسعير وبدء المدفوعات. وهذا مهم جدًا لاقتصاد الوكلاء — لا يحتاج الوكيل إلى معرفة مسبقة بواجهة الدفع لدى مزود الخدمة؛ بل يمكنه اكتشافها تلقائيًا أثناء التشغيل وإتمام الدفع.
مجموعة تطوير SDK نمطية/وحدوية
بنية قابلة للإضافة بنمط Plug-in: إضافة سلسلة جديدة كحزمة مستقلة لتقليل تكاليف الدمج. اقترحت Cloudflare مخطط الدفع المؤجل (deferred payment scheme)، بما في ذلك حل Circle Gateway، وما زال قيد التقدم.
2.5 الجهات المشاركة في النظام البيئي
المؤسسة وطبقة البروتوكول
2.6 بنية مكدس دفع الوكلاء
مقارنة تفصيلية للبروتوكول
رؤية محورية: ليس الهدف استبدال أحدهما بالآخر، بل كيفية دمجهما. تعاونت Google مع Coinbase لإصدار امتداد A2A x402، حيث تعتمد AP2 على x402 كمسار دفع تشفيري. الخطر الحقيقي للتنافس هو تفتت المعايير (standard fragmentation).
2.7 إشارات المخاطر الأساسية
انخفض حجم المعاملات اليومي من حوالي 731 ألف معاملة في ديسمبر 2025 إلى حوالي 57 ألف في مارس 2026 (-92%)، وبحجم معاملات حقيقي قرابة 14 ألف دولار/يوم (وفق معيار Artemis: في ذروة ديسمبر كان متوسط اليوم 250 ألف دولار، و95% منها كانت Gamed)
القيمة السوقية للنظام البيئي 7 مليارات دولار (LINK 6 مليارات + Virtuals 0.6 مليار)، والتقييم لا يتماشى بشكل خطير مع الاستخدام الفعلي
أكبر هبوط في أحجام استخدام مشاريع البنية التحتية: x402secure.com (-80%+)، AgentLISA (قريب من الصفر)، pay.codenut.ai (انكماش كبير)
تحليل الأسباب من ثلاث طبقات
الطبقة الأولى: اختفاء المحفزات. انفجار حجم المعاملات في الفترة من أكتوبر إلى ديسمبر 2025 نتج عن ثلاثة عوامل: موجة رموز meme، توقعات TGE لعدة مشاريع، وتنافس Facilitator على تحسين/مسح ترتيب Dune.
الطبقة الثانية: عدم تطابق جوهري بين العرض والطلب. المشكلة التي يعالجها x402 هي «استدعاء API بشكل مستقل من قبل وكيل AI لدفع تكاليفه»، لكن الغالبية العظمى من وكلاء AI ما يزالون يستدعون الخدمات عبر API Key + نموذج الاشتراك؛ كما أن الوكلاء الذين يمتلكون فعلًا قدرة اتخاذ قرار اقتصادي مستقل نادرون جدًا في الصناعة؛ وبائعون على استعداد لتلقي USDC «حسب كل مرة» (pay-per-use) نادرون أيضًا. لقد تم إصلاح الطريق، لكن لم تُصنع السيارة بعد.
الطبقة الثالثة: تبريد شامل لسوق التشفير
أخبار إيجابية: دمج Stripe مع x402 حدث مهم. صرّح John Collison، المؤسس المشارك في Stripe، بأن «فيضان التجارة بالوكلاء» سيأتي خلال الأشهر والسنوات القادمة. وفي الوقت نفسه، تستعد Stripe لمسارين: ACP (مسار Web2 عبر بطاقات الائتمان) و x402 (مسار Web3 عبر العملات المستقرة)، ما يجعلها جهة متحوطه بين الطريقين.
أدى x402 إلى ظهور عدد من مشاريع الوسيطة (middleware) الجديدة؛ وهي في جوهرها تساعد الوكلاء على الحصول بشكل أكثر سهولة على مختلف الخدمات في ظل نمط «الدفع = التفويض». مسار دفع تشفيري مبرمج وغير مُرخَّص يعمل 7×24 ساعة هو الاختيار الطبيعي للوكلاء المستقلين. لكن الشرط هو أن الوكيل يحتاج فعلًا إلى «عدم الترخيص». فإذا كان الوكيل يعمل دائمًا ضمن نطاق تفويض البشر (المرحلة الثانية: وكلاء مُتحكَّم بهم)، فإن مسار الدفع التقليدي مع البطاقات الافتراضية يكفي. ولا يصبح «عدم الترخيص» ضرورة مُلحّة إلا عندما يبدأ الوكيل بمزاولة نشاط اقتصادي مستقل عن البشر (المرحلة الثالثة: اقتصاد مستقل).
علاوة على ذلك، هناك آلية chargeback في بطاقات الائتمان (يمكن للمستهلك الاعتراض على العملية واسترجاع الأموال)، وهذا ما بُنيت عليه حماية المستهلكين على مدى عقود. الدفع على السلسلة هو final settlement: عندما تدفع، تصبح العملية قد تمت ولا يوجد chargeback. وهذا يعني أنه إذا أخطأ الوكيل (مثل التعرض لهجوم prompt injection)، يمكن للمستخدم في نظام بطاقات الائتمان الاتصال بالبنك لاسترجاع الأموال. أما في حل x402، فقد أصبحت الأموال على السلسلة ولا يمكن استعادتها. وهذه هي الخسارة/العيب الحقيقي لـ x402 مقارنة بالدفع التقليدي.
احتكاكات كثيرة تنشأ لأن البشر يعملون كـ «وسيط بشري/إنسان-برمجي (human middleware)» ينتقلون بين أنظمة مختلفة لتشغيل العملية. إن آليات بناء الثقة — مكافحة الاحتيال، التحكم بالوصول، المساءلة، حل النزاعات، توثيق التدقيق — هي ما يحافظ على عمل النظام التجاري.
قد يكون اتجاه الحل هو آلية escrow على السلسلة (قفل الأموال في عقد ذكي أولًا، ثم إطلاقها بعد تأكيد تسليم الخدمة)، أو بروتوكولات تأمين (توفير تأمين لمعاملات الوكلاء)، أو نظام سمعة 8004 لتقليل احتمالية التعامل مع أطراف غير موثوقة. لكن هذه الأمور حتى الآن ليست ناضجة.
2.8 منظور استثمارات VC
اتجاهات استثمارية جديرة بالاهتمام
مزود خدمة API ذات احتياج فعلي للدفع (البائع): تحليل بيانات / استخراج صفحات / Oracle / تدقيق أمني / استدلال مدفوع / امتثال KYC… معيار الحكم: يمكن تحقيق الربح بالنموذج التقليدي أيضًا، وx402 يضيف فقط قناة توزيع إضافية
حل النزاعات وطبقة ضمان الدفع Gateway: لا يمكن التراجع على السلسلة (on-chain) أو إجراء chargeback للمعاملات الكبيرة تتطلب آلية لمعالجة النزاعات. أمثلة مشاريع: Circle Gateway (إيداعات غير مُدارة/غير custodial مسبقة + تسوية دفعات كبيرة على نحو غير تتابعي/بالدفعات off-chain)، Kamiyo (سمعة الوكيل / احتجاز الأموال / حكم شبكة الأوراكل / تحكيم عبر ZKP)
أدوات Dashboard / FinOps: تساعد الشركات على إدارة إنفاق عدة وكلاء (كم أنفقت / أين أنفقت / هل كان يستحق / كيف توفر)، على غرار أدوات CloudHealth/Cloudability في الحوسبة السحابية، مع مقارنة بسعة استحواذ شركات كبرى تبلغ 3–5 مليارات دولار
الفصل الثالث ERC-8004: طبقة ثقة الوكلاء
ERC-8004 هي مجموعة من معايير التنسيق على السلسلة. من خلال ثلاث سجلات رئيسية: Identity وReputation وValidation، تُنشئ إطار اكتشاف وتفاعل بين الوكلاء دون الحاجة إلى ثقة مباشرة.
3.1 نظرة عامة على المعيار والتمييز الجوهري
في التفاعلات التقليدية، غالبًا ما تُقيَّد تفاعلات الوكلاء بسبب الحاجة إلى تأسيس علاقة ثقة مسبقة أو الاعتماد على جهات طرف ثالث، وبالتالي تظل غالبًا ضمن النظام البيئي نفسه. في بيئة مفتوحة، يتمثل السؤال الجوهري في: كيف يكتشف الوكيل شركاء التعاون، ويطلع على الأداء التاريخي، ويتحقق من الموثوقية؟
تمييز مهم: ERC-8004 ليس Token. فهو يستخدم تمثيل هويات الوكلاء داخل ERC-721 كـ NFT، لكن معيار التنسيق والثقة بحد ذاته لا يحمل قيمة اقتصادية ولا يكون قابلاً للتداول.
3.2 ثلاثة سجلات رئيسية
Identity Registry (سجل الهوية)
بناءً على ERC-721 + URIStorage: يحصل كل Agent على هوية مُعرّفة عبر NFT، ويرتبط agentURI يشير إلى ملف التسجيل (JSON) يتضمن الاسم والوصف ونقاط النهاية الخاصة بالخدمات (A2A/MCP/Web) وحالة دعم x402… يمكن تخزين URL في IPFS (لا مركزي ومقاوم للرقابة)، أو في خادم HTTPS (بسيط لكنه مركزي)، أو ترميزها مباشرة على السلسلة (الأكثر لا مركزية لكن التكلفة أعلى).
سجل السمعة (Reputation Registry)
إصدار واجهات معيارية وإشارات للحصول على ملاحظات/تغذية راجعة، مع دعم التقييم على السلسلة والخوارزميات خارج السلسلة. يمكن إرفاق proofOfPayment الخاص بـ x402 كإشارة دعم ائتماني/اقتصادي. يقوم الوكلاء بتقييم بعضهم البعض، لكن لمنع الاحتيال في التقييمات، يلزم ERC-8183 لإثبات أن هناك تفاعلًا حقيقيًا للوظائف (Jobs) بين الوكلاء.
Validation Registry (سجل التحقق)
إدخال TEE (بيئة تنفيذ جديرة بالثقة)، وآلية رهن PoS، وZK (إثباتات معرفة-صفرية)، للتحقق من مخرجات المهام التي يتعامل معها الوكيل وتوثيقها عبر:
من خلال TEE: تنفيذ المهام القابلة للتحقق داخل صندوق أسود آمن، دون أن تتمكن الجهات الخارجية من مراقبة/تسريب أو العبث بالشفرة والبيانات
من خلال PoS: يجب على المدققين رهن الأصول للمشاركة في تنفيذ المهام، وإذا تصرفوا بسوء يتم سحب الرهن/مصادرته
من خلال ZK: يمكن التحقق من صحة عملية استدلال الوكيل دون معرفة أوزانه الداخلية
3.3 معالم التطور
الداعمين: ENS وEigenLayer وThe Graph وTaiko. حوالي 1000–2000 مطور انضموا.
لكن حدود 8004 الحالية يعترف بها Crapis نفسه: «8004 جوهريًا هي مجموعة من السجلات». إنها تعطي الوكيل بطاقة هوية وتوفر آلية تقييم، لكنها لا تضمن أن سلوك الوكيل موثوق. التحقق الحقيقي يحتاج إلى تدقيق السلوك (ما الذي فعله الوكيل في الماضي)، وإثبات بيئة التنفيذ (الأدلة التي تعمل داخل TEE)، والتحقق من النوايا (أن الوكيل يدّعي أنه سيفعل X لكنه فعليًا نفّذ X). جزء Validation Registry الخاص بـ TEE ما يزال قيد نقاش مجتمع المطورين، ولم يكتمل بعد وهو بعيد عن النضج.
بعبارة أخرى: 8004 شرطٌ لازم لكنه ليس شرطًا كافيًا. إنه يحل مسألة «من هو هذا الوكيل؟» لكنه لم يحل بعد مسألة «هل هذا الوكيل موثوق؟». التحقق يحتاج إلى مجموعة من 8004 + TEE + تدقيق السلوك، وحاليًا لا يوجد من ينفذ هذا المزيج كاملًا.
بالطبع، هناك اتجاه آخر لم يُمنح حقه من التقدير: في الاقتصاد البشري، يُبنى نظام الائتمان على الميزانيات (قائمة الأصول والخصوم) وسجل الائتمان — كم لديك من المال، وكم من القروض سددتها في الماضي. الوكلاء لا يملكون هذا، لكن لديهم بيانات سلوكية: كم مهمة نفذها في الماضي، ما معدل النجاح، ما متوسط زمن الاستجابة، وهل تم تقديم شكاوى ضده. إذا تحولت البيانات السلوكية إلى «بدائيات مالية» (financial primitives)، فإن نظام سمعة 8004 لن يكون مجرد تقييمات جيدة/سيئة، بل سيصبح «تصنيف ائتمان» لعالم الوكلاء. يمكن لوكيل عالي السمعة الحصول على حد ائتمان أعلى (تفويض مسبق بمبالغ أكثر)، وتكلفة معاملات أقل (لأن المخاطر أقل)، وتوزيع أول للمهام (يختار أصحاب العمل عادةً الوكلاء ذوي السمعة الأفضل).
سجل الهوية والسمعة لـ 8004 مجرد طبقة بيانات أساسية. القيمة تُخلق في قدرة من يستطيع بناء تقييم ائتمان الوكلاء والخدمات المالية فوق طبقة البيانات هذه — قروض الوكلاء، تأمين الوكلاء، حدود الائتمان للوكلاء… أي أن الأمر يتعلق بإجمالي حزمة الخدمات المالية (financial services stack).
3.4 العلاقة مع البروتوكولات الأخرى
3.5 ERC-8183: معيار Ethereum لـ ACP
ERC-8183 هو نسخة معيارية مفتوحة على Ethereum لبروتوكول ACP الداخلي لدى Virtuals (تم إصداره بتاريخ 10 مارس 2026، وهو حاليًا في مرحلة Draft).
المبدأ/البدائي الأساسي هو Job — آلة حالة على السلسلة (Open → Funded → Submitted → Completed/Rejected/Expired). تُدار الأموال عبر Escrow قابل للبرمجة، ويتم إجراء تسوية تلقائية بعد أن يقوم Evaluator مستقل بالتحكيم في جودة التسليم. يدعم Hooks لتوسعات مثل عتبة السمعة، والمزايدة، ودفع على مراحل (milestone payments) وغيرها.
تصميم محوري: عند اكتمال كل Job يتم تلقائيًا إنشاء سجل تفاعلات وإطعامه إلى ERC-8004 ضمن Reputation Registry — على غرار أن «التقييمات في أماكن مثل Yelp/Tripadvisor يجب أن تتم بعد الاستهلاك»، مع إضافة «قاضٍ/طرف ثالث محكِّم». هذه هي نقطة الربط التي تجعل 8183 و8004 يخلقان حلقة تكافلية (symbiotic loop).
الفصل الرابع Virtuals Protocol: الطبقة التجارية لوكلاء
4.1 نظرة عامة على المشروع
Virtuals Protocol هو بنية تحتية شاملة لا مركزية لوكلاء AI من الطرف إلى الطرف (full-stack)، تتيح لأي شخص إنشاء وكلاء AI مستقلين على السلسلة، وترميزهم (tokenize)، والامتلاك المشترك، وتحقيق عائد من بيع قدرتهم/منتجاتهم. تم تأسيس المشروع أولًا في 2021 باسم PathDAO (نادي/نقابة ألعاب)، ثم تحوّل بداية 2024 إلى اتجاه وكلاء AI؛ ويجري تشغيله حاليًا بشكل أساسي على Base، مع توسع إلى Ethereum وSolana وRonin.
الفريق الأساسي: المؤسسون Jansen Teng (سابقًا مستشار BCG، حاصل على بكالوريوس في التكنولوجيا الحيوية + إدارة الأعمال من كلية الإمبراطورية تشينج للعلوم والتكنولوجيا) وWeekee Tiew (بكالوريوس في التكنولوجيا الحيوية من الإمبراطورية كوليج + ماجستير إدارة من كلية لندن للأعمال، خلفية PE/BCG). المقر في كوالالمبور، ماليزيا، وعدد أعضاء الفريق قرابة 38. سجل التمويل: مرحلة PathDAO seed بقيمة 16 مليون دولار (DeFiance Capital، بقيادة مشتركة Beam).
4.2 البنية التقنية: أربع ركائز
الركيزة الأولى: إطار GAME — كيف يتخذ وكيل واحد قراراته داخليًا
GAME هو الدماغ: تثبّت هدفًا وشخصية وقدرات إدراك وإجراءات قابلة للتنفيذ على وكيل ما ليتمكن من التخطيط بشكل مستقل «ماذا سأفعل في الخطوة التالية»، ثم تقسيم المهام إلى Workers داخليين لتنفيذها. وتحدث العملية كلها داخل حدود وكيل واحد.
نواة البنية: بنية تخطيط طبقية (Hierarchical Planning) تفصل «التفكير» عن «طريقة التنفيذ». يقوم Task Generator (مخطط عليا/HLP) بتوليد مهام بناءً على أهداف الوكيل واختيار Worker؛ بينما يمتلك Workers (مخطط سفلي/LLP) مجموعة Functions قابلة للتنفيذ ضمن تخصصاتهم؛ وتنفذ Functions استدعاءات API محددة، معاملات on-chain، واسترجاع البيانات…
يدعم نموذج القاعدة: Llama 3.1 405B (افتراضيًا)، Llama 3.3 70B، DeepSeek R1، DeepSeek V3 — تصميم مستقل عن النموذج. مع إصدار OpenAI/Google لإطارات وكلاء، لا يتبقى من تمييز GAME سوى نقطة واحدة: إنه الإطار الوحيد الذي يتكامل أصليًا مع طبقة الاقتصاد على السلسلة (ACP + رموز VIRTUAL).
الركيزة الثانية: ACP — «قانون التجارة» بين الوكلاء
بروتوكول Agent Commerce (ACP) هو بروتوكول مُوحَّد على السلسلة يتيح لوكلاء AI اكتشاف بعضهم، وتوظيفهم، والتفاوض معهم، وحجز الأموال (escrow) وإتمام التسليم والتسوية — طوال الوقت دون تدخل البشر.
آلة حالات ACP ذات أربع مراحل
الركيزة الثالثة: Butler — المدخل الفائق للمستخدمين
Butler هو بوابة المستهلكين في شبكة ACP — وهو وكيل مبني على LLM، وبشكل أساسي منسق/أوركسترتر لبروتوكول ACP. وظيفته تحويل اللغة الطبيعية للمستخدم إلى سير عمل (workflows) على السلسلة لتعاون متعدد الوكلاء.
Butler عبارة عن بنية من طبقتين: الطبقة السطحية هي واجهة حوار LLM (الواجهات الخلفية الحالية: Gemini 3 Pro)؛ والطبقة السفلية هي منسق بروتوكول ACP الذي ينفذ دورة كاملة: اكتشاف الوكيل → تأكيد التسعير → قفل Escrow → توجيه المهمة (task routing) → التحقق من التسليم → إطلاق الأموال. ما يراه المستخدم هو الدردشة، لكن Butler يقوم بتنسيق العقود.
وضع Butler Pro يفصل بوضوح التخطيط عن التنفيذ: مرحلة التخطيط → مرحلة المراجعة (يمكن للمستخدم تحسين الخطة) → مرحلة التنفيذ (تنسيق مستقل لكل دورة العمل). القدرات المضمنة تشمل Token Swap وDCA والاستثمار بالتقسيط، وعقود الدوام/العقود الدائمة، وFund of Funds.
الركيزة الرابعة: منصة الإطلاق — وول ستريت للوكلاء
نظام إطلاق من ثلاث طبقات يغطي دورة حياة مشاريع الوكلاء كاملة من 0→1→100:
مشروع الإطلاق الأول من Titan: XMAQUINA ($DEUS، DAO تمتلك حصصًا في شركات ذكاء جسدي مثل Figure AI، $60 مليون FDV)، Fabric Foundation ($ROBO، بالشراكة مع OpenMind لاقتصاد روبوتات)
4.3 تحليل Agentic GDP (aGDP)
aGDP (Agentic Gross Domestic Product) هو مؤشر بيئي أساسي مُخصص من Virtuals، يقيس القيمة الاقتصادية الإجمالية التي يخلقها كل الوكلاء المستقلون في البيئة عبر الخدمات والتنسيق والأنشطة على السلسلة.
مسار نمو aGDP
مشكلة جودة aGDP — ثلاث إشارات تحذير:
تقلب الإيرادات يكشف اعتمادًا على المضاربة: إيراد يوم بروتوكول في يناير 2025 بلغ 1.02 مليون دولار → نهاية فبراير 3.5 آلاف دولار (-97%). الإيرادات تأتي أساسًا من ضريبة تداول Agent Token (1%)، وليس من الدفع المستمر مقابل خدمات الوكيل.
تركيز شديد في القمة: يساهم Ethy AI بوكل واحد بقيمة 218 مليون دولار من aGDP (أي 45.5% من إجمالي النظام)، وثلاثة الأوائل مجتمعة 407 ملايين دولار (84.9%). هؤلاء الثلاثة جميعهم وكلاء من نوع تنفيذ الصفقات؛ وaGDP في جوهرها عبارة عن تدفقات معاملات تم التعامل معها، وليست عائدًا من خدمات الوكلاء. Luna كهوية/علامة رئيسية من نوع IP، تصل take rate لديها إلى قرابة 100%؛ أما take rate لدى Ethy AI فهو 0.26% فقط.
افتراض هدف 3 مليارات دولار: من 470 مليون إلى 3 مليارات يتطلب نموًا بمقدار 6.4 أضعاف. إذا كان المحتوى المضاربي في aGDP هو المسيطر، فإن الهدف يراهن جوهريًا على سخونة سوق Agent Token، لا على نمو عضوي لأعمال الوكلاء.
4.4 نموذج اقتصاديات الرموز
آليات التقاط قيمة رباعية عبر $VIRTUAL
هيكل الضرائب في ACP: المستخدم يدفع 100% → محفظة Agent تحصل على 90% (قابلة للسحب أو لإعادة توظيف وكلاء آخرين؛ وبما يخلق aGDP مركب على السلسلة) + الخزانة 10% (منها 1% يتدفق إلى G.A.M.E Treasury) → إعادة شراء مستمرة لـ Agent Token من إيرادات الخزانة، لمحاذاة الحوافز طويلة الأجل.
هيكل الإمداد: إجمالي 1 مليار VIRTUAL (10^9)، مع إمداد ثابت دون تضخم ابتدائي؛ الحالة الحالية: تم فك كل الإمداد للتداول؛ الزيادة المحتملة: خلال السنوات الثلاث القادمة بحد أقصى 10% سنويًا، بشرط موافقة الحوكمة؛ veVIRTUAL: يتيح التّحصيل عبر الرهن حقوق التصويت في الحوكمة + حقوق تخصيص (Airdrop) في Agent Token.
4.5 نظرة عامة على بيانات النظام البيئي
مثال وكيل مرجعي
4.6 المشهد التنافسي والحواجز
طبقة الحواجز (من الأقوى إلى الأضعف)
تأثيرات الشبكة + عجلة الرموز (الأقوى): أكثر من 18,000 وكيل + أكثر من 650,000 حامل يشكلون سوقًا ثنائي الجانب. كل وكيل يفرض اقترانًا (pairing) مع VIRTUAL مما يخلق حلقة تغذية راجعة إيجابية. هذا لا يمكن نسخه بإطار مفتوح المصدر — LangChain لا يمتلك طبقة تسوية اقتصادية بين الوكلاء بشكل أصلي.
سلطة تحديد المعايير (قوية نسبيًا): ACP → ERC-8183 (نُشرت بالتعاون مع مؤسسة Ethereum) + ERC-8004 + x402؛ الثلاثة معًا تتنافس على «المنظومة القانونية الأساسية» لاقتصاد وكلاء AI.
ميزة السبق + العلامة التجارية (متوسطة): لدى مسار AI Agents + Crypto Mindshare قيادي؛ مع شهادات من جهات مثل Grayscale وFundstrat.
القدرة التقنية (الأضعف): لدى بنية طبقية لـ GAME ميزة تصميمية، لكنها تعتمد على LLM طرف ثالث، ولا تملك نموذجًا مُطوَّرًا ذاتيًا؛ كما أن طبقة التخطيط/التنسيق يمكن استبدالها بسهولة بإطار أقوى.