docs/docs/fa/tools/thinking.md

read_when	summary	title	x-i18n
تنظیم تجزیه یا پیش‌فرض‌های تفکر، حالت سریع، یا دستورالعمل پرجزئیات	نحو دستورها برای /think، /fast، /verbose، /trace و قابلیت مشاهدهٔ استدلال	سطوح تفکر	generated_at model provider source_hash source_path workflow 2026-04-30T16:32:32Z gpt-5.5 openai f9adf065e46cb64e4c2149b95ecd69ed887a17e2eff5a5569894defa3e7217b7 tools/thinking.md 16

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

• دستور درون‌خطی در هر بدنهٔ ورودی: /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، به‌علاوه effort مربوط به 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 این را به بالاترین effort بومی 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 به‌طور پیش‌فرض از تفکر تطبیقی استفاده نمی‌کند. پیش‌فرض effort در API آن همچنان در مالکیت ارائه‌دهنده می‌ماند، مگر اینکه صراحتا یک سطح تفکر تنظیم کنید.
  • Anthropic Claude Opus 4.7 دستور /think xhigh را به تفکر تطبیقی به‌همراه output_config.effort: "xhigh" نگاشت می‌کند، چون /think یک دستور تفکر است و xhigh تنظیم effort در Opus 4.7 است.
  • Anthropic Claude Opus 4.7 همچنین /think max را در دسترس می‌گذارد؛ این دستور به همان مسیر بیشینهٔ effort در مالکیت ارائه‌دهنده نگاشت می‌شود.
  • مدل‌های DeepSeek V4 دستورهای /think xhigh|max را در دسترس می‌گذارند؛ هر دو به reasoning_effort: "max" در DeepSeek نگاشت می‌شوند، در حالی که سطح‌های پایین‌تر غیر off به high نگاشت می‌شوند.
  • مدل‌های Ollama با قابلیت تفکر دستور /think low|medium|high|max را در دسترس می‌گذارند؛ max به think: "high" بومی نگاشت می‌شود، چون API بومی Ollama رشته‌های effort با مقدارهای low، medium، و high را می‌پذیرد.
  • مدل‌های OpenAI GPT دستور /think را از مسیر پشتیبانی effort ویژهٔ هر مدل در Responses API نگاشت می‌کنند. /think off فقط وقتی مدل هدف از آن پشتیبانی کند reasoning.effort: "none" را ارسال می‌کند؛ در غیر این صورت OpenClaw به‌جای ارسال مقدار پشتیبانی‌نشده، payload غیرفعال‌سازی استدلال را حذف می‌کند.
  • مدخل‌های کاتالوگ سفارشی سازگار با OpenAI می‌توانند با تنظیم models.providers.<provider>.models[].compat.supportedReasoningEfforts برای شامل کردن "xhigh"، پشتیبانی از /think xhigh را فعال کنند. این کار از همان فرادادهٔ سازگاری استفاده می‌کند که payloadهای effort استدلال خروجی OpenAI را نگاشت می‌کند؛ بنابراین منوها، اعتبارسنجی نشست، CLI عامل، و llm-task با رفتار انتقال هم‌نظر می‌مانند.
  • ارجاع‌های قدیمی پیکربندی‌شده به OpenRouter Hunter Alpha تزریق استدلال proxy را رد می‌کنند، چون آن مسیر بازنشسته می‌توانست متن پاسخ نهایی را از طریق فیلدهای استدلال برگرداند.
  • 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 توکار: سطح حل‌شده به runtime عامل Pi درون‌فرآیندی پاس داده می‌شود.

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

• سطح‌ها: on|off.
• پیام فقط شامل دستور، بازنویسی حالت سریع نشست را تغییر می‌دهد و با Fast mode enabled. / Fast mode disabled. پاسخ می‌دهد.
• برای دیدن وضعیت مؤثر فعلی حالت سریع، /fast (یا /fast status) را بدون mode بفرستید.
• 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های پایهٔ proxy غیر Anthropic رد می‌کند.
• /status فقط وقتی حالت سریع فعال باشد، Fast را نشان می‌دهد.

