تحفيز OpenClaw عبر Gmail

تريد أن يتفاعل المساعد عندما يصل بريد: فاتورة جديدة، أو طلب دعم، أو إشعار بفشل نشر. والتوصيل البديهي، أي توجيه Gmail إلى الوكيل الذي تدردش معه أصلًا، يمنح أي غريب يعرف عنوانك دورة على وكيل يملك shell الخاص بك وملفاتك ومتصفحك. مسار Gmail في OpenClaw موجود لتفادي ذلك، وهو سلسلة من الأجزاء لا مفتاح تشغيل واحد.

كيف تصل رسالة Gmail إلى وكيل

• وسيلة النقل هي Google Pub/Sub. تنشر مراقبة Gmail المضبوطة على تصنيف معيّن أحداث صندوق الوارد إلى موضوع، ويدفعها Pub/Sub إلى العملية gog gmail watch serve، ويمرر هذا المراقب بيانات البريد إلى خطاف HTTP في Gateway. وهو لا يحمّل أبدًا معالجًا داخليًا من نوع HOOK.md: فهذا هو الخطاف الخارجي الوارد، لا نظام الأحداث داخل العملية.
• المتطلبات المسبقة محددة: أداة gcloud CLI، وgog مفوّض لحساب Gmail الخاضع للمراقبة، والخطافات (hooks) مفعّلة في OpenClaw، ونقطة نهاية دفع عبر HTTPS يستطيع Pub/Sub الوصول إليها فعلًا (Tailscale Funnel في الإعداد الموصى به)، وواجهة خلفية عاملة للبيئة المعزولة، تبني صورتها قبل التشغيل الأول إذا بقيت على الواجهة الخلفية الافتراضية Docker.
• يبدأ Gateway المراقب ويجدّده بنفسه بمجرد تفعيل الخطافات وضبط حساب Gmail، مع متغير بيئة لإلغاء ذلك. شغّل نسخة واحدة بالضبط: فعملية serve ثانية أو أمر run يدوي على المستمع نفسه يسبب تعارضًا في ربط المنفذ، والمستمع الذي بدأ العمل ليس دليلًا على أنه قد تم تسجيل المراقبة.
• تتحول كل دفعة تصل عبر push إلى تشغيل واحد للوكيل لكل رسالة بريد، لأن التعيين (mapping) يتفرع على مصفوفة messages، بحد أقصى 200 عنصر. وتحصل مسارات Gmail على سماحية أكبر لحجم جسم الطلب مشتقة من حد البايتات لكل رسالة وبسقف 32 MiB، وصفحة history الواردة من المصدر تحسب سجلات history لا رسائل البريد، لذا قد يظل تراكم الرسائل يصطدم بالحدود.

الجلسة لكل رسالة في إعداد Gmail المسبق المدمج تفصل سياق المحادثة؛ لكنها لا تقيّد أدوات الوكيل المستهدف ولا مساحة عمله.

الجلسات لكل رسالة ليست حدًا للأذونات

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

الوكيل mail_reader

• القارئ إدخال ثانٍ في قائمة الوكلاء بمساحة عمل ونموذج خاصين به، وببيئة معزولة مضبوطة على الوضع all والنطاق session ودون وصول إلى مساحة العمل. لذا تحصل كل رسالة بريد على بيئة معزولة جديدة لا تستطيع الوصول إلى مساحة عمل الوكيل المضيف، ويكون التشغيل قابلًا للتخلص منه بحكم بنيته.
• سياسة أدواته هي ملف التعريف minimal مع أداة واحدة مسموح بها، session_status، إضافة إلى قائمة منع صريحة تغطي مجموعات نظام الملفات وruntime وweb، والأدوات browser وcron وgateway وnodes. وقائمة السماح الخاصة بالوكيل هذه قيد مطلق، فلا يمكن لإضافة also-allow عامة أن تتسرب إلى القارئ، وحالات المنع الصريحة تبقي الحدود المقصودة قابلة للتدقيق.
• إضافة القارئ تحوّل قائمة الوكلاء إلى أسطول صريح، لذا تحتاج كل قناة لا يزال يملكها وكيلك الرئيسي إلى ارتباط (binding) خاص بها، واحد لكل قناة، لأنه لا يوجد حرف بدل يشمل القنوات كلها. وعرض الوكلاء مع ارتباطاتهم قبل إعادة التشغيل هو الفحص الذي يكشف قناة بلا مالك، والتسليم معطّل، لذا تُسجّل حالات الاكتمال في السجلات بدلًا من الإعلان عنها.

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

