بعد OpenClaw، لماذا يشعر معظم الناس أن هناك فجوة ما زالت موجودة

كتابة: دائرة التفكير العميق

هل فكرت يومًا في سؤال: لماذا يحقق OpenClaw شهرة واسعة، ولكن عند الاستخدام الفعلي، يشعر معظم الناس بأنه—رغم ذكائه—لا زال ينقصه شيء ما؟

ليس بسبب ضعف النموذج، أو قلة الوظائف. بل لأنه حل مشكلة “التفكير”، لكنه لم يحل مشكلة “العمل”.

عندما تخبره بتنفيذ مهمة، فإنه يعمل في الطرفية، يكتب في بيئة التطوير، أو يستنتج في الحوار. لكن بين “القرار النهائي” و"الإنجاز الحقيقي" هناك مسافة—تغيير النافذة، البحث في النظام، النسخ واللصق، النقر على تأكيد—وهذه المسافة أنت من يقطعها.

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

المتغير الذي يقلل الناس من تقديره

خلال العامين الماضيين، تركز النقاش حول بنية تحتية للذكاء الاصطناعي على اتجاهين:

الأول هو قدرات النموذج—حجم المعلمات، سرعة الاستنتاج، نافذة السياق، والتقدم في هذا المجال واضح للجميع.

الثاني هو إطار عمل الوكيل—مثل LangChain، AutoGPT، OpenClaw، التي تمثل قدرات تنظيم المهام والجدولة، وهناك استثمار كبير في هذا الجانب أيضًا.

لكن هناك متغيرًا واحدًا، يكاد لا أحد يركز عليه بشكل منهجي: البنية التحتية لتنفيذ المهام على مستوى المحطة.

ما المقصود بالبنية التحتية لتنفيذ المهام على مستوى المحطة؟

ببساطة، هو ذلك الشيء الذي يمكن الوكيل من “العمل اليدوي” الحقيقي في بيئة عملك الفعلية—ليس في بيئة معزولة، وليس داخل حاويته الخاصة، بل على شاشتك الفعلية، أدواتك الحقيقية، ونظامك الحقيقي.

لماذا هذا الأمر صعب؟

لأن تعقيد بيئة العمل الواقعية يتجاوز أي محاكاة في بيئة معزولة. هناك أنظمة قديمة بدون API، تدفقات عمل تتطلب التنقل بين خمسة أو ستة أدوات مختلفة، وسياقات مهام متناثرة عبر نوافذ متعددة، ولا توجد واجهات قياسية يمكن استدعاؤها.

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

وهذا هو فعلاً العقبة الحقيقية أمام تطبيق الوكيل، والمتغير الذي يقلل الناس من تقديره عند مناقشة وكلاء الذكاء الاصطناعي.

ما الذي يفعله Violoop؟

مؤخرًا، ظهرت لديّ رؤية لمشروع يُدعى Violoop.

هو عبارة عن جهاز ذكي يعمل على سطح المكتب، مزود بشاشة تعمل باللمس، ويعمل بشكل أصلي على الذكاء الاصطناعي، ويتصل بالحاسوب عبر HDMI وType-C، ويدعم كل من Mac و Windows. من شكله، يبدو بسيطًا، لكنه يوجهنا مباشرة نحو ذلك المتغير الذي يُقلل الناس من تقديره.

يستقبل ثلاثة أنواع من البيانات: تدفق الفيديو (الإدراك البصري الشامل للشاشة)، API النظام (إشارات حالة نظام التشغيل)، وصلاحيات HID (التحكم الأساسي في الماوس ولوحة المفاتيح). هذه الطبقات الثلاثة تتكامل لتشكل بيئة إدراك، استنتاج، وتنفيذ على مستوى المحطة.

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

يراقب أي نافذة تفتح، المدة التي يقضيها في صفحة معينة، وتيرة تقدم المهمة—ثم يقرر بنفسه هل يتدخل أم لا. هذا المنطق في التصميم يختلف جوهريًا عن أنماط الأدوات الحالية التي تعتمد على “الاستجابة السلبية”.

القيمة الهيكلية لطبقة التنفيذ

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

يمكن فهم بنية أدوات وكلاء الذكاء الاصطناعي الحالية بشكل تقريبي على أنها طبقات:

طبقة النموذج: مسؤولة عن الاستنتاج، وقد تطورت بشكل كبير.

طبقة الإطار: مسؤولة عن تنظيم المهام، وتحقق تقدمًا سريعًا.

طبقة الأدوات: تعزز قدرات محددة في سيناريوهات معينة، وتتميز بالتشابه العالي.

