پیام‌ها

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,      },    },  },}

نکته‌ها:

• تأخیر تجمیعی فقط برای پیام‌های صرفاً متنی اعمال می‌شود؛ رسانه/پیوست‌ها بلافاصله تخلیه می‌شوند.
• فرمان‌های کنترلی تأخیر تجمیعی را دور می‌زنند تا مستقل باقی بمانند. کانال‌هایی که صراحتاً در تجمیع پیام مستقیم از همان فرستنده شرکت می‌کنند، می‌توانند فرمان‌های پیام مستقیم را داخل پنجره تأخیر تجمیعی نگه دارند تا payload ارسال‌شده به‌صورت چندبخشی بتواند به همان نوبت عامل بپیوندد.

نشست‌ها و دستگاه‌ها

نشست‌ها در مالکیت Gateway هستند، نه کلاینت‌ها.

• گفت‌وگوهای مستقیم در کلید نشست اصلی عامل ادغام می‌شوند.
• گروه‌ها/کانال‌ها کلیدهای نشست خودشان را می‌گیرند.
• ذخیره‌گاه نشست و رونوشت‌ها روی میزبان Gateway قرار دارند.

چند دستگاه/کانال می‌توانند به یک نشست یکسان نگاشت شوند، اما تاریخچه به‌طور کامل به همه کلاینت‌ها همگام‌سازی نمی‌شود. توصیه: برای مکالمه‌های طولانی از یک دستگاه اصلی استفاده کنید تا از واگرایی زمینه جلوگیری شود. Control UI و TUI همیشه رونوشت نشست پشتیبانی‌شده توسط Gateway را نشان می‌دهند، بنابراین منبع حقیقت هستند.

جزئیات: مدیریت نشست.

فراداده نتیجه ابزار

content نتیجه ابزار، نتیجه قابل مشاهده برای مدل است. details نتیجه ابزار، فراداده زمان اجرا برای رندر UI، تشخیص، تحویل رسانه، و Pluginها است.

OpenClaw این مرز را صریح نگه می‌دارد:

• toolResult.details پیش از بازپخش ارائه‌دهنده و ورودی Compaction حذف می‌شود.
• رونوشت‌های نشست پایدارشده فقط details محدودشده را نگه می‌دارند؛ فراداده بیش‌ازحد بزرگ با خلاصه‌ای فشرده که با persistedDetailsTruncated: true علامت‌گذاری شده جایگزین می‌شود.
• Pluginها و ابزارها باید متنی را که مدل باید بخواند در content بگذارند، نه فقط در details.

بدنه‌های ورودی و زمینه تاریخچه

OpenClaw بدنه اعلان را از بدنه فرمان جدا می‌کند:

• BodyForAgent: متن اصلی رو به مدل برای پیام فعلی. Pluginهای کانال باید آن را بر متن فعلیِ حامل اعلانِ فرستنده متمرکز نگه دارند.
• 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 است، با تأخیر تجمیعی ۵۰۰ میلی‌ثانیه برای دسته‌های هدایت Codex و صف‌های پیگیری/جمع‌آوری.
• حالت‌ها: steer، followup، collect، و interrupt.

جزئیات: صف فرمان و صف هدایت.

مالکیت اجرای کانال

Pluginهای کانال می‌توانند ترتیب را حفظ کنند، ورودی را با تأخیر تجمیعی پردازش کنند، و پیش از ورود پیام به صف نشست، فشار برگشتی انتقال را اعمال کنند. آن‌ها نباید برای خود نوبت عامل یک timeout جداگانه اعمال کنند. پس از اینکه پیام به یک نشست مسیریابی شد، کار طولانی‌مدت توسط چرخه عمر نشست، ابزار، و زمان اجرا اداره می‌شود تا همه کانال‌ها نوبت‌های کند را به‌طور سازگار گزارش کنند و از آن‌ها بازیابی شوند.

جریان‌دهی، بخش‌بندی، و دسته‌بندی

جریان‌دهی بلوکی پاسخ‌های جزئی را همان‌طور که مدل بلوک‌های متن را تولید می‌کند ارسال می‌کند. بخش‌بندی به محدودیت‌های متن کانال احترام می‌گذارد و از شکستن کدهای حصارشده جلوگیری می‌کند.

تنظیمات کلیدی:

• 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 همچنین از پاسخ‌های بی‌صدا برای شکست‌های عمومی runner داخلی در گفت‌وگوهای غیرمستقیم استفاده می‌کند، تا گروه‌ها/کانال‌ها متن تکراری خطای Gateway را نبینند. شکست‌های طبقه‌بندی‌شده با متن بازیابی رو به کاربر، مانند نبود احراز هویت، محدودیت نرخ، یا اعلان‌های اضافه‌بار، همچنان می‌توانند تحویل داده شوند. گفت‌وگوهای مستقیم به‌طور پیش‌فرض متن فشرده شکست را نشان می‌دهند؛ جزئیات خام runner فقط وقتی /verbose full فعال است نشان داده می‌شوند.

پیش‌فرض‌ها زیر agents.defaults.silentReply قرار دارند؛ surfaces.<id>.silentReply می‌تواند سیاست گروه/داخلی را برای هر سطح بازنویسی کند.

پاسخ‌های بی‌صدای تنها روی همه سطح‌ها دور انداخته می‌شوند، بنابراین نشست‌های والد به‌جای بازنویسی متن sentinel به گفت‌وگوی جایگزین، ساکت می‌مانند.

مرتبط

• بازآرایی چرخه عمر پیام - هدف طراحی پایدار ارسال و دریافت
• جریان‌دهی — تحویل پیام بی‌درنگ
• تلاش دوباره — رفتار تلاش دوباره برای تحویل پیام
• صف — صف پردازش پیام
• کانال‌ها — یکپارچه‌سازی‌های پلتفرم پیام‌رسانی