أفضل أطر وكلاء الهاتف مفتوحة المصدر: Open-AutoGLM وMobilerun وmobile-use

اختر الإطار حسب المهمة

أفضل أطر وكلاء الهاتف مفتوحة المصدر لا تُختار كسباق واحد. ابدأ من نوع العمل الذي تريد بناءه: وكيل بصري يتصرف على شاشة هاتف، إطار اختبار وتحكم قابل للتتبع، أو طبقة أتمتة مهام جوال منظمة. الأسماء الثلاثة هنا مختلفة في نقطة البداية: Open-AutoGLM يركز على وكيل هاتف بصري مع تنفيذ عبر ADB على Android، وMobilerun يوفر إطارًا للتحكم والتتبع مع مسار Cloud مُدار منفصل، وMinitap mobile-use يقدم أتمتة واجهات جوال بلغة طبيعية مع مزودي نماذج قابلين للتهيئة.

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

قارن الإعداد والتنفيذ والنماذج والتراخيص

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

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

متى يناسبك Open-AutoGLM؟

اختر Open-AutoGLM عندما تريد بناء تجربة وكيل هاتف بصري حول فهم الشاشة وتنفيذ أفعال على جهاز Android متصل. يوضح المستودع أن Android يعتمد على ADB، مع متطلبات مثل وضع المطور وتصحيح USB وADB Keyboard. كما يذكر HDC لمسار HarmonyOS، ويعرض إعدادًا منفصلًا لـiOS باستخدام WebDriverAgent. هذه ليست وعودًا بتكافؤ كامل بين الأنظمة؛ كل مسار له إعداد وتنفيذ خاصان.

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

متى تختار Mobilerun Framework أو Cloud؟

Mobilerun، المعروف سابقًا باسم DroidRun، مناسب عندما تريد إطارًا برمجيًا للتحكم في الهاتف وفحص التنفيذ. يوثق CLI وPython، وشجرة الوصول ولقطات الشاشة واختيار مزود النموذج والمخرجات المنظمة. على Android تحتاج ADB وخدمة Portal، بينما iOS له إعداد منفصل. أما Cloud فيقدم مسارًا مُدارًا بأجهزة متصلة أو مستضافة وواجهات API؛ تقليل عبء البنية لا يلغي شروط الخدمة أو مسؤولية فحص التنفيذ.

تضيف ملاحظات إصدار 14 أكتوبر 2026 بتوقيت UTC، الموافق 15 أكتوبر في الصين فحصًا مهمًا لاختيار الهاتف: يستخدم mobilerun run التحديد الصريح عبر -d أولًا، ثم ANDROID_SERIAL، ثم الجهاز المتصل الوحيد. إذا وُجدت عدة أجهزة دون اختيار، يتوقف بخطأ بدل استخدام أول جهاز. افحص قائمة الأجهزة المتصلة وحدد المقصود عمدًا قبل التشغيل.

وفي FastAgent، تُنفذ أول كتلة function_calls فقط وتُتجاهل الكتل اللاحقة، ويُتخطى باقي الكتلة بعد فشل استدعاء. لا يعني ذلك التراجع عما نُفذ سابقًا أو تنفيذ مجموعة الأفعال كوحدة لا تتجزأ. عند الفشل، أوقف المحاولة وافحص الشاشة والنتيجة الفعلية، ثم أصلح السبب قبل الاستئناف؛ لا تكرر المهمة كاملة دون مراجعة.

ولترقية إعداد قديم، توضح تغييرات 5 أكتوبر الخاصة ببطاقات التطبيقات أن المسارين أصبحا app_cards_dir/android/app_cards.json وapp_cards_dir/ios/app_cards.json. يُتجاهل app_cards.json الموجود مباشرة في app_cards_dir. انقل البطاقات إلى المنصة الصحيحة، وطابق معرّفات Android مع بطاقاته ومعرّفات حزم iOS مع بطاقاتها. يختار الإعداد إصدار Portal المناسب، ويُبقي الإصدار الأحدث الموجود بدل استبداله بأقدم؛ لا تفرض رقم توافق من تخمينك.

قد يعيد Portal تفعيل خدمة الوصول ولوحة مفاتيحه أثناء التشغيل. إذا أردت سحب هذا الوصول، أوقف الوكيل أولًا ثم راجع الحالة الفعلية على الهاتف؛ لا تعطل Play Protect أو تتجاوز تحذيرًا أمنيًا كي يستمر التشغيل. وفي مسار Cloud، تُراجع تغييرات توافق شجرة الواجهة وسلوك النقر والكتابة دون إعادة محاولة تلقائية ضمن صيانة SDK، لا بوصفها ضمانًا لنجاح كل جهاز أو تطبيق. يفيد التتبع عبر Arize Phoenix أو Langfuse وحفظ مسارات التنفيذ في تحديد موضع الفشل، لكنه لا يصلحه تلقائيًا.

