پیام‌ها

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

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

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

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

برای طرح‌واره کامل، پیکربندی را ببینید.

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

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

انتظار تثبیت ورودی

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

{  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 را نمایش می‌دهند؛ بنابراین منبع حقیقت هستند.

جزئیات: مدیریت نشست.

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

Pluginهای کانال چند فیلد متنی را در زمینه ورودی مقداردهی می‌کنند که ترتیب ترجیح آن‌ها از بیشترین به کمترین به شرح زیر است:

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

• [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 حالت را کنترل می‌کند:

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

جزئیات: صف فرمان و صف هدایت.

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

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" باشد.

جزئیات: جریان‌دهی + قطعه‌بندی.

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

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

جزئیات: دستورالعمل‌های تفکر + استدلال و مصرف توکن.

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

• پیشوندهای خروجی در channels.<channel>.responsePrefix و channels.<channel>.accounts.<id>.responsePrefix قرار دارند. مقادیر حساب اولویت دارند. وقتی آن فیلدهای متعارف تنظیم نشده باشند، Doctor مقدار جایگزین سراسری را در بلوک‌های کانال پیکربندی‌شده کپی می‌کند؛ messages.responsePrefix برای کانال‌های ضمنی و سفارشی به‌عنوان مقدار جایگزین باقی می‌ماند.
• رشته‌بندی پاسخ از طریق replyToMode و پیش‌فرض‌های مختص هر کانال.

جزئیات: پیکربندی و مستندات کانال.

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

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

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

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

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

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

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

مرتبط

• بازآرایی چرخه عمر پیام - طراحی هدف پایدار برای ارسال و دریافت
• جریان‌دهی - تحویل بی‌درنگ پیام
• تلاش مجدد - رفتار تلاش مجدد برای تحویل پیام
• صف - صف پردازش پیام
• کانال‌ها - یکپارچه‌سازی‌های پلتفرم پیام‌رسانی