---
read_when:
    - การปรับการแยกวิเคราะห์หรือค่าเริ่มต้นของไดเรกทีฟ thinking, fast-mode หรือ verbose
summary: ไวยากรณ์คำสั่งสำหรับ /think, /fast, /verbose, /trace และการแสดงเหตุผล
title: ระดับการคิด
x-i18n:
    generated_at: "2026-07-19T08:04:59Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: bb2a4ed4179e115c184d89ecf3a0a22379d3d0dad4a4838d9c5db851e1334728
    source_path: tools/thinking.md
    workflow: 16
---

## หน้าที่การทำงาน

- ไดเรกทีฟแบบอินไลน์ในเนื้อหาขาเข้าใดๆ: `/t <level>`, `/think:<level>` หรือ `/thinking <level>`
- ระดับ (นามแฝง): `off | minimal | low | medium | high | xhigh | adaptive | max | ultra` ซึ่งใกล้เคียงกับลำดับคำวิเศษแบบคลาสสิกของ Anthropic คือ "think" < "think hard" < "think harder" < "ultrathink":
  - 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` แบบเนทีฟสูงสุด)
  - ultra → การให้เหตุผลสูงสุดของผู้ให้บริการ พร้อมการประสานงาน sub-agent เชิงรุกเมื่อโมเดล/รันไทม์ที่เลือกสนับสนุน
  - `x-high`, `x_high`, `extra-high`, `extra high` และ `extra_high` จะแมปไปยัง `xhigh`
  - `highest` จะแมปไปยัง `high`
- หมายเหตุสำหรับผู้ให้บริการ:
  - เมนูและตัวเลือกการคิดขับเคลื่อนโดยโปรไฟล์ผู้ให้บริการ Plugin ของผู้ให้บริการจะประกาศชุดระดับที่แน่นอนสำหรับโมเดลที่เลือก รวมถึงป้ายกำกับ เช่น ค่าไบนารี `on`
  - `adaptive`, `xhigh`, `max` และ `ultra` จะแสดงเฉพาะในโปรไฟล์ผู้ให้บริการ/โมเดล/รันไทม์ที่รองรับเท่านั้น ไดเรกทีฟที่ระบุชนิดสำหรับระดับที่ไม่รองรับจะถูกปฏิเสธพร้อมตัวเลือกที่ใช้ได้สำหรับโมเดลนั้น
  - ระดับที่ไม่รองรับซึ่งจัดเก็บไว้เดิมจะถูกแมปใหม่ตามลำดับขั้นของโปรไฟล์ผู้ให้บริการ `adaptive` จะย้อนกลับไปใช้ `medium` บนโมเดลที่ไม่รองรับ adaptive ส่วน `xhigh` และ `max` จะย้อนกลับไปใช้ระดับที่รองรับสูงสุดซึ่งไม่ใช่ off สำหรับโมเดลที่เลือก
  - โมเดล Anthropic Claude 4.6 ใช้ค่าเริ่มต้นเป็น `adaptive` เมื่อไม่ได้กำหนดระดับการคิดอย่างชัดเจน
  - Anthropic Claude Opus 4.8 และ Opus 4.7 จะปิดการคิดไว้ เว้นแต่จะกำหนดระดับการคิดอย่างชัดเจน ค่าเริ่มต้นของระดับความพยายามที่ผู้ให้บริการกำหนดสำหรับ Opus 4.8 คือ `high` หลังจากเปิดใช้การคิดแบบ adaptive
  - Anthropic Claude Opus 4.7+ จะแมป `/think xhigh` ไปยังการคิดแบบ adaptive พร้อม `output_config.effort: "xhigh"` เนื่องจาก `/think` เป็นไดเรกทีฟการคิด และ `xhigh` เป็นการตั้งค่าระดับความพยายามของ Opus
  - Anthropic Claude Opus 4.7+ ยังมี `/think max` ซึ่งจะแมปไปยังเส้นทางระดับความพยายามสูงสุดที่ผู้ให้บริการกำหนดเช่นเดียวกัน
  - โมเดล DeepSeek V4 ที่เชื่อมต่อโดยตรงมี `/think xhigh|max`; ทั้งสองจะแมปไปยัง DeepSeek `reasoning_effort: "max"` ขณะที่ระดับต่ำกว่าซึ่งไม่ใช่ off จะแมปไปยัง `high`
  - โมเดล DeepSeek V4 ที่กำหนดเส้นทางผ่าน OpenRouter มี `/think xhigh` และส่งค่า `reasoning.effort` ที่ OpenRouter รองรับแทน `reasoning_effort` ระดับบนสุดแบบเนทีฟของ DeepSeek ระดับต่ำกว่าซึ่งไม่ใช่ 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 มี `/think ultra` แบบเนทีฟผ่านรันไทม์ Codex ส่วน GPT-5.6 Luna มีระดับต่างๆ ผ่าน `max` เนื่องจากแค็ตตาล็อก Codex ของโมเดลนี้ไม่ได้ประกาศ Ultra
  - รันไทม์ OpenClaw แบบฝังตัวมี `/think ultra` เชิงตรรกะสำหรับ GPT-5.6 Sol, Terra และ Luna โดยจะส่งระดับความพยายามสูงสุดของผู้ให้บริการและเพิ่มแนวทางการประสานงาน sub-agent เชิงรุกที่มีขอบเขตเฉพาะการรัน
  - รายการแค็ตตาล็อกแบบกำหนดเองที่เข้ากันได้กับ OpenAI สามารถเลือกใช้ `/think xhigh` ได้โดยตั้งค่า `models.providers.<provider>.models[].compat.supportedReasoningEfforts` ให้รวม `"xhigh"` การดำเนินการนี้ใช้เมทาดาทาความเข้ากันได้ชุดเดียวกับที่แมปเพย์โหลดระดับความพยายามในการให้เหตุผลขาออกของ OpenAI เพื่อให้เมนู การตรวจสอบเซสชัน agent 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 ไว้บนเส้นทางการคิดแบบละค่า/adaptive ของผู้ให้บริการ
  - Z.AI (`zai/*`) เป็นแบบไบนารี (`on`/`off`) สำหรับโมเดล GLM ส่วนใหญ่ โดย GLM-5.2 เป็นข้อยกเว้น: มี `/think off|low|high|max`, แมป `low` และ `high` ไปยัง Z.AI `reasoning_effort: "high"` และแมป `max` ไปยัง `reasoning_effort: "max"`
  - Moonshot API Kimi K3 (`moonshot/kimi-k3`) จะคิดที่ `max` เสมอ ส่ง `reasoning_effort: "max"` ละฟิลด์ `thinking` ของ K2 และการแทนที่การสุ่มตัวอย่างแบบคงที่ และคงตัวเลือกเครื่องมือที่ K3 รองรับไว้ Kimi Code K3 (`kimi/k3` และ `kimi/k3[1m]`) มี `/think off|max`: off จะส่ง `thinking.type: "disabled"` ส่วน max จะส่งการคิดแบบ adaptive พร้อมระดับความพยายามสูงสุด การอ้างอิง Kimi Code ปัจจุบันยังรวม `kimi/kimi-for-coding` และ `kimi/kimi-for-coding-highspeed` ด้วย Kimi K2.7 Code (`moonshot/kimi-k2.7-code` และ `moonshot/kimi-k2.7-code-highspeed`) จะคิดเสมอ มีเฉพาะ `on` และละทั้ง `thinking` และ `reasoning_effort` ขาออก โมเดล `moonshot/*` อื่นๆ จะแมป `/think off` ไปยัง `thinking: { type: "disabled" }` และระดับใดๆ ที่ไม่ใช่ `off` ไปยัง `thinking: { type: "enabled" }` เมื่อเปิดใช้การคิดของ K2 Moonshot จะยอมรับเฉพาะ `tool_choice` `auto|none`; OpenClaw จะปรับค่าที่เข้ากันไม่ได้ให้เป็น `auto`

## ลำดับการกำหนดค่า

1. ไดเรกทีฟแบบอินไลน์บนข้อความ (ใช้กับข้อความนั้นเท่านั้น)
2. การแทนที่ระดับเซสชัน (ตั้งค่าโดยส่งข้อความที่มีเฉพาะไดเรกทีฟ)
3. ค่าเริ่มต้นราย agent (`agents.list[].thinkingDefault` ในการกำหนดค่า)
4. ค่าเริ่มต้นส่วนกลาง (`agents.defaults.thinkingDefault` ในการกำหนดค่า)
5. ค่าทดแทน: ค่าเริ่มต้นที่ผู้ให้บริการประกาศเมื่อมี มิฉะนั้นโมเดลที่รองรับการให้เหตุผลจะใช้ `medium` หรือระดับที่รองรับซึ่งไม่ใช่ `off` ที่ใกล้เคียงที่สุดสำหรับโมเดลนั้น และโมเดลที่ไม่รองรับการให้เหตุผลจะคงเป็น `off`

## การตั้งค่าเริ่มต้นของเซสชัน

- ส่งข้อความที่มี **เฉพาะ** ไดเรกทีฟ (อนุญาตให้มีช่องว่าง) เช่น `/think:medium` หรือ `/t high`
- ค่านี้จะคงอยู่สำหรับเซสชันปัจจุบัน (ค่าเริ่มต้นคือแยกตามผู้ส่ง) ใช้ `/think default` เพื่อล้างการแทนที่ระดับเซสชันและสืบทอดค่าเริ่มต้นที่กำหนดค่าไว้/ของผู้ให้บริการ โดยมีนามแฝง ได้แก่ `inherit`, `clear`, `reset` และ `unpin`
- `/think off` จะจัดเก็บการแทนที่เป็น off อย่างชัดเจน ซึ่งจะปิดการคิดจนกว่าจะเปลี่ยนหรือล้างการแทนที่ระดับเซสชัน
- ระบบจะส่งการตอบกลับยืนยัน (`Thinking level set to high.` / `Thinking disabled.`) หากระดับไม่ถูกต้อง (เช่น `/thinking big`) คำสั่งจะถูกปฏิเสธพร้อมคำแนะนำ และสถานะเซสชันจะไม่เปลี่ยนแปลง
- ส่ง `/think` (หรือ `/think:`) โดยไม่มีอาร์กิวเมนต์เพื่อดูระดับการคิดปัจจุบัน

## การนำไปใช้โดย agent

- **OpenClaw แบบฝังตัว**: ระดับที่กำหนดแล้วจะถูกส่งไปยังรันไทม์ agent ของ OpenClaw ภายในโพรเซส
- **แบ็กเอนด์ Claude CLI**: ระดับที่เป็นรูปธรรมและไม่ใช่ off จะถูกส่งไปยัง Claude Code เป็น `--effort` เมื่อใช้ `claude-cli`; `adaptive` จะลบแฟล็กระดับความพยายามที่กำหนดค่าไว้ และมอบหมายระดับความพยายามที่มีผลให้กับสภาพแวดล้อม การตั้งค่า และค่าเริ่มต้นของโมเดลใน Claude Code ดู[แบ็กเอนด์ CLI](/th/gateway/cli-backends)

## โหมดเร็ว (/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. ค่าเริ่มต้นราย agent (`agents.list[].fastModeDefault`)
  4. การกำหนดค่ารายโมเดล: `agents.defaults.models["<provider>/<model>"].params.fastMode`
  5. ค่าทดแทน: `off`
- `auto` จะคงโหมดเซสชัน/การกำหนดค่าไว้เป็น auto แต่จะกำหนดแต่ละการเรียกโมเดลใหม่อย่างอิสระ การเรียกที่เริ่มก่อนเวลาตัดของ auto จะเปิดใช้โหมดเร็ว ส่วนการเรียกซ้ำ การใช้ค่าทดแทน ผลลัพธ์เครื่องมือ หรือการเรียกต่อเนื่องที่เกิดภายหลังจะเริ่มโดยปิดโหมดเร็ว เวลาตัดมีค่าเริ่มต้นเป็น 60 วินาที; ตั้งค่า `agents.defaults.models["<provider>/<model>"].params.fastAutoOnSeconds` บนโมเดลที่ใช้งานอยู่เพื่อเปลี่ยนค่า
- สำหรับ `openai/*` โหมดเร็วจะแมปไปยังการประมวลผลแบบมีลำดับความสำคัญของ OpenAI โดยส่ง `service_tier=priority` ในคำขอ Responses ที่รองรับ
- สำหรับโมเดล `openai/*` / `openai-codex/*` ที่ใช้ Codex เป็นแบ็กเอนด์ โหมดเร็วจะส่งแฟล็ก `service_tier=priority` เดียวกันใน Codex Responses เทิร์นของ Codex app-server แบบเนทีฟจะได้รับระดับบริการเฉพาะใน `turn/start` หรือเมื่อเริ่ม/ดำเนินเธรดต่อ ดังนั้น `auto` จึงไม่สามารถเปลี่ยนระดับบริการของเทิร์น app-server ที่กำลังทำงานอยู่ได้ แต่จะมีผลกับเทิร์นโมเดลถัดไปที่ 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 ยังคงข้ามการแทรกระดับบริการ Anthropic สำหรับ URL ฐานของพร็อกซีที่ไม่ใช่ Anthropic
- `/status` จะแสดง `Fast` เมื่อเปิดใช้โหมดเร็ว และแสดง `Fast:auto` เมื่อโหมดที่กำหนดค่าไว้เป็น 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` เอาต์พุตของเครื่องมือจะถูกส่งต่อหลังจากทำงานเสร็จด้วย (เป็นกล่องข้อความแยกและตัดให้มีความยาวที่ปลอดภัย) หากสลับ `/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 จะลบแท็กเปิดที่มีรูปแบบไม่ถูกต้องและส่งข้อความที่เหลือ

## ที่เกี่ยวข้อง

- เอกสารโหมดยกระดับอยู่ที่ [โหมดยกระดับ](/th/tools/elevated)

## 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` ของแต่ละเอเจนต์

## UI เว็บแชต

- เมื่อโหลดหน้า ตัวเลือกระดับการคิดของเว็บแชตจะแสดงระดับที่จัดเก็บไว้ของเซสชันจากที่เก็บ/การกำหนดค่าเซสชันขาเข้า
- การเลือกระดับอื่นจะเขียนค่าที่เขียนทับของเซสชันทันทีผ่าน `sessions.patch`; โดยไม่รอการส่งครั้งถัดไปและไม่ใช่ค่าที่เขียนทับ `thinkingOnce` แบบใช้ครั้งเดียว
- การส่งขณะที่การเปลี่ยนแปลงตัวเลือกโมเดล เหตุผล หรือความเร็วยังอยู่ระหว่างนำไปใช้ จะรอแพตช์ของตัวเลือกที่ค้างอยู่ทั้งหมด หากการเปลี่ยนแปลงล้มเหลว ข้อความจะยังไม่ถูกส่งเพื่อให้ตรวจสอบ
- ตัวเลือกแรกเป็นตัวเลือกล้างค่าที่เขียนทับเสมอ โดยจะแสดง `Inherited: <resolved level>` รวมถึง `Inherited: Off` เมื่อการคิดที่สืบทอดมาถูกปิดใช้
- ตัวเลือกที่เลือกอย่างชัดเจนจะใช้ป้ายกำกับระดับโดยตรง พร้อมคงป้ายกำกับผู้ให้บริการไว้เมื่อมี (เช่น `Maximum` สำหรับตัวเลือก `max` ที่มีป้ายกำกับผู้ให้บริการ)
- ตัวเลือกนี้ใช้ `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` หรือ `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/แชตแสดงรหัสและป้ายกำกับโปรไฟล์เดียวกับที่การตรวจสอบรันไทม์ใช้
