---
read_when:
    - توضیح چگونگی تبدیل پیام‌های ورودی به پاسخ‌ها
    - شفاف‌سازی نشست‌ها، حالت‌های صف‌بندی یا رفتار پخش جریانی
    - مستندسازی نمایش استدلال و پیامدهای استفاده
summary: جریان پیام، نشست‌ها، صف‌بندی و نمایش استدلال
title: پیام‌ها
x-i18n:
    generated_at: "2026-07-16T16:03:02Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: e2982ebb1b82b90368263826ef8f42babab9c8a559cc1409a381893a011a0ad7
    source_path: concepts/messages.md
    workflow: 16
---

پیام‌های ورودی از مسیریابی، حذف موارد تکراری/درنگ، اجرای عامل و تحویل خروجی عبور می‌کنند:

```text
پیام ورودی
  -> مسیریابی/اتصال‌ها -> کلید نشست
  -> حذف موارد تکراری + درنگ
  -> صف (اگر اجرایی از قبل فعال باشد)
  -> اجرای عامل (جریان‌سازی + ابزارها)
  -> پاسخ‌های خروجی (محدودیت‌های کانال + قطعه‌بندی)
```

سطوح پیکربندی کلیدی:

- `messages.*` برای پیشوندها، صف‌بندی، درنگ ورودی و رفتار گروه.
- `agents.defaults.*` برای جریان‌سازی بلوکی، قطعه‌بندی و پیش‌فرض‌های پاسخ بی‌صدا.
- بازنویسی‌های کانال (`channels.telegram.*`، `channels.whatsapp.*` و غیره) برای سقف‌های هر کانال و کلیدهای تغییر وضعیت جریان‌سازی.

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

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

کانال‌ها ممکن است پس از اتصال مجدد همان پیام را دوباره تحویل دهند. OpenClaw یک حافظه نهان درون‌حافظه‌ای نگه می‌دارد که کلید آن از دامنه عامل، مسیر کانال (کانال + همتا + حساب + رشته) و شناسه پیام تشکیل شده است؛ بنابراین پیام دوباره تحویل‌شده باعث اجرای دوباره عامل نمی‌شود. ورودی حافظه نهان پس از 20 دقیقه یا با رسیدن تعداد ورودی‌های ردیابی‌شده به 5000، هرکدام زودتر رخ دهد، منقضی می‌شود.

## درنگ ورودی

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

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

- درنگ فقط روی پیام‌های متنی اعمال می‌شود؛ رسانه/پیوست‌ها بی‌درنگ تخلیه می‌شوند.
- فرمان‌های کنترلی (توقف/لغو/وضعیت و غیره) درنگ را دور می‌زنند تا بی‌درنگ ارسال شوند.
- به‌طور پیش‌فرض غیرفعال است: `messages.inbound.debounceMs` پیش‌فرض داخلی ندارد، بنابراین درنگ تنها پس از تنظیم آن (به‌صورت سراسری یا برای هر کانال) فعال می‌شود.
- گزینش صریح `coalesceSameSenderDms` در iMessage تنها استثنا است: همه متن‌های پیام مستقیم از یک فرستنده (از جمله فرمان‌ها) را آن‌قدر نگه می‌دارد تا ارسال تفکیک‌شده فرمان+نشانی وب توسط Apple در یک نوبت دریافت شود. گفت‌وگوهای گروهی فارغ از این تنظیم همیشه بی‌درنگ ارسال می‌شوند.

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

مالک نشست‌ها Gateway است، نه کارخواه‌ها.

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

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

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

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

Pluginهای کانال چند فیلد متنی را در زمینه ورودی، به‌ترتیب از بیشترین تا کمترین اولویت، پر می‌کنند:

| فیلد             | هدف                                                                                                     |
| ----------------- | ----------------------------------------------------------------------------------------------------------- |
| `BodyForAgent`    | متن روبه‌روی مدل برای نوبت کنونی. اگر تنظیم نشده باشد، به `CommandBody` / `RawBody` / `Body` برمی‌گردد.        |
| `BodyForCommands` | متن پاک‌سازی‌شده برای تجزیه دستورالعمل/فرمان. اگر تنظیم نشده باشد، به `CommandBody` / `RawBody` / `Body` برمی‌گردد. |
| `CommandBody`     | بدنه میانی قدیمی؛ `BodyForCommands` را ترجیح دهید.                                                         |
| `RawBody`         | نام مستعار منسوخ‌شده برای `CommandBody`.                                                                         |
| `Body`            | بدنه پرامپت قدیمی؛ ممکن است پاکت‌های کانال و پوشش‌های تاریخچه را شامل شود.                                     |

وقتی کانالی تاریخچه را ارائه می‌کند، آن را با موارد زیر می‌پوشاند:

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

