diff --git a/docs/th/ci.md b/docs/th/ci.md index 35ef9a7b7..9349cbae9 100644 --- a/docs/th/ci.md +++ b/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 # สรุป wall time, queue time และงานที่ช้าที่สุด ``` diff --git a/docs/th/cli/status.md b/docs/th/cli/status.md index 3899abfb4..9fb30a233 100644 --- a/docs/th/cli/status.md +++ b/docs/th/cli/status.md @@ -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 (ตัดทอนเพื่อให้อ่านง่าย) โดยไม่หยุดการสร้างรายงาน diff --git a/docs/th/providers/openai.md b/docs/th/providers/openai.md index 1a54c6e54..abd28e77d 100644 --- a/docs/th/providers/openai.md +++ b/docs/th/providers/openai.md @@ -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/` | ใช่ | - | โมเดลแบบสมัครใช้งาน Codex | model provider `openai-codex/` | ใช่ | - | การค้นหาเว็บฝั่งเซิร์ฟเวอร์ | 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/` | ใช่ | + | โมเดลการสมัครใช้งาน Codex | ผู้ให้บริการโมเดล `openai-codex/` | ใช่ | + | การค้นหาเว็บฝั่งเซิร์ฟเวอร์ | เครื่องมือ 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 | ใช่ | ## เริ่มต้นใช้งาน - เลือกวิธีการยืนยันตัวตนที่คุณต้องการ และทำตามขั้นตอนการตั้งค่า + เลือกวิธีการยืนยันตัวตนที่คุณต้องการ แล้วทำตามขั้นตอนการตั้งค่า - - **เหมาะที่สุดสำหรับ:** การเข้าถึง API โดยตรงและการคิดค่าบริการตามการใช้งาน + + **เหมาะสำหรับ:** การเข้าถึง API โดยตรงและการคิดค่าบริการตามการใช้งาน - - สร้างหรือคัดลอก API key จาก [แดชบอร์ด OpenAI Platform](https://platform.openai.com/api-keys) + + สร้างหรือคัดลอกคีย์ API จาก [แดชบอร์ด OpenAI Platform](https://platform.openai.com/api-keys) - + ```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` | การลงชื่อเข้าใช้ ChatGPT/Codex จะถูกกำหนดเส้นทางผ่าน `openai-codex/*` ไม่ใช่ `openai/*` @@ -89,27 +89,27 @@ x-i18n: ``` - 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 เท่านั้น - **เหมาะที่สุดสำหรับ:** การใช้การสมัครใช้งาน ChatGPT/Codex ของคุณแทน API key แยกต่างหาก Codex cloud ต้องใช้การลงชื่อเข้าใช้ ChatGPT + **เหมาะสำหรับ:** ใช้การสมัครใช้งาน ChatGPT/Codex ของคุณแทนคีย์ API แยกต่างหาก Codex cloud ต้องใช้การลงชื่อเข้าใช้ ChatGPT - + ```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) | - เส้นทางนี้ถูกแยกจาก `openai/gpt-5.4` โดยเจตนา ใช้ `openai/*` กับ API key สำหรับการเข้าถึง Platform โดยตรง และใช้ `openai-codex/*` สำหรับการเข้าถึงผ่านการสมัครใช้งาน Codex + เส้นทางนี้แยกจาก `openai/gpt-5.4` โดยตั้งใจ ใช้ `openai/*` กับคีย์ API สำหรับการเข้าถึง Platform โดยตรง และใช้ `openai-codex/*` สำหรับการเข้าถึงผ่านการสมัครใช้งาน Codex ### ตัวอย่าง config @@ -147,19 +147,19 @@ x-i18n: ``` - Onboarding จะไม่นำเข้า OAuth material จาก `~/.codex` อีกต่อไป ให้ลงชื่อเข้าใช้ด้วย browser OAuth (ค่าเริ่มต้น) หรือโฟลว์ device-code ด้านบน — OpenClaw จะจัดการข้อมูลรับรองที่ได้ไว้ในที่เก็บ auth ของเอเจนต์ของตัวเอง + Onboarding จะไม่ import ข้อมูล OAuth จาก `~/.codex` อีกต่อไป ให้ลงชื่อเข้าใช้ด้วย browser OAuth (ค่าเริ่มต้น) หรือโฟลว์ device-code ด้านบน — OpenClaw จะจัดการข้อมูลรับรองที่ได้ในที่เก็บการยืนยันตัวตนของเอเจนต์ของตัวเอง - ### ขีดจำกัด 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: ``` - ใช้ `contextWindow` เพื่อประกาศข้อมูลเมตา native ของโมเดล ใช้ `contextTokens` เพื่อจำกัดงบประมาณ context ของรันไทม์ + ใช้ `contextWindow` เพื่อประกาศข้อมูลเมตาเนทีฟของโมเดล ใช้ `contextTokens` เพื่อจำกัดงบประมาณ context ระหว่างรันไทม์ -## การสร้างรูปภาพ +## การสร้างภาพ -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` ที่มากับระบบจะลงทะเบี ``` -ดู [การสร้างรูปภาพ](/th/tools/image-generation) สำหรับพารามิเตอร์เครื่องมือแบบใช้ร่วมกัน การเลือก provider และพฤติกรรม failover +ดู [การสร้างภาพ](/th/tools/image-generation) สำหรับพารามิเตอร์เครื่องมือที่ใช้ร่วมกัน การเลือก provider และพฤติกรรม failover -`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` ที่มากับระบบจะลงทะเบี ``` -ดู [การสร้างวิดีโอ](/th/tools/video-generation) สำหรับพารามิเตอร์เครื่องมือแบบใช้ร่วมกัน การเลือก provider และพฤติกรรม failover +ดู [การสร้างวิดีโอ](/th/tools/video-generation) สำหรับพารามิเตอร์เครื่องมือที่ใช้ร่วมกัน การเลือก provider และพฤติกรรม failover -## ส่วนเสริมพรอมป์ต 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"` | ปิดเฉพาะเลเยอร์สไตล์แบบเป็นมิตร | @@ -284,27 +282,27 @@ provider harness Codex แบบ native ที่มากับระบบ (`c -ค่าต่าง ๆ ไม่สนใจตัวพิมพ์เล็กใหญ่ในรันไทม์ ดังนั้น `"Off"` และ `"off"` จะปิดเลเยอร์รูปแบบที่เป็นมิตรเหมือนกัน +ค่าต่างๆ ไม่สนตัวพิมพ์เล็ก-ใหญ่ในระหว่างรันไทม์ ดังนั้นทั้ง `"Off"` และ `"off"` จะปิดเลเยอร์สไตล์แบบเป็นมิตร -`plugins.entries.openai.config.personality` แบบเดิมยังคงถูกอ่านในฐานะ compatibility fallback เมื่อไม่ได้ตั้งค่าร่วม `agents.defaults.promptOverlays.gpt5.personality` +ระบบยังคงอ่าน `plugins.entries.openai.config.personality` แบบเดิมเป็น fallback เพื่อความเข้ากันได้ เมื่อไม่ได้ตั้งค่า `agents.defaults.promptOverlays.gpt5.personality` ที่ใช้ร่วมกัน -## เสียงและสุนทรพจน์ +## เสียงและคำพูด - 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 ``` - ตั้งค่า `OPENAI_TTS_BASE_URL` เพื่อ override TTS base URL โดยไม่กระทบ endpoint ของ chat API + ตั้งค่า `OPENAI_TTS_BASE_URL` เพื่อแทนที่ TTS base URL โดยไม่กระทบ endpoint ของ chat API - - plugin `openai` ที่มากับระบบจะลงทะเบียน speech-to-text แบบแบตช์ผ่าน - พื้นผิวการถอดเสียงของ media-understanding ใน OpenClaw + + 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 เสียงมีเดียที่ใช้ร่วมกัน หรือคำขอถอดเสียงรายครั้ง - - plugin `openai` ที่มากับระบบจะลงทะเบียนการถอดเสียงแบบเรียลไทม์สำหรับ Voice Call plugin + + 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` | - ใช้การเชื่อมต่อ 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` แทน - - plugin `openai` ที่มากับระบบจะลงทะเบียนเสียงแบบเรียลไทม์สำหรับ Voice Call plugin + + 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` | รองรับ Azure OpenAI ผ่านคีย์ config `azureEndpoint` และ `azureDeployment` รองรับการเรียกใช้เครื่องมือแบบสองทิศทาง ใช้รูปแบบเสียง G.711 u-law @@ -399,23 +398,148 @@ provider harness Codex แบบ native ที่มากับระบบ (`c +## endpoint ของ Azure OpenAI + +provider `openai` ที่มาพร้อมกันสามารถกำหนดเป้าหมายไปยัง resource ของ Azure OpenAI สำหรับการสร้างภาพ +ได้โดยการแทนที่ base URL ในเส้นทางการสร้างภาพ OpenClaw +จะตรวจจับ hostname ของ Azure บน `models.providers.openai.baseUrl` และสลับไปใช้ +รูปแบบคำขอของ Azure โดยอัตโนมัติ + + +เสียงแบบเรียลไทม์ใช้เส้นทาง config แยกต่างหาก +(`plugins.entries.voice-call.config.realtime.providers.openai.azureEndpoint`) +และไม่ได้รับผลจาก `models.providers.openai.baseUrl` โปรดดูหัวข้อ **เสียงแบบเรียลไทม์** +ใต้ [เสียงและคำพูด](#voice-and-speech) สำหรับการตั้งค่า Azure ของฟีเจอร์นี้ + + +ใช้ 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://.openai.azure.com", + apiKey: "", + }, + }, + }, +} +``` + +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 + + +การกำหนดเส้นทาง Azure สำหรับเส้นทางการสร้างภาพของ provider `openai` +ต้องใช้ OpenClaw 2026.4.22 หรือใหม่กว่า เวอร์ชันก่อนหน้านั้นจะมองว่า +`openai.baseUrl` แบบกำหนดเองทั้งหมดเป็น endpoint สาธารณะของ OpenAI และจะล้มเหลวกับ deployment +ภาพบน Azure + + +### เวอร์ชัน 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 + + +Azure OpenAI ใช้การขนส่งแบบเนทีฟและพฤติกรรม compat แต่จะไม่ได้รับ +header attribution แบบซ่อนของ OpenClaw โปรดดูหัวข้อ **เส้นทางแบบเนทีฟเทียบกับแบบเข้ากันได้กับ OpenAI** +ใต้ [การกำหนดค่าขั้นสูง](#advanced-configuration) +สำหรับรายละเอียด + + + +สำหรับ provider Azure OpenAI Responses แบบแยกต่างหาก (ต่างจาก provider `openai`) +โปรดดู model ref `azure-openai-responses/*` ในหัวข้อ +[Compaction ฝั่งเซิร์ฟเวอร์](#server-side-compaction-responses-api) + + + +ทราฟฟิก Azure chat และ Responses ต้องใช้ config provider/API แบบเฉพาะของ Azure เพิ่มเติม +นอกเหนือจากการแทนที่ base URL หากคุณต้องการเรียกใช้โมเดล Azure นอกเหนือจากการ +สร้างภาพ ให้ใช้โฟลว์ onboarding หรือ config provider ที่ตั้งค่า +รูปแบบ Azure API/auth ที่เหมาะสม แทนการสมมติว่า `openai.baseUrl` เพียงอย่างเดียวเพียงพอ + + ## การกำหนดค่าขั้นสูง - - OpenClaw ใช้ WebSocket-first พร้อม SSE fallback (`"auto"`) สำหรับทั้ง `openai/*` และ `openai-codex/*` + + 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 - - OpenClaw เปิดใช้ WebSocket warm-up โดยค่าเริ่มต้นสำหรับ `openai/*` เพื่อลด latency ของเทิร์นแรก + + OpenClaw เปิดใช้การวอร์มอัป WebSocket โดยค่าเริ่มต้นสำหรับ `openai/*` เพื่อลดเวลาแฝงของเทิร์นแรก ```json5 - // ปิด warm-up + // ปิดใช้งานการวอร์มอัป { agents: { defaults: { @@ -459,13 +583,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c - - OpenClaw เปิดเผยตัวสลับ fast mode แบบใช้ร่วมกันสำหรับทั้ง `openai/*` และ `openai-codex/*`: + + OpenClaw เปิดให้ใช้สวิตช์โหมดเร็วแบบใช้ร่วมกันสำหรับทั้ง `openai/*` และ `openai-codex/*`: - - **Chat/UI:** `/fast status|on|off` + - **แชต/UI:** `/fast status|on|off` - **Config:** `agents.defaults.models["/"].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 ``` - การ override ระดับ session มีลำดับความสำคัญเหนือ config การล้าง session override ใน Sessions UI จะทำให้ session กลับไปใช้ค่าเริ่มต้นที่กำหนดไว้ + การแทนที่ระดับเซสชันมีผลเหนือกว่า config การล้างการแทนที่ระดับเซสชันใน Sessions UI จะทำให้เซสชันกลับไปใช้ค่าเริ่มต้นที่กำหนดไว้ - - API ของ OpenAI เปิดเผยการประมวลผลแบบ priority ผ่าน `service_tier` ตั้งค่าเป็นรายโมเดลใน OpenClaw ได้: + + API ของ OpenAI เปิดให้ใช้การประมวลผลแบบ priority ผ่าน `service_tier` ตั้งค่าต่อโมเดลใน OpenClaw ได้ดังนี้: ```json5 { @@ -505,7 +629,7 @@ provider harness Codex แบบ native ที่มากับระบบ (`c ค่าที่รองรับ: `auto`, `default`, `flex`, `priority` - `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` @@ -513,13 +637,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c สำหรับโมเดล 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` เมื่อไม่มีข้อมูล) - - มีประโยชน์สำหรับ endpoints ที่เข้ากันได้ เช่น Azure OpenAI Responses: + + มีประโยชน์สำหรับ endpoint ที่เข้ากันได้ เช่น Azure OpenAI Responses: ```json5 { @@ -535,7 +659,7 @@ provider harness Codex แบบ native ที่มากับระบบ (`c } ``` - + ```json5 { agents: { @@ -571,13 +695,13 @@ provider harness Codex แบบ native ที่มากับระบบ (`c - `responsesServerCompaction` ควบคุมเฉพาะการแทรก `context_management` เท่านั้น โมเดล OpenAI Responses โดยตรงยังคงบังคับ `store: true` เว้นแต่ compat จะตั้ง `supportsStore: false` + `responsesServerCompaction` ควบคุมเฉพาะการแทรก `context_management` เท่านั้น โมเดล Direct OpenAI Responses จะยังคงบังคับ `store: true` เว้นแต่ compat จะตั้งค่า `supportsStore: false` - สำหรับการรันตระกูล 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` โดยอัตโนมัติสำหรับงานที่มีสาระสำคัญ + - แสดงสถานะถูกบล็อกอย่างชัดเจนหากโมเดลยังคงวางแผนโดยไม่ลงมือทำ - จำกัดเฉพาะการรันตระกูล GPT-5 ของ OpenAI และ Codex เท่านั้น providers อื่นและตระกูลโมเดลรุ่นเก่าจะยังคงใช้พฤติกรรมค่าเริ่มต้น + จำกัดขอบเขตเฉพาะการรันตระกูล GPT-5 ของ OpenAI และ Codex เท่านั้น providers อื่นและตระกูลโมเดลที่เก่ากว่าจะยังคงใช้พฤติกรรมเริ่มต้น - - OpenClaw ปฏิบัติต่อ direct OpenAI, Codex และ Azure OpenAI endpoints แตกต่างจากพร็อกซี `/v1` แบบ OpenAI-compatible ทั่วไป: + + 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 แบบซ่อน @@ -623,16 +747,16 @@ provider harness Codex แบบ native ที่มากับระบบ (`c ## ที่เกี่ยวข้อง - - การเลือก providers, model refs และพฤติกรรม failover + + การเลือก provider, model ref และพฤติกรรม failover - - พารามิเตอร์เครื่องมือรูปภาพแบบใช้ร่วมกันและการเลือก provider + + พารามิเตอร์เครื่องมือภาพที่ใช้ร่วมกันและการเลือก provider - - พารามิเตอร์เครื่องมือวิดีโอแบบใช้ร่วมกันและการเลือก provider + + พารามิเตอร์เครื่องมือวิดีโอที่ใช้ร่วมกันและการเลือก provider - + รายละเอียดการยืนยันตัวตนและกฎการใช้ข้อมูลรับรองซ้ำ diff --git a/docs/th/reference/test.md b/docs/th/reference/test.md index af8189eec..3bcf715fc 100644 --- a/docs/th/reference/test.md +++ b/docs/th/reference/test.md @@ -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/` สำหรับ 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 ` ทำ 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/` สำหรับ 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 ` ทำ 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=` และตั้ง `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=` และตั้ง `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=` ตัวรันจะหยุดจัดคิว 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//` +- `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 ` สำหรับโฮสต์ที่หน่วยความจำจำกัด ให้ใช้: +หาก `pnpm test` มีอาการ flake บนเครื่องที่มีโหลดสูง ให้รันซ้ำหนึ่งครั้งก่อนจะถือว่าเป็น regression จากนั้นค่อยแยกตรวจด้วย `pnpm 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 diff --git a/docs/th/tools/image-generation.md b/docs/th/tools/image-generation.md index 727ae29c9..384f0cff5 100644 --- a/docs/th/tools/image-generation.md +++ b/docs/th/tools/image-generation.md @@ -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` ช่วยให้เอเจนต์สร้างและแก้ไขรูปภาพโดยใช้ผู้ให้บริการที่คุณกำหนดค่าไว้ รูปภาพที่สร้างขึ้นจะถูกส่งให้อัตโนมัติเป็นไฟล์แนบสื่อในคำตอบของเอเจนต์ -เครื่องมือนี้จะแสดงขึ้นก็ต่อเมื่อมี image generation provider อย่างน้อยหนึ่งตัวพร้อมใช้งาน หากคุณไม่เห็น `image_generate` ในรายการเครื่องมือของเอเจนต์ ให้ตั้งค่า `agents.defaults.imageGenerationModel` หรือกำหนด provider API key +เครื่องมือนี้จะแสดงขึ้นก็ต่อเมื่อมีผู้ให้บริการสร้างรูปภาพอย่างน้อยหนึ่งรายเท่านั้น หากคุณไม่เห็น `image_generate` ในเครื่องมือของเอเจนต์ ให้กำหนดค่า `agents.defaults.imageGenerationModel` หรือตั้งค่า API key ของผู้ให้บริการ ## เริ่มต้นอย่างรวดเร็ว -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 diff --git a/docs/th/tools/plugin.md b/docs/th/tools/plugin.md index 1e9d2b99d..48284e204 100644 --- a/docs/th/tools/plugin.md +++ b/docs/th/tools/plugin.md @@ -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 โดยชุมชน) ## เริ่มต้นอย่างรวดเร็ว - + ```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** -หากคุณต้องการควบคุมผ่านแชตแบบเนทีฟ ให้เปิดใช้ `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:` โดยตรง หรือใช้ package spec เปล่า (ClawHub ก่อน แล้ว fallback ไป npm) +เส้นทางการติดตั้งจะใช้ตัวแก้ไขเดียวกับ CLI: พาธหรือไฟล์เก็บถาวรในเครื่อง, `clawhub:` +แบบระบุชัดเจน, หรือสเปกแพ็กเกจแบบเปล่า (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` - - - `memory-core` — memory search แบบ bundled (ค่าเริ่มต้นผ่าน `plugins.slots.memory`) - - `memory-lancedb` — หน่วยความจำระยะยาวแบบติดตั้งเมื่อจำเป็น พร้อม auto-recall/capture (ตั้งค่า `plugins.slots.memory = "memory-lancedb"`) + + - `memory-core` — การค้นหาหน่วยความจำแบบ bundled (ค่าเริ่มต้นผ่าน `plugins.slots.memory`) + - `memory-lancedb` — หน่วยความจำระยะยาวแบบ install-on-demand พร้อมการเรียกคืน/บันทึกอัตโนมัติ (ตั้งค่า `plugins.slots.memory = "memory-lancedb"`) - + `elevenlabs`, `microsoft` - - `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 (ปิดโดยค่าเริ่มต้น) -กำลังมองหา 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.\` | สวิตช์ต่อ Plugin + คอนฟิก | +| `entries.\` | สวิตช์เปิด/ปิด + คอนฟิกราย Plugin | -การเปลี่ยนคอนฟิก **ต้องรีสตาร์ต gateway** หาก Gateway กำลังทำงานพร้อม config -watch + in-process restart (ซึ่งเป็นค่าเริ่มต้นของเส้นทาง `openclaw gateway`) -โดยปกติการรีสตาร์ตนั้นจะเกิดขึ้นโดยอัตโนมัติไม่นานหลังจากเขียนคอนฟิกเสร็จ +การเปลี่ยนคอนฟิก **ต้องรีสตาร์ต gateway** หาก Gateway กำลังทำงานพร้อมการเฝ้าดูคอนฟิก +และเปิดใช้การรีสตาร์ตในโปรเซสไว้ (ซึ่งเป็นพฤติกรรมค่าเริ่มต้นของเส้นทาง `openclaw gateway`) +โดยปกติการรีสตาร์ตนั้นจะเกิดขึ้นโดยอัตโนมัติไม่นานหลังจากมีการเขียนคอนฟิก - - - **Disabled**: มี plugin อยู่ แต่กฎการเปิดใช้ทำให้มันถูกปิด คอนฟิกยังคงถูกเก็บไว้ - - **Missing**: คอนฟิกอ้างถึง plugin id ที่ discovery หาไม่เจอ - - **Invalid**: มี plugin อยู่ แต่คอนฟิกไม่ตรงกับ schema ที่ประกาศไว้ + + - **ปิดใช้งาน**: มี Plugin อยู่ แต่กฎการเปิดใช้ปิดมันไว้ คอนฟิกจะยังคงถูกเก็บไว้ + - **ไม่พบ**: คอนฟิกอ้างถึงรหัส Plugin ที่การค้นหาไม่พบ + - **ไม่ถูกต้อง**: มี Plugin อยู่ แต่คอนฟิกของมันไม่ตรงกับ schema ที่ประกาศไว้ -## Discovery และลำดับความสำคัญ +## การค้นหาและลำดับความสำคัญ -OpenClaw สแกนหา plugins ตามลำดับนี้ (ตัวแรกที่ตรงจะชนะ): +OpenClaw จะสแกนหา Plugin ตามลำดับนี้ (ที่พบก่อนมีสิทธิ์ก่อน): - - `plugins.load.paths` — paths ของไฟล์หรือไดเรกทอรีที่ระบุชัดเจน + + `plugins.load.paths` — พาธไฟล์หรือไดเรกทอรีที่ระบุชัดเจน - + `\/.openclaw//*.ts` และ `\/.openclaw//*/index.ts` - + `~/.openclaw//*.ts` และ `~/.openclaw//*/index.ts` - - มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (model providers, speech) - ส่วนตัวอื่นต้องเปิดใช้แบบชัดเจน + + มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (ผู้ให้บริการโมเดล, เสียง) + ส่วนตัวอื่นต้องเปิดใช้แบบระบุชัดเจน ### กฎการเปิดใช้ -- `plugins.enabled: false` ปิด plugins ทั้งหมด -- `plugins.deny` มีผลเหนือกว่า `allow` เสมอ -- `plugins.entries.\.enabled: false` ปิด plugin นั้น -- plugins ที่มาจาก workspace จะ **ปิดโดยค่าเริ่มต้น** (ต้องเปิดใช้อย่างชัดเจน) -- bundled plugins เป็นไปตามชุด default-on ที่มีมาให้ เว้นแต่จะมีการ override -- exclusive slots สามารถบังคับเปิด plugin ที่ถูกเลือกสำหรับ slot นั้นได้ +- `plugins.enabled: false` จะปิดใช้งาน Plugin ทั้งหมด +- `plugins.deny` มีสิทธิ์เหนือกว่า allow เสมอ +- `plugins.entries.\.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 # รายละเอียดเชิงลึก -openclaw plugins inspect --json # แบบ machine-readable -openclaw plugins inspect --all # ตารางทั้งระบบ +openclaw plugins inspect --json # แบบอ่านได้โดยเครื่อง +openclaw plugins inspect --all # ตารางทั้งชุด openclaw plugins info # alias ของ inspect -openclaw plugins doctor # diagnostics +openclaw plugins doctor # การวินิจฉัย -openclaw plugins install # ติดตั้ง (ClawHub ก่อน แล้ว npm) +openclaw plugins install # ติดตั้ง (ClawHub ก่อน แล้วจึง npm) openclaw plugins install clawhub: # ติดตั้งจาก ClawHub เท่านั้น openclaw plugins install --force # เขียนทับการติดตั้งที่มีอยู่ -openclaw plugins install # ติดตั้งจาก path ในเครื่อง -openclaw plugins install -l # ลิงก์ (ไม่คัดลอก) สำหรับ dev +openclaw plugins install # ติดตั้งจากพาธในเครื่อง +openclaw plugins install -l # ลิงก์ (ไม่คัดลอก) สำหรับการพัฒนา openclaw plugins install --marketplace openclaw plugins install --marketplace https://github.com// -openclaw plugins install --pin # บันทึก npm spec ที่ resolve แบบตรงตัว +openclaw plugins install --pin # บันทึกสเปก npm ที่ resolve แบบเจาะจง openclaw plugins install --dangerously-force-unsafe-install -openclaw plugins update # อัปเดต plugin เดียว +openclaw plugins update # อัปเดต Plugin หนึ่งตัว openclaw plugins update --dangerously-force-unsafe-install openclaw plugins update --all # อัปเดตทั้งหมด -openclaw plugins uninstall # ลบคอนฟิก/ระเบียนการติดตั้ง +openclaw plugins uninstall # ลบระเบียนคอนฟิก/การติดตั้ง openclaw plugins uninstall --keep-files openclaw plugins marketplace list openclaw plugins marketplace list --json @@ -253,56 +253,62 @@ openclaw plugins enable openclaw plugins disable ``` -bundled plugins มาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (เช่น -bundled model providers, bundled speech providers และ bundled browser -plugin) ส่วน bundled plugins ตัวอื่นยังคงต้องใช้ `openclaw plugins enable ` +bundled plugin จะมาพร้อมกับ OpenClaw หลายตัวเปิดใช้โดยค่าเริ่มต้น (เช่น +bundled ผู้ให้บริการโมเดล, bundled ผู้ให้บริการเสียง, และ bundled browser +plugin) ส่วน bundled plugin อื่น ๆ ยังต้องใช้ `openclaw plugins enable ` -`--force` จะเขียนทับ installed plugin หรือ hook pack ที่มีอยู่ในตำแหน่งเดิม ใช้ -`openclaw plugins update ` สำหรับการอัปเกรดตามปกติของ tracked npm -plugins โดยไม่รองรับร่วมกับ `--link` ซึ่งจะใช้ source path เดิมซ้ำ -แทนการคัดลอกไปยัง managed install target +`--force` จะเขียนทับ Plugin หรือ hook pack ที่ติดตั้งอยู่แล้วในตำแหน่งเดิม ใช้ +`openclaw plugins update ` สำหรับการอัปเกรดตามปกติของ npm +plugin ที่ติดตามอยู่ ไม่รองรับการใช้ร่วมกับ `--link` ซึ่งจะใช้พาธต้นทางซ้ำแทน +การคัดลอกไปยังปลายทางการติดตั้งที่จัดการโดยระบบ -`openclaw plugins update ` ใช้กับ 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 ` ใช้กับการติดตั้งที่ติดตามอยู่ การส่ง +สเปกแพ็กเกจ 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 ` ยังรายงาน bundle capabilities ที่ตรวจพบ พร้อมทั้ง -รายการ MCP และ LSP server entries ที่รองรับหรือไม่รองรับสำหรับ bundle-backed plugins +`openclaw plugins inspect ` ยังรายงานความสามารถของ 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) — รายการจากบุคคลที่สาม diff --git a/docs/th/tools/slash-commands.md b/docs/th/tools/slash-commands.md index f3940291d..e18e1a79f 100644 --- a/docs/th/tools/slash-commands.md +++ b/docs/th/tools/slash-commands.md @@ -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 แบบเฉพาะโฮสต์ใช้ `! ` (โดยมี `/bash ` เป็น alias) +คำสั่งจะถูกจัดการโดย Gateway คำสั่งส่วนใหญ่ต้องส่งเป็นข้อความแบบ **เดี่ยว ๆ** ที่ขึ้นต้นด้วย `/` +คำสั่งแชต bash แบบโฮสต์เท่านั้นใช้ `! ` (โดยมี `/bash ` เป็นนามแฝง) มีสองระบบที่เกี่ยวข้องกัน: -- **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`) เปิดใช้ `! ` เพื่อรันคำสั่ง shell ของโฮสต์ (`/bash ` เป็น 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`) เปิดใช้ `! ` เพื่อรันคำสั่งเชลล์บนโฮสต์ (`/bash ` เป็นนามแฝง; ต้องใช้รายการอนุญาต `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..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..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 ` และ `/session max-age ` ใช้จัดการอายุหมดของ thread binding -- `/think ` ตั้งค่าระดับการคิด ตัวเลือกขึ้นอยู่กับโปรไฟล์ 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 ` และ `/session max-age ` จัดการการหมดอายุของการผูกกับเธรด +- `/think ` ตั้งค่าระดับการคิด ตัวเลือกมาจากโปรไฟล์ผู้ให้บริการของโมเดลที่ใช้งานอยู่ ระดับที่พบบ่อยคือ `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= security= ask= node=` แสดงหรือตั้งค่าเริ่มต้นของ exec - `/model [name|#|status]` แสดงหรือตั้งค่าโมเดล -- `/models [provider] [page] [limit=|size=|all]` แสดงรายการ provider หรือโมเดลของ provider หนึ่ง -- `/queue ` จัดการพฤติกรรมของคิว (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`) พร้อมตัวเลือก เช่น `debounce:2s cap:25 drop:summarize` -- `/help` แสดงสรุปช่วยเหลือแบบย่อ +- `/models [provider] [page] [limit=|size=|all]` แสดงรายการผู้ให้บริการหรือโมเดลของผู้ให้บริการ +- `/queue ` จัดการพฤติกรรมคิว (`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 [input]` รัน Skill ตามชื่อ -- `/allowlist [list|add|remove] ...` จัดการรายการ allowlist ใช้ได้เฉพาะแบบข้อความเท่านั้น -- `/approve ` จัดการพรอมป์อนุมัติ exec -- `/btw ` ถามคำถามข้างเคียงโดยไม่เปลี่ยนบริบทของเซสชันในอนาคต ดู [/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 [input]` เรียกใช้ skill ตามชื่อ +- `/allowlist [list|add|remove] ...` จัดการรายการใน allowlist ใช้ได้เฉพาะแบบข้อความเท่านั้น +- `/approve ` จัดการคำขออนุมัติ exec ให้เสร็จสิ้น +- `/btw ` ถามคำถามแทรกโดยไม่เปลี่ยนบริบทของเซสชันในอนาคต ดู [/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 ` ผูก Discord thread หรือหัวข้อ/บทสนทนา Telegram ปัจจุบันเข้ากับเป้าหมายเซสชัน -- `/unfocus` ลบการผูกปัจจุบัน +- `/focus ` ผูกเธรด Discord หรือหัวข้อ/การสนทนา Telegram ปัจจุบันเข้ากับเป้าหมายของเซสชัน +- `/unfocus` เอาการผูกปัจจุบันออก - `/agents` แสดงรายการเอเจนต์ที่ผูกกับเธรดสำหรับเซสชันปัจจุบัน -- `/kill ` ยกเลิก sub-agent หนึ่งตัวหรือทั้งหมดที่กำลังทำงาน -- `/steer ` ส่งคำสั่ง 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 ` ยกเลิก sub-agent ที่กำลังรันอยู่หนึ่งตัวหรือทั้งหมด +- `/steer ` ส่งคำสั่งกำกับไปยัง 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 ` รันคำสั่ง shell ของโฮสต์ ใช้ได้เฉพาะแบบข้อความ Alias: `! ` ต้องใช้ `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 ` รันคำสั่งเชลล์บนโฮสต์ ใช้ได้เฉพาะแบบข้อความเท่านั้น นามแฝง: `! ` ต้องมี `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 [duration]|disarm` เปิดใช้งานชั่วคราวสำหรับคำสั่ง node ของโทรศัพท์ที่มีความเสี่ยงสูง -- `/voice status|list [limit]|set ` จัดการคอนฟิกเสียงของ 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 [duration]|disarm` เปิดใช้งานคำสั่ง node โทรศัพท์ที่มีความเสี่ยงสูงชั่วคราว +- `/voice status|list [limit]|set ` จัดการการกำหนดค่าเสียง 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 [input]` ใช้งานได้เสมอในฐานะจุดเข้าแบบ generic -- Skills อาจปรากฏเป็นคำสั่งตรง เช่น `/prose` เมื่อ Skill/Plugin ลงทะเบียนไว้ -- การลงทะเบียนคำสั่ง Skills แบบ native ถูกควบคุมโดย `commands.nativeSkills` และ `channels..commands.nativeSkills` +- `/skill [input]` ใช้งานได้เสมอในฐานะจุดเข้าใช้งานแบบทั่วไป +- skills อาจปรากฏเป็นคำสั่งโดยตรง เช่น `/prose` เมื่อ skill/plugin ลงทะเบียนไว้ +- การลงทะเบียนคำสั่ง skill แบบเนทีฟควบคุมโดย `commands.nativeSkills` และ `channels..commands.nativeSkills` หมายเหตุ: - คำสั่งรองรับ `:` แบบไม่บังคับระหว่างคำสั่งกับอาร์กิวเมนต์ (เช่น `/think: high`, `/send: on`, `/help:`) -- `/new ` รองรับ alias ของโมเดล, `provider/model` หรือชื่อ provider (fuzzy match); หากไม่พบรายการที่ตรงกัน ข้อความนั้นจะถูกถือเป็นเนื้อหาข้อความ -- หากต้องการดูรายละเอียดการใช้งานแยกตาม provider แบบครบถ้วน ให้ใช้ `openclaw status --usage` -- `/allowlist add|remove` ต้องใช้ `commands.config=true` และจะเคารพ `configWrites` ของช่องทาง -- ในช่องทางหลายบัญชี `/allowlist --account ` ที่มุ่งเป้าไปยังคอนฟิก และ `/config set channels..accounts....` จะเคารพ `configWrites` ของบัญชีเป้าหมายด้วย -- `/usage` ควบคุม footer การใช้งานต่อคำตอบ; `/usage cost` จะพิมพ์สรุปต้นทุนในเครื่องจาก log เซสชันของ OpenClaw +- `/new ` รับนามแฝงของโมเดล, `provider/model` หรือชื่อผู้ให้บริการ (จับคู่แบบฟัซซี); หากไม่พบรายการที่ตรงกัน ข้อความนั้นจะถูกถือเป็นเนื้อหาข้อความ +- สำหรับรายละเอียดการใช้งานของผู้ให้บริการแบบเต็ม ให้ใช้ `openclaw status --usage` +- `/allowlist add|remove` ต้องใช้ `commands.config=true` และเป็นไปตาม `configWrites` ของช่องทาง +- ในช่องทางแบบหลายบัญชี `/allowlist --account ` ที่กำหนดเป้าหมายการตั้งค่า และ `/config set channels..accounts....` จะเป็นไปตาม `configWrites` ของบัญชีเป้าหมายด้วย +- `/usage` ควบคุมส่วนท้ายการใช้งานต่อการตอบกลับ; `/usage cost` จะพิมพ์สรุปค่าใช้จ่ายในเครื่องจากบันทึกเซสชัน OpenClaw - `/restart` เปิดใช้งานโดยค่าเริ่มต้น; ตั้ง `commands.restart: false` เพื่อปิดใช้งาน -- `/plugins install ` รองรับ plugin spec แบบเดียวกับ `openclaw plugins install`: local path/archive, npm package หรือ `clawhub:` -- `/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 ` รับสเปก plugin แบบเดียวกับ `openclaw plugins install`: พาธ/ไฟล์เก็บถาวรในเครื่อง, แพ็กเกจ npm หรือ `clawhub:` +- `/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 [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 [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::discord:slash:` - Slack: `agent::slack:slash:` (คำนำหน้าปรับได้ผ่าน `channels.slack.slashCommand.sessionPrefix`) - - Telegram: `telegram:slash:` (มุ่งเป้าไปยังเซสชันแชตผ่าน `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:` (กำหนดเป้าหมายไปยังเซสชันแชตผ่าน `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 ของไคลเอนต์ diff --git a/docs/th/tools/thinking.md b/docs/th/tools/thinking.md index ea2f59782..4e91ecf38 100644 --- a/docs/th/tools/thinking.md +++ b/docs/th/tools/thinking.md @@ -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 `, `/think:` หรือ `/thinking `. -- ระดับ (aliases): `off | minimal | low | medium | high | xhigh | adaptive | max` - - minimal → “think” - - low → “think hard” - - medium → “think harder” +- คำสั่งแบบอินไลน์ในเนื้อหาขาเข้าข้อความใดก็ได้: `/t `, `/think:` หรือ `/thinking `. +- ระดับ (ชื่อเรียกแทน): `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["/"].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["/"].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 ของตัวเอง โดยเติมคำนำหน้าด้วย ` : ` เมื่อมี (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 ของตัวเอง โดยมีคำนำหน้าเป็น ` : ` เมื่อมีข้อมูล (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 default จะมาจาก provider thinking profile ของโมเดลที่ใช้งานอยู่ในเซสชัน -- ตัวเลือกจะใช้ `thinkingOptions` ที่ส่งกลับมาจาก gateway session row Browser UI จะไม่เก็บรายการ provider regex ของตัวเอง; Plugins เป็นเจ้าของชุดระดับที่เฉพาะกับโมเดล -- `/think:` ยังคงใช้งานได้และอัปเดตระดับของเซสชันที่จัดเก็บไว้เดียวกัน ดังนั้น chat directives และตัวเลือกจึงสอดคล้องกัน +- ตัวเลือกระดับการคิดของเว็บแชตจะสะท้อนระดับที่จัดเก็บไว้ของเซสชันจาก session store/config ขาเข้าเมื่อหน้าโหลด +- การเลือกระดับอื่นจะเขียนการแทนที่ระดับเซสชันทันทีผ่าน `sessions.patch`; ไม่รอการส่งครั้งถัดไปและไม่ใช่การแทนที่ `thinkingOnce` แบบครั้งเดียว +- ตัวเลือกแรกจะเป็น `Default ()` เสมอ โดยค่าเริ่มต้นที่ตัดสินแล้วมาจากโปรไฟล์การคิดของผู้ให้บริการของโมเดลเซสชันที่ใช้งานอยู่ บวกกับตรรกะการย้อนกลับแบบเดียวกับที่ `/status` และ `session_status` ใช้ +- ตัวเลือกนี้ใช้ `thinkingOptions` ที่ส่งกลับโดยแถว session ของ Gateway UI บนเบราว์เซอร์จะไม่เก็บรายการ regex ของผู้ให้บริการไว้เอง ปลั๊กอินเป็นเจ้าของชุดระดับเฉพาะโมเดล +- `/think:` ยังใช้งานได้และจะอัปเดตระดับเซสชันที่จัดเก็บไว้ตัวเดียวกัน ดังนั้นคำสั่งในแชตและตัวเลือกจะซิงก์กัน -## 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/แชตแสดงผลโปรไฟล์เดียวกันกับที่ใช้ในการตรวจสอบความถูกต้องขณะรันไทม์