متى يناسبك Minitap mobile-use؟

يناسب Minitap mobile-use من يريد وصف مهام جوال بلغة طبيعية مع مزودي نماذج قابلين للتهيئة واستخراج منظم من الواجهة. يوضح المستودع أن Android يعمل عبر ADB على أجهزة فعلية أو محاكيات، وأن مسار البدء السريع باستخدام Docker موجه إلى Android. أما iOS فاقرأ تفاصيل الإعداد بدقة: README يذكر محاكيات iOS على macOS، ويقول إن أجهزة iOS الفيزيائية غير مدعومة حاليًا.

هذه النقطة مهمة لأن بعض النصوص العامة حول المنتج قد تبدو أوسع من إعداد المستودع. للقرار العملي، اعتمد على ما ستشغله أنت: Android فعلي، أو محاكي Android، أو محاكي iOS على macOS. كما يذكر المشروع حدودًا مع الألعاب التي لا توفر معلومات كافية في شجرة الوصول. لذلك اختر mobile-use للمهام المنظمة التي يمكن للنظام رؤيتها وفحصها، لا للواجهات التي تخفي حالتها عن طبقة الوصول.

اختبر مهمة قابلة للتراجع وافحص الفشل

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

1. حدد البيئة: اختر جهازًا أو محاكيًا واحدًا ونموذجًا واحدًا، وافحص قائمة الاتصال قبل أي فعل.
2. ثبّت الهدف: في Mobilerun استخدم -d أو تحقق من ANDROID_SERIAL، ولا تعتمد على ترتيب الأجهزة.
3. راجع الإعداد: افحص حالة الخدمة والأذونات وتعريف التطبيق؛ وفي Mobilerun راجع مجلد بطاقات المنصة بعد الترحيل.
4. نفّذ طلبًا محدودًا: اطلب فتح التطبيق المختار فقط، ثم قارن النتيجة المرئية بالهدف.
5. افحص التتبع: راجع المدخلات والاستدعاءات وما نجح فعلًا، لا وصف النموذج وحده.
6. توقف عند الخلل: إذا استُهدف جهاز خاطئ أو فشلت خطوة، أوقف التشغيل وافحص الأثر قبل إصلاح السبب وإعادة الجزء غير المكتمل.

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

إذا أردت توسيع هذه التجربة، فدليل معيار تقييم وكيل هاتف Android: كيف نختبر الوكلاء في 2026؟ يربط نجاح المهمة بالسلامة والاستقرار والتعافي، لا بسرعة الرد وحدها.

اختر مسار Android جاهزًا بدل إطار

إذا كان هدفك استخدام وكيل على هاتفك، لا بناء إطار وإدارة اتصال ADB والنموذج وسجلات التتبع، فقد يناسبك المسار الجاهز. FoneClaw ليس إطارًا مفتوح المصدر ضمن هذه المقارنة، ولا نقدمه بوصفه تكاملًا أصليًا مع Open-AutoGLM أو Mobilerun أو mobile-use. نوفر تطبيق وكيل Android مع نموذج افتراضي مجاني ومسارات نماذج متوافقة قابلة للتهيئة وأدوات هاتف مدعومة.

في FoneClaw يفهم النموذج المهيأ الطلب ويخطط، وتنفذ الأدوات المفعّلة الأفعال وفق أذونات Android وسياسة الموافقة الخاصة بها. يمكن اختيار مهمة مدعومة مثل فتح تطبيق أو استخدام سياق شاشة مختار، ثم فحص النتيجة. لا يعني ذلك تحكمًا عامًا في كل التطبيقات، ولا ظهور طلب موافقة جديد لكل فعل. كما أن تشغيل الأداة على الهاتف لا يثبت بقاء الاستدلال محليًا؛ مسار النموذج مهم.

لفهم هذا الفصل، يشرح دليل تحكم وكيل الذكاء الاصطناعي في هاتف Android: من النية إلى التنفيذ الموثوق دور النموذج والأداة والإذن والنتيجة. ويمكنك مراجعة ميزات FoneClaw قبل تحديد ما إذا كانت حاجتك تستدعي بناء بنية إطار مفتوح المصدر أو استخدام تطبيق جاهز ضمن نطاقه المدعوم.