---
read_when:
    - توضیح اینکه چگونه پیام‌های ورودی به پاسخ تبدیل می‌شوند
    - شفاف‌سازی نشست‌ها، حالت‌های صف‌بندی یا رفتار پخش جریانی
    - مستندسازی قابلیت مشاهدهٔ استدلال و پیامدهای استفاده
summary: جریان پیام، نشست‌ها، صف‌بندی و مشاهده‌پذیری استدلال
title: پیام‌ها
x-i18n:
    generated_at: "2026-04-30T16:27:51Z"
    model: gpt-5.5
    provider: openai
    source_hash: fdeee014d92767a725501691fbe0c4ee6b631acc9a2ab5cbbcf321bfee9679b9
    source_path: concepts/messages.md
    workflow: 16
---

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.*` و غیره) برای سقف‌ها و کلیدهای جریان‌سازی.

برای طرح‌واره کامل، [پیکربندی](/fa/gateway/configuration) را ببینید.

## حذف تکرار ورودی

کانال‌ها می‌توانند پس از اتصال دوباره همان پیام را دوباره تحویل دهند. OpenClaw یک کش کوتاه‌عمر نگه می‌دارد که با شناسه کانال/حساب/همتا/نشست/پیام کلیدگذاری شده است تا تحویل‌های تکراری باعث اجرای دوباره عامل نشوند.

## ضدپرش ورودی

پیام‌های پشت‌سرهم سریع از **همان فرستنده** می‌توانند از طریق `messages.inbound` در یک نوبت واحد عامل دسته‌بندی شوند. ضدپرش برای هر کانال + گفتگو محدوده‌بندی می‌شود و از تازه‌ترین پیام برای رشته‌بندی/شناسه‌های پاسخ استفاده می‌کند.

پیکربندی (پیش‌فرض سراسری + بازنویسی‌های هر کانال):

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

نکته‌ها:

- ضدپرش فقط روی پیام‌های **فقط متنی** اعمال می‌شود؛ رسانه/پیوست‌ها بلافاصله تخلیه می‌شوند.
- فرمان‌های کنترلی ضدپرش را دور می‌زنند تا مستقل بمانند — **مگر** وقتی کانالی صراحتا در ادغام DM از همان فرستنده شرکت کند (برای نمونه [BlueBubbles `coalesceSameSenderDms`](/fa/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition))، که در آن فرمان‌های DM داخل پنجره ضدپرش منتظر می‌مانند تا محتوای ارسالِ تقسیم‌شده بتواند به همان نوبت عامل بپیوندد.

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

نشست‌ها متعلق به Gateway هستند، نه کلاینت‌ها.

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

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

جزئیات: [مدیریت نشست](/fa/concepts/session).

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

`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.byChannel`) پیکربندی کنید.
- حالت پیش‌فرض `steer` است، با ضدپرش پیگیری ۵۰۰ میلی‌ثانیه‌ای وقتی هدایت به تحویل پیگیری صف‌شده برمی‌گردد.
- حالت‌ها: `steer`، `followup`، `collect`، `steer-backlog`، `interrupt`، و حالت قدیمی یکی‌درهرزمان `queue`.

جزئیات: [صف فرمان](/fa/concepts/queue) و [صف هدایت](/fa/concepts/queue-steering).

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

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

## جریان‌سازی، تکه‌تکه‌سازی و دسته‌بندی

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

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

- `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` صریح نیاز دارند)

جزئیات: [جریان‌سازی + تکه‌تکه‌سازی](/fa/concepts/streaming).

## نمایش‌پذیری استدلال و توکن‌ها

OpenClaw می‌تواند استدلال مدل را آشکار یا پنهان کند:

- `/reasoning on|off|stream` نمایش‌پذیری را کنترل می‌کند.
- محتوای استدلال، وقتی توسط مدل تولید شود، همچنان در مصرف توکن حساب می‌شود.
- Telegram از جریان استدلال به داخل حباب پیش‌نویس پشتیبانی می‌کند.

جزئیات: [دستورالعمل‌های فکر کردن + استدلال](/fa/tools/thinking) و [مصرف توکن](/fa/reference/token-use).

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

قالب‌بندی پیام خروجی در `messages` متمرکز شده است:

- `messages.responsePrefix`، `channels.<channel>.responsePrefix` و `channels.<channel>.accounts.<id>.responsePrefix` (آبشار پیشوند خروجی)، به‌علاوه `channels.whatsapp.messagePrefix` (پیشوند ورودی WhatsApp)
- رشته‌بندی پاسخ از طریق `replyToMode` و پیش‌فرض‌های هر کانال

جزئیات: [پیکربندی](/fa/gateway/config-agents#messages) و مستندات کانال.

## پاسخ‌های خاموش

توکن خاموش دقیق `NO_REPLY` / `no_reply` یعنی «پاسخ قابل مشاهده برای کاربر تحویل نده».
وقتی یک نوبت همچنین رسانه ابزار معلق دارد، مانند صوت TTS تولیدشده، OpenClaw متن خاموش را حذف می‌کند اما همچنان پیوست رسانه را تحویل می‌دهد.
OpenClaw این رفتار را بر اساس نوع گفتگو حل می‌کند:

- گفتگوهای مستقیم به‌طور پیش‌فرض سکوت را مجاز نمی‌دانند و یک پاسخ خاموش تنها را به جایگزین کوتاه قابل مشاهده بازنویسی می‌کنند.
- گروه‌ها/کانال‌ها به‌طور پیش‌فرض سکوت را مجاز می‌دانند.
- ارکستراسیون داخلی به‌طور پیش‌فرض سکوت را مجاز می‌داند.

OpenClaw همچنین برای خرابی‌های داخلی اجراکننده که پیش از هر پاسخ دستیار در گفتگوهای غیرمستقیم رخ می‌دهند از پاسخ‌های خاموش استفاده می‌کند، تا گروه‌ها/کانال‌ها متن کلیشه‌ای خطای Gateway را نبینند. گفتگوهای مستقیم به‌طور پیش‌فرض متن کوتاه خرابی را نشان می‌دهند؛ جزئیات خام اجراکننده فقط وقتی `/verbose` روی `on` یا `full` باشد نشان داده می‌شود.

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

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

## مرتبط

- [جریان‌سازی](/fa/concepts/streaming) — تحویل بی‌درنگ پیام
- [تلاش دوباره](/fa/concepts/retry) — رفتار تلاش دوباره برای تحویل پیام
- [صف](/fa/concepts/queue) — صف پردازش پیام
- [کانال‌ها](/fa/channels) — یکپارچه‌سازی‌های پلتفرم پیام‌رسانی
