الانتقال إلى المحتوى الرئيسي
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,
      },
    },
  },
}
ملاحظات:
  • تنطبق التهدئة على الرسائل النصية فقط؛ أما الوسائط/المرفقات فتُرسل فورًا.
  • تتجاوز أوامر التحكم التهدئة حتى تبقى مستقلة. يمكن للقنوات التي تختار صراحةً تجميع الرسائل الخاصة من المرسل نفسه أن تُبقي أوامر الرسائل الخاصة داخل نافذة التهدئة، بحيث يمكن لحمولة مرسلة على أجزاء أن تنضم إلى دور الوكيل نفسه.

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

يمتلك Gateway الجلسات، وليس العملاء.
  • تُطوى المحادثات المباشرة في مفتاح الجلسة الرئيسي للوكيل.
  • تحصل المجموعات/القنوات على مفاتيح جلسة خاصة بها.
  • يوجد مخزن الجلسات والنصوص على مضيف Gateway.
يمكن لأجهزة/قنوات متعددة أن ترتبط بالجلسة نفسها، لكن السجل لا يُزامن بالكامل مرة أخرى إلى كل عميل. التوصية: استخدم جهازًا أساسيًا واحدًا للمحادثات الطويلة لتجنب تباعد السياق. تعرض واجهة Control UI و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 (وmessages.queue.byChannel).
  • الوضع الافتراضي هو steer، مع تهدئة قدرها 500ms لدُفعات توجيه Codex وطوابير المتابعة/الجمع.
  • الأوضاع: steer، وfollowup، وcollect، وinterrupt.
التفاصيل: طابور الأوامر وطابور التوجيه.

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

قد تحافظ 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 هذا السلوك حسب نوع المحادثة:
  • لا تتلقى المحادثات المباشرة أبدًا إرشاد مطالبة NO_REPLY. إذا أعاد تشغيل مباشر عن طريق الخطأ رمزًا صامتًا مجردًا، فإن OpenClaw يكبته بدلًا من إعادة كتابته أو تسليمه.
  • تسمح المجموعات/القنوات بالصمت افتراضيًا فقط للردود التلقائية في المجموعات. في وضع الرد المرئي message_tool، يعني الصمت أن النموذج لا يستدعي message(action=send).
  • يسمح التنسيق الداخلي بالصمت افتراضيًا.
يستخدم OpenClaw أيضًا الردود الصامتة لإخفاقات مشغل داخلية عامة في المحادثات غير المباشرة، بحيث لا ترى المجموعات/القنوات نصوص أخطاء Gateway الجاهزة. لا يزال من الممكن تسليم الإخفاقات المصنفة التي تحتوي على نص استرداد موجه للمستخدم، مثل إشعارات نقص المصادقة، أو حد المعدل، أو الحمل الزائد. تعرض المحادثات المباشرة نسخة فشل مضغوطة افتراضيًا؛ وتُعرض تفاصيل المشغل الخام فقط عند تمكين /verbose full. توجد الإعدادات الافتراضية تحت agents.defaults.silentReply؛ ويمكن لـ surfaces.<id>.silentReply تجاوز سياسة المجموعة/الداخلية لكل سطح. تُسقط الردود الصامتة المجردة على كل الأسطح، لذلك تبقى الجلسات الأصلية هادئة بدلًا من إعادة كتابة نص الحارس إلى ثرثرة احتياطية.

​
ذات صلة