معيار تقييم وكيل هاتف Android: كيف نختبر الوكلاء في 2026؟
إطار عملي لتقييم وكيل هاتف Android في 2026: نجاح المهمة، الأثر الجانبي، الأذونات، الموافقات، الاسترداد، التعميم، ومصفوفة اختبار FoneClaw الحالية.
- معيار تقييم وكيل هاتف Android يجب أن يقيس النتيجة المتحققة وسلامة الطريق إليها: فهم الهدف، تنفيذ الأثر الصحيح، الموافقة، التحقق، والاسترداد.
- B-MoCA وMobileWorld وKnowU-Bench وPhoneHarness تكشف فجوات مختلفة: تعميم إعدادات الجهاز، المهام الطويلة، التخصيص والموافقة، والتحقق من الآثار الجانبية.
- نسبة نجاح المهمة وحدها لا تكفي؛ نحتاج مقاييس للأخطاء المؤثرة، التدخل البشري، الاسترداد، زمن التنفيذ، التكلفة، وجودة السجل.
- في FoneClaw نستخدم السلوك الحالي المتاح كأساس لمصفوفة اختبار عملية تشمل الشاشة المرئية، DND، الصوت، Bluetooth، الرسائل، المهام، الأذونات، الإيقاف، واستمرارية المهمة.
ما الذي يجب أن يقيسه معيار وكيل هاتف Android؟
عندما نقيّم وكيل هاتف Android، لا يكفي أن نسأل: هل ضغط الأزرار الصحيحة؟ السؤال الأدق هو: هل فهم هدف المستخدم، نفذ الأثر الصحيح على الهاتف، استخدم أقل سلطة كافية، طلب الموافقة في مكانها، تحقق من النتيجة، واستعاد المسار عند الفشل؟ من بناء FoneClaw تعلمنا أن النقرة المعقولة على الشاشة قد تبدو ناجحة في التسجيل، بينما النتيجة الفعلية ما زالت خاطئة أو ناقصة.
معيار تقييم وكيل هاتف Android يجب أن يبدأ من النتيجة المتحققة. إذا كانت المهمة تفعيل Do Not Disturb، فالنجاح هو تغير حالة الهاتف إلى الوضع المطلوب لمدة مناسبة، لا مجرد فتح شاشة الإعداد. إذا كانت المهمة تجهيز رسالة، فالنجاح هو ظهور المسودة الصحيحة للمستلم الصحيح، ومعرفة متى تحتاج الإرسال إلى موافقة. وإذا كانت المهمة قراءة شاشة، فالنجاح هو التقاط سياق حديث لا معلومات قديمة.
لذلك نبني إطار التقييم حول النتيجة والطريق معا. النتيجة تقول هل اكتملت المهمة. الطريق يقول هل احترم الوكيل الأذونات، هل انتظر عند الفعل المؤثر، هل تجنب التخمين عند الغموض، وهل ترك سجلا يمكن مراجعته. ولمن يريد تحويل هذه الفكرة إلى حلقة اختبار وتحسين مستمرة، يشرح مقال وكيل الهاتف ذاتي التحسين: إصدارات المهارات والاختبارات والتراجع كيف نحكم تطور الاختبارات والمهارات عبر الإصدارات.
خريطة معايير وكلاء الهاتف في 2026
توجد عدة معايير بحثية مفيدة في 2026، وكل واحد منها يضيء زاوية مختلفة. لا نعاملها كلوحة ترتيب واحدة، لأن الأجهزة والتطبيقات والمهام وسياسات القياس تختلف. نستخدمها كخريطة أسئلة: هل يعمم الوكيل على إعدادات مختلفة؟ هل يصمد في مهمة طويلة؟ هل يحترم تفضيلات المستخدم؟ هل يثبت الأثر الجانبي؟
| المعيار | ما الذي يختبره؟ | الدروس العملية لوكيل الهاتف |
|---|---|---|
| B-MoCA | في ورقة B-MoCA المنشورة في PMLR توجد 131 مهمة Android يومية مع تغيير إعدادات الجهاز مثل تخطيط الواجهة واللغة. | اختبار وكيل الهاتف يحتاج تنويع اللغة والتخطيط والإعدادات، لأن نجاحه على جهاز واحد لا يثبت تعميمه. |
| MobileWorld | تصف ورقة MobileWorld في ACL 2026 201 مهمة عبر 20 تطبيقا، بمتوسط 27.8 خطوة، و62.2% منها متعددة التطبيقات، وتضيف تفاعل المستخدم وفئات مهام مدعومة بـMCP. | المهام الطويلة تكشف ضعف الذاكرة والحالة والاسترداد، خصوصا عندما ينتقل الوكيل بين تطبيقات متعددة. |
| KnowU-Bench | يعرض KnowU-Bench كبحث أولي 42 مهمة GUI عامة، و86 مهمة شخصية، و64 مهمة مبادرة، مع إخفاء ملف المستخدم وكشف سجلات سلوكية. | التخصيص لا يقاس فقط بالإنجاز؛ يجب قياس الاستيضاح، الموافقة على التدخل، وضبط النفس بعد رفض المستخدم. |
| PhoneHarness | يقدم PhoneHarness كبحث أولي مزيجا من GUI وCLI وأدوات المضيف، ويسجل الآثار الجانبية المرصودة وآثار تنفيذ قابلة للتدقيق. | الاختبار العملي يحتاج التحقق من الأثر، لا مجرد تقييم نصي أو حكم نموذج على لقطة شاشة. |
هذه المعايير تساعدنا على بناء أسئلة منتج أفضل. B-MoCA يذكرنا بتغيير الإعدادات واللغة. MobileWorld يضغط على المهام الطويلة العابرة للتطبيقات. KnowU-Bench يرفع أهمية التخصيص والموافقة. PhoneHarness يضع الأثر الجانبي والسجل في المركز. وعند تقييم اكتشاف الأدوات والموارد، يفيد ربط ذلك بإطار ثقة مستقل مثل Agentic Resource Discovery: اكتشاف موارد الوكلاء من ai-catalog.json إلى تفويض الهاتف.
ستة أبعاد لاختبار وكيل واجهة Android
مجموعة اختبارات الهاتف الجيدة لا تزيد عدد المهام عشوائيا؛ بل تغير أبعادا محددة. البعد الأول هو تهيئة الجهاز: اللغة، حجم الخط، ترتيب التطبيقات، أذونات النظام، وضع الشبكة، ونسخة التطبيق. وكيل Android الذي يحفظ مسارا واحدا على جهاز واحد سيبدو قويا في العرض، ثم يتعثر عند أول تغيير بسيط.
البعد الثاني هو أفق المهمة. مهمة من خطوة واحدة مثل فتح تطبيق تختلف عن مهمة طويلة تبدأ من شاشة، تنتقل إلى إعداد، ثم تعود إلى مسودة أو نتيجة. البعد الثالث هو عدد التطبيقات: تطبيق واحد، تطبيقان، أو مسار متعدد. لا يعني عدد الخطوات دائما صعوبة أعلى؛ أحيانا تكون خطوة واحدة حساسة أصعب من عشر خطوات قراءة.
البعد الرابع هو وضوح النية. “افتح Discord” طلب واضح، بينما “جهز هاتفي للاجتماع” يحتاج استيضاحا: هل تريد Do Not Disturb؟ مدة محددة؟ خفض الصوت؟ تذكيرا؟ البعد الخامس هو سطح الإجراء: GUI مرئي، وظيفة منظمة، أداة مضيف، أو خليط بينها. البعد السادس هو نوع الأثر: قراءة، تغيير قابل للرجوع، إرسال خارجي، حذف، أو مشاركة بيانات.
في كل بعد يجب تغيير عامل واحد قدر الإمكان. اختبر المهمة نفسها بلغة مختلفة، ثم بتطبيق مختلف، ثم بإذن مفقود، ثم بمقاطعة مستخدم. بهذه الطريقة تعرف هل فشل الوكيل بسبب فهم النية، أم بسبب الشاشة، أم بسبب الإذن، أم بسبب الاسترداد.
مقاييس تتجاوز نسبة نجاح المهمة
نسبة نجاح المهمة مفيدة كبداية، لكنها تخفي أسئلة مهمة. النجاح الكامل يعني تحقق النتيجة المطلوبة دون أثر جانبي غير مقصود. النجاح الجزئي يعني الوصول إلى نقطة مفيدة مع حاجة إلى تدخل. الفشل الآمن يعني توقف الوكيل قبل الضرر وشرح السبب. أما الفشل المؤثر فهو تنفيذ إجراء خاطئ، أو إرسال إلى جهة خاطئة، أو تغيير إعداد غير مقصود.
نقيس أيضا نقاط التحقق الوسطى: هل فهم الوكيل الطلب؟ هل اختار الأداة المناسبة؟ هل طلب الإذن في الوقت الصحيح؟ هل عرض الموافقة قبل الأثر؟ هل تحقق من النتيجة بعد التنفيذ؟ هذه المقاييس تكشف أين يجب تحسين النظام. إذا كان الفشل دائما في مرحلة قراءة الشاشة، فهذا يختلف عن فشل في قرار الموافقة.
هناك مقاييس عملية لا تقل أهمية: عدد تدخلات المستخدم، عدد المحاولات، زمن التنفيذ، تكلفة النموذج أو الأدوات، استهلاك البطارية عند الاختبار الطويل، وجودة السجل. سياسة الإعادة يجب أن تكون ثابتة: كم محاولة مسموحة؟ متى نعد المهمة فاشلة؟ متى نحظر الإعادة لأن الأثر الخارجي قد حدث؟
لا نعتمد على حكم نموذج لغوي وحده لإثبات النجاح. نحتاج دليلا من الهاتف: حالة إعداد، وجود مسودة، لقطة شاشة، سجل إجراء، أو نتيجة يمكن للمستخدم رؤيتها. وللتعمق في ربط الهوية والأذونات وسجلات التدقيق، يقدم مقال هوية وكيل الذكاء الاصطناعي: الأذونات وسجل التدقيق والموافقة لكل أداة أساسا مفيدا لبناء بطاقة قياس قابلة للمراجعة.
اختبار الموافقات والأذونات وضبط النفس والإيقاف
الأمان في معيار وكلاء الذكاء الاصطناعي 2026 يجب أن يكون سلوكا مقاسا، لا فقرة وصفية. نبدأ بأقل سلطة كافية: هل طلب الوكيل الإذن الذي يخدم المهمة فقط؟ ثم توقيت الموافقة: هل ظهرت قبل الإرسال أو المشاركة أو التغيير؟ ثم الاستيضاح: هل سأل عند الغموض بدلا من التخمين؟
KnowU-Bench مهم هنا لأنه يختبر التخصيص والمبادرة والموافقة وضبط النفس بعد رفض المستخدم. هذا يطابق ما نراه في الهاتف: الوكيل قد يعرف عادة المستخدم، لكن معرفة العادة لا تعطيه حق تنفيذ فعل مؤثر في لحظة محددة. إذا رفض المستخدم، يجب أن يتوقف المسار أو يعرض بديلا منخفض الأثر، لا أن يعيد المحاولة بصيغة مختلفة.
نختبر زر الإيقاف كذلك. أثناء تنفيذ مهمة طويلة، هل يستطيع المستخدم إيقاف الوكيل؟ هل يعرف النظام ما تم وما لم يتم؟ هل يسجل سبب التوقف؟ وهل يعود إلى حالة مفهومة عند الاستئناف؟ هذه أسئلة حقيقية في الهاتف، خصوصا عندما تكون الشاشة صغيرة والمستخدم ينتقل بين تطبيقات.
تصميم الموافقة نفسه يستحق اختبارا مستقلا: هل النص واضح؟ هل يذكر الهدف والنتيجة؟ هل يميز المسودة عن التنفيذ؟ لهذا نحيل تفاصيل تصميم الموافقة إلى واجهة موافقة وكيل الذكاء الاصطناعي على الهاتف: الثقة والسبب والاسترداد، بينما نستخدم هنا الموافقة كجزء من بطاقة القياس.
كيف نقيّم مهام FoneClaw الحالية؟
في FoneClaw لا ننشر هنا درجة معيارية غير مقاسة؛ نعرض طريقة تقييم عملية نستطيع نحن والقراء استخدامها. وفق أحدث معلومات FoneClaw المتاحة حتى الآن، يعطي خط الأساس الحالي المتاح من FoneClaw أساسا واضحا للاختبار: مساعد عائم، إرفاق الشاشة الحالية، استمرارية المهمة، الموافقات والإيقاف، استرداد الأذونات، تحسينات DND والصوت ووضع الاجتماع وموثوقية لقطات الشاشة، وإجراءات سريعة.
نبدأ باختبارات قراءة وحالة: أرفق الشاشة الحالية، اطلب تلخيص ما يظهر، تحقق من أن الوكيل يستخدم السياق الحديث لا شاشة قديمة. ثم ننتقل إلى إجراءات قابلة للرجوع: ضبط مستوى الصوت، فحص Bluetooth، تفعيل Do Not Disturb لمدة قصيرة، أو أخذ لقطة شاشة. هنا نقيس النتيجة والتحقق والاسترداد عند نقص الإذن.
بعد ذلك نختبر أفعالا لها أثر خارجي مثل الرسائل أو المهام أو التقويم. نستخدم شروطا واضحة: جهة صحيحة، نص كامل، مسودة مرئية، موافقة قبل الإرسال، وتحقق من النتيجة. في الاختبارات متعددة الخطوات، ننتقل بين Home والمساعد العائم لنرى هل تبقى حالة المهمة مفهومة. في اختبار الإيقاف، نقطع المهمة قبل الأثر ثم نراجع السجل.
| فئة الاختبار | مثال | ما نقيسه؟ |
|---|---|---|
| قراءة مرئية | إرفاق شاشة إعدادات أو تطبيق | حداثة السياق ودقة التفسير |
| تحكم قابل للرجوع | الصوت، Bluetooth، DND قصير | الإذن، التنفيذ، التحقق، الاسترداد |
| أثر خارجي | مسودة رسالة أو مهمة | الموافقة، صحة المستلم أو التفاصيل، السجل |
| استمرارية | الانتقال بين Home والمساعد العائم | حفظ حالة المهمة وفهم سبب الانتظار |
| فشل مقصود | سحب إذن أو تغيير الشاشة | شرح السبب، مسار الاسترداد، منع الإجراء الخاطئ |
على صفحة ميزات FoneClaw نعرض القدرات الحالية بلغة مستقرة، بما في ذلك 100+ أداة مدمجة ومسارات Android مدعومة. ويمكن تحويل بعض هذه الاختبارات إلى سيناريوهات للمستخدم، مثل فحص الأذونات والتطبيقات المخفية الموضح في فحص صحة هاتف Android بالذكاء الاصطناعي: تدقيق الأذونات والتطبيقات المخفية مع FoneClaw.
بروتوكول قابل للتكرار لاختبار وكيل الهاتف
لبناء اختبار قابل للتكرار، جمّد البيئة أولا: نوع الجهاز، إصدار Android، اللغة، حجم الخط، حالة الشبكة، إصدار التطبيقات، حالة تسجيل الدخول، وسياسة إعادة المحاولة. ثم اكتب الحالة الابتدائية والنتيجة المتوقعة. لا تقل “اضبط الهاتف للاجتماع” فقط؛ اكتب: Do Not Disturb مفعل لمدة 30 دقيقة، الصوت عند مستوى محدد، والنتيجة ظاهرة في الإعداد.
- ثبّت الجهاز واللغة والتطبيقات والإذن الابتدائي.
- عرّف نية المستخدم والحالة المتوقعة بدقة.
- غيّر بعدا واحدا فقط في كل جولة: لغة، تخطيط، إذن، تطبيق، أو مقاطعة.
- سجل كل أداة وموافقة وتدخل بشري.
- تحقق من الأثر على الهاتف لا من النص فقط.
- صنّف الفشل: فهم، شاشة، أداة، إذن، موافقة، استرداد، أو أثر جانبي.
- انشر حدود الاختبار وسياسة الإعادة مع النتيجة.
ابدأ بمهمة قابلة للرجوع: فحص Bluetooth، ضبط الصوت، أو DND لمدة قصيرة. بعد ذلك أضف رسالة مسودة، ثم مهمة متعددة التطبيقات، ثم إذنا مفقودا. بهذه الطريقة لا يتحول المعيار إلى عرض ناجح واحد، بل إلى نظام قياس يستطيع المنتج التعلم منه. وعندما تدخل النتائج في حلقة تحسين منظمة، يعود مقال وكيل الهاتف ذاتي التحسين: إصدارات المهارات والاختبارات والتراجع إلى الجانب الحاكم للإصدارات والتراجع.