أول شيء، دعوني أبدأ بشيء محرج لكن واقعي: عندما رأيت خبر إطلاق OctoClaw لأول مرة، شعرت بشيء من القلق. ليس لأنه سيء، بل لأن كلمة "Agent" تم استخدامها بشكل مبالغ فيه هذه الأيام - العديد من المشاريع قادرة على تقديم "الحديث" بشكل يبدو مثل "التنفيذ". عندما تدخل وتشاهد، تجد الشاشة مليئة بكلمات مثل "تلقائي" و"ذكي" و"بنقرة واحدة"، وعندما تحين اللحظة لتطلب منه أن ينفذ لك مجموعة من الأوامر على السلسلة، فإن النتيجة الأكثر شيوعًا هي: يعطيك ملخصًا، ثم يعيد الإجراءات إليك. لذا، كانت توقعاتي في ذلك الوقت قاسية بعض الشيء: أعتقد أن OctoClaw سيكون مجرد مساعد أفضل قليلاً.
والنتيجة أنني في تلك الليلة طعنت نفسي بيدي، وما زلت أذهب للعبث. والسبب بسيط: OpenLedger هذه المرة لم يعطني انطباعًا بأنه “مجرد مربع دردشة آخر”، بل إنه يحاول بناء شيء يهتم به أكثر شيء عندي، وأيضًا أكثر شيء سهل أن يقع فيه فخ—وهو “مسار التنفيذ”. البحث واتخاذ القرار ووضع الأوامر والربط عبر السلاسل وتدفق الأموال وإعادة استخدام الاستراتيجيات... إذا كنت تعتمد على البشر لربط كل ذلك يدويًا، فستفشل دائمًا في خطوة ما. ليس لأنك غبي، بل لأن التفاعلات على السلسلة متكسرة بطبيعتها: صفحة تلو صفحة، معلمة تلو معلمة، تؤكد في الخطوة السابقة ثم تبدّل الشبكة وتبدّل الحوض في الخطوة التالية، وفي النهاية يكون رأسك مليئًا بـ“من الذي خوّلتُ له للتو؟” و“كم حددت الانزلاق؟” و“هل عبرت الجسر في المسار الصحيح؟”. لذلك كانت أهدافي التي وضعتها لنفسي بسيطة للغاية: لا تفكر في جني المال أولاً؛ شاهد أولاً ما إذا كان بإمكانه تشغيل سير عمل كامل على السلسلة دون انقطاع، والأهم أن يكون استخدامه مريحًا وغير مزعج.
اللحظة التي بدأت أؤمن بها حقًا—بشكل مدهش—لم تكن لأنه أكثر ذكاءً، بل لأنني أول مرة فتحت واجهة إعدادات OctoClaw شعرت بحدس يفرض نفسه: إنه يجبرك أن تتعامل بجدية مع “الصلاحيات”. هذه النقطة مهمة جدًا. كثير من الأدوات حتى تجعلك تستمتع قد تقلل عمدًا من شأن الصلاحيات والمخاطر؛ لكن طالما أنك تريد أن يقوم وكيل (Agent) بـ“التحرك/العمل”، فالصلاحيات ليست خيارًا، بل هي شريان حياتك. في ذلك الوقت، كنت مترددًا قليلًا—هل تعرف ذلك الشعور؟ كأنك أول مرة تعطي مفتاح API لنظام جديد، في ذهنك تُعاد تلقائيًا كل فواجع “السرقة”، و“التشغيل الخاطئ”، و“الصلاحيات لم يتم سحبها”. من وجهة نظري، نقطة OctoClaw cloud config ليست زينة؛ إنها أشبه بإبراز خط أحمر لدى OpenLedger: القدرة على التحليل لا تعني القدرة على التنفيذ، والقدرة على التنفيذ لا تعني السماح بعشوائية التنفيذ. بمعنى آخر، على الأقل في مستوى المنتج، يعترف بأن “يد الـAgent” أخطر بكثير من “فم الـAgent”، وهذا الموقف أقنعني جدًا.
ثم لمست نقطة trading agent بنفسها. التداول هو أكثر شيء يختبر صدق/حقيقة المنتج، لأن التداول لا يقبل الغموض. جملة مثل “أظن أنه سيزيد” لا معنى لها؛ المعنى الحقيقي هو: على أي سلسلة، وأي تجمع/حوض تستخدم، وأي مسار/route تختار، وكيف تحدد الانزلاق، وماذا يحدث إذا فشل التنفيذ، وكيف تتم المراجعة بعد إتمام الصفقة. معلومات OpenLedger عن trading agent، في الحقيقة، وضعت الموقف بوضوح: إنها تريد منك نشر الاستراتيجيات بطريقة أكثر “وحداتية” (modular)، كأنك تبني مكعبات (lego) عبر ربط مجموعة من الأفعال في سلسلة تنفيذ قابلة للتشغيل، بدل أن تفتح في كل مرة مجموعة صفحات ويب وتعمل كأنك جهاز توجيه بشري (human router). أثناء تجاربي العملية، لم تكن أكثر مشاعري “أنه جعلني أفكر أقل”، بل “أنه جمع عادات التشغيل التي كانت مبعثرة عندي داخل أدوات مختلفة”. سابقًا عندما كنت أعمل على سلسلة من الأفعال على السلسلة، غالبًا كان المسار مثل: أولًا أبحث عن البيانات، ثم أفتح مُجمّعًا (aggregator)، ثم أؤكد الشبكة، ثم أوقع، ثم أنتقل إلى جسر عبر السلاسل، ثم أعود لأداء عمليات دخول/خروج الأموال... ليس الأمر معقدًا إلى هذه الدرجة، ولا هو شيء مستحيل؛ لكن كل خطوة تستهلك الانتباه، وأي لحظة تشتت فيها، يظهر الخطأ.
في تلك الليلة، كنت أكرر أمرًا بدا لي مملًا فعلًا: جعل نفسي أمر عبر العملية الكاملة عمدًا، ثم أرى في أي خطوة بالتحديد سيكون أسهل شيء أن ينكشف خلل/شيء غير صحيح. مثلًا، كنت أبدأ بأن أجعله يراقب وفق شروط حددتها أنا (ليس ذلك الكلام العام الفارغ مثل “مراقبة مشاعر السوق”، بل إشارات على السلسلة من نوع التي أركز عليها عادة)، ثم أحول تلك الإشارة إلى فعل محدد، ثم أحول الفعل إلى تنفيذ فعلي. الشيء الذي أردت أن أراه ليس “هل يستطيع التنبؤ؟”، بل “هل يستطيع أن يفهم متطلبات التنفيذ التي لدي ويطبقها”. وهذا يعيدنا إلى ما قلته سابقًا: مسار التنفيذ هو التحدي. مشروع إذا فعل فقط “البحث وتوليد النتائج”، يمكنه دائمًا أن يكون رائعًا. لكن إذا كان يجرؤ على جعل “التنفيذ” محور المنتج، فهذا يعني أنه يعرف أين أكثر شيء سيتعرض فيه لانتقاد الناس.
ثم، كعادتي، عضضت أيضًا نقطة ERC-4626 integration. كثيرون عندما يرون 4626 يصابون بالنعاس؛ وأنا كنت كذلك أيضًا: معيار صندوق العوائد—تم الحديث عنه لسنوات، والجميع يعرف. لكن في تلك الليلة فجأة غيّرت زاوية النظر: إذا كنت حقًا تريد أن يقوم Agent بإدارة الأموال، فالتوحيد (standardization) ليس رفاهية، بل هو شرط أساسي لتوسيع نطاق العمل. اليوم تربط بروتوكولًا، غدًا بروتوكولًا آخر؛ وكل vault لديه اختلافات في حساب الإيداع/الاسترداد (redemption)/الحصص. عندها يتحول مستوى تنفيذ Agent إلى جحيم محولات (adapter hell). يمكنك القول إنه يستطيع أن يعمل؟ نعم يعمل، لكن بمجرد تحديث البروتوكول عليك إصلاح الكثير. ومهما زادت الاستراتيجيات، ستبدأ في إهمال شيء آخر. قيمة 4626 في هذا السياق، باختصار، هي تحويل “حركات الأموال” إلى واجهة أكثر توحيدًا وأكثر قابلية للتجميع والتركيب (composability)، بحيث تصبح أفعال مثل الإيداع والاسترداد والحصص والعائد أقرب إلى لغة واحدة بين استراتيجيات مختلفة. تخيلها كأنك “تحدد شكلًا معياريًا لحاوية أموال الـAgent”، وستشعر أن كل شيء يسير فجأة بسلاسة.
وفي هذا أيضًا تفصيلة صغيرة تعجبني جدًا: عندما يتم توحيد التنفيذ، تصبح عملية الاسترجاع/المراجعة (replay/recap) ذات معنى. سابقًا، عندما كنت تستخدم بروتوكولات مختلفة لتحقيق عوائد، كانت المراجعة تتحول بسهولة إلى “أظن أنني ربحت/خسرت”، لأن المسارات كانت مشتتة جدًا؛ لكن عندما يتم حصر المسار داخل أفعال معيارية، يسهل عليك عمل المطابقة: متى حدث الإيداع، وما تغيّر بالضبط في الحصص (shares) المرتبطة به، ومن أين جاء العائد تحديدًا، وكم مقدار الاحتكاك (friction) عند الخروج. لا تنخدع—قد تبدو هذه “تفاصيل مملة على مستوى التشغيل”، لكن من يعمل على السلسلة لفترة طويلة يعرف هذا: هل يمكنك عمل مراجعة بعد التنفيذ، يحدد ما إذا كان بإمكانك الاستمرار بثبات.
ثم ذهبت وجربت EVM Bridge. هذا النوع من جسور الربط بين السلاسل يستخدمه الجميع حتى صار مألوفًا ومملًا بعض الشيء، لكنني ما زلت أراه “اختبارًا للسلامة من ناحية التكامل”. لأن كثيرًا من أدوات الأتمتة المزعومة في النهاية تتعثر في جزء الربط عبر السلاسل: قد تتمكن من تشغيل كل شيء بكفاءة على نفس السلسلة، لكن بمجرد أن تحتاج إلى نقل الأصول إلى سلسلة أخرى، سيجعلك تذهب إلى جسر يدويًا ثم تعود لتكملة المسار. التجربة هنا غير متناسقة جدًا، كأنك تقود سيارة بتقنية القيادة الذاتية على الطريق السريع، ثم عند بوابة الرسوم تضطر للنزول من السيارة ورفع حاجز البوابة يدويًا. على الأقل، EVM Bridge في OpenLedger يقدم قناة بترميز/دلالة أقرب لـ“المعنى الرسمي”، بحيث يمكن إدراج مسألة “وصول الأموال” ضمن نفس سير العمل. قد لا يعني هذا أن الربط عبر السلاسل صار آمنًا بلا قلق، لكنه على الأقل يجعل التجربة أكثر سلاسة واتساقًا: لم يعد الجسر خطوة خارجية تضطر لحلها مؤقتًا لدى طرف ثالث، بل صار جزءًا يمكن التحكم فيه داخل سلسلة الخطوات.
عندما أصل إلى هذا، أدركت أن بعض نقاط الحديث (talking points) في OpenLedger ليست مجرد قائمة وظائف مستقلة؛ بل إنها أشبه بتجميع stack تنفيذ كامل: OctoClaw هو المدخل، و cloud config هو لوحة التحكم، و trading agent هو السيناريو الأكثر مباشرة للتنفيذ، و ERC-4626 يضع معيارًا لحركات التمويل، و EVM Bridge يكمل جزء الربط بين السلاسل. إذا نظرت إليها منفصلة، ستراها مثل تحديثات متفرقة لخمسة أو ستة أجزاء؛ لكن إذا ربطتها معًا وفق “المسار الذي أستخدمه فعليًا”، تصبح حلقة مغلقة من “ماذا أريد أن أفعل” إلى “ماذا حدث بالفعل على السلسلة”.
وأخيرًا أريد أن أتحدث عن vibecoding مع OpenLedger. هذه النقطة اعتقدت في البداية أنها غريبة: ألا تتحدث عن التنفيذ والتداول؟ لماذا فجأة ننتقل إلى vibe coding ومنصة مفتوحة المصدر؟ لكن كلما استخدمت أكثر، شعرت أنها في الحقيقة إحدى الطرق الأساسية التي يريد OpenLedger من خلالها بناء منظومة/إيكولوجيا. لأن طريق الـAgent لا يمكن أن يعتمد فقط على أن يقدم الفريق الرسمي ميزات. الاحتياجات الحقيقية دائمًا ما تكون مجزأة: شخص يريد مراقبة على السلسلة، وآخر يريد عتبات للتحكم في المخاطر (risk control)، وآخر يريد نقل/تحريك أرباح (arb) بطريقة “تحويلات” (搬砖)، وآخر يريد أدوات أقرب إلى “الأعمال/سير العمل” (workflow). أنت إما أن تسمح للمستخدمين أن يكتبوا سكربتات بأنفسهم، وفي النهاية يتحول الأمر إلى أكوام من قطع خاصة يصعب صيانتها؛ أو توفر لهم طريقة “لبناء سريع وتوزيع” أكثر جدية، بحيث يستطيع الجميع تجميع الميزات ضمن الإطار الذي تقدمه، ثم إعادة ربطها بمدخل التنفيذ مثل OctoClaw. إذا تم تنفيذ vibecoding بشكل جيد، فلن يكون مجرد “امتياز للمطورين”، بل سيقرر فعليًا حيوية OpenLedger: عدد الأدوات يزداد، وسير العمل يصبح أغنى، ويثبت أكثر أنه ليس مجرد عرض/ديمو يمكن تقديمه فقط، بل قاعدة يمكن أن تُنبت أشياء حقيقية.
بالطبع، وأنا أيضًا لا أريد أن أكتب وكأني أضع المشروع في موضع منصة استعراض. في تلك الليلة، بعد أن عبثت كثيرًا، كانت في قلبي في الواقع ثلاث نقاط واقعية جدًا تتعلق بـ“الأولوية لإنقاذ الحياة”؛ ويمكن حتى القول إنها كانت نقاط انتقاد للتدقيق. أولاً: هل يمكن التحكم بالصلاحيات بشكل أدق؟ مثلًا حسب السياسات، حسب الأصول، حسب حدود كل عملية على حدة، والأفضل أيضًا وجود عزل صارم من نوع “للقراءة فقط” و“للتنفيذ فقط لنوع محدد من الإجراءات”. ثانيًا: هل يمكن أن تصبح سجلات التنفيذ قابلة فعلًا لإعادة التشغيل؟ أسباب الفشل، اختيار المسار، التعامل مع الانزلاق (slippage)، تأخر ما بين السلاسل... إذا لم تكن هذه الأمور شفافة، فحتى إن كان الـAgent ذكيًا، فسيتحول إلى صندوق أسود. ثالثًا: هل توجد تنبيهات مخاطر وقيود افتراضية على إجراءات الربح المعيارية؟ لا تترك “الأتمتة” تدفع الناس إلى استراتيجيات أكثر اندفاعًا، بل اجعل من السهل عليهم عمل المطابقة (reconciliation)، وإيقاف الخسائر (stop loss)، والتوقف عندما يحتاجون إلى التوقف.
لكن حتى مع كل هذه الملاحظات النقدية، ما زلت أريد أن أقول خلاصة رأيي بنفسي: أنا الآن أكثر رغبة في رؤية OpenLedger باعتباره “مشروعًا جادًا في سد فجوة مسار التنفيذ”، وليس “مشروعًا يحكي قصة” فقط ليواكب موجة الـAgent. أحب أن يركز على وحدات هندسية يمكن تنفيذها على الأرض: الإعدادات، الصلاحيات، المعايير، الربط/الجسر، أدوات المطور... هذه الأشياء ليست مثيرة للانتباه على السطح، والكتابة عنها لا تجذب التدفق (traffic) بسرعة، لكنها تحدد ما إذا كان منتج الـAgent يمكنه دخول سيناريوهات حقيقية أم لا. في النهاية، سأستمر في استخدامه لفترة—إلى أن أجري عدة استراتيجيات إضافية، وأقع في عدة فخاخ أكثر—ثم سأعود لأكتب المقال الثاني بتركيز أكبر على “المطابقة والتحقق”: حينها لن نتحدث عن المفاهيم؛ بل مباشرة عن: كم من الوقت وفره لي، وكم من الأخطاء قللها، وما هي الأماكن التي ما زال يتعين عليّ أن أراقبها بنفسي.