Messages and delivery
پیامها
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, }, }, },}نکات:
- تأخیر ادغام برای پیامهای فقط متنی اعمال میشود؛ رسانه/پیوستها بلافاصله تخلیه میشوند.
- دستورهای کنترلی از تأخیر ادغام عبور میکنند تا مستقل باقی بمانند. کانالهایی که بهصراحت ادغام پیام خصوصی از همان فرستنده را فعال میکنند میتوانند دستورهای پیام خصوصی را در پنجره تأخیر ادغام نگه دارند تا یک محتوای ارسالشده در چند بخش بتواند به همان نوبت عامل بپیوندد.
جلسهها و دستگاهها
جلسهها در مالکیت Gateway هستند، نه کلاینتها.
- چتهای مستقیم در کلید جلسه اصلی عامل ادغام میشوند.
- گروهها/کانالها کلیدهای جلسه خودشان را میگیرند.
- ذخیرهساز جلسه و رونویسیها روی میزبان Gateway قرار دارند.
چند دستگاه/کانال میتوانند به یک جلسه نگاشت شوند، اما تاریخچه بهطور کامل به همه کلاینتها همگامسازی نمیشود. توصیه: برای گفتگوهای طولانی از یک دستگاه اصلی استفاده کنید تا از واگرایی زمینه جلوگیری شود. رابط کنترل و TUI همیشه رونویسی جلسه پشتیبانیشده توسط Gateway را نشان میدهند، بنابراین منبع حقیقت هستند.
جزئیات: مدیریت جلسه.
فراداده نتیجه ابزار
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.
مالکیت اجرای کانال
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صریح نیاز دارند)
جزئیات: جریاندهی + قطعهبندی.
نمایشپذیری استدلال و توکنها
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 آن رفتار را بر اساس نوع گفتگو حل میکند:
- گفتگوهای مستقیم بهطور پیشفرض سکوت را مجاز نمیدانند و یک پاسخ خاموش تنها را به یک جایگزین کوتاه قابل مشاهده بازنویسی میکنند.
- گروهها/کانالها بهطور پیشفرض سکوت را مجاز میدانند.
- هماهنگسازی داخلی بهطور پیشفرض سکوت را مجاز میداند.
OpenClaw همچنین از پاسخهای خاموش برای خطاهای runner داخلی استفاده میکند که
پیش از هر پاسخ دستیار در چتهای غیرمستقیم رخ میدهند، تا گروهها/کانالها
متن آماده خطای Gateway را نبینند. چتهای مستقیم بهطور پیشفرض متن کوتاه خطا را نشان میدهند؛
جزئیات خام runner فقط وقتی نشان داده میشوند که /verbose برابر on یا full باشد.
پیشفرضها زیر agents.defaults.silentReply و
agents.defaults.silentReplyRewrite قرار دارند؛ surfaces.<id>.silentReply و
surfaces.<id>.silentReplyRewrite میتوانند آنها را برای هر سطح بازنویسی کنند.
وقتی جلسه والد یک یا چند اجرای زیرعامل ایجادشده در انتظار دارد، پاسخهای خاموش تنها در همه سطوح بهجای بازنویسی حذف میشوند، تا والد تا زمانی که رویداد تکمیل فرزند پاسخ واقعی را تحویل دهد خاموش بماند.
مرتبط
- بازآرایی چرخه عمر پیام - طراحی هدفمند ارسال و دریافت بادوام
- جریاندهی — تحویل بلادرنگ پیام
- تلاش مجدد — رفتار تلاش مجدد برای تحویل پیام
- صف — صف پردازش پیام
- کانالها — یکپارچهسازیهای پلتفرم پیامرسانی