سطوح تفکر

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

• دستور درون‌خطی در هر بدنه ورودی: /t <level>،‏ /think:<level> یا /thinking <level>.
• سطح‌ها (نام‌های مستعار): off | minimal | low | medium | high | xhigh | adaptive | max | ultra که تقریباً از نردبان واژه‌های جادویی کلاسیک Anthropic یعنی "فکر کن" < "سخت فکر کن" < "سخت‌تر فکر کن" < "فوق‌العاده فکر کن" پیروی می‌کنند:
  • 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 خود نگاشت می‌کند)
  • ultra → حداکثر استدلال ارائه‌دهنده، به‌علاوه هماهنگ‌سازی پیش‌دستانه زیرعامل‌ها، هنگامی که مدل/زمان‌اجرای انتخاب‌شده از آن پشتیبانی کند
  • x-high،‏ x_high،‏ extra-high،‏ extra high و extra_high به xhigh نگاشت می‌شوند.
  • highest به high نگاشت می‌شود.
• نکات ارائه‌دهنده:
  • منوها و انتخابگرهای تفکر بر اساس پروفایل ارائه‌دهنده عمل می‌کنند. Pluginهای ارائه‌دهنده مجموعه دقیق سطح‌ها را برای مدل انتخاب‌شده، از جمله برچسب‌هایی مانند on دودویی، اعلام می‌کنند.
  • adaptive،‏ xhigh،‏ max و ultra فقط برای پروفایل‌های ارائه‌دهنده/مدل/زمان‌اجرایی که از آن‌ها پشتیبانی می‌کنند نمایش داده می‌شوند. دستورهای تایپ‌شده برای سطح‌های پشتیبانی‌نشده رد می‌شوند و گزینه‌های معتبر آن مدل نمایش داده می‌شوند.
  • سطح‌های پشتیبانی‌نشده ذخیره‌شده بر اساس رتبه پروفایل ارائه‌دهنده دوباره نگاشت می‌شوند. در مدل‌های غیرتطبیقی، 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 نگاشت می‌شوند، درحالی‌که سطح‌های پایین‌تر غیر از off به high نگاشت می‌شوند.
  • مدل‌های DeepSeek V4 که از طریق OpenRouter مسیریابی می‌شوند، /think xhigh را ارائه می‌دهند و به‌جای reasoning_effort سطح‌بالای بومی DeepSeek، مقادیر reasoning.effort پشتیبانی‌شده توسط OpenRouter را ارسال می‌کنند. سطح‌های پایین‌تر غیر از off به high نگاشت می‌شوند و بازنویسی‌های ذخیره‌شده 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 به‌جای ارسال مقداری پشتیبانی‌نشده، محموله استدلال غیرفعال را حذف می‌کند.
  • GPT-5.6 Sol و Terra از طریق زمان‌اجرای Codex،‏ /think ultra بومی را ارائه می‌دهند. GPT-5.6 Luna سطح‌ها را تا max ارائه می‌دهد، زیرا فهرست Codex آن Ultra را اعلام نمی‌کند.
  • زمان‌اجرای تعبیه‌شده OpenClaw،‏ /think ultra منطقی را برای GPT-5.6 Sol،‏ Terra و Luna ارائه می‌دهد. این زمان‌اجرا حداکثر میزان تلاش ارائه‌دهنده را ارسال می‌کند و راهنمای هماهنگ‌سازی پیش‌دستانه زیرعامل‌ها را در محدوده اجرا می‌افزاید.
  • ورودی‌های سفارشی فهرست سازگار با 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 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 مطابق الزام Moonshot فیلد خروجی thinking را حذف می‌کند. دیگر مدل‌های 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 یک بازنویسی خاموش صریح ذخیره می‌کند. تا زمانی که بازنویسی نشست را تغییر دهید یا پاک کنید، تفکر را غیرفعال نگه می‌دارد.
