الرسائل

يعالج OpenClaw الرسائل الواردة عبر مسار يتضمن حلّ الجلسات، ووضعها في الصف، والبث، وتنفيذ الأدوات، وإظهار الاستدلال. ترسم هذه الصفحة المسار من الرسالة الواردة إلى الرد.

# تدفق الرسائل (على مستوى عالٍ)

Inbound message
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)

توجد عناصر الضبط الأساسية في التكوين:

• messages.* للبادئات، ووضع الرسائل في الصف، وسلوك المجموعات.
• agents.defaults.* لإعدادات بث الكتل والتجزئة الافتراضية.
• تجاوزات القنوات (channels.whatsapp.*، وchannels.telegram.*، وما إلى ذلك) للحدود ومفاتيح تبديل البث.

راجع التكوين للاطلاع على المخطط الكامل.

# إزالة تكرار الرسائل الواردة

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

# تهدئة الرسائل الواردة

يمكن تجميع الرسائل المتتالية السريعة من المرسل نفسه في دورة وكيل واحدة عبر messages.inbound. تُطبَّق التهدئة ضمن نطاق كل قناة + محادثة، وتستخدم أحدث رسالة لتسلسل الردود/المعرّفات.

التكوين (افتراضي عام + تجاوزات لكل قناة):

{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}

ملاحظات:

• تنطبق التهدئة على الرسائل النصية فقط؛ أما الوسائط/المرفقات فتُفرَّغ فورًا.
• تتجاوز أوامر التحكم التهدئة كي تبقى مستقلة — إلا عندما تختار قناة صراحةً دمج رسائل DM من المرسل نفسه (مثل BlueBubbles coalesceSameSenderDms)، حيث تنتظر أوامر DM داخل نافذة التهدئة حتى تتمكن حمولة الإرسال المقسّم من الانضمام إلى دورة الوكيل نفسها.

# الجلسات والأجهزة

تعود ملكية الجلسات إلى Gateway، وليس إلى العملاء.

• تُدمَج الدردشات المباشرة في مفتاح الجلسة الرئيسي للوكيل.
• تحصل المجموعات/القنوات على مفاتيح جلسات خاصة بها.
• يعيش مخزن الجلسات والنصوص على مضيف Gateway.

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

التفاصيل: إدارة الجلسات.

# بيانات تعريف نتائج الأدوات

يمثل content في نتيجة الأداة النتيجة المرئية للنموذج. وتمثل details في نتيجة الأداة بيانات تعريف وقت التشغيل لعرض واجهة المستخدم، والتشخيصات، وتسليم الوسائط، وPlugins.

يحافظ OpenClaw على وضوح هذا الحد:

• تُزال toolResult.details قبل إعادة تشغيل المزوّد وإدخال Compaction.
• تحتفظ نصوص الجلسات المستمرة فقط بـ details محدودة؛ وتُستبدل بيانات التعريف كبيرة الحجم بملخص موجز معلَّم بـ persistedDetailsTruncated: true.
• يجب أن تضع Plugins والأدوات النص الذي يجب على النموذج قراءته في content، وليس فقط في details.

# أجسام الرسائل الواردة وسياق السجل

يفصل OpenClaw بين جسم الموجّه وجسم الأمر:

• BodyForAgent: النص الأساسي المواجه للنموذج للرسالة الحالية. يجب على Plugins القنوات إبقاء هذا مركّزًا على النص الحالي من المرسل الذي يحمل الموجّه.
• Body: بديل قديم للموجّه. قد يتضمن هذا أغلفة القنوات ومغلّفات سجل اختيارية، لكن لا ينبغي للقنوات الحالية الاعتماد عليه كإدخال أساسي للنموذج عندما يكون BodyForAgent متاحًا.
• CommandBody: نص المستخدم الخام لتحليل التوجيهات/الأوامر.
• RawBody: اسم مستعار قديم لـ CommandBody (محفوظ للتوافق).

عندما توفّر قناة سجلًا، تستخدم مغلّفًا مشتركًا:

• [Chat messages since your last reply - for context]
• [Current message - respond to this]

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

مخازن السجل للمعلّق فقط: فهي تتضمن رسائل المجموعة التي لم تؤدِّ إلى تشغيل (مثل الرسائل المحجوبة ببوابة الإشارة)، وتستثني الرسائل الموجودة بالفعل في نص الجلسة.

