سطوح تفکر

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

• دستور درون‌خطی در هر بدنه ورودی: /t <level>، /think:<level>، یا /thinking <level>.
• سطح‌ها (نام‌های جایگزین): off | minimal | low | medium | high | xhigh | adaptive | max
  • minimal → «فکر کن»
  • low → «سخت فکر کن»
  • medium → «سخت‌تر فکر کن»
  • high → «فوق‌العاده فکر کن» (حداکثر بودجه)
  • xhigh → «فوق‌العاده فکر کن+» (مدل‌های 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 را عرضه می‌کند؛ این دستور به همان مسیر حداکثر تلاشِ در مالکیت ارائه‌دهنده نگاشت می‌شود.
  • مدل‌های مستقیم 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:off یا بازنشانی نشست پس از بی‌کاری پاک می‌شود.
• پاسخ تأیید ارسال می‌شود (Thinking level set to high. / Thinking disabled.). اگر سطح نامعتبر باشد (مثلاً /thinking big)، فرمان با یک راهنما رد می‌شود و وضعیت نشست بدون تغییر می‌ماند.
• برای دیدن سطح تفکر فعلی، /think (یا /think:) را بدون آرگومان بفرستید.

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

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

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

• سطح‌ها: on|off.
• پیام فقط-دستور بازنویسی حالت سریع نشست را تغییر می‌دهد و پاسخ Fast mode enabled. / Fast mode disabled. می‌دهد.
• برای دیدن وضعیت مؤثر فعلی حالت سریع، /fast (یا /fast status) را بدون حالت بفرستید.
• OpenClaw حالت سریع را به این ترتیب تفکیک می‌کند:
  1. /fast on|off درون‌خطی/فقط-دستور
  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 یک بازنویسی نشست صریح ذخیره می‌کند؛ آن را از طریق رابط کاربری Sessions با انتخاب inherit پاک کنید.
• دستور درون‌خطی فقط بر همان پیام اثر می‌گذارد؛ در غیر این صورت پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• برای دیدن سطح پرجزئیات فعلی، /verbose (یا /verbose:) را بدون آرگومان بفرستید.
• وقتی پرجزئیات فعال است، عامل‌هایی که نتایج ابزار ساختاریافته منتشر می‌کنند (Pi، عامل‌های JSON دیگر) هر فراخوانی ابزار را به‌صورت پیام جداگانه فقط-فراداده برمی‌گردانند، در صورت وجود با پیشوند <emoji> <tool-name>: <arg>. این خلاصه‌های ابزار به‌محض شروع هر ابزار ارسال می‌شوند (حباب‌های جداگانه)، نه به‌صورت دلتاهای استریم.
• خلاصه‌های شکست ابزار در حالت عادی هم قابل مشاهده می‌مانند، اما پسوندهای جزئیات خطای خام پنهان می‌شوند مگر اینکه پرجزئیات on یا full باشد.
• وقتی پرجزئیات full باشد، خروجی‌های ابزار نیز پس از تکمیل ارسال می‌شوند (حباب جداگانه، کوتاه‌شده تا طول امن). اگر هنگام اجرای یک کار /verbose on|full|off را تغییر دهید، حباب‌های ابزار بعدی از تنظیم جدید پیروی می‌کنند.
• agents.defaults.toolProgressDetail شکل خلاصه‌های ابزار /verbose و خطوط ابزار پیش‌نویس پیشرفت را کنترل می‌کند. برای برچسب‌های انسانی فشرده مانند 🛠️ Exec: checking JS syntax از "explain" (پیش‌فرض) استفاده کنید؛ وقتی می‌خواهید فرمان/جزئیات خام نیز برای اشکال‌زدایی اضافه شود، از "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)، سپس جایگزین (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 نیست.
• گزینه اول همیشه Default (<resolved level>) است، که در آن پیش‌فرض تفکیک‌شده از نمایه تفکر ارائه‌دهنده مدل نشست فعال به‌علاوه همان منطق جایگزینی می‌آید که /status و session_status استفاده می‌کنند.
• انتخاب‌گر از 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/چت همان شناسه‌ها و برچسب‌های پروفایلی را رندر کنند که اعتبارسنجی زمان اجرا استفاده می‌کند.