أفضل أطر وكلاء الهاتف مفتوحة المصدر: Open-AutoGLM وMobilerun وmobile-use
دليل اختيار عملي بين Open-AutoGLM وMobilerun وMinitap mobile-use حسب الجهاز ونظام التنفيذ والنموذج والتراخيص والتتبع وتكلفة الصيانة.
- Open-AutoGLM يناسب من يريد إطار وكيل بصري للهاتف مع تنفيذ عبر ADB على Android وخيارات نموذج مستضاف أو ذاتي التشغيل.
- Mobilerun Framework مناسب لبناء اختبارات وتحكم برمجي مع لقطات شاشة وشجرة وصول وتتبع، بينما Mobilerun Cloud مسار تشغيلي مُدار مختلف.
- Minitap mobile-use يلائم مهام واجهة منظمة مع LLM قابل للتهيئة، مع دعم Android عبر ADB وحدود واضحة حول iOS الفيزيائي.
- الأطر المفتوحة لا تلغي تكلفة النموذج أو الجهاز أو الصيانة؛ ومن لا يريد نشر إطار يمكنه اختيار FoneClaw كمسار Android جاهز بمهام مدعومة وموافقات.
اختر الإطار حسب المهمة
أفضل أطر وكلاء الهاتف مفتوحة المصدر لا تُختار كسباق واحد. ابدأ من نوع العمل الذي تريد بناءه: وكيل بصري يتصرف على شاشة هاتف، إطار اختبار وتحكم قابل للتتبع، أو طبقة أتمتة مهام جوال منظمة. الأسماء الثلاثة هنا مختلفة في نقطة البداية: Open-AutoGLM يركز على وكيل هاتف بصري مع تنفيذ عبر ADB على Android، وMobilerun يوفر Framework للتحكم والتتبع مع مسار Cloud مُدار منفصل، وMinitap mobile-use يقدم أتمتة واجهات جوال بلغة طبيعية مع مزودي نماذج قابلين للتهيئة.
| اختره عندما تريد | المرشح الأقرب | ما تتحقق منه أولاً |
|---|---|---|
| تجربة وكيل هاتف بصري مرتبط بنموذج GUI | Open-AutoGLM | إعداد ADB أو HDC، مسار النموذج، وتدخل الإنسان في الدخول والتحقق |
| إطار تحكم واختبار مع tracing ونتائج منظمة | Mobilerun Framework | Portal accessibility، مزود النموذج، ومسار تتبع التنفيذ |
| مهام واجهة منظمة واستخراج بيانات باستخدام LLM | Minitap mobile-use | نوع الجهاز، حدود iOS، ومعلومات accessibility المتاحة |
لا تجعل كلمة مفتوح المصدر تختصر القرار. الترخيص يخص المستودع، أما النموذج، والجهاز، والسحابة، والمحاكيات، وأعمال الصيانة فلها تكلفة وشروط منفصلة.
قارن الإعداد والتنفيذ والنماذج والتراخيص
افصل أربعة أشياء قبل المقارنة: إطار العمل الذي يدير الوكيل، النموذج الذي يفهم الشاشة ويقرر الخطوة، آلية تنفيذ الفعل على الهاتف، ومكان تشغيل البنية كلها. قد يكون الإطار مفتوح المصدر بينما تستخدم نموذجاً مدفوعاً أو هاتفاً سحابياً أو خادماً خاصاً. وقد يعمل Runtime على جهازك بينما الاستدلال نفسه يتم عبر API خارجي.
| المحور | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| تنفيذ الهاتف | ADB على Android، وتوثيق HDC لـHarmonyOS، مع إعداد WebDriverAgent منفصل لـiOS | ADB وPortal accessibility على Android، ومسار Portal منفصل لـiOS | ADB لأجهزة ومحاكيات Android؛ iOS simulators على macOS، ولا يدعم iOS الفيزيائي حالياً وفق README |
| النموذج | نقطة نهاية نموذج، سواء API مستضاف أو استدلال ذاتي | اختيار مزود نموذج ضمن Framework؛ المحلي لا يعني استدلالاً محلياً تلقائياً | مزودو LLM قابلون للتهيئة مع مهام واستخراج منظم |
| التتبع والفحص | يركز على سلسلة الوكيل والتدخل البشري في الحالات الحساسة | يوثق tracing عبر Arize Phoenix وLangfuse وحفظ trajectories | يركز على مهام منظمة ومخرجات يمكن فحصها |
| الترخيص | Apache-2.0 للمستودع | MIT للمستودع | Apache-2.0 للمستودع |
| تكلفة التشغيل | نماذج، جهاز متصل أو بيئة نشر، وصيانة إعدادات | Framework محلي أو Cloud مُدار بتبعيات مختلفة | نماذج، جهاز أو محاكي، وحدود بيانات accessibility |
إذا كان قرارك متعلقاً بالنموذج نفسه، فافصل ذلك عن قرار الإطار. دليل أفضل نماذج الذكاء الاصطناعي للوكلاء في 2026: اختر حسب مهمة الهاتف يساعدك على مقارنة مسار النموذج من دون خلطه بطبقة تنفيذ الهاتف.
متى يناسبك Open-AutoGLM؟
اختر Open-AutoGLM عندما تريد بناء تجربة وكيل هاتف بصري حول فهم الشاشة وتنفيذ أفعال على جهاز Android متصل. يوضح المستودع أن Android يعتمد على ADB، مع متطلبات مثل وضع المطور وUSB debugging وADB Keyboard. كما يذكر HDC لمسار HarmonyOS، ويعرض إعداداً منفصلاً لـiOS باستخدام WebDriverAgent. هذه ليست وعوداً بتكافؤ كامل بين الأنظمة؛ كل مسار له إعداد وتنفيذ خاصان.
نقطة القوة هنا هي القرب من نموذج GUI ووظيفة الوكيل البصري. كما يوضح المشروع إمكان استخدام API نموذج مستضاف أو استدلال ذاتي، لذلك لا تحتاج بالضرورة إلى GPU محلية إذا اخترت المسار المستضاف. في المقابل، عليك إدارة مفاتيح النموذج، الجهاز المتصل، أذونات المطور، وتدخل الإنسان عند تسجيل الدخول أو captcha أو الأفعال الحساسة. هذا مناسب للفرق التي تريد بحثاً أو نموذجاً أولياً عميقاً، لا مجرد زر جاهز لمستخدم نهائي.
متى تختار Mobilerun Framework أو Cloud؟
Mobilerun، المعروف سابقاً باسم DroidRun، مناسب عندما تريد Framework برمجياً للتحكم في الهاتف وفحص التنفيذ. يذكر المستودع CLI وPython، واستخدام accessibility trees ولقطات الشاشة، واختيار مزود النموذج، ومخرجات منظمة. على Android تحتاج ADB وخدمة Portal accessibility، بينما iOS له إعداد Portal منفصل. لذلك لا تعامل دعم iOS كنسخة مطابقة من Android؛ افحص بيئة الجهاز التي ستستخدمها فعلاً.
الفصل المهم هنا هو بين Mobilerun Framework وMobilerun Cloud. Framework يعني أنك تشغل الوكيل على جهازك وتدير تبعياته ونموذجه وأجهزته. أما Cloud فيقدم مساراً مُداراً مع هواتف محلية متصلة أو هواتف افتراضية أو فيزيائية مستضافة وواجهات API. هذا قد يقلل عبء البنية، لكنه يضيف شروط سحابة وتشغيل مختلفة. إذا كان هدفك تقييم الفشل، فميزة tracing عبر Arize Phoenix أو Langfuse وحفظ trajectories تجعل Mobilerun جذاباً للفرق التي تحتاج تفتيشاً منهجياً لا مجرد تنفيذ.
متى يناسبك Minitap mobile-use؟
يناسب Minitap mobile-use من يريد وصف مهام جوال بلغة طبيعية مع مزودي LLM قابلين للتهيئة واستخراج منظم من الواجهة. المستودع يوضح أن Android يعمل عبر ADB على أجهزة فعلية أو محاكيات، وأن Docker quickstart موجه لـAndroid. أما iOS فاقرأ تفاصيل الإعداد بدقة: README يذكر iOS simulators على macOS، ويقول صراحة إن أجهزة iOS الفيزيائية غير مدعومة حالياً.
هذه النقطة مهمة لأن بعض النصوص العامة حول المنتج قد تبدو أوسع من إعداد المستودع. للقرار العملي، اعتمد على ما ستشغله أنت: Android فعلي، Android emulator، أو iOS simulator على macOS. كما يذكر المشروع حدوداً مع الألعاب التي لا توفر معلومات accessibility-tree كافية. لذلك اختر mobile-use للمهام المنظمة التي يمكن للنظام رؤيتها وفحصها، لا للواجهات التي تخفي حالتها عن طبقة الوصول.
اختبر مهمة قابلة للتراجع وافحص الفشل
لا تحتاج إلى معيار ضخم لتقرر من أين تبدأ. اختر مهمة واحدة منخفضة المخاطر، مثل فتح تطبيق ملاحظات تجريبي، قراءة نص ظاهر، إنشاء مسودة ملاحظة غير حساسة، ثم العودة إلى الشاشة السابقة. هذا اختبار مقترح، لا نتيجة ندعي أننا أجريناها. الهدف أن ترى كيف يفهم الإطار الشاشة، كيف يختار الفعل، كيف يسجل الخطوات، وكيف يتعامل مع فشل أو نقص إذن.
- ثبت بيئة واحدة فقط: جهاز Android واحد أو محاكي واحد، ونموذج واحد، ومهمة واحدة.
- سجل المدخلات: صورة الشاشة أو accessibility tree أو الأوامر التي وصلت إلى الوكيل.
- افحص التنفيذ: هل الفعل تم عبر ADB أو accessibility أو سحابة؟ وهل النتيجة مرئية؟
- أدخل تعطيلاً مقصوداً: تطبيق مغلق، إذن ناقص، أو عنصر واجهة غير ظاهر.
- قارن التعافي: هل طلب الإطار تدخلاً؟ هل حفظ trace؟ هل تجنب تكرار الفعل؟
إذا أردت تحويل هذه التجربة إلى منهج تقييم أوسع، فدليل معيار تقييم وكيل هاتف Android: كيف نختبر الوكلاء في 2026؟ يوضح كيف نربط نجاح المهمة بالسلامة والاستقرار والتعافي، لا بسرعة الرد وحدها.
اختر مسار Android جاهزاً بدل إطار
إذا كان هدفك استخدام وكيل على هاتفك اليوم، لا بناء إطار أو إدارة نموذج وبنية ADB وسجلات tracing، فالمسار الجاهز قد يكون أنسب. FoneClaw ليس إطاراً مفتوح المصدر في هذه المقارنة، ولا نقدمه كبديل بحثي لـOpen-AutoGLM أو Mobilerun أو mobile-use. دوره مختلف: تطبيق Android جاهز مع نموذج افتراضي مجاني، ومسارات نماذج قابلة للتهيئة، وأدوات هاتف مدعومة تعمل ضمن أذونات وموافقات واضحة.
هذا يناسب من يريد فتح تطبيق، قراءة سياق شاشة مختار، تلخيص رسائل SMS ضمن أذونات واضحة، إنشاء ملاحظة، أو تنفيذ مهمة مدعومة مع مراجعة مرئية. تشغيل المهمة على الهاتف لا يعني أن كل الاستدلال يبقى محلياً؛ مسار النموذج الذي تختاره مهم. كما أن المهام المجدولة غير المراقبة لها نطاق محدود، وليست وعداً بتحكم عام في كل تطبيق. لفهم الفرق بين النية والتنفيذ على الهاتف، راجع تحكم وكيل الذكاء الاصطناعي في هاتف Android: من النية إلى التنفيذ الموثوق. ويمكنك مراجعة ميزات FoneClaw لمعرفة مسار المنتج الجاهز قبل أن تقرر إن كنت تحتاج إطاراً مفتوح المصدر أم تطبيقاً عملياً.