• پاسخ تأیید ارسال می‌شود (سطح تفکر روی high تنظیم شد. / تفکر غیرفعال شد.). اگر سطح نامعتبر باشد (برای نمونه /thinking big)، فرمان همراه با راهنمایی رد می‌شود و وضعیت نشست بدون تغییر باقی می‌ماند.
• برای مشاهده سطح فعلی تفکر، /think (یا /think:) را بدون آرگومان ارسال کنید.

اعمال توسط عامل

• OpenClaw تعبیه‌شده: سطح تعیین‌شده به زمان‌اجرای درون‌پردازشی عامل OpenClaw ارسال می‌شود.
• بخش پشتی Claude CLI: هنگام استفاده از claude-cli، سطح‌های مشخص غیر از off با --effort به Claude Code ارسال می‌شوند؛ adaptive پرچم‌های میزان تلاش پیکربندی‌شده را حذف می‌کند و میزان تلاش مؤثر را به محیط، تنظیمات و پیش‌فرض‌های مدل Claude Code واگذار می‌کند. بخش‌های پشتی CLI را ببینید.

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

• سطح‌ها: auto|on|off|default.
• پیامی که فقط شامل دستور است، بازنویسی حالت سریع نشست را تغییر می‌دهد و پاسخ حالت سریع روی auto تنظیم شد.،‏ حالت سریع فعال شد. یا حالت سریع غیرفعال شد. را برمی‌گرداند. برای پاک‌کردن بازنویسی نشست و به‌ارث‌بردن پیش‌فرض پیکربندی‌شده از /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 حالت نشست/پیکربندی را روی خودکار نگه می‌دارد، اما هر فراخوانی جدید مدل را به‌طور مستقل تعیین می‌کند. فراخوانی‌هایی که پیش از آستانه خودکار آغاز می‌شوند، حالت سریع را فعال دارند؛ فراخوانی‌های بعدیِ تلاش مجدد، جایگزین، نتیجه ابزار یا ادامه با حالت سریع غیرفعال آغاز می‌شوند. مقدار پیش‌فرض آستانه ۶۰ ثانیه است؛ برای تغییر آن، agents.defaults.models["<provider>/<model>"].params.fastAutoOnSeconds را روی مدل فعال تنظیم کنید.
• برای openai/*، حالت سریع با ارسال service_tier=priority در درخواست‌های پشتیبانی‌شده Responses به پردازش اولویت‌دار OpenAI نگاشت می‌شود.
• برای مدل‌های openai/* / openai-codex/* مبتنی بر Codex، حالت سریع همان پرچم service_tier=priority را در Codex Responses ارسال می‌کند. نوبت‌های بومی کارساز برنامه Codex فقط در turn/start یا آغاز/ازسرگیری رشته، سطح را دریافت می‌کنند؛ بنابراین auto نمی‌تواند سطح یک نوبت کارساز برنامه را که از قبل در حال اجراست تغییر دهد و روی نوبت بعدی مدلی که OpenClaw آغاز می‌کند اعمال می‌شود.
• برای درخواست‌های عمومی مستقیم 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 همچنان برای URLهای پایه پراکسی غیر Anthropic از تزریق سطح سرویس Anthropic صرف‌نظر می‌کند.
• وقتی حالت سریع فعال باشد، /status مقدار Fast و وقتی حالت پیکربندی‌شده خودکار باشد، مقدار Fast:auto را نشان می‌دهد.

دستورهای گزارش تفصیلی (/verbose یا /v)

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

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

• سطح‌ها: on | off (پیش‌فرض).
• پیامی که فقط شامل دستور است، خروجی ردیابی Plugin نشست را تغییر می‌دهد و پاسخ ردیابی Plugin فعال شد. / ردیابی Plugin غیرفعال شد. را برمی‌گرداند.
• دستور درون‌خطی فقط همان پیام را تحت تأثیر قرار می‌دهد؛ در غیر این صورت، پیش‌فرض‌های نشست/سراسری اعمال می‌شوند.
• برای مشاهده سطح فعلی ردیابی، /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 را تنظیم کنید.

رابط کاربری گفت‌وگوی وب

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