---
read_when:
    - توضیح چگونگی تبدیل پیام‌های ورودی به پاسخ‌ها
    - شفاف‌سازی نشست‌ها، حالت‌های صف‌بندی یا رفتار استریمینگ
    - مستندسازی قابلیت مشاهدهٔ استدلال و پیامدهای استفاده از آن
summary: جریان پیام، نشست‌ها، صف‌بندی و نمایش استدلال
title: پیام‌ها
x-i18n:
    generated_at: "2026-07-27T14:02:13Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: e42bed834e9a57fb8a248c8654b75ea9977928582f68a83859cf6c16ed0b6bf5
    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` پیش‌فرض داخلی ندارد، بنابراین انتظار تثبیت فقط پس از تنظیم آن (به‌صورت سراسری یا برای هر کانال) فعال می‌شود.
- iMessage از همان خط‌مشی عمومی انتظار تثبیت پیروی می‌کند. `imsg` نسخه 0.13.1 و جدیدتر، ارسال‌های تفکیک‌شده پیش‌نمایش URL اپل را پیش از دریافت آن‌ها توسط OpenClaw ادغام می‌کند؛ بنابراین تنظیم انتظار تثبیت ویژه iMessage لازم نیست.

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

مالک نشست‌ها 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`       | اجرای فعال را لغو می‌کند، سپس جدیدترین پرامپت را آغاز می‌کند. |

صف برای دسته‌بندی هدایت، پیگیری و جمع‌آوری از انتظار تثبیت داخلی 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).

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

- پیشوندهای خروجی در `channels.<channel>.responsePrefix` و `channels.<channel>.accounts.<id>.responsePrefix` قرار دارند. مقادیر حساب اولویت دارند. وقتی آن فیلدهای متعارف تنظیم نشده باشند، Doctor مقدار جایگزین سراسری را در بلوک‌های کانال پیکربندی‌شده کپی می‌کند؛ `messages.responsePrefix` برای کانال‌های ضمنی و سفارشی به‌عنوان مقدار جایگزین باقی می‌ماند.
- رشته‌بندی پاسخ از طریق `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) - یکپارچه‌سازی‌های پلتفرم پیام‌رسانی
