---
read_when:
    - توضیح اینکه پیام‌های ورودی چگونه به پاسخ تبدیل می‌شوند
    - شفاف‌سازی نشست‌ها، حالت‌های صف‌بندی، یا رفتار جریان‌دهی
    - مستندسازی قابلیت مشاهدهٔ استدلال و پیامدهای استفاده
summary: جریان پیام، نشست‌ها، صف‌بندی و قابلیت مشاهدهٔ استدلال
title: پیام‌ها
x-i18n:
    generated_at: "2026-05-10T19:36:06Z"
    model: gpt-5.5
    provider: openai
    source_hash: 053ff7b2ecca07e99057aed2f9ba199a6c1a07f15e865915045d25d128db984b
    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,
      },
    },
  },
}
```

نکات:

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

## جلسه‌ها و دستگاه‌ها

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

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

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

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

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

`content` نتیجه ابزار، نتیجه قابل مشاهده برای مدل است. `details` نتیجه ابزار
فراداده زمان اجرا برای رندر رابط کاربری، عیب‌یابی، تحویل رسانه و 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 از جریان استدلال در یک حباب پیش‌نویس گذرا پشتیبانی می‌کند که پس از تحویل نهایی حذف می‌شود؛ برای خروجی استدلال پایدار از `/reasoning on` استفاده کنید.

جزئیات: [دستورهای تفکر + استدلال](/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 همچنین از پاسخ‌های خاموش برای خطاهای runner داخلی استفاده می‌کند که
پیش از هر پاسخ دستیار در چت‌های غیرمستقیم رخ می‌دهند، تا گروه‌ها/کانال‌ها
متن آماده خطای Gateway را نبینند. چت‌های مستقیم به‌طور پیش‌فرض متن کوتاه خطا را نشان می‌دهند؛
جزئیات خام runner فقط وقتی نشان داده می‌شوند که `/verbose` برابر `on` یا `full` باشد.

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

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

## مرتبط

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