قائمة انتظار مهام وكيل الذكاء الاصطناعي على Android

لماذا تحتاج محادثات الوكيل إلى قائمة مهام حقيقية؟

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

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

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

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

حالات التشغيل والانتظار والموافقة والإذن والإيقاف والإكمال

أول علامة على أن وكيل Android يتعامل بجدية مع محادثات متعددة هي أن الحالات تظهر بوضوح. لا يكفي أن يقول “أعمل على ذلك”. يحتاج المستخدم أن يرى هل المهمة تعمل الآن، تنتظر موافقة، تحتاج إذنًا، توقفت بطلبه، أم اكتملت بنتيجة يمكن التحقق منها. هذا يجعل المقاطعات مفهومة ويمنع تحويل الانتظار إلى موافقة ضمنية.

هذه الحالات لا تصنع معيارًا عالميًا لكل المنتجات، لكنها تمنح نموذجًا عمليًا لتقييم وكيل الهاتف. “في الانتظار” ليست “فشلت”، و“تنتظر موافقة” ليست “مسموح لها بالتنفيذ”، و“مكتملة” تحتاج نتيجة يمكن للمستخدم فهمها. عندما تكون الحالات مفصولة، يمكن لمحادثة ثانية أن تعمل دون أن تسحب موافقة الأولى أو سياقها.

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

هوية المحادثة وعزل المهمة

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

مثال بسيط: في محادثة “الاجتماع” تطلب ضبط Do Not Disturb لمدة ثلاثين دقيقة. في محادثة “العائلة” تطلب تجهيز رسالة. إذا ظهر زر موافقة بعد التبديل بين المحادثتين، يجب أن يوضح الزر أنه يخص ضبط DND في جلسة الاجتماع، لا إرسال الرسالة في جلسة العائلة. العنوان وحده لا يكفي؛ ينبغي عرض الهدف، الأثر، والجهة أو الإعداد المعني.

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

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

موافقة مرتبطة بالجلسة دون تكرار واجهة الموافقة

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

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

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

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

فرق الوكلاء المتوازية مقابل قائمة مهام الهاتف

التوازي في عالم الوكلاء لا يعني أن كل أفعال الهاتف يجب أن تعمل في اللحظة نفسها. في إعلان MiniMax Agent Team تظهر فكرة الأدوار مثل قائد، عامل، ومراجع لمهام طويلة؛ هذا مناسب لبحث أو كود أو تقرير يحتاج توزيعًا داخليًا ومراجعة. هناك جلسة طويلة، حالة وسيطة، وقدرة على التوقف أو الاستئناف عند تدخل الإنسان.

وفي اتجاه آخر، تتحدث OPPO في إعلان OPPO مع Google Cloud حول AIOS عن قابلية تواصل الوكلاء واتجاهات تعاون الجهاز والسحابة والذاكرة والخصوصية. كما يوضح مستودع X-OmniClaw من OPPO Mente Lab إشارات تصميمية مثل التوازي متعدد الجلسات، العزل، وسلاسل الإيقاف الدقيقة داخل بيئة بحثية. هذه أمثلة مفيدة لفهم الصناعة، لكنها لا تعني أن هاتف المستخدم يجب أن ينفذ كل إجراء بالتوازي.

تعرض Microsoft أيضًا في أنماط الوكلاء متعددة المراحل الموجهة بسير العمل فصلًا بين التنسيق، الوكلاء، الحالة، والتحكم في العملية. هذه اللغة قريبة من عالم المؤسسات وسير العمل، وتساعدنا على صياغة سؤال الهاتف: ما الذي يمكن أن يتوازي، وما الذي يحتاج ترتيبًا؟

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

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

الإيقاف والاستئناف واسترداد الإذن وفحص الحالة القديمة

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

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

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

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

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

كيف يحمل FoneClaw حاليًا مهام المحادثات المتعددة؟

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

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

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

يدعم هذا المسار نموذج مكوّن يفهم ويخطط، بينما تنفذ FoneClaw إجراءات Android المدعومة عبر أدوات محكومة. عند الحاجة، تعرض صفحة ميزات FoneClaw قدرات المنتج بلغة مستقرة، بما في ذلك 100+ built-in tools، لكن قيمة قائمة المهام لا تأتي من العدد؛ تأتي من أن كل أداة تعمل داخل هوية مهمة وموافقة وحالة واضحة.

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

قائمة فحص لتقييم قائمة مهام وكيل Android

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

1. تحقق أن كل مهمة تعرض هويتها ومحادثتها الأصلية.
2. راقب هل تختلف حالات التشغيل والانتظار والموافقة بوضوح.
3. بدّل المحادثة وتأكد أن الموافقة لا تنتقل إلى مهمة أخرى.
4. أوقف مهمة ثم راقب أن الخطوات اللاحقة لا تستمر بصمت.
5. استرد إذنًا أو غيّر الشاشة وتحقق من فحص الحالة قبل الاستئناف.
6. راجع النتيجة: هل فهمت ما حدث وما بقي منتظرًا؟

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