سطوح تفکر

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

• دستور درون‌خطی در هر بدنهٔ ورودی: /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.7 به‌طور پیش‌فرض از تفکر تطبیقی استفاده نمی‌کند. پیش‌فرض تلاش API آن در مالکیت ارائه‌دهنده باقی می‌ماند، مگر اینکه صراحتاً سطح تفکر را تنظیم کنید.
  • Anthropic Claude Opus 4.7 دستور /think xhigh را به تفکر تطبیقی به‌علاوهٔ output_config.effort: "xhigh" نگاشت می‌کند، چون /think یک دستور تفکر است و xhigh تنظیم تلاش Opus 4.7 است.
  • Anthropic Claude Opus 4.7 همچنین /think max را ارائه می‌کند؛ این دستور به همان مسیر حداکثر تلاش تحت مالکیت ارائه‌دهنده نگاشت می‌شود.
  • مدل‌های Direct DeepSeek V4 دستور /think xhigh|max را ارائه می‌کنند؛ هر دو به reasoning_effort: "max" در DeepSeek نگاشت می‌شوند، در حالی که سطح‌های پایین‌ترِ غیر off به high نگاشت می‌شوند.
  • مدل‌های DeepSeek V4 مسیریابی‌شده از طریق OpenRouter دستور /think xhigh را ارائه می‌کنند و مقدارهای reasoning_effort پشتیبانی‌شده توسط OpenRouter را ارسال می‌کنند. بازنویسی‌های ذخیره‌شدهٔ max به xhigh برمی‌گردند.
  • مدل‌های Ollama دارای قابلیت تفکر دستور /think low|medium|high|max را ارائه می‌کنند؛ max به think: "high" بومی نگاشت می‌شود، چون API بومی Ollama رشته‌های تلاش low، medium و high را می‌پذیرد.
  • مدل‌های OpenAI GPT دستور /think را از طریق پشتیبانی تلاش Responses API مخصوص همان مدل نگاشت می‌کنند. /think off فقط وقتی مدل هدف از آن پشتیبانی کند، reasoning.effort: "none" را ارسال می‌کند؛ در غیر این صورت OpenClaw به‌جای ارسال مقدار پشتیبانی‌نشده، محمولهٔ استدلال غیرفعال‌شده را حذف می‌کند.
  • ورودی‌های کاتالوگ سازگار با OpenAI سفارشی می‌توانند با تنظیم models.providers.<provider>.models[].compat.supportedReasoningEfforts برای شامل کردن "xhigh"، در /think xhigh شرکت کنند. این از همان فرادادهٔ سازگاری استفاده می‌کند که محموله‌های تلاش استدلال خروجی OpenAI را نگاشت می‌کند، بنابراین منوها، اعتبارسنجی نشست، CLI عامل و llm-task با رفتار انتقال هماهنگ هستند.
  • ارجاع‌های پیکربندی‌شدهٔ قدیمی OpenRouter Hunter Alpha تزریق استدلال پروکسی را رد می‌کنند، چون آن مسیر بازنشسته می‌توانست متن پاسخ نهایی را از طریق فیلدهای استدلال برگرداند.
  • Google Gemini دستور /think adaptive را به تفکر پویای تحت مالکیت ارائه‌دهندهٔ Gemini نگاشت می‌کند. درخواست‌های Gemini 3 یک thinkingLevel ثابت را حذف می‌کنند، در حالی که درخواست‌های Gemini 2.5 مقدار thinkingBudget: -1 را ارسال می‌کنند؛ سطح‌های ثابت همچنان به نزدیک‌ترین thinkingLevel یا بودجهٔ Gemini برای آن خانوادهٔ مدل نگاشت می‌شوند.
  • MiniMax (minimax/*) در مسیر جریان سازگار با Anthropic به‌طور پیش‌فرض از thinking: { type: "disabled" } استفاده می‌کند، مگر اینکه تفکر را صراحتاً در پارامترهای مدل یا پارامترهای درخواست تنظیم کنید. این از نشت دلتاهای reasoning_content از قالب جریان غیر بومی Anthropic در MiniMax جلوگیری می‌کند.
  • Z.AI (zai/*) فقط از تفکر دودویی (on/off) پشتیبانی می‌کند. هر سطح غیر off به‌عنوان on در نظر گرفته می‌شود (به low نگاشت می‌شود).
  • 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:) را بدون آرگومان بفرستید.

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

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

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

• سطح‌ها: on|off|default.
• پیام فقط شامل دستور، بازنویسی حالت سریع نشست را روشن یا خاموش می‌کند و پاسخ Fast mode enabled. / Fast mode disabled. می‌دهد. از /fast default برای پاک کردن بازنویسی نشست و به‌ارث‌بردن پیش‌فرض پیکربندی‌شده استفاده کنید؛ نام‌های مستعار شامل inherit، clear، reset و unpin هستند.
• برای دیدن وضعیت مؤثر فعلی حالت سریع، /fast (یا /fast status) را بدون حالت بفرستید.
• OpenClaw حالت سریع را به این ترتیب حل می‌کند:
  1. بازنویسی درون‌خطی/فقط‌دستوری /fast on|off (/fast default این لایه را پاک می‌کند)
  2. بازنویسی نشست
  3. پیش‌فرض هر عامل (agents.list[].fastModeDefault)
  4. پیکربندی هر مدل: agents.defaults.models["<provider>/<model>"].params.fastMode
  5. حالت پشتیبان: off
• برای openai/*، حالت سریع با ارسال service_tier=priority در درخواست‌های Responses پشتیبانی‌شده به پردازش اولویت‌دار OpenAI نگاشت می‌شود.
• برای openai-codex/*، حالت سریع همان پرچم service_tier=priority را در Codex Responses ارسال می‌کند. OpenClaw یک سوییچ مشترک /fast را در هر دو مسیر احراز هویت نگه می‌دارد.
• برای درخواست‌های عمومی مستقیم anthropic/*، از جمله ترافیک احراز هویت‌شده با OAuth که به api.anthropic.com ارسال می‌شود، حالت سریع به سطح‌های سرویس 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 همچنان تزریق سطح سرویس Anthropic را برای URLهای پایهٔ پروکسی غیر Anthropic رد می‌کند.
• /status فقط وقتی حالت سریع فعال باشد Fast را نشان می‌دهد.

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

• سطح‌ها: on (حداقلی) | full | off (پیش‌فرض).
• پیام فقط شامل دستور، پرجزئیات بودن نشست را روشن یا خاموش می‌کند و پاسخ Verbose logging enabled. / Verbose logging disabled. می‌دهد؛ سطح‌های نامعتبر بدون تغییر وضعیت، یک راهنما برمی‌گردانند.
• /verbose off یک بازنویسی نشست صریح ذخیره می‌کند؛ آن را از طریق رابط کاربری نشست‌ها با انتخاب inherit پاک کنید.
• دستور درون‌خطی فقط روی همان پیام اثر می‌گذارد؛ در غیر این صورت پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• برای دیدن سطح پرجزئیات فعلی، /verbose (یا /verbose:) را بدون آرگومان بفرستید.
• وقتی حالت پرجزئیات روشن باشد، عامل‌هایی که نتایج ابزار ساخت‌یافته تولید می‌کنند (Pi و سایر عامل‌های JSON) هر فراخوانی ابزار را به‌عنوان پیام جداگانهٔ فقط‌فراداده برمی‌گردانند، و در صورت موجود بودن با <emoji> <tool-name>: <arg> پیشوند می‌دهند. این خلاصه‌های ابزار به‌محض شروع هر ابزار ارسال می‌شوند (حباب‌های جداگانه)، نه به‌صورت دلتاهای جریانی.
• خلاصه‌های شکست ابزار در حالت عادی قابل مشاهده می‌مانند، اما پسوندهای جزئیات خام خطا پنهان هستند مگر اینکه پرجزئیات روی on یا full باشد.
• وقتی پرجزئیات روی full باشد، خروجی‌های ابزار نیز پس از تکمیل ارسال می‌شوند (حباب جداگانه، کوتاه‌شده تا طول امن). اگر هنگام در حال اجرا بودن یک اجرا، /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.
• پیام فقط شامل دستور، نمایش بلوک‌های تفکر در پاسخ‌ها را روشن یا خاموش می‌کند.
• وقتی فعال باشد، استدلال به‌عنوان پیام جداگانه با پیشوند Reasoning: ارسال می‌شود.
• stream (فقط Telegram): هنگام تولید پاسخ، استدلال را در حباب پیش‌نویس Telegram جریان می‌دهد، سپس پاسخ نهایی را بدون استدلال ارسال می‌کند.
• نام مستعار: /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 به‌طور پیش‌فرض فقط شامل محمولهٔ نهایی است. برای ارسال پیام جداگانهٔ Reasoning: نیز (در صورت موجود بودن)، agents.defaults.heartbeat.includeReasoning: true یا برای هر عامل agents.list[].heartbeat.includeReasoning: true را تنظیم کنید.

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

• انتخابگر تفکر در چت وب، هنگام بارگذاری صفحه، سطح ذخیره‌شدهٔ نشست را از مخزن/پیکربندی نشست ورودی بازتاب می‌دهد.
• انتخاب سطحی دیگر، لغو نشست را بلافاصله از طریق sessions.patch می‌نویسد؛ منتظر ارسال بعدی نمی‌ماند و یک لغو یک‌بارهٔ thinkingOnce نیست.
• گزینهٔ نخست همیشه انتخاب پاک‌کردن لغو است. وقتی نشست یک پیش‌فرض مؤثرِ غیرخاموش را به ارث می‌برد، Inherited: <resolved level> را نشان می‌دهد، یا وقتی تفکر ارثی غیرفعال است، Off را نشان می‌دهد.
• انتخاب‌های صریح انتخابگر به‌عنوان لغو برچسب‌گذاری می‌شوند، درحالی‌که برچسب‌های ارائه‌دهنده در صورت وجود حفظ می‌شوند (برای مثال Override: 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" } استفاده می‌کنند.
• Pluginهای ابزار که باید یک لغو صریح تفکر را اعتبارسنجی کنند، باید از api.runtime.agent.resolveThinkingPolicy({ provider, model }) به‌همراه api.runtime.agent.normalizeThinkingLevel(...) استفاده کنند؛ نباید فهرست‌های سطح ارائه‌دهنده/مدل خودشان را نگه دارند.
• Pluginهای ابزار با دسترسی به فرادادهٔ مدل سفارشی پیکربندی‌شده می‌توانند catalog را به resolveThinkingPolicy پاس بدهند تا اعلام پشتیبانی‌های compat.supportedReasoningEfforts در اعتبارسنجی سمت Plugin بازتاب داده شود.
• هوک‌های قدیمی منتشرشده (supportsXHighThinking، isBinaryThinking و resolveDefaultThinkingLevel) به‌عنوان آداپتورهای سازگاری باقی می‌مانند، اما مجموعه سطح‌های سفارشی جدید باید از resolveThinkingProfile استفاده کنند.
• ردیف‌ها/پیش‌فرض‌های Gateway، thinkingLevels، thinkingOptions و thinkingDefault را عرضه می‌کنند تا کلاینت‌های ACP/چت همان شناسه‌ها و برچسب‌های پروفایلی را رندر کنند که اعتبارسنجی زمان اجرا استفاده می‌کند.