تشخيص فشل وكيل الهاتف واستعادته: دليل تشغيل لمهام Android وFoneClaw

أوقف الفشل بأمان في أول خمس دقائق

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

اكتب النية الأصلية في جملة قصيرة: ماذا طلبت؟ وما النتيجة التي كنت تتوقعها؟ ثم سجّل آخر ما ظهر: رسالة خطأ، شاشة إذن، نتيجة أداة، أو توقف بلا نتيجة. الخطأ الظاهر ليس دائما السبب الجذري للوكيل. قد تظهر المشكلة في خطوة الإرسال بينما السبب الحقيقي كان اختيار جهة اتصال خاطئة أو فقدان إذن قبلها.

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

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

اجمع حزمة أدلة صغيرة

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

سجل أيضا خط سير الأدوات: هل قرأ الوكيل الشاشة؟ هل اختار أداة مراسلة؟ هل طلب إذنا؟ هل ظهرت موافقة؟ هل عاد بنتيجة فارغة؟ هذه التفاصيل تساعد في معرفة هل الفشل من النموذج، أم من توجيه القدرة، أم من الأذن، أم من واجهة التطبيق، أم من خدمة خارجية. ولأن سياق المسار الكامل يفيد في التشخيص، يركز AgentDebugX على فهم trajectory لا على لقطة واحدة فقط.

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

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

صنف طبقة الفشل

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

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

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

اعثر على أبكر خطوة سببية

بعد التصنيف، ارجع للخلف من الخطأ الظاهر إلى أبكر خطوة تفسر ما حدث. هذا هو جوهر مرحلة Attribute في حلقة Detect–Attribute–Recover–Rerun. إذا فشل الإرسال، لا تبدأ بالإرسال؛ اسأل: هل كان المستلم صحيحا؟ هل النص صحيح؟ هل الإذن موجود؟ هل التطبيق مفتوح؟ هل الموافقة ظهرت؟

استخدم فحوصا لا تحدث آثارا خارجية. افتح جهة الاتصال للقراءة بدل الاتصال. افحص وجود التقويم بدل إنشاء حدث جديد. اقرأ حالة Wi-Fi بدل تغييرها. الفحص المقروء يحافظ على الحالة ويعطيك دليل السبب. عندما تحدد سببين محتملين، سمّهما بثقة مختلفة: مثلا السبب الأقوى إذن الإشعارات مسحوب، والبديل شاشة التطبيق تغيرت بعد التحديث.

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

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

استعد دون تكرار آثار مكتملة

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

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

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

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

استخدم ضوابط FoneClaw للتشخيص والاسترداد

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

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

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

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

يمكنك مراجعة صفحة ميزات FoneClaw الرسمية لمعرفة عائلات القدرات الحالية، وصفحة ما الجديد في FoneClaw لمتابعة التحسينات العامة في الاستمرارية والاسترداد دون الحاجة إلى أرقام إصدارات داخلية.

اكتب بلاغ دعم مفيدا

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

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

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

امنع التكرار باختبارات قبول

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

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

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