وكلاء الذكاء الاصطناعي على سطح مكتب بعيد حقيقي — Agent Runtime، قيد التطوير.
Agent Runtime قيد التطوير — ولا توجد حزمة تطوير للوكلاء بعد. أما الموجود فعلاً فهو سبب كونه جديراً بالبناء: يعمل مسار Remio الأصلي للإدخال والتقاط الشاشة اليوم لإنسان يجلس أمام جهاز Mac أو كمبيوتر أو Linux حقيقي. وهذه الصفحة هي التصميم الصريح لما سيأتي — والقيود التي نلتزم بها قبل أن يُطرح أي شيء منه.
لماذا يحتاج الوكلاء إلى شاشة حقيقية.
بيئة المتصفح المعزولة جيدة لوكيل يملأ نماذج الويب فقط. وما إن يتجاوز العمل إلى التطبيقات الأصلية حتى ينتهي طريقها. سطح المكتب الحقيقي هو أنظف بيئة تشغيل للوكيل — فما يستخدمه الإنسان يستطيع الوكيل استخدامه.
الوكيل الذي يعيش داخل متصفح بلا واجهة فقط لا يستطيع فتح Final Cut، ولا سحب ملف فيديو من Finder إلى أداة إبداعية، ولا توقيع ملف PDF في Preview، ولا تشغيل مثبّت .dmg أو .exe، ولا منح تطبيق آخر إذن تسجيل الشاشة، ولا اختيار ملف عبر منتقي الملفات في النظام، ولا النجاة من نافذة حوار غير متوقعة من نظام التشغيل. وهذه هي اللحظات التي تعيش فيها معظم سير العمل الحقيقية — وحيث يفشل وكيل المتصفح بلا واجهة بصمت.
تسد الحاويات الافتراضية (نمط "حاسوب الوكيل" لدى المختبرات الكبرى) بعض هذه الثغرات، لكنها تجلب ثغراتها. فالصورة عادةً سطح مكتب Linux بسيط مع حفنة تطبيقات مثبّتة مسبقاً؛ وأي شيء خارج هذا النطاق يتعذّر الوصول إليه. ولا استمرارية بين الحاوية وعمل المستخدم الفعلي — تطبيقاته المثبّتة وحساباته المسجّل دخولها وملفاته المحفوظة وأذوناته الممنوحة. كل تشغيل للوكيل يبدأ من جهاز نظيف ليس جهاز المستخدم.
يسلك تصميم Remio الطريق الآخر. فالوكيل المتصل عبر الـ runtime الذي نبنيه سيحصل على سطح مكتب المستخدم الحقيقي — جهاز Mac أو الكمبيوتر أو Linux الذي يعمل عليه المستخدم فعلاً — عبر جلسة سطح المكتب البعيد نفسها التي يستخدمها الإنسان اليوم. ستكون كل التطبيقات المثبّتة لدى المستخدم هناك. وكل حساب سجّل المستخدم دخوله هناك. وكل ملف هناك. لن يكون الوكيل مستأجراً في بيئة اصطناعية؛ بل ضيفاً على محطة عمل المستخدم الفعلية، ما دام المستخدم يسمح له بالدخول — ولا لحظة أطول.
المسار الذي سيستخدمه الوكيل — يعمل فعلاً، للبشر.
كل نقرة وضغطة مفتاح وتمرير يرسلها مستخدم Remio اليوم تصل إلى المضيف عبر نظام الإدخال الأصلي في نظام التشغيل نفسه — الحدث نفسه الذي تولّده فأرة أو لوحة مفاتيح فعلية. هذا المسار ليس افتراضياً؛ بل هو ما يجعل Remio يعمل للإنسان الآن، على جهاز Mac أو كمبيوتر أو Linux حقيقي. وهو أيضاً، لا مصادفةً، الأساس نفسه الذي سيتصل به Agent Runtime: لا واجهة برمجية منفصلة موجّهة للوكلاء، ولا ضغطات مفاتيح اصطناعية تُحقَن في طابور أحداث نافذة، ولا طبقة وصول بديلة تقوم مقام نقرة حقيقية.
التزام التصميم: إن طُرح، فسيكون إدخال الوكيل غير قابل للتمييز عن إدخال الإنسان عند المضيف — لأنه سيستخدم المسار نفسه تماماً، لا مساراً موازياً بُني للوكلاء وحدهم.
هذا أهم مما يبدو، وهو سبب اعتقادنا أن بنية Remio نقطة انطلاق جيدة فعلاً لـ Agent Runtime، لا مجرد نقطة مريحة. فمنصات الوكلاء التي تزيّف الإدخال على مستوى التطبيق — ضغطات مفاتيح اصطناعية في طابور أحداث نافذة، أو واجهات الوصول تقود عناصر الواجهة مباشرة — تصطدم بحدود باستمرار: الحقول المحمية ترفض الإدخال، واختصارات النظام الأصلية تخطئ، والسحب والإفلات لا يعمل بين التطبيقات، وإدارة التركيز تضطرب. أما التوجيه عبر مسار الإدخال على مستوى نظام التشغيل فيتجاوز ذلك كله فعلاً، لجلسات البشر التي تعمل اليوم. وتوسيعه إلى جلسات الوكلاء عمل تصميمي ما زال علينا إنجازه — لكن الأساس الذي يؤدي الجزء الصعب يُطرح فعلاً.
ستنتقل حدود الصلاحيات دون تغيير، بحكم التصميم. فإذني إمكانية الوصول ومراقبة الإدخال في المضيف، اللذان يمنحهما إنسان لتطبيق Remio Host مرة واحدة، يحكمان فعلاً كل حدث إدخال ترسله جلسة بشرية. والتزام التصميم أن جلسة الوكيل ستحكمها المنحة نفسها تماماً — لا إذن منفصل يملكه الوكيل بنفسه، ولا باب أوسع من الباب الذي فتحه الإنسان للتطبيق.
الوصول إلى الشاشة، وتصميم كيفية استخدام الوكيل له.
يبث مسار التقاط الشاشة في Remio اليوم عرضاً مباشراً للمضيف إلى عميل بشري — إطارات كاملة، مرمّزة بالعتاد، في الزمن الفعلي. وسيحتاج Agent Runtime إلى بضعة أشكال أخرى من البيانات نفسها: لقطة ثابتة عند الطلب، ومنطقة أصغر، وقراءة منظمة لما على الشاشة. لا شيء من هذه الأشكال الإضافية موجود في الشيفرة المطروحة بعد.
ما هو متوفر اليوم هو البث المباشر: شاشة المضيف، تُلتقط باستمرار، وتُرمَّز بالعتاد، وتُسلَّم عبر القناة المشفّرة نفسها التي يستخدمها العميل البشري. وسيعيد Agent Runtime استخدام المسار نفسه للقطاته الثابتة — إطار واحد عند الطلب، أو المنطقة التي يعرف النموذج أصلاً أن ينظر إليها فقط — بدلاً من إقامة مسار التقاط ثانٍ منفصل. وإعادة الاستخدام هذه خيار تصميمي استقررنا عليه، لا ادعاء بشأن ما هو موجود اليوم.
للوكلاء الذين يستدلّون على النص أفضل من البكسلات، يرسم التصميم وضع نص مكتوب: نص الشاشة يُعاد مع مربعات الإحاطة، ويُولَّد بالتعرف الضوئي على الحروف الأصلي في المنصة (إطار Vision على macOS وواجهة Windows OCR على Windows) بدلاً من نموذج رؤية في الحلقة. لم يُبنَ شيء من هذا. وهو على القائمة لأنه سيتيح للوكيل تحويل مطابقة نص إلى نقرة دقيقة دون إرسال أي إطار إلى نموذجه — مكسب كفاءة حقيقي، إن بنيناه جيداً.
وللوصول المنظم الأعلى دقة، يرسم التصميم أيضاً قراءة لشجرة إمكانية الوصول في نظام التشغيل للنافذة المركَّز عليها — الشجرة نفسها التي يتجول فيها قارئ الشاشة: تسلسل هرمي معنوَن من الأزرار وحقول النص والقوائم والأدوار. لا شيء من هذا موجود بعد أيضاً. وفي كل صيغة نرسمها تنتقل القاعدة نفسها من مسار الإدخال: ستحصل جلسة الوكيل على ما يسمح إذن تسجيل الشاشة في المضيف لجلسة بشرية برؤيته بالضبط، لا أكثر. وإن كان ذلك الإذن مغلقاً لشاشة ما، فلن يحصل الوكيل على شيء من تلك الشاشة — تماماً كما يحدث لعميل بشري اليوم.
القيود التي نلتزم بها قبل كتابة شيفرة الوكيل.
هذه ليست ميزات نبنيها لاحقاً ونأمل أن نصيبها. إنها القيود التي يجب أن يستوفيها تصميم Agent Runtime كله قبل أن يُطرح أي شيء منه — حُسمت الآن، بينما لا توجد شيفرة تُصمَّم حولها.
كل جلسة Remio — بشرية أو وكيلية — ستبدأ بالطريقة نفسها: إنسان يمسح رمز QR، أو يكتب معرّف الجهاز ورمز PIN، المعروضين على شاشة المضيف، في Remio. لا يوجد أي تصميم قيد النظر ينشئ فيه الوكيل جلسته بنفسه، أو يحتفظ برمز يجدّده بصمت، أو يمدّد الوصول إلى ما بعد اللحظة التي يقرر فيها الإنسان الذي أقرنه إنهاءه. وسيحتاج التشغيل التالي للوكيل إلى أن يقرن الإنسان من جديد — لحظة جديدة يكون فيها الإنسان في الحلقة، في كل مرة، بحكم التصميم.
بينما تكون جلسة الوكيل نشطة، سيعرض كل من المضيف والعميل مؤشراً دائماً لا يلتبس — وزر إيقاف ينهي الجلسة فوراً، يستطيع الوصول إليه كل من يجلس أمام لوحة مفاتيح المضيف، لا من بدأها فقط. وسيُسجَّل كل إجراء يتخذه الوكيل في سجل تدقيق يستطيع الإنسان مراجعته. لا شيء من هذا موجود في الشيفرة المطروحة اليوم؛ بل هو المعيار الذي يجب أن يجتازه التصميم.
حدود الأذونات هي القصة نفسها كما في قسمي الإدخال والشاشة أعلاه: سترث جلسة الوكيل أذونات نظام التشغيل في المضيف التي تحترمها الجلسة البشرية فعلاً — تسجيل الشاشة وإمكانية الوصول — دون أوسع منها. لن تحصل على منحة مرتفعة خاصة بها، ولن يكون لها سبيل لتوسيع الحدود التي وضعها الإنسان لتطبيق Remio. وإن كانت قدرة نصممها لا تتسع داخل تلك الحدود، فلن تُطرح.
لا توجد حزمة تطوير بعد — وهذا الشكل الذي نتجه نحوه.
لم ينشر Remio حزمة تطوير للوكلاء ولا واجهة برمجية ولا مواصفات اتصال للوكلاء. ما لدينا قائمة قصيرة من القدرات الأساسية يعود إليها التصميم باستمرار — الإدخال والوصول إلى الشاشة وقراءات الواجهة المنظمة — والتزام بأن ما سيُطرح سيكون محايداً تجاه النماذج منذ اليوم الأول.
الشكل الذي نستقر عليه صغير عن قصد: أساسيتان للإدخال (نقرة ومفتاح)، وأساسيتان للرؤية (إطار ثابت ومنطقة)، وواحدة لقراءة منظمة للواجهة. هذا رسم أولي لا مواصفات — لم يُطرح شيء منه، والواجهة الدقيقة لا تزال مفتوحة. ما نلتزم به الآن هو الشكل لا الصياغة.
الحياد تجاه النماذج شرط تصميمي لا طموح سنصل إليه لاحقاً. وكل ما سيُطرح سيعمل بالطريقة نفسها سواء كان النموذج الذي يخطط لسير العمل Claude أو GPT أو Gemini أو شيئاً تشغّله بنفسك. لا نبني هذا حول صيغة استدعاء أدوات لمزوّد واحد، لأننا في اللحظة التي نقيّد فيها الـ runtime بواجهة نموذج واحد نكون قد قطعنا الوعد الخطأ.
بيئة تشغيل سطح المكتب وبيئة تشغيل الوكيل نفسه شيئان مختلفان، وننوي إبقاءهما كذلك. سيكون Remio ما يوصل إجراءات الوكيل إلى سطح مكتب حقيقي؛ أما النموذج وحلقة التخطيط ومكان التشغيل فتبقى كلياً لمن يبني الوكيل. ولا نخطط لاستضافة النماذج أو قياس استخدامها أو تقييد الوصول إليها بأنفسنا.
ما لم يُبنَ هذا التصميم من أجله.
سيكون runtime سطح المكتب الحقيقي الشكل الصحيح لبعض سير عمل الوكلاء والشكل الخطأ لغيرها. وهذا هو التحديد القصير الصريح — حتى قبل أن يُطرح أي شيء منه.
لم يُبنَ Remio لوكيل لا يحتاج إلا إلى متصفح ويب — يجمع الصفحات ويملأ النماذج ويقرأ لوحات المعلومات. فجلسة سطح مكتب بعيد كاملة أكثر مما تحتاجه علامة تبويب في متصفح، ولا يحاول Remio المنافسة في تلك الفئة.
ولم يُبنَ Remio لوكيل يحتاج عشرات البيئات المؤقتة — واحدة لكل مهمة، بحالة جديدة في كل مرة، وتنفيذ متوازٍ. بُني Remio حول جلسة دائمة بإقران بشري، وهي الشكل المعاكس: تزامن منخفض، واستمرارية عالية، وسياق مستخدم حقيقي.
إن بنينا Agent Runtime كما تصفه هذه الصفحة، فسيكون الجواب الصحيح حين يحتاج الوكيل إلى سطح مكتب نظام تشغيل حقيقي مع تطبيقات أصلية، وبرمجيات المستخدم المثبّتة فعلاً، وحساباته وملفاته الحقيقية، وحدود جلسة يكون فيها الإنسان في الحلقة. وكلاء إمكانية الوصول الذين يقودون سطح مكتب لمستخدم من ذوي الإعاقة. وضمان الجودة بمساعدة الذكاء الاصطناعي على تطبيقات نظام تشغيل حقيقية. وسير العمل الوكيلية التي يجب أن تستخدم أداة أصلية معينة يملكها المستخدم أصلاً. وأي مهمة يكون فيها "استخدم جهازي الفعلي بكل ما عليه بينما أشرف" هو الإطار الطبيعي. في هذه الحالات، متى طُرح، سيكون Remio هو الـ runtime.
أسئلة شائعة حول Agent Runtime الذي نصممه.
خمسة أسئلة يثيرها هذا التصميم عادةً — وإجابات صريحة أدناه، بما فيها تلك التي تكون الإجابة الصريحة فيها "ليس بعد".
هل يمكنني اليوم استخدام Claude أو GPT أو وكيل ذكاء اصطناعي آخر للتحكم في جهازي عبر Remio؟
هل يمكن لوكيل أن يبدأ جلسة Remio بنفسه دون إنسان؟
كيف سيعرف المضيف أن وكيلاً متصل بدلاً من إنسان؟
هل سيستطيع الوكيل رؤية أو بلوغ ما لا تستطيعه الجلسة البشرية؟
أي نماذج ذكاء اصطناعي ستعمل مع Agent Runtime في Remio؟
حقيقي اليوم: سطح مكتب سريع وخاص لك. قريباً: سطح المكتب نفسه لوكلاء الذكاء الاصطناعي لديك.
ثبّت Remio لأسرع وأخصّ طريقة للوصول إلى جهاز Mac أو الكمبيوتر أو Linux الخاص بك — إدخال أصلي، ووصول أصلي إلى الشاشة، وتشفير من طرف إلى طرف، دون حاجة إلى حساب. لم يُطرح Agent Runtime الموصوف في هذه الصفحة، ولا نعد بموعد — لكن البنية نفسها هي بالضبط سبب اعتقادنا أنه جدير بالبناء.