chore(i18n): refresh th translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
c1ad4f9999
commit
d72979a74a
154
docs/th/ci.md
154
docs/th/ci.md
@ -1,106 +1,128 @@
|
||||
---
|
||||
read_when:
|
||||
- คุณต้องเข้าใจว่าทำไมงาน CI จึงรันหรือไม่รัน
|
||||
- คุณต้องเข้าใจว่าทำไมงาน CI จึงทำงานหรือไม่ได้ทำงาน
|
||||
- คุณกำลังดีบักการตรวจสอบ GitHub Actions ที่ล้มเหลว
|
||||
summary: กราฟงาน CI, เกตขอบเขตการเปลี่ยนแปลง และคำสั่งในเครื่องที่เทียบเท่ากัน
|
||||
summary: กราฟงาน CI, เกตตามขอบเขต และคำสั่งเทียบเท่าบนเครื่อง локալ
|
||||
title: ไปป์ไลน์ CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T05:28:50Z"
|
||||
generated_at: "2026-04-23T13:58:19Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 5c89c66204b203a39435cfc19de7b437867f2792bbfa2c3948371abde9f80e11
|
||||
source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# ไปป์ไลน์ CI
|
||||
|
||||
CI จะรันในทุกการ push ไปยัง `main` และทุก pull request โดยใช้การกำหนดขอบเขตอัจฉริยะเพื่อข้ามงานที่มีค่าใช้จ่ายสูงเมื่อมีการเปลี่ยนแปลงเฉพาะส่วนที่ไม่เกี่ยวข้อง
|
||||
CI จะทำงานทุกครั้งที่มีการ push ไปยัง `main` และทุก pull request โดยใช้การกำหนดขอบเขตอัจฉริยะเพื่อข้ามงานที่มีค่าใช้จ่ายสูงเมื่อมีการเปลี่ยนแปลงเฉพาะส่วนที่ไม่เกี่ยวข้อง
|
||||
|
||||
QA Lab มี lane ของ CI โดยเฉพาะแยกจากเวิร์กโฟลว์หลักที่กำหนดขอบเขตแบบอัจฉริยะ เวิร์กโฟลว์
|
||||
`Parity gate` จะรันบนการเปลี่ยนแปลง PR ที่ตรงเงื่อนไขและการสั่งรันด้วยตนเอง โดยจะ
|
||||
build runtime QA ส่วนตัวและเปรียบเทียบแพ็ก agentic จำลองของ GPT-5.4 และ Opus 4.6
|
||||
เวิร์กโฟลว์ `QA-Lab - All Lanes` จะรันทุกคืนบน `main` และเมื่อสั่งรันด้วยตนเอง โดยจะ
|
||||
แตกงานออกเป็น mock parity gate, live Matrix lane และ live Telegram lane แบบขนาน
|
||||
งานแบบ live ใช้ environment `qa-live-shared` และ Telegram lane ใช้ Convex lease
|
||||
`OpenClaw Release Checks` ยังรัน lane ของ QA Lab ชุดเดียวกันก่อนอนุมัติ release
|
||||
QA Lab มีเลน CI เฉพาะของตัวเองที่แยกออกจากเวิร์กโฟลว์หลักแบบกำหนดขอบเขตอัจฉริยะ
|
||||
เวิร์กโฟลว์ `Parity gate` จะทำงานเมื่อมีการเปลี่ยนแปลงใน PR ที่ตรงเงื่อนไขและเมื่อสั่งแบบ manual dispatch; เวิร์กโฟลว์นี้จะสร้างรันไทม์ QA ส่วนตัวและเปรียบเทียบแพ็ก agentic แบบ mock ของ GPT-5.4 และ Opus 4.6
|
||||
เวิร์กโฟลว์ `QA-Lab - All Lanes` จะทำงานทุกคืนบน `main` และเมื่อสั่งแบบ manual dispatch; โดยจะกระจาย mock parity gate, เลน Matrix แบบ live และเลน Telegram แบบ live ออกเป็นงานขนานกัน
|
||||
งานแบบ live ใช้ environment `qa-live-shared` และเลน Telegram ใช้ Convex leases
|
||||
`OpenClaw Release Checks` ก็จะรันเลน QA Lab ชุดเดียวกันนี้ก่อนอนุมัติรีลีสด้วย
|
||||
|
||||
## ภาพรวมของงาน
|
||||
|
||||
| งาน | วัตถุประสงค์ | รันเมื่อใด |
|
||||
| -------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------ |
|
||||
| `preflight` | ตรวจหาการเปลี่ยนแปลงเฉพาะ docs, ขอบเขตที่เปลี่ยน, extensions ที่เปลี่ยน, และ build CI manifest | เสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-scm-fast` | ตรวจจับ private key และ audit workflow ผ่าน `zizmor` | เสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-dependency-audit` | audit lockfile สำหรับ production ที่ไม่ต้องใช้ dependency เทียบกับ advisory ของ npm | เสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-fast` | ตัวรวมที่จำเป็นสำหรับงาน security แบบเร็ว | เสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `build-artifacts` | build `dist/`, Control UI, การตรวจสอบ built artifact และ artifact ใช้ซ้ำสำหรับงานปลายทาง | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-fast-core` | lane ความถูกต้องแบบเร็วบน Linux เช่น bundled/plugin-contract/protocol checks | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| งาน | วัตถุประสงค์ | ช่วงเวลาที่ทำงาน |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- |
|
||||
| `preflight` | ตรวจจับการเปลี่ยนแปลงเฉพาะ docs, ขอบเขตที่เปลี่ยน, extensions ที่เปลี่ยน และสร้าง CI manifest | ทำงานเสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-scm-fast` | ตรวจจับ private key และตรวจสอบ workflow ผ่าน `zizmor` | ทำงานเสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-dependency-audit` | ตรวจสอบ production lockfile โดยไม่พึ่ง dependency เทียบกับ npm advisories | ทำงานเสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `security-fast` | งานรวมที่จำเป็นสำหรับงาน security แบบเร็ว | ทำงานเสมอบน push และ PR ที่ไม่ใช่ draft |
|
||||
| `build-artifacts` | สร้าง `dist/`, Control UI, ตรวจสอบ built artifacts และสร้าง artifacts ที่ใช้ซ้ำได้ปลายทาง | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-fast-core` | เลนตรวจความถูกต้องบน Linux แบบเร็ว เช่น bundled/plugin-contract/protocol checks | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-fast-contracts-channels` | ตรวจสอบ channel contract แบบแบ่ง shard พร้อมผล aggregate check ที่คงที่ | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-node-extensions` | shard การทดสอบ bundled plugin แบบเต็มทั้งชุด extension | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-node-core-test` | shard การทดสอบ core Node โดยไม่รวม lane ของ channel, bundled, contract และ extension | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `extension-fast` | การทดสอบแบบเจาะจงสำหรับเฉพาะ bundled plugin ที่เปลี่ยน | Pull request ที่มีการเปลี่ยนแปลง extension |
|
||||
| `check` | ตัวเทียบเท่า local gate หลักแบบแบ่ง shard: prod types, lint, guards, test types และ strict smoke | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `check-additional` | สถาปัตยกรรม, boundary, guards ของ extension surface, package-boundary และ shard ของ gateway-watch | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `build-smoke` | การทดสอบ smoke ของ built CLI และ smoke ด้านหน่วยความจำขณะเริ่มต้น | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks` | ตัวตรวจสอบสำหรับ channel test ของ built artifact พร้อม compatibility ของ Node 22 แบบ push-only | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `check-docs` | ตรวจรูปแบบเอกสาร lint และลิงก์เสีย | เมื่อ docs เปลี่ยน |
|
||||
| `skills-python` | Ruff + pytest สำหรับ Skills ที่ใช้ Python | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Python skill |
|
||||
| `checks-windows` | lane การทดสอบเฉพาะ Windows | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Windows |
|
||||
| `macos-node` | lane ทดสอบ TypeScript บน macOS โดยใช้ built artifact ที่ใช้ร่วมกัน | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS |
|
||||
| `macos-swift` | Swift lint, build และทดสอบสำหรับแอป macOS | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS |
|
||||
| `android` | Android unit tests สำหรับทั้งสอง flavor พร้อม build debug APK หนึ่งชุด | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Android |
|
||||
| `checks-node-extensions` | ทดสอบ bundled plugin แบบแบ่ง shard ครบทั้งชุด extension | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks-node-core-test` | ชุดทดสอบ Node ของ core แบบแบ่ง shard โดยไม่รวมเลน channel, bundled, contract และ extension | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `extension-fast` | ทดสอบแบบเจาะจงเฉพาะ bundled plugins ที่เปลี่ยน | Pull requests ที่มีการเปลี่ยน extension |
|
||||
| `check` | สิ่งเทียบเท่า local gate หลักแบบแบ่ง shard: prod types, lint, guards, test types และ strict smoke | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `check-additional` | architecture, boundary, guards ของ extension-surface, package-boundary และ gateway-watch shards | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `build-smoke` | ทดสอบ built-CLI smoke และ startup-memory smoke | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `checks` | ตัวตรวจสอบสำหรับ built-artifact channel tests พร้อมความเข้ากันได้กับ Node 22 ที่รันเฉพาะ push | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node |
|
||||
| `check-docs` | ตรวจสอบการจัดรูปแบบ docs, lint และ broken links | เมื่อ docs มีการเปลี่ยนแปลง |
|
||||
| `skills-python` | Ruff + pytest สำหรับ Skills ที่รองรับด้วย Python | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Python skill |
|
||||
| `checks-windows` | เลนทดสอบเฉพาะ Windows | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Windows |
|
||||
| `macos-node` | เลนทดสอบ TypeScript บน macOS โดยใช้ built artifacts ที่แชร์ร่วมกัน | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS |
|
||||
| `macos-swift` | lint, build และทดสอบ Swift สำหรับแอป macOS | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS |
|
||||
| `android` | ทดสอบยูนิต Android สำหรับทั้งสอง flavor พร้อม build debug APK หนึ่งรายการ | เมื่อมีการเปลี่ยนแปลงที่เกี่ยวข้องกับ Android |
|
||||
|
||||
## ลำดับการ fail-fast
|
||||
## ลำดับการหยุดเมื่อพบความล้มเหลวอย่างรวดเร็ว
|
||||
|
||||
งานต่าง ๆ ถูกจัดลำดับเพื่อให้การตรวจสอบที่ต้นทุนต่ำล้มเหลวก่อนที่งานราคาแพงจะเริ่มรัน:
|
||||
งานต่าง ๆ ถูกจัดลำดับให้การตรวจสอบที่มีต้นทุนต่ำล้มเหลวก่อนที่งานราคาแพงจะเริ่มทำงาน:
|
||||
|
||||
1. `preflight` จะตัดสินใจว่า lane ใดควรมีอยู่ตั้งแต่แรก โดยตรรกะ `docs-scope` และ `changed-scope` เป็น step ภายในงานนี้ ไม่ใช่งานแยก
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` และ `skills-python` จะล้มเหลวได้อย่างรวดเร็วโดยไม่ต้องรอ artifact หนักและงานเมทริกซ์ตามแพลตฟอร์ม
|
||||
3. `build-artifacts` ทำงานทับซ้อนกับ lane Linux แบบเร็ว เพื่อให้ consumer ปลายทางเริ่มได้ทันทีเมื่อ shared build พร้อม
|
||||
4. หลังจากนั้น lane ที่หนักกว่าตามแพลตฟอร์มและ runtime จะแตกออก: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` เฉพาะ PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` และ `android`
|
||||
1. `preflight` เป็นตัวตัดสินว่าจะมีเลนใดอยู่บ้าง `docs-scope` และตรรกะ `changed-scope` เป็นขั้นตอนภายในงานนี้ ไม่ใช่งานแยกต่างหาก
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` และ `skills-python` จะล้มเหลวได้อย่างรวดเร็วโดยไม่ต้องรอ artifact และงานเมทริกซ์ของแพลตฟอร์มที่หนักกว่า
|
||||
3. `build-artifacts` จะทำงานซ้อนกับเลน Linux แบบเร็ว เพื่อให้ downstream consumers เริ่มได้ทันทีเมื่อ shared build พร้อม
|
||||
4. หลังจากนั้นเลนแพลตฟอร์มและรันไทม์ที่หนักกว่าจะกระจายออก: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` ที่รันเฉพาะ PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` และ `android`
|
||||
|
||||
ตรรกะขอบเขตอยู่ใน `scripts/ci-changed-scope.mjs` และมี unit test ครอบคลุมใน `src/scripts/ci-changed-scope.test.ts`
|
||||
การแก้ไข workflow ของ CI จะตรวจสอบกราฟ Node CI และ workflow linting แต่จะไม่บังคับให้เกิด build native ของ Windows, Android หรือ macOS ด้วยตัวเอง; lane ของแพลตฟอร์มเหล่านั้นยังคงผูกกับการเปลี่ยนแปลงในซอร์สของแพลตฟอร์มนั้น
|
||||
การตรวจสอบ Node บน Windows ถูกกำหนดขอบเขตไปยัง wrapper เฉพาะของ Windows สำหรับ process/path, ตัวช่วย npm/pnpm/UI runner, config ของ package manager และพื้นผิว workflow ของ CI ที่รัน lane นั้น; การเปลี่ยนแปลงซอร์ส, plugin, install-smoke และ test-only ที่ไม่เกี่ยวข้องจะยังคงอยู่ใน lane Node บน Linux เพื่อไม่ให้จอง worker Windows 16-vCPU สำหรับการครอบคลุมที่ได้ถูกทดสอบแล้วใน shard ปกติ
|
||||
เวิร์กโฟลว์ `install-smoke` แยกต่างหากนำสคริปต์กำหนดขอบเขตเดียวกันมาใช้ผ่านงาน `preflight` ของตัวเอง มันคำนวณ `run_install_smoke` จากสัญญาณ changed-smoke ที่แคบกว่า ดังนั้น Docker/install smoke จะรันสำหรับการเปลี่ยนแปลงด้าน install, packaging, container, การเปลี่ยนแปลง production ของ bundled extension และพื้นผิว core ของ plugin/channel/gateway/Plugin SDK ที่งาน Docker smoke ใช้ การแก้ไขเฉพาะ test และ docs จะไม่จอง worker ของ Docker การทดสอบ package แบบ QR จะบังคับให้เลเยอร์ Docker `pnpm install` รันใหม่ ขณะยังคงรักษาแคช BuildKit pnpm store ไว้ จึงยังได้ทดสอบการติดตั้งโดยไม่ต้องดาวน์โหลด dependency ใหม่ทุกครั้ง gateway-network e2e ใช้อิมเมจ runtime ที่ build ไว้ก่อนหน้านี้ในงานเดียวกันซ้ำ จึงเพิ่มการครอบคลุม WebSocket ระหว่างคอนเทนเนอร์จริงโดยไม่ต้องเพิ่ม Docker build อีกครั้ง `test:docker:all` ในเครื่องจะ prebuild built-app image ที่ใช้ร่วมกันจาก `scripts/e2e/Dockerfile` เพียงหนึ่งชุด และนำกลับมาใช้ซ้ำกับตัวรัน E2E container smoke โดยเวิร์กโฟลว์ live/E2E ที่ใช้ซ้ำได้ก็สะท้อนรูปแบบเดียวกัน โดย build และ push Docker E2E image ที่ติดแท็ก SHA ไปยัง GHCR หนึ่งครั้งก่อน Docker matrix จากนั้นรันเมทริกซ์ด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1` การทดสอบ Docker แบบ QR และ installer ยังคงใช้ Dockerfile ที่เน้นด้าน install ของตนเอง งาน `docker-e2e-fast` แยกต่างหากจะรันโปรไฟล์ Docker ของ bundled plugin แบบมีขอบเขต ภายใต้ command timeout 120 วินาที: การซ่อมแซม dependency ของ setup-entry และการแยก failure ของ bundled-loader แบบสังเคราะห์ เมทริกซ์เต็มของ bundled update/channel ยังคงเป็น manual/full-suite เพราะมีการรัน npm update จริงซ้ำหลายรอบและ doctor repair
|
||||
ตรรกะการกำหนดขอบเขตอยู่ใน `scripts/ci-changed-scope.mjs` และมี unit tests ครอบคลุมใน `src/scripts/ci-changed-scope.test.ts`
|
||||
การแก้ไข CI workflow จะตรวจสอบกราฟ Node CI และ workflow linting แต่จะไม่บังคับให้รัน Windows, Android หรือ native builds ของ macOS เพียงเพราะมีการแก้ workflow; เลนของแพลตฟอร์มเหล่านั้นยังคงถูกกำหนดขอบเขตตามการเปลี่ยนแปลงในซอร์สของแพลตฟอร์มนั้น
|
||||
การตรวจสอบ Node บน Windows ถูกกำหนดขอบเขตให้ครอบคลุมเฉพาะ process/path wrappers ที่เฉพาะกับ Windows, ตัวช่วย npm/pnpm/UI runner, การตั้งค่า package manager และพื้นผิวของ CI workflow ที่รันเลนนั้น; การเปลี่ยนแปลงซอร์ส, plugin, install-smoke และเฉพาะการทดสอบที่ไม่เกี่ยวข้อง จะยังอยู่ในเลน Linux Node เพื่อไม่ให้ต้องจอง worker Windows แบบ 16-vCPU สำหรับความครอบคลุมที่เลนทดสอบปกติได้ครอบคลุมอยู่แล้ว
|
||||
เวิร์กโฟลว์ `install-smoke` แยกต่างหากนำสคริปต์กำหนดขอบเขตเดียวกันมาใช้ผ่านงาน `preflight` ของตัวเอง โดยคำนวณ `run_install_smoke` จากสัญญาณ changed-smoke ที่แคบกว่า ดังนั้น Docker/install smoke จะรันเมื่อมีการเปลี่ยนแปลงที่เกี่ยวกับ install, packaging, container, bundled extension production และพื้นผิว core plugin/channel/gateway/Plugin SDK ที่งาน Docker smoke ใช้งาน การแก้ไขเฉพาะ test และ docs จะไม่จอง Docker workers
|
||||
QR package smoke ของมันจะบังคับให้ Docker `pnpm install` layer รันใหม่ โดยยังคงรักษา BuildKit pnpm store cache เอาไว้ จึงยังคงทดสอบการติดตั้งได้โดยไม่ต้องดาวน์โหลด dependencies ใหม่ทุกครั้ง
|
||||
gateway-network e2e ของมันจะใช้ runtime image ที่สร้างไว้ก่อนหน้าในงานเดิมซ้ำ จึงเพิ่มความครอบคลุม WebSocket แบบ container-to-container จริง โดยไม่ต้องเพิ่มการ build Docker อีกครั้ง
|
||||
บนเครื่อง local, `test:docker:all` จะ prebuild live-test image ที่แชร์ร่วมกันหนึ่งรายการ และ built-app image จาก `scripts/e2e/Dockerfile` ที่แชร์ร่วมกันอีกหนึ่งรายการ จากนั้นจึงรันเลน live/E2E แบบขนานด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1`; สามารถปรับ concurrency ค่าเริ่มต้นที่ 4 ได้ด้วย `OPENCLAW_DOCKER_ALL_PARALLELISM`
|
||||
ตัว aggregate บนเครื่อง local จะหยุดกำหนดตารางเลนใหม่ใน pool หลังจากเจอความล้มเหลวครั้งแรกตามค่าเริ่มต้น และแต่ละเลนมี timeout 120 นาที ซึ่ง override ได้ด้วย `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`
|
||||
เลนที่ไวต่อ startup หรือ provider จะรันแบบ exclusive หลังจาก pool แบบขนานเสร็จแล้ว
|
||||
เวิร์กโฟลว์ live/E2E แบบใช้ซ้ำได้สะท้อนรูปแบบ shared-image เดียวกัน โดยสร้างและ push Docker E2E image บน GHCR ที่ติดแท็กด้วย SHA หนึ่งรายการก่อน Docker matrix แล้วจึงรันเมทริกซ์ด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1`
|
||||
เวิร์กโฟลว์ live/E2E แบบ scheduled จะรันชุด Docker สำหรับเส้นทางรีลีสเต็มรูปแบบทุกวัน
|
||||
การทดสอบ Docker ของ QR และ installer ยังคงใช้ Dockerfiles เฉพาะของตัวเองที่มุ่งเน้นการติดตั้ง
|
||||
มีงาน `docker-e2e-fast` แยกต่างหากที่รันโปรไฟล์ Docker ของ bundled-plugin แบบมีขอบเขต ภายใต้ command timeout 120 วินาที: setup-entry dependency repair พร้อม synthetic bundled-loader failure isolation
|
||||
เมทริกซ์ bundled update/channel แบบเต็มยังคงเป็นแบบ manual/full-suite เพราะมีการทำ npm update จริงซ้ำหลายครั้งและทำ doctor repair pass
|
||||
|
||||
ตรรกะ changed-lane ในเครื่องอยู่ใน `scripts/changed-lanes.mjs` และถูกรันโดย `scripts/check-changed.mjs` local gate นี้เข้มงวดกว่าขอบเขตแพลตฟอร์มกว้าง ๆ ของ CI ในด้าน boundary ของสถาปัตยกรรม: การเปลี่ยนแปลง production ของ core จะรัน core prod typecheck พร้อม core tests, การเปลี่ยนแปลงเฉพาะ test ของ core จะรันเฉพาะ core test typecheck/tests, การเปลี่ยนแปลง production ของ extension จะรัน extension prod typecheck พร้อม extension tests และการเปลี่ยนแปลงเฉพาะ test ของ extension จะรันเฉพาะ extension test typecheck/tests การเปลี่ยนแปลงของ Plugin SDK สาธารณะหรือ plugin-contract จะขยายไปยังการตรวจสอบ extension เพราะ extensions พึ่งพาสัญญาเหล่านั้น การ bump เวอร์ชันที่เป็นเฉพาะ release metadata จะรันการตรวจสอบแบบเจาะจงสำหรับ version/config/root-dependency ส่วนการเปลี่ยนแปลง root/config ที่ไม่รู้จักจะ fail-safe ไปยังทุก lane
|
||||
ตรรกะ local changed-lane อยู่ใน `scripts/changed-lanes.mjs` และถูกรันโดย `scripts/check-changed.mjs`
|
||||
local gate นี้เข้มงวดกว่าการกำหนดขอบเขตแพลตฟอร์มแบบกว้างของ CI ในเรื่อง architecture boundaries: การเปลี่ยนแปลง production ของ core จะรัน core prod typecheck พร้อม core tests, การเปลี่ยนแปลงเฉพาะการทดสอบของ core จะรันเฉพาะ core test typecheck/tests, การเปลี่ยนแปลง production ของ extension จะรัน extension prod typecheck พร้อม extension tests และการเปลี่ยนแปลงเฉพาะการทดสอบของ extension จะรันเฉพาะ extension test typecheck/tests
|
||||
การเปลี่ยนแปลง Public Plugin SDK หรือ plugin-contract จะขยายไปสู่การตรวจสอบ extension ด้วย เพราะ extensions พึ่งพา core contracts เหล่านั้น
|
||||
การ bump เวอร์ชันที่เป็น metadata สำหรับรีลีสเท่านั้นจะรัน targeted version/config/root-dependency checks
|
||||
การเปลี่ยนแปลง root/config ที่ไม่ทราบประเภทจะ fail safe ไปยังทุกเลน
|
||||
|
||||
สำหรับ push เมทริกซ์ `checks` จะเพิ่ม lane `compat-node22` แบบ push-only สำหรับ pull request lane นี้จะถูกข้าม และเมทริกซ์จะยังคงโฟกัสที่ lane การทดสอบ/แชนเนลปกติ
|
||||
บน push, เมทริกซ์ `checks` จะเพิ่มเลน `compat-node22` ที่รันเฉพาะ push
|
||||
บน pull request เลนนั้นจะถูกข้ามไป และเมทริกซ์จะยังคงเน้นเฉพาะเลนทดสอบ/channel ปกติ
|
||||
|
||||
ตระกูลการทดสอบ Node ที่ช้าที่สุดถูกแยกหรือปรับสมดุลเพื่อให้งานแต่ละงานมีขนาดเล็ก: channel contracts แยกการครอบคลุม registry และ core เป็นทั้งหมดหก shard แบบถ่วงน้ำหนัก, bundled plugin tests ถูกปรับสมดุลบน worker ของ extension หกตัว, auto-reply รันเป็น worker ที่สมดุลสามตัวแทนหก worker เล็ก ๆ และ config ของ agentic gateway/plugin ถูกกระจายไปตามงาน agentic Node ที่ใช้เฉพาะซอร์สที่มีอยู่แล้ว แทนที่จะรอ built artifact การทดสอบกว้าง ๆ สำหรับ browser, QA, media และ plugin เบ็ดเตล็ด ใช้ config ของ Vitest เฉพาะแทน shared plugin catch-all lane ของ agents แบบกว้างใช้ตัวจัดตาราง file-parallel ร่วมของ Vitest เพราะถูกครอบงำด้วย import/scheduling มากกว่าจะมีไฟล์ทดสอบช้าเพียงไฟล์เดียว `runtime-config` รันร่วมกับ infra core-runtime shard เพื่อไม่ให้ shared runtime shard เป็นเจ้าของส่วนท้าย `check-additional` เก็บงาน compile/canary ของ package-boundary ไว้ด้วยกัน และแยกสถาปัตยกรรม topology ของ runtime ออกจากการครอบคลุม gateway watch; boundary guard shard รัน guard เล็กอิสระของมันพร้อมกันภายในงานเดียว Gateway watch, channel tests และ core support-boundary shard รันพร้อมกันภายใน `build-artifacts` หลังจาก `dist/` และ `dist-runtime/` ถูก build แล้ว ทำให้ยังคงชื่อ check เดิมเป็นงาน verifier แบบเบา ขณะหลีกเลี่ยง worker Blacksmith เพิ่มอีกสองตัวและคิว consumer artifact ชุดที่สอง
|
||||
Android CI รันทั้ง `testPlayDebugUnitTest` และ `testThirdPartyDebugUnitTest` แล้วจึง build Play debug APK โดย flavor แบบ third-party ไม่มี source set หรือ manifest แยก แต่ lane ของ unit test ยัง compile flavor นั้นพร้อมแฟล็ก BuildConfig ของ SMS/call-log ขณะหลีกเลี่ยงงานแพ็กเกจ debug APK ซ้ำในทุก push ที่เกี่ยวข้องกับ Android
|
||||
`extension-fast` เป็น PR-only เพราะการ push ได้รัน shard ของ bundled plugin แบบเต็มอยู่แล้ว ซึ่งทำให้ได้ feedback สำหรับ plugin ที่เปลี่ยนระหว่างการ review โดยไม่ต้องจอง worker Blacksmith เพิ่มบน `main` สำหรับการครอบคลุมที่มีอยู่แล้วใน `checks-node-extensions`
|
||||
ตระกูลการทดสอบ Node ที่ช้าที่สุดถูกแยกหรือถ่วงดุลเพื่อให้งานแต่ละงานมีขนาดเล็ก: channel contracts แยกความครอบคลุมของ registry และ core ออกเป็นทั้งหมดหก shard แบบถ่วงน้ำหนัก, การทดสอบ bundled plugin ถ่วงดุลข้าม workers ของ extension จำนวนหกตัว, auto-reply รันเป็น workers แบบถ่วงดุลสามตัวแทนที่จะเป็น workers เล็ก ๆ หกตัว และ configs ของ agentic gateway/plugin จะถูกกระจายไปยังงาน source-only agentic Node ที่มีอยู่แทนที่จะไปรอ built artifacts
|
||||
การทดสอบ browser, QA, media และ plugin เบ็ดเตล็ดแบบกว้างใช้ Vitest config เฉพาะของตัวเอง แทนที่จะใช้ plugin catch-all ที่แชร์ร่วมกัน
|
||||
เลน agents แบบกว้างใช้ตัวจัดตาราง file-parallel ของ Vitest ที่แชร์ร่วมกัน เพราะถูกครอบงำด้วยการ import/การจัดตาราง มากกว่าจะเป็นเจ้าของโดยไฟล์ทดสอบช้าไฟล์เดียว
|
||||
`runtime-config` รันร่วมกับ infra core-runtime shard เพื่อไม่ให้ shared runtime shard เป็นเจ้าของส่วนท้ายของงาน
|
||||
`check-additional` รวม package-boundary compile/canary work ไว้ด้วยกัน และแยก runtime topology architecture ออกจาก gateway watch coverage; boundary guard shard จะรัน guards อิสระขนาดเล็กของตัวเองพร้อมกันภายในงานเดียว
|
||||
Gateway watch, channel tests และ core support-boundary shard จะรันพร้อมกันภายใน `build-artifacts` หลังจากสร้าง `dist/` และ `dist-runtime/` เรียบร้อยแล้ว โดยคงชื่อ check เดิมไว้เป็นงาน verifier แบบเบา ขณะเดียวกันก็หลีกเลี่ยงการใช้ Blacksmith workers เพิ่มอีกสองตัวและหลีกเลี่ยงคิว artifact-consumer รอบที่สอง
|
||||
Android CI จะรันทั้ง `testPlayDebugUnitTest` และ `testThirdPartyDebugUnitTest` จากนั้นจึง build Play debug APK
|
||||
third-party flavor ไม่มี source set หรือ manifest แยกต่างหาก; เลน unit-test ของมันยังคงคอมไพล์ flavor นั้นด้วยแฟล็ก BuildConfig ของ SMS/call-log ขณะเดียวกันก็หลีกเลี่ยงงาน debug APK packaging ที่ซ้ำซ้อนในทุก push ที่เกี่ยวข้องกับ Android
|
||||
`extension-fast` เป็น PR-only เพราะการรันบน push ได้รัน bundled plugin shards แบบเต็มอยู่แล้ว ซึ่งช่วยให้มี feedback สำหรับ plugin ที่เปลี่ยนระหว่างรีวิว โดยไม่ต้องจอง Blacksmith worker เพิ่มบน `main` สำหรับความครอบคลุมที่มีอยู่แล้วใน `checks-node-extensions`
|
||||
|
||||
GitHub อาจทำเครื่องหมายงานที่ถูกแทนที่ว่าเป็น `cancelled` เมื่อมี push ใหม่กว่ามาถึง PR เดียวกันหรือ ref `main` เดียวกัน ให้ถือว่านี่เป็น noise ของ CI เว้นแต่ว่าการรันล่าสุดสำหรับ ref เดียวกันนั้นก็ยังล้มเหลวด้วย aggregate shard checks ใช้ `!cancelled() && always()` เพื่อให้ยังรายงานความล้มเหลวปกติของ shard แต่จะไม่เข้าแถวหลังจากทั้ง workflow ถูกแทนที่ไปแล้ว
|
||||
คีย์ concurrency ของ CI ถูกกำหนดเวอร์ชัน (`CI-v7-*`) เพื่อไม่ให้ zombie ฝั่ง GitHub ในกลุ่มคิวเก่าบล็อกการรันใหม่บน main ได้ไม่มีกำหนด
|
||||
GitHub อาจทำเครื่องหมายงานที่ถูกแทนที่แล้วว่า `cancelled` เมื่อมี push ใหม่กว่ามายัง PR เดียวกันหรือ ref `main` เดียวกัน
|
||||
ให้ถือว่านี่เป็นสัญญาณรบกวนของ CI เว้นแต่ว่าการรันล่าสุดสำหรับ ref เดียวกันนั้นจะล้มเหลวด้วย
|
||||
การตรวจสอบ shard แบบ aggregate ใช้ `!cancelled() && always()` เพื่อให้ยังคงรายงานความล้มเหลวปกติของ shard ได้ แต่จะไม่เข้าคิวหลังจากที่ทั้ง workflow ถูกแทนที่ไปแล้ว
|
||||
|
||||
## Runner
|
||||
คีย์ concurrency ของ CI ถูกใส่เวอร์ชันไว้ (`CI-v7-*`) เพื่อไม่ให้ zombie ฝั่ง GitHub ใน queue group เก่าบล็อกการรันใหม่บน main ได้ไม่มีกำหนด
|
||||
|
||||
| Runner | งาน |
|
||||
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, งาน security แบบเร็วและตัวรวม (`security-scm-fast`, `security-dependency-audit`, `security-fast`), การตรวจสอบ protocol/contract/bundled แบบเร็ว, การตรวจสอบ channel contract แบบแบ่ง shard, shard ของ `check` ยกเว้น lint, shard และตัวรวมของ `check-additional`, ตัวตรวจสอบ aggregate ของ Node test, การตรวจสอบ docs, Python Skills, workflow-sanity, labeler, auto-response; preflight ของ install-smoke ก็ใช้ Ubuntu ที่โฮสต์โดย GitHub เช่นกัน เพื่อให้เมทริกซ์ Blacksmith เข้าแถวได้เร็วขึ้น |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard การทดสอบ Linux Node, shard การทดสอบ bundled plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` ซึ่งยังไวต่อ CPU มากพอที่ 8 vCPU มีต้นทุนมากกว่าประโยชน์ที่ประหยัดได้; Docker build ของ install-smoke ซึ่งเวลาเข้าคิวของ 32-vCPU มีต้นทุนมากกว่าประโยชน์ที่ประหยัดได้ |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` บน `openclaw/openclaw`; fork จะ fallback ไปใช้ `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` บน `openclaw/openclaw`; fork จะ fallback ไปใช้ `macos-latest` |
|
||||
## รันเนอร์
|
||||
|
||||
## คำสั่งในเครื่องที่เทียบเท่ากัน
|
||||
| รันเนอร์ | งาน |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, งาน security แบบเร็วและงาน aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), การตรวจสอบ protocol/contract/bundled แบบเร็ว, การตรวจสอบ channel contract แบบแบ่ง shard, shard ของ `check` ยกเว้น lint, shard และ aggregate ของ `check-additional`, ตัวตรวจสอบ aggregate ของชุดทดสอบ Node, การตรวจสอบ docs, Python Skills, workflow-sanity, labeler, auto-response; preflight ของ install-smoke ก็ใช้ Ubuntu ที่โฮสต์โดย GitHub เช่นกัน เพื่อให้เมทริกซ์ Blacksmith เข้าคิวได้เร็วขึ้น |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard ของชุดทดสอบ Linux Node, shard ของชุดทดสอบ bundled plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` ซึ่งยังคงไวต่อ CPU มากพอที่ 8 vCPU จะมีต้นทุนสูงกว่าประโยชน์ที่ได้; การ build Docker ของ install-smoke ซึ่งเวลาเข้าคิวของ 32-vCPU มีต้นทุนสูงกว่าประโยชน์ที่ได้ |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` บน `openclaw/openclaw`; fork จะ fallback ไปใช้ `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` บน `openclaw/openclaw`; fork จะ fallback ไปใช้ `macos-latest` |
|
||||
|
||||
## คำสั่งเทียบเท่าบนเครื่อง local
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # ตรวจสอบตัวจำแนก changed-lane ในเครื่องสำหรับ origin/main...HEAD
|
||||
pnpm check:changed # local gate อัจฉริยะ: typecheck/lint/tests ที่เปลี่ยนตาม boundary lane
|
||||
pnpm changed:lanes # ตรวจสอบตัวจัดประเภท changed-lane บนเครื่องสำหรับ origin/main...HEAD
|
||||
pnpm check:changed # local gate อัจฉริยะ: typecheck/lint/tests ตามเลน boundary ที่เปลี่ยน
|
||||
pnpm check # local gate แบบเร็ว: production tsgo + lint แบบแบ่ง shard + fast guards แบบขนาน
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # gate เดิมพร้อมเวลาแยกตามแต่ละสเตจ
|
||||
pnpm check:timed # gate เดียวกันพร้อมเวลาแยกตามแต่ละช่วง
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
pnpm test # การทดสอบ vitest
|
||||
pnpm test # การทดสอบ Vitest
|
||||
pnpm test:channels
|
||||
pnpm test:contracts:channels
|
||||
pnpm check:docs # รูปแบบ docs + lint + ลิงก์เสีย
|
||||
pnpm build # build dist เมื่อ lane ของ artifact/build-smoke ใน CI มีความเกี่ยวข้อง
|
||||
pnpm check:docs # จัดรูปแบบ docs + lint + broken links
|
||||
pnpm build # build dist เมื่อเลน artifact/build-smoke ของ CI มีความเกี่ยวข้อง
|
||||
node scripts/ci-run-timings.mjs <run-id> # สรุป wall time, queue time และงานที่ช้าที่สุด
|
||||
```
|
||||
|
||||
@ -1,21 +1,21 @@
|
||||
---
|
||||
read_when:
|
||||
- คุณต้องการการวินิจฉัยอย่างรวดเร็วเกี่ยวกับสถานะสุขภาพของแชนแนลและผู้รับของเซสชันล่าสุด
|
||||
- คุณต้องการสถานะ “all” ที่คัดลอกไปวางได้สำหรับการดีบัก
|
||||
summary: ข้อมูลอ้างอิง CLI สำหรับ `openclaw status` (การวินิจฉัย การตรวจสอบ และ snapshot การใช้งาน)
|
||||
- คุณต้องการการวินิจฉัยอย่างรวดเร็วเกี่ยวกับสถานะของช่องทาง + ผู้รับของเซสชันล่าสุด
|
||||
- คุณต้องการสถานะ “ทั้งหมด” แบบพร้อมวางสำหรับการดีบัก
|
||||
summary: ข้อมูลอ้างอิง CLI สำหรับ `openclaw status` (การวินิจฉัย, โพรบ, ภาพรวมการใช้งาน)
|
||||
title: สถานะ
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T06:19:53Z"
|
||||
generated_at: "2026-04-23T13:58:17Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: fbe9d94fbe9938cd946ee6f293b5bd3b464b75e1ade2eacdd851788c3bffe94e
|
||||
source_hash: 015614e329ec172a62c625581897fa64589f12dfe28edefe8a2764b5b5367b2a
|
||||
source_path: cli/status.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# `openclaw status`
|
||||
|
||||
การวินิจฉัยสำหรับแชนแนล + เซสชัน
|
||||
การวินิจฉัยสำหรับช่องทาง + เซสชัน
|
||||
|
||||
```bash
|
||||
openclaw status
|
||||
@ -26,17 +26,18 @@ openclaw status --usage
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- `--deep` จะเรียกใช้การตรวจสอบแบบสด (WhatsApp Web + Telegram + Discord + Slack + Signal)
|
||||
- `--usage` จะแสดงหน้าต่างการใช้งานของผู้ให้บริการที่ถูกทำให้เป็นมาตรฐานในรูปแบบ `เหลือ X%`
|
||||
- ฟิลด์ดิบ `usage_percent` / `usagePercent` ของ MiniMax เป็นโควตาที่เหลืออยู่ ดังนั้น OpenClaw จะกลับค่าก่อนแสดงผล; ฟิลด์แบบนับจำนวนจะมีลำดับความสำคัญมากกว่าเมื่อมีอยู่ การตอบกลับ `model_remains` จะให้ความสำคัญกับรายการ chat-model อนุมานป้ายหน้าต่างจากการประทับเวลาเมื่อจำเป็น และรวมชื่อโมเดลไว้ในป้ายแผน
|
||||
- เมื่อ snapshot ของเซสชันปัจจุบันมีข้อมูลน้อย `/status` สามารถเติมค่าตัวนับโทเค็นและแคชกลับจากบันทึกการใช้งาน transcript ล่าสุดได้ ค่าที่เป็น nonzero จากการทำงานสดที่มีอยู่แล้วจะยังมีลำดับความสำคัญเหนือกว่าค่าที่เติมกลับจาก transcript
|
||||
- การเติมกลับจาก transcript ยังสามารถกู้คืนป้ายโมเดลรันไทม์ที่ใช้งานอยู่ได้เมื่อรายการเซสชันแบบสดไม่มีข้อมูลดังกล่าว หากโมเดลจาก transcript นั้นแตกต่างจากโมเดลที่เลือก status จะ resolve context window เทียบกับโมเดลรันไทม์ที่กู้คืนมา แทนที่จะใช้โมเดลที่เลือก
|
||||
- สำหรับการคำนวณขนาดพรอมป์ การเติมกลับจาก transcript จะเลือกยอดรวมที่เกี่ยวกับพรอมป์ซึ่งมีค่ามากกว่าเมื่อ metadata ของเซสชันไม่มีหรือมีค่าน้อยกว่า เพื่อไม่ให้เซสชัน custom-provider แสดงโทเค็นเป็น `0`
|
||||
- เอาต์พุตรวมถึงที่เก็บเซสชันต่อ agent เมื่อมีการกำหนดค่า agent หลายตัว
|
||||
- ภาพรวมรวมถึงสถานะการติดตั้ง/รันไทม์ของบริการ Gateway + Node host เมื่อมีข้อมูล
|
||||
- ภาพรวมรวมถึงช่องทางอัปเดต + git SHA (สำหรับ source checkout)
|
||||
- ข้อมูลอัปเดตจะแสดงใน Overview; หากมีอัปเดตพร้อมใช้งาน status จะแสดงคำแนะนำให้รัน `openclaw update` (ดู [การอัปเดต](/th/install/updating))
|
||||
- พื้นผิว status แบบอ่านอย่างเดียว (`status`, `status --json`, `status --all`) จะ resolve SecretRefs ที่รองรับสำหรับพาธคอนฟิกเป้าหมายเมื่อทำได้
|
||||
- หากมีการกำหนดค่า SecretRef ของแชนแนลที่รองรับไว้แต่ไม่พร้อมใช้งานในเส้นทางคำสั่งปัจจุบัน status จะยังคงเป็นแบบอ่านอย่างเดียวและรายงานเอาต์พุตแบบ degraded แทนการล้มเหลว เอาต์พุตสำหรับมนุษย์จะแสดงคำเตือน เช่น “configured token unavailable in this command path” และเอาต์พุต JSON จะมี `secretDiagnostics`
|
||||
- เมื่อการ resolve SecretRef ในระดับคำสั่งสำเร็จ status จะให้ความสำคัญกับ snapshot ที่ resolve แล้วและล้างเครื่องหมายชั่วคราวของแชนแนลประเภท “secret unavailable” ออกจากเอาต์พุตสุดท้าย
|
||||
- `--deep` เรียกใช้โพรบแบบสด (WhatsApp Web + Telegram + Discord + Slack + Signal)
|
||||
- `--usage` พิมพ์ช่วงการใช้งานของผู้ให้บริการที่ถูกทำให้เป็นมาตรฐานในรูปแบบ `X% left`
|
||||
- เอาต์พุตสถานะเซสชันตอนนี้แยก `Runtime:` ออกจาก `Runner:` แล้ว `Runtime` คือเส้นทางการทำงานและสถานะแซนด์บ็อกซ์ (`direct`, `docker/*`) ส่วน `Runner` จะบอกคุณว่าเซสชันกำลังใช้ Pi แบบฝังตัว, ผู้ให้บริการที่ขับเคลื่อนด้วย CLI หรือแบ็กเอนด์ ACP harness เช่น `codex (acp/acpx)`
|
||||
- ฟิลด์ `usage_percent` / `usagePercent` แบบดิบของ MiniMax เป็นโควต้าที่เหลืออยู่ ดังนั้น OpenClaw จึงกลับค่าก่อนแสดงผล โดยฟิลด์แบบนับจำนวนจะมีลำดับความสำคัญสูงกว่าเมื่อมีอยู่ การตอบกลับ `model_remains` จะใช้รายการ chat-model เป็นหลัก, อนุมานป้ายกำกับช่วงเวลาจากการประทับเวลาเมื่อจำเป็น และรวมชื่อโมเดลไว้ในป้ายกำกับแผน
|
||||
- เมื่อสแนปช็อตของเซสชันปัจจุบันมีข้อมูลน้อย `/status` สามารถเติมตัวนับโทเค็นและแคชกลับจากบันทึกการใช้งาน transcript ล่าสุดได้ ค่าที่ไม่เป็นศูนย์จากสถานะสดที่มีอยู่จะยังคงมีลำดับความสำคัญเหนือกว่าค่าที่เติมกลับจาก transcript
|
||||
- การเติมกลับจาก transcript ยังสามารถกู้คืนป้ายกำกับโมเดล runtime ที่ใช้งานอยู่ได้เมื่อไม่มีอยู่ในรายการเซสชันสด หากโมเดลจาก transcript นั้นต่างจากโมเดลที่เลือกไว้ สถานะจะจับคู่ context window กับโมเดล runtime ที่กู้คืนมาแทนโมเดลที่เลือก
|
||||
- สำหรับการคิดขนาดพรอมป์ การเติมกลับจาก transcript จะเลือกยอดรวมที่เกี่ยวกับพรอมป์ซึ่งมีค่ามากกว่า เมื่อไม่มีเมทาดาทาของเซสชันหรือมีค่าน้อยกว่า เพื่อไม่ให้เซสชัน custom-provider ยุบเหลือการแสดงผลโทเค็นเป็น `0`
|
||||
- เอาต์พุตรวมคลังเก็บเซสชันต่อเอเจนต์เมื่อมีการกำหนดค่าหลายเอเจนต์
|
||||
- ภาพรวมรวมสถานะการติดตั้ง/การทำงานของบริการโฮสต์ Gateway + Node เมื่อมี
|
||||
- ภาพรวมรวมช่องทางอัปเดต + git SHA (สำหรับการเช็กเอาต์จากซอร์ส)
|
||||
- ข้อมูลการอัปเดตจะแสดงในภาพรวม หากมีการอัปเดตพร้อมใช้งาน status จะพิมพ์คำแนะนำให้เรียกใช้ `openclaw update` (ดู [การอัปเดต](/th/install/updating))
|
||||
- ส่วนแสดงสถานะแบบอ่านอย่างเดียว (`status`, `status --json`, `status --all`) จะ resolve SecretRefs ที่รองรับสำหรับพาธ config เป้าหมายเมื่อทำได้
|
||||
- หากมีการกำหนดค่า SecretRef ของช่องทางที่รองรับไว้แต่ไม่พร้อมใช้งานในเส้นทางคำสั่งปัจจุบัน status จะยังคงเป็นแบบอ่านอย่างเดียวและรายงานเอาต์พุตที่ลดทอนลงแทนการล้มเหลว เอาต์พุตสำหรับมนุษย์อ่านจะแสดงคำเตือน เช่น “configured token unavailable in this command path” และเอาต์พุต JSON จะรวม `secretDiagnostics`
|
||||
- เมื่อการ resolve SecretRef ภายในคำสั่งสำเร็จ status จะใช้สแนปช็อตที่ resolve แล้วเป็นหลัก และล้างเครื่องหมายช่องทาง “secret unavailable” แบบชั่วคราวออกจากเอาต์พุตสุดท้าย
|
||||
- `status --all` รวมแถวภาพรวม Secrets และส่วนการวินิจฉัยที่สรุปการวินิจฉัย secret (ตัดทอนเพื่อให้อ่านง่าย) โดยไม่หยุดการสร้างรายงาน
|
||||
|
||||
@ -1,61 +1,61 @@
|
||||
---
|
||||
read_when:
|
||||
- คุณต้องการใช้โมเดล OpenAI ใน OpenClaw
|
||||
- คุณต้องการการยืนยันตัวตนด้วยการสมัครใช้งาน Codex แทน API keys
|
||||
- คุณต้องการพฤติกรรมการรันเอเจนต์ของ GPT-5 ที่เข้มงวดขึ้น
|
||||
summary: ใช้ OpenAI ผ่าน API keys หรือการสมัครใช้งาน Codex ใน OpenClaw
|
||||
- คุณต้องการใช้การยืนยันตัวตนด้วยการสมัครใช้งาน Codex แทนคีย์ API
|
||||
- คุณต้องการพฤติกรรมการทำงานของเอเจนต์ GPT-5 ที่เข้มงวดมากขึ้น
|
||||
summary: ใช้ OpenAI ผ่านคีย์ API หรือการสมัครใช้งาน Codex ใน OpenClaw
|
||||
title: OpenAI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T10:22:39Z"
|
||||
generated_at: "2026-04-23T13:58:20Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: c3d847e53c2faee5363071dfdcb1f4150b64577674161e000844f579482198d1
|
||||
source_hash: ac42660234e1971440f6de3b04adb1d3a1fddca20219fb68936c36e4c2f95265
|
||||
source_path: providers/openai.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# OpenAI
|
||||
|
||||
OpenAI ให้บริการ API สำหรับนักพัฒนาสำหรับโมเดล GPT OpenClaw รองรับ 2 เส้นทางการยืนยันตัวตน:
|
||||
OpenAI มี API สำหรับนักพัฒนาสำหรับโมเดล GPT OpenClaw รองรับการยืนยันตัวตน 2 รูปแบบ:
|
||||
|
||||
- **API key** — การเข้าถึง OpenAI Platform โดยตรงพร้อมการคิดค่าบริการตามการใช้งาน (`openai/*` models)
|
||||
- **การสมัครใช้งาน Codex** — การลงชื่อเข้าใช้ ChatGPT/Codex พร้อมการเข้าถึงผ่านการสมัครใช้งาน (`openai-codex/*` models)
|
||||
- **คีย์ API** — เข้าถึง OpenAI Platform โดยตรงพร้อมการคิดค่าบริการตามการใช้งาน (`openai/*` models)
|
||||
- **การสมัครใช้งาน Codex** — ลงชื่อเข้าใช้ ChatGPT/Codex พร้อมสิทธิ์การเข้าถึงตามการสมัครใช้งาน (`openai-codex/*` models)
|
||||
|
||||
OpenAI รองรับการใช้งาน subscription OAuth ในเครื่องมือภายนอกและเวิร์กโฟลว์อย่าง OpenClaw อย่างชัดเจน
|
||||
|
||||
## ความครอบคลุมของฟีเจอร์ใน OpenClaw
|
||||
|
||||
| ความสามารถของ OpenAI | พื้นผิวใน OpenClaw | สถานะ |
|
||||
| ------------------------- | ------------------------------------------ | ------------------------------------------------------- |
|
||||
| Chat / Responses | model provider `openai/<model>` | ใช่ |
|
||||
| โมเดลแบบสมัครใช้งาน Codex | model provider `openai-codex/<model>` | ใช่ |
|
||||
| การค้นหาเว็บฝั่งเซิร์ฟเวอร์ | Native OpenAI Responses tool | ใช่ เมื่อเปิดใช้ web search และไม่ได้ pin provider ไว้ |
|
||||
| รูปภาพ | `image_generate` | ใช่ |
|
||||
| วิดีโอ | `video_generate` | ใช่ |
|
||||
| Text-to-speech | `messages.tts.provider: "openai"` / `tts` | ใช่ |
|
||||
| Speech-to-text แบบแบตช์ | `tools.media.audio` / media understanding | ใช่ |
|
||||
| Speech-to-text แบบสตรีม | Voice Call `streaming.provider: "openai"` | ใช่ |
|
||||
| เสียงแบบ Realtime | Voice Call `realtime.provider: "openai"` | ใช่ |
|
||||
| Embeddings | memory embedding provider | ใช่ |
|
||||
| ความสามารถของ OpenAI | พื้นที่ใน OpenClaw | สถานะ |
|
||||
| ------------------------- | ----------------------------------------- | ------------------------------------------------------ |
|
||||
| แชต / Responses | ผู้ให้บริการโมเดล `openai/<model>` | ใช่ |
|
||||
| โมเดลการสมัครใช้งาน Codex | ผู้ให้บริการโมเดล `openai-codex/<model>` | ใช่ |
|
||||
| การค้นหาเว็บฝั่งเซิร์ฟเวอร์ | เครื่องมือ OpenAI Responses แบบเนทีฟ | ใช่ เมื่อเปิดใช้การค้นหาเว็บและไม่ได้ปักหมุด provider |
|
||||
| รูปภาพ | `image_generate` | ใช่ |
|
||||
| วิดีโอ | `video_generate` | ใช่ |
|
||||
| การแปลงข้อความเป็นเสียง | `messages.tts.provider: "openai"` / `tts` | ใช่ |
|
||||
| การแปลงเสียงเป็นข้อความแบบแบตช์ | `tools.media.audio` / media understanding | ใช่ |
|
||||
| การแปลงเสียงเป็นข้อความแบบสตรีมมิง | Voice Call `streaming.provider: "openai"` | ใช่ |
|
||||
| เสียงแบบเรียลไทม์ | Voice Call `realtime.provider: "openai"` | ใช่ |
|
||||
| Embeddings | ผู้ให้บริการ memory embedding | ใช่ |
|
||||
|
||||
## เริ่มต้นใช้งาน
|
||||
|
||||
เลือกวิธีการยืนยันตัวตนที่คุณต้องการ และทำตามขั้นตอนการตั้งค่า
|
||||
เลือกวิธีการยืนยันตัวตนที่คุณต้องการ แล้วทำตามขั้นตอนการตั้งค่า
|
||||
|
||||
<Tabs>
|
||||
<Tab title="API key (OpenAI Platform)">
|
||||
**เหมาะที่สุดสำหรับ:** การเข้าถึง API โดยตรงและการคิดค่าบริการตามการใช้งาน
|
||||
<Tab title="คีย์ API (OpenAI Platform)">
|
||||
**เหมาะสำหรับ:** การเข้าถึง API โดยตรงและการคิดค่าบริการตามการใช้งาน
|
||||
|
||||
<Steps>
|
||||
<Step title="รับ API key ของคุณ">
|
||||
สร้างหรือคัดลอก API key จาก [แดชบอร์ด OpenAI Platform](https://platform.openai.com/api-keys)
|
||||
<Step title="รับคีย์ API ของคุณ">
|
||||
สร้างหรือคัดลอกคีย์ API จาก [แดชบอร์ด OpenAI Platform](https://platform.openai.com/api-keys)
|
||||
</Step>
|
||||
<Step title="รัน onboarding">
|
||||
<Step title="เรียกใช้ onboarding">
|
||||
```bash
|
||||
openclaw onboard --auth-choice openai-api-key
|
||||
```
|
||||
|
||||
หรือส่ง key โดยตรง:
|
||||
หรือส่งคีย์โดยตรง:
|
||||
|
||||
```bash
|
||||
openclaw onboard --openai-api-key "$OPENAI_API_KEY"
|
||||
@ -72,8 +72,8 @@ x-i18n:
|
||||
|
||||
| Model ref | Route | Auth |
|
||||
|-----------|-------|------|
|
||||
| `openai/gpt-5.4` | OpenAI Platform API โดยตรง | `OPENAI_API_KEY` |
|
||||
| `openai/gpt-5.4-pro` | OpenAI Platform API โดยตรง | `OPENAI_API_KEY` |
|
||||
| `openai/gpt-5.4` | Direct OpenAI Platform API | `OPENAI_API_KEY` |
|
||||
| `openai/gpt-5.4-pro` | Direct OpenAI Platform API | `OPENAI_API_KEY` |
|
||||
|
||||
<Note>
|
||||
การลงชื่อเข้าใช้ ChatGPT/Codex จะถูกกำหนดเส้นทางผ่าน `openai-codex/*` ไม่ใช่ `openai/*`
|
||||
@ -89,27 +89,27 @@ x-i18n:
|
||||
```
|
||||
|
||||
<Warning>
|
||||
OpenClaw **ไม่** เปิดเผย `openai/gpt-5.3-codex-spark` บนเส้นทาง API โดยตรง คำขอ OpenAI API แบบ live จะปฏิเสธโมเดลนั้น Spark ใช้ได้เฉพาะกับ Codex เท่านั้น
|
||||
OpenClaw **ไม่** เปิดให้ใช้ `openai/gpt-5.3-codex-spark` บนเส้นทาง direct API คำขอ OpenAI API จริงจะปฏิเสธโมเดลนั้น Spark ใช้งานได้เฉพาะกับ Codex เท่านั้น
|
||||
</Warning>
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="การสมัครใช้งาน Codex">
|
||||
**เหมาะที่สุดสำหรับ:** การใช้การสมัครใช้งาน ChatGPT/Codex ของคุณแทน API key แยกต่างหาก Codex cloud ต้องใช้การลงชื่อเข้าใช้ ChatGPT
|
||||
**เหมาะสำหรับ:** ใช้การสมัครใช้งาน ChatGPT/Codex ของคุณแทนคีย์ API แยกต่างหาก Codex cloud ต้องใช้การลงชื่อเข้าใช้ ChatGPT
|
||||
|
||||
<Steps>
|
||||
<Step title="รัน Codex OAuth">
|
||||
<Step title="เรียกใช้ Codex OAuth">
|
||||
```bash
|
||||
openclaw onboard --auth-choice openai-codex
|
||||
```
|
||||
|
||||
หรือรัน OAuth โดยตรง:
|
||||
หรือเรียกใช้ OAuth โดยตรง:
|
||||
|
||||
```bash
|
||||
openclaw models auth login --provider openai-codex
|
||||
```
|
||||
|
||||
สำหรับการตั้งค่าแบบ headless หรือสภาพแวดล้อมที่ไม่เหมาะกับ callback ให้เพิ่ม `--device-code` เพื่อเข้าสู่ระบบด้วยโฟลว์ device-code ของ ChatGPT แทน callback ผ่านเบราว์เซอร์บน localhost:
|
||||
สำหรับการตั้งค่าแบบ headless หรือแบบที่ไม่เหมาะกับ callback ให้เพิ่ม `--device-code` เพื่อลงชื่อเข้าใช้ด้วยโฟลว์ device-code ของ ChatGPT แทน localhost browser callback:
|
||||
|
||||
```bash
|
||||
openclaw models auth login --provider openai-codex --device-code
|
||||
@ -135,7 +135,7 @@ x-i18n:
|
||||
| `openai-codex/gpt-5.3-codex-spark` | ChatGPT/Codex OAuth | การลงชื่อเข้าใช้ Codex (ขึ้นอยู่กับ entitlement) |
|
||||
|
||||
<Note>
|
||||
เส้นทางนี้ถูกแยกจาก `openai/gpt-5.4` โดยเจตนา ใช้ `openai/*` กับ API key สำหรับการเข้าถึง Platform โดยตรง และใช้ `openai-codex/*` สำหรับการเข้าถึงผ่านการสมัครใช้งาน Codex
|
||||
เส้นทางนี้แยกจาก `openai/gpt-5.4` โดยตั้งใจ ใช้ `openai/*` กับคีย์ API สำหรับการเข้าถึง Platform โดยตรง และใช้ `openai-codex/*` สำหรับการเข้าถึงผ่านการสมัครใช้งาน Codex
|
||||
</Note>
|
||||
|
||||
### ตัวอย่าง config
|
||||
@ -147,19 +147,19 @@ x-i18n:
|
||||
```
|
||||
|
||||
<Note>
|
||||
Onboarding จะไม่นำเข้า OAuth material จาก `~/.codex` อีกต่อไป ให้ลงชื่อเข้าใช้ด้วย browser OAuth (ค่าเริ่มต้น) หรือโฟลว์ device-code ด้านบน — OpenClaw จะจัดการข้อมูลรับรองที่ได้ไว้ในที่เก็บ auth ของเอเจนต์ของตัวเอง
|
||||
Onboarding จะไม่ import ข้อมูล OAuth จาก `~/.codex` อีกต่อไป ให้ลงชื่อเข้าใช้ด้วย browser OAuth (ค่าเริ่มต้น) หรือโฟลว์ device-code ด้านบน — OpenClaw จะจัดการข้อมูลรับรองที่ได้ในที่เก็บการยืนยันตัวตนของเอเจนต์ของตัวเอง
|
||||
</Note>
|
||||
|
||||
### ขีดจำกัด context window
|
||||
### เพดาน context window
|
||||
|
||||
OpenClaw ถือว่าข้อมูลเมตาของโมเดลและเพดาน context ของรันไทม์เป็นคนละค่า
|
||||
OpenClaw จัดการข้อมูลเมตาของโมเดลและเพดาน context ระหว่างรันไทม์เป็นคนละค่า
|
||||
|
||||
สำหรับ `openai-codex/gpt-5.4`:
|
||||
|
||||
- `contextWindow` แบบ native: `1050000`
|
||||
- เพดาน `contextTokens` ของรันไทม์โดยค่าเริ่มต้น: `272000`
|
||||
- `contextWindow` แบบเนทีฟ: `1050000`
|
||||
- เพดาน `contextTokens` ระหว่างรันไทม์เริ่มต้น: `272000`
|
||||
|
||||
เพดานค่าเริ่มต้นที่เล็กกว่านี้ให้ latency และคุณภาพที่ดีกว่าในทางปฏิบัติ คุณสามารถ override ได้ด้วย `contextTokens`:
|
||||
เพดานเริ่มต้นที่เล็กกว่านี้ให้คุณลักษณะด้านเวลาแฝงและคุณภาพที่ดีกว่าในทางปฏิบัติ แทนที่ค่าได้ด้วย `contextTokens`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -174,22 +174,22 @@ x-i18n:
|
||||
```
|
||||
|
||||
<Note>
|
||||
ใช้ `contextWindow` เพื่อประกาศข้อมูลเมตา native ของโมเดล ใช้ `contextTokens` เพื่อจำกัดงบประมาณ context ของรันไทม์
|
||||
ใช้ `contextWindow` เพื่อประกาศข้อมูลเมตาเนทีฟของโมเดล ใช้ `contextTokens` เพื่อจำกัดงบประมาณ context ระหว่างรันไทม์
|
||||
</Note>
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## การสร้างรูปภาพ
|
||||
## การสร้างภาพ
|
||||
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียนการสร้างรูปภาพผ่านเครื่องมือ `image_generate`
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนการสร้างภาพผ่านเครื่องมือ `image_generate`
|
||||
|
||||
| ความสามารถ | ค่า |
|
||||
| ----------------------- | ---------------------------------- |
|
||||
| โมเดลเริ่มต้น | `openai/gpt-image-2` |
|
||||
| จำนวนรูปสูงสุดต่อคำขอ | 4 |
|
||||
| โหมดแก้ไข | เปิดใช้ (สูงสุด 5 รูปอ้างอิง) |
|
||||
| การ override ขนาด | รองรับ รวมถึงขนาด 2K/4K |
|
||||
| ความสามารถ | ค่า |
|
||||
| ------------------------- | ---------------------------------- |
|
||||
| โมเดลเริ่มต้น | `openai/gpt-image-2` |
|
||||
| จำนวนภาพสูงสุดต่อคำขอ | 4 |
|
||||
| โหมดแก้ไข | เปิดใช้งาน (อ้างอิงภาพได้สูงสุด 5 ภาพ) |
|
||||
| การแทนที่ขนาด | รองรับ รวมถึงขนาด 2K/4K |
|
||||
| อัตราส่วนภาพ / ความละเอียด | ไม่ส่งต่อไปยัง OpenAI Images API |
|
||||
|
||||
```json5
|
||||
@ -203,36 +203,34 @@ plugin `openai` ที่มากับระบบจะลงทะเบี
|
||||
```
|
||||
|
||||
<Note>
|
||||
ดู [การสร้างรูปภาพ](/th/tools/image-generation) สำหรับพารามิเตอร์เครื่องมือแบบใช้ร่วมกัน การเลือก provider และพฤติกรรม failover
|
||||
ดู [การสร้างภาพ](/th/tools/image-generation) สำหรับพารามิเตอร์เครื่องมือที่ใช้ร่วมกัน การเลือก provider และพฤติกรรม failover
|
||||
</Note>
|
||||
|
||||
`gpt-image-2` เป็นค่าเริ่มต้นทั้งสำหรับการสร้างภาพจากข้อความของ OpenAI และการ
|
||||
แก้ไขรูปภาพ `gpt-image-1` ยังสามารถใช้ได้ในฐานะการ override โมเดลแบบ explicit แต่
|
||||
เวิร์กโฟลว์รูปภาพใหม่ของ OpenAI ควรใช้ `openai/gpt-image-2`
|
||||
`gpt-image-2` เป็นค่าเริ่มต้นสำหรับทั้งการสร้างภาพจากข้อความของ OpenAI และการแก้ไขภาพ ส่วน `gpt-image-1` ยังคงใช้งานได้เมื่อระบุเป็นการแทนที่โมเดลแบบชัดเจน แต่เวิร์กโฟลว์ภาพใหม่ของ OpenAI ควรใช้ `openai/gpt-image-2`
|
||||
|
||||
สร้าง:
|
||||
|
||||
```
|
||||
/tool image_generate model=openai/gpt-image-2 prompt="A polished launch poster for OpenClaw on macOS" size=3840x2160 count=1
|
||||
/tool image_generate model=openai/gpt-image-2 prompt="โปสเตอร์เปิดตัว OpenClaw บน macOS ที่ดูประณีต" size=3840x2160 count=1
|
||||
```
|
||||
|
||||
แก้ไข:
|
||||
|
||||
```
|
||||
/tool image_generate model=openai/gpt-image-2 prompt="Preserve the object shape, change the material to translucent glass" image=/path/to/reference.png size=1024x1536
|
||||
/tool image_generate model=openai/gpt-image-2 prompt="คงรูปทรงของวัตถุไว้ เปลี่ยนวัสดุเป็นกระจกโปร่งแสง" image=/path/to/reference.png size=1024x1536
|
||||
```
|
||||
|
||||
## การสร้างวิดีโอ
|
||||
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียนการสร้างวิดีโอผ่านเครื่องมือ `video_generate`
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนการสร้างวิดีโอผ่านเครื่องมือ `video_generate`
|
||||
|
||||
| ความสามารถ | ค่า |
|
||||
| ------------------ | --------------------------------------------------------------------------------- |
|
||||
| โมเดลเริ่มต้น | `openai/sora-2` |
|
||||
| โหมด | ข้อความเป็นวิดีโอ, รูปภาพเป็นวิดีโอ, แก้ไขวิดีโอเดี่ยว |
|
||||
| อินพุตอ้างอิง | 1 รูปภาพ หรือ 1 วิดีโอ |
|
||||
| การ override ขนาด | รองรับ |
|
||||
| การ override อื่น ๆ | `aspectRatio`, `resolution`, `audio`, `watermark` จะถูกเพิกเฉยพร้อมคำเตือนจากเครื่องมือ |
|
||||
| ความสามารถ | ค่า |
|
||||
| ---------------- | --------------------------------------------------------------------------------- |
|
||||
| โมเดลเริ่มต้น | `openai/sora-2` |
|
||||
| โหมด | ข้อความเป็นวิดีโอ, ภาพเป็นวิดีโอ, แก้ไขวิดีโอเดี่ยว |
|
||||
| อินพุตอ้างอิง | 1 ภาพ หรือ 1 วิดีโอ |
|
||||
| การแทนที่ขนาด | รองรับ |
|
||||
| การแทนที่อื่นๆ | `aspectRatio`, `resolution`, `audio`, `watermark` จะถูกละเว้นพร้อมคำเตือนจากเครื่องมือ |
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -245,22 +243,22 @@ plugin `openai` ที่มากับระบบจะลงทะเบี
|
||||
```
|
||||
|
||||
<Note>
|
||||
ดู [การสร้างวิดีโอ](/th/tools/video-generation) สำหรับพารามิเตอร์เครื่องมือแบบใช้ร่วมกัน การเลือก provider และพฤติกรรม failover
|
||||
ดู [การสร้างวิดีโอ](/th/tools/video-generation) สำหรับพารามิเตอร์เครื่องมือที่ใช้ร่วมกัน การเลือก provider และพฤติกรรม failover
|
||||
</Note>
|
||||
|
||||
## ส่วนเสริมพรอมป์ต GPT-5
|
||||
## การเพิ่มพรอมป์สำหรับ GPT-5
|
||||
|
||||
OpenClaw เพิ่มส่วนเสริมพรอมป์ต GPT-5 แบบใช้ร่วมกันสำหรับการรันตระกูล GPT-5 ข้าม providers โดยจะใช้ตาม model id ดังนั้น `openai/gpt-5.4`, `openai-codex/gpt-5.4`, `openrouter/openai/gpt-5.4`, `opencode/gpt-5.4` และ GPT-5 refs อื่นที่เข้ากันได้จะได้รับ overlay เดียวกัน ส่วนโมเดล GPT-4.x รุ่นเก่าจะไม่ได้รับ
|
||||
OpenClaw เพิ่มการเพิ่มพรอมป์ GPT-5 ที่ใช้ร่วมกันสำหรับการรันตระกูล GPT-5 ข้าม providers โดยจะนำไปใช้ตาม id ของโมเดล ดังนั้น `openai/gpt-5.4`, `openai-codex/gpt-5.4`, `openrouter/openai/gpt-5.4`, `opencode/gpt-5.4` และ ref ของ GPT-5 ที่เข้ากันได้อื่นๆ จะได้รับ overlay เดียวกัน ส่วนโมเดล GPT-4.x รุ่นเก่าจะไม่ได้รับ
|
||||
|
||||
provider harness Codex แบบ native ที่มากับระบบ (`codex/*`) ใช้พฤติกรรม GPT-5 และ Heartbeat overlay เดียวกันผ่านคำสั่งสำหรับนักพัฒนาใน Codex app-server ดังนั้นเซสชัน `codex/gpt-5.x` จะคงการติดตามงานต่อและแนวทาง Heartbeat เชิงรุกแบบเดียวกัน แม้ว่า Codex จะเป็นเจ้าของพรอมป์ตส่วนที่เหลือของ harness
|
||||
provider native Codex harness (`codex/*`) ที่มาพร้อมกันใช้พฤติกรรม GPT-5 เดียวกันและ Heartbeat overlay ผ่านคำสั่งนักพัฒนาใน Codex app-server ดังนั้นเซสชัน `codex/gpt-5.x` จะยังคงมีแนวทางการติดตามงานต่อเนื่องและ Heartbeat เชิงรุกแบบเดียวกัน แม้ว่า Codex จะเป็นผู้ควบคุมพรอมป์ส่วนที่เหลือของ harness
|
||||
|
||||
ส่วนเสริม GPT-5 จะเพิ่มสัญญาพฤติกรรมแบบมีแท็กสำหรับการคง persona ความปลอดภัยในการรัน วินัยการใช้เครื่องมือ รูปแบบผลลัพธ์ การตรวจสอบความเสร็จสมบูรณ์ และการตรวจสอบยืนยัน พฤติกรรมการตอบกลับและข้อความเงียบที่เฉพาะกับ channel ยังคงอยู่ใน system prompt แบบใช้ร่วมกันของ OpenClaw และนโยบายการส่งขาออก แนวทาง GPT-5 จะเปิดใช้งานเสมอสำหรับโมเดลที่ตรงกัน ส่วนเลเยอร์รูปแบบการโต้ตอบที่เป็นมิตรนั้นแยกออกมาและกำหนดค่าได้
|
||||
การเพิ่มพรอมป์ GPT-5 จะเพิ่มสัญญาพฤติกรรมแบบติดแท็กสำหรับการคงบุคลิก การทำงานอย่างปลอดภัย วินัยในการใช้เครื่องมือ รูปแบบผลลัพธ์ การตรวจสอบความสมบูรณ์ และการยืนยันผล พฤติกรรมการตอบกลับและข้อความเงียบที่เฉพาะกับช่องทางยังคงอยู่ใน system prompt ที่ใช้ร่วมกันของ OpenClaw และนโยบายการส่งออกข้อความ การแนะนำสำหรับ GPT-5 จะเปิดใช้งานเสมอสำหรับโมเดลที่ตรงกัน ส่วนเลเยอร์รูปแบบการโต้ตอบแบบเป็นมิตรนั้นแยกออกมาต่างหากและกำหนดค่าได้
|
||||
|
||||
| ค่า | ผลลัพธ์ |
|
||||
| ค่า | ผลลัพธ์ |
|
||||
| ---------------------- | ------------------------------------------- |
|
||||
| `"friendly"` (ค่าเริ่มต้น) | เปิดใช้เลเยอร์รูปแบบการโต้ตอบที่เป็นมิตร |
|
||||
| `"on"` | alias ของ `"friendly"` |
|
||||
| `"off"` | ปิดเฉพาะเลเยอร์รูปแบบที่เป็นมิตร |
|
||||
| `"friendly"` (ค่าเริ่มต้น) | เปิดใช้เลเยอร์รูปแบบการโต้ตอบแบบเป็นมิตร |
|
||||
| `"on"` | ชื่อแทนของ `"friendly"` |
|
||||
| `"off"` | ปิดเฉพาะเลเยอร์สไตล์แบบเป็นมิตร |
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Config">
|
||||
@ -284,27 +282,27 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
</Tabs>
|
||||
|
||||
<Tip>
|
||||
ค่าต่าง ๆ ไม่สนใจตัวพิมพ์เล็กใหญ่ในรันไทม์ ดังนั้น `"Off"` และ `"off"` จะปิดเลเยอร์รูปแบบที่เป็นมิตรเหมือนกัน
|
||||
ค่าต่างๆ ไม่สนตัวพิมพ์เล็ก-ใหญ่ในระหว่างรันไทม์ ดังนั้นทั้ง `"Off"` และ `"off"` จะปิดเลเยอร์สไตล์แบบเป็นมิตร
|
||||
</Tip>
|
||||
|
||||
<Note>
|
||||
`plugins.entries.openai.config.personality` แบบเดิมยังคงถูกอ่านในฐานะ compatibility fallback เมื่อไม่ได้ตั้งค่าร่วม `agents.defaults.promptOverlays.gpt5.personality`
|
||||
ระบบยังคงอ่าน `plugins.entries.openai.config.personality` แบบเดิมเป็น fallback เพื่อความเข้ากันได้ เมื่อไม่ได้ตั้งค่า `agents.defaults.promptOverlays.gpt5.personality` ที่ใช้ร่วมกัน
|
||||
</Note>
|
||||
|
||||
## เสียงและสุนทรพจน์
|
||||
## เสียงและคำพูด
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="การสังเคราะห์เสียงพูด (TTS)">
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียนการสังเคราะห์เสียงพูดสำหรับพื้นผิว `messages.tts`
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนการสังเคราะห์เสียงพูดสำหรับพื้นที่ `messages.tts`
|
||||
|
||||
| Setting | Path config | ค่าเริ่มต้น |
|
||||
|---------|------------|-------------|
|
||||
| Model | `messages.tts.providers.openai.model` | `gpt-4o-mini-tts` |
|
||||
| Voice | `messages.tts.providers.openai.voice` | `coral` |
|
||||
| Speed | `messages.tts.providers.openai.speed` | (ไม่ตั้งค่า) |
|
||||
| Instructions | `messages.tts.providers.openai.instructions` | (ไม่ตั้งค่า, เฉพาะ `gpt-4o-mini-tts`) |
|
||||
| Format | `messages.tts.providers.openai.responseFormat` | `opus` สำหรับ voice notes, `mp3` สำหรับไฟล์ |
|
||||
| API key | `messages.tts.providers.openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
| การตั้งค่า | เส้นทาง config | ค่าเริ่มต้น |
|
||||
|---------|------------|---------|
|
||||
| โมเดล | `messages.tts.providers.openai.model` | `gpt-4o-mini-tts` |
|
||||
| เสียง | `messages.tts.providers.openai.voice` | `coral` |
|
||||
| ความเร็ว | `messages.tts.providers.openai.speed` | (ไม่ได้ตั้งค่า) |
|
||||
| คำสั่ง | `messages.tts.providers.openai.instructions` | (ไม่ได้ตั้งค่า, เฉพาะ `gpt-4o-mini-tts`) |
|
||||
| รูปแบบ | `messages.tts.providers.openai.responseFormat` | `opus` สำหรับบันทึกเสียง, `mp3` สำหรับไฟล์ |
|
||||
| คีย์ API | `messages.tts.providers.openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
| Base URL | `messages.tts.providers.openai.baseUrl` | `https://api.openai.com/v1` |
|
||||
|
||||
โมเดลที่ใช้ได้: `gpt-4o-mini-tts`, `tts-1`, `tts-1-hd` เสียงที่ใช้ได้: `alloy`, `ash`, `ballad`, `cedar`, `coral`, `echo`, `fable`, `juniper`, `marin`, `onyx`, `nova`, `sage`, `shimmer`, `verse`
|
||||
@ -322,22 +320,23 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
```
|
||||
|
||||
<Note>
|
||||
ตั้งค่า `OPENAI_TTS_BASE_URL` เพื่อ override TTS base URL โดยไม่กระทบ endpoint ของ chat API
|
||||
ตั้งค่า `OPENAI_TTS_BASE_URL` เพื่อแทนที่ TTS base URL โดยไม่กระทบ endpoint ของ chat API
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Speech-to-text">
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียน speech-to-text แบบแบตช์ผ่าน
|
||||
พื้นผิวการถอดเสียงของ media-understanding ใน OpenClaw
|
||||
<Accordion title="การแปลงเสียงเป็นข้อความ">
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนการแปลงเสียงเป็นข้อความแบบแบตช์ผ่าน
|
||||
พื้นที่การถอดเสียง media-understanding ของ OpenClaw
|
||||
|
||||
- โมเดลเริ่มต้น: `gpt-4o-transcribe`
|
||||
- Endpoint: OpenAI REST `/v1/audio/transcriptions`
|
||||
- เส้นทางอินพุต: การอัปโหลดไฟล์เสียงแบบ multipart
|
||||
- รองรับใน OpenClaw ทุกที่ที่การถอดเสียงเสียงขาเข้าใช้
|
||||
`tools.media.audio` รวมถึงเซกเมนต์ voice-channel ของ Discord และไฟล์แนบเสียงของ channel
|
||||
- เส้นทางอินพุต: อัปโหลดไฟล์เสียงแบบ multipart
|
||||
- รองรับโดย OpenClaw ในทุกที่ที่การถอดเสียงจากเสียงขาเข้าใช้
|
||||
`tools.media.audio` รวมถึงส่วนเสียงของช่องเสียง Discord และ
|
||||
ไฟล์แนบเสียงของช่องทางต่างๆ
|
||||
|
||||
หากต้องการบังคับใช้ OpenAI สำหรับการถอดเสียงเสียงขาเข้า:
|
||||
หากต้องการบังคับใช้ OpenAI สำหรับการถอดเสียงจากเสียงขาเข้า:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -357,40 +356,40 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
}
|
||||
```
|
||||
|
||||
คำใบ้ภาษาและพรอมป์ตจะถูกส่งต่อไปยัง OpenAI เมื่อมีการระบุจาก
|
||||
config สื่อเสียงแบบใช้ร่วมกันหรือคำขอถอดเสียงรายครั้ง
|
||||
คำใบ้ด้านภาษาและพรอมป์จะถูกส่งต่อไปยัง OpenAI เมื่อมีการระบุผ่าน
|
||||
config เสียงมีเดียที่ใช้ร่วมกัน หรือคำขอถอดเสียงรายครั้ง
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Realtime transcription">
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียนการถอดเสียงแบบเรียลไทม์สำหรับ Voice Call plugin
|
||||
<Accordion title="การถอดเสียงแบบเรียลไทม์">
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนการถอดเสียงแบบเรียลไทม์สำหรับ Plugin Voice Call
|
||||
|
||||
| Setting | Path config | ค่าเริ่มต้น |
|
||||
|---------|------------|-------------|
|
||||
| Model | `plugins.entries.voice-call.config.streaming.providers.openai.model` | `gpt-4o-transcribe` |
|
||||
| Language | `...openai.language` | (ไม่ตั้งค่า) |
|
||||
| Prompt | `...openai.prompt` | (ไม่ตั้งค่า) |
|
||||
| Silence duration | `...openai.silenceDurationMs` | `800` |
|
||||
| VAD threshold | `...openai.vadThreshold` | `0.5` |
|
||||
| API key | `...openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
| การตั้งค่า | เส้นทาง config | ค่าเริ่มต้น |
|
||||
|---------|------------|---------|
|
||||
| โมเดล | `plugins.entries.voice-call.config.streaming.providers.openai.model` | `gpt-4o-transcribe` |
|
||||
| ภาษา | `...openai.language` | (ไม่ได้ตั้งค่า) |
|
||||
| พรอมป์ | `...openai.prompt` | (ไม่ได้ตั้งค่า) |
|
||||
| ระยะเวลาความเงียบ | `...openai.silenceDurationMs` | `800` |
|
||||
| ค่า VAD threshold | `...openai.vadThreshold` | `0.5` |
|
||||
| คีย์ API | `...openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
|
||||
<Note>
|
||||
ใช้การเชื่อมต่อ WebSocket ไปยัง `wss://api.openai.com/v1/realtime` พร้อมเสียง G.711 u-law (`g711_ulaw` / `audio/pcmu`) streaming provider นี้มีไว้สำหรับเส้นทางการถอดเสียงแบบเรียลไทม์ของ Voice Call; ขณะนี้เสียง Discord ยังบันทึกเป็นเซกเมนต์สั้น ๆ และใช้เส้นทางการถอดเสียงแบบแบตช์ `tools.media.audio` แทน
|
||||
ใช้การเชื่อมต่อ WebSocket ไปยัง `wss://api.openai.com/v1/realtime` พร้อมเสียงรูปแบบ G.711 u-law (`g711_ulaw` / `audio/pcmu`) provider การสตรีมนี้ใช้สำหรับเส้นทางการถอดเสียงแบบเรียลไทม์ของ Voice Call ส่วน Discord voice ในปัจจุบันจะบันทึกเป็นช่วงสั้นๆ และใช้เส้นทางการถอดเสียงแบบแบตช์ `tools.media.audio` แทน
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Realtime voice">
|
||||
plugin `openai` ที่มากับระบบจะลงทะเบียนเสียงแบบเรียลไทม์สำหรับ Voice Call plugin
|
||||
<Accordion title="เสียงแบบเรียลไทม์">
|
||||
Plugin `openai` ที่มาพร้อมกันจะลงทะเบียนเสียงแบบเรียลไทม์สำหรับ Plugin Voice Call
|
||||
|
||||
| Setting | Path config | ค่าเริ่มต้น |
|
||||
|---------|------------|-------------|
|
||||
| Model | `plugins.entries.voice-call.config.realtime.providers.openai.model` | `gpt-realtime` |
|
||||
| Voice | `...openai.voice` | `alloy` |
|
||||
| การตั้งค่า | เส้นทาง config | ค่าเริ่มต้น |
|
||||
|---------|------------|---------|
|
||||
| โมเดล | `plugins.entries.voice-call.config.realtime.providers.openai.model` | `gpt-realtime` |
|
||||
| เสียง | `...openai.voice` | `alloy` |
|
||||
| Temperature | `...openai.temperature` | `0.8` |
|
||||
| VAD threshold | `...openai.vadThreshold` | `0.5` |
|
||||
| Silence duration | `...openai.silenceDurationMs` | `500` |
|
||||
| API key | `...openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
| ค่า VAD threshold | `...openai.vadThreshold` | `0.5` |
|
||||
| ระยะเวลาความเงียบ | `...openai.silenceDurationMs` | `500` |
|
||||
| คีย์ API | `...openai.apiKey` | fallback ไปที่ `OPENAI_API_KEY` |
|
||||
|
||||
<Note>
|
||||
รองรับ Azure OpenAI ผ่านคีย์ config `azureEndpoint` และ `azureDeployment` รองรับการเรียกใช้เครื่องมือแบบสองทิศทาง ใช้รูปแบบเสียง G.711 u-law
|
||||
@ -399,23 +398,148 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## endpoint ของ Azure OpenAI
|
||||
|
||||
provider `openai` ที่มาพร้อมกันสามารถกำหนดเป้าหมายไปยัง resource ของ Azure OpenAI สำหรับการสร้างภาพ
|
||||
ได้โดยการแทนที่ base URL ในเส้นทางการสร้างภาพ OpenClaw
|
||||
จะตรวจจับ hostname ของ Azure บน `models.providers.openai.baseUrl` และสลับไปใช้
|
||||
รูปแบบคำขอของ Azure โดยอัตโนมัติ
|
||||
|
||||
<Note>
|
||||
เสียงแบบเรียลไทม์ใช้เส้นทาง config แยกต่างหาก
|
||||
(`plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint`)
|
||||
และไม่ได้รับผลจาก `models.providers.openai.baseUrl` โปรดดูหัวข้อ **เสียงแบบเรียลไทม์**
|
||||
ใต้ [เสียงและคำพูด](#voice-and-speech) สำหรับการตั้งค่า Azure ของฟีเจอร์นี้
|
||||
</Note>
|
||||
|
||||
ใช้ Azure OpenAI เมื่อ:
|
||||
|
||||
- คุณมีการสมัครใช้งาน Azure OpenAI, quota หรือข้อตกลงระดับองค์กรอยู่แล้ว
|
||||
- คุณต้องการการคงอยู่ของข้อมูลตามภูมิภาคหรือการควบคุมด้าน compliance ที่ Azure มีให้
|
||||
- คุณต้องการให้ทราฟฟิกอยู่ภายใน tenancy ของ Azure ที่มีอยู่เดิม
|
||||
|
||||
### การกำหนดค่า
|
||||
|
||||
สำหรับการสร้างภาพผ่าน Azure โดยใช้ provider `openai` ที่มาพร้อมกัน ให้ชี้
|
||||
`models.providers.openai.baseUrl` ไปที่ resource Azure ของคุณ และตั้งค่า `apiKey` เป็น
|
||||
คีย์ Azure OpenAI (ไม่ใช่คีย์ OpenAI Platform):
|
||||
|
||||
```json5
|
||||
{
|
||||
models: {
|
||||
providers: {
|
||||
openai: {
|
||||
baseUrl: "https://<your-resource>.openai.azure.com",
|
||||
apiKey: "<azure-openai-api-key>",
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
OpenClaw รู้จัก suffix ของโฮสต์ Azure เหล่านี้สำหรับเส้นทางการสร้างภาพบน Azure:
|
||||
|
||||
- `*.openai.azure.com`
|
||||
- `*.services.ai.azure.com`
|
||||
- `*.cognitiveservices.azure.com`
|
||||
|
||||
สำหรับคำขอสร้างภาพบนโฮสต์ Azure ที่ระบบรู้จัก OpenClaw จะ:
|
||||
|
||||
- ส่ง header `api-key` แทน `Authorization: Bearer`
|
||||
- ใช้เส้นทางแบบ deployment-scoped (`/openai/deployments/{deployment}/...`)
|
||||
- ต่อท้าย `?api-version=...` ในแต่ละคำขอ
|
||||
|
||||
base URL อื่นๆ (OpenAI สาธารณะ, proxy ที่เข้ากันได้กับ OpenAI) จะยังคงใช้
|
||||
รูปแบบคำขอภาพมาตรฐานของ OpenAI
|
||||
|
||||
<Note>
|
||||
การกำหนดเส้นทาง Azure สำหรับเส้นทางการสร้างภาพของ provider `openai`
|
||||
ต้องใช้ OpenClaw 2026.4.22 หรือใหม่กว่า เวอร์ชันก่อนหน้านั้นจะมองว่า
|
||||
`openai.baseUrl` แบบกำหนดเองทั้งหมดเป็น endpoint สาธารณะของ OpenAI และจะล้มเหลวกับ deployment
|
||||
ภาพบน Azure
|
||||
</Note>
|
||||
|
||||
### เวอร์ชัน API
|
||||
|
||||
ตั้งค่า `AZURE_OPENAI_API_VERSION` เพื่อปักหมุดเวอร์ชัน preview หรือ GA ของ Azure แบบเฉพาะ
|
||||
สำหรับเส้นทางการสร้างภาพบน Azure:
|
||||
|
||||
```bash
|
||||
export AZURE_OPENAI_API_VERSION="2024-12-01-preview"
|
||||
```
|
||||
|
||||
ค่าเริ่มต้นคือ `2024-12-01-preview` เมื่อไม่ได้ตั้งค่าตัวแปรนี้
|
||||
|
||||
### ชื่อโมเดลคือชื่อ deployment
|
||||
|
||||
Azure OpenAI ผูกโมเดลเข้ากับ deployment สำหรับคำขอสร้างภาพบน Azure
|
||||
ที่ถูกกำหนดเส้นทางผ่าน provider `openai` ที่มาพร้อมกัน ฟิลด์ `model` ใน OpenClaw
|
||||
ต้องเป็น **ชื่อ deployment ของ Azure** ที่คุณกำหนดในพอร์ทัล Azure ไม่ใช่
|
||||
id โมเดลสาธารณะของ OpenAI
|
||||
|
||||
หากคุณสร้าง deployment ชื่อ `gpt-image-2-prod` ที่ให้บริการ `gpt-image-2`:
|
||||
|
||||
```
|
||||
/tool image_generate model=openai/gpt-image-2-prod prompt="โปสเตอร์ที่สะอาดตา" size=1024x1024 count=1
|
||||
```
|
||||
|
||||
กฎเรื่องชื่อ deployment เดียวกันนี้ใช้กับการเรียกสร้างภาพ
|
||||
ที่ถูกกำหนดเส้นทางผ่าน provider `openai` ที่มาพร้อมกันเช่นกัน
|
||||
|
||||
### ความพร้อมใช้งานตามภูมิภาค
|
||||
|
||||
ปัจจุบันการสร้างภาพบน Azure ใช้งานได้เฉพาะในบางภูมิภาคเท่านั้น
|
||||
(เช่น `eastus2`, `swedencentral`, `polandcentral`, `westus3`,
|
||||
`uaenorth`) โปรดตรวจสอบรายการภูมิภาคล่าสุดของ Microsoft ก่อนสร้าง
|
||||
deployment และยืนยันว่าโมเดลที่ต้องการมีให้ใช้ในภูมิภาคของคุณ
|
||||
|
||||
### ความแตกต่างของพารามิเตอร์
|
||||
|
||||
Azure OpenAI และ OpenAI สาธารณะไม่ได้ยอมรับพารามิเตอร์ภาพเหมือนกันเสมอไป
|
||||
Azure อาจปฏิเสธตัวเลือกที่ OpenAI สาธารณะยอมรับได้ (เช่นค่า `background`
|
||||
บางค่าใน `gpt-image-2`) หรือเปิดให้ใช้ได้เฉพาะในบางเวอร์ชันของโมเดลเท่านั้น
|
||||
ความแตกต่างเหล่านี้มาจาก Azure และโมเดลพื้นฐาน ไม่ใช่ OpenClaw
|
||||
หากคำขอ Azure ล้มเหลวด้วยข้อผิดพลาดการตรวจสอบความถูกต้อง ให้ตรวจสอบ
|
||||
ชุดพารามิเตอร์ที่ deployment และเวอร์ชัน API เฉพาะของคุณรองรับใน
|
||||
พอร์ทัล Azure
|
||||
|
||||
<Note>
|
||||
Azure OpenAI ใช้การขนส่งแบบเนทีฟและพฤติกรรม compat แต่จะไม่ได้รับ
|
||||
header attribution แบบซ่อนของ OpenClaw โปรดดูหัวข้อ **เส้นทางแบบเนทีฟเทียบกับแบบเข้ากันได้กับ OpenAI**
|
||||
ใต้ [การกำหนดค่าขั้นสูง](#advanced-configuration)
|
||||
สำหรับรายละเอียด
|
||||
</Note>
|
||||
|
||||
<Tip>
|
||||
สำหรับ provider Azure OpenAI Responses แบบแยกต่างหาก (ต่างจาก provider `openai`)
|
||||
โปรดดู model ref `azure-openai-responses/*` ในหัวข้อ
|
||||
[Compaction ฝั่งเซิร์ฟเวอร์](#server-side-compaction-responses-api)
|
||||
</Tip>
|
||||
|
||||
<Note>
|
||||
ทราฟฟิก Azure chat และ Responses ต้องใช้ config provider/API แบบเฉพาะของ Azure เพิ่มเติม
|
||||
นอกเหนือจากการแทนที่ base URL หากคุณต้องการเรียกใช้โมเดล Azure นอกเหนือจากการ
|
||||
สร้างภาพ ให้ใช้โฟลว์ onboarding หรือ config provider ที่ตั้งค่า
|
||||
รูปแบบ Azure API/auth ที่เหมาะสม แทนการสมมติว่า `openai.baseUrl` เพียงอย่างเดียวเพียงพอ
|
||||
</Note>
|
||||
|
||||
## การกำหนดค่าขั้นสูง
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Transport (WebSocket vs SSE)">
|
||||
OpenClaw ใช้ WebSocket-first พร้อม SSE fallback (`"auto"`) สำหรับทั้ง `openai/*` และ `openai-codex/*`
|
||||
<Accordion title="การขนส่ง (WebSocket เทียบกับ SSE)">
|
||||
OpenClaw ใช้ WebSocket ก่อน พร้อม fallback ไปยัง SSE (`"auto"`) สำหรับทั้ง `openai/*` และ `openai-codex/*`
|
||||
|
||||
ในโหมด `"auto"` OpenClaw จะ:
|
||||
- ลองใหม่หนึ่งครั้งเมื่อ WebSocket ล้มเหลวในช่วงต้น ก่อน fallback ไปใช้ SSE
|
||||
- หลังเกิดความล้มเหลว จะทำเครื่องหมายว่า WebSocket เสื่อมสภาพเป็นเวลาประมาณ 60 วินาที และใช้ SSE ระหว่างช่วง cool-down
|
||||
- แนบ headers ตัวตนของ session และ turn ที่เสถียรสำหรับการลองใหม่และการเชื่อมต่อใหม่
|
||||
- ปรับมาตรฐานตัวนับการใช้งาน (`input_tokens` / `prompt_tokens`) ข้าม transport แต่ละแบบ
|
||||
- ลองใหม่หนึ่งครั้งเมื่อ WebSocket ล้มเหลวในช่วงต้น ก่อน fallback ไปยัง SSE
|
||||
- หลังจากเกิดความล้มเหลว จะทำเครื่องหมายว่า WebSocket เสื่อมสภาพเป็นเวลาประมาณ 60 วินาที และใช้ SSE ระหว่างช่วง cool-down
|
||||
- แนบ header รหัสประจำเซสชันและเทิร์นที่คงที่สำหรับการลองใหม่และการเชื่อมต่อใหม่
|
||||
- ทำให้ตัวนับการใช้งาน (`input_tokens` / `prompt_tokens`) เป็นมาตรฐานเดียวกันข้ามรูปแบบการขนส่ง
|
||||
|
||||
| Value | พฤติกรรม |
|
||||
| ค่า | พฤติกรรม |
|
||||
|-------|----------|
|
||||
| `"auto"` (ค่าเริ่มต้น) | WebSocket ก่อน, fallback เป็น SSE |
|
||||
| `"sse"` | บังคับใช้ SSE เท่านั้น |
|
||||
| `"websocket"` | บังคับใช้ WebSocket เท่านั้น |
|
||||
| `"auto"` (ค่าเริ่มต้น) | ใช้ WebSocket ก่อน แล้ว fallback ไปยัง SSE |
|
||||
| `"sse"` | บังคับใช้เฉพาะ SSE |
|
||||
| `"websocket"` | บังคับใช้เฉพาะ WebSocket |
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -437,11 +561,11 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="WebSocket warm-up">
|
||||
OpenClaw เปิดใช้ WebSocket warm-up โดยค่าเริ่มต้นสำหรับ `openai/*` เพื่อลด latency ของเทิร์นแรก
|
||||
<Accordion title="การวอร์มอัป WebSocket">
|
||||
OpenClaw เปิดใช้การวอร์มอัป WebSocket โดยค่าเริ่มต้นสำหรับ `openai/*` เพื่อลดเวลาแฝงของเทิร์นแรก
|
||||
|
||||
```json5
|
||||
// ปิด warm-up
|
||||
// ปิดใช้งานการวอร์มอัป
|
||||
{
|
||||
agents: {
|
||||
defaults: {
|
||||
@ -459,13 +583,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
|
||||
<a id="openai-fast-mode"></a>
|
||||
|
||||
<Accordion title="Fast mode">
|
||||
OpenClaw เปิดเผยตัวสลับ fast mode แบบใช้ร่วมกันสำหรับทั้ง `openai/*` และ `openai-codex/*`:
|
||||
<Accordion title="โหมดเร็ว">
|
||||
OpenClaw เปิดให้ใช้สวิตช์โหมดเร็วแบบใช้ร่วมกันสำหรับทั้ง `openai/*` และ `openai-codex/*`:
|
||||
|
||||
- **Chat/UI:** `/fast status|on|off`
|
||||
- **แชต/UI:** `/fast status|on|off`
|
||||
- **Config:** `agents.defaults.models["<provider>/<model>"].params.fastMode`
|
||||
|
||||
เมื่อเปิดใช้ OpenClaw จะจับคู่ fast mode ไปยังการประมวลผลแบบ priority ของ OpenAI (`service_tier = "priority"`) ค่า `service_tier` ที่มีอยู่เดิมจะถูกรักษาไว้ และ fast mode จะไม่เขียนทับ `reasoning` หรือ `text.verbosity`
|
||||
เมื่อเปิดใช้งาน OpenClaw จะจับคู่โหมดเร็วเข้ากับการประมวลผลแบบ priority ของ OpenAI (`service_tier = "priority"`) โดยจะคงค่า `service_tier` เดิมไว้ และโหมดเร็วจะไม่เขียนทับ `reasoning` หรือ `text.verbosity`
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -481,13 +605,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
```
|
||||
|
||||
<Note>
|
||||
การ override ระดับ session มีลำดับความสำคัญเหนือ config การล้าง session override ใน Sessions UI จะทำให้ session กลับไปใช้ค่าเริ่มต้นที่กำหนดไว้
|
||||
การแทนที่ระดับเซสชันมีผลเหนือกว่า config การล้างการแทนที่ระดับเซสชันใน Sessions UI จะทำให้เซสชันกลับไปใช้ค่าเริ่มต้นที่กำหนดไว้
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Priority processing (service_tier)">
|
||||
API ของ OpenAI เปิดเผยการประมวลผลแบบ priority ผ่าน `service_tier` ตั้งค่าเป็นรายโมเดลใน OpenClaw ได้:
|
||||
<Accordion title="การประมวลผลแบบ priority (service_tier)">
|
||||
API ของ OpenAI เปิดให้ใช้การประมวลผลแบบ priority ผ่าน `service_tier` ตั้งค่าต่อโมเดลใน OpenClaw ได้ดังนี้:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -505,7 +629,7 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
ค่าที่รองรับ: `auto`, `default`, `flex`, `priority`
|
||||
|
||||
<Warning>
|
||||
`serviceTier` จะถูกส่งต่อเฉพาะไปยัง native OpenAI endpoints (`api.openai.com`) และ native Codex endpoints (`chatgpt.com/backend-api`) เท่านั้น หากคุณกำหนดเส้นทาง provider ใด provider หนึ่งผ่านพร็อกซี OpenClaw จะปล่อย `service_tier` ไว้โดยไม่แก้ไข
|
||||
`serviceTier` จะถูกส่งต่อเฉพาะไปยัง endpoint เนทีฟของ OpenAI (`api.openai.com`) และ endpoint เนทีฟของ Codex (`chatgpt.com/backend-api`) เท่านั้น หากคุณกำหนดเส้นทาง provider ใด provider หนึ่งผ่าน proxy OpenClaw จะไม่แตะต้อง `service_tier`
|
||||
</Warning>
|
||||
|
||||
</Accordion>
|
||||
@ -513,13 +637,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
<Accordion title="Compaction ฝั่งเซิร์ฟเวอร์ (Responses API)">
|
||||
สำหรับโมเดล OpenAI Responses โดยตรง (`openai/*` บน `api.openai.com`) OpenClaw จะเปิดใช้ Compaction ฝั่งเซิร์ฟเวอร์โดยอัตโนมัติ:
|
||||
|
||||
- บังคับ `store: true` (เว้นแต่ compat ของโมเดลจะตั้ง `supportsStore: false`)
|
||||
- บังคับ `store: true` (เว้นแต่ model compat จะตั้งค่า `supportsStore: false`)
|
||||
- แทรก `context_management: [{ type: "compaction", compact_threshold: ... }]`
|
||||
- ค่าเริ่มต้น `compact_threshold`: 70% ของ `contextWindow` (หรือ `80000` เมื่อไม่มีค่า)
|
||||
- `compact_threshold` เริ่มต้น: 70% ของ `contextWindow` (หรือ `80000` เมื่อไม่มีข้อมูล)
|
||||
|
||||
<Tabs>
|
||||
<Tab title="เปิดใช้แบบ explicit">
|
||||
มีประโยชน์สำหรับ endpoints ที่เข้ากันได้ เช่น Azure OpenAI Responses:
|
||||
<Tab title="เปิดใช้อย่างชัดเจน">
|
||||
มีประโยชน์สำหรับ endpoint ที่เข้ากันได้ เช่น Azure OpenAI Responses:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -535,7 +659,7 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="threshold แบบกำหนดเอง">
|
||||
<Tab title="เกณฑ์ที่กำหนดเอง">
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
@ -571,13 +695,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
</Tabs>
|
||||
|
||||
<Note>
|
||||
`responsesServerCompaction` ควบคุมเฉพาะการแทรก `context_management` เท่านั้น โมเดล OpenAI Responses โดยตรงยังคงบังคับ `store: true` เว้นแต่ compat จะตั้ง `supportsStore: false`
|
||||
`responsesServerCompaction` ควบคุมเฉพาะการแทรก `context_management` เท่านั้น โมเดล Direct OpenAI Responses จะยังคงบังคับ `store: true` เว้นแต่ compat จะตั้งค่า `supportsStore: false`
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="โหมด GPT แบบเอเจนต์เข้มงวด">
|
||||
สำหรับการรันตระกูล GPT-5 บน `openai/*` และ `openai-codex/*` OpenClaw สามารถใช้สัญญาการรันแบบฝังที่เข้มงวดยิ่งขึ้นได้:
|
||||
สำหรับการรันตระกูล GPT-5 บน `openai/*` และ `openai-codex/*` OpenClaw สามารถใช้สัญญาการทำงานแบบฝังตัวที่เข้มงวดยิ่งขึ้นได้:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -589,33 +713,33 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
}
|
||||
```
|
||||
|
||||
เมื่อใช้ `strict-agentic`, OpenClaw จะ:
|
||||
เมื่อใช้ `strict-agentic` OpenClaw จะ:
|
||||
- ไม่ถือว่าเทิร์นที่มีเพียงแผนเป็นความคืบหน้าที่สำเร็จอีกต่อไปเมื่อมีการกระทำผ่านเครื่องมือที่พร้อมใช้งาน
|
||||
- ลองเทิร์นใหม่พร้อมคำชี้นำให้ลงมือทันที
|
||||
- เปิดใช้ `update_plan` อัตโนมัติสำหรับงานที่มีสาระสำคัญ
|
||||
- แสดงสถานะ blocked แบบ explicit หากโมเดลยังคงวางแผนโดยไม่ลงมือทำ
|
||||
- ลองเทิร์นนั้นใหม่พร้อมคำชี้นำให้ลงมือทำทันที
|
||||
- เปิดใช้ `update_plan` โดยอัตโนมัติสำหรับงานที่มีสาระสำคัญ
|
||||
- แสดงสถานะถูกบล็อกอย่างชัดเจนหากโมเดลยังคงวางแผนโดยไม่ลงมือทำ
|
||||
|
||||
<Note>
|
||||
จำกัดเฉพาะการรันตระกูล GPT-5 ของ OpenAI และ Codex เท่านั้น providers อื่นและตระกูลโมเดลรุ่นเก่าจะยังคงใช้พฤติกรรมค่าเริ่มต้น
|
||||
จำกัดขอบเขตเฉพาะการรันตระกูล GPT-5 ของ OpenAI และ Codex เท่านั้น providers อื่นและตระกูลโมเดลที่เก่ากว่าจะยังคงใช้พฤติกรรมเริ่มต้น
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="เส้นทางแบบ native กับแบบ OpenAI-compatible">
|
||||
OpenClaw ปฏิบัติต่อ direct OpenAI, Codex และ Azure OpenAI endpoints แตกต่างจากพร็อกซี `/v1` แบบ OpenAI-compatible ทั่วไป:
|
||||
<Accordion title="เส้นทางแบบเนทีฟเทียบกับแบบเข้ากันได้กับ OpenAI">
|
||||
OpenClaw ปฏิบัติต่อ endpoint ของ OpenAI โดยตรง, Codex และ Azure OpenAI แตกต่างจาก proxy `/v1` แบบเข้ากันได้กับ OpenAI ทั่วไป:
|
||||
|
||||
**เส้นทางแบบ native** (`openai/*`, `openai-codex/*`, Azure OpenAI):
|
||||
- คง `reasoning: { effort: "none" }` ไว้เฉพาะสำหรับโมเดลที่รองรับ OpenAI `none` effort
|
||||
- ละเว้น disabled reasoning สำหรับโมเดลหรือพร็อกซีที่ปฏิเสธ `reasoning.effort: "none"`
|
||||
- ใช้ strict mode เป็นค่าเริ่มต้นสำหรับ schema ของเครื่องมือ
|
||||
- แนบ attribution headers แบบซ่อนบนโฮสต์ native ที่ยืนยันแล้วเท่านั้น
|
||||
- คงการจัดรูปคำขอเฉพาะของ OpenAI (`service_tier`, `store`, reasoning-compat, prompt-cache hints)
|
||||
**เส้นทางแบบเนทีฟ** (`openai/*`, `openai-codex/*`, Azure OpenAI):
|
||||
- คง `reasoning: { effort: "none" }` ไว้เฉพาะสำหรับโมเดลที่รองรับค่า effort แบบ OpenAI `none`
|
||||
- ละเว้น reasoning ที่ปิดใช้งานสำหรับโมเดลหรือ proxy ที่ปฏิเสธ `reasoning.effort: "none"`
|
||||
- ตั้งค่า schema ของเครื่องมือให้เป็นโหมด strict โดยค่าเริ่มต้น
|
||||
- แนบ header attribution แบบซ่อนเฉพาะบนโฮสต์เนทีฟที่ผ่านการยืนยันแล้วเท่านั้น
|
||||
- คงรูปแบบคำขอเฉพาะของ OpenAI (`service_tier`, `store`, reasoning-compat, คำใบ้ prompt-cache)
|
||||
|
||||
**เส้นทางแบบพร็อกซี/compatible:**
|
||||
- ใช้พฤติกรรม compat ที่ผ่อนปรนกว่า
|
||||
- ไม่บังคับ strict tool schemas หรือ native-only headers
|
||||
**เส้นทางแบบ proxy/compatible:**
|
||||
- ใช้พฤติกรรม compat ที่ผ่อนคลายกว่า
|
||||
- ไม่บังคับ schema เครื่องมือแบบ strict หรือ header แบบเนทีฟเท่านั้น
|
||||
|
||||
Azure OpenAI ใช้ transport และพฤติกรรม compat แบบ native แต่จะไม่ได้รับ hidden attribution headers
|
||||
Azure OpenAI ใช้การขนส่งแบบเนทีฟและพฤติกรรม compat แต่จะไม่ได้รับ header attribution แบบซ่อน
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -623,16 +747,16 @@ provider harness Codex แบบ native ที่มากับระบบ (`c
|
||||
## ที่เกี่ยวข้อง
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Model selection" href="/th/concepts/model-providers" icon="layers">
|
||||
การเลือก providers, model refs และพฤติกรรม failover
|
||||
<Card title="การเลือกโมเดล" href="/th/concepts/model-providers" icon="layers">
|
||||
การเลือก provider, model ref และพฤติกรรม failover
|
||||
</Card>
|
||||
<Card title="Image generation" href="/th/tools/image-generation" icon="image">
|
||||
พารามิเตอร์เครื่องมือรูปภาพแบบใช้ร่วมกันและการเลือก provider
|
||||
<Card title="การสร้างภาพ" href="/th/tools/image-generation" icon="image">
|
||||
พารามิเตอร์เครื่องมือภาพที่ใช้ร่วมกันและการเลือก provider
|
||||
</Card>
|
||||
<Card title="Video generation" href="/th/tools/video-generation" icon="video">
|
||||
พารามิเตอร์เครื่องมือวิดีโอแบบใช้ร่วมกันและการเลือก provider
|
||||
<Card title="การสร้างวิดีโอ" href="/th/tools/video-generation" icon="video">
|
||||
พารามิเตอร์เครื่องมือวิดีโอที่ใช้ร่วมกันและการเลือก provider
|
||||
</Card>
|
||||
<Card title="OAuth and auth" href="/th/gateway/authentication" icon="key">
|
||||
<Card title="OAuth และการยืนยันตัวตน" href="/th/gateway/authentication" icon="key">
|
||||
รายละเอียดการยืนยันตัวตนและกฎการใช้ข้อมูลรับรองซ้ำ
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -1,50 +1,51 @@
|
||||
---
|
||||
read_when:
|
||||
- การรันหรือแก้ไขการทดสอบ to=final
|
||||
summary: วิธีรันการทดสอบในเครื่อง (Vitest) และเมื่อใดควรใช้โหมด force/coverage
|
||||
- การรันหรือแก้ไขการทดสอบ
|
||||
summary: วิธีรันการทดสอบในเครื่อง (vitest) และควรใช้โหมด force/coverage เมื่อใด
|
||||
title: การทดสอบ
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T05:56:29Z"
|
||||
generated_at: "2026-04-23T13:58:16Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: ed665840ef2c7728da8ec923eb3ea2878d9b20a841cb2fe4116a7f6334567b8e
|
||||
source_hash: e0bcecb0868b3b68361e5ef78afc3170f2a481771bda8f7d54200b1d778d044a
|
||||
source_path: reference/test.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# การทดสอบ
|
||||
|
||||
- ชุดเครื่องมือการทดสอบแบบเต็ม (suites, live, Docker): [Testing](/th/help/testing)
|
||||
- ชุดเครื่องมือการทดสอบแบบครบชุด (suites, live, Docker): [การทดสอบ](/th/help/testing)
|
||||
|
||||
- `pnpm test:force`: ฆ่าโปรเซส gateway ที่ค้างอยู่ซึ่งยึดพอร์ต control เริ่มต้นไว้ จากนั้นรันชุด Vitest ทั้งหมดด้วยพอร์ต gateway แบบแยก เพื่อไม่ให้การทดสอบฝั่ง server ชนกับ instance ที่กำลังรันอยู่ ใช้สิ่งนี้เมื่อการรัน gateway ครั้งก่อนทิ้งพอร์ต 18789 ไว้ในสถานะถูกใช้งาน
|
||||
- `pnpm test:coverage`: รัน unit suite พร้อม V8 coverage (ผ่าน `vitest.unit.config.ts`) นี่คือ coverage gate ของ unit ที่อิงกับไฟล์ที่ถูกโหลด ไม่ใช่ coverage ของทุกไฟล์ทั้ง repo threshold คือ 70% สำหรับ lines/functions/statements และ 55% สำหรับ branches เพราะ `coverage.all` เป็น false gate นี้จึงวัดไฟล์ที่ถูกโหลดโดย unit coverage suite แทนที่จะถือว่าไฟล์ source ทุกตัวใน split-lane ไม่ถูกครอบคลุม
|
||||
- `pnpm test:coverage:changed`: รัน unit coverage เฉพาะไฟล์ที่เปลี่ยนจาก `origin/main`
|
||||
- `pnpm test:changed`: ขยายพาธ git ที่เปลี่ยนเป็น Vitest lane แบบมีขอบเขต เมื่อ diff แตะเฉพาะไฟล์ source/test ที่กำหนดเส้นทางได้ การเปลี่ยน config/setup จะยัง fallback ไปยัง native root projects run เพื่อให้การแก้ wiring รันซ้ำในวงกว้างเมื่อจำเป็น
|
||||
- `pnpm changed:lanes`: แสดง architectural lane ที่ถูกกระตุ้นโดย diff เทียบกับ `origin/main`
|
||||
- `pnpm check:changed`: รัน changed gate แบบอัจฉริยะสำหรับ diff เทียบกับ `origin/main` มันจะรันงาน core พร้อม lane ทดสอบของ core, งาน extension พร้อม lane ทดสอบของ extension, งานที่เป็นเฉพาะการทดสอบพร้อมเฉพาะ test typecheck/tests, ขยายการเปลี่ยน Plugin SDK หรือ plugin-contract สาธารณะไปยังการตรวจสอบ extension และคงการชนเวอร์ชันแบบ metadata-only ของ release ไว้บน targeted version/config/root-dependency checks
|
||||
- `pnpm test`: กำหนดเส้นทางเป้าหมายไฟล์/ไดเรกทอรีแบบ explicit ผ่าน Vitest lane ที่มีขอบเขต การรันที่ไม่ระบุเป้าหมายจะใช้ fixed shard groups และขยายไปยัง leaf config สำหรับการรันขนานในเครื่อง กลุ่ม extension จะขยายไปยัง per-extension shard config เสมอ แทนที่จะใช้ root-project process ขนาดใหญ่ตัวเดียว
|
||||
- การรันแบบเต็มและ extension shard จะอัปเดตข้อมูลเวลาท้องถิ่นใน `.artifacts/vitest-shard-timings.json`; การรันครั้งต่อ ๆ ไปจะใช้เวลาเหล่านั้นเพื่อถ่วง shard ที่ช้าและเร็วให้สมดุล ตั้ง `OPENCLAW_TEST_PROJECTS_TIMINGS=0` เพื่อไม่ใช้ timing artifact ในเครื่อง
|
||||
- ไฟล์ทดสอบบางชุดของ `plugin-sdk` และ `commands` ตอนนี้ถูกกำหนดเส้นทางผ่าน light lane โดยเฉพาะที่คงไว้เพียง `test/setup.ts` ทำให้เคสที่หนักด้านรันไทม์ยังอยู่ใน lane เดิมของมัน
|
||||
- ไฟล์ source helper บางชุดของ `plugin-sdk` และ `commands` ยังแมป `pnpm test:changed` ไปยัง sibling test แบบ explicit ใน light lane เหล่านั้นด้วย ดังนั้นการแก้ helper เล็ก ๆ จะไม่ทำให้ต้องรัน suite หนักที่รองรับด้วยรันไทม์ซ้ำ
|
||||
- `auto-reply` ตอนนี้ยังถูกแยกเป็น config เฉพาะสามตัว (`core`, `top-level`, `reply`) เพื่อไม่ให้ reply harness ครอบงำการทดสอบสถานะ/token/helper แบบ top-level ที่เบากว่า
|
||||
- Base Vitest config ตอนนี้ใช้ค่าเริ่มต้น `pool: "threads"` และ `isolate: false` พร้อมเปิด shared non-isolated runner ทั่วทั้ง config ของ repo
|
||||
- `pnpm test:force`: ฆ่าโปรเซส gateway ที่ยังค้างอยู่และยึดพอร์ตควบคุมเริ่มต้น จากนั้นรันชุด Vitest ทั้งหมดด้วยพอร์ต gateway แบบแยก เพื่อไม่ให้การทดสอบเซิร์ฟเวอร์ชนกับอินสแตนซ์ที่กำลังรันอยู่ ใช้คำสั่งนี้เมื่อการรัน gateway ก่อนหน้าทิ้งให้พอร์ต 18789 ยังถูกใช้งานอยู่
|
||||
- `pnpm test:coverage`: รันชุด unit พร้อม V8 coverage (ผ่าน `vitest.unit.config.ts`) นี่คือเกณฑ์ coverage ของ unit สำหรับไฟล์ที่ถูกโหลด ไม่ใช่ coverage ของทั้งรีโปทุกไฟล์ เกณฑ์คือ 70% สำหรับ lines/functions/statements และ 55% สำหรับ branches เนื่องจาก `coverage.all` เป็น false เกณฑ์นี้จึงวัดไฟล์ที่ถูกโหลดโดยชุด unit coverage แทนที่จะนับทุกไฟล์ซอร์สใน lane ที่ถูกแยกเป็น uncovered
|
||||
- `pnpm test:coverage:changed`: รัน unit coverage เฉพาะไฟล์ที่เปลี่ยนไปจาก `origin/main`
|
||||
- `pnpm test:changed`: ขยายพาธ git ที่เปลี่ยนไปเป็น lane ของ Vitest แบบกำหนดขอบเขต เมื่อ diff แตะเฉพาะไฟล์ซอร์ส/ทดสอบที่สามารถ route ได้ การเปลี่ยนแปลง config/setup จะยัง fallback ไปใช้การรัน root projects แบบปกติ เพื่อให้การแก้ wiring มีการรันซ้ำในขอบเขตกว้างเมื่อจำเป็น
|
||||
- `pnpm changed:lanes`: แสดง lane ทางสถาปัตยกรรมที่ถูกทริกเกอร์โดย diff เทียบกับ `origin/main`
|
||||
- `pnpm check:changed`: รัน smart changed gate สำหรับ diff เทียบกับ `origin/main` โดยจะรันงาน core พร้อม lane ทดสอบของ core, งาน extension พร้อม lane ทดสอบของ extension, งานที่เปลี่ยนเฉพาะการทดสอบพร้อม typecheck/tests ของการทดสอบเท่านั้น, ขยายการเปลี่ยนแปลงใน public Plugin SDK หรือ plugin-contract ไปยังการตรวจสอบ extension และคงการตรวจสอบแบบเจาะจงสำหรับ version/config/root-dependency checks เมื่อเป็น version bump ที่แตะเฉพาะ release metadata
|
||||
- `pnpm test`: route เป้าหมายไฟล์/ไดเรกทอรีที่ระบุอย่างชัดเจนผ่าน lane ของ Vitest แบบกำหนดขอบเขต การรันที่ไม่ระบุเป้าหมายจะใช้กลุ่ม shard แบบคงที่และขยายไปยัง leaf configs เพื่อการรันแบบขนานในเครื่อง กลุ่ม extension จะขยายไปยัง per-extension shard configs เสมอ แทนที่จะเป็นโปรเซส root-project ขนาดใหญ่เพียงตัวเดียว
|
||||
- การรันแบบเต็มและแบบ extension shard จะอัปเดตข้อมูล timing ในเครื่องที่ `.artifacts/vitest-shard-timings.json`; การรันครั้งถัดไปจะใช้ timing เหล่านี้เพื่อถ่วงดุล shard ที่ช้ากับเร็ว ตั้งค่า `OPENCLAW_TEST_PROJECTS_TIMINGS=0` เพื่อไม่ใช้ timing artifact ในเครื่อง
|
||||
- ไฟล์ทดสอบ `plugin-sdk` และ `commands` บางรายการตอนนี้จะ route ผ่าน light lanes แบบเฉพาะที่คงไว้เพียง `test/setup.ts` โดยปล่อยเคสที่ใช้ runtime หนักให้อยู่ใน lane เดิม
|
||||
- ไฟล์ซอร์ส helper บางรายการของ `plugin-sdk` และ `commands` ก็แมป `pnpm test:changed` ไปยังการทดสอบข้างเคียงแบบชัดเจนใน light lanes เช่นกัน เพื่อให้การแก้ helper ขนาดเล็กไม่ต้องรันชุดที่พึ่งพา runtime หนักซ้ำ
|
||||
- ตอนนี้ `auto-reply` ถูกแยกเป็นสาม config เฉพาะ (`core`, `top-level`, `reply`) ด้วย เพื่อให้ reply harness ไม่กลายเป็นภาระหลักของการทดสอบ top-level status/token/helper ที่เบากว่า
|
||||
- ตอนนี้ base Vitest config ใช้ค่าเริ่มต้นเป็น `pool: "threads"` และ `isolate: false` พร้อมเปิดใช้ shared non-isolated runner ทั่ว repo configs
|
||||
- `pnpm test:channels` รัน `vitest.channels.config.ts`
|
||||
- `pnpm test:extensions` และ `pnpm test extensions` รัน shard ของ extension/plugin ทั้งหมด heavy channel extension และ OpenAI จะรันเป็น shard เฉพาะ ส่วนกลุ่ม extension อื่นยังคงถูกรวมเป็น batch ใช้ `pnpm test extensions/<id>` สำหรับ lane ของ bundled plugin ตัวเดียว
|
||||
- `pnpm test:perf:imports`: เปิดการรายงาน import-duration + import-breakdown ของ Vitest ขณะยังใช้การกำหนดเส้นทางแบบ lane ที่มีขอบเขตสำหรับเป้าหมายไฟล์/ไดเรกทอรีแบบ explicit
|
||||
- `pnpm test:perf:imports:changed`: profiling การ import แบบเดียวกัน แต่เฉพาะไฟล์ที่เปลี่ยนจาก `origin/main`
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` ทำ benchmark เส้นทาง changed-mode ที่ถูกกำหนดเส้นทาง เทียบกับ native root-project run สำหรับ committed git diff เดียวกัน
|
||||
- `pnpm test:extensions` และ `pnpm test extensions` รัน shard ของ extension/plugin ทั้งหมด extension ของ channel ที่หนักและ OpenAI จะรันเป็น shard เฉพาะ ส่วนกลุ่ม extension อื่นยังคงถูกรวมเป็นชุด ใช้ `pnpm test extensions/<id>` สำหรับ lane ของ bundled plugin รายตัว
|
||||
- `pnpm test:perf:imports`: เปิดใช้การรายงาน import-duration + import-breakdown ของ Vitest ขณะยังคงใช้การ route ผ่าน lane แบบกำหนดขอบเขตสำหรับเป้าหมายไฟล์/ไดเรกทอรีที่ระบุอย่างชัดเจน
|
||||
- `pnpm test:perf:imports:changed`: โปรไฟล์ import แบบเดียวกัน แต่สำหรับเฉพาะไฟล์ที่เปลี่ยนจาก `origin/main`
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` ทำ benchmark เส้นทาง changed-mode ที่ถูก route เทียบกับการรัน root-project แบบปกติ สำหรับ git diff ที่ commit แล้วชุดเดียวกัน
|
||||
- `pnpm test:perf:changed:bench -- --worktree` ทำ benchmark ชุดการเปลี่ยนแปลงใน worktree ปัจจุบันโดยไม่ต้อง commit ก่อน
|
||||
- `pnpm test:perf:profile:main`: เขียน CPU profile สำหรับเธรดหลักของ Vitest (`.artifacts/vitest-main-profile`)
|
||||
- `pnpm test:perf:profile:runner`: เขียน CPU + heap profile สำหรับ unit runner (`.artifacts/vitest-runner-profile`)
|
||||
- Gateway integration: เปิดใช้แบบ opt-in ผ่าน `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` หรือ `pnpm test:gateway`
|
||||
- `pnpm test:e2e`: รัน gateway end-to-end smoke tests (multi-instance WS/HTTP/node pairing) ค่าเริ่มต้นคือ `threads` + `isolate: false` พร้อม worker แบบ adaptive ใน `vitest.e2e.config.ts`; ปรับได้ด้วย `OPENCLAW_E2E_WORKERS=<n>` และตั้ง `OPENCLAW_E2E_VERBOSE=1` เพื่อดูล็อกแบบ verbose
|
||||
- `pnpm test:live`: รัน provider live tests (minimax/zai) ต้องมี API keys และ `LIVE=1` (หรือ `*_LIVE_TEST=1` เฉพาะ provider) เพื่อยกเลิกการ skip
|
||||
- `pnpm test:docker:openwebui`: เริ่ม OpenClaw + Open WebUI แบบ Dockerized, ลงชื่อเข้าใช้ผ่าน Open WebUI, ตรวจสอบ `/api/models`, จากนั้นรันแชตจริงที่ถูก proxy ผ่าน `/api/chat/completions` ต้องใช้ live model key ที่ใช้งานได้ (เช่น OpenAI ใน `~/.profile`) ดึง Open WebUI image ภายนอก และไม่ได้คาดหวังว่าจะเสถียรแบบ CI เหมือน unit/e2e suite ปกติ
|
||||
- `pnpm test:docker:mcp-channels`: เริ่ม Gateway container ที่ถูก seed แล้ว และ client container ตัวที่สองที่สตาร์ต `openclaw mcp serve` จากนั้นตรวจสอบ routed conversation discovery, การอ่าน transcript, attachment metadata, พฤติกรรมของ live event queue, outbound send routing และการแจ้งเตือน channel + permission แบบ Claude ผ่าน stdio bridge จริง การตรวจสอบการแจ้งเตือนของ Claude จะอ่าน raw stdio MCP frame โดยตรง เพื่อให้ smoke สะท้อนสิ่งที่ bridge ปล่อยออกมาจริง
|
||||
- `pnpm test:perf:profile:main`: เขียน CPU profile สำหรับ Vitest main thread (`.artifacts/vitest-main-profile`)
|
||||
- `pnpm test:perf:profile:runner`: เขียน CPU + heap profiles สำหรับ unit runner (`.artifacts/vitest-runner-profile`)
|
||||
- Gateway integration: เปิดใช้แบบ opt-in ด้วย `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` หรือ `pnpm test:gateway`
|
||||
- `pnpm test:e2e`: รันการทดสอบ gateway end-to-end smoke (multi-instance WS/HTTP/node pairing) โดยใช้ค่าเริ่มต้นเป็น `threads` + `isolate: false` พร้อม adaptive workers ใน `vitest.e2e.config.ts`; ปรับแต่งได้ด้วย `OPENCLAW_E2E_WORKERS=<n>` และตั้ง `OPENCLAW_E2E_VERBOSE=1` เพื่อดูล็อกแบบละเอียด
|
||||
- `pnpm test:live`: รันการทดสอบ provider แบบ live (minimax/zai) ต้องมี API keys และ `LIVE=1` (หรือ `*_LIVE_TEST=1` เฉพาะ provider) เพื่อยกเลิกการ skip
|
||||
- `pnpm test:docker:all`: สร้าง shared live-test image และ Docker E2E image เพียงครั้งเดียว จากนั้นรัน Docker smoke lanes โดยใช้ `OPENCLAW_SKIP_DOCKER_BUILD=1` ด้วย concurrency ค่าเริ่มต้นที่ 4 ปรับได้ด้วย `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` ตัวรันจะหยุดจัดคิว lane ใหม่หลังจากความล้มเหลวครั้งแรก เว้นแต่จะตั้ง `OPENCLAW_DOCKER_ALL_FAIL_FAST=0` และแต่ละ lane มี timeout 120 นาที ซึ่ง override ได้ด้วย `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` lane ที่ไวต่อการเริ่มต้นระบบหรือ provider จะรันแบบ exclusive หลังจาก parallel pool จบแล้ว ล็อกของแต่ละ lane จะถูกเขียนไว้ภายใต้ `.artifacts/docker-tests/<run-id>/`
|
||||
- `pnpm test:docker:openwebui`: เริ่ม OpenClaw + Open WebUI บน Docker, ลงชื่อเข้าใช้ผ่าน Open WebUI, ตรวจสอบ `/api/models`, จากนั้นรันแชต proxied จริงผ่าน `/api/chat/completions` ต้องมี live model key ที่ใช้งานได้ (เช่น OpenAI ใน `~/.profile`), ดึง image ของ Open WebUI จากภายนอก และไม่ได้คาดหวังว่าจะเสถียรใน CI เท่ากับชุด unit/e2e ปกติ
|
||||
- `pnpm test:docker:mcp-channels`: เริ่มคอนเทนเนอร์ Gateway ที่ seeded แล้ว และคอนเทนเนอร์ client ตัวที่สองซึ่งสตาร์ต `openclaw mcp serve` จากนั้นตรวจสอบ routed conversation discovery, การอ่าน transcript, attachment metadata, พฤติกรรมของ live event queue, การ route สำหรับ outbound send และการแจ้งเตือน channel + permission แบบ Claude ผ่าน stdio bridge จริง การยืนยัน Claude notification จะอ่าน raw stdio MCP frames โดยตรง เพื่อให้ smoke test สะท้อนสิ่งที่ bridge ส่งออกจริง
|
||||
|
||||
## PR gate ในเครื่อง
|
||||
|
||||
สำหรับการตรวจสอบ local PR gate ก่อน land ให้รัน:
|
||||
สำหรับการตรวจสอบก่อน land/gate PR ในเครื่อง ให้รัน:
|
||||
|
||||
- `pnpm check:changed`
|
||||
- `pnpm check`
|
||||
@ -53,31 +54,31 @@ x-i18n:
|
||||
- `pnpm test`
|
||||
- `pnpm check:docs`
|
||||
|
||||
หาก `pnpm test` มีอาการ flaky บนโฮสต์ที่มีโหลดสูง ให้รันซ้ำอีกหนึ่งครั้งก่อนจะถือว่าเป็น regression จากนั้นค่อยแยกด้วย `pnpm test <path/to/test>` สำหรับโฮสต์ที่หน่วยความจำจำกัด ให้ใช้:
|
||||
หาก `pnpm test` มีอาการ flake บนเครื่องที่มีโหลดสูง ให้รันซ้ำหนึ่งครั้งก่อนจะถือว่าเป็น regression จากนั้นค่อยแยกตรวจด้วย `pnpm test <path/to/test>` สำหรับเครื่องที่มีข้อจำกัดด้านหน่วยความจำ ให้ใช้:
|
||||
|
||||
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
|
||||
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
|
||||
|
||||
## benchmark ความหน่วงของโมเดล (local keys)
|
||||
## benchmark ความหน่วงของโมเดล (คีย์ในเครื่อง)
|
||||
|
||||
สคริปต์: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
|
||||
|
||||
การใช้งาน:
|
||||
วิธีใช้:
|
||||
|
||||
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
|
||||
- env แบบไม่บังคับ: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
|
||||
- พรอมป์เริ่มต้น: “Reply with a single word: ok. No punctuation or extra text.”
|
||||
- ตัวแปรแวดล้อมเสริม: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
|
||||
- prompt เริ่มต้น: “Reply with a single word: ok. No punctuation or extra text.”
|
||||
|
||||
การรันล่าสุด (2025-12-31, 20 runs):
|
||||
ผลการรันล่าสุด (2025-12-31, 20 ครั้ง):
|
||||
|
||||
- minimax median 1279ms (min 1114, max 2431)
|
||||
- opus median 2454ms (min 1224, max 3170)
|
||||
- minimax มัธยฐาน 1279ms (ต่ำสุด 1114, สูงสุด 2431)
|
||||
- opus มัธยฐาน 2454ms (ต่ำสุด 1224, สูงสุด 3170)
|
||||
|
||||
## benchmark การเริ่ม CLI
|
||||
## benchmark เวลาเริ่มต้น CLI
|
||||
|
||||
สคริปต์: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
|
||||
|
||||
การใช้งาน:
|
||||
วิธีใช้:
|
||||
|
||||
- `pnpm test:startup:bench`
|
||||
- `pnpm test:startup:bench:smoke`
|
||||
@ -94,41 +95,41 @@ x-i18n:
|
||||
- `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
|
||||
- `pnpm tsx scripts/bench-cli-startup.ts --json`
|
||||
|
||||
Preset:
|
||||
ชุดพรีเซ็ต:
|
||||
|
||||
- `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
|
||||
- `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
|
||||
- `all`: ทั้งสอง preset
|
||||
- `all`: ทั้งสองพรีเซ็ต
|
||||
|
||||
เอาต์พุตประกอบด้วย `sampleCount`, avg, p50, p95, min/max, การกระจายของ exit-code/signal และสรุป max RSS สำหรับแต่ละคำสั่ง ตัวเลือก `--cpu-prof-dir` / `--heap-prof-dir` จะเขียน V8 profile ต่อการรัน ทำให้การจับเวลาและการเก็บ profile ใช้ harness เดียวกัน
|
||||
ผลลัพธ์จะรวม `sampleCount`, avg, p50, p95, min/max, การกระจายของ exit-code/signal และสรุป max RSS สำหรับแต่ละคำสั่ง ตัวเลือก `--cpu-prof-dir` / `--heap-prof-dir` จะเขียน V8 profiles ต่อการรันแต่ละครั้ง เพื่อให้การจับเวลาและการเก็บโปรไฟล์ใช้ harness เดียวกัน
|
||||
|
||||
ธรรมเนียมของเอาต์พุตที่บันทึกไว้:
|
||||
รูปแบบผลลัพธ์ที่บันทึก:
|
||||
|
||||
- `pnpm test:startup:bench:smoke` จะเขียน smoke artifact แบบเจาะจงไว้ที่ `.artifacts/cli-startup-bench-smoke.json`
|
||||
- `pnpm test:startup:bench:save` จะเขียน full-suite artifact ที่ `.artifacts/cli-startup-bench-all.json` โดยใช้ `runs=5` และ `warmup=1`
|
||||
- `pnpm test:startup:bench:update` จะรีเฟรช baseline fixture ที่ถูกเก็บไว้ใน `test/fixtures/cli-startup-bench.json` โดยใช้ `runs=5` และ `warmup=1`
|
||||
- `pnpm test:startup:bench:smoke` จะเขียน targeted smoke artifact ไปที่ `.artifacts/cli-startup-bench-smoke.json`
|
||||
- `pnpm test:startup:bench:save` จะเขียน artifact ของชุดเต็มไปที่ `.artifacts/cli-startup-bench-all.json` โดยใช้ `runs=5` และ `warmup=1`
|
||||
- `pnpm test:startup:bench:update` จะรีเฟรช baseline fixture ที่ check-in ไว้ที่ `test/fixtures/cli-startup-bench.json` โดยใช้ `runs=5` และ `warmup=1`
|
||||
|
||||
fixture ที่ถูกเก็บไว้:
|
||||
fixture ที่ check-in ไว้:
|
||||
|
||||
- `test/fixtures/cli-startup-bench.json`
|
||||
- รีเฟรชด้วย `pnpm test:startup:bench:update`
|
||||
- เปรียบเทียบผลลัพธ์ปัจจุบันกับ fixture ด้วย `pnpm test:startup:bench:check`
|
||||
- เปรียบเทียบผลปัจจุบันกับ fixture ด้วย `pnpm test:startup:bench:check`
|
||||
|
||||
## Onboarding E2E (Docker)
|
||||
|
||||
Docker เป็นตัวเลือกเสริม; จำเป็นเฉพาะสำหรับ onboarding smoke test แบบ containerized เท่านั้น
|
||||
Docker เป็นทางเลือก ส่วนนี้จำเป็นเฉพาะสำหรับการทดสอบ onboarding smoke แบบคอนเทนเนอร์
|
||||
|
||||
โฟลว์ full cold-start ใน Linux container ที่สะอาด:
|
||||
โฟลว์ cold-start แบบเต็มในคอนเทนเนอร์ Linux ที่สะอาด:
|
||||
|
||||
```bash
|
||||
scripts/e2e/onboard-docker.sh
|
||||
```
|
||||
|
||||
สคริปต์นี้จะขับเคลื่อนวิซาร์ดแบบโต้ตอบผ่าน pseudo-tty, ตรวจสอบไฟล์ config/workspace/session แล้วเริ่ม gateway และรัน `openclaw health`
|
||||
สคริปต์นี้จะขับวิซาร์ดแบบโต้ตอบผ่าน pseudo-tty, ตรวจสอบไฟล์ config/workspace/session จากนั้นสตาร์ต gateway และรัน `openclaw health`
|
||||
|
||||
## QR import smoke (Docker)
|
||||
|
||||
ตรวจสอบว่า `qrcode-terminal` โหลดได้ภายใต้ Node runtime แบบ Docker ที่รองรับ (ค่าเริ่มต้น Node 24, รองรับ Node 22):
|
||||
ยืนยันว่า `qrcode-terminal` โหลดได้ภายใต้ Docker Node runtimes ที่รองรับ (ค่าเริ่มต้น Node 24, รองรับ Node 22):
|
||||
|
||||
```bash
|
||||
pnpm test:docker:qr
|
||||
|
||||
@ -1,31 +1,31 @@
|
||||
---
|
||||
read_when:
|
||||
- การสร้างภาพผ่านเอเจนต์
|
||||
- การตั้งค่า providers และโมเดลสำหรับการสร้างภาพ
|
||||
- การทำความเข้าใจพารามิเตอร์ของเครื่องมือ `image_generate`
|
||||
summary: สร้างและแก้ไขภาพโดยใช้ providers ที่ตั้งค่าไว้ (OpenAI, Google Gemini, fal, MiniMax, ComfyUI, Vydra, xAI)
|
||||
title: การสร้างภาพ
|
||||
- การสร้างรูปภาพผ่านเอเจนต์
|
||||
- การกำหนดค่าผู้ให้บริการและโมเดลสำหรับการสร้างรูปภาพ
|
||||
- ทำความเข้าใจพารามิเตอร์ของเครื่องมือ image_generate
|
||||
summary: สร้างและแก้ไขรูปภาพโดยใช้ผู้ให้บริการที่กำหนดค่าไว้ (OpenAI, Google Gemini, fal, MiniMax, ComfyUI, Vydra, xAI)
|
||||
title: การสร้างรูปภาพ
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T06:01:14Z"
|
||||
generated_at: "2026-04-23T13:58:19Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 228049c74dd3437544cda6418da665aed375c0494ef36a6927d15c28d7783bbd
|
||||
source_hash: 0fbd8eda2cb0867d1426b9349f6778c231051d600ebe451534efbee0e215c871
|
||||
source_path: tools/image-generation.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# การสร้างภาพ
|
||||
# การสร้างรูปภาพ
|
||||
|
||||
เครื่องมือ `image_generate` ช่วยให้เอเจนต์สร้างและแก้ไขภาพโดยใช้ providers ที่คุณตั้งค่าไว้ ภาพที่สร้างขึ้นจะถูกส่งกลับโดยอัตโนมัติเป็นไฟล์แนบสื่อในการตอบกลับของเอเจนต์
|
||||
เครื่องมือ `image_generate` ช่วยให้เอเจนต์สร้างและแก้ไขรูปภาพโดยใช้ผู้ให้บริการที่คุณกำหนดค่าไว้ รูปภาพที่สร้างขึ้นจะถูกส่งให้อัตโนมัติเป็นไฟล์แนบสื่อในคำตอบของเอเจนต์
|
||||
|
||||
<Note>
|
||||
เครื่องมือนี้จะแสดงขึ้นก็ต่อเมื่อมี image generation provider อย่างน้อยหนึ่งตัวพร้อมใช้งาน หากคุณไม่เห็น `image_generate` ในรายการเครื่องมือของเอเจนต์ ให้ตั้งค่า `agents.defaults.imageGenerationModel` หรือกำหนด provider API key
|
||||
เครื่องมือนี้จะแสดงขึ้นก็ต่อเมื่อมีผู้ให้บริการสร้างรูปภาพอย่างน้อยหนึ่งรายเท่านั้น หากคุณไม่เห็น `image_generate` ในเครื่องมือของเอเจนต์ ให้กำหนดค่า `agents.defaults.imageGenerationModel` หรือตั้งค่า API key ของผู้ให้บริการ
|
||||
</Note>
|
||||
|
||||
## เริ่มต้นอย่างรวดเร็ว
|
||||
|
||||
1. ตั้งค่า API key สำหรับอย่างน้อยหนึ่ง provider (ตัวอย่างเช่น `OPENAI_API_KEY` หรือ `GEMINI_API_KEY`)
|
||||
2. ตั้งค่าโมเดลที่ต้องการแบบไม่บังคับ:
|
||||
1. ตั้งค่า API key สำหรับผู้ให้บริการอย่างน้อยหนึ่งราย (เช่น `OPENAI_API_KEY` หรือ `GEMINI_API_KEY`)
|
||||
2. เลือกตั้งค่าโมเดลที่ต้องการ:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -39,23 +39,23 @@ x-i18n:
|
||||
}
|
||||
```
|
||||
|
||||
3. สั่งเอเจนต์ว่า: _"Generate an image of a friendly lobster mascot."_
|
||||
3. ขอให้เอเจนต์: _"สร้างรูปภาพมาสคอตล็อบสเตอร์ที่เป็นมิตร"_
|
||||
|
||||
เอเจนต์จะเรียก `image_generate` โดยอัตโนมัติ ไม่ต้องตั้ง allow-list ของเครื่องมือ — มันเปิดใช้งานเป็นค่าเริ่มต้นเมื่อมี provider พร้อมใช้งาน
|
||||
เอเจนต์จะเรียก `image_generate` โดยอัตโนมัติ ไม่ต้องกำหนด allow-list ของเครื่องมือ เพราะจะเปิดใช้งานเป็นค่าเริ่มต้นเมื่อมีผู้ให้บริการพร้อมใช้งาน
|
||||
|
||||
## Providers ที่รองรับ
|
||||
## ผู้ให้บริการที่รองรับ
|
||||
|
||||
| Provider | โมเดลเริ่มต้น | รองรับการแก้ไข | API key |
|
||||
| -------- | ---------------------------------- | -------------------------------- | ------------------------------------------------------ |
|
||||
| OpenAI | `gpt-image-2` | ใช่ (สูงสุด 5 ภาพ) | `OPENAI_API_KEY` |
|
||||
| Google | `gemini-3.1-flash-image-preview` | ใช่ | `GEMINI_API_KEY` หรือ `GOOGLE_API_KEY` |
|
||||
| fal | `fal-ai/flux/dev` | ใช่ | `FAL_KEY` |
|
||||
| MiniMax | `image-01` | ใช่ (อ้างอิง subject) | `MINIMAX_API_KEY` หรือ MiniMax OAuth (`minimax-portal`) |
|
||||
| ComfyUI | `workflow` | ใช่ (1 ภาพ, กำหนดโดย workflow) | `COMFY_API_KEY` หรือ `COMFY_CLOUD_API_KEY` สำหรับ cloud |
|
||||
| Vydra | `grok-imagine` | ไม่ | `VYDRA_API_KEY` |
|
||||
| xAI | `grok-imagine-image` | ใช่ (สูงสุด 5 ภาพ) | `XAI_API_KEY` |
|
||||
| ผู้ให้บริการ | โมเดลเริ่มต้น | รองรับการแก้ไข | API key |
|
||||
| -------- | -------------------------------- | ---------------------------------- | ----------------------------------------------------- |
|
||||
| OpenAI | `gpt-image-2` | ใช่ (สูงสุด 5 รูป) | `OPENAI_API_KEY` |
|
||||
| Google | `gemini-3.1-flash-image-preview` | ใช่ | `GEMINI_API_KEY` หรือ `GOOGLE_API_KEY` |
|
||||
| fal | `fal-ai/flux/dev` | ใช่ | `FAL_KEY` |
|
||||
| MiniMax | `image-01` | ใช่ (อ้างอิงวัตถุหลัก) | `MINIMAX_API_KEY` หรือ MiniMax OAuth (`minimax-portal`) |
|
||||
| ComfyUI | `workflow` | ใช่ (1 รูป, กำหนดโดย workflow) | `COMFY_API_KEY` หรือ `COMFY_CLOUD_API_KEY` สำหรับคลาวด์ |
|
||||
| Vydra | `grok-imagine` | ไม่ | `VYDRA_API_KEY` |
|
||||
| xAI | `grok-imagine-image` | ใช่ (สูงสุด 5 รูป) | `XAI_API_KEY` |
|
||||
|
||||
ใช้ `action: "list"` เพื่อตรวจดู providers และโมเดลที่พร้อมใช้งานในรันไทม์:
|
||||
ใช้ `action: "list"` เพื่อตรวจสอบผู้ให้บริการและโมเดลที่พร้อมใช้งานขณะรัน:
|
||||
|
||||
```
|
||||
/tool image_generate action=list
|
||||
@ -63,24 +63,24 @@ x-i18n:
|
||||
|
||||
## พารามิเตอร์ของเครื่องมือ
|
||||
|
||||
| พารามิเตอร์ | ชนิด | คำอธิบาย |
|
||||
| ------------- | -------- | ------------------------------------------------------------------------ |
|
||||
| `prompt` | string | พรอมป์ต์สำหรับการสร้างภาพ (จำเป็นสำหรับ `action: "generate"`) |
|
||||
| `action` | string | `"generate"` (ค่าเริ่มต้น) หรือ `"list"` เพื่อตรวจดู providers |
|
||||
| `model` | string | override ของ provider/model เช่น `openai/gpt-image-2` |
|
||||
| `image` | string | พาธหรือ URL ของภาพอ้างอิงภาพเดียวสำหรับโหมดแก้ไข |
|
||||
| `images` | string[] | ภาพอ้างอิงหลายภาพสำหรับโหมดแก้ไข (สูงสุด 5) |
|
||||
| `size` | string | คำใบ้เรื่องขนาด: `1024x1024`, `1536x1024`, `1024x1536`, `2048x2048`, `3840x2160` |
|
||||
| พารามิเตอร์ | ประเภท | คำอธิบาย |
|
||||
| ------------- | -------- | -------------------------------------------------------------------------------------- |
|
||||
| `prompt` | string | พรอมป์ต์สำหรับการสร้างรูปภาพ (จำเป็นสำหรับ `action: "generate"`) |
|
||||
| `action` | string | `"generate"` (ค่าเริ่มต้น) หรือ `"list"` เพื่อดูผู้ให้บริการ |
|
||||
| `model` | string | ระบุผู้ให้บริการ/โมเดลทับค่าเดิม เช่น `openai/gpt-image-2` |
|
||||
| `image` | string | พาธหรือ URL ของรูปภาพอ้างอิงเดี่ยวสำหรับโหมดแก้ไข |
|
||||
| `images` | string[] | รูปภาพอ้างอิงหลายรูปสำหรับโหมดแก้ไข (สูงสุด 5 รูป) |
|
||||
| `size` | string | คำใบ้ขนาด: `1024x1024`, `1536x1024`, `1024x1536`, `2048x2048`, `3840x2160` |
|
||||
| `aspectRatio` | string | อัตราส่วนภาพ: `1:1`, `2:3`, `3:2`, `3:4`, `4:3`, `4:5`, `5:4`, `9:16`, `16:9`, `21:9` |
|
||||
| `resolution` | string | คำใบ้เรื่องความละเอียด: `1K`, `2K` หรือ `4K` |
|
||||
| `count` | number | จำนวนภาพที่จะสร้าง (1–4) |
|
||||
| `filename` | string | คำใบ้ชื่อไฟล์เอาต์พุต |
|
||||
| `resolution` | string | คำใบ้ความละเอียด: `1K`, `2K` หรือ `4K` |
|
||||
| `count` | number | จำนวนรูปภาพที่ต้องการสร้าง (1–4) |
|
||||
| `filename` | string | คำใบ้ชื่อไฟล์ผลลัพธ์ |
|
||||
|
||||
ไม่ใช่ทุก provider ที่รองรับทุกพารามิเตอร์ เมื่อ fallback provider รองรับตัวเลือก geometry ที่ใกล้เคียงแทนค่าที่ร้องขอแบบตรงตัว OpenClaw จะ remap ไปยัง size, aspect ratio หรือ resolution ที่รองรับและใกล้ที่สุดก่อนส่งคำขอ ส่วน overrides ที่ไม่รองรับจริงๆ จะยังคงถูกรายงานในผลลัพธ์ของเครื่องมือ
|
||||
ผู้ให้บริการแต่ละรายไม่ได้รองรับทุกพารามิเตอร์เสมอไป เมื่อผู้ให้บริการสำรองรองรับตัวเลือกเรขาคณิตที่ใกล้เคียงแทนค่าที่ร้องขอแบบตรงตัว OpenClaw จะรีแมปไปยังขนาด อัตราส่วนภาพ หรือความละเอียดที่รองรับและใกล้ที่สุดก่อนส่งคำขอ ส่วนค่าที่ไม่รองรับจริงจะยังถูกรายงานอยู่ในผลลัพธ์ของเครื่องมือ
|
||||
|
||||
ผลลัพธ์ของเครื่องมือจะรายงานค่าการตั้งค่าที่ถูกนำไปใช้ เมื่อ OpenClaw ทำการ remap geometry ระหว่าง provider fallback ค่า `size`, `aspectRatio` และ `resolution` ที่คืนมาจะสะท้อนสิ่งที่ถูกส่งจริง และ `details.normalization` จะเก็บการแปลจากค่าที่ร้องขอไปเป็นค่าที่ถูกนำไปใช้
|
||||
ผลลัพธ์ของเครื่องมือจะแสดงการตั้งค่าที่ถูกนำไปใช้ เมื่อ OpenClaw รีแมปค่าทางเรขาคณิตระหว่างการ fallback ของผู้ให้บริการ ค่า `size`, `aspectRatio` และ `resolution` ที่ส่งกลับจะสะท้อนค่าที่ถูกส่งจริง และ `details.normalization` จะเก็บการแปลงจากค่าที่ร้องขอไปเป็นค่าที่นำไปใช้
|
||||
|
||||
## การตั้งค่า
|
||||
## การกำหนดค่า
|
||||
|
||||
### การเลือกโมเดล
|
||||
|
||||
@ -97,114 +97,119 @@ x-i18n:
|
||||
}
|
||||
```
|
||||
|
||||
### ลำดับการเลือก provider
|
||||
### ลำดับการเลือกผู้ให้บริการ
|
||||
|
||||
เมื่อสร้างภาพ OpenClaw จะลอง providers ตามลำดับนี้:
|
||||
เมื่อสร้างรูปภาพ OpenClaw จะลองผู้ให้บริการตามลำดับนี้:
|
||||
|
||||
1. **พารามิเตอร์ `model`** จากการเรียกเครื่องมือ (หากเอเจนต์ระบุมา)
|
||||
2. **`imageGenerationModel.primary`** จาก config
|
||||
1. **พารามิเตอร์ `model`** จากการเรียกเครื่องมือ (หากเอเจนต์ระบุไว้)
|
||||
2. **`imageGenerationModel.primary`** จากการตั้งค่า
|
||||
3. **`imageGenerationModel.fallbacks`** ตามลำดับ
|
||||
4. **Auto-detection** — ใช้เฉพาะ provider defaults ที่รองรับ auth:
|
||||
- current default provider ก่อน
|
||||
- providers สำหรับการสร้างภาพที่ลงทะเบียนไว้ที่เหลือตามลำดับ provider-id
|
||||
4. **การตรวจจับอัตโนมัติ** — ใช้เฉพาะค่าเริ่มต้นของผู้ให้บริการที่มีการยืนยันตัวตนรองรับเท่านั้น:
|
||||
- ผู้ให้บริการเริ่มต้นปัจจุบันก่อน
|
||||
- ผู้ให้บริการสร้างรูปภาพที่ลงทะเบียนไว้ที่เหลือตามลำดับ provider-id
|
||||
|
||||
หาก provider ล้มเหลว (auth error, rate limit ฯลฯ) ระบบจะลองตัวเลือกถัดไปโดยอัตโนมัติ หากทุกตัวล้มเหลว ข้อผิดพลาดจะรวมรายละเอียดจากทุกความพยายาม
|
||||
หากผู้ให้บริการรายหนึ่งล้มเหลว (ข้อผิดพลาดการยืนยันตัวตน, ติด rate limit ฯลฯ) ระบบจะลองตัวเลือกถัดไปโดยอัตโนมัติ หากล้มเหลวทั้งหมด ข้อผิดพลาดจะมีรายละเอียดจากแต่ละความพยายาม
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- Auto-detection รับรู้สถานะ auth ด้วย provider default จะเข้ารายการตัวเลือก
|
||||
ก็ต่อเมื่อ OpenClaw สามารถยืนยันตัวตนกับ provider นั้นได้จริง
|
||||
- Auto-detection เปิดใช้เป็นค่าเริ่มต้น ตั้ง
|
||||
`agents.defaults.mediaGenerationAutoProviderFallback: false` หากคุณต้องการให้ image
|
||||
generation ใช้เฉพาะ `model`, `primary` และ `fallbacks`
|
||||
- การตรวจจับอัตโนมัติรับรู้สถานะการยืนยันตัวตน ผู้ให้บริการเริ่มต้นจะถูกเพิ่มเข้าไปในรายการตัวเลือกก็ต่อเมื่อ OpenClaw สามารถยืนยันตัวตนกับผู้ให้บริการนั้นได้จริง
|
||||
- การตรวจจับอัตโนมัติเปิดใช้งานเป็นค่าเริ่มต้น ตั้งค่า
|
||||
`agents.defaults.mediaGenerationAutoProviderFallback: false` หากคุณต้องการให้การสร้างรูปภาพ
|
||||
ใช้เฉพาะรายการ `model`, `primary` และ `fallbacks`
|
||||
ที่ระบุไว้อย่างชัดเจนเท่านั้น
|
||||
- ใช้ `action: "list"` เพื่อตรวจดู providers ที่ลงทะเบียนไว้ในปัจจุบัน
|
||||
โมเดลเริ่มต้นของแต่ละตัว และคำใบ้ env-var สำหรับ auth
|
||||
- ใช้ `action: "list"` เพื่อตรวจสอบผู้ให้บริการที่ลงทะเบียนอยู่ในขณะนี้
|
||||
โมเดลเริ่มต้นของแต่ละราย และคำใบ้เกี่ยวกับ env var สำหรับการยืนยันตัวตน
|
||||
|
||||
### การแก้ไขภาพ
|
||||
### การแก้ไขรูปภาพ
|
||||
|
||||
OpenAI, Google, fal, MiniMax, ComfyUI และ xAI รองรับการแก้ไขภาพอ้างอิง ส่งพาธหรือ URL ของภาพอ้างอิงเข้าไป:
|
||||
OpenAI, Google, fal, MiniMax, ComfyUI และ xAI รองรับการแก้ไขรูปภาพอ้างอิง ส่งพาธหรือ URL ของรูปภาพอ้างอิงได้ดังนี้:
|
||||
|
||||
```
|
||||
"Generate a watercolor version of this photo" + image: "/path/to/photo.jpg"
|
||||
"สร้างภาพถ่ายนี้ในเวอร์ชันสีน้ำ" + image: "/path/to/photo.jpg"
|
||||
```
|
||||
|
||||
OpenAI, Google และ xAI รองรับภาพอ้างอิงได้สูงสุด 5 ภาพผ่านพารามิเตอร์ `images` ส่วน fal, MiniMax และ ComfyUI รองรับ 1 ภาพ
|
||||
OpenAI, Google และ xAI รองรับรูปภาพอ้างอิงได้สูงสุด 5 รูปผ่านพารามิเตอร์ `images` ส่วน fal, MiniMax และ ComfyUI รองรับ 1 รูป
|
||||
|
||||
### OpenAI `gpt-image-2`
|
||||
|
||||
การสร้างภาพของ OpenAI ใช้ค่าเริ่มต้นเป็น `openai/gpt-image-2` โดยโมเดลเก่า
|
||||
`openai/gpt-image-1` ยังสามารถเลือกใช้อย่างชัดเจนได้ แต่คำขอสร้างภาพและแก้ไขภาพใหม่ของ OpenAI ควรใช้ `gpt-image-2`
|
||||
การสร้างรูปภาพของ OpenAI ใช้ค่าเริ่มต้นเป็น `openai/gpt-image-2` โมเดลรุ่นเก่า
|
||||
`openai/gpt-image-1` ยังสามารถเลือกใช้อย่างชัดเจนได้ แต่คำขอสร้างรูปภาพและแก้ไขรูปภาพใหม่ของ OpenAI
|
||||
ควรใช้ `gpt-image-2`
|
||||
|
||||
`gpt-image-2` รองรับทั้งการสร้างภาพจากข้อความและการแก้ไขภาพอ้างอิง
|
||||
ผ่านเครื่องมือ `image_generate` เดียวกัน OpenClaw จะส่งต่อ `prompt`,
|
||||
`count`, `size` และภาพอ้างอิงไปยัง OpenAI โดย OpenAI จะไม่ได้รับ
|
||||
`aspectRatio` หรือ `resolution` โดยตรง; หากเป็นไปได้ OpenClaw จะแมปสิ่งเหล่านี้ไปยัง
|
||||
`size` ที่รองรับ มิฉะนั้นเครื่องมือจะรายงานว่าเป็น overrides ที่ถูกละเลย
|
||||
`gpt-image-2` รองรับทั้งการสร้างรูปภาพจากข้อความและการแก้ไขรูปภาพอ้างอิง
|
||||
ผ่านเครื่องมือ `image_generate` ตัวเดียวกัน OpenClaw จะส่งต่อ `prompt`,
|
||||
`count`, `size` และรูปภาพอ้างอิงไปยัง OpenAI โดย OpenAI จะไม่ได้รับ
|
||||
`aspectRatio` หรือ `resolution` โดยตรง; เมื่อเป็นไปได้ OpenClaw จะจับคู่ค่าเหล่านั้นไปเป็น
|
||||
`size` ที่รองรับ มิฉะนั้นเครื่องมือจะรายงานว่าเป็นค่าทับที่ถูกละเว้น
|
||||
|
||||
สร้างภาพแนวนอน 4K หนึ่งภาพ:
|
||||
สร้างรูปภาพแนวนอน 4K หนึ่งรูป:
|
||||
|
||||
```
|
||||
/tool image_generate action=generate model=openai/gpt-image-2 prompt="A clean editorial poster for OpenClaw image generation" size=3840x2160 count=1
|
||||
```
|
||||
|
||||
สร้างภาพสี่เหลี่ยมจัตุรัสสองภาพ:
|
||||
สร้างรูปภาพสี่เหลี่ยมจัตุรัสสองรูป:
|
||||
|
||||
```
|
||||
/tool image_generate action=generate model=openai/gpt-image-2 prompt="Two visual directions for a calm productivity app icon" size=1024x1024 count=2
|
||||
```
|
||||
|
||||
แก้ไขภาพอ้างอิงในเครื่องหนึ่งภาพ:
|
||||
แก้ไขรูปภาพอ้างอิงภายในเครื่องหนึ่งรูป:
|
||||
|
||||
```
|
||||
/tool image_generate action=generate model=openai/gpt-image-2 prompt="Keep the subject, replace the background with a bright studio setup" image=/path/to/reference.png size=1024x1536
|
||||
```
|
||||
|
||||
แก้ไขด้วยภาพอ้างอิงหลายภาพ:
|
||||
แก้ไขโดยใช้รูปภาพอ้างอิงหลายรูป:
|
||||
|
||||
```
|
||||
/tool image_generate action=generate model=openai/gpt-image-2 prompt="Combine the character identity from the first image with the color palette from the second" images='["/path/to/character.png","/path/to/palette.jpg"]' size=1536x1024
|
||||
```
|
||||
|
||||
การสร้างภาพของ MiniMax ใช้งานได้ผ่านทั้งสองเส้นทาง auth ของ MiniMax ที่ bundled มา:
|
||||
หากต้องการให้การสร้างรูปภาพของ OpenAI ส่งผ่านการติดตั้งใช้งาน Azure OpenAI แทน
|
||||
`api.openai.com` โปรดดู [Azure OpenAI endpoints](/th/providers/openai#azure-openai-endpoints)
|
||||
ในเอกสารของผู้ให้บริการ OpenAI
|
||||
|
||||
การสร้างรูปภาพของ MiniMax ใช้งานได้ผ่านทั้งสองเส้นทางการยืนยันตัวตน MiniMax ที่มีมาให้:
|
||||
|
||||
- `minimax/image-01` สำหรับการตั้งค่าด้วย API key
|
||||
- `minimax-portal/image-01` สำหรับการตั้งค่าด้วย OAuth
|
||||
|
||||
## ความสามารถของ Provider
|
||||
## ความสามารถของผู้ให้บริการ
|
||||
|
||||
| ความสามารถ | OpenAI | Google | fal | MiniMax | ComfyUI | Vydra | xAI |
|
||||
| ---------------------- | -------------------- | -------------------- | ------------------- | -------------------------- | ---------------------------------- | ------- | -------------------- |
|
||||
| Generate | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 9) | ใช่ (outputs ตาม workflow) | ใช่ (1) | ใช่ (สูงสุด 4) |
|
||||
| Edit/reference | ใช่ (สูงสุด 5 ภาพ) | ใช่ (สูงสุด 5 ภาพ) | ใช่ (1 ภาพ) | ใช่ (1 ภาพ, subject ref) | ใช่ (1 ภาพ, กำหนดโดย workflow) | ไม่ | ใช่ (สูงสุด 5 ภาพ) |
|
||||
| Size control | ใช่ (สูงสุด 4K) | ใช่ | ใช่ | ไม่ | ไม่ | ไม่ | ไม่ |
|
||||
| Aspect ratio | ไม่ | ใช่ | ใช่ (เฉพาะ generate) | ใช่ | ไม่ | ไม่ | ใช่ |
|
||||
| Resolution (1K/2K/4K) | ไม่ | ใช่ | ใช่ | ไม่ | ไม่ | ไม่ | ใช่ (1K/2K) |
|
||||
| ความสามารถ | OpenAI | Google | fal | MiniMax | ComfyUI | Vydra | xAI |
|
||||
| ------------------- | -------------------- | -------------------- | ------------------- | -------------------------- | ---------------------------------- | ------- | -------------------- |
|
||||
| สร้าง | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 4) | ใช่ (สูงสุด 9) | ใช่ (ผลลัพธ์กำหนดโดย workflow) | ใช่ (1) | ใช่ (สูงสุด 4) |
|
||||
| แก้ไข/อ้างอิง | ใช่ (สูงสุด 5 รูป) | ใช่ (สูงสุด 5 รูป) | ใช่ (1 รูป) | ใช่ (1 รูป, อ้างอิงวัตถุหลัก) | ใช่ (1 รูป, กำหนดโดย workflow) | ไม่ | ใช่ (สูงสุด 5 รูป) |
|
||||
| ควบคุมขนาด | ใช่ (สูงสุด 4K) | ใช่ | ใช่ | ไม่ | ไม่ | ไม่ | ไม่ |
|
||||
| อัตราส่วนภาพ | ไม่ | ใช่ | ใช่ (เฉพาะการสร้าง) | ใช่ | ไม่ | ไม่ | ใช่ |
|
||||
| ความละเอียด (1K/2K/4K) | ไม่ | ใช่ | ใช่ | ไม่ | ไม่ | ไม่ | ใช่ (1K/2K) |
|
||||
|
||||
### xAI `grok-imagine-image`
|
||||
|
||||
xAI provider แบบ bundled ใช้ `/v1/images/generations` สำหรับคำขอแบบ prompt-only
|
||||
ผู้ให้บริการ xAI ที่มีมาให้ใช้ `/v1/images/generations` สำหรับคำขอที่มีเฉพาะพรอมป์ต์
|
||||
และใช้ `/v1/images/edits` เมื่อมี `image` หรือ `images`
|
||||
|
||||
- Models: `xai/grok-imagine-image`, `xai/grok-imagine-image-pro`
|
||||
- Count: สูงสุด 4
|
||||
- References: `image` หนึ่งรายการ หรือ `images` สูงสุดห้ารายการ
|
||||
- Aspect ratios: `1:1`, `16:9`, `9:16`, `4:3`, `3:4`, `2:3`, `3:2`
|
||||
- Resolutions: `1K`, `2K`
|
||||
- Outputs: คืนค่าเป็น image attachments ที่ OpenClaw จัดการให้
|
||||
- โมเดล: `xai/grok-imagine-image`, `xai/grok-imagine-image-pro`
|
||||
- จำนวน: สูงสุด 4
|
||||
- รูปภาพอ้างอิง: `image` หนึ่งรายการ หรือ `images` สูงสุดห้ารายการ
|
||||
- อัตราส่วนภาพ: `1:1`, `16:9`, `9:16`, `4:3`, `3:4`, `2:3`, `3:2`
|
||||
- ความละเอียด: `1K`, `2K`
|
||||
- ผลลัพธ์: ส่งกลับเป็นไฟล์แนบรูปภาพที่ OpenClaw จัดการให้
|
||||
|
||||
OpenClaw ตั้งใจไม่เปิดเผย `quality`, `mask`, `user` หรือ
|
||||
native-only aspect ratios เพิ่มเติมของ xAI จนกว่าตัวควบคุมเหล่านั้นจะมีอยู่ในสัญญา `image_generate` แบบใช้ร่วมกันข้าม providers
|
||||
OpenClaw ตั้งใจไม่เปิดเผย `quality`, `mask`, `user` ของ xAI โดยตรง หรือ
|
||||
อัตราส่วนภาพเพิ่มเติมที่มีเฉพาะแบบ native จนกว่าตัวควบคุมเหล่านั้นจะมีอยู่ในสัญญา
|
||||
`image_generate` แบบใช้ร่วมกันข้ามผู้ให้บริการ
|
||||
|
||||
## ที่เกี่ยวข้อง
|
||||
|
||||
- [Tools Overview](/th/tools) — เครื่องมือของเอเจนต์ทั้งหมดที่มีให้ใช้
|
||||
- [fal](/th/providers/fal) — การตั้งค่า provider สำหรับภาพและวิดีโอของ fal
|
||||
- [ComfyUI](/th/providers/comfy) — การตั้งค่า workflow ของ ComfyUI ในเครื่องและ Comfy Cloud
|
||||
- [Google (Gemini)](/th/providers/google) — การตั้งค่า provider ภาพของ Gemini
|
||||
- [MiniMax](/th/providers/minimax) — การตั้งค่า provider ภาพของ MiniMax
|
||||
- [OpenAI](/th/providers/openai) — การตั้งค่า provider OpenAI Images
|
||||
- [Vydra](/th/providers/vydra) — การตั้งค่า image, video และ speech ของ Vydra
|
||||
- [xAI](/th/providers/xai) — การตั้งค่า Grok สำหรับ image, video, search, code execution และ TTS
|
||||
- [Configuration Reference](/th/gateway/configuration-reference#agent-defaults) — การตั้งค่า `imageGenerationModel`
|
||||
- [Models](/th/concepts/models) — การตั้งค่าโมเดลและ failover
|
||||
- [ภาพรวมของเครื่องมือ](/th/tools) — เครื่องมือเอเจนต์ทั้งหมดที่พร้อมใช้งาน
|
||||
- [fal](/th/providers/fal) — การตั้งค่าผู้ให้บริการภาพและวิดีโอ fal
|
||||
- [ComfyUI](/th/providers/comfy) — การตั้งค่า workflow ของ ComfyUI ภายในเครื่องและ Comfy Cloud
|
||||
- [Google (Gemini)](/th/providers/google) — การตั้งค่าผู้ให้บริการภาพ Gemini
|
||||
- [MiniMax](/th/providers/minimax) — การตั้งค่าผู้ให้บริการภาพ MiniMax
|
||||
- [OpenAI](/th/providers/openai) — การตั้งค่าผู้ให้บริการ OpenAI Images
|
||||
- [Vydra](/th/providers/vydra) — การตั้งค่ารูปภาพ วิดีโอ และเสียงพูดของ Vydra
|
||||
- [xAI](/th/providers/xai) — การตั้งค่า Grok สำหรับรูปภาพ วิดีโอ การค้นหา การรันโค้ด และ TTS
|
||||
- [ข้อมูลอ้างอิงการกำหนดค่า](/th/gateway/configuration-reference#agent-defaults) — ค่ากำหนด `imageGenerationModel`
|
||||
- [โมเดล](/th/concepts/models) — การกำหนดค่าโมเดลและการ failover
|
||||
|
||||
@ -1,32 +1,32 @@
|
||||
---
|
||||
read_when:
|
||||
- การติดตั้งหรือกำหนดค่า plugins
|
||||
- การทำความเข้าใจ discovery ของ Plugin และกฎการโหลด
|
||||
- การทำงานกับ plugin bundles ที่เข้ากันได้กับ Codex/Claude
|
||||
- การติดตั้งหรือกำหนดค่า Plugin
|
||||
- ทำความเข้าใจกฎการค้นหาและการโหลด Plugin
|
||||
- การทำงานกับชุดรวม Plugin ที่เข้ากันได้กับ Codex/Claude
|
||||
sidebarTitle: Install and Configure
|
||||
summary: ติดตั้ง กำหนดค่า และจัดการ plugins ของ OpenClaw
|
||||
title: Plugins
|
||||
summary: ติดตั้ง กำหนดค่า และจัดการ Plugin ของ OpenClaw
|
||||
title: Plugin
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T10:24:12Z"
|
||||
generated_at: "2026-04-23T13:58:18Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: dc944b53654552ca5cf6132c6ef16c71745a7bffc249daccaee40c513e04209c
|
||||
source_hash: 63aa1b5ed9e3aaa2117b78137a457582b00ea47d94af7da3780ddae38e8e3665
|
||||
source_path: tools/plugin.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Plugins
|
||||
# Plugin
|
||||
|
||||
Plugins ช่วยขยาย OpenClaw ด้วยความสามารถใหม่: channels, model providers,
|
||||
tools, Skills, speech, realtime transcription, realtime voice,
|
||||
media-understanding, image generation, video generation, web fetch, web
|
||||
search และอื่น ๆ บาง Plugin เป็นแบบ **core** (มาพร้อมกับ OpenClaw) ส่วนบางตัว
|
||||
เป็นแบบ **external** (เผยแพร่บน npm โดยชุมชน)
|
||||
Plugin จะขยายความสามารถของ OpenClaw ด้วยฟีเจอร์ใหม่ ๆ เช่น แชนเนล ผู้ให้บริการโมเดล
|
||||
เครื่องมือ Skills เสียง การถอดเสียงแบบเรียลไทม์ เสียงแบบเรียลไทม์
|
||||
การทำความเข้าใจสื่อ การสร้างภาพ การสร้างวิดีโอ การดึงข้อมูลเว็บ การค้นหาเว็บ
|
||||
และอื่น ๆ อีกมากมาย บาง Plugin เป็น **core** (มาพร้อมกับ OpenClaw) ส่วนบางตัว
|
||||
เป็น **external** (เผยแพร่บน npm โดยชุมชน)
|
||||
|
||||
## เริ่มต้นอย่างรวดเร็ว
|
||||
|
||||
<Steps>
|
||||
<Step title="ดูว่าอะไรถูกโหลดอยู่">
|
||||
<Step title="ดูว่ามีอะไรถูกโหลดอยู่บ้าง">
|
||||
```bash
|
||||
openclaw plugins list
|
||||
```
|
||||
@ -37,7 +37,7 @@ search และอื่น ๆ บาง Plugin เป็นแบบ **core**
|
||||
# จาก npm
|
||||
openclaw plugins install @openclaw/voice-call
|
||||
|
||||
# จากไดเรกทอรีหรือ archive ภายในเครื่อง
|
||||
# จากไดเรกทอรีหรือไฟล์เก็บถาวรในเครื่อง
|
||||
openclaw plugins install ./my-plugin
|
||||
openclaw plugins install ./my-plugin.tgz
|
||||
```
|
||||
@ -54,7 +54,7 @@ search และอื่น ๆ บาง Plugin เป็นแบบ **core**
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
หากคุณต้องการควบคุมผ่านแชตแบบเนทีฟ ให้เปิดใช้ `commands.plugins: true` แล้วใช้:
|
||||
หากคุณต้องการควบคุมผ่านแชตโดยตรง ให้เปิดใช้ `commands.plugins: true` แล้วใช้:
|
||||
|
||||
```text
|
||||
/plugin install clawhub:@openclaw/voice-call
|
||||
@ -62,40 +62,40 @@ search และอื่น ๆ บาง Plugin เป็นแบบ **core**
|
||||
/plugin enable voice-call
|
||||
```
|
||||
|
||||
เส้นทางการติดตั้งใช้ resolver เดียวกับ CLI: path/archive ในเครื่อง, ระบุ
|
||||
`clawhub:<pkg>` โดยตรง หรือใช้ package spec เปล่า (ClawHub ก่อน แล้ว fallback ไป npm)
|
||||
เส้นทางการติดตั้งจะใช้ตัวแก้ไขเดียวกับ CLI: พาธหรือไฟล์เก็บถาวรในเครื่อง, `clawhub:<pkg>`
|
||||
แบบระบุชัดเจน, หรือสเปกแพ็กเกจแบบเปล่า (ClawHub ก่อน แล้วจึง fallback ไป npm)
|
||||
|
||||
หากคอนฟิกไม่ถูกต้อง โดยปกติการติดตั้งจะล้มเหลวแบบปิดและชี้คุณไปที่
|
||||
`openclaw doctor --fix` ข้อยกเว้นเดียวในการกู้คืนคือเส้นทางติดตั้ง bundled-plugin ใหม่แบบแคบ
|
||||
สำหรับ plugins ที่เลือกใช้
|
||||
หากคอนฟิกไม่ถูกต้อง โดยปกติการติดตั้งจะล้มเหลวแบบปิดทางไว้ก่อนและชี้ให้คุณไปที่
|
||||
`openclaw doctor --fix` ข้อยกเว้นด้านการกู้คืนมีเพียงเส้นทางติดตั้งใหม่ของ bundled-plugin
|
||||
แบบจำกัด สำหรับ Plugin ที่เลือกใช้
|
||||
`openclaw.install.allowInvalidConfigRecovery`
|
||||
|
||||
การติดตั้ง OpenClaw แบบแพ็กเกจจะไม่ติดตั้ง
|
||||
runtime dependency tree ของ bundled plugin ทุกตัวอย่าง eager เมื่อ bundled Plugin ที่ OpenClaw เป็นเจ้าของถูกเปิดใช้งานจาก
|
||||
plugin config, legacy channel config หรือ manifest ที่เปิดใช้งานโดยค่าเริ่มต้น
|
||||
การเริ่มต้นระบบจะซ่อมเฉพาะ runtime dependencies ที่ plugin นั้นประกาศไว้ก่อน import เท่านั้น
|
||||
ส่วน external plugins และ custom load paths ยังคงต้องติดตั้งผ่าน
|
||||
การติดตั้ง OpenClaw แบบแพ็กเกจจะไม่ติดตั้ง dependency runtime ทั้งหมดของ bundled plugin
|
||||
ทุกตัวแบบ eager ล่วงหน้า เมื่อ bundled plugin ที่ OpenClaw เป็นเจ้าของเปิดใช้งานจาก
|
||||
คอนฟิก plugin, คอนฟิกแชนเนลแบบเดิม, หรือ manifest ที่เปิดใช้เป็นค่าเริ่มต้น
|
||||
การซ่อมแซมตอนเริ่มทำงานจะซ่อมเฉพาะ dependency runtime ที่ประกาศไว้ของ Plugin นั้น
|
||||
ก่อนนำเข้าเท่านั้น ส่วน Plugin ภายนอกและพาธการโหลดแบบกำหนดเองยังคงต้องติดตั้งผ่าน
|
||||
`openclaw plugins install`
|
||||
|
||||
## ประเภทของ Plugin
|
||||
|
||||
OpenClaw รู้จัก Plugin อยู่สองรูปแบบ:
|
||||
OpenClaw รู้จักรูปแบบ Plugin สองแบบ:
|
||||
|
||||
| Format | วิธีการทำงาน | ตัวอย่าง |
|
||||
| ---------- | ------------------------------------------------------------------ | ------------------------------------------------------ |
|
||||
| **Native** | `openclaw.plugin.json` + runtime module; รันใน process เดียวกัน | plugins ทางการ, แพ็กเกจ npm จากชุมชน |
|
||||
| **Bundle** | เลย์เอาต์ที่เข้ากันได้กับ Codex/Claude/Cursor; ถูกแมปเป็นฟีเจอร์ของ OpenClaw | `.codex-plugin/`, `.claude-plugin/`, `.cursor-plugin/` |
|
||||
| รูปแบบ | วิธีการทำงาน | ตัวอย่าง |
|
||||
| ---------- | ----------------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| **Native** | `openclaw.plugin.json` + โมดูล runtime; ทำงานในโปรเซสเดียวกัน | Plugin ทางการ, แพ็กเกจ npm จากชุมชน |
|
||||
| **Bundle** | เลย์เอาต์ที่เข้ากันได้กับ Codex/Claude/Cursor; แมปเป็นความสามารถของ OpenClaw | `.codex-plugin/`, `.claude-plugin/`, `.cursor-plugin/` |
|
||||
|
||||
ทั้งสองแบบจะแสดงใน `openclaw plugins list` ดูรายละเอียด bundle ได้ที่ [Plugin Bundles](/th/plugins/bundles)
|
||||
ทั้งสองแบบจะแสดงภายใต้ `openclaw plugins list` ดูรายละเอียดของ bundle ได้ที่ [ชุดรวม Plugin](/th/plugins/bundles)
|
||||
|
||||
หากคุณกำลังเขียน native plugin ให้เริ่มที่ [Building Plugins](/th/plugins/building-plugins)
|
||||
หากคุณกำลังเขียน Native Plugin ให้เริ่มจาก [การสร้าง Plugin](/th/plugins/building-plugins)
|
||||
และ [ภาพรวม Plugin SDK](/th/plugins/sdk-overview)
|
||||
|
||||
## Plugins ทางการ
|
||||
## Plugin ทางการ
|
||||
|
||||
### ติดตั้งได้ (npm)
|
||||
|
||||
| Plugin | Package | เอกสาร |
|
||||
| Plugin | แพ็กเกจ | เอกสาร |
|
||||
| --------------- | ---------------------- | ------------------------------------ |
|
||||
| Matrix | `@openclaw/matrix` | [Matrix](/th/channels/matrix) |
|
||||
| Microsoft Teams | `@openclaw/msteams` | [Microsoft Teams](/th/channels/msteams) |
|
||||
@ -115,22 +115,22 @@ OpenClaw รู้จัก Plugin อยู่สองรูปแบบ:
|
||||
`vercel-ai-gateway`, `volcengine`, `xiaomi`, `zai`
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Memory plugins">
|
||||
- `memory-core` — memory search แบบ bundled (ค่าเริ่มต้นผ่าน `plugins.slots.memory`)
|
||||
- `memory-lancedb` — หน่วยความจำระยะยาวแบบติดตั้งเมื่อจำเป็น พร้อม auto-recall/capture (ตั้งค่า `plugins.slots.memory = "memory-lancedb"`)
|
||||
<Accordion title="Plugin หน่วยความจำ">
|
||||
- `memory-core` — การค้นหาหน่วยความจำแบบ bundled (ค่าเริ่มต้นผ่าน `plugins.slots.memory`)
|
||||
- `memory-lancedb` — หน่วยความจำระยะยาวแบบ install-on-demand พร้อมการเรียกคืน/บันทึกอัตโนมัติ (ตั้งค่า `plugins.slots.memory = "memory-lancedb"`)
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="ผู้ให้บริการ speech (เปิดใช้โดยค่าเริ่มต้น)">
|
||||
<Accordion title="ผู้ให้บริการเสียง (เปิดใช้โดยค่าเริ่มต้น)">
|
||||
`elevenlabs`, `microsoft`
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="อื่น ๆ">
|
||||
- `browser` — bundled browser plugin สำหรับ browser tool, CLI `openclaw browser`, gateway method `browser.request`, browser runtime และ browser control service เริ่มต้น (เปิดใช้โดยค่าเริ่มต้น; ปิดก่อนหากจะนำตัวอื่นมาแทน)
|
||||
- `browser` — browser plugin แบบ bundled สำหรับเครื่องมือ browser, CLI `openclaw browser`, เมธอด Gateway `browser.request`, browser runtime และบริการควบคุมเบราว์เซอร์ค่าเริ่มต้น (เปิดใช้โดยค่าเริ่มต้น; ปิดก่อนหากต้องการแทนที่)
|
||||
- `copilot-proxy` — สะพานเชื่อม VS Code Copilot Proxy (ปิดโดยค่าเริ่มต้น)
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
กำลังมองหา third-party plugins อยู่หรือไม่ ดู [Community Plugins](/th/plugins/community)
|
||||
กำลังมองหา Plugin จากบุคคลที่สามอยู่หรือไม่ ดู [Plugin จากชุมชน](/th/plugins/community)
|
||||
|
||||
## การกำหนดค่า
|
||||
|
||||
@ -148,103 +148,103 @@ OpenClaw รู้จัก Plugin อยู่สองรูปแบบ:
|
||||
}
|
||||
```
|
||||
|
||||
| Field | คำอธิบาย |
|
||||
| ฟิลด์ | คำอธิบาย |
|
||||
| ---------------- | --------------------------------------------------------- |
|
||||
| `enabled` | สวิตช์หลัก (ค่าเริ่มต้น: `true`) |
|
||||
| `allow` | allowlist ของ Plugin (ไม่บังคับ) |
|
||||
| `deny` | denylist ของ Plugin (ไม่บังคับ; deny มีผลเหนือกว่า) |
|
||||
| `enabled` | สวิตช์หลัก (ค่าเริ่มต้น: `true`) |
|
||||
| `allow` | allowlist ของ Plugin (ไม่บังคับ) |
|
||||
| `deny` | denylist ของ Plugin (ไม่บังคับ; deny มีสิทธิ์เหนือกว่า) |
|
||||
| `load.paths` | ไฟล์/ไดเรกทอรี Plugin เพิ่มเติม |
|
||||
| `slots` | ตัวเลือก slot แบบ exclusive (เช่น `memory`, `contextEngine`) |
|
||||
| `entries.\<id\>` | สวิตช์ต่อ Plugin + คอนฟิก |
|
||||
| `entries.\<id\>` | สวิตช์เปิด/ปิด + คอนฟิกราย Plugin |
|
||||
|
||||
การเปลี่ยนคอนฟิก **ต้องรีสตาร์ต gateway** หาก Gateway กำลังทำงานพร้อม config
|
||||
watch + in-process restart (ซึ่งเป็นค่าเริ่มต้นของเส้นทาง `openclaw gateway`)
|
||||
โดยปกติการรีสตาร์ตนั้นจะเกิดขึ้นโดยอัตโนมัติไม่นานหลังจากเขียนคอนฟิกเสร็จ
|
||||
การเปลี่ยนคอนฟิก **ต้องรีสตาร์ต gateway** หาก Gateway กำลังทำงานพร้อมการเฝ้าดูคอนฟิก
|
||||
และเปิดใช้การรีสตาร์ตในโปรเซสไว้ (ซึ่งเป็นพฤติกรรมค่าเริ่มต้นของเส้นทาง `openclaw gateway`)
|
||||
โดยปกติการรีสตาร์ตนั้นจะเกิดขึ้นโดยอัตโนมัติไม่นานหลังจากมีการเขียนคอนฟิก
|
||||
|
||||
<Accordion title="สถานะของ Plugin: disabled vs missing vs invalid">
|
||||
- **Disabled**: มี plugin อยู่ แต่กฎการเปิดใช้ทำให้มันถูกปิด คอนฟิกยังคงถูกเก็บไว้
|
||||
- **Missing**: คอนฟิกอ้างถึง plugin id ที่ discovery หาไม่เจอ
|
||||
- **Invalid**: มี plugin อยู่ แต่คอนฟิกไม่ตรงกับ schema ที่ประกาศไว้
|
||||
<Accordion title="สถานะ Plugin: ปิดใช้งาน เทียบกับ ไม่พบ เทียบกับ ไม่ถูกต้อง">
|
||||
- **ปิดใช้งาน**: มี Plugin อยู่ แต่กฎการเปิดใช้ปิดมันไว้ คอนฟิกจะยังคงถูกเก็บไว้
|
||||
- **ไม่พบ**: คอนฟิกอ้างถึงรหัส Plugin ที่การค้นหาไม่พบ
|
||||
- **ไม่ถูกต้อง**: มี Plugin อยู่ แต่คอนฟิกของมันไม่ตรงกับ schema ที่ประกาศไว้
|
||||
</Accordion>
|
||||
|
||||
## Discovery และลำดับความสำคัญ
|
||||
## การค้นหาและลำดับความสำคัญ
|
||||
|
||||
OpenClaw สแกนหา plugins ตามลำดับนี้ (ตัวแรกที่ตรงจะชนะ):
|
||||
OpenClaw จะสแกนหา Plugin ตามลำดับนี้ (ที่พบก่อนมีสิทธิ์ก่อน):
|
||||
|
||||
<Steps>
|
||||
<Step title="Config paths">
|
||||
`plugins.load.paths` — paths ของไฟล์หรือไดเรกทอรีที่ระบุชัดเจน
|
||||
<Step title="พาธในคอนฟิก">
|
||||
`plugins.load.paths` — พาธไฟล์หรือไดเรกทอรีที่ระบุชัดเจน
|
||||
</Step>
|
||||
|
||||
<Step title="Workspace plugins">
|
||||
<Step title="Plugin ใน workspace">
|
||||
`\<workspace\>/.openclaw/<plugin-root>/*.ts` และ `\<workspace\>/.openclaw/<plugin-root>/*/index.ts`
|
||||
</Step>
|
||||
|
||||
<Step title="Global plugins">
|
||||
<Step title="Plugin แบบ global">
|
||||
`~/.openclaw/<plugin-root>/*.ts` และ `~/.openclaw/<plugin-root>/*/index.ts`
|
||||
</Step>
|
||||
|
||||
<Step title="Bundled plugins">
|
||||
มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (model providers, speech)
|
||||
ส่วนตัวอื่นต้องเปิดใช้แบบชัดเจน
|
||||
<Step title="Plugin แบบ bundled">
|
||||
มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (ผู้ให้บริการโมเดล, เสียง)
|
||||
ส่วนตัวอื่นต้องเปิดใช้แบบระบุชัดเจน
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
### กฎการเปิดใช้
|
||||
|
||||
- `plugins.enabled: false` ปิด plugins ทั้งหมด
|
||||
- `plugins.deny` มีผลเหนือกว่า `allow` เสมอ
|
||||
- `plugins.entries.\<id\>.enabled: false` ปิด plugin นั้น
|
||||
- plugins ที่มาจาก workspace จะ **ปิดโดยค่าเริ่มต้น** (ต้องเปิดใช้อย่างชัดเจน)
|
||||
- bundled plugins เป็นไปตามชุด default-on ที่มีมาให้ เว้นแต่จะมีการ override
|
||||
- exclusive slots สามารถบังคับเปิด plugin ที่ถูกเลือกสำหรับ slot นั้นได้
|
||||
- `plugins.enabled: false` จะปิดใช้งาน Plugin ทั้งหมด
|
||||
- `plugins.deny` มีสิทธิ์เหนือกว่า allow เสมอ
|
||||
- `plugins.entries.\<id\>.enabled: false` จะปิดใช้งาน Plugin นั้น
|
||||
- Plugin ที่มาจาก workspace จะ **ปิดใช้งานโดยค่าเริ่มต้น** (ต้องเปิดใช้แบบระบุชัดเจน)
|
||||
- bundled plugin จะเป็นไปตามชุดค่าเริ่มต้นที่เปิดใช้อยู่ในระบบ เว้นแต่จะมีการ override
|
||||
- slot แบบ exclusive สามารถบังคับเปิดใช้ Plugin ที่ถูกเลือกสำหรับ slot นั้นได้
|
||||
|
||||
## slots ของ Plugin (หมวดหมู่แบบ exclusive)
|
||||
## Plugin slots (หมวดหมู่แบบ exclusive)
|
||||
|
||||
บางหมวดหมู่เป็นแบบ exclusive (มีตัวที่ทำงานได้เพียงตัวเดียวในเวลาเดียวกัน):
|
||||
บางหมวดหมู่เป็นแบบ exclusive (เปิดใช้งานได้ครั้งละตัวเดียว):
|
||||
|
||||
```json5
|
||||
{
|
||||
plugins: {
|
||||
slots: {
|
||||
memory: "memory-core", // หรือ "none" เพื่อปิด
|
||||
contextEngine: "legacy", // หรือ plugin id
|
||||
memory: "memory-core", // หรือ "none" เพื่อปิดใช้งาน
|
||||
contextEngine: "legacy", // หรือรหัส plugin
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
| Slot | ควบคุมอะไร | ค่าเริ่มต้น |
|
||||
| --------------- | --------------------- | ------------------- |
|
||||
| `memory` | memory plugin ที่ใช้งานอยู่ | `memory-core` |
|
||||
| `contextEngine` | context engine ที่ใช้งานอยู่ | `legacy` (built-in) |
|
||||
| Slot | สิ่งที่ควบคุม | ค่าเริ่มต้น |
|
||||
| --------------- | ------------------------- | ------------------- |
|
||||
| `memory` | Active Memory plugin | `memory-core` |
|
||||
| `contextEngine` | กลไกบริบทที่ใช้งานอยู่ | `legacy` (มีมาในตัว) |
|
||||
|
||||
## เอกสารอ้างอิง CLI
|
||||
|
||||
```bash
|
||||
openclaw plugins list # รายการแบบย่อ
|
||||
openclaw plugins list --enabled # เฉพาะ plugins ที่ถูกโหลด
|
||||
openclaw plugins list --verbose # บรรทัดรายละเอียดต่อ plugin
|
||||
openclaw plugins list --json # รายการแบบ machine-readable
|
||||
openclaw plugins list # รายการสินค้าคงคลังแบบย่อ
|
||||
openclaw plugins list --enabled # เฉพาะ Plugin ที่ถูกโหลด
|
||||
openclaw plugins list --verbose # รายละเอียดต่อ Plugin
|
||||
openclaw plugins list --json # สินค้าคงคลังแบบอ่านได้โดยเครื่อง
|
||||
openclaw plugins inspect <id> # รายละเอียดเชิงลึก
|
||||
openclaw plugins inspect <id> --json # แบบ machine-readable
|
||||
openclaw plugins inspect --all # ตารางทั้งระบบ
|
||||
openclaw plugins inspect <id> --json # แบบอ่านได้โดยเครื่อง
|
||||
openclaw plugins inspect --all # ตารางทั้งชุด
|
||||
openclaw plugins info <id> # alias ของ inspect
|
||||
openclaw plugins doctor # diagnostics
|
||||
openclaw plugins doctor # การวินิจฉัย
|
||||
|
||||
openclaw plugins install <package> # ติดตั้ง (ClawHub ก่อน แล้ว npm)
|
||||
openclaw plugins install <package> # ติดตั้ง (ClawHub ก่อน แล้วจึง npm)
|
||||
openclaw plugins install clawhub:<pkg> # ติดตั้งจาก ClawHub เท่านั้น
|
||||
openclaw plugins install <spec> --force # เขียนทับการติดตั้งที่มีอยู่
|
||||
openclaw plugins install <path> # ติดตั้งจาก path ในเครื่อง
|
||||
openclaw plugins install -l <path> # ลิงก์ (ไม่คัดลอก) สำหรับ dev
|
||||
openclaw plugins install <path> # ติดตั้งจากพาธในเครื่อง
|
||||
openclaw plugins install -l <path> # ลิงก์ (ไม่คัดลอก) สำหรับการพัฒนา
|
||||
openclaw plugins install <plugin> --marketplace <source>
|
||||
openclaw plugins install <plugin> --marketplace https://github.com/<owner>/<repo>
|
||||
openclaw plugins install <spec> --pin # บันทึก npm spec ที่ resolve แบบตรงตัว
|
||||
openclaw plugins install <spec> --pin # บันทึกสเปก npm ที่ resolve แบบเจาะจง
|
||||
openclaw plugins install <spec> --dangerously-force-unsafe-install
|
||||
openclaw plugins update <id-or-npm-spec> # อัปเดต plugin เดียว
|
||||
openclaw plugins update <id-or-npm-spec> # อัปเดต Plugin หนึ่งตัว
|
||||
openclaw plugins update <id-or-npm-spec> --dangerously-force-unsafe-install
|
||||
openclaw plugins update --all # อัปเดตทั้งหมด
|
||||
openclaw plugins uninstall <id> # ลบคอนฟิก/ระเบียนการติดตั้ง
|
||||
openclaw plugins uninstall <id> # ลบระเบียนคอนฟิก/การติดตั้ง
|
||||
openclaw plugins uninstall <id> --keep-files
|
||||
openclaw plugins marketplace list <source>
|
||||
openclaw plugins marketplace list <source> --json
|
||||
@ -253,56 +253,62 @@ openclaw plugins enable <id>
|
||||
openclaw plugins disable <id>
|
||||
```
|
||||
|
||||
bundled plugins มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (เช่น
|
||||
bundled model providers, bundled speech providers และ bundled browser
|
||||
plugin) ส่วน bundled plugins ตัวอื่นยังคงต้องใช้ `openclaw plugins enable <id>`
|
||||
bundled plugin จะมาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (เช่น
|
||||
bundled ผู้ให้บริการโมเดล, bundled ผู้ให้บริการเสียง, และ bundled browser
|
||||
plugin) ส่วน bundled plugin อื่น ๆ ยังต้องใช้ `openclaw plugins enable <id>`
|
||||
|
||||
`--force` จะเขียนทับ installed plugin หรือ hook pack ที่มีอยู่ในตำแหน่งเดิม ใช้
|
||||
`openclaw plugins update <id-or-npm-spec>` สำหรับการอัปเกรดตามปกติของ tracked npm
|
||||
plugins โดยไม่รองรับร่วมกับ `--link` ซึ่งจะใช้ source path เดิมซ้ำ
|
||||
แทนการคัดลอกไปยัง managed install target
|
||||
`--force` จะเขียนทับ Plugin หรือ hook pack ที่ติดตั้งอยู่แล้วในตำแหน่งเดิม ใช้
|
||||
`openclaw plugins update <id-or-npm-spec>` สำหรับการอัปเกรดตามปกติของ npm
|
||||
plugin ที่ติดตามอยู่ ไม่รองรับการใช้ร่วมกับ `--link` ซึ่งจะใช้พาธต้นทางซ้ำแทน
|
||||
การคัดลอกไปยังปลายทางการติดตั้งที่จัดการโดยระบบ
|
||||
|
||||
`openclaw plugins update <id-or-npm-spec>` ใช้กับ tracked installs การส่ง
|
||||
npm package spec ที่มี dist-tag หรือเวอร์ชันแบบตรงตัวจะ resolve ชื่อแพ็กเกจ
|
||||
กลับไปยัง tracked plugin record และบันทึก spec ใหม่ไว้สำหรับการอัปเดตในอนาคต
|
||||
การส่งชื่อแพ็กเกจโดยไม่มีเวอร์ชันจะย้าย exact pinned install กลับไปสู่
|
||||
release line เริ่มต้นของ registry หาก installed npm plugin ตรงกับเวอร์ชันที่ resolve แล้ว
|
||||
และ identity ของ artifact ที่บันทึกไว้ OpenClaw จะข้ามการอัปเดต
|
||||
โดยไม่ดาวน์โหลด ติดตั้งใหม่ หรือเขียนคอนฟิกซ้ำ
|
||||
เมื่อมีการตั้งค่า `plugins.allow` อยู่แล้ว `openclaw plugins install` จะเพิ่ม
|
||||
รหัส Plugin ที่ติดตั้งเข้าไปใน allowlist นั้นก่อนเปิดใช้งาน เพื่อให้โหลดได้ทันที
|
||||
หลังรีสตาร์ต
|
||||
|
||||
`--pin` ใช้ได้กับ npm เท่านั้น และไม่รองรับร่วมกับ `--marketplace` เพราะ
|
||||
การติดตั้งผ่าน marketplace จะเก็บ metadata ของแหล่ง marketplace แทน npm spec
|
||||
`openclaw plugins update <id-or-npm-spec>` ใช้กับการติดตั้งที่ติดตามอยู่ การส่ง
|
||||
สเปกแพ็กเกจ npm ที่มี dist-tag หรือเวอร์ชันแบบเจาะจงจะ resolve ชื่อแพ็กเกจกลับไปยัง
|
||||
ระเบียน Plugin ที่ติดตามอยู่ และบันทึกสเปกใหม่ไว้สำหรับการอัปเดตครั้งถัดไป
|
||||
การส่งชื่อแพ็กเกจโดยไม่มีเวอร์ชันจะย้ายการติดตั้งแบบ pinned เวอร์ชันแน่นอนกลับไปยัง
|
||||
สายรีลีสค่าเริ่มต้นของ registry หาก npm plugin ที่ติดตั้งอยู่ตรงกับเวอร์ชันที่ resolve ได้
|
||||
และ identity ของ artifact ที่บันทึกไว้แล้ว OpenClaw จะข้ามการอัปเดตโดยไม่ดาวน์โหลด
|
||||
ติดตั้งใหม่ หรือเขียนคอนฟิกใหม่
|
||||
|
||||
`--dangerously-force-unsafe-install` คือ override แบบ break-glass สำหรับ false
|
||||
positives จาก dangerous-code scanner ที่มีมาในระบบ มันอนุญาตให้การติดตั้ง plugin
|
||||
และการอัปเดต plugin ดำเนินต่อไปแม้มีผลการตรวจพบระดับ `critical` จากระบบ แต่ยังคง
|
||||
ไม่ข้ามการบล็อกจากนโยบาย `before_install` ของ plugin หรือการบล็อกจาก scan-failure
|
||||
`--pin` ใช้ได้กับ npm เท่านั้น ไม่รองรับร่วมกับ `--marketplace` เพราะการติดตั้งจาก
|
||||
marketplace จะเก็บ metadata ของแหล่งที่มาจาก marketplace แทนสเปก npm
|
||||
|
||||
แฟล็ก CLI นี้ใช้กับโฟลว์ติดตั้ง/อัปเดต plugin เท่านั้น การติดตั้ง dependency ของ Skills ที่รองรับผ่าน Gateway
|
||||
จะใช้ request override `dangerouslyForceUnsafeInstall` ที่ตรงกันแทน ส่วน `openclaw skills install` ยังคงเป็นโฟลว์ดาวน์โหลด/ติดตั้ง Skills จาก ClawHub แยกต่างหาก
|
||||
`--dangerously-force-unsafe-install` เป็นตัวเลือก override แบบ break-glass สำหรับ
|
||||
false positive จากตัวสแกนโค้ดอันตรายในตัว อนุญาตให้การติดตั้ง Plugin
|
||||
และการอัปเดต Plugin ดำเนินต่อไปได้แม้จะพบผลลัพธ์ `critical` จากระบบในตัว แต่ก็ยัง
|
||||
ไม่ข้ามการบล็อกตามนโยบาย `before_install` ของ Plugin หรือการบล็อกจากความล้มเหลวในการสแกน
|
||||
|
||||
bundle ที่เข้ากันได้จะเข้าร่วมในโฟลว์ list/inspect/enable/disable ของ plugin เดียวกัน
|
||||
ปัจจุบันรองรับ runtime ของ bundle skills, Claude command-skills,
|
||||
ค่าเริ่มต้นจาก Claude `settings.json`, ค่าเริ่มต้นจาก Claude `.lsp.json` และ
|
||||
แฟล็ก CLI นี้ใช้กับ flow การติดตั้ง/อัปเดต Plugin เท่านั้น การติดตั้ง dependency ของ Skills
|
||||
ที่อาศัย Gateway จะใช้ request override ชื่อ `dangerouslyForceUnsafeInstall`
|
||||
ที่สอดคล้องกันแทน ขณะที่ `openclaw skills install` ยังคงเป็น flow แยกต่างหากสำหรับ
|
||||
การดาวน์โหลด/ติดตั้ง Skills จาก ClawHub
|
||||
|
||||
bundle ที่เข้ากันได้จะเข้าร่วม flow เดียวกันของการแสดงรายการ/ตรวจสอบ/เปิดใช้/ปิดใช้
|
||||
Plugin รองรับ runtime ในปัจจุบันรวมถึง bundle skills, Claude command-skills,
|
||||
ค่าเริ่มต้นของ Claude `settings.json`, ค่าเริ่มต้นของ Claude `.lsp.json` และ
|
||||
`lspServers` ที่ประกาศใน manifest, Cursor command-skills และไดเรกทอรี hook ของ Codex
|
||||
ที่เข้ากันได้
|
||||
|
||||
`openclaw plugins inspect <id>` ยังรายงาน bundle capabilities ที่ตรวจพบ พร้อมทั้ง
|
||||
รายการ MCP และ LSP server entries ที่รองรับหรือไม่รองรับสำหรับ bundle-backed plugins
|
||||
`openclaw plugins inspect <id>` ยังรายงานความสามารถของ bundle ที่ตรวจพบ รวมถึง
|
||||
รายการ MCP และเซิร์ฟเวอร์ LSP ที่รองรับหรือไม่รองรับสำหรับ Plugin ที่อิง bundle ด้วย
|
||||
|
||||
แหล่ง marketplace อาจเป็นชื่อ known-marketplace ของ Claude จาก
|
||||
`~/.claude/plugins/known_marketplaces.json`, root ของ marketplace ในเครื่องหรือ path ของ
|
||||
`marketplace.json`, shorthand ของ GitHub เช่น `owner/repo`, URL ของ GitHub repo
|
||||
หรือ git URL สำหรับ remote marketplaces รายการ plugin ต้องอยู่ภายใน
|
||||
repo ของ marketplace ที่ถูก clone และใช้เฉพาะแหล่งที่มาแบบ relative path เท่านั้น
|
||||
แหล่งที่มาของ marketplace สามารถเป็นชื่อ known-marketplace ของ Claude จาก
|
||||
`~/.claude/plugins/known_marketplaces.json`, root ของ marketplace ในเครื่อง หรือพาธ
|
||||
`marketplace.json`, รูปแบบย่อ GitHub เช่น `owner/repo`, URL ของ repo บน GitHub
|
||||
หรือ URL ของ git ก็ได้ สำหรับ marketplace ระยะไกล รายการ Plugin จะต้องอยู่ภายใน
|
||||
repo ของ marketplace ที่ถูกโคลน และใช้เฉพาะแหล่งที่มาแบบพาธสัมพัทธ์เท่านั้น
|
||||
|
||||
ดูรายละเอียดทั้งหมดได้ที่ [เอกสารอ้างอิง CLI ของ `openclaw plugins`](/th/cli/plugins)
|
||||
ดูรายละเอียดทั้งหมดได้ที่ [เอกสารอ้างอิง CLI `openclaw plugins`](/th/cli/plugins)
|
||||
|
||||
## ภาพรวม Plugin API
|
||||
|
||||
native plugins จะ export entry object ที่เปิดเผย `register(api)` ส่วน plugins
|
||||
รุ่นเก่าอาจยังใช้ `activate(api)` เป็น alias แบบ legacy ได้ แต่ plugins ใหม่ควร
|
||||
ใช้ `register`
|
||||
Native plugin จะ export ออบเจ็กต์ entry ที่เปิดเผย `register(api)` Plugin รุ่นเก่า
|
||||
อาจยังใช้ `activate(api)` เป็น alias แบบ legacy ได้ แต่ Plugin ใหม่ควรใช้
|
||||
`register`
|
||||
|
||||
```typescript
|
||||
export default definePluginEntry({
|
||||
@ -322,48 +328,48 @@ export default definePluginEntry({
|
||||
});
|
||||
```
|
||||
|
||||
OpenClaw จะโหลด entry object และเรียก `register(api)` ระหว่างการ
|
||||
เปิดใช้งาน plugin loader ยังคง fallback ไปใช้ `activate(api)` สำหรับ plugins รุ่นเก่า
|
||||
แต่ bundled plugins และ external plugins ใหม่ควรมองว่า `register` คือสัญญาสาธารณะ
|
||||
OpenClaw จะโหลดออบเจ็กต์ entry และเรียก `register(api)` ระหว่างการเปิดใช้งาน Plugin
|
||||
ตัวโหลดจะยังคง fallback ไปใช้ `activate(api)` สำหรับ Plugin รุ่นเก่า แต่ bundled plugin
|
||||
และ Plugin ภายนอกตัวใหม่ควรมองว่า `register` เป็นสัญญาสาธารณะ
|
||||
|
||||
วิธีการลงทะเบียนที่ใช้บ่อย:
|
||||
เมธอดการลงทะเบียนที่ใช้บ่อย:
|
||||
|
||||
| Method | สิ่งที่มันลงทะเบียน |
|
||||
| --------------------------------------- | --------------------------- |
|
||||
| `registerProvider` | ผู้ให้บริการโมเดล (LLM) |
|
||||
| `registerChannel` | ช่องแชต |
|
||||
| `registerTool` | tool ของเอเจนต์ |
|
||||
| `registerHook` / `on(...)` | lifecycle hooks |
|
||||
| `registerSpeechProvider` | text-to-speech / STT |
|
||||
| เมธอด | สิ่งที่ลงทะเบียน |
|
||||
| -------------------------------------- | --------------------------- |
|
||||
| `registerProvider` | ผู้ให้บริการโมเดล (LLM) |
|
||||
| `registerChannel` | แชนเนลแชต |
|
||||
| `registerTool` | เครื่องมือของเอเจนต์ |
|
||||
| `registerHook` / `on(...)` | hook ของวงจรชีวิต |
|
||||
| `registerSpeechProvider` | การแปลงข้อความเป็นเสียง / STT |
|
||||
| `registerRealtimeTranscriptionProvider` | STT แบบสตรีม |
|
||||
| `registerRealtimeVoiceProvider` | เสียงเรียลไทม์แบบสองทาง |
|
||||
| `registerMediaUnderstandingProvider` | การวิเคราะห์ภาพ/เสียง |
|
||||
| `registerImageGenerationProvider` | การสร้างภาพ |
|
||||
| `registerMusicGenerationProvider` | การสร้างเพลง |
|
||||
| `registerVideoGenerationProvider` | การสร้างวิดีโอ |
|
||||
| `registerWebFetchProvider` | ผู้ให้บริการ web fetch / scrape |
|
||||
| `registerWebSearchProvider` | การค้นหาเว็บ |
|
||||
| `registerHttpRoute` | HTTP endpoint |
|
||||
| `registerCommand` / `registerCli` | คำสั่ง CLI |
|
||||
| `registerContextEngine` | context engine |
|
||||
| `registerService` | background service |
|
||||
| `registerRealtimeVoiceProvider` | เสียงแบบเรียลไทม์สองทิศทาง |
|
||||
| `registerMediaUnderstandingProvider` | การวิเคราะห์ภาพ/เสียง |
|
||||
| `registerImageGenerationProvider` | การสร้างภาพ |
|
||||
| `registerMusicGenerationProvider` | การสร้างเพลง |
|
||||
| `registerVideoGenerationProvider` | การสร้างวิดีโอ |
|
||||
| `registerWebFetchProvider` | ผู้ให้บริการดึงข้อมูล / scrape เว็บ |
|
||||
| `registerWebSearchProvider` | การค้นหาเว็บ |
|
||||
| `registerHttpRoute` | endpoint HTTP |
|
||||
| `registerCommand` / `registerCli` | คำสั่ง CLI |
|
||||
| `registerContextEngine` | กลไกบริบท |
|
||||
| `registerService` | บริการเบื้องหลัง |
|
||||
|
||||
พฤติกรรมของ hook guard สำหรับ typed lifecycle hooks:
|
||||
พฤติกรรม guard ของ hook สำหรับ hook วงจรชีวิตแบบกำหนดชนิด:
|
||||
|
||||
- `before_tool_call`: `{ block: true }` เป็นคำตัดสินสุดท้าย; handlers ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `before_tool_call`: `{ block: false }` ไม่ทำอะไร และไม่ยกเลิก block ก่อนหน้า
|
||||
- `before_install`: `{ block: true }` เป็นคำตัดสินสุดท้าย; handlers ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `before_install`: `{ block: false }` ไม่ทำอะไร และไม่ยกเลิก block ก่อนหน้า
|
||||
- `message_sending`: `{ cancel: true }` เป็นคำตัดสินสุดท้าย; handlers ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `message_sending`: `{ cancel: false }` ไม่ทำอะไร และไม่ยกเลิก cancel ก่อนหน้า
|
||||
- `before_tool_call`: `{ block: true }` เป็นสถานะสิ้นสุด; handler ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `before_tool_call`: `{ block: false }` ไม่มีผล และจะไม่ล้างการ block ที่เกิดขึ้นก่อนหน้า
|
||||
- `before_install`: `{ block: true }` เป็นสถานะสิ้นสุด; handler ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `before_install`: `{ block: false }` ไม่มีผล และจะไม่ล้างการ block ที่เกิดขึ้นก่อนหน้า
|
||||
- `message_sending`: `{ cancel: true }` เป็นสถานะสิ้นสุด; handler ที่มีลำดับความสำคัญต่ำกว่าจะถูกข้าม
|
||||
- `message_sending`: `{ cancel: false }` ไม่มีผล และจะไม่ล้างการ cancel ที่เกิดขึ้นก่อนหน้า
|
||||
|
||||
สำหรับพฤติกรรมเต็มของ typed hook ดู [ภาพรวม SDK](/th/plugins/sdk-overview#hook-decision-semantics)
|
||||
สำหรับพฤติกรรม hook แบบกำหนดชนิดทั้งหมด ดู [ภาพรวม SDK](/th/plugins/sdk-overview#hook-decision-semantics)
|
||||
|
||||
## ที่เกี่ยวข้อง
|
||||
|
||||
- [Building Plugins](/th/plugins/building-plugins) — สร้าง plugin ของคุณเอง
|
||||
- [Plugin Bundles](/th/plugins/bundles) — ความเข้ากันได้ของ bundle สำหรับ Codex/Claude/Cursor
|
||||
- [การสร้าง Plugin](/th/plugins/building-plugins) — สร้าง plugin ของคุณเอง
|
||||
- [ชุดรวม Plugin](/th/plugins/bundles) — ความเข้ากันได้ของ bundle กับ Codex/Claude/Cursor
|
||||
- [Plugin Manifest](/th/plugins/manifest) — schema ของ manifest
|
||||
- [Registering Tools](/th/plugins/building-plugins#registering-agent-tools) — เพิ่ม tools ของเอเจนต์ใน plugin
|
||||
- [Plugin Internals](/th/plugins/architecture) — โมเดล capability และไปป์ไลน์การโหลด
|
||||
- [Community Plugins](/th/plugins/community) — รายการ third-party
|
||||
- [การลงทะเบียนเครื่องมือ](/th/plugins/building-plugins#registering-agent-tools) — เพิ่มเครื่องมือของเอเจนต์ใน Plugin
|
||||
- [โครงสร้างภายในของ Plugin](/th/plugins/architecture) — โมเดลความสามารถและไปป์ไลน์การโหลด
|
||||
- [Plugin จากชุมชน](/th/plugins/community) — รายการจากบุคคลที่สาม
|
||||
|
||||
@ -1,36 +1,37 @@
|
||||
---
|
||||
read_when:
|
||||
- การใช้หรือการตั้งค่าคำสั่งแชต
|
||||
- การดีบักการกำหนดเส้นทางคำสั่งหรือสิทธิ์ใช้งาน
|
||||
summary: 'คำสั่ง Slash: แบบข้อความเทียบกับแบบ native, การตั้งค่า และคำสั่งที่รองรับ'
|
||||
title: คำสั่ง Slash
|
||||
- การใช้หรือการกำหนดค่าคำสั่งแชต
|
||||
- การดีบักการกำหนดเส้นทางคำสั่งหรือสิทธิ์
|
||||
summary: 'คำสั่งแบบสแลช: ข้อความเทียบกับแบบเนทีฟ, การกำหนดค่า และคำสั่งที่รองรับ'
|
||||
title: คำสั่งแบบสแลช
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T10:24:08Z"
|
||||
generated_at: "2026-04-23T13:58:16Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 0f6b454afa77cf02b2c307efcc99ef35d002cb560c427affaf03ac12b2b666e8
|
||||
source_hash: 13290dcdf649ae66603a92a0aca68460bb63ff476179cc2dded796aaa841d66c
|
||||
source_path: tools/slash-commands.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# คำสั่ง Slash
|
||||
# คำสั่งแบบสแลช
|
||||
|
||||
คำสั่งจะถูกจัดการโดย Gateway คำสั่งส่วนใหญ่ต้องส่งเป็นข้อความ **แบบเดี่ยว** ที่ขึ้นต้นด้วย `/`
|
||||
คำสั่ง bash แบบเฉพาะโฮสต์ใช้ `! <cmd>` (โดยมี `/bash <cmd>` เป็น alias)
|
||||
คำสั่งจะถูกจัดการโดย Gateway คำสั่งส่วนใหญ่ต้องส่งเป็นข้อความแบบ **เดี่ยว ๆ** ที่ขึ้นต้นด้วย `/`
|
||||
คำสั่งแชต bash แบบโฮสต์เท่านั้นใช้ `! <cmd>` (โดยมี `/bash <cmd>` เป็นนามแฝง)
|
||||
|
||||
มีสองระบบที่เกี่ยวข้องกัน:
|
||||
|
||||
- **Commands**: ข้อความ `/...` แบบเดี่ยว
|
||||
- **Commands**: ข้อความ `/...` แบบเดี่ยว ๆ
|
||||
- **Directives**: `/think`, `/fast`, `/verbose`, `/trace`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`
|
||||
- Directives จะถูกตัดออกจากข้อความก่อนที่โมเดลจะเห็น
|
||||
- ในข้อความแชตปกติ (ไม่ใช่ข้อความที่มีแต่ directive) จะถือเป็น “inline hints” และจะ **ไม่** คงการตั้งค่าไว้ในเซสชัน
|
||||
- ในข้อความที่มีแต่ directive (ข้อความมีเพียง directives เท่านั้น) จะคงค่าไว้ในเซสชันและตอบกลับด้วยข้อความยืนยัน
|
||||
- Directives จะถูกนำไปใช้เฉพาะกับ **ผู้ส่งที่ได้รับอนุญาต** เท่านั้น หากมีการตั้งค่า `commands.allowFrom` ระบบจะใช้ allowlist นี้เพียงอย่างเดียว มิฉะนั้นการอนุญาตจะมาจาก allowlist/การจับคู่ของช่องทางร่วมกับ `commands.useAccessGroups` ผู้ส่งที่ไม่ได้รับอนุญาตจะเห็น directives ถูกปฏิบัติเสมือนข้อความธรรมดา
|
||||
- ในข้อความแชตปกติ (ไม่ใช่ข้อความที่มีเฉพาะ directive) จะถือเป็น “คำใบ้ในบรรทัด” และจะ **ไม่** คงค่าการตั้งค่าของเซสชัน
|
||||
- ในข้อความที่มีเฉพาะ directive (ข้อความมีแต่ directives เท่านั้น) ค่าจะคงอยู่ในเซสชันและตอบกลับด้วยการยืนยัน
|
||||
- Directives จะถูกนำไปใช้เฉพาะกับ **ผู้ส่งที่ได้รับอนุญาต** เท่านั้น หากตั้งค่า `commands.allowFrom` ไว้ จะใช้เป็นรายการอนุญาตเพียงรายการเดียว มิฉะนั้นการอนุญาตจะมาจากรายการอนุญาต/การจับคู่ของช่องทางร่วมกับ `commands.useAccessGroups`
|
||||
ผู้ส่งที่ไม่ได้รับอนุญาตจะเห็น directives ถูกปฏิบัติเสมือนเป็นข้อความธรรมดา
|
||||
|
||||
ยังมี **inline shortcuts** บางรายการด้วย (เฉพาะผู้ส่งที่อยู่ใน allowlist/ได้รับอนุญาต): `/help`, `/commands`, `/status`, `/whoami` (`/id`)
|
||||
คำสั่งเหล่านี้จะทำงานทันที ถูกตัดออกก่อนที่โมเดลจะเห็น และข้อความที่เหลือจะดำเนินต่อผ่าน flow ปกติ
|
||||
ยังมี **ทางลัดแบบอินไลน์** บางรายการด้วย (เฉพาะผู้ส่งที่อยู่ในรายการอนุญาต/ได้รับอนุญาต): `/help`, `/commands`, `/status`, `/whoami` (`/id`)
|
||||
คำสั่งเหล่านี้จะทำงานทันที ถูกตัดออกก่อนที่โมเดลจะเห็นข้อความ และข้อความที่เหลือจะดำเนินต่อไปตามโฟลว์ปกติ
|
||||
|
||||
## การตั้งค่า
|
||||
## การกำหนดค่า
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -57,109 +58,109 @@ x-i18n:
|
||||
}
|
||||
```
|
||||
|
||||
- `commands.text` (ค่าเริ่มต้น `true`) เปิดใช้การพาร์ส `/...` ในข้อความแชต
|
||||
- บนพื้นผิวที่ไม่มีคำสั่ง native (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) คำสั่งแบบข้อความจะยังคงทำงานแม้ว่าคุณจะตั้งค่านี้เป็น `false`
|
||||
- `commands.native` (ค่าเริ่มต้น `"auto"`) ลงทะเบียนคำสั่ง native
|
||||
- Auto: เปิดสำหรับ Discord/Telegram; ปิดสำหรับ Slack (จนกว่าคุณจะเพิ่ม slash command); ไม่สนใจสำหรับ provider ที่ไม่รองรับ native
|
||||
- ตั้งค่า `channels.discord.commands.native`, `channels.telegram.commands.native` หรือ `channels.slack.commands.native` เพื่อ override ราย provider (bool หรือ `"auto"`)
|
||||
- `false` จะล้างคำสั่งที่เคยลงทะเบียนไว้ก่อนหน้าออกจาก Discord/Telegram ระหว่างเริ่มต้นระบบ ส่วนคำสั่ง Slack จัดการในแอป Slack และจะไม่ถูกลบออกโดยอัตโนมัติ
|
||||
- `commands.nativeSkills` (ค่าเริ่มต้น `"auto"`) ลงทะเบียนคำสั่ง **Skills** แบบ native เมื่อรองรับ
|
||||
- Auto: เปิดสำหรับ Discord/Telegram; ปิดสำหรับ Slack (Slack ต้องสร้าง slash command แยกต่อ Skill)
|
||||
- ตั้งค่า `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` หรือ `channels.slack.commands.nativeSkills` เพื่อ override ราย provider (bool หรือ `"auto"`)
|
||||
- `commands.bash` (ค่าเริ่มต้น `false`) เปิดใช้ `! <cmd>` เพื่อรันคำสั่ง shell ของโฮสต์ (`/bash <cmd>` เป็น alias; ต้องใช้ allowlist ของ `tools.elevated`)
|
||||
- `commands.bashForegroundMs` (ค่าเริ่มต้น `2000`) ควบคุมระยะเวลาที่ bash จะรอก่อนสลับไปเป็นโหมดพื้นหลัง (`0` จะย้ายไปพื้นหลังทันที)
|
||||
- `commands.text` (ค่าเริ่มต้น `true`) เปิดใช้การแยกวิเคราะห์ `/...` ในข้อความแชต
|
||||
- บนพื้นผิวที่ไม่มีคำสั่งแบบเนทีฟ (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) คำสั่งข้อความจะยังคงทำงานได้แม้ว่าคุณจะตั้งค่านี้เป็น `false`
|
||||
- `commands.native` (ค่าเริ่มต้น `"auto"`) ลงทะเบียนคำสั่งแบบเนทีฟ
|
||||
- อัตโนมัติ: เปิดสำหรับ Discord/Telegram; ปิดสำหรับ Slack (จนกว่าคุณจะเพิ่ม slash commands); ถูกละเว้นสำหรับผู้ให้บริการที่ไม่รองรับแบบเนทีฟ
|
||||
- ตั้งค่า `channels.discord.commands.native`, `channels.telegram.commands.native` หรือ `channels.slack.commands.native` เพื่อเขียนทับเป็นรายผู้ให้บริการ (bool หรือ `"auto"`)
|
||||
- `false` จะล้างคำสั่งที่ลงทะเบียนไว้ก่อนหน้านี้บน Discord/Telegram ตอนเริ่มต้น Slack commands ถูกจัดการในแอป Slack และจะไม่ถูกลบออกโดยอัตโนมัติ
|
||||
- `commands.nativeSkills` (ค่าเริ่มต้น `"auto"`) ลงทะเบียนคำสั่ง **skill** แบบเนทีฟเมื่อรองรับ
|
||||
- อัตโนมัติ: เปิดสำหรับ Discord/Telegram; ปิดสำหรับ Slack (Slack ต้องสร้าง slash command แยกสำหรับแต่ละ skill)
|
||||
- ตั้งค่า `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` หรือ `channels.slack.commands.nativeSkills` เพื่อเขียนทับเป็นรายผู้ให้บริการ (bool หรือ `"auto"`)
|
||||
- `commands.bash` (ค่าเริ่มต้น `false`) เปิดใช้ `! <cmd>` เพื่อรันคำสั่งเชลล์บนโฮสต์ (`/bash <cmd>` เป็นนามแฝง; ต้องใช้รายการอนุญาต `tools.elevated`)
|
||||
- `commands.bashForegroundMs` (ค่าเริ่มต้น `2000`) ควบคุมว่า bash จะรอนานเท่าใดก่อนสลับไปโหมดเบื้องหลัง (`0` จะส่งไปเบื้องหลังทันที)
|
||||
- `commands.config` (ค่าเริ่มต้น `false`) เปิดใช้ `/config` (อ่าน/เขียน `openclaw.json`)
|
||||
- `commands.mcp` (ค่าเริ่มต้น `false`) เปิดใช้ `/mcp` (อ่าน/เขียนคอนฟิก MCP ที่ OpenClaw จัดการไว้ภายใต้ `mcp.servers`)
|
||||
- `commands.plugins` (ค่าเริ่มต้น `false`) เปิดใช้ `/plugins` (การค้นหา/สถานะของ Plugin พร้อมตัวควบคุม install + enable/disable)
|
||||
- `commands.debug` (ค่าเริ่มต้น `false`) เปิดใช้ `/debug` (override เฉพาะรันไทม์)
|
||||
- `commands.restart` (ค่าเริ่มต้น `true`) เปิดใช้ `/restart` พร้อม tool action สำหรับรีสตาร์ต gateway
|
||||
- `commands.ownerAllowFrom` (ไม่บังคับ) กำหนด owner allowlist แบบ explicit สำหรับพื้นผิวคำสั่ง/เครื่องมือที่จำกัดเฉพาะ owner ซึ่งแยกจาก `commands.allowFrom`
|
||||
- `channels.<channel>.commands.enforceOwnerForCommands` รายช่องทาง (ไม่บังคับ, ค่าเริ่มต้น `false`) ทำให้คำสั่งที่จำกัดเฉพาะ owner ต้องใช้ **identity ของ owner** บนพื้นผิวนั้น เมื่อเป็น `true` ผู้ส่งต้องตรงกับ candidate ของ owner ที่ resolve ได้ (เช่น รายการใน `commands.ownerAllowFrom` หรือ metadata owner แบบ native ของ provider) หรือถือ scope ภายใน `operator.admin` บนช่องทางข้อความภายใน รายการ wildcard ใน `allowFrom` ของช่องทาง หรือรายการ owner-candidate ที่ว่าง/resolve ไม่ได้ **ไม่เพียงพอ** — คำสั่งที่จำกัดเฉพาะ owner จะล้มเหลวแบบ fail-closed บนช่องทางนั้น ปล่อยค่าเป็นปิดไว้หากคุณต้องการให้คำสั่งแบบ owner-only ถูกควบคุมเพียงโดย `ownerAllowFrom` และ allowlist คำสั่งมาตรฐาน
|
||||
- `commands.ownerDisplay` ควบคุมว่า owner id จะแสดงใน system prompt อย่างไร: `raw` หรือ `hash`
|
||||
- `commands.ownerDisplaySecret` ใช้ตั้งค่า HMAC secret แบบไม่บังคับเมื่อ `commands.ownerDisplay="hash"`
|
||||
- `commands.allowFrom` (ไม่บังคับ) กำหนด allowlist ราย provider สำหรับการอนุญาตคำสั่ง เมื่อตั้งค่าแล้ว จะกลายเป็นแหล่งการอนุญาตเพียงแหล่งเดียวสำหรับ commands และ directives (allowlist/การจับคู่ของช่องทางและ `commands.useAccessGroups` จะถูกละเว้น) ใช้ `"*"` สำหรับค่าเริ่มต้นแบบ global; คีย์เฉพาะ provider จะ override ค่านั้น
|
||||
- `commands.useAccessGroups` (ค่าเริ่มต้น `true`) บังคับใช้ allowlist/นโยบายสำหรับคำสั่งเมื่อไม่ได้ตั้งค่า `commands.allowFrom`
|
||||
- `commands.mcp` (ค่าเริ่มต้น `false`) เปิดใช้ `/mcp` (อ่าน/เขียนการกำหนดค่า MCP ที่ OpenClaw จัดการภายใต้ `mcp.servers`)
|
||||
- `commands.plugins` (ค่าเริ่มต้น `false`) เปิดใช้ `/plugins` (การค้นหา/สถานะของ plugin รวมถึงการติดตั้ง + ตัวควบคุมเปิด/ปิดใช้งาน)
|
||||
- `commands.debug` (ค่าเริ่มต้น `false`) เปิดใช้ `/debug` (การเขียนทับแบบ runtime เท่านั้น)
|
||||
- `commands.restart` (ค่าเริ่มต้น `true`) เปิดใช้ `/restart` รวมถึงการกระทำของเครื่องมือรีสตาร์ต gateway
|
||||
- `commands.ownerAllowFrom` (ไม่บังคับ) ตั้งค่ารายการอนุญาตเจ้าของแบบชัดเจนสำหรับพื้นผิวคำสั่ง/เครื่องมือที่จำกัดเฉพาะเจ้าของ ซึ่งแยกจาก `commands.allowFrom`
|
||||
- `channels.<channel>.commands.enforceOwnerForCommands` ต่อช่องทาง (ไม่บังคับ, ค่าเริ่มต้น `false`) ทำให้คำสั่งที่จำกัดเฉพาะเจ้าของต้องใช้ **ตัวตนของเจ้าของ** จึงจะรันได้บนพื้นผิวนั้น เมื่อเป็น `true` ผู้ส่งต้องตรงกับผู้สมัครเจ้าของที่แก้ค่าแล้ว (เช่น รายการใน `commands.ownerAllowFrom` หรือเมทาดาทาเจ้าของแบบเนทีฟของผู้ให้บริการ) หรือมี scope ภายใน `operator.admin` บนช่องข้อความภายใน รายการ wildcard ใน `allowFrom` ของช่องทาง หรือรายการผู้สมัครเจ้าของที่ว่าง/แก้ค่าไม่ได้ จะ **ไม่** เพียงพอ — คำสั่งเฉพาะเจ้าของจะปิดการทำงานโดยปริยายบนช่องทางนั้น ปล่อยค่านี้เป็นปิดไว้ หากคุณต้องการให้คำสั่งเฉพาะเจ้าของถูกจำกัดเพียงด้วย `ownerAllowFrom` และรายการอนุญาตคำสั่งมาตรฐาน
|
||||
- `commands.ownerDisplay` ควบคุมว่ารหัสเจ้าของจะแสดงอย่างไรใน system prompt: `raw` หรือ `hash`
|
||||
- `commands.ownerDisplaySecret` ตั้งค่าซีเคร็ต HMAC ที่ใช้เมื่อ `commands.ownerDisplay="hash"` ได้ตามต้องการ
|
||||
- `commands.allowFrom` (ไม่บังคับ) ตั้งค่ารายการอนุญาตต่อผู้ให้บริการสำหรับการอนุญาตคำสั่ง เมื่อกำหนดค่าแล้ว จะเป็นแหล่งการอนุญาตเพียงแหล่งเดียวสำหรับคำสั่งและ directives (รายการอนุญาต/การจับคู่ของช่องทางและ `commands.useAccessGroups` จะถูกละเว้น) ใช้ `"*"` สำหรับค่าเริ่มต้นแบบโกลบอล; คีย์เฉพาะผู้ให้บริการจะเขียนทับค่านี้
|
||||
- `commands.useAccessGroups` (ค่าเริ่มต้น `true`) บังคับใช้รายการอนุญาต/นโยบายกับคำสั่งเมื่อไม่ได้ตั้งค่า `commands.allowFrom`
|
||||
|
||||
## รายการคำสั่ง
|
||||
|
||||
แหล่งข้อมูลจริงปัจจุบัน:
|
||||
แหล่งข้อมูลอ้างอิงปัจจุบัน:
|
||||
|
||||
- core built-in มาจาก `src/auto-reply/commands-registry.shared.ts`
|
||||
- คำสั่ง built-in ของแกนหลักมาจาก `src/auto-reply/commands-registry.shared.ts`
|
||||
- คำสั่ง dock ที่สร้างขึ้นมาจาก `src/auto-reply/commands-registry.data.ts`
|
||||
- คำสั่ง Plugin มาจากการเรียก `registerCommand()` ของ Plugin
|
||||
- ความพร้อมใช้งานจริงบน gateway ของคุณยังขึ้นอยู่กับแฟล็กในคอนฟิก พื้นผิวของช่องทาง และ Plugin ที่ติดตั้ง/เปิดใช้งาน
|
||||
- คำสั่ง plugin มาจากการเรียก `registerCommand()` ของ plugin
|
||||
- การใช้งานได้จริงบน gateway ของคุณยังขึ้นอยู่กับแฟล็กการกำหนดค่า พื้นผิวของช่องทาง และ plugin ที่ติดตั้ง/เปิดใช้งานอยู่
|
||||
|
||||
### คำสั่ง built-in ของ core
|
||||
### คำสั่ง built-in ของแกนหลัก
|
||||
|
||||
คำสั่ง built-in ที่มีในปัจจุบัน:
|
||||
คำสั่ง built-in ที่พร้อมใช้งานในปัจจุบัน:
|
||||
|
||||
- `/new [model]` เริ่มเซสชันใหม่; `/reset` เป็น alias สำหรับรีเซ็ต
|
||||
- `/reset soft [message]` คง transcript ปัจจุบันไว้, ลบ backend session id ของ CLI ที่ถูกใช้ซ้ำ และรันการโหลด startup/system-prompt ใหม่ในที่เดิม
|
||||
- `/compact [instructions]` ทำ Compaction กับบริบทของเซสชัน ดู [/concepts/compaction](/th/concepts/compaction)
|
||||
- `/new [model]` เริ่มเซสชันใหม่; `/reset` เป็นนามแฝงสำหรับรีเซ็ต
|
||||
- `/reset soft [message]` เก็บ transcript ปัจจุบันไว้ ลบรหัสเซสชันของแบ็กเอนด์ CLI ที่นำกลับมาใช้ซ้ำ และรันการโหลด startup/system prompt ใหม่ในที่เดิม
|
||||
- `/compact [instructions]` ทำ Compaction บริบทของเซสชัน ดู [/concepts/compaction](/th/concepts/compaction)
|
||||
- `/stop` ยกเลิกการรันปัจจุบัน
|
||||
- `/session idle <duration|off>` และ `/session max-age <duration|off>` ใช้จัดการอายุหมดของ thread binding
|
||||
- `/think <level>` ตั้งค่าระดับการคิด ตัวเลือกขึ้นอยู่กับโปรไฟล์ provider ของโมเดลที่ใช้งาน ระดับที่พบบ่อยคือ `off`, `minimal`, `low`, `medium` และ `high` พร้อมระดับแบบกำหนดเอง เช่น `xhigh`, `adaptive`, `max` หรือแบบไบนารี `on` เฉพาะในกรณีที่รองรับ Alias: `/thinking`, `/t`
|
||||
- `/verbose on|off|full` สลับเอาต์พุตแบบละเอียด Alias: `/v`
|
||||
- `/trace on|off` สลับเอาต์พุต trace ของ Plugin สำหรับเซสชันปัจจุบัน
|
||||
- `/fast [status|on|off]` แสดงหรือตั้งค่าโหมดเร็ว
|
||||
- `/reasoning [on|off|stream]` สลับการมองเห็น reasoning Alias: `/reason`
|
||||
- `/elevated [on|off|ask|full]` สลับโหมด elevated Alias: `/elev`
|
||||
- `/session idle <duration|off>` และ `/session max-age <duration|off>` จัดการการหมดอายุของการผูกกับเธรด
|
||||
- `/think <level>` ตั้งค่าระดับการคิด ตัวเลือกมาจากโปรไฟล์ผู้ให้บริการของโมเดลที่ใช้งานอยู่ ระดับที่พบบ่อยคือ `off`, `minimal`, `low`, `medium` และ `high` พร้อมระดับแบบกำหนดเอง เช่น `xhigh`, `adaptive`, `max` หรือแบบไบนารี `on` เฉพาะในกรณีที่รองรับ นามแฝง: `/thinking`, `/t`
|
||||
- `/verbose on|off|full` สลับการแสดงผลแบบ verbose นามแฝง: `/v`
|
||||
- `/trace on|off` สลับการแสดงผล trace ของ plugin สำหรับเซสชันปัจจุบัน
|
||||
- `/fast [status|on|off]` แสดงหรือตั้งค่า fast mode
|
||||
- `/reasoning [on|off|stream]` สลับการมองเห็น reasoning นามแฝง: `/reason`
|
||||
- `/elevated [on|off|ask|full]` สลับ elevated mode นามแฝง: `/elev`
|
||||
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` แสดงหรือตั้งค่าเริ่มต้นของ exec
|
||||
- `/model [name|#|status]` แสดงหรือตั้งค่าโมเดล
|
||||
- `/models [provider] [page] [limit=<n>|size=<n>|all]` แสดงรายการ provider หรือโมเดลของ provider หนึ่ง
|
||||
- `/queue <mode>` จัดการพฤติกรรมของคิว (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`) พร้อมตัวเลือก เช่น `debounce:2s cap:25 drop:summarize`
|
||||
- `/help` แสดงสรุปช่วยเหลือแบบย่อ
|
||||
- `/models [provider] [page] [limit=<n>|size=<n>|all]` แสดงรายการผู้ให้บริการหรือโมเดลของผู้ให้บริการ
|
||||
- `/queue <mode>` จัดการพฤติกรรมคิว (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`) พร้อมตัวเลือกอย่าง `debounce:2s cap:25 drop:summarize`
|
||||
- `/help` แสดงสรุปวิธีใช้แบบสั้น
|
||||
- `/commands` แสดงแค็ตตาล็อกคำสั่งที่สร้างขึ้น
|
||||
- `/tools [compact|verbose]` แสดงว่าเอเจนต์ปัจจุบันใช้อะไรได้บ้างในตอนนี้
|
||||
- `/status` แสดงสถานะรันไทม์ รวมถึงการใช้งาน/quota ของ provider เมื่อมี
|
||||
- `/tools [compact|verbose]` แสดงสิ่งที่เอเจนต์ปัจจุบันสามารถใช้ได้ในตอนนี้
|
||||
- `/status` แสดงสถานะ runtime รวมถึงป้าย `Runtime`/`Runner` และการใช้งาน/โควตาของผู้ให้บริการเมื่อมี
|
||||
- `/tasks` แสดงรายการงานเบื้องหลังที่กำลังทำงาน/ล่าสุดสำหรับเซสชันปัจจุบัน
|
||||
- `/context [list|detail|json]` อธิบายว่าบริบทถูกประกอบขึ้นอย่างไร
|
||||
- `/export-session [path]` ส่งออกเซสชันปัจจุบันเป็น HTML Alias: `/export`
|
||||
- `/export-trajectory [path]` ส่งออก [trajectory bundle](/th/tools/trajectory) แบบ JSONL สำหรับเซสชันปัจจุบัน Alias: `/trajectory`
|
||||
- `/whoami` แสดง sender id ของคุณ Alias: `/id`
|
||||
- `/skill <name> [input]` รัน Skill ตามชื่อ
|
||||
- `/allowlist [list|add|remove] ...` จัดการรายการ allowlist ใช้ได้เฉพาะแบบข้อความเท่านั้น
|
||||
- `/approve <id> <decision>` จัดการพรอมป์อนุมัติ exec
|
||||
- `/btw <question>` ถามคำถามข้างเคียงโดยไม่เปลี่ยนบริบทของเซสชันในอนาคต ดู [/tools/btw](/th/tools/btw)
|
||||
- `/context [list|detail|json]` อธิบายวิธีประกอบบริบท
|
||||
- `/export-session [path]` ส่งออกเซสชันปัจจุบันเป็น HTML นามแฝง: `/export`
|
||||
- `/export-trajectory [path]` ส่งออก [trajectory bundle](/th/tools/trajectory) แบบ JSONL สำหรับเซสชันปัจจุบัน นามแฝง: `/trajectory`
|
||||
- `/whoami` แสดงรหัสผู้ส่งของคุณ นามแฝง: `/id`
|
||||
- `/skill <name> [input]` เรียกใช้ skill ตามชื่อ
|
||||
- `/allowlist [list|add|remove] ...` จัดการรายการใน allowlist ใช้ได้เฉพาะแบบข้อความเท่านั้น
|
||||
- `/approve <id> <decision>` จัดการคำขออนุมัติ exec ให้เสร็จสิ้น
|
||||
- `/btw <question>` ถามคำถามแทรกโดยไม่เปลี่ยนบริบทของเซสชันในอนาคต ดู [/tools/btw](/th/tools/btw)
|
||||
- `/subagents list|kill|log|info|send|steer|spawn` จัดการการรัน sub-agent สำหรับเซสชันปัจจุบัน
|
||||
- `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` จัดการเซสชัน ACP และตัวเลือกรันไทม์
|
||||
- `/focus <target>` ผูก Discord thread หรือหัวข้อ/บทสนทนา Telegram ปัจจุบันเข้ากับเป้าหมายเซสชัน
|
||||
- `/unfocus` ลบการผูกปัจจุบัน
|
||||
- `/focus <target>` ผูกเธรด Discord หรือหัวข้อ/การสนทนา Telegram ปัจจุบันเข้ากับเป้าหมายของเซสชัน
|
||||
- `/unfocus` เอาการผูกปัจจุบันออก
|
||||
- `/agents` แสดงรายการเอเจนต์ที่ผูกกับเธรดสำหรับเซสชันปัจจุบัน
|
||||
- `/kill <id|#|all>` ยกเลิก sub-agent หนึ่งตัวหรือทั้งหมดที่กำลังทำงาน
|
||||
- `/steer <id|#> <message>` ส่งคำสั่ง steer ไปยัง sub-agent ที่กำลังทำงาน Alias: `/tell`
|
||||
- `/config show|get|set|unset` อ่านหรือเขียน `openclaw.json` จำกัดเฉพาะ owner ต้องใช้ `commands.config: true`
|
||||
- `/mcp show|get|set|unset` อ่านหรือเขียนคอนฟิก MCP server ที่ OpenClaw จัดการไว้ภายใต้ `mcp.servers` จำกัดเฉพาะ owner ต้องใช้ `commands.mcp: true`
|
||||
- `/plugins list|inspect|show|get|install|enable|disable` ตรวจสอบหรือเปลี่ยนสถานะ Plugin `/plugin` เป็น alias จำกัดเฉพาะ owner สำหรับการเขียน ต้องใช้ `commands.plugins: true`
|
||||
- `/debug show|set|unset|reset` จัดการ override คอนฟิกเฉพาะรันไทม์ จำกัดเฉพาะ owner ต้องใช้ `commands.debug: true`
|
||||
- `/usage off|tokens|full|cost` ควบคุม footer การใช้งานต่อคำตอบ หรือพิมพ์สรุปต้นทุนในเครื่อง
|
||||
- `/kill <id|#|all>` ยกเลิก sub-agent ที่กำลังรันอยู่หนึ่งตัวหรือทั้งหมด
|
||||
- `/steer <id|#> <message>` ส่งคำสั่งกำกับไปยัง sub-agent ที่กำลังรันอยู่ นามแฝง: `/tell`
|
||||
- `/config show|get|set|unset` อ่านหรือเขียน `openclaw.json` เฉพาะเจ้าของ ต้องมี `commands.config: true`
|
||||
- `/mcp show|get|set|unset` อ่านหรือเขียนการกำหนดค่าเซิร์ฟเวอร์ MCP ที่ OpenClaw จัดการภายใต้ `mcp.servers` เฉพาะเจ้าของ ต้องมี `commands.mcp: true`
|
||||
- `/plugins list|inspect|show|get|install|enable|disable` ตรวจสอบหรือเปลี่ยนสถานะ plugin `/plugin` เป็นนามแฝง การเขียนจำกัดเฉพาะเจ้าของ ต้องมี `commands.plugins: true`
|
||||
- `/debug show|set|unset|reset` จัดการการเขียนทับการกำหนดค่าแบบ runtime เท่านั้น เฉพาะเจ้าของ ต้องมี `commands.debug: true`
|
||||
- `/usage off|tokens|full|cost` ควบคุมส่วนท้ายการใช้งานต่อการตอบกลับ หรือพิมพ์สรุปค่าใช้จ่ายในเครื่อง
|
||||
- `/tts on|off|status|provider|limit|summary|audio|help` ควบคุม TTS ดู [/tools/tts](/th/tools/tts)
|
||||
- `/restart` รีสตาร์ต OpenClaw เมื่อเปิดใช้งาน ค่าเริ่มต้น: เปิด; ตั้ง `commands.restart: false` เพื่อปิด
|
||||
- `/activation mention|always` ตั้งค่าโหมดการเปิดใช้งานในกลุ่ม
|
||||
- `/send on|off|inherit` ตั้งค่านโยบายการส่ง จำกัดเฉพาะ owner
|
||||
- `/bash <command>` รันคำสั่ง shell ของโฮสต์ ใช้ได้เฉพาะแบบข้อความ Alias: `! <command>` ต้องใช้ `commands.bash: true` พร้อม allowlist ของ `tools.elevated`
|
||||
- `!poll [sessionId]` ตรวจสอบงาน bash พื้นหลัง
|
||||
- `!stop [sessionId]` หยุดงาน bash พื้นหลัง
|
||||
- `/restart` รีสตาร์ต OpenClaw เมื่อเปิดใช้งาน ค่าเริ่มต้น: เปิดใช้งาน; ตั้ง `commands.restart: false` เพื่อปิด
|
||||
- `/activation mention|always` ตั้งค่าโหมดการเปิดใช้งานกลุ่ม
|
||||
- `/send on|off|inherit` ตั้งค่านโยบายการส่ง เฉพาะเจ้าของ
|
||||
- `/bash <command>` รันคำสั่งเชลล์บนโฮสต์ ใช้ได้เฉพาะแบบข้อความเท่านั้น นามแฝง: `! <command>` ต้องมี `commands.bash: true` พร้อม allowlist ของ `tools.elevated`
|
||||
- `!poll [sessionId]` ตรวจสอบงาน bash เบื้องหลัง
|
||||
- `!stop [sessionId]` หยุดงาน bash เบื้องหลัง
|
||||
|
||||
### คำสั่ง dock ที่สร้างขึ้น
|
||||
|
||||
คำสั่ง dock จะถูกสร้างจาก channel Plugin ที่รองรับ native-command ชุด bundled ปัจจุบันคือ:
|
||||
คำสั่ง dock ถูกสร้างจาก channel plugins ที่รองรับคำสั่งแบบเนทีฟ ชุดที่มากับระบบในปัจจุบันคือ:
|
||||
|
||||
- `/dock-discord` (alias: `/dock_discord`)
|
||||
- `/dock-mattermost` (alias: `/dock_mattermost`)
|
||||
- `/dock-slack` (alias: `/dock_slack`)
|
||||
- `/dock-telegram` (alias: `/dock_telegram`)
|
||||
- `/dock-discord` (นามแฝง: `/dock_discord`)
|
||||
- `/dock-mattermost` (นามแฝง: `/dock_mattermost`)
|
||||
- `/dock-slack` (นามแฝง: `/dock_slack`)
|
||||
- `/dock-telegram` (นามแฝง: `/dock_telegram`)
|
||||
|
||||
### คำสั่งจาก Plugin แบบ bundled
|
||||
### คำสั่ง plugin ที่มากับระบบ
|
||||
|
||||
Plugin แบบ bundled สามารถเพิ่ม slash command ได้เพิ่มเติม คำสั่ง bundled ปัจจุบันในรีโปนี้คือ:
|
||||
Bundled plugins สามารถเพิ่ม slash commands ได้อีก คำสั่งที่มากับระบบในรีโปนี้ในปัจจุบันคือ:
|
||||
|
||||
- `/dreaming [on|off|status|help]` สลับ Dreaming ของ memory ดู [Dreaming](/th/concepts/dreaming)
|
||||
- `/pair [qr|status|pending|approve|cleanup|notify]` จัดการ flow การจับคู่/การตั้งค่าอุปกรณ์ ดู [การจับคู่](/th/channels/pairing)
|
||||
- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` เปิดใช้งานชั่วคราวสำหรับคำสั่ง node ของโทรศัพท์ที่มีความเสี่ยงสูง
|
||||
- `/voice status|list [limit]|set <voiceId|name>` จัดการคอนฟิกเสียงของ Talk บน Discord ชื่อคำสั่ง native คือ `/talkvoice`
|
||||
- `/card ...` ส่ง preset rich card ของ LINE ดู [LINE](/th/channels/line)
|
||||
- `/codex status|models|threads|resume|compact|review|account|mcp|skills` ตรวจสอบและควบคุม Codex app-server harness แบบ bundled ดู [Codex Harness](/th/plugins/codex-harness)
|
||||
- `/dreaming [on|off|status|help]` สลับ Dreaming ของหน่วยความจำ ดู [Dreaming](/th/concepts/dreaming)
|
||||
- `/pair [qr|status|pending|approve|cleanup|notify]` จัดการโฟลว์การจับคู่อุปกรณ์/การตั้งค่า ดู [Pairing](/th/channels/pairing)
|
||||
- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` เปิดใช้งานคำสั่ง node โทรศัพท์ที่มีความเสี่ยงสูงชั่วคราว
|
||||
- `/voice status|list [limit]|set <voiceId|name>` จัดการการกำหนดค่าเสียง Talk บน Discord ชื่อคำสั่งแบบเนทีฟคือ `/talkvoice`
|
||||
- `/card ...` ส่งพรีเซ็ต rich card ของ LINE ดู [LINE](/th/channels/line)
|
||||
- `/codex status|models|threads|resume|compact|review|account|mcp|skills` ตรวจสอบและควบคุมชุด harness app-server ของ Codex ที่มากับระบบ ดู [Codex Harness](/th/plugins/codex-harness)
|
||||
- คำสั่งเฉพาะ QQBot:
|
||||
- `/bot-ping`
|
||||
- `/bot-version`
|
||||
@ -167,76 +168,78 @@ Plugin แบบ bundled สามารถเพิ่ม slash command ได
|
||||
- `/bot-upgrade`
|
||||
- `/bot-logs`
|
||||
|
||||
### คำสั่ง Skills แบบ dynamic
|
||||
### คำสั่ง skill แบบไดนามิก
|
||||
|
||||
Skills ที่ผู้ใช้เรียกใช้ได้จะถูกเปิดเผยเป็น slash command ด้วย:
|
||||
Skills ที่ผู้ใช้เรียกใช้ได้จะถูกเปิดเผยเป็น slash commands ด้วย:
|
||||
|
||||
- `/skill <name> [input]` ใช้งานได้เสมอในฐานะจุดเข้าแบบ generic
|
||||
- Skills อาจปรากฏเป็นคำสั่งตรง เช่น `/prose` เมื่อ Skill/Plugin ลงทะเบียนไว้
|
||||
- การลงทะเบียนคำสั่ง Skills แบบ native ถูกควบคุมโดย `commands.nativeSkills` และ `channels.<provider>.commands.nativeSkills`
|
||||
- `/skill <name> [input]` ใช้งานได้เสมอในฐานะจุดเข้าใช้งานแบบทั่วไป
|
||||
- skills อาจปรากฏเป็นคำสั่งโดยตรง เช่น `/prose` เมื่อ skill/plugin ลงทะเบียนไว้
|
||||
- การลงทะเบียนคำสั่ง skill แบบเนทีฟควบคุมโดย `commands.nativeSkills` และ `channels.<provider>.commands.nativeSkills`
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- คำสั่งรองรับ `:` แบบไม่บังคับระหว่างคำสั่งกับอาร์กิวเมนต์ (เช่น `/think: high`, `/send: on`, `/help:`)
|
||||
- `/new <model>` รองรับ alias ของโมเดล, `provider/model` หรือชื่อ provider (fuzzy match); หากไม่พบรายการที่ตรงกัน ข้อความนั้นจะถูกถือเป็นเนื้อหาข้อความ
|
||||
- หากต้องการดูรายละเอียดการใช้งานแยกตาม provider แบบครบถ้วน ให้ใช้ `openclaw status --usage`
|
||||
- `/allowlist add|remove` ต้องใช้ `commands.config=true` และจะเคารพ `configWrites` ของช่องทาง
|
||||
- ในช่องทางหลายบัญชี `/allowlist --account <id>` ที่มุ่งเป้าไปยังคอนฟิก และ `/config set channels.<provider>.accounts.<id>...` จะเคารพ `configWrites` ของบัญชีเป้าหมายด้วย
|
||||
- `/usage` ควบคุม footer การใช้งานต่อคำตอบ; `/usage cost` จะพิมพ์สรุปต้นทุนในเครื่องจาก log เซสชันของ OpenClaw
|
||||
- `/new <model>` รับนามแฝงของโมเดล, `provider/model` หรือชื่อผู้ให้บริการ (จับคู่แบบฟัซซี); หากไม่พบรายการที่ตรงกัน ข้อความนั้นจะถูกถือเป็นเนื้อหาข้อความ
|
||||
- สำหรับรายละเอียดการใช้งานของผู้ให้บริการแบบเต็ม ให้ใช้ `openclaw status --usage`
|
||||
- `/allowlist add|remove` ต้องใช้ `commands.config=true` และเป็นไปตาม `configWrites` ของช่องทาง
|
||||
- ในช่องทางแบบหลายบัญชี `/allowlist --account <id>` ที่กำหนดเป้าหมายการตั้งค่า และ `/config set channels.<provider>.accounts.<id>...` จะเป็นไปตาม `configWrites` ของบัญชีเป้าหมายด้วย
|
||||
- `/usage` ควบคุมส่วนท้ายการใช้งานต่อการตอบกลับ; `/usage cost` จะพิมพ์สรุปค่าใช้จ่ายในเครื่องจากบันทึกเซสชัน OpenClaw
|
||||
- `/restart` เปิดใช้งานโดยค่าเริ่มต้น; ตั้ง `commands.restart: false` เพื่อปิดใช้งาน
|
||||
- `/plugins install <spec>` รองรับ plugin spec แบบเดียวกับ `openclaw plugins install`: local path/archive, npm package หรือ `clawhub:<pkg>`
|
||||
- `/plugins enable|disable` จะอัปเดตคอนฟิก Plugin และอาจแจ้งให้รีสตาร์ต
|
||||
- คำสั่ง native เฉพาะ Discord: `/vc join|leave|status` ใช้ควบคุม voice channel (ต้องใช้ `channels.discord.voice` และ native commands; ไม่มีในรูปแบบข้อความ)
|
||||
- คำสั่ง Discord thread-binding (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) ต้องให้ effective thread binding เปิดใช้งานอยู่ (`session.threadBindings.enabled` และ/หรือ `channels.discord.threadBindings.enabled`)
|
||||
- `/plugins install <spec>` รับสเปก plugin แบบเดียวกับ `openclaw plugins install`: พาธ/ไฟล์เก็บถาวรในเครื่อง, แพ็กเกจ npm หรือ `clawhub:<pkg>`
|
||||
- `/plugins enable|disable` อัปเดตการกำหนดค่า plugin และอาจแจ้งให้รีสตาร์ต
|
||||
- คำสั่งแบบเนทีฟเฉพาะ Discord: `/vc join|leave|status` ใช้ควบคุมช่องเสียง (ต้องใช้ `channels.discord.voice` และคำสั่งแบบเนทีฟ; ไม่มีให้ใช้แบบข้อความ)
|
||||
- คำสั่งผูกกับเธรดของ Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) ต้องเปิดใช้การผูกกับเธรดอย่างมีผลอยู่ (`session.threadBindings.enabled` และ/หรือ `channels.discord.threadBindings.enabled`)
|
||||
- เอกสารอ้างอิงคำสั่ง ACP และพฤติกรรมรันไทม์: [ACP Agents](/th/tools/acp-agents)
|
||||
- `/verbose` มีไว้สำหรับการดีบักและการมองเห็นเพิ่มเติม; ในการใช้งานปกติควรปล่อยให้ **ปิด**
|
||||
- `/trace` แคบกว่า `/verbose`: มันเปิดเผยเฉพาะบรรทัด trace/debug ที่ Plugin เป็นเจ้าของ และยังคงปิดข้อความเครื่องมือแบบ verbose ปกติไว้
|
||||
- `/fast on|off` จะบันทึก override ระดับเซสชัน ใช้ตัวเลือก `inherit` ใน Sessions UI เพื่อล้างค่าและ fallback กลับไปใช้ค่าเริ่มต้นจากคอนฟิก
|
||||
- `/fast` มีพฤติกรรมเฉพาะ provider: OpenAI/OpenAI Codex จะแมปไปยัง `service_tier=priority` บนปลายทาง Responses แบบ native ขณะที่คำขอ Anthropic สาธารณะแบบตรง รวมถึงทราฟฟิกที่ยืนยันตัวตนด้วย OAuth ที่ส่งไปยัง `api.anthropic.com` จะแมปไปยัง `service_tier=auto` หรือ `standard_only` ดู [OpenAI](/th/providers/openai) และ [Anthropic](/th/providers/anthropic)
|
||||
- สรุปความล้มเหลวของเครื่องมือจะแสดงอยู่เมื่อเกี่ยวข้อง แต่ข้อความความล้มเหลวแบบละเอียดจะรวมมาด้วยเฉพาะเมื่อ `/verbose` เป็น `on` หรือ `full`
|
||||
- `/reasoning`, `/verbose` และ `/trace` มีความเสี่ยงในบริบทกลุ่ม: อาจเปิดเผย reasoning ภายใน เอาต์พุตของเครื่องมือ หรือข้อมูลวินิจฉัยของ Plugin ที่คุณไม่ได้ตั้งใจให้เปิดเผย ควรปล่อยให้ปิดไว้ โดยเฉพาะในแชตกลุ่ม
|
||||
- `/model` จะบันทึกโมเดลเซสชันใหม่ทันที
|
||||
- หากเอเจนต์ว่างอยู่ การรันครั้งถัดไปจะใช้โมเดลนั้นทันที
|
||||
- หากมีการรันที่กำลังทำงานอยู่แล้ว OpenClaw จะทำเครื่องหมายว่ามี live switch ที่รอดำเนินการ และจะรีสตาร์ตไปยังโมเดลใหม่เฉพาะเมื่อถึงจุด retry ที่สะอาด
|
||||
- หากกิจกรรมเครื่องมือหรือเอาต์พุตคำตอบเริ่มไปแล้ว การสลับที่รอดำเนินการอาจค้างอยู่จนกว่าจะมีโอกาส retry ในภายหลัง หรือจนถึงเทิร์นถัดไปของผู้ใช้
|
||||
- **Fast path:** ข้อความที่มีแต่คำสั่งจากผู้ส่งที่อยู่ใน allowlist จะถูกจัดการทันที (ข้ามคิว + โมเดล)
|
||||
- **การบังคับ mention ในกลุ่ม:** ข้อความที่มีแต่คำสั่งจากผู้ส่งที่อยู่ใน allowlist จะข้ามข้อกำหนดเรื่อง mention
|
||||
- **Inline shortcuts (เฉพาะผู้ส่งที่อยู่ใน allowlist):** บางคำสั่งยังทำงานได้เมื่อฝังอยู่ในข้อความปกติ และจะถูกตัดออกก่อนที่โมเดลจะเห็นข้อความที่เหลือ
|
||||
- ตัวอย่าง: `hey /status` จะกระตุ้นการตอบกลับสถานะ และข้อความที่เหลือจะดำเนินต่อผ่าน flow ปกติ
|
||||
- `/verbose` มีไว้สำหรับการดีบักและการมองเห็นเพิ่มเติม; ในการใช้งานปกติควรปิดไว้ **off**
|
||||
- `/trace` มีขอบเขตแคบกว่า `/verbose`: จะแสดงเฉพาะบรรทัด trace/debug ที่ plugin เป็นเจ้าของ และยังคงปิดการแสดงผล chatter ของเครื่องมือแบบ verbose ปกติไว้
|
||||
- `/fast on|off` จะคงค่าการเขียนทับระดับเซสชัน ใช้ตัวเลือก `inherit` ใน UI Sessions เพื่อล้างค่านี้และกลับไปใช้ค่าเริ่มต้นจากการกำหนดค่า
|
||||
- `/fast` ขึ้นอยู่กับผู้ให้บริการ: OpenAI/OpenAI Codex จะจับคู่เป็น `service_tier=priority` บน native Responses endpoints ขณะที่คำขอ Anthropic สาธารณะโดยตรง รวมถึงทราฟฟิกที่ยืนยันตัวตนด้วย OAuth และส่งไปยัง `api.anthropic.com` จะจับคู่เป็น `service_tier=auto` หรือ `standard_only` ดู [OpenAI](/th/providers/openai) และ [Anthropic](/th/providers/anthropic)
|
||||
- สรุปความล้มเหลวของเครื่องมือจะยังคงแสดงเมื่อเกี่ยวข้อง แต่ข้อความความล้มเหลวโดยละเอียดจะรวมมาให้เฉพาะเมื่อ `/verbose` เป็น `on` หรือ `full`
|
||||
- `/reasoning`, `/verbose` และ `/trace` มีความเสี่ยงในบริบทกลุ่ม: อาจเปิดเผย reasoning ภายใน เอาต์พุตของเครื่องมือ หรือข้อมูลวินิจฉัยของ plugin ที่คุณไม่ได้ตั้งใจให้เห็น ควรปล่อยให้ปิดไว้ โดยเฉพาะในแชตกลุ่ม
|
||||
- `/model` จะคงค่าโมเดลเซสชันใหม่ทันที
|
||||
- หากเอเจนต์ว่างอยู่ การรันถัดไปจะใช้ค่านั้นทันที
|
||||
- หากมีการรันที่กำลังทำงานอยู่แล้ว OpenClaw จะทำเครื่องหมายการสลับสดว่าอยู่ระหว่างรอดำเนินการ และจะรีสตาร์ตเข้าโมเดลใหม่เมื่อถึงจุดลองใหม่ที่สะอาดเท่านั้น
|
||||
- หากกิจกรรมของเครื่องมือหรือเอาต์พุตการตอบกลับเริ่มต้นไปแล้ว การสลับที่รอดำเนินการอาจค้างอยู่ในคิวจนกว่าจะมีโอกาสลองใหม่ในภายหลังหรือจนถึงตาของผู้ใช้ถัดไป
|
||||
- **เส้นทางเร็ว:** ข้อความที่มีแต่คำสั่งจากผู้ส่งที่อยู่ใน allowlist จะถูกจัดการทันที (ข้ามคิว + โมเดล)
|
||||
- **การบังคับด้วยการเมนชันในกลุ่ม:** ข้อความที่มีแต่คำสั่งจากผู้ส่งที่อยู่ใน allowlist จะข้ามข้อกำหนดเรื่องการเมนชัน
|
||||
- **ทางลัดแบบอินไลน์ (เฉพาะผู้ส่งที่อยู่ใน allowlist):** คำสั่งบางรายการใช้ได้ด้วยเมื่อฝังอยู่ในข้อความปกติ และจะถูกตัดออกก่อนที่โมเดลจะเห็นข้อความที่เหลือ
|
||||
- ตัวอย่าง: `hey /status` จะเรียกการตอบกลับสถานะ และข้อความที่เหลือจะดำเนินต่อไปตามโฟลว์ปกติ
|
||||
- ปัจจุบัน: `/help`, `/commands`, `/status`, `/whoami` (`/id`)
|
||||
- ข้อความที่มีแต่คำสั่งจากผู้ที่ไม่ได้รับอนุญาตจะถูกเพิกเฉยแบบเงียบ ๆ และโทเค็น `/...` แบบ inline จะถูกปฏิบัติเสมือนข้อความธรรมดา
|
||||
- **คำสั่ง Skills:** Skills แบบ `user-invocable` จะถูกเปิดเผยเป็น slash command ชื่อจะถูก sanitize เป็น `a-z0-9_` (สูงสุด 32 ตัวอักษร); หากชนกันจะเติม suffix เป็นตัวเลข (เช่น `_2`)
|
||||
- `/skill <name> [input]` ใช้รัน Skill ตามชื่อ (มีประโยชน์เมื่อข้อจำกัดของคำสั่ง native ทำให้ไม่สามารถมีคำสั่งต่อ Skill ได้)
|
||||
- โดยค่าเริ่มต้น คำสั่ง Skill จะถูกส่งต่อไปยังโมเดลเป็นคำขอปกติ
|
||||
- Skill สามารถประกาศ `command-dispatch: tool` แบบไม่บังคับ เพื่อกำหนดเส้นทางคำสั่งตรงไปยังเครื่องมือได้ (กำหนดแน่นอน, ไม่ผ่านโมเดล)
|
||||
- ตัวอย่าง: `/prose` (Plugin OpenProse) — ดู [OpenProse](/th/prose)
|
||||
- **อาร์กิวเมนต์ของคำสั่ง native:** Discord ใช้ autocomplete สำหรับตัวเลือกแบบ dynamic (และใช้เมนูปุ่มเมื่อคุณไม่ใส่อาร์กิวเมนต์ที่จำเป็น) Telegram และ Slack จะแสดงเมนูปุ่มเมื่อคำสั่งรองรับตัวเลือกและคุณละอาร์กิวเมนต์นั้นไว้
|
||||
- ข้อความที่มีแต่คำสั่งจากผู้ที่ไม่ได้รับอนุญาตจะถูกเพิกเฉยแบบเงียบ ๆ และโทเค็น `/...` แบบอินไลน์จะถูกปฏิบัติเสมือนเป็นข้อความธรรมดา
|
||||
- **คำสั่ง Skills:** Skills แบบ `user-invocable` จะถูกเปิดเผยเป็น slash commands ด้วย ชื่อจะถูกปรับให้เป็น `a-z0-9_` (สูงสุด 32 อักขระ); หากชนกันจะเติมคำต่อท้ายเป็นตัวเลข (เช่น `_2`)
|
||||
- `/skill <name> [input]` เรียกใช้ skill ตามชื่อ (มีประโยชน์เมื่อข้อจำกัดของคำสั่งแบบเนทีฟทำให้ไม่สามารถมีคำสั่งแยกต่อ skill ได้)
|
||||
- โดยค่าเริ่มต้น คำสั่ง skill จะถูกส่งต่อไปยังโมเดลเป็นคำขอปกติ
|
||||
- Skills สามารถประกาศ `command-dispatch: tool` แบบไม่บังคับเพื่อกำหนดเส้นทางคำสั่งไปยังเครื่องมือโดยตรงได้ (กำหนดแน่นอน ไม่ใช้โมเดล)
|
||||
- ตัวอย่าง: `/prose` (plugin OpenProse) — ดู [OpenProse](/th/prose)
|
||||
- **อาร์กิวเมนต์ของคำสั่งแบบเนทีฟ:** Discord ใช้ autocomplete สำหรับตัวเลือกแบบไดนามิก (และใช้เมนูปุ่มเมื่อคุณละอาร์กิวเมนต์ที่จำเป็น) Telegram และ Slack จะแสดงเมนูปุ่มเมื่อคำสั่งรองรับตัวเลือกและคุณละอาร์กิวเมนต์นั้น
|
||||
|
||||
## `/tools`
|
||||
|
||||
`/tools` ตอบคำถามในระดับรันไทม์ ไม่ใช่คำถามระดับคอนฟิก: **เอเจนต์นี้ใช้อะไรได้บ้างในตอนนี้
|
||||
ในบทสนทนานี้**
|
||||
`/tools` ตอบคำถามด้าน runtime ไม่ใช่คำถามด้านการกำหนดค่า: **สิ่งที่เอเจนต์นี้สามารถใช้ได้ในตอนนี้
|
||||
ในการสนทนานี้**
|
||||
|
||||
- ค่าเริ่มต้นของ `/tools` เป็นแบบย่อและเหมาะสำหรับการสแกนอย่างรวดเร็ว
|
||||
- ค่าเริ่มต้นของ `/tools` เป็นแบบย่อและปรับให้เหมาะกับการสแกนอย่างรวดเร็ว
|
||||
- `/tools verbose` จะเพิ่มคำอธิบายสั้น ๆ
|
||||
- พื้นผิวคำสั่ง native ที่รองรับอาร์กิวเมนต์จะเปิดเผยสวิตช์โหมดเดียวกันในรูปแบบ `compact|verbose`
|
||||
- ผลลัพธ์มีขอบเขตระดับเซสชัน ดังนั้นการเปลี่ยนเอเจนต์ ช่องทาง เธรด การอนุญาตผู้ส่ง หรือโมเดล สามารถ
|
||||
- พื้นผิวคำสั่งแบบเนทีฟที่รองรับอาร์กิวเมนต์ จะแสดงตัวสลับโหมดเดียวกันเป็น `compact|verbose`
|
||||
- ผลลัพธ์มีขอบเขตตามเซสชัน ดังนั้นการเปลี่ยนเอเจนต์ ช่องทาง เธรด การอนุญาตผู้ส่ง หรือโมเดล อาจ
|
||||
เปลี่ยนเอาต์พุตได้
|
||||
- `/tools` รวมเครื่องมือที่เข้าถึงได้จริงในรันไทม์ รวมถึงเครื่องมือ core เครื่องมือจาก Plugin ที่เชื่อมต่ออยู่ และเครื่องมือที่เป็นเจ้าของโดยช่องทาง
|
||||
- `/tools` รวมเครื่องมือที่เข้าถึงได้จริงขณะ runtime รวมถึงเครื่องมือแกนหลัก เครื่องมือ plugin
|
||||
ที่เชื่อมต่ออยู่ และเครื่องมือที่ช่องทางเป็นเจ้าของ
|
||||
|
||||
สำหรับการแก้ไขโปรไฟล์และ override ให้ใช้แผง Tools ใน Control UI หรือพื้นผิวคอนฟิก/แค็ตตาล็อก แทนที่จะ
|
||||
มอง `/tools` เป็นแค็ตตาล็อกแบบคงที่
|
||||
สำหรับการแก้ไขโปรไฟล์และการเขียนทับ ให้ใช้แผงเครื่องมือใน Control UI หรือพื้นผิว config/catalog แทน
|
||||
การมอง `/tools` เป็นแค็ตตาล็อกแบบคงที่
|
||||
|
||||
## พื้นผิวการใช้งาน (อะไรแสดงที่ไหน)
|
||||
|
||||
- **การใช้งาน/quota ของ provider** (ตัวอย่างเช่น “Claude เหลือ 80%”) จะแสดงใน `/status` สำหรับ provider ของโมเดลปัจจุบัน เมื่อเปิดใช้งานการติดตามการใช้งาน OpenClaw จะ normalize ช่วงเวลาของ provider ให้เป็น `% ที่เหลือ`; สำหรับ MiniMax ฟิลด์เปอร์เซ็นต์ที่รายงานเฉพาะส่วนที่เหลือจะถูกกลับค่าก่อนแสดงผล และการตอบกลับ `model_remains` จะเลือก entry ของ chat-model พร้อม label ของแผนที่มีแท็กโมเดลก่อน
|
||||
- **บรรทัด token/cache** ใน `/status` สามารถ fallback ไปใช้ entry การใช้งานล่าสุดใน transcript ได้ หาก snapshot ของเซสชันแบบ live มีข้อมูลน้อย ค่า live ที่ไม่เป็นศูนย์ที่มีอยู่เดิมยังคงมีความสำคัญสูงกว่า และ transcript fallback ยังสามารถกู้คืน label ของโมเดลรันไทม์ที่กำลังใช้งานอยู่พร้อม total แบบเน้น prompt ที่มากกว่าได้ เมื่อ total ที่เก็บไว้ไม่มีหรือมีขนาดเล็กกว่า
|
||||
- **token/ต้นทุนต่อคำตอบ** ถูกควบคุมโดย `/usage off|tokens|full` (จะถูกต่อท้ายคำตอบปกติ)
|
||||
- `/model status` เกี่ยวกับ **models/auth/endpoints** ไม่ใช่การใช้งาน
|
||||
- **การใช้งาน/โควตาของผู้ให้บริการ** (ตัวอย่าง: “Claude เหลือ 80%”) จะแสดงใน `/status` สำหรับผู้ให้บริการของโมเดลปัจจุบันเมื่อเปิดใช้การติดตามการใช้งาน OpenClaw จะปรับหน้าต่างของผู้ให้บริการให้เป็น `% ที่เหลือ`; สำหรับ MiniMax ฟิลด์เปอร์เซ็นต์แบบเหลืออย่างเดียวจะถูกกลับค่า قبلแสดง และการตอบกลับ `model_remains` จะเลือกใช้รายการ chat-model พร้อมป้ายแผนที่ติดแท็กโมเดลก่อน
|
||||
- บรรทัด **โทเค็น/แคช** ใน `/status` สามารถย้อนกลับไปใช้รายการการใช้งานล่าสุดใน transcript ได้เมื่อ snapshot ของเซสชันสดมีข้อมูลน้อย ค่าที่ไม่เป็นศูนย์จากข้อมูลสดที่มีอยู่เดิมยังคงมีลำดับความสำคัญสูงกว่า และการย้อนกลับไปใช้ transcript ยังสามารถกู้คืนป้ายโมเดล runtime ที่ใช้งานอยู่ รวมถึงยอดรวมที่เน้น prompt ซึ่งมากกว่าได้เมื่อยอดรวมที่เก็บไว้หายไปหรือมีค่าน้อยกว่า
|
||||
- **Runtime เทียบกับ runner:** `/status` จะรายงาน `Runtime` สำหรับเส้นทางการทำงานจริงและสถานะ sandbox และรายงาน `Runner` ว่าใครเป็นผู้รันเซสชันจริง: Pi แบบฝัง, ผู้ให้บริการที่อิง CLI หรือ harness/backend ของ ACP
|
||||
- **โทเค็น/ค่าใช้จ่ายต่อการตอบกลับ** ควบคุมโดย `/usage off|tokens|full` (ต่อท้ายกับการตอบกลับปกติ)
|
||||
- `/model status` เกี่ยวกับ **โมเดล/การยืนยันตัวตน/endpoints** ไม่ใช่การใช้งาน
|
||||
|
||||
## การเลือกโมเดล (`/model`)
|
||||
|
||||
`/model` ถูกใช้งานในฐานะ directive
|
||||
`/model` ถูกนำไปใช้งานในรูปแบบ directive
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -251,14 +254,14 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- `/model` และ `/model list` จะแสดงตัวเลือกแบบกะทัดรัดที่มีหมายเลขกำกับ (ตระกูลโมเดล + provider ที่ใช้งานได้)
|
||||
- บน Discord, `/model` และ `/models` จะเปิดตัวเลือกแบบโต้ตอบพร้อม dropdown ของ provider และโมเดล รวมถึงขั้นตอน Submit
|
||||
- `/model <#>` จะเลือกจากตัวเลือกนั้น (และจะพยายามใช้ provider ปัจจุบันเมื่อทำได้)
|
||||
- `/model status` จะแสดงมุมมองแบบละเอียด รวมถึงปลายทาง provider (`baseUrl`) และโหมด API (`api`) ที่ตั้งค่าไว้เมื่อมี
|
||||
- `/model` และ `/model list` จะแสดงตัวเลือกแบบกะทัดรัดที่มีหมายเลขกำกับ (ตระกูลโมเดล + ผู้ให้บริการที่มี)
|
||||
- บน Discord, `/model` และ `/models` จะเปิดตัวเลือกแบบโต้ตอบที่มีดรอปดาวน์ผู้ให้บริการและโมเดล พร้อมขั้นตอน Submit
|
||||
- `/model <#>` เลือกจากตัวเลือกนั้น (และจะพยายามใช้ผู้ให้บริการปัจจุบันก่อนเมื่อเป็นไปได้)
|
||||
- `/model status` จะแสดงมุมมองแบบละเอียด รวมถึง endpoint ของผู้ให้บริการที่กำหนดค่าไว้ (`baseUrl`) และโหมด API (`api`) เมื่อมี
|
||||
|
||||
## Debug overrides
|
||||
## การเขียนทับสำหรับดีบัก
|
||||
|
||||
`/debug` ให้คุณตั้งค่า override คอนฟิก **เฉพาะรันไทม์** (อยู่ในหน่วยความจำ ไม่เขียนลงดิสก์) จำกัดเฉพาะ owner ปิดไว้โดยค่าเริ่มต้น; เปิดใช้งานด้วย `commands.debug: true`
|
||||
`/debug` ให้คุณตั้งค่าการเขียนทับการกำหนดค่าแบบ **runtime เท่านั้น** (อยู่ในหน่วยความจำ ไม่เขียนดิสก์) เฉพาะเจ้าของ ปิดไว้โดยค่าเริ่มต้น; เปิดใช้ด้วย `commands.debug: true`
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -272,12 +275,12 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- override จะมีผลทันทีต่อการอ่านคอนฟิกครั้งใหม่ แต่จะ **ไม่** เขียนลง `openclaw.json`
|
||||
- ใช้ `/debug reset` เพื่อล้าง override ทั้งหมดและกลับไปใช้คอนฟิกบนดิสก์
|
||||
- การเขียนทับจะมีผลทันทีต่อการอ่านการกำหนดค่าใหม่ แต่จะ **ไม่** เขียนลง `openclaw.json`
|
||||
- ใช้ `/debug reset` เพื่อล้างการเขียนทับทั้งหมดและกลับไปใช้การกำหนดค่าบนดิสก์
|
||||
|
||||
## เอาต์พุต trace ของ Plugin
|
||||
## เอาต์พุต trace ของ plugin
|
||||
|
||||
`/trace` ให้คุณสลับ **บรรทัด trace/debug ของ Plugin ที่มีขอบเขตระดับเซสชัน** โดยไม่ต้องเปิด verbose mode เต็มรูปแบบ
|
||||
`/trace` ให้คุณสลับ **บรรทัด trace/debug ของ plugin ที่มีขอบเขตตามเซสชัน** ได้โดยไม่ต้องเปิดโหมด verbose เต็มรูปแบบ
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -290,15 +293,15 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
หมายเหตุ:
|
||||
|
||||
- `/trace` โดยไม่มีอาร์กิวเมนต์จะแสดงสถานะ trace ปัจจุบันของเซสชัน
|
||||
- `/trace on` จะเปิดใช้บรรทัด trace ของ Plugin สำหรับเซสชันปัจจุบัน
|
||||
- `/trace off` จะปิดอีกครั้ง
|
||||
- บรรทัด trace ของ Plugin อาจปรากฏใน `/status` และเป็นข้อความวินิจฉัยติดตามหลังคำตอบปกติของผู้ช่วย
|
||||
- `/trace` ไม่ได้มาแทน `/debug`; `/debug` ยังคงใช้จัดการ override คอนฟิกเฉพาะรันไทม์
|
||||
- `/trace` ไม่ได้มาแทน `/verbose`; เอาต์พุตเครื่องมือ/สถานะแบบ verbose ตามปกติยังคงเป็นหน้าที่ของ `/verbose`
|
||||
- `/trace on` เปิดใช้บรรทัด trace ของ plugin สำหรับเซสชันปัจจุบัน
|
||||
- `/trace off` ปิดอีกครั้ง
|
||||
- บรรทัด trace ของ plugin อาจปรากฏใน `/status` และเป็นข้อความวินิจฉัยติดตามหลังการตอบกลับปกติของผู้ช่วย
|
||||
- `/trace` ไม่ได้ใช้แทน `/debug`; `/debug` ยังคงใช้จัดการการเขียนทับการกำหนดค่าแบบ runtime เท่านั้น
|
||||
- `/trace` ไม่ได้ใช้แทน `/verbose`; เอาต์พุตเครื่องมือ/สถานะแบบ verbose ปกติยังคงเป็นหน้าที่ของ `/verbose`
|
||||
|
||||
## การอัปเดตคอนฟิก
|
||||
## การอัปเดตการกำหนดค่า
|
||||
|
||||
`/config` จะเขียนลงคอนฟิกบนดิสก์ของคุณ (`openclaw.json`) จำกัดเฉพาะ owner ปิดไว้โดยค่าเริ่มต้น; เปิดใช้งานด้วย `commands.config: true`
|
||||
`/config` จะเขียนไปยังไฟล์การกำหนดค่าบนดิสก์ของคุณ (`openclaw.json`) เฉพาะเจ้าของ ปิดไว้โดยค่าเริ่มต้น; เปิดใช้ด้วย `commands.config: true`
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -312,12 +315,12 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- คอนฟิกจะถูกตรวจสอบความถูกต้องก่อนเขียน; การเปลี่ยนแปลงที่ไม่ถูกต้องจะถูกปฏิเสธ
|
||||
- การอัปเดตผ่าน `/config` จะคงอยู่ข้ามการรีสตาร์ต
|
||||
- การกำหนดค่าจะถูกตรวจสอบความถูกต้องก่อนเขียน; การเปลี่ยนแปลงที่ไม่ถูกต้องจะถูกปฏิเสธ
|
||||
- การอัปเดต `/config` จะคงอยู่หลังการรีสตาร์ต
|
||||
|
||||
## การอัปเดต MCP
|
||||
|
||||
`/mcp` จะเขียนนิยาม MCP server ที่ OpenClaw จัดการไว้ภายใต้ `mcp.servers` จำกัดเฉพาะ owner ปิดไว้โดยค่าเริ่มต้น; เปิดใช้งานด้วย `commands.mcp: true`
|
||||
`/mcp` เขียนคำจำกัดความเซิร์ฟเวอร์ MCP ที่ OpenClaw จัดการไว้ภายใต้ `mcp.servers` เฉพาะเจ้าของ ปิดไว้โดยค่าเริ่มต้น; เปิดใช้ด้วย `commands.mcp: true`
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -330,12 +333,12 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- `/mcp` จะเก็บคอนฟิกไว้ในคอนฟิกของ OpenClaw ไม่ใช่การตั้งค่าโปรเจ็กต์ที่ Pi เป็นเจ้าของ
|
||||
- adapter ของรันไทม์จะเป็นตัวตัดสินว่า transport ใดสามารถรันได้จริง
|
||||
- `/mcp` จะเก็บการกำหนดค่าไว้ในคอนฟิก OpenClaw ไม่ใช่การตั้งค่าโปรเจกต์ที่ Pi เป็นเจ้าของ
|
||||
- อะแดปเตอร์รันไทม์จะเป็นผู้ตัดสินว่าทรานสปอร์ตใดสามารถรันได้จริง
|
||||
|
||||
## การอัปเดต Plugin
|
||||
## การอัปเดต plugin
|
||||
|
||||
`/plugins` ให้ผู้ปฏิบัติงานตรวจสอบ Plugin ที่ค้นพบและสลับสถานะการเปิดใช้งานในคอนฟิก flow แบบอ่านอย่างเดียวสามารถใช้ `/plugin` เป็น alias ได้ ปิดไว้โดยค่าเริ่มต้น; เปิดใช้งานด้วย `commands.plugins: true`
|
||||
`/plugins` ให้ผู้ปฏิบัติการตรวจสอบ plugin ที่ค้นพบและสลับการเปิดใช้งานในคอนฟิกได้ โฟลว์แบบอ่านอย่างเดียวสามารถใช้ `/plugin` เป็นนามแฝงได้ ปิดไว้โดยค่าเริ่มต้น; เปิดใช้ด้วย `commands.plugins: true`
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
@ -349,41 +352,40 @@ Skills ที่ผู้ใช้เรียกใช้ได้จะถู
|
||||
|
||||
หมายเหตุ:
|
||||
|
||||
- `/plugins list` และ `/plugins show` ใช้การค้นหา Plugin จริงกับ workspace ปัจจุบันร่วมกับคอนฟิกบนดิสก์
|
||||
- `/plugins enable|disable` จะอัปเดตเฉพาะคอนฟิก Plugin; ไม่ได้ติดตั้งหรือลบ Plugin
|
||||
- หลังการเปลี่ยนแปลง enable/disable ให้รีสตาร์ต gateway เพื่อนำไปใช้
|
||||
- `/plugins list` และ `/plugins show` ใช้การค้นหา plugin จริงกับ workspace ปัจจุบันพร้อมคอนฟิกบนดิสก์
|
||||
- `/plugins enable|disable` จะอัปเดตเฉพาะคอนฟิกของ plugin; ไม่ได้ติดตั้งหรือลบการติดตั้ง plugin
|
||||
- หลังเปลี่ยนแปลงการเปิด/ปิดใช้งาน ให้รีสตาร์ต gateway เพื่อให้มีผล
|
||||
|
||||
## หมายเหตุของพื้นผิว
|
||||
## หมายเหตุเกี่ยวกับพื้นผิว
|
||||
|
||||
- **คำสั่งแบบข้อความ** จะทำงานในเซสชันแชตปกติ (DM ใช้ `main` ร่วมกัน, กลุ่มมีเซสชันของตัวเอง)
|
||||
- **คำสั่ง native** ใช้เซสชันแบบ isolated:
|
||||
- **คำสั่งแบบข้อความ** จะทำงานในเซสชันแชตปกติ (DM ใช้ `main` ร่วมกัน, กลุ่มมีเซสชันของตนเอง)
|
||||
- **คำสั่งแบบเนทีฟ** ใช้เซสชันแยก:
|
||||
- Discord: `agent:<agentId>:discord:slash:<userId>`
|
||||
- Slack: `agent:<agentId>:slack:slash:<userId>` (คำนำหน้าปรับได้ผ่าน `channels.slack.slashCommand.sessionPrefix`)
|
||||
- Telegram: `telegram:slash:<userId>` (มุ่งเป้าไปยังเซสชันแชตผ่าน `CommandTargetSessionKey`)
|
||||
- **`/stop`** จะมุ่งเป้าไปยังเซสชันแชตที่กำลังทำงานอยู่ เพื่อยกเลิกการรันปัจจุบัน
|
||||
- **Slack:** `channels.slack.slashCommand` ยังคงรองรับสำหรับคำสั่งเดี่ยวสไตล์ `/openclaw` หากคุณเปิด `commands.native` คุณต้องสร้าง Slack slash command แยกหนึ่งคำสั่งต่อหนึ่งคำสั่ง built-in (ใช้ชื่อเดียวกับ `/help`) เมนูอาร์กิวเมนต์ของคำสั่งสำหรับ Slack จะถูกส่งเป็นปุ่ม Block Kit แบบ ephemeral
|
||||
- ข้อยกเว้นของคำสั่ง native บน Slack: ให้ลงทะเบียน `/agentstatus` (ไม่ใช่ `/status`) เพราะ Slack สงวน `/status` ไว้ ข้อความ `/status` แบบข้อความยังคงทำงานในข้อความ Slack
|
||||
- Telegram: `telegram:slash:<userId>` (กำหนดเป้าหมายไปยังเซสชันแชตผ่าน `CommandTargetSessionKey`)
|
||||
- **`/stop`** กำหนดเป้าหมายไปยังเซสชันแชตที่กำลังใช้งาน เพื่อให้สามารถยกเลิกการรันปัจจุบันได้
|
||||
- **Slack:** `channels.slack.slashCommand` ยังรองรับอยู่สำหรับคำสั่งเดี่ยวสไตล์ `/openclaw` หากคุณเปิดใช้ `commands.native` คุณต้องสร้างคำสั่ง slash ของ Slack หนึ่งรายการต่อคำสั่ง built-in (ใช้ชื่อเดียวกับ `/help`) เมนูอาร์กิวเมนต์ของคำสั่งสำหรับ Slack จะถูกส่งเป็นปุ่ม Block Kit แบบ ephemeral
|
||||
- ข้อยกเว้นของคำสั่งแบบเนทีฟบน Slack: ลงทะเบียน `/agentstatus` (ไม่ใช่ `/status`) เพราะ Slack สงวน `/status` ไว้ ข้อความ `/status` ยังใช้ได้ในข้อความ Slack
|
||||
|
||||
## คำถามข้างเคียง BTW
|
||||
## คำถามแทรก BTW
|
||||
|
||||
`/btw` คือ **คำถามข้างเคียง** แบบรวดเร็วเกี่ยวกับเซสชันปัจจุบัน
|
||||
`/btw` คือ **คำถามแทรก** แบบรวดเร็วเกี่ยวกับเซสชันปัจจุบัน
|
||||
|
||||
ต่างจากแชตปกติ:
|
||||
|
||||
- มันใช้เซสชันปัจจุบันเป็นบริบทพื้นหลัง
|
||||
- มันทำงานเป็นการเรียกแบบครั้งเดียว **ที่ไม่มีเครื่องมือ**
|
||||
- มันรันเป็นการเรียกแบบครั้งเดียวแยกต่างหากที่ **ไม่มีเครื่องมือ**
|
||||
- มันไม่เปลี่ยนบริบทของเซสชันในอนาคต
|
||||
- มันไม่ถูกเขียนลงประวัติ transcript
|
||||
- มันถูกส่งมอบเป็นผลลัพธ์ข้างเคียงแบบ live แทนที่จะเป็นข้อความผู้ช่วยปกติ
|
||||
- มันไม่ถูกเขียนลงในประวัติ transcript
|
||||
- มันถูกส่งเป็นผลลัพธ์แทรกแบบสดแทนที่จะเป็นข้อความผู้ช่วยปกติ
|
||||
|
||||
สิ่งนี้ทำให้ `/btw` มีประโยชน์เมื่อคุณต้องการคำชี้แจงชั่วคราว ในขณะที่งานหลัก
|
||||
ยังคงดำเนินต่อไป
|
||||
สิ่งนี้ทำให้ `/btw` มีประโยชน์เมื่อคุณต้องการคำชี้แจงชั่วคราวในขณะที่งานหลัก
|
||||
ยังดำเนินต่อไป
|
||||
|
||||
ตัวอย่าง:
|
||||
|
||||
```text
|
||||
/btw ตอนนี้เรากำลังทำอะไรอยู่?
|
||||
/btw what are we doing right now?
|
||||
```
|
||||
|
||||
ดู [คำถามข้างเคียง BTW](/th/tools/btw) สำหรับพฤติกรรมทั้งหมดและรายละเอียด
|
||||
UX ของไคลเอนต์
|
||||
ดู [BTW Side Questions](/th/tools/btw) สำหรับรายละเอียดพฤติกรรมทั้งหมดและ UX ของไคลเอนต์
|
||||
|
||||
@ -1,132 +1,132 @@
|
||||
---
|
||||
read_when:
|
||||
- การปรับการคิด การแยกวิเคราะห์หรือค่าเริ่มต้นของโหมด fast หรือ verbose directive
|
||||
summary: ไวยากรณ์ของ directive สำหรับ /think, /fast, /verbose, /trace และการมองเห็น reasoning
|
||||
- การปรับการแยกวิเคราะห์หรือค่าเริ่มต้นของคำสั่งระดับการคิด โหมดเร็ว หรือโหมดละเอียด
|
||||
summary: ไวยากรณ์คำสั่งสำหรับ /think, /fast, /verbose, /trace และการมองเห็นการให้เหตุผล
|
||||
title: ระดับการคิด
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T10:24:08Z"
|
||||
generated_at: "2026-04-23T13:58:14Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 66033bb9272c9b9ea8fc85dc91e33e95ce4c469c56a8cd10c19632a5aa8a2338
|
||||
source_hash: 4efe899f7b47244745a105583b3239effa7975fadd06bd7bcad6327afcc91207
|
||||
source_path: tools/thinking.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# ระดับการคิด (/think directives)
|
||||
|
||||
## สิ่งที่ทำได้
|
||||
## สิ่งที่ทำ
|
||||
|
||||
- Inline directive ในเนื้อหาขาเข้าใดก็ได้: `/t <level>`, `/think:<level>` หรือ `/thinking <level>`.
|
||||
- ระดับ (aliases): `off | minimal | low | medium | high | xhigh | adaptive | max`
|
||||
- minimal → “think”
|
||||
- low → “think hard”
|
||||
- medium → “think harder”
|
||||
- คำสั่งแบบอินไลน์ในเนื้อหาขาเข้าข้อความใดก็ได้: `/t <level>`, `/think:<level>` หรือ `/thinking <level>`.
|
||||
- ระดับ (ชื่อเรียกแทน): `off | minimal | low | medium | high | xhigh | adaptive | max`
|
||||
- minimal → “คิด”
|
||||
- low → “คิดอย่างหนัก”
|
||||
- medium → “คิดให้หนักขึ้น”
|
||||
- high → “ultrathink” (งบประมาณสูงสุด)
|
||||
- xhigh → “ultrathink+” (GPT-5.2 + Codex models และ effort ของ Anthropic Claude Opus 4.7)
|
||||
- adaptive → การคิดแบบปรับตัวโดยผู้ให้บริการเป็นผู้จัดการ (รองรับสำหรับ Claude 4.6 บน Anthropic/Bedrock และ Anthropic Claude Opus 4.7)
|
||||
- max → reasoning สูงสุดของผู้ให้บริการ (ปัจจุบันคือ Anthropic Claude Opus 4.7)
|
||||
- `x-high`, `x_high`, `extra-high`, `extra high` และ `extra_high` จะถูกแมปเป็น `xhigh`
|
||||
- `highest` จะถูกแมปเป็น `high`
|
||||
- หมายเหตุเกี่ยวกับผู้ให้บริการ:
|
||||
- เมนูและตัวเลือกของการคิดขับเคลื่อนด้วย provider profile ผู้ให้บริการ Plugins จะประกาศชุดระดับที่แน่นอนสำหรับโมเดลที่เลือก รวมถึงป้ายกำกับอย่าง `on` แบบไบนารี
|
||||
- `adaptive`, `xhigh` และ `max` จะถูกโฆษณาเฉพาะสำหรับ provider/model profiles ที่รองรับเท่านั้น Typed directives สำหรับระดับที่ไม่รองรับจะถูกปฏิเสธพร้อมตัวเลือกที่ใช้ได้ของโมเดลนั้น
|
||||
- ระดับที่จัดเก็บไว้เดิมแต่ไม่รองรับจะถูก remap ตามลำดับ rank ของ provider profile `adaptive` จะ fallback ไปเป็น `medium` บนโมเดลที่ไม่รองรับ adaptive ส่วน `xhigh` และ `max` จะ fallback ไปยังระดับที่รองรับสูงสุดซึ่งไม่ใช่ `off` สำหรับโมเดลที่เลือก
|
||||
- โมเดล Anthropic Claude 4.6 ใช้ค่าเริ่มต้นเป็น `adaptive` เมื่อไม่มีการตั้งระดับการคิดอย่างชัดเจน
|
||||
- Anthropic Claude Opus 4.7 ไม่ได้ใช้ adaptive thinking เป็นค่าเริ่มต้น ค่าเริ่มต้น effort ของ API ยังคงเป็นของผู้ให้บริการ เว้นแต่คุณจะตั้งระดับการคิดอย่างชัดเจน
|
||||
- Anthropic Claude Opus 4.7 จะแมป `/think xhigh` ไปยัง adaptive thinking พร้อม `output_config.effort: "xhigh"` เพราะ `/think` เป็น thinking directive และ `xhigh` คือการตั้งค่า effort ของ Opus 4.7
|
||||
- Anthropic Claude Opus 4.7 ยังเปิดให้ใช้ `/think max`; โดยมันจะถูกแมปไปยังเส้นทาง max effort เดียวกันที่ผู้ให้บริการเป็นเจ้าของ
|
||||
- OpenAI GPT models จะแมป `/think` ผ่านการรองรับ effort ของ Responses API ที่เฉพาะกับแต่ละโมเดล `/think off` จะส่ง `reasoning.effort: "none"` เฉพาะเมื่อโมเดลเป้าหมายรองรับเท่านั้น; มิฉะนั้น OpenClaw จะละเว้น payload สำหรับปิด reasoning แทนการส่งค่าที่ไม่รองรับ
|
||||
- MiniMax (`minimax/*`) บนเส้นทางสตรีมที่เข้ากันได้กับ Anthropic จะใช้ค่าเริ่มต้น `thinking: { type: "disabled" }` เว้นแต่คุณจะตั้ง thinking อย่างชัดเจนใน model params หรือ request params วิธีนี้ช่วยหลีกเลี่ยง `reasoning_content` deltas ที่รั่วออกมาจากรูปแบบสตรีม Anthropic ที่ไม่ใช่เนทีฟของ MiniMax
|
||||
- xhigh → “ultrathink+” (GPT-5.2 + โมเดล Codex และระดับ effort ของ Anthropic Claude Opus 4.7)
|
||||
- adaptive → การคิดแบบปรับตามสถานการณ์ที่ผู้ให้บริการจัดการ (รองรับสำหรับ Claude 4.6 บน Anthropic/Bedrock และ Anthropic Claude Opus 4.7)
|
||||
- max → การให้เหตุผลระดับสูงสุดของผู้ให้บริการ (ปัจจุบันคือ Anthropic Claude Opus 4.7)
|
||||
- `x-high`, `x_high`, `extra-high`, `extra high` และ `extra_high` จะถูกแมปเป็น `xhigh`.
|
||||
- `highest` จะถูกแมปเป็น `high`.
|
||||
- หมายเหตุของผู้ให้บริการ:
|
||||
- เมนูและตัวเลือกการคิดขับเคลื่อนโดยโปรไฟล์ของผู้ให้บริการ ปลั๊กอินผู้ให้บริการจะประกาศชุดระดับที่แน่นอนสำหรับโมเดลที่เลือก รวมถึงป้ายกำกับอย่างเช่น `on` แบบไบนารี
|
||||
- `adaptive`, `xhigh` และ `max` จะแสดงเฉพาะกับโปรไฟล์ผู้ให้บริการ/โมเดลที่รองรับเท่านั้น คำสั่งที่พิมพ์ระบุระดับที่ไม่รองรับจะถูกปฏิเสธพร้อมตัวเลือกที่ใช้ได้ของโมเดลนั้น
|
||||
- ระดับที่ไม่รองรับซึ่งจัดเก็บไว้อยู่แล้วจะถูกแมปใหม่ตามลำดับอันดับของโปรไฟล์ผู้ให้บริการ `adaptive` จะย้อนกลับไปเป็น `medium` บนโมเดลที่ไม่รองรับ adaptive ส่วน `xhigh` และ `max` จะย้อนกลับไปเป็นระดับที่ไม่ใช่ `off` สูงสุดที่รองรับสำหรับโมเดลที่เลือก
|
||||
- โมเดล Anthropic Claude 4.6 ใช้ค่าเริ่มต้นเป็น `adaptive` เมื่อไม่ได้ตั้งระดับการคิดอย่างชัดเจน
|
||||
- Anthropic Claude Opus 4.7 ไม่ได้ใช้การคิดแบบ adaptive เป็นค่าเริ่มต้น ค่า effort เริ่มต้นของ API ยังเป็นของผู้ให้บริการ เว้นแต่คุณจะตั้งระดับการคิดอย่างชัดเจน
|
||||
- Anthropic Claude Opus 4.7 แมป `/think xhigh` เป็นการคิดแบบ adaptive บวกกับ `output_config.effort: "xhigh"` เพราะ `/think` เป็นคำสั่งการคิด และ `xhigh` คือค่าระดับ effort ของ Opus 4.7
|
||||
- Anthropic Claude Opus 4.7 ยังรองรับ `/think max`; โดยแมปไปยังเส้นทาง effort สูงสุดแบบเดียวกันที่ผู้ให้บริการเป็นผู้กำหนด
|
||||
- โมเดล OpenAI GPT แมป `/think` ผ่านการรองรับ effort ของ Responses API เฉพาะแต่ละโมเดล `/think off` จะส่ง `reasoning.effort: "none"` เฉพาะเมื่อโมเดลเป้าหมายรองรับเท่านั้น มิฉะนั้น OpenClaw จะไม่ส่งเพย์โหลดปิดการให้เหตุผล แทนการส่งค่าที่ไม่รองรับ
|
||||
- MiniMax (`minimax/*`) บนเส้นทางสตรีมที่เข้ากันได้กับ Anthropic ใช้ค่าเริ่มต้นเป็น `thinking: { type: "disabled" }` เว้นแต่คุณจะตั้งค่าการคิดอย่างชัดเจนในพารามิเตอร์ของโมเดลหรือพารามิเตอร์คำขอ เพื่อหลีกเลี่ยง `reasoning_content` delta ที่รั่วออกมาจากรูปแบบสตรีม Anthropic ที่ไม่ใช่แบบเนทีฟของ MiniMax
|
||||
- Z.AI (`zai/*`) รองรับเฉพาะการคิดแบบไบนารี (`on`/`off`) ระดับใดก็ตามที่ไม่ใช่ `off` จะถือเป็น `on` (แมปเป็น `low`)
|
||||
- Moonshot (`moonshot/*`) จะแมป `/think off` ไปเป็น `thinking: { type: "disabled" }` และระดับใดก็ตามที่ไม่ใช่ `off` เป็น `thinking: { type: "enabled" }` เมื่อเปิด thinking แล้ว Moonshot จะยอมรับ `tool_choice` ได้เฉพาะ `auto|none`; OpenClaw จะ normalize ค่าที่ไม่เข้ากันให้เป็น `auto`
|
||||
- Moonshot (`moonshot/*`) แมป `/think off` เป็น `thinking: { type: "disabled" }` และแมประดับใดก็ตามที่ไม่ใช่ `off` เป็น `thinking: { type: "enabled" }` เมื่อเปิดการคิด Moonshot จะยอมรับ `tool_choice` ได้เฉพาะ `auto|none`; OpenClaw จะปรับค่าที่ไม่เข้ากันให้เป็น `auto`
|
||||
|
||||
## ลำดับการ resolve
|
||||
## ลำดับการตัดสินใจ
|
||||
|
||||
1. Inline directive บนข้อความ (มีผลกับข้อความนั้นเท่านั้น)
|
||||
2. Session override (ตั้งโดยส่งข้อความที่มีแต่ directive)
|
||||
1. คำสั่งอินไลน์บนข้อความ (มีผลกับข้อความนั้นเท่านั้น)
|
||||
2. การแทนที่ระดับเซสชัน (ตั้งโดยการส่งข้อความที่มีแต่คำสั่ง)
|
||||
3. ค่าเริ่มต้นต่อเอเจนต์ (`agents.list[].thinkingDefault` ใน config)
|
||||
4. ค่าเริ่มต้นแบบโกลบอล (`agents.defaults.thinkingDefault` ใน config)
|
||||
5. Fallback: ค่าเริ่มต้นที่ผู้ให้บริการประกาศเมื่อมี, `low` สำหรับ catalog models อื่นที่ถูกทำเครื่องหมายว่ารองรับ reasoning, และ `off` ในกรณีอื่น
|
||||
4. ค่าเริ่มต้นส่วนกลาง (`agents.defaults.thinkingDefault` ใน config)
|
||||
5. การย้อนกลับ: ค่าเริ่มต้นที่ผู้ให้บริการประกาศไว้หากมี มิฉะนั้นโมเดลที่รองรับการให้เหตุผลจะใช้ `medium` หรือระดับที่ไม่ใช่ `off` ที่ใกล้เคียงที่สุดซึ่งโมเดลนั้นรองรับ และโมเดลที่ไม่รองรับการให้เหตุผลจะคงเป็น `off`
|
||||
|
||||
## การตั้งค่า session default
|
||||
## การตั้งค่าเริ่มต้นของเซสชัน
|
||||
|
||||
- ส่งข้อความที่เป็น **directive เท่านั้น** (อนุญาตให้มี whitespace) เช่น `/think:medium` หรือ `/t high`
|
||||
- ค่านี้จะคงอยู่สำหรับเซสชันปัจจุบัน (ต่อผู้ส่งเป็นค่าเริ่มต้น); ล้างได้ด้วย `/think:off` หรือ session idle reset
|
||||
- จะมีการส่งข้อความยืนยัน (`Thinking level set to high.` / `Thinking disabled.`) หากระดับไม่ถูกต้อง (เช่น `/thinking big`) คำสั่งจะถูกปฏิเสธพร้อมคำแนะนำ และสถานะของเซสชันจะไม่เปลี่ยน
|
||||
- ส่ง `/think` (หรือ `/think:`) โดยไม่มีอาร์กิวเมนต์เพื่อดูระดับการคิดปัจจุบัน
|
||||
- ส่งข้อความที่เป็น **คำสั่งเท่านั้น** (อนุญาตให้มีช่องว่างได้) เช่น `/think:medium` หรือ `/t high`
|
||||
- ค่านี้จะคงอยู่สำหรับเซสชันปัจจุบัน (เป็นต่อผู้ส่งโดยค่าเริ่มต้น); ล้างได้ด้วย `/think:off` หรือเมื่อเซสชันว่างจนถูกรีเซ็ต
|
||||
- ระบบจะส่งข้อความยืนยัน (`ตั้งค่าระดับการคิดเป็น high แล้ว` / `ปิดการคิดแล้ว`) หากระดับไม่ถูกต้อง (เช่น `/thinking big`) คำสั่งจะถูกปฏิเสธพร้อมคำแนะนำ และสถานะเซสชันจะไม่เปลี่ยนแปลง
|
||||
- ส่ง `/think` (หรือ `/think:`) โดยไม่ระบุอาร์กิวเมนต์เพื่อดูระดับการคิดปัจจุบัน
|
||||
|
||||
## การนำไปใช้โดยเอเจนต์
|
||||
## การนำไปใช้ตามเอเจนต์
|
||||
|
||||
- **Embedded Pi**: ระดับที่ resolve แล้วจะถูกส่งไปยัง runtime ของ Pi agent ภายใน process
|
||||
- **Pi แบบฝังตัว**: ระดับที่ตัดสินแล้วจะถูกส่งไปยังรันไทม์เอเจนต์ Pi ภายในโปรเซส
|
||||
|
||||
## โหมด Fast (/fast)
|
||||
## โหมดเร็ว (/fast)
|
||||
|
||||
- ระดับ: `on|off`
|
||||
- ข้อความที่มีแต่ directive จะสลับ session fast-mode override และตอบกลับ `Fast mode enabled.` / `Fast mode disabled.`
|
||||
- ส่ง `/fast` (หรือ `/fast status`) โดยไม่มีโหมดเพื่อดูสถานะ fast-mode ที่มีผลอยู่จริงในปัจจุบัน
|
||||
- OpenClaw จะ resolve fast mode ตามลำดับนี้:
|
||||
1. `/fast on|off` แบบ inline/directive-only
|
||||
2. Session override
|
||||
- ข้อความที่เป็นคำสั่งเท่านั้นจะสลับการแทนที่โหมดเร็วของเซสชันและตอบกลับ `เปิดโหมดเร็วแล้ว` / `ปิดโหมดเร็วแล้ว`
|
||||
- ส่ง `/fast` (หรือ `/fast status`) โดยไม่ระบุโหมดเพื่อดูสถานะโหมดเร็วที่มีผลจริงในปัจจุบัน
|
||||
- OpenClaw ตัดสินโหมดเร็วตามลำดับนี้:
|
||||
1. `/fast on|off` แบบอินไลน์/คำสั่งเท่านั้น
|
||||
2. การแทนที่ระดับเซสชัน
|
||||
3. ค่าเริ่มต้นต่อเอเจนต์ (`agents.list[].fastModeDefault`)
|
||||
4. การกำหนดค่าต่อโมเดล: `agents.defaults.models["<provider>/<model>"].params.fastMode`
|
||||
5. Fallback: `off`
|
||||
- สำหรับ `openai/*`, fast mode จะถูกแมปเป็นการประมวลผลแบบลำดับความสำคัญของ OpenAI โดยส่ง `service_tier=priority` บน Requests ของ Responses ที่รองรับ
|
||||
- สำหรับ `openai-codex/*`, fast mode จะส่งแฟล็ก `service_tier=priority` เดียวกันบน Codex Responses OpenClaw ใช้สวิตช์ `/fast` ร่วมกันหนึ่งตัวข้ามทั้งสองเส้นทาง auth
|
||||
- สำหรับคำขอ `anthropic/*` แบบ public โดยตรง รวมถึงทราฟฟิกที่ยืนยันตัวตนด้วย OAuth ที่ส่งไปยัง `api.anthropic.com`, fast mode จะถูกแมปไปยัง Anthropic service tiers: `/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`
|
||||
- model params แบบ `serviceTier` / `service_tier` ของ Anthropic ที่ระบุอย่างชัดเจน จะมีสิทธิ์เหนือค่าเริ่มต้นของ fast-mode เมื่อทั้งสองอย่างถูกตั้งไว้ OpenClaw ยังคงข้ามการ inject Anthropic service-tier สำหรับ base URL ของพร็อกซีที่ไม่ใช่ Anthropic
|
||||
- `/status` จะแสดง `Fast` เฉพาะเมื่อเปิด fast mode
|
||||
4. config ต่อโมเดล: `agents.defaults.models["<provider>/<model>"].params.fastMode`
|
||||
5. การย้อนกลับ: `off`
|
||||
- สำหรับ `openai/*`, โหมดเร็วจะถูกแมปเป็นการประมวลผลแบบ priority ของ OpenAI โดยส่ง `service_tier=priority` บนคำขอ Responses ที่รองรับ
|
||||
- สำหรับ `openai-codex/*`, โหมดเร็วจะส่งแฟล็ก `service_tier=priority` เดียวกันบน Codex Responses OpenClaw ใช้สวิตช์ `/fast` ร่วมกันตัวเดียวระหว่างทั้งสองเส้นทางการยืนยันตัวตน
|
||||
- สำหรับคำขอ `anthropic/*` สาธารณะแบบตรง รวมถึงทราฟฟิกที่ยืนยันตัวตนด้วย OAuth ซึ่งส่งไปยัง `api.anthropic.com`, โหมดเร็วจะถูกแมปเป็น Anthropic service tier: `/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 ยังจะข้ามการแทรก service tier ของ Anthropic สำหรับ base URL ของพร็อกซีที่ไม่ใช่ Anthropic
|
||||
- `/status` จะแสดง `Fast` เฉพาะเมื่อเปิดโหมดเร็ว
|
||||
|
||||
## Verbose directives (/verbose หรือ /v)
|
||||
## คำสั่งโหมดละเอียด (/verbose หรือ /v)
|
||||
|
||||
- ระดับ: `on` (minimal) | `full` | `off` (ค่าเริ่มต้น)
|
||||
- ข้อความที่มีแต่ directive จะสลับ session verbose และตอบกลับ `Verbose logging enabled.` / `Verbose logging disabled.`; ระดับที่ไม่ถูกต้องจะคืนคำแนะนำโดยไม่เปลี่ยนสถานะ
|
||||
- `/verbose off` จะจัดเก็บ session override แบบชัดเจน; ล้างได้ผ่าน Sessions UI โดยเลือก `inherit`
|
||||
- Inline directive มีผลกับข้อความนั้นเท่านั้น; มิฉะนั้นจะใช้ session/global defaults
|
||||
- ส่ง `/verbose` (หรือ `/verbose:`) โดยไม่มีอาร์กิวเมนต์เพื่อดูระดับ verbose ปัจจุบัน
|
||||
- เมื่อเปิด verbose เอเจนต์ที่ปล่อย structured tool results (Pi, JSON agents อื่นๆ) จะส่งแต่ละ tool call กลับมาเป็นข้อความ metadata-only ของตัวเอง โดยเติมคำนำหน้าด้วย `<emoji> <tool-name>: <arg>` เมื่อมี (path/command) สรุป tool เหล่านี้จะถูกส่งทันทีที่แต่ละ tool เริ่มทำงาน (เป็นบับเบิลแยก) ไม่ใช่สตรีมมิงเดลตา
|
||||
- สรุปความล้มเหลวของ tool ยังคงมองเห็นได้ในโหมดปกติ แต่ suffix รายละเอียดข้อผิดพลาดแบบดิบจะถูกซ่อนไว้ เว้นแต่ verbose จะเป็น `on` หรือ `full`
|
||||
- เมื่อ verbose เป็น `full` เอาต์พุตของ tool จะถูกส่งต่อหลังเสร็จสิ้นด้วย (บับเบิลแยก ถูกตัดให้สั้นในระดับปลอดภัย) หากคุณสลับ `/verbose on|full|off` ขณะที่กำลังมี run อยู่ บับเบิลของ tool ที่ตามมาจะใช้การตั้งค่าใหม่
|
||||
- ระดับ: `on` (ขั้นต่ำ) | `full` | `off` (ค่าเริ่มต้น)
|
||||
- ข้อความที่เป็นคำสั่งเท่านั้นจะสลับ verbose ของเซสชันและตอบกลับ `เปิดการบันทึกแบบละเอียดแล้ว` / `ปิดการบันทึกแบบละเอียดแล้ว`; ระดับที่ไม่ถูกต้องจะคืนคำแนะนำโดยไม่เปลี่ยนสถานะ
|
||||
- `/verbose off` จะจัดเก็บการแทนที่ระดับเซสชันแบบชัดเจน; ล้างได้ผ่าน UI ของ Sessions โดยเลือก `inherit`
|
||||
- คำสั่งอินไลน์มีผลกับข้อความนั้นเท่านั้น; ในกรณีอื่นจะใช้ค่าเริ่มต้นระดับเซสชัน/ส่วนกลาง
|
||||
- ส่ง `/verbose` (หรือ `/verbose:`) โดยไม่ระบุอาร์กิวเมนต์เพื่อดูระดับ verbose ปัจจุบัน
|
||||
- เมื่อเปิด verbose เอเจนต์ที่ปล่อยผลลัพธ์เครื่องมือแบบมีโครงสร้าง (Pi, เอเจนต์ JSON อื่น ๆ) จะส่งการเรียกใช้เครื่องมือแต่ละครั้งกลับมาเป็นข้อความแบบ metadata-only ของตัวเอง โดยมีคำนำหน้าเป็น `<emoji> <tool-name>: <arg>` เมื่อมีข้อมูล (path/command) สรุปเครื่องมือเหล่านี้จะถูกส่งทันทีที่แต่ละเครื่องมือเริ่มทำงาน (เป็นบับเบิลแยก) ไม่ใช่เป็น streaming delta
|
||||
- สรุปความล้มเหลวของเครื่องมือยังคงมองเห็นได้ในโหมดปกติ แต่ส่วนต่อท้ายรายละเอียดข้อผิดพลาดดิบจะถูกซ่อน เว้นแต่ verbose จะเป็น `on` หรือ `full`
|
||||
- เมื่อ verbose เป็น `full` เอาต์พุตของเครื่องมือจะถูกส่งต่อหลังเสร็จสิ้นด้วย (บับเบิลแยก ตัดทอนให้มีความยาวที่ปลอดภัย) หากคุณสลับ `/verbose on|full|off` ระหว่างที่งานกำลังรันอยู่ บับเบิลเครื่องมือถัดไปจะใช้การตั้งค่าใหม่
|
||||
|
||||
## Plugin trace directives (/trace)
|
||||
## คำสั่งติดตาม Plugin (/trace)
|
||||
|
||||
- ระดับ: `on` | `off` (ค่าเริ่มต้น)
|
||||
- ข้อความที่มีแต่ directive จะสลับ session plugin trace output และตอบกลับ `Plugin trace enabled.` / `Plugin trace disabled.`
|
||||
- Inline directive มีผลกับข้อความนั้นเท่านั้น; มิฉะนั้นจะใช้ session/global defaults
|
||||
- ส่ง `/trace` (หรือ `/trace:`) โดยไม่มีอาร์กิวเมนต์เพื่อดูระดับ trace ปัจจุบัน
|
||||
- `/trace` แคบกว่า `/verbose`: มันเปิดเผยเฉพาะบรรทัด trace/debug ที่ Plugin เป็นเจ้าของ เช่น Active Memory debug summaries
|
||||
- บรรทัด trace อาจปรากฏใน `/status` และเป็นข้อความวินิจฉัยติดตามผลหลังคำตอบปกติของ assistant
|
||||
- ข้อความที่เป็นคำสั่งเท่านั้นจะสลับเอาต์พุตการติดตาม Plugin ของเซสชันและตอบกลับ `เปิดการติดตาม Plugin แล้ว` / `ปิดการติดตาม Plugin แล้ว`
|
||||
- คำสั่งอินไลน์มีผลกับข้อความนั้นเท่านั้น; ในกรณีอื่นจะใช้ค่าเริ่มต้นระดับเซสชัน/ส่วนกลาง
|
||||
- ส่ง `/trace` (หรือ `/trace:`) โดยไม่ระบุอาร์กิวเมนต์เพื่อดูระดับ trace ปัจจุบัน
|
||||
- `/trace` แคบกว่า `/verbose`: มันจะแสดงเฉพาะบรรทัด trace/debug ที่เป็นของ Plugin เช่น สรุปดีบักของ Active Memory
|
||||
- บรรทัด trace อาจปรากฏใน `/status` และเป็นข้อความวินิจฉัยติดตามหลังจากคำตอบปกติของผู้ช่วย
|
||||
|
||||
## การมองเห็น reasoning (/reasoning)
|
||||
## การมองเห็นการให้เหตุผล (/reasoning)
|
||||
|
||||
- ระดับ: `on|off|stream`
|
||||
- ข้อความที่มีแต่ directive จะสลับว่าจะให้แสดงบล็อกการคิดในคำตอบหรือไม่
|
||||
- เมื่อเปิดใช้งาน reasoning จะถูกส่งเป็น **ข้อความแยก** โดยมีคำนำหน้า `Reasoning:`
|
||||
- `stream` (Telegram เท่านั้น): สตรีม reasoning เข้าไปใน Telegram draft bubble ระหว่างกำลังสร้างคำตอบ จากนั้นส่งคำตอบสุดท้ายโดยไม่มี reasoning
|
||||
- Alias: `/reason`
|
||||
- ส่ง `/reasoning` (หรือ `/reasoning:`) โดยไม่มีอาร์กิวเมนต์เพื่อดูระดับ reasoning ปัจจุบัน
|
||||
- ลำดับการ resolve: inline directive, ตามด้วย session override, จากนั้นค่าเริ่มต้นต่อเอเจนต์ (`agents.list[].reasoningDefault`) แล้ว fallback (`off`)
|
||||
- ข้อความที่เป็นคำสั่งเท่านั้นจะสลับว่าจะแสดงบล็อกการคิดในคำตอบหรือไม่
|
||||
- เมื่อเปิดใช้งาน การให้เหตุผลจะถูกส่งเป็น **ข้อความแยกต่างหาก** ที่ขึ้นต้นด้วย `Reasoning:`
|
||||
- `stream` (Telegram เท่านั้น): สตรีมการให้เหตุผลเข้าไปในบับเบิลร่างของ Telegram ระหว่างที่กำลังสร้างคำตอบ จากนั้นจึงส่งคำตอบสุดท้ายโดยไม่มีการให้เหตุผล
|
||||
- ชื่อเรียกแทน: `/reason`
|
||||
- ส่ง `/reasoning` (หรือ `/reasoning:`) โดยไม่ระบุอาร์กิวเมนต์เพื่อดูระดับการให้เหตุผลปัจจุบัน
|
||||
- ลำดับการตัดสินใจ: คำสั่งอินไลน์ จากนั้นการแทนที่ระดับเซสชัน จากนั้นค่าเริ่มต้นต่อเอเจนต์ (`agents.list[].reasoningDefault`) จากนั้นการย้อนกลับ (`off`)
|
||||
|
||||
## ที่เกี่ยวข้อง
|
||||
|
||||
- เอกสารโหมด Elevated อยู่ที่ [Elevated mode](/th/tools/elevated)
|
||||
- เอกสารโหมดยกระดับอยู่ที่ [Elevated mode](/th/tools/elevated)
|
||||
|
||||
## Heartbeats
|
||||
|
||||
- เนื้อหาของ Heartbeat probe คือ heartbeat prompt ที่กำหนดค่าไว้ (ค่าเริ่มต้น: `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.`) Inline directives ใน heartbeat message จะมีผลตามปกติ (แต่ควรหลีกเลี่ยงการเปลี่ยน session defaults จาก heartbeats)
|
||||
- โดยค่าเริ่มต้นการส่ง Heartbeat จะส่งเฉพาะ payload สุดท้าย หากต้องการส่งข้อความ `Reasoning:` แยกด้วย (เมื่อมี) ให้ตั้ง `agents.defaults.heartbeat.includeReasoning: true` หรือแบบต่อเอเจนต์ `agents.list[].heartbeat.includeReasoning: true`
|
||||
- เนื้อหาคำขอของ 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` ต่อเอเจนต์
|
||||
|
||||
## Web chat UI
|
||||
## UI เว็บแชต
|
||||
|
||||
- ตัวเลือกการคิดในเว็บแชตจะสะท้อนระดับที่จัดเก็บไว้ของเซสชันจาก inbound session store/config ตอนที่โหลดหน้า
|
||||
- การเลือกอีกระดับหนึ่งจะเขียน session override ทันทีผ่าน `sessions.patch`; จะไม่รอการส่งครั้งถัดไป และไม่ใช่ one-shot `thinkingOnce` override
|
||||
- ตัวเลือกแรกจะเป็น `Default (<resolved level>)` เสมอ โดย resolved default จะมาจาก provider thinking profile ของโมเดลที่ใช้งานอยู่ในเซสชัน
|
||||
- ตัวเลือกจะใช้ `thinkingOptions` ที่ส่งกลับมาจาก gateway session row Browser UI จะไม่เก็บรายการ provider regex ของตัวเอง; Plugins เป็นเจ้าของชุดระดับที่เฉพาะกับโมเดล
|
||||
- `/think:<level>` ยังคงใช้งานได้และอัปเดตระดับของเซสชันที่จัดเก็บไว้เดียวกัน ดังนั้น chat directives และตัวเลือกจึงสอดคล้องกัน
|
||||
- ตัวเลือกระดับการคิดของเว็บแชตจะสะท้อนระดับที่จัดเก็บไว้ของเซสชันจาก session store/config ขาเข้าเมื่อหน้าโหลด
|
||||
- การเลือกระดับอื่นจะเขียนการแทนที่ระดับเซสชันทันทีผ่าน `sessions.patch`; ไม่รอการส่งครั้งถัดไปและไม่ใช่การแทนที่ `thinkingOnce` แบบครั้งเดียว
|
||||
- ตัวเลือกแรกจะเป็น `Default (<resolved level>)` เสมอ โดยค่าเริ่มต้นที่ตัดสินแล้วมาจากโปรไฟล์การคิดของผู้ให้บริการของโมเดลเซสชันที่ใช้งานอยู่ บวกกับตรรกะการย้อนกลับแบบเดียวกับที่ `/status` และ `session_status` ใช้
|
||||
- ตัวเลือกนี้ใช้ `thinkingOptions` ที่ส่งกลับโดยแถว session ของ Gateway UI บนเบราว์เซอร์จะไม่เก็บรายการ regex ของผู้ให้บริการไว้เอง ปลั๊กอินเป็นเจ้าของชุดระดับเฉพาะโมเดล
|
||||
- `/think:<level>` ยังใช้งานได้และจะอัปเดตระดับเซสชันที่จัดเก็บไว้ตัวเดียวกัน ดังนั้นคำสั่งในแชตและตัวเลือกจะซิงก์กัน
|
||||
|
||||
## Provider profiles
|
||||
## โปรไฟล์ผู้ให้บริการ
|
||||
|
||||
- Provider plugins สามารถเปิดเผย `resolveThinkingProfile(ctx)` เพื่อกำหนดระดับที่รองรับและค่าเริ่มต้นของโมเดล
|
||||
- แต่ละระดับใน profile จะมี `id` แบบ canonical ที่จัดเก็บไว้ (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` หรือ `max`) และอาจมี `label` สำหรับการแสดงผล ผู้ให้บริการแบบไบนารีใช้ `{ id: "low", label: "on" }`
|
||||
- hooks แบบเดิมที่เผยแพร่อยู่แล้ว (`supportsXHighThinking`, `isBinaryThinking` และ `resolveDefaultThinkingLevel`) ยังคงอยู่ในฐานะ compatibility adapters แต่ชุดระดับแบบกำหนดเองใหม่ควรใช้ `resolveThinkingProfile`
|
||||
- Gateway rows จะเปิดเผย `thinkingOptions` และ `thinkingDefault` เพื่อให้ ACP/chat clients เรนเดอร์ profile เดียวกันกับที่ runtime validation ใช้
|
||||
- ปลั๊กอินผู้ให้บริการสามารถเปิดเผย `resolveThinkingProfile(ctx)` เพื่อกำหนดระดับและค่าเริ่มต้นที่โมเดลรองรับ
|
||||
- แต่ละระดับในโปรไฟล์มี `id` ตามรูปแบบมาตรฐานที่จัดเก็บไว้ (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` หรือ `max`) และอาจมี `label` สำหรับแสดงผล ผู้ให้บริการแบบไบนารีใช้ `{ id: "low", label: "on" }`
|
||||
- hook แบบดั้งเดิมที่เผยแพร่อยู่ (`supportsXHighThinking`, `isBinaryThinking` และ `resolveDefaultThinkingLevel`) ยังคงอยู่เป็นตัวแปลงเพื่อความเข้ากันได้ แต่ชุดระดับแบบกำหนดเองใหม่ควรใช้ `resolveThinkingProfile`
|
||||
- แถว Gateway เปิดเผย `thinkingOptions` และ `thinkingDefault` เพื่อให้ไคลเอนต์ ACP/แชตแสดงผลโปรไฟล์เดียวกันกับที่ใช้ในการตรวจสอบความถูกต้องขณะรันไทม์
|
||||
|
||||
Loading…
Reference in New Issue
Block a user