سطوح تفکر

چه کاری انجام می‌دهد

• دستور درون‌خطی در هر بدنه ورودی: /t <level>، /think:<level>، یا /thinking <level>.
• سطح‌ها (نام‌های مستعار): off | minimal | low | medium | high | xhigh | adaptive | max
  • minimal → "think"
  • low → "think hard"
  • medium → "think harder"
  • high → "ultrathink" (حداکثر بودجه)
  • xhigh → "ultrathink+" (مدل‌های GPT-5.2+ و Codex، به‌علاوه تلاش Anthropic Claude Opus 4.7+)
  • adaptive → تفکر تطبیقی مدیریت‌شده توسط ارائه‌دهنده (برای Claude 4.6 روی Anthropic/Bedrock، Anthropic Claude Opus 4.7+، و تفکر پویای Google Gemini پشتیبانی می‌شود)
  • max → حداکثر استدلال ارائه‌دهنده (Anthropic Claude Opus 4.7+؛ Ollama این را به بالاترین تلاش بومی think خود نگاشت می‌کند)
  • x-high، x_high، extra-high، extra high، و extra_high به xhigh نگاشت می‌شوند.
  • highest به high نگاشت می‌شود.
• نکته‌های ارائه‌دهنده:
  • منوها و انتخابگرهای تفکر بر اساس نمایه ارائه‌دهنده هدایت می‌شوند. Pluginهای ارائه‌دهنده مجموعه دقیق سطح‌ها را برای مدل انتخاب‌شده اعلام می‌کنند، از جمله برچسب‌هایی مانند on دودویی.
  • adaptive، xhigh، و max فقط برای نمایه‌های ارائه‌دهنده/مدلی نمایش داده می‌شوند که از آن‌ها پشتیبانی می‌کنند. دستورهای تایپ‌شده برای سطح‌های پشتیبانی‌نشده با گزینه‌های معتبر همان مدل رد می‌شوند.
  • سطح‌های پشتیبانی‌نشده ذخیره‌شده موجود بر اساس رتبه نمایه ارائه‌دهنده دوباره نگاشت می‌شوند. adaptive روی مدل‌های غیرتطبیقی به medium برمی‌گردد، در حالی که xhigh و max به بزرگ‌ترین سطح پشتیبانی‌شده غیر از off برای مدل انتخاب‌شده برمی‌گردند.
  • مدل‌های Anthropic Claude 4.6 وقتی سطح تفکر صریحی تنظیم نشده باشد به‌طور پیش‌فرض adaptive هستند.
  • Anthropic Claude Opus 4.8 و Opus 4.7 تفکر را خاموش نگه می‌دارند مگر اینکه صریحا سطح تفکر تنظیم کنید. پیش‌فرض تلاش متعلق به ارائه‌دهنده در Opus 4.8 پس از فعال شدن تفکر تطبیقی high است.
  • Anthropic Claude Opus 4.7+ دستور /think xhigh را به تفکر تطبیقی به‌همراه output_config.effort: "xhigh" نگاشت می‌کند، چون /think یک دستور تفکر است و xhigh تنظیم تلاش Opus است.
  • Anthropic Claude Opus 4.7+ همچنین /think max را ارائه می‌کند؛ این دستور به همان مسیر حداکثر تلاش متعلق به ارائه‌دهنده نگاشت می‌شود.
  • مدل‌های مستقیم DeepSeek V4 دستور /think xhigh|max را ارائه می‌کنند؛ هر دو به reasoning_effort: "max" در DeepSeek نگاشت می‌شوند، در حالی که سطح‌های پایین‌تر غیر از خاموش به high نگاشت می‌شوند.
  • مدل‌های DeepSeek V4 مسیر‌یابی‌شده از طریق OpenRouter دستور /think xhigh را ارائه می‌کنند و به‌جای reasoning_effort سطح‌بالای بومی DeepSeek، مقدارهای reasoning.effort پشتیبانی‌شده توسط OpenRouter را می‌فرستند. سطح‌های پایین‌تر غیر از خاموش به high نگاشت می‌شوند، و بازنویسی‌های ذخیره‌شده max به xhigh برمی‌گردند.
  • مدل‌های Ollama با قابلیت تفکر دستور /think low|medium|high|max را ارائه می‌کنند؛ max به think: "high" بومی نگاشت می‌شود چون API بومی Ollama رشته‌های تلاش low، medium، و high را می‌پذیرد.
  • مدل‌های OpenAI GPT، /think را از طریق پشتیبانی تلاش API Responses ویژه هر مدل نگاشت می‌کنند. /think off فقط زمانی reasoning.effort: "none" را می‌فرستد که مدل مقصد از آن پشتیبانی کند؛ در غیر این صورت OpenClaw به‌جای فرستادن مقدار پشتیبانی‌نشده، payload استدلال غیرفعال را حذف می‌کند.
  • ورودی‌های کاتالوگ سفارشی سازگار با OpenAI می‌توانند با تنظیم models.providers.<provider>.models[].compat.supportedReasoningEfforts برای شامل کردن "xhigh"، پشتیبانی از /think xhigh را فعال کنند. این از همان فراداده سازگاری استفاده می‌کند که payloadهای تلاش استدلال خروجی OpenAI را نگاشت می‌کند، بنابراین منوها، اعتبارسنجی نشست، CLI عامل، و llm-task با رفتار ترابری هم‌نظر می‌شوند.
  • ارجاع‌های OpenRouter Hunter Alpha پیکربندی‌شده کهنه، تزریق استدلال پروکسی را رد می‌کنند چون آن مسیر بازنشسته می‌توانست متن پاسخ نهایی را از طریق فیلدهای استدلال برگرداند.
  • Google Gemini دستور /think adaptive را به تفکر پویای متعلق به ارائه‌دهنده Gemini نگاشت می‌کند. درخواست‌های Gemini 3 یک thinkingLevel ثابت را حذف می‌کنند، در حالی که درخواست‌های Gemini 2.5 مقدار thinkingBudget: -1 را می‌فرستند؛ سطح‌های ثابت همچنان به نزدیک‌ترین thinkingLevel یا بودجه Gemini برای آن خانواده مدل نگاشت می‌شوند.
  • MiniMax M2.x (minimax/MiniMax-M2*) در مسیر جریان سازگار با Anthropic، به‌طور پیش‌فرض thinking: { type: "disabled" } است مگر اینکه صریحا تفکر را در پارامترهای مدل یا پارامترهای درخواست تنظیم کنید. این از نشت دلتاهای reasoning_content از قالب جریان غیر‌بومی Anthropic در M2.x جلوگیری می‌کند. MiniMax-M3 (و M3.x) مستثنا است: M3 بلوک‌های تفکر درست Anthropic را منتشر می‌کند و وقتی تفکر غیرفعال است محتوای خالی برمی‌گرداند، بنابراین OpenClaw، M3 را در مسیر تفکر حذف‌شده/تطبیقی ارائه‌دهنده نگه می‌دارد.
  • Z.AI (zai/*) برای بیشتر مدل‌های GLM دودویی (on/off) است. GLM-5.2 استثنا است: /think off|low|high|max را ارائه می‌کند، low و high را به reasoning_effort: "high" در Z.AI نگاشت می‌کند، و max را به reasoning_effort: "max" نگاشت می‌کند.
  • Moonshot Kimi K2.7 Code (moonshot/kimi-k2.7-code) همیشه فکر می‌کند. نمایه آن فقط on را ارائه می‌کند، و OpenClaw فیلد خروجی thinking را همان‌طور که Moonshot لازم دارد حذف می‌کند. دیگر مدل‌های moonshot/*، /think off را به thinking: { type: "disabled" } و هر سطح غیر از off را به thinking: { type: "enabled" } نگاشت می‌کنند. وقتی تفکر فعال است، Moonshot فقط tool_choice با مقدارهای auto|none را می‌پذیرد؛ OpenClaw مقدارهای ناسازگار را به auto نرمال‌سازی می‌کند.

ترتیب حل‌وفصل

1. دستور درون‌خطی روی پیام (فقط روی همان پیام اعمال می‌شود).
2. بازنویسی نشست (با فرستادن یک پیام فقط شامل دستور تنظیم می‌شود).
3. پیش‌فرض هر عامل (agents.list[].thinkingDefault در پیکربندی).
4. پیش‌فرض سراسری (agents.defaults.thinkingDefault در پیکربندی).
5. بازگشت: پیش‌فرض اعلام‌شده توسط ارائه‌دهنده وقتی در دسترس باشد؛ در غیر این صورت مدل‌های دارای قابلیت استدلال به medium یا نزدیک‌ترین سطح پشتیبانی‌شده غیر از off برای آن مدل حل می‌شوند، و مدل‌های بدون استدلال روی off می‌مانند.

تنظیم پیش‌فرض نشست

• پیامی بفرستید که فقط دستور باشد (فضای خالی مجاز است)، مانند /think:medium یا /t high.
• این برای نشست فعلی باقی می‌ماند (به‌طور پیش‌فرض برای هر فرستنده). از /think default برای پاک کردن بازنویسی نشست و به‌ارث‌بردن پیش‌فرض پیکربندی‌شده/ارائه‌دهنده استفاده کنید؛ نام‌های مستعار شامل inherit، clear، reset، و unpin هستند.
• /think off یک بازنویسی خاموش صریح ذخیره می‌کند. این تفکر را تا زمانی که بازنویسی نشست را تغییر دهید یا پاک کنید غیرفعال می‌کند.
• پاسخ تأیید فرستاده می‌شود (Thinking level set to high. / Thinking disabled.). اگر سطح نامعتبر باشد (مثلا /thinking big)، فرمان با یک راهنما رد می‌شود و وضعیت نشست بدون تغییر می‌ماند.
• /think (یا /think:) را بدون آرگومان بفرستید تا سطح تفکر فعلی را ببینید.

اعمال بر اساس عامل

• OpenClaw تعبیه‌شده: سطح حل‌شده به زمان‌اجرای عامل OpenClaw درون‌فرآیندی پاس داده می‌شود.
• پشتانه Claude CLI: سطح‌های غیر از خاموش هنگام استفاده از claude-cli به‌صورت --effort به Claude Code پاس داده می‌شوند؛ پشتانه‌های CLI را ببینید.

حالت سریع (/fast)

• سطح‌ها: auto|on|off|default.
• پیام فقط شامل دستور، بازنویسی حالت سریع نشست را تغییر می‌دهد و پاسخ Fast mode set to auto.، Fast mode enabled.، یا Fast mode disabled. می‌دهد. از /fast default برای پاک کردن بازنویسی نشست و به‌ارث‌بردن پیش‌فرض پیکربندی‌شده استفاده کنید؛ نام‌های مستعار شامل inherit، clear، reset، و unpin هستند.
• /fast (یا /fast status) را بدون حالت بفرستید تا وضعیت مؤثر فعلی حالت سریع را ببینید.
• OpenClaw حالت سریع را به این ترتیب حل می‌کند:
  1. بازنویسی درون‌خطی/فقط‌دستور /fast auto|on|off (/fast default این لایه را پاک می‌کند)
  2. بازنویسی نشست
  3. پیش‌فرض هر عامل (agents.list[].fastModeDefault)
  4. پیکربندی هر مدل: agents.defaults.models["<provider>/<model>"].params.fastMode
  5. بازگشت: off
• auto حالت نشست/پیکربندی را به‌صورت auto نگه می‌دارد اما هر فراخوانی مدل جدید را مستقل حل می‌کند. فراخوانی‌هایی که پیش از آستانه auto شروع می‌شوند حالت سریع را فعال دارند؛ فراخوانی‌های تلاش دوباره، بازگشت، نتیجه ابزار، یا ادامه بعدی با حالت سریع غیرفعال شروع می‌شوند. آستانه به‌طور پیش‌فرض ۶۰ ثانیه است؛ برای تغییر آن، agents.defaults.models["<provider>/<model>"].params.fastAutoOnSeconds را روی مدل فعال تنظیم کنید.
• برای openai/*، حالت سریع با فرستادن service_tier=priority روی درخواست‌های Responses پشتیبانی‌شده، به پردازش اولویت‌دار OpenAI نگاشت می‌شود.
• برای مدل‌های openai/* / openai-codex/* مبتنی بر Codex، حالت سریع همان پرچم service_tier=priority را روی Codex Responses می‌فرستد. نوبت‌های app-server بومی Codex، tier را فقط روی turn/start یا شروع/ازسرگیری thread دریافت می‌کنند، بنابراین auto نمی‌تواند tier یک نوبت app-server از قبل درحال‌اجرا را دوباره تنظیم کند؛ این روی نوبت مدل بعدی که OpenClaw شروع می‌کند اعمال می‌شود.
• برای درخواست‌های مستقیم عمومی anthropic/*، از جمله ترافیک احراز هویت‌شده با OAuth که به api.anthropic.com فرستاده می‌شود، حالت سریع به tierهای سرویس Anthropic نگاشت می‌شود: /fast on مقدار service_tier=auto را تنظیم می‌کند، /fast off مقدار service_tier=standard_only را تنظیم می‌کند.
• برای minimax/* در مسیر سازگار با Anthropic، /fast on (یا params.fastMode: true) مقدار MiniMax-M2.7 را به MiniMax-M2.7-highspeed بازنویسی می‌کند.
• پارامترهای صریح مدل Anthropic با نام serviceTier / service_tier وقتی هر دو تنظیم شده باشند، پیش‌فرض حالت سریع را بازنویسی می‌کنند. OpenClaw همچنان تزریق tier سرویس Anthropic را برای URLهای پایه پروکسی غیر Anthropic رد می‌کند.
• /status وقتی حالت سریع فعال است Fast و وقتی حالت پیکربندی‌شده auto است Fast:auto را نشان می‌دهد.

دستورهای پرجزئیات (/verbose یا /v)

• سطح‌ها: on (حداقلی) | full | off (پیش‌فرض).
• پیام فقط شامل دستور، حالت پرجزئیات نشست را تغییر می‌دهد و پاسخ Verbose logging enabled. / Verbose logging disabled. می‌دهد؛ سطح‌های نامعتبر بدون تغییر وضعیت، یک راهنما برمی‌گردانند.
• /verbose off یک بازنویسی صریح نشست ذخیره می‌کند؛ آن را از طریق UI نشست‌ها با انتخاب inherit پاک کنید.
• فرستندگان مجاز کانال خارجی می‌توانند بازنویسی پرجزئیات نشست را پایدار کنند. کلاینت‌های داخلی gateway/webchat برای پایدار کردن آن به operator.admin نیاز دارند.
• دستور درون‌خطی فقط روی همان پیام اثر می‌گذارد؛ در غیر این صورت پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• /verbose (یا /verbose:) را بدون آرگومان بفرستید تا سطح پرجزئیات فعلی را ببینید.
• وقتی حالت پرجزئیات روشن است، عامل‌هایی که نتیجه‌های ساختاریافته ابزار منتشر می‌کنند، هر فراخوانی ابزار را به‌صورت پیام جداگانه فقط‌فراداده برمی‌گردانند که در صورت وجود با <emoji> <tool-name>: <arg> پیشوند می‌گیرد. این خلاصه‌های ابزار به‌محض شروع هر ابزار فرستاده می‌شوند (حباب‌های جداگانه)، نه به‌صورت دلتاهای جریانی.
• خلاصه‌های شکست ابزار در حالت عادی قابل مشاهده می‌مانند، اما پسوندهای جزئیات خطای خام پنهان می‌شوند مگر اینکه پرجزئیات روی full باشد.
• وقتی پرجزئیات full است، خروجی‌های ابزار نیز پس از تکمیل ارسال می‌شوند (حباب جداگانه، کوتاه‌شده تا طول امن). اگر هنگام اجرای یک run، /verbose on|full|off را تغییر دهید، حباب‌های ابزار بعدی از تنظیم جدید پیروی می‌کنند.
• agents.defaults.toolProgressDetail شکل خلاصه‌های ابزار /verbose و خط‌های ابزار پیش‌نویس پیشرفت را کنترل می‌کند. از "explain" (پیش‌فرض) برای برچسب‌های انسانی فشرده مانند 🛠️ Exec: checking JS syntax استفاده کنید؛ وقتی می‌خواهید فرمان/جزئیات خام نیز برای اشکال‌زدایی افزوده شود از "raw" استفاده کنید. مقدار agents.list[].toolProgressDetail برای هر عامل، پیش‌فرض را بازنویسی می‌کند.
  • explain: 🛠️ Exec: check JS syntax for /tmp/app.js
  • raw: 🛠️ Exec: check JS syntax for /tmp/app.js, node --check /tmp/app.js

دستورهای ردیابی Plugin (/trace)

• سطح‌ها: on | off (پیش‌فرض).
• پیام فقط شامل دستور، خروجی ردیابی Plugin نشست را تغییر می‌دهد و پاسخ Plugin trace enabled. / Plugin trace disabled. می‌دهد.
• دستور درون‌خطی فقط روی همان پیام اثر می‌گذارد؛ در غیر این صورت پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• /trace (یا /trace:) را بدون آرگومان بفرستید تا سطح ردیابی فعلی را ببینید.
• /trace محدودتر از /verbose است: فقط خط‌های ردیابی/اشکال‌زدایی متعلق به Plugin مانند خلاصه‌های اشکال‌زدایی Active Memory را آشکار می‌کند.
• خط‌های ردیابی می‌توانند در /status و به‌صورت پیام تشخیصی دنباله‌دار پس از پاسخ عادی دستیار ظاهر شوند.

نمایش استدلال (/reasoning)

• سطح‌ها: on|off|stream.
• پیام فقط شامل دستور، تعیین می‌کند که آیا بلوک‌های تفکر در پاسخ‌ها نمایش داده شوند یا نه.
• وقتی فعال باشد، استدلال به‌صورت یک پیام جداگانه با پیشوند Thinking فرستاده می‌شود.
• stream: وقتی کانال فعال از پیش‌نمایش‌های استدلال پشتیبانی کند، هنگام تولید پاسخ، استدلال را جریان می‌دهد و سپس پاسخ نهایی را بدون استدلال می‌فرستد.
• نام مستعار: /reason.
• /reasoning (یا /reasoning:) را بدون آرگومان بفرستید تا سطح استدلال فعلی را ببینید.
• ترتیب حل‌وفصل: دستور درون‌خطی، سپس بازنویسی نشست، سپس پیش‌فرض هر عامل (agents.list[].reasoningDefault)، سپس پیش‌فرض سراسری (agents.defaults.reasoningDefault)، سپس بازگشت (off).

تگ‌های استدلال مدل محلیِ نادرست، محافظه‌کارانه مدیریت می‌شوند. بلوک‌های بسته‌ی <think>...</think> در پاسخ‌های عادی پنهان می‌مانند، و استدلالِ بسته‌نشده پس از متنی که از قبل قابل مشاهده است نیز پنهان می‌شود. اگر یک پاسخ به‌طور کامل در یک تگ بازِ بسته‌نشده قرار گرفته باشد و در غیر این صورت به‌صورت متن خالی تحویل داده شود، OpenClaw تگ بازِ نادرست را حذف می‌کند و متن باقی‌مانده را تحویل می‌دهد.

مرتبط

• مستندات حالت ارتقایافته در حالت ارتقایافته قرار دارد.

Heartbeatها

• بدنه‌ی کاوش Heartbeat همان اعلان Heartbeat پیکربندی‌شده است (پیش‌فرض: Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.). دستورالعمل‌های درون‌خطی در پیام Heartbeat طبق معمول اعمال می‌شوند (اما از تغییر پیش‌فرض‌های نشست از طریق Heartbeatها پرهیز کنید).
• تحویل Heartbeat به‌طور پیش‌فرض فقط شامل محموله‌ی نهایی است. برای ارسال پیام جداگانه‌ی Thinking نیز (در صورت وجود)، agents.defaults.heartbeat.includeReasoning: true یا برای هر عامل agents.list[].heartbeat.includeReasoning: true را تنظیم کنید.

رابط کاربری چت وب

• انتخاب‌گر thinking در چت وب، هنگام بارگذاری صفحه، سطح ذخیره‌شده‌ی نشست را از ذخیره‌گاه/پیکربندی نشست ورودی منعکس می‌کند.
• انتخاب سطحی دیگر، بازنویسی نشست را بلافاصله از طریق sessions.patch می‌نویسد؛ منتظر ارسال بعدی نمی‌ماند و یک بازنویسی یک‌باره‌ی thinkingOnce نیست.
• گزینه‌ی اول همیشه گزینه‌ی پاک‌کردن بازنویسی است. این گزینه Inherited: <resolved level> را نشان می‌دهد، از جمله Inherited: Off زمانی که thinking ارث‌بری‌شده غیرفعال باشد.
• انتخاب‌های صریح انتخاب‌گر از برچسب‌های سطح مستقیم خود استفاده می‌کنند و در صورت وجود، برچسب‌های ارائه‌دهنده را حفظ می‌کنند (برای مثال Maximum برای گزینه‌ی max با برچسب ارائه‌دهنده).
• انتخاب‌گر از thinkingLevels بازگردانده‌شده توسط ردیف/پیش‌فرض‌های نشست Gateway استفاده می‌کند، و thinkingOptions به‌عنوان فهرست برچسب قدیمی نگه داشته می‌شود. رابط کاربری مرورگر فهرست regex ارائه‌دهنده‌ی خودش را نگه نمی‌دارد؛ Pluginها مجموعه‌های سطحِ مختص مدل را مالکیت می‌کنند.
• /think:<level> همچنان کار می‌کند و همان سطح ذخیره‌شده‌ی نشست را به‌روزرسانی می‌کند، بنابراین دستورالعمل‌های چت و انتخاب‌گر همگام می‌مانند.

پروفایل‌های ارائه‌دهنده

• Pluginهای ارائه‌دهنده می‌توانند resolveThinkingProfile(ctx) را ارائه کنند تا سطح‌های پشتیبانی‌شده و پیش‌فرض مدل را تعریف کنند.
• Pluginهای ارائه‌دهنده‌ای که مدل‌های Claude را پروکسی می‌کنند باید از resolveClaudeThinkingProfile(modelId) در openclaw/plugin-sdk/provider-model-shared دوباره استفاده کنند تا کاتالوگ‌های مستقیم Anthropic و پروکسی هم‌راستا بمانند.
• هر سطح پروفایل یک id کانونی ذخیره‌شده دارد (off، minimal، low، medium، high، xhigh، adaptive، یا max) و ممکن است شامل یک label نمایشی باشد. ارائه‌دهندگان دودویی از { id: "low", label: "on" } استفاده می‌کنند.
• هوک‌های پروفایل، در صورت وجود، واقعیت‌های کاتالوگ ادغام‌شده را دریافت می‌کنند، از جمله reasoning، compat.thinkingFormat، و compat.supportedReasoningEfforts. از این واقعیت‌ها استفاده کنید تا پروفایل‌های دودویی یا سفارشی را فقط زمانی ارائه کنید که قرارداد درخواست پیکربندی‌شده از محموله‌ی متناظر پشتیبانی کند.
• Pluginهای ابزار که نیاز دارند یک بازنویسی صریح thinking را اعتبارسنجی کنند، باید از api.runtime.agent.resolveThinkingPolicy({ provider, model }) به‌همراه api.runtime.agent.normalizeThinkingLevel(...) استفاده کنند؛ آن‌ها نباید فهرست‌های سطح ارائه‌دهنده/مدل خودشان را نگه دارند.
• Pluginهای ابزار که به فراداده‌ی مدل سفارشی پیکربندی‌شده دسترسی دارند می‌توانند catalog را به resolveThinkingPolicy پاس بدهند تا اعلام‌های opt-in در compat.supportedReasoningEfforts در اعتبارسنجی سمت Plugin منعکس شوند.
• هوک‌های قدیمی منتشرشده (supportsXHighThinking، isBinaryThinking، و resolveDefaultThinkingLevel) به‌عنوان آداپتورهای سازگاری باقی می‌مانند، اما مجموعه‌های سطح سفارشی جدید باید از resolveThinkingProfile استفاده کنند.
• ردیف‌ها/پیش‌فرض‌های Gateway، thinkingLevels، thinkingOptions، و thinkingDefault را ارائه می‌کنند تا کلاینت‌های ACP/چت همان شناسه‌ها و برچسب‌های پروفایلی را رندر کنند که اعتبارسنجی زمان اجرا استفاده می‌کند.