در گفت‌وگوهای غیرمستقیم (گروه‌ها/کانال‌ها/اتاق‌ها)، برچسب فرستنده به ابتدای بدنه پیام کنونی افزوده می‌شود تا با سبک ورودی‌های تاریخچه مطابقت داشته باشد. حذف دستورالعمل فقط روی بخش پیام کنونی اعمال می‌شود، بنابراین تاریخچه دست‌نخورده می‌ماند. کانال‌هایی که تاریخچه را می‌پوشانند باید `BodyForCommands` (یا `CommandBody` / `RawBody` قدیمی) را روی متن اصلی پیام تنظیم کنند و `Body` را به‌عنوان پرامپت ترکیبی نگه دارند.

بافرهای تاریخچه فقط شامل موارد در انتظار هستند: پیام‌های گروهی را که باعث اجرا نشده‌اند (برای مثال، پیام‌های مشروط به اشاره) شامل می‌شوند و پیام‌هایی را که از قبل در رونوشت نشست هستند کنار می‌گذارند. تاریخچه ساخت‌یافته، پاسخ، پیام هدایت‌شده و فراداده کانال هنگام سرهم‌بندی پرامپت به‌شکل بلوک‌های زمینه نقش کاربرِ غیرقابل‌اعتماد رندر می‌شوند.

اندازه تاریخچه را با `messages.groupChat.historyLimit` (پیش‌فرض سراسری) یا بازنویسی‌های هر کانال مانند `channels.slack.historyLimit` و `channels.telegram.accounts.<id>.historyLimit` پیکربندی کنید (برای غیرفعال‌کردن، `0` را تنظیم کنید).

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

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

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

## صف‌بندی و پیگیری‌ها

وقتی اجرایی از قبل فعال است، پیام‌های ورودی به‌طور پیش‌فرض آن را هدایت می‌کنند. `messages.queue` حالت را کنترل می‌کند:

| حالت              | رفتار                                            |
| ----------------- | --------------------------------------------------- |
| `steer` (پیش‌فرض) | پرامپت جدید را به اجرای فعال تزریق می‌کند.          |
| `followup`        | پیام را پس از پایان اجرای فعال اجرا می‌کند.      |
| `collect`         | پیام‌های سازگار را در یک نوبت بعدی دسته‌بندی می‌کند.      |
| `interrupt`       | اجرای فعال را لغو می‌کند، سپس جدیدترین پرامپت را آغاز می‌کند. |

پیش‌فرض‌ها: `messages.queue.debounceMs` برابر 500ms است (به‌طور یکسان برای هدایت، پیگیری و دسته‌بندی گردآوری اعمال می‌شود)، `messages.queue.cap` برابر 20 پیام صف‌شده است و `messages.queue.drop` برابر `summarize` است (`old` و `new` نیز در دسترس‌اند). بازنویسی‌های هر کانال را از طریق `messages.queue.byChannel` و `messages.queue.debounceMsByChannel` پیکربندی کنید.

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

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

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

## جریان‌سازی، قطعه‌بندی و دسته‌بندی

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

- `agents.defaults.blockStreamingDefault` (`on|off`، پیش‌فرض `off`)
- `agents.defaults.blockStreamingBreak` (`text_end|message_end`)
- `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`)
- `agents.defaults.blockStreamingCoalesce` (دسته‌بندی مبتنی بر بیکاری)
- `agents.defaults.humanDelay` (مکث شبیه انسان میان پاسخ‌های بلوکی)
- بازنویسی‌های کانال: `*.streaming.block.enabled` و `*.streaming.block.coalesce` در کانال‌های همراه؛ کلیدهای تخت قدیمی توسط `openclaw doctor --fix` مهاجرت داده می‌شوند. جریان‌سازی بلوکی در همه کانال‌ها، از جمله Telegram، غیرفعال است مگر اینکه صریحاً فعال شود. QQ Bot استثنا است: هیچ کلید `streaming.block` ندارد و پاسخ‌های بلوکی را جریان‌سازی می‌کند، مگر اینکه `channels.qqbot.streaming.mode` برابر `"off"` باشد.

جزئیات: [جریان‌سازی + قطعه‌بندی](/fa/concepts/streaming).

## نمایانی استدلال و توکن‌ها

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

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

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

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

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

## پاسخ‌های بی‌صدا

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

سیاست سکوت براساس نوع مکالمه تعیین می‌شود:

- مکالمه‌های مستقیم هرگز راهنمای پرامپت `NO_REPLY` را دریافت نمی‌کنند. اگر اجرای مستقیمی تصادفاً فقط یک توکن بی‌صدا برگرداند، OpenClaw به‌جای بازنویسی یا تحویل، آن را سرکوب می‌کند.
- گروه‌ها/کانال‌ها به‌طور پیش‌فرض سکوت را مجاز می‌دانند. در حالت پاسخ قابل‌مشاهده `message_tool`، سکوت یعنی مدل `message(action=send)` را فراخوانی نمی‌کند.
- هماهنگ‌سازی داخلی به‌طور پیش‌فرض سکوت را مجاز می‌داند.

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

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

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

## مرتبط

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