ينطبق تجريد التوجيهات فقط على قسم الرسالة الحالية حتى يبقى السجل سليمًا. يجب على القنوات التي تغلّف السجل ضبط CommandBody (أو RawBody) على نص الرسالة الأصلي، وإبقاء Body كالموجّه المدمج. تُعرَض بيانات تعريف السجل المنظم، والرد، والرسائل المُعاد توجيهها، والقناة ككتل سياق غير موثوقة بدور المستخدم أثناء تجميع الموجّه. يمكن تكوين مخازن السجل عبر messages.groupChat.historyLimit (الافتراضي العام) وتجاوزات لكل قناة مثل channels.slack.historyLimit أو channels.telegram.accounts.<id>.historyLimit (اضبط 0 للتعطيل).

# وضع الرسائل في الصف والمتابعات

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

• كوّن ذلك عبر messages.queue (وmessages.queue.byChannel).
• الوضع الافتراضي هو steer، مع تهدئة متابعة قدرها 500ms عندما يعود التوجيه إلى تسليم متابعة في الصف.
• الأوضاع: steer، وfollowup، وcollect، وsteer-backlog، وinterrupt، ووضع queue القديم الذي يعالج عنصرًا واحدًا في كل مرة.

التفاصيل: صف الأوامر وصف التوجيه.

# ملكية تشغيل القناة

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

# البث، والتجزئة، والتجميع

يرسل بث الكتل ردودًا جزئية بينما ينتج النموذج كتلًا نصية. تراعي التجزئة حدود نص القناة وتتجنب تقسيم كتل التعليمات البرمجية المسيّجة.

الإعدادات الرئيسية:

• agents.defaults.blockStreamingDefault (on|off، الافتراضي إيقاف)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (تجميع قائم على الخمول)
• agents.defaults.humanDelay (توقف شبيه بالبشر بين ردود الكتل)
• تجاوزات القنوات: *.blockStreaming و*.blockStreamingCoalesce (تتطلب القنوات غير Telegram ضبطًا صريحًا لـ *.blockStreaming: true)

التفاصيل: البث + التجزئة.

# إظهار الاستدلال والرموز

يمكن لـ OpenClaw إظهار استدلال النموذج أو إخفاؤه:

• يتحكم /reasoning on|off|stream في الإظهار.
• ما يزال محتوى الاستدلال يُحتسب ضمن استخدام الرموز عندما ينتجه النموذج.
• يدعم Telegram بث الاستدلال إلى فقاعة مسودة مؤقتة تُحذف بعد التسليم النهائي؛ استخدم /reasoning on لإخراج استدلال مستمر.

التفاصيل: توجيهات التفكير + الاستدلال واستخدام الرموز.

# البادئات، وتسلسل المحادثات، والردود

تتم مركزية تنسيق الرسائل الصادرة في messages:

• messages.responsePrefix، وchannels.<channel>.responsePrefix، وchannels.<channel>.accounts.<id>.responsePrefix (تسلسل بادئات الرسائل الصادرة)، إضافةً إلى channels.whatsapp.messagePrefix (بادئة الرسائل الواردة في WhatsApp)
• تسلسل الردود عبر replyToMode والافتراضيات لكل قناة

التفاصيل: التكوين ووثائق القنوات.

# الردود الصامتة

يعني رمز الصمت الدقيق NO_REPLY / no_reply "عدم تسليم رد مرئي للمستخدم". عندما تحتوي دورة أيضًا على وسائط أدوات معلّقة، مثل صوت TTS مُنشأ، يزيل OpenClaw النص الصامت لكنه يظل يسلّم مرفق الوسائط. يحسم OpenClaw هذا السلوك حسب نوع المحادثة:

• تمنع المحادثات المباشرة الصمت افتراضيًا وتعيد كتابة الرد الصامت المجرد إلى بديل قصير مرئي.
• تسمح المجموعات/القنوات بالصمت افتراضيًا.
• يسمح التنسيق الداخلي بالصمت افتراضيًا.

يستخدم OpenClaw أيضًا الردود الصامتة لإخفاقات المشغّل الداخلية التي تحدث قبل أي رد من المساعد في الدردشات غير المباشرة، بحيث لا ترى المجموعات/القنوات نصوص أخطاء Gateway النمطية. تعرض الدردشات المباشرة نص إخفاق موجزًا افتراضيًا؛ ولا تُعرض تفاصيل المشغّل الخام إلا عندما يكون /verbose في وضع on أو full.

توجد الافتراضيات تحت agents.defaults.silentReply وagents.defaults.silentReplyRewrite؛ ويمكن لـ surfaces.<id>.silentReply وsurfaces.<id>.silentReplyRewrite تجاوزها لكل سطح.

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

# ذات صلة

• إعادة هيكلة دورة حياة الرسائل - تصميم مستهدف للإرسال والاستقبال المتينين
• البث — تسليم الرسائل في الوقت الحقيقي
• إعادة المحاولة — سلوك إعادة محاولة تسليم الرسائل
• الصف — صف معالجة الرسائل
• القنوات — تكاملات منصات المراسلة