في السنتين الماضيتين تم الحديث عن وكلاء الذكاء الاصطناعي بشكل مفرط.
العديد من المشاريع عندما تبدأ، تقول إن الذكاء الاصطناعي يمكنه مراقبة السوق، ووضع استراتيجيات، وإدارة الأصول، وتنفيذ العمليات على السلسلة. يبدو الأمر سهلاً، حتى مغريًا بعض الشيء.
لكن الآن عندما أسمع مثل هذه الأقوال، ردة فعلي الأولى ستكون أكثر حذرًا.
لأنه بمجرد أن يبدأ الوكيل في التعامل مع الأصول على السلسلة، تتغير الأمور على الفور.
لم يعد مجرد صندوق دردشة، ولم يعد مجرد أداة اقتراح. بمجرد دخوله إلى المحفظة، وعبر السلاسل، واستدعاء العقود، ومسارات التداول، وتنفيذ الاستراتيجيات، ما يهم حقًا ليس مدى ذكائه في الإجابة، بل ما الذي يُسمح له بفعله.
قضية حدود الصلاحيات، غالبًا أهم من الذكاء بحد ذاته.
عندما كنت أعمل على منتجات مالية لـ Web2، كان لدي انطباع عميق جدًا عن نظام الصلاحيات. ففي الخلفية الداخلية، قد يبدو الأمر مجرد بضعة أزرار، لكن خلفها في الواقع كل شيء عبارة عن جداول صلاحيات: من يمكنه رؤية البيانات، من يمكنه تعديل الحدود، من يمكنه الموافقة، من يمكنه إرسال الأموال، ومن يمكنه الاستعلام فقط دون إجراء عمليات. هذه الأمور يجب تفكيكها بدقة بالغة.
إذا كان تصميم الصلاحيات غير دقيق، فلن ينفع أن تكون صفحة الواجهة الأمامية جميلة جدًا.
لأن المشكلة الحقيقية عندما تقع، لن تبقى عند "تجربة سيئة". بل ستصبح: من الذي منح التفويض؟ من الذي قام بالعملية؟ وأي مرحلة حدث فيها تجاوز للصلاحيات؟ ولماذا لم يتم منع ذلك.
عالم السلسلة أكثر مبالغة.
قد يؤدي تفويض واحد وتوقيع واحد وجسر عبر السلاسل وتفاعل عقد واحد إلى تغييرات فعلية في الأصول. وبعد تنفيذ العديد من الإجراءات، يصبح من الصعب جدًا التراجع عنها كما هو الحال في خوادم Web2.
لذلك اليوم عندما أنظر إلى @OpenLedger الخاصة بـ OctoClaw وTrading Agent، فأكثر ما يهمني ليس ما إذا كان بإمكانهما توفير الوقت للمستخدمين، بل ما إذا كان بإمكانهما معالجة الأمور الثلاثة: الصلاحيات والتنفيذ والسجلات بشكل واضح.
تذكر المواضيع الموصى بها رسميًا OctoClaw وTrading Agent وcloud config وEVM Bridge وERC-4626 integration. وعندما تنظر إليها معًا، فإنها تشير كلها إلى اتجاه واحد: ليس الـ AI Agent مجرد محادثة معك، بل يجب أن يدخل في سير عمل فعلي على السلسلة.
بمجرد تحقق هذه الفكرة، تصبح منظومة الصلاحيات هي أساس البناء.
عندما يقول المستخدم جملة: "ساعدني في تحسين الاستراتيجية"، فهذه الجملة نفسها غامضة جدًا.
هل يمكن للوكيل فعلًا استخدام الأموال؟
هل يمكنه عبور السلاسل؟
هل يمكنه استدعاء عقد معيّن؟
هل يمكنه الوصول إلى vault معيّن؟
هل يمكن إيقاف التصرف في ظروف السوق المتطرفة؟
كل خطوة يجب تفكيكها إلى صلاحيات محددة، وليس إعطاء باقة تفويض كبيرة وعامة.
وهذا أيضًا ما أعتقد أن قدرة OpenLedger على السجلّات على السلسلة تستحق أن تُنظر إليها.
تشدد المواد الرسمية لـ OpenLedger على أن نظامه سيحتفظ بسجلات حول البيانات والنماذج واستدعاءات الاستدلال وإسناد المساهمات والحوكمة. كما يذكر الكتاب الأبيض أن النماذج يمكن ربطها عبر API وأطر عمل الـ Agent لتصبح محركات لاتخاذ القرار داخل التطبيقات اللامركزية.
وهذا يوضح أنه لا يريد التعامل مع أداة واحدة فقط، بل مع علاقة السجلات الكاملة بعد دخول الـ AI إلى التطبيق.
إذا شارك وكيل فعلًا في التنفيذ على السلسلة مستقبلًا، فعلى الأقل يجب أن يجيب عن عدة أسئلة.
أولًا، أي نموذج يستدعي؟
ثانيًا، ما البيانات أو الإشارات التي استخدمها؟
ثالثًا، حسب أي قواعد يولد الإجراء؟
الرابع: في أي خطوة منح المستخدم التفويض؟
خامسًا، هل يمكن مراجعة نتيجة التنفيذ لاحقًا؟
إذا لم تُحل هذه المشاكل، فكلما كان الـ Agent أذكى، زادت المخاطر بدلًا من أن تقل.
لأن أكثر ما يخيف في وكيل "صندوق أسود" ليس أنه لن يفعل شيئًا، بل أنه عندما ينتهي ويفعل، لن تعرف لماذا فعل ذلك على هذا النحو.
في سيناريو المحادثة العادية، إذا أجاب الـ AI خطأ، فعلى الأكثر ستطلب مرة أخرى.
في سيناريوهات الأصول على السلسلة، إذا أخطأ الـ AI في استخدام الصلاحيات، فقد تظهر النتيجة مباشرةً في الرصيد.
لذلك لدي حكم أساسي دائمًا على منتجات مثل Trading Agent: لا ينبغي تغليفها كأدوات لكسب المال تلقائيًا.
مكانه الأكثر منطقية هو تحويل عمليات معقدة وعالية التردد وسهلة الخطأ إلى شيء أوضح، بحيث يمكن للمستخدم إدارة القواعد والتفويض والتنفيذ والمراجعة بشكل منفصل.
بعبارة أخرى، يجب ألا يجعل الوكيل الجيد المستخدم يسلّم المفتاح وهو مغمض العينين.
يجب أن يجعل الوكيل الجيد الناس يعرفون أي باب تفتح كل مفتاح.
من هنا أيضًا يمكن رؤية مكان $OPEN.
وفقًا للمواد الرسمية، سيتم استخدام $OPEN في gas والعمليات الشبكية وتسجيل النماذج واستدعاءات الاستدلال والوصول إلى خدمات الذكاء الاصطناعي وstaking والحوكمة. وفي سيناريو الوكيل، قد لا يقتصر دوره على رسوم المعاملات فقط، بل يشمل استدعاء النماذج وسجلات التنفيذ والوصول إلى الخدمات والمشاركة في الحوكمة.
وهذا يجعل استخدام $OPEN أكثر تحديدًا من مجرد عملة سردية عادية.
لكن هذا يفرض مطلبًا: يجب أن يحدث الاستدعاء الحقيقي.
إذا كان الـ Agent يكتفي بالبقاء في صفحة ترويجية، فهذه الاستخدامات كلها تكون مجرد تصميم على الورق. لا يمكن أن يرى السوق دور $OPEN إلا عندما يكوّن المستخدمون فعلًا مهام عبر OctoClaw أو أدوات ذات صلة، ويدعون النماذج، ويُطلقون عمليات على السلسلة، وينتجون سجلات تنفيذ يمكن الرجوع إليها.
لذلك اليوم عندما أنظر إلى @OpenLedger، سأركز على عدة متغيرات.
هل لدى OctoClaw في المستقبل مهام يتم تكوينها بواسطة مستخدمين حقيقيين؟
هل يمكن عرض سجل تنفيذ Trading Agent بشكل واضح؟
هل حدود صلاحيات الـ Agent دقيقة حتى إلى مستوى كل إجراء محدد؟
بعد دمج وحدات مثل EVM Bridge وERC-4626، هل يمكن إدارة مسارات الأصول المعقدة بأمان؟
هل توجد استخدامات حقيقية لاستدعاء النماذج والدفع مقابل الاستدلال؟
هذه المؤشرات أهم من مجرد ترديد عبارة "AI Agent".
في النهاية، في موضوع AI Agent، ليس بالضرورة أن يكون من يجيد الكلام مثل البشر هو الأهم، بل من يمكنه التعامل جيدًا مع الصلاحيات والسجلات والمسؤولية في سيناريوهات الأصول الحقيقية.
إذا أراد OpenLedger أن يدخل الـ Agent فعليًا في سير عمل على السلسلة، فلا بد أن يصلح هذه البوابة أولًا.
إذا لم تكن البوابة مستقرة، فكلما ركضت أسرع لاحقًا، زادت المخاطر.