طبقة التنفيذ: مسؤولة عن الإدراك على مستوى المحطة والتنفيذ عبر الأدوات، وهي شبه غائبة.

غياب طبقة التنفيذ لا يجعل الوكيل “ضعيفًا” فحسب، بل يحد من قدراته بشكل أساسي، حيث يُقيد سياق العمل الذي يمكنه التعامل معه.

قدرة المؤشر (Cursor) محدودة ببيئة IDE، وClaude Code محدود ببيئة الطرفية. في داخل حاوياتهما، يمكنهما أن يكونا قويين، لكن خارجها، لا يعرفان ولا يستطيعان الاستجابة لما يحدث.

وهذا يعني أن الوكيل اليوم هو نوع من “تعزيز محلي”—يعزز قدراتك في أداة واحدة، لكنه لا يعزز قدراتك في سير العمل بأكمله.

التحول الحقيقي للوكيل يتطلب قدرات إدراك وتنفيذ تتجاوز حدود الحاويات، وتعمل على مستوى نظام تشغيل شامل يمكنه رؤية والتحكم في الصورة الكاملة.

وهذا هو المكان الذي يركز عليه Violoop.

بعض القرارات التصميمية التي تستحق التفكير العميق

في بنية Violoop، هناك قرارات تصميم أراها ليست مجرد خيارات وظيفية، بل تعكس فهمًا عميقًا للمشكلة.

نمط التعلم عبر التسجيل: رد فعل مباشر على “الأنظمة بدون API”

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

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

هذا الفهم صحيح، وهو السبب الجذري وراء عوائق التوسع التي تواجه أدوات RPA التقليدية.

تقسيم العمل بين الطرفية والسحابة: للرد على تكاليف الاستنتاج وحدود الخصوصية

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

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

الأهم من ذلك، أن هذا الهيكل يتيح لـ Violoop أن يكون في حالة استعداد دائم على مدار الساعة، ومع ميكانيكية Wake-on-LAN، يمكنه إيقاظ الجهاز تلقائيًا، تنفيذ المهام، ثم العودة إلى وضع السكون. وهذا شيء لا يمكن للوكيل البرمجي فقط تحقيقه.

عزل الصلاحيات على مستوى الأجهزة: للرد الهندسي على “مخاطر التنفيذ الذاتي”

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

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

لماذا ظهر هذا الاتجاه الآن؟

هناك سؤال مهم: غياب طبقة التنفيذ ليس مشكلة جديدة، فلماذا يظهر مشروع مثل Violoop الآن؟

اعتقادي أن هناك عدة شروط نضجت مؤخرًا بشكل متزامن:

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

الثاني، قدرات فهم المهام في النماذج الكبيرة أصبحت قوية بما يكفي، مما يجعل “فهم نية المهمة” ممكنًا، وليس مجرد “تسجيل تسلسل العمليات”. هذا هو الأساس لنجاح نمط التعلم عبر التسجيل.

الثالث، كشفت موجة OpenClaw عن مشكلة غياب طبقة التنفيذ، مما زاد من وضوح الطلب السوقي على هذا الاتجاه.

تزامن نضوج هذه الشروط الثلاثة فتح نافذة لم تكن موجودة من قبل.

فريق Violoop أيضًا يدعم هذا التقييم—الرئيس التنفيذي Jaylen He هو رائد أعمال متكرر، قاد فريقه إلى YC، وCTO King Zhu هو عبقري أكاديمي من MIT EECS، أنجز دراسته خلال 3.5 سنوات، وله خلفية هندسية في Microsoft Xbox وHoloLens وSurface، وبدأ منذ 2023 في نشر تطبيقات على مستوى الشركات العالمية. هذا ليس فريقًا بدأ يغير مساره بعد نجاح OpenClaw، بل هو فريق كان يختبر هذا الاتجاه قبل أن يشتد الطلب.

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

إشارة مهمة تستحق الانتباه

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

لكن هناك شيء أعتقد أنه يمكن الحكم عليه الآن:

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

هذا الموقع، في النهاية، سيقوم أحدهم ببنائه.

السؤال الآن ليس “هل طبقة التنفيذ مهمة”، بل “من سيبنيها، وكيف، ومتى”.

Violoop هو من بين القلائل الذين يفهمون المشكلة بشكل واضح، ويصممون بنية تحتية برؤية خاصة.

نجاح OpenClaw أظهر إمكانيات الوكيل، لكن نقطة التحول الحقيقية في تطبيق الوكيل قد لا تكون مع إصدار نموذج جديد، بل عندما يتم إكمال البنية التحتية لطبقة التنفيذ.

وهذا هو الإشارة الحقيقية التي يجب أن نتابعها في هذه الموجة.