بعد فترة من السكون، أصدر "السرطان" OpenClaw الإصدار 2.0 في 30 أغسطس.
وفقًا للبيان الرسمي، فإن هذه هي أكبر تحديث في تاريخ OpenClaw، مع أكثر من 16,000 Pull Request مجمعة، تلامس تقريبًا كامل ترسانة المنتج، بما في ذلك التثبيت والرسائل والذاكرة والمهارات والنماذج والأتمتة والمتصفح والتطبيقات الأصلية والإضافات وآليات الأمان.
لكن ما يجدر الانتباه إليه أكثر من قائمة الوظائف المعقدة هذه هو المسار التدريجي الأوضح خلف OpenClaw 2.0: حيث يصبح الوكلاء أكثر قدرة على "القيام بالمهام" فعليًا.
في الوقت نفسه، فإنه يضع الصناعة أمام معضلة ثقة لا مفر منها: عندما تصبح الوكلاء قادرة بشكل متزايد على اتخاذ قرارات مستقلة بشأن "كيفية القيام بذلك"، كيف يمكننا ضمان أن كل عملية حاسمة تقوم بها لا تتجاوز الحدود التي وافق عليها المستخدم حقًا؟
أولاً: معضلة الاستقلالية الكاملة للوكيل: التفويض الكامل أم التأكيد المتعدد المستويات؟
في العام الماضي، لم يكن التغيير الأبرز في وكلاء الذكاء الاصطناعي هو فقط أن النماذج الأساسية أصبحت أكثر ذكاءً.
مع نضج البنية التحتية مثل MCP وSkills وPlugins وتحكم المتصفح وتنفيذ التعليمات البرمجية، يكتسب الوكلاء越来越多 من "الأطراف" الحقيقية التي يمكنها التأثير على العالم الخارجي، مثل تعديل المعلومات أو النقر على الأزرار أو التحكم المباشر في المتصفح من خلال استخدام الكمبيوتر (اقرأ المزيد في "هل وصل الذكاء الاصطناعي الوكيلي إلى نقطة تحول؟ عندما يتعلم الذكاء الاصطناعي "التحرك بنفسه"، كيف نعيد تشكيل حدود الأمان في Web3؟").
لكن المشكلة تكمن بالضبط هنا، حيث يُسهل غالبًا الوقوع في طرفين متطرفين ضمن نماذج التفاعل الحالية.
إحدى الطرق هي منح جميع الصلاحيات مباشرةً عن طريق تسليم المفتاح الخاص، أو مفتاح جلسة واحد طويل الأمد وذو صلاحيات كافية إلى الوكيل، ليقوم هو باتخاذ القرار وتنفيذ الإجراءات.
بالطبع، أفضل تجربة أتمتة لهذا النمط، لكن المخاطر مركزة أيضًا بشكل كبير؛ ففي حال تعرضك لحقن تعليمات برمجية، أو صفحة ويب خبيثة، أو تلوث بيانات، أو حتى حدوث انحراف في فهم النموذج، فقد تنتقل الأخطاء عبر سلسلة التنفيذ بأكملها وتصبح عمليات حقيقية (اقرأ المزيد في المقال: Sign ليس مجرد توقيع: عندما يوقع وكيل الذكاء الاصطناعي بدلاً منك، من يملك السيطرة؟).
في السياقات العادية للإنترنت، قد يكون هذا مجرد إرسال بريد إلكتروني خاطئ أو حذف ملف خاطئ، لكن على السلسلة، غالبًا ما تكون المعاملة الخاطئة غير قابلة للعكس.
النوع الآخر هو عدم منح أي صلاحيات على الإطلاق، حيث يظهر نافذة توقيع للتأكيد على كل عملية وكل استدعاء فرعي، مما يزيد الأمان، لكنه يقلل بشكل كبير من معنى الأتمتة.
في النهاية، عندما يساعد وكيل المستخدم في تنفيذ استراتيجية DeFi معقدة تتضمن خطوات متعددة، وإذا احتاج كل خطوة إلى أن يضغط المستخدم على هاتفه للـ «Approve»، فإن المستخدم يتحول فعليًا من مجرد «النقر على الأزرار بنفسه» إلى آلة بشرية تُصادق باستمرار على طلبات الوكيل.
بعبارة أخرى، درجة الحرية الوسيطة هي مصدر كفاءة الوكيل، وكذلك مصدر مخاطر جديدة.
من هذا المنظور، لا تكمن جوهر المشكلة في "ما إذا كان ينبغي منح الصلاحيات للوكيل" بل في ما إذا كانت دقة التفويض وآليات التحقق تتمتع بالمرونة الديناميكية، لأن إدارة الصلاحيات التقليدية ثنائية (إما السماح أو الرفض)، بينما المهام التي يواجهها الوكيل أكثر تعقيدًا بكثير.
نفس العملية التجارية، 10 دولارات و100 ألف دولار مختلفان؛ التفاعل مع بروتوكول مستخدم على المدى الطويل، وتأهيل عقد مجهول فجأة مختلفان؛ إكمال عملية Swap طلبها المستخدم بوضوح، واتخاذ العميل قرارًا ذاتيًا بنقل الأصول إلى سلسلة أخرى، ليسا بنفس مستوى المخاطرة.
لذلك، كلما كان Agent قادرًا على اتخاذ إجراءات ذاتية أكثر، لا يمكن أن يكون الصلاحية مجرد مفتاح بسيط.
ما هو مطلوب حقًا هو آلية أمان تسمح له بالتحرك بحرية ضمن الحدود، وتتوقف تلقائيًا عند تجاوزها.
ثانيًا: كيف تبني خط دفاع "قابل للتحقق" لوكيل ذاتي؟
في الواقع، لم تتجاهل OpenClaw هذه المسألة.
يقدم حاليًا آلية صلاحيات متعددة الطبقات، مثل إمكانية وقف الإضافات وطلب تأكيد المستخدم قبل تنفيذ العمليات المحددة، وعندما يتعلق الأمر بأوامر المضيف، فهناك أيضًا موافقات Exec وقوائم السماح المستقلة وغيرها.
مقارنةً بإعطاء العامل جميع الأدوات والصلاحيات دفعة واحدة، فقد تم تحقيق خطوة كبيرة إلى الأمام. لكن عندما يدخل العامل فعليًا في سيناريوهات الدفع والتجارة وإدارة الأصول، يظهر سؤال أدق: السماح للعامل باستخدام قدرة معينة ليس نفس شيء منح العامل تفويضًا لإتمام إجراء محدد.
كما أن السماح للوكيل باستخدام المتصفح لا يعني السماح له بشراء أي شيء من أي موقع ويب؛ والسماح للوكيل بالوصول إلى البريد الإلكتروني لا يعني السماح له بإرسال رسائل إلى أي شخص باسمك؛ بنفس الطريقة، السماح للوكيل بالوصول إلى المحفظة لا ينبغي أبدًا أن يعني السماح له بإرسال أي مبلغ إلى أي عنوان.
لذلك، قد تحتاج نظام الصلاحيات في عصر الوكلاء إلى التمييز بين مشكلتين مختلفتين. واحدة هي صلاحية القدرة، أي هل يمكن للوكيل استخدام المتصفح أو الطرفية أو البريد الإلكتروني أو المحفظة؟ والأخرى هي تفويض إجرائي أكثر تحديدًا، مثل: في هذه اللحظة، هل هذا الإجراء الذي يعتزم تنفيذه هو بالفعل ما سمح به المستخدم له؟
كيف يمكن جعل العامل يعمل بأتمتة كاملة ضمن حدود واضحة، مع إعادة اتخاذ القرار إلى المستخدم عند تجاوز الحدود فعليًا؟
هذا أيضًا السبب الذي يجعل imToken تستكشف Sigil. فهدفه الأساسي ليس إضافة نافذة تأكيد تقليدية إلى العامل، بل محاولة إنشاء حماية أمنية يمكن التحكم فيها بوضوح بين المستخدم والعامل من خلال التوقيع القابل للتحقق والتحكم الدقيق في الصلاحيات.
أحد المبادئ المهمة جدًا هو "ما تراه هو ما توقعه"، فما تراه، فقم بتوقيعه.
ببساطة، يمكن للمستخدم منح الوكيل صلاحيات محددة مسبقًا لإنجاز السلوكيات منخفضة المخاطر والموافق عليها وفقًا للإستراتيجية المحددة تلقائيًا؛ وعندما تصل العمليات إلى حدود المبالغ المالية أو البروتوكولات غير المعروفة أو أي حدود صلاحيات حرجة أخرى، يتم إيقاف التنفيذ مؤقتًا وإعادة طلب التأكيد من المستخدم.
الأهم من ذلك، أن هذا التأكيد لا ينبغي أن يكون مجرد عبارة غامضة مثل "الوكيل جاهز لتنفيذ الصفقة، هل توافق؟"، بل ما يحتاجه المستخدم حقًا هو رؤية المعلمات الأساسية التي ستتغير في هذه العملية: ما هي الأصول المستخدمة، وما هو المبلغ، ومن هو الطرف المتفاعل، وما الذي سيتم تنفيذه بالضبط في النهاية.
لأن التأكيد يصبح ذا معنى حقيقي فقط عندما تتطابق المحتويات التي يراها المستخدم، والمحتويات التي وافق عليها المستخدم، مع المحتويات التي نفذها النظام في النهاية.
تسعى Sigil أيضًا حول هذا الأمر إلى استخدام آليات مثل Passkey والتعريف البيومتري وتوقيع واحد وفترة صلاحية قصيرة وربط معلمات الطلب، لضمان أن التفويضات الحيوية يمكن فهمها من قبل المستخدمين وتحققها النظام.
هذا يعني أن التفويض ليس مجرد "شخص ما نقر على التأكيد"، بل يمكنه أيضًا الإجابة عن من وافق، وما الذي وافق عليه، وما إذا كان ما تم تنفيذه فعليًا هو نفس الشيء الذي تم رؤيته في ذلك الوقت.
من هذا المنظور، ما يحاول Sigil حلّه حقًا ليس "كيفية جعل الوكيل يقوم بمهام أقل".
على العكس تمامًا.
إنه يحاول حل كيفية السماح للوكيل بفعل المزيد دون أخذ السيطرة النهائية من المستخدم (اقرأ المزيد: من النقر العشوائي على "نعم" إلى التحقق قبل التوقيع: كيف توفر Sigil حماية أمنية للوكيل الذكي؟).
ثالثًا: من إدارة الأصول إلى إدارة الوكلاء
إذا تم سحب المنظور خطوة إضافية إلى الخلف، فسيتضح أن هذا يمثل أيضًا تغييرًا في دور المحافظ.
منذ ولادة إيثريوم، مرّت محفظة imToken وشهدت جيلين أساسيين: من عصر 1.0 الذي يدير مفتاحًا خاصًا واحدًا، إلى عصر 2.0 الذي يحسن تجربة التفاعل من خلال التجريد الحسابي (AA).
مع انتشار الوكلاء الذاتيين مثل OpenClaw 2.0، فإن المحافظ تدخل بلا شك مرحلة التطور الثالثة، وتحتاج إلى مساعدة إضافية للمستخدمين في إدارة مجموعة من الوكلاء التي تتخذ قرارات ذاتية وتعمل باستمرار.
وهذا هو السبب في أن قدرات إدارة المفاتيح الخاصة، والتوقيع الرقمي، والمصادقة الهوية، وعزل الصلاحيات التي تراكمت في صناعة المحافظ في الماضي، قد تكتسب معنى جديدًا في عصر الوكلاء.
لأن هذه التقنيات، على السطح، تهدف إلى حل مشكلة "كيفية التوقيع الآمن على معاملة على السلسلة"، إلا أنها في الخلفية تعالج مشكلة أكثر شمولاً: كيفية إثبات أن إجراءً معينًا حصل بالفعل على تفويض حقيقي من طرف ما.
اليوم، قد يكون هذا الإجراء نقل 1 ETH. في المستقبل، قد يكون أيضًا إرسال بريد إلكتروني، أو تعديل ملف، أو استخدام هوية رقمية، أو شراء خدمة، أو السماح للوكيل بتنفيذ استراتيجية آلية مستمرة خلال الأسبوع القادم.
لا تحدث هذه السلوكيات بالضرورة كلها على البلوكشين، لكن العلاقة الأساسية متشابهة جدًا، وهي أن العامل (Agent) يقوم بطلب قدرة تابعة للمستخدم باسم المستخدم.
لذلك، فإن معنى Sigil لا يقتصر بالضرورة على عالم العملات المشفرة.
عندما تبدأ OpenClaw و Hermes وأكثر من ذلك من الوكلاء الذين يعملون على أجهزة شخصية أو في بيئات سحابية في الاتصال بالبريد الإلكتروني والمراسلة الفورية والتقويم والملفات والمتصفح والطرفية وأدوات الدفع، سيصبح السؤال "كيف يمكن إثبات أن هذا الإجراء تم تفويضه فعليًا من قبل المستخدم" مشكلة متزايدة الانتشار.
لذلك قد تمتد Sigil في المستقبل من التداول على السلسلة إلى الوصول إلى البيانات، واستخدام الهوية، وتعديل الملفات، ونشر المحتوى، وشراء الخدمات، والمهام التلقائية.
بشكل عام، يسعى Sigil، كاستكشاف مشترك بين imToken وOpenClaw، إلى نقل الخبرات التي تراكمت خلال العقد الماضي من imToken في مجالات التخزين الذاتي والمحفظة والتوقيع الرقمي، إلى المرحلة الجديدة التي تبدأ فيها الوكلاء الذاتيون في الدخول إلى بيئات التنفيذ الحقيقية.
It does not replace Agent, nor does it replace the wallet.
إنه يقف بينهما.