رمزان، وإعداد gcloud، واختبار الحدود

يكتب أمر إعداد Gmail كتلة النقل، ويفعّل الإعداد المسبق، ويحافظ على التعيين المقيّد الذي طبقته أولًا، ويعتمد Tailscale Funnel افتراضيًا لنقطة نهاية الدفع؛ أما الوضع serve فهو مقصور على tailnet وليس هدفًا لـ Pub/Sub يمكن الوصول إليه علنًا، لذا يُدخل الرابط المدار خارجيًا مع إيقاف النفق وتمرير نقطة النهاية صراحةً. يحرس رمزان قفزتين: رمز الدفع يصادق Pub/Sub لدى المراقب، ورمز الخطاف يصادق المراقب لدى OpenClaw عبر ترويسة، والرموز الممررة في سلسلة الاستعلام مرفوضة، لذا فإن رابط الدفع الحامل للرمز ذاك ليس قالبًا لاستدعاء مسار الخطاف بنفسك. وقد تطبع مخرجات الإعداد الرمزين كليهما، لذا نقّحها قبل مشاركتها. أما المسار اليدوي فقصير: اختر المشروع الذي يملك عميل OAuth الخاص بـ gog، وفعّل واجهتي API لـ Gmail وPub/Sub، وأنشئ الموضوع، وامنح حساب الخدمة الخاص بدفع Gmail دور الناشر، ثم ابدأ المراقبة على ذلك الموضوع، وهذا لا يسجّل أي اشتراك دفع ولا يشغّل أي مستمع. ثم اختبر. أرسل إلى نفسك من حساب آخر تعليمات خاملة، إذ تقترح الوثائق أن تطلب من الوكيل اتباع رابط وتشغيل أمر، ثم اقرأ سجل التشغيل. نجاح المراقب يؤكد النقل، واستجابة 200 من الخطاف مع معرّف تشغيل تسجّل القبول، وأي محاولة للانتقال إلى رابط أو كتابة ملف أو تنفيذ أمر shell أو إجراء في المتصفح أو تسجيل MCP تعني فشل اختبار الحدود. تشرح صفحة حقن الأوامر في OpenClaw نموذج التهديد الكامن وراء كل هذا، ويطبّق محفّز البريد عبر IMAP نمط القارئ نفسه خارج Google.

على Diali

يتولى Diali استضافة OpenClaw كخدمة مدارة، ويشغّل كل عميل مساعده الخاص بدلًا من مقعد في مساعد مشترك. تُولّد إعدادات المحرك من إعدادات لوحة التحكم لديك وتُكتب من جديد مع كل إصدار، بينما تُحفظ الجلسات والذاكرة وملفات مساحة العمل على وحدة تخزين دائمة، مع لقطات يومية واستعادة بنقرة واحدة متاحة عبر إضافة «النسخ الاحتياطية» (مضمّنة في Max). ونقطة نهاية الدفع التي يمكن الوصول إليها علنًا هي الجزء الذي يجب ترتيبه معنا، لأن نقطة الدخول (ingress) أمام مساعدك تابعة لنا. تصف صفحة OpenClaw المستضاف على Diali المساعد المستضاف، وتعرض صفحة أسعار Diali ما تتضمنه كل خطة.

• الإعداد المسبق يفصل السياق، لا الأذونات أبدًا.
• رمزان، وقفزتان، ولا بدائل.
• استجابة 200 من الخطاف تعني القبول، لا التلخيص.