MCP عديم الحالة وتدفقات وكيل الهاتف ذات الحالة: دليل معماري لـ Android

ما الذي غيره MCP 2026-07-28؟

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

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

الجزء الذي يهم وكيل الهاتف هو الفصل بين حالتين: حالة النقل وحالة التطبيق. MCP عديم الحالة على مستوى النقل، بينما تطبيق الهاتف يحتاج حالة مهمة متماسكة. إذا بدأ المستخدم رسالة، رفض إذنا، عاد من إعدادات Android، ثم وافق على الإرسال، فهذه ليست مجرد طلبات متفرقة. إنها مهمة واحدة لها هوية وسياق وموافقات ونتيجة. لذلك نضع حالة المهمة في مضيف الوكيل أو مخزن تطبيقي صريح، ونستخدم MCP كقناة أدوات قابلة للتوسع. ولموضوع اكتشاف الموارد والثقة قبل التفويض، يقدم مقال Agentic Resource Discovery: اكتشاف موارد الوكلاء من ai-catalog.json إلى تفويض الهاتف خلفية مكملة.

كيف تعمل دورة طلب MCP عديم الحالة؟

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

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

تشرح وثيقة SEP-2567 حول مقابض الحالة الصريحة كيف يمكن استبدال حالة الجلسة الضمنية بمراجع صريحة يصدرها الخادم وتُمرر في طلبات لاحقة. هذه المقابض مفيدة للعمليات الطويلة أو الموارد التي تحتاج متابعة، لكنها ليست بديلا عن موافقة المستخدم أو سجل التدقيق أو قراءة حالة الجهاز في اللحظة المناسبة.

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

ست حالات يجب أن يملكها وكيل الهاتف

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

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

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

MCP Tasks وMRTR والاستيضاح والموافقات

إصدار MCP 2026-07-28 يقدم Tasks كامتداد رسمي، ويقوي أنماطا مثل MRTR حيث يطلب النموذج أداة ثم تعود النتيجة إلى مسار التفكير. هذا مناسب للعمليات التي تمتد بعد طلب واحد: مهمة تبدأ، تحصل على مقبض، ثم تُفحص أو تُلغى أو تُستكمل لاحقا. المهم في تصميم الهاتف أن هذا المقبض يمثل مرجعا للعمل، لا موافقة كاملة على كل أثر محتمل.

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

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

تدفق Android ذو حالة فوق MCP عديم الحالة

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

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

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

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

توسيع خوادم MCP مع الحفاظ على موثوقية مهام الهاتف

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

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

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

حدود الأمان وقائمة انتقال عملية

الأمان في MCP 2026-07-28 يتقدم عبر تفويض أوضح، بيانات طلب صريحة، وإطار امتدادات. في وكيل الهاتف نضيف قاعدة عملية: المصادقة، التفويض، الموافقة، وحالة الجهاز حالات مختلفة. رمز الوصول يفتح قناة إلى أداة، والموافقة تفتح فعلا محددا، وحالة الجهاز تحدد هل يمكن تنفيذ الفعل الآن. هذا الفصل يجعل التدفق قابلا للتفسير والاسترداد.

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

• حدّد مالك كل حالة: المحادثة، المهمة، الجهاز، الموافقة، التفويض، التدقيق.
• اجعل طلبات MCP قابلة للتوجيه دون جلسة مخفية.
• مرر مقابض صريحة عند الحاجة، مع صلاحية وانتهاء واضحين.
• استخدم idempotency لكل فعل خارجي مؤثر.
• تحقق من النتيجة على الهاتف قبل إعلان النجاح.
• صمم استرداد الإذن وتغير الشاشة كجزء من المهمة.

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