دستورهای verbose (/verbose یا /v)

• سطح‌ها: on (حداقلی) | full | off (پیش‌فرض).
• پیام فقط شامل دستور، verbose نشست را تغییر می‌دهد و با Verbose logging enabled. / Verbose logging disabled. پاسخ می‌دهد؛ سطح‌های نامعتبر بدون تغییر وضعیت، یک راهنما برمی‌گردانند.
• /verbose off یک بازنویسی صریح نشست ذخیره می‌کند؛ آن را از طریق UI نشست‌ها با انتخاب inherit پاک کنید.
• دستور درون‌خطی فقط همان پیام را تحت تأثیر قرار می‌دهد؛ در غیر این صورت پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• برای دیدن سطح verbose فعلی، /verbose (یا /verbose:) را بدون آرگومان بفرستید.
• وقتی verbose روشن است، عامل‌هایی که نتایج ساخت‌یافتهٔ ابزار منتشر می‌کنند (Pi، عامل‌های JSON دیگر) هر فراخوانی ابزار را به‌صورت پیام جداگانهٔ فقط-فراداده برمی‌گردانند، و وقتی موجود باشد با <emoji> <tool-name>: <arg> پیشوند می‌زنند (مسیر/فرمان). این خلاصه‌های ابزار به‌محض شروع هر ابزار ارسال می‌شوند (حباب‌های جداگانه)، نه به‌شکل دلتاهای جریان‌سازی.
• خلاصه‌های شکست ابزار در حالت عادی قابل مشاهده می‌مانند، اما پسوندهای جزئیات خطای خام پنهان هستند، مگر اینکه verbose برابر on یا full باشد.
• وقتی verbose برابر full است، خروجی‌های ابزار نیز پس از تکمیل فوروارد می‌شوند (حباب جداگانه، کوتاه‌شده تا طول امن). اگر هنگام در حال اجرا بودن یک اجرا، /verbose on|full|off را تغییر دهید، حباب‌های بعدی ابزار تنظیم جدید را رعایت می‌کنند.

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

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

مشاهده‌پذیری استدلال (/reasoning)

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

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

مرتبط

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

Heartbeatها

• بدنهٔ probe مربوط به Heartbeat همان prompt پیکربندی‌شدهٔ 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 به‌طور پیش‌فرض فقط شامل payload نهایی است. برای اینکه پیام جداگانهٔ Reasoning: نیز ارسال شود (وقتی موجود باشد)، agents.defaults.heartbeat.includeReasoning: true یا برای هر عامل agents.list[].heartbeat.includeReasoning: true را تنظیم کنید.

UI گفت‌وگوی وب

• انتخابگر تفکر گفت‌وگوی وب، سطح ذخیره‌شدهٔ نشست را از store/پیکربندی نشست ورودی هنگام بارگذاری صفحه بازتاب می‌دهد.
• انتخاب سطح دیگر، بازنویسی نشست را فورا از طریق sessions.patch می‌نویسد؛ منتظر ارسال بعدی نمی‌ماند و یک بازنویسی یک‌بارهٔ thinkingOnce نیست.
• گزینهٔ اول همیشه Default (<resolved level>) است، که در آن پیش‌فرض حل‌شده از نمایهٔ تفکر ارائه‌دهندهٔ مدل نشست فعال به‌همراه همان منطق جایگزینی می‌آید که /status و session_status استفاده می‌کنند.
• انتخابگر از thinkingLevels برگردانده‌شده توسط ردیف/پیش‌فرض‌های نشست gateway استفاده می‌کند، و thinkingOptions به‌عنوان فهرست برچسب قدیمی نگه داشته می‌شود. UI مرورگر فهرست 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/chat همان شناسه‌ها و برچسب‌های پروفایلی را رندر کنند که اعتبارسنجی زمان اجرا از آن‌ها استفاده می‌کند.