---
read_when:
    - คุณต้องการงานที่ตั้งเวลาไว้และการปลุกระบบ
    - คุณกำลังแก้ไขข้อบกพร่องในการทำงานและบันทึกของ Cron
summary: ข้อมูลอ้างอิง CLI สำหรับ `openclaw cron` (กำหนดเวลาและเรียกใช้งานเบื้องหลัง)
title: Cron
x-i18n:
    generated_at: "2026-07-22T03:31:03Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 0368a02283b0a3e107e6f41b71110d571e097461877ed6aea494614feaa092ca
    source_path: cli/cron.md
    workflow: 16
---

# `openclaw cron`

จัดการงาน cron สำหรับตัวกำหนดเวลา Gateway

<Tip>
เรียกใช้ `openclaw cron --help` เพื่อดูคำสั่งทั้งหมด โปรดดู [งาน Cron](/th/automation/cron-jobs) สำหรับคู่มือเชิงแนวคิด
</Tip>

<Note>
การเปลี่ยนแปลง cron ทั้งหมด (`add`/`create`, `update`/`edit`, `remove`, `run`) ต้องใช้ `operator.admin` การเรียกใช้เพย์โหลดคำสั่งจะดำเนินการโดยตรงในโพรเซส Gateway ไม่ใช่เป็นการเรียกเครื่องมือ `tools.exec` ของเอเจนต์ โดย `tools.exec.*` และการอนุมัติ exec ยังคงควบคุมเครื่องมือ exec ที่โมเดลมองเห็น
</Note>

## สร้างงานอย่างรวดเร็ว

`openclaw cron create` เป็นนามแฝงของ `openclaw cron add` สำหรับงานใหม่ ให้ระบุกำหนดเวลาก่อนและพรอมต์ตามหลัง:

```bash
openclaw cron create "0 7 * * *" \
  "สรุปอัปเดตในช่วงข้ามคืน" \
  --name "สรุปยามเช้า" \
  --agent ops
```

ใช้ `--webhook <url>` เมื่อต้องการให้งานส่งเพย์โหลดที่เสร็จสมบูรณ์ด้วย POST แทนการส่งไปยังเป้าหมายแชต:

```bash
openclaw cron create "0 18 * * 1-5" \
  "สรุปการปรับใช้ของวันนี้เป็น JSON" \
  --name "สรุปการปรับใช้" \
  --webhook "https://example.invalid/openclaw/cron"
```

ใช้ `--command` สำหรับงานแบบเชลล์ที่ให้ผลลัพธ์แน่นอน ซึ่งทำงานภายใน cron ของ OpenClaw โดยไม่เริ่มการเรียกใช้เอเจนต์/โมเดลแบบแยก:

```bash
openclaw cron create "*/15 * * * *" \
  --name "ตรวจสอบความลึกของคิว" \
  --command "scripts/check-queue.sh" \
  --command-cwd "/srv/app" \
  --announce \
  --channel telegram \
  --to "-1001234567890"
```

`--command <shell>` จัดเก็บ `argv: ["sh", "-lc", <shell>]` ใช้ `--command-argv '["node","scripts/report.mjs"]'` สำหรับการดำเนินการ argv อย่างตรงตัว งานคำสั่งจะบันทึก stdout/stderr บันทึกประวัติ cron ตามปกติ และกำหนดเส้นทางเอาต์พุตผ่านโหมดการส่ง `announce`, `webhook` หรือ `none` แบบเดียวกับงานแบบแยก คำสั่งที่พิมพ์เฉพาะ `NO_REPLY` จะถูกระงับ

## เซสชัน

`--session` ยอมรับ `main`, `isolated`, `current` หรือ `session:<id>`

<AccordionGroup>
  <Accordion title="คีย์เซสชัน">
    - `main` ผูกกับเซสชันหลักของเอเจนต์
    - `isolated` สร้างทรานสคริปต์และรหัสเซสชันใหม่สำหรับการเรียกใช้แต่ละครั้ง
    - `current` ผูกกับเซสชันที่ใช้งานอยู่ ณ เวลาที่สร้าง
    - `session:<id>` ตรึงกับคีย์เซสชันถาวรที่ระบุอย่างชัดเจน

  </Accordion>
  <Accordion title="ความหมายของเซสชันแบบแยก">
    การเรียกใช้แบบแยกจะรีเซ็ตบริบทการสนทนาแวดล้อม การกำหนดเส้นทางช่องและกลุ่ม นโยบายการส่ง/คิว การยกระดับ ต้นทาง และการผูกกับรันไทม์ ACP จะถูกรีเซ็ตสำหรับการเรียกใช้ใหม่ ค่ากำหนดที่ปลอดภัยและการแทนที่โมเดลหรือการตรวจสอบสิทธิ์ที่ผู้ใช้เลือกไว้อย่างชัดเจนสามารถส่งต่อระหว่างการเรียกใช้ได้
  </Accordion>
</AccordionGroup>

## การส่ง

`openclaw cron list` และ `openclaw cron show <job-id>` แสดงตัวอย่างเส้นทางการส่งที่แก้ไขแล้ว สำหรับ `channel: "last"` ตัวอย่างจะแสดงว่าเส้นทางถูกแก้ไขจากเซสชันหลักหรือเซสชันปัจจุบัน หรือจะปิดโดยปฏิเสธเมื่อเกิดความล้มเหลว

เป้าหมายที่มีคำนำหน้าผู้ให้บริการสามารถแยกแยะช่องประกาศที่ยังแก้ไขไม่ได้ ตัวอย่างเช่น `to: "telegram:123"` เลือก Telegram เมื่อไม่ได้ระบุ `delivery.channel` หรือเมื่อเป็น `last` เฉพาะคำนำหน้าที่ Plugin ซึ่งโหลดแล้วประกาศไว้เท่านั้นที่เป็นตัวเลือกผู้ให้บริการ หากระบุ `delivery.channel` อย่างชัดเจน คำนำหน้าต้องตรงกับช่องนั้น โดย `channel: "whatsapp"` ที่ใช้กับ `to: "telegram:123"` จะถูกปฏิเสธ คำนำหน้าบริการ เช่น `imessage:` และ `sms:` ยังคงเป็นไวยากรณ์เป้าหมายที่ช่องเป็นเจ้าของ

<Note>
งาน `cron add` แบบแยกใช้การส่งแบบ `--announce` เป็นค่าเริ่มต้น ใช้ `--no-deliver` เพื่อเก็บเอาต์พุตไว้ภายใน `--deliver` ยังคงเป็นนามแฝงที่เลิกใช้แล้วของ `--announce`
</Note>

### ความเป็นเจ้าของการส่ง

การส่งแชตของ cron แบบแยกเป็นความรับผิดชอบร่วมกันระหว่างเอเจนต์กับตัวเรียกใช้:

- เอเจนต์สามารถส่งโดยตรงโดยใช้เครื่องมือ `message` เมื่อมีเส้นทางแชต
- `announce` จะส่งข้อความตอบกลับสุดท้ายเป็นทางเลือกสำรองเฉพาะเมื่อเอเจนต์ไม่ได้ส่งโดยตรงไปยังเป้าหมายที่แก้ไขแล้ว
- `webhook` ส่งเพย์โหลดที่เสร็จสมบูรณ์ไปยัง URL
- `none` ปิดใช้งานการส่งสำรองโดยตัวเรียกใช้

ใช้ `cron add|create --webhook <url>` หรือ `cron edit <job-id> --webhook <url>` เพื่อตั้งค่าการส่ง Webhook ห้ามใช้ `--webhook` ร่วมกับแฟล็กการส่งแชต เช่น `--announce`, `--no-deliver`, `--channel`, `--to`, `--thread-id` หรือ `--account`

`cron edit <job-id>` สามารถยกเลิกการตั้งค่าฟิลด์การกำหนดเส้นทางการส่งแต่ละรายการด้วย `--clear-channel`, `--clear-to`, `--clear-thread-id` และ `--clear-account` (แต่ละรายการจะถูกปฏิเสธเมื่อใช้ร่วมกับแฟล็กตั้งค่าที่ตรงกัน) ต่างจาก `--no-deliver` ซึ่งเพียงปิดใช้งานการส่งสำรองโดยตัวเรียกใช้ ตัวเลือกเหล่านี้จะลบฟิลด์ที่จัดเก็บไว้ เพื่อให้งานกลับไปแก้ไขส่วนนั้นของเส้นทางจากค่าเริ่มต้นอีกครั้ง

`--announce` คือการส่งข้อความตอบกลับสุดท้ายเป็นทางเลือกสำรองโดยตัวเรียกใช้ `--no-deliver` ปิดใช้งานทางเลือกสำรองนั้น แต่ไม่ลบเครื่องมือ `message` ของเอเจนต์เมื่อมีเส้นทางแชต

การแจ้งเตือนที่สร้างจากแชตที่ใช้งานอยู่จะคงเป้าหมายการส่งแชตปัจจุบันไว้สำหรับการส่งประกาศสำรอง คีย์เซสชันภายในอาจเป็นตัวพิมพ์เล็ก ห้ามใช้คีย์เหล่านี้เป็นแหล่งข้อมูลจริงสำหรับรหัสผู้ให้บริการที่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ เช่น รหัสห้อง Matrix

### การส่งเมื่อเกิดความล้มเหลว

การแจ้งเตือนความล้มเหลวจะได้รับการแก้ไขตามลำดับนี้:

1. `delivery.failureDestination` ในงาน
2. `cron.failureDestination` ส่วนกลาง
3. เป้าหมายประกาศหลักของงาน (เมื่อสองรายการข้างต้นไม่สามารถแก้ไขเป็นปลายทางที่เป็นรูปธรรมได้)

<Note>
งานในเซสชันหลักอาจใช้ `delivery.failureDestination` ได้เฉพาะเมื่อโหมดการส่งหลักเป็น `webhook` งานแบบแยกยอมรับตัวเลือกนี้ในทุกโหมด
</Note>

การเรียกใช้ cron แบบแยกถือว่าความล้มเหลวของเอเจนต์ในระดับการเรียกใช้เป็นข้อผิดพลาดของงาน แม้จะไม่มีการสร้างเพย์โหลดตอบกลับ ดังนั้นความล้มเหลวของโมเดล/ผู้ให้บริการยังคงเพิ่มตัวนับข้อผิดพลาดและทริกเกอร์การแจ้งเตือนความล้มเหลว

งาน cron แบบคำสั่งจะไม่เริ่มเทิร์นของเอเจนต์แบบแยก รหัสออกเป็นศูนย์จะบันทึก `ok` ส่วนรหัสออกที่ไม่ใช่ศูนย์ สัญญาณ การหมดเวลา หรือการหมดเวลาเนื่องจากไม่มีเอาต์พุตจะบันทึก `error` และอาจทริกเกอร์เส้นทางการแจ้งเตือนความล้มเหลวแบบเดียวกัน

หากการเรียกใช้แบบแยกหมดเวลาก่อนคำขอโมเดลครั้งแรก `openclaw cron show` และ `openclaw cron runs` จะมีข้อผิดพลาดเฉพาะระยะ เช่น `setup timed out before runner start` หรือข้อความหยุดชะงักที่ระบุระยะการเริ่มต้นล่าสุดที่ทราบ (ตัวอย่างเช่น `context-engine`) สำหรับผู้ให้บริการที่รองรับด้วย CLI ตัวเฝ้าระวังก่อนโมเดลจะยังคงทำงานจนกว่าเทิร์น CLI ภายนอกจะเริ่มขึ้น ดังนั้นการหยุดชะงักของการค้นหาเซสชัน ฮุก การตรวจสอบสิทธิ์ พรอมต์ และการตั้งค่า CLI จะถูกรายงานเป็นความล้มเหลวของ cron ก่อนโมเดล

## การกำหนดเวลา

### งานแบบครั้งเดียว

`--at <datetime>` กำหนดเวลาการเรียกใช้แบบครั้งเดียว วันที่และเวลาที่ไม่มีออฟเซ็ตจะถือเป็น UTC เว้นแต่จะส่ง `--tz <iana>` ด้วย ซึ่งจะตีความเวลาตามนาฬิกาในเขตเวลาที่กำหนด

<Note>
งานแบบครั้งเดียวจะถูกลบหลังสำเร็จโดยค่าเริ่มต้น ใช้ `--keep-after-run` เพื่อเก็บรักษาไว้
</Note>

### งานที่เกิดซ้ำ

งานที่เกิดซ้ำใช้การหน่วงเวลาก่อนลองใหม่แบบทวีคูณหลังเกิดข้อผิดพลาดติดต่อกัน: 30s, 1m, 5m, 15m, 60m กำหนดเวลาจะกลับเป็นปกติหลังการเรียกใช้ครั้งถัดไปสำเร็จ

การเรียกใช้ที่ข้ามจะถูกติดตามแยกจากข้อผิดพลาดในการดำเนินการ และไม่ส่งผลต่อการหน่วงเวลาก่อนลองใหม่ แต่ `openclaw cron edit <job-id> --failure-alert-include-skipped` สามารถเลือกให้การแจ้งเตือนความล้มเหลวรวมการแจ้งเตือนการเรียกใช้ที่ข้ามซ้ำๆ ได้

สำหรับงานแบบแยกที่กำหนดเป้าหมายไปยังผู้ให้บริการโมเดลภายในที่กำหนดค่าไว้ (URL ฐานอยู่บนลูปแบ็ก เครือข่ายส่วนตัว หรือ `.local`) cron จะดำเนินการตรวจสอบผู้ให้บริการเบื้องต้นแบบเบาก่อนเริ่มเทิร์นของเอเจนต์: ผู้ให้บริการ `api: "ollama"` จะถูกตรวจสอบที่ `/api/tags` ส่วนผู้ให้บริการภายในอื่นที่เข้ากันได้กับ OpenAI (`api: "openai-completions"` เช่น vLLM, SGLang, LM Studio) จะถูกตรวจสอบที่ `/models` หากเข้าถึงปลายทางไม่ได้ การเรียกใช้จะถูกบันทึกเป็น `skipped` และลองใหม่ตามกำหนดเวลาในภายหลัง ผลการเข้าถึงจะถูกแคชแยกตามปลายทางเป็นเวลา 5 นาที เพื่อไม่ให้งานจำนวนมากที่ใช้เซิร์ฟเวอร์ภายในเดียวกันกระหน่ำตรวจสอบซ้ำ

งาน cron สถานะรันไทม์ที่รอดำเนินการ และประวัติการเรียกใช้จะอยู่ในฐานข้อมูลสถานะ SQLite ที่ใช้ร่วมกัน ไฟล์ `jobs.json`, `<name>-state.json` และ `runs/*.jsonl` แบบเก่าจะถูกนำเข้าเพียงครั้งเดียวและเปลี่ยนชื่อโดยเพิ่มส่วนต่อท้าย `.migrated` หลังนำเข้า ให้แก้ไขกำหนดเวลาด้วย `openclaw cron add|edit|remove` แทนการแก้ไขไฟล์ JSON

### การเรียกใช้ด้วยตนเอง

`openclaw cron run <job-id>` บังคับเรียกใช้โดยค่าเริ่มต้น และส่งคืนทันทีที่การเรียกใช้ด้วยตนเองถูกเพิ่มลงในคิว การตอบกลับที่สำเร็จจะมี `{ ok: true, enqueued: true, runId }` ใช้ `runId` ที่ส่งคืนมาเพื่อตรวจสอบผลลัพธ์ภายหลัง:

```bash
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --run-id <run-id>
```

เพิ่ม `--wait` เมื่อสคริปต์ควรบล็อกจนกว่าการเรียกใช้ในคิวรายการนั้นจะบันทึกสถานะสิ้นสุด:

```bash
openclaw cron run <job-id> --wait --wait-timeout 10m --poll-interval 2s
```

เมื่อใช้ `--wait` CLI จะยังคงเรียก `cron.run` ก่อน จากนั้นจึงสำรวจ `cron.runs` สำหรับ `runId` ที่ส่งคืนมา คำสั่งจะออกด้วย `0` เฉพาะเมื่อการเรียกใช้เสร็จสิ้นด้วยสถานะ `ok` และจะออกด้วยค่าที่ไม่ใช่ศูนย์เมื่อการเรียกใช้เสร็จสิ้นด้วย `error` หรือ `skipped` เมื่อการตอบกลับจาก Gateway ไม่มี `runId` หรือเมื่อ `--wait-timeout` หมดเวลา (ค่าเริ่มต้น `10m` โดยสำรวจทุก `2s` ตามค่าเริ่มต้น) `--poll-interval` ต้องมากกว่าศูนย์

<Note>
ใช้ `--due` เมื่อต้องการให้คำสั่งด้วยตนเองทำงานเฉพาะเมื่องานครบกำหนดในขณะนั้น หาก `--due --wait` ไม่ได้เพิ่มการเรียกใช้ลงในคิว คำสั่งจะส่งคืนการตอบกลับปกติกรณีไม่มีการเรียกใช้ แทนการสำรวจ
</Note>

## โมเดล

`cron add|edit --model <ref>` เลือกโมเดลที่อนุญาตสำหรับงาน `cron add|edit --fallbacks <list>` ตั้งค่าโมเดลสำรองแยกตามงาน ตัวอย่างเช่น `--fallbacks openrouter/gpt-4.1-mini,openai/gpt-5` ส่ง `--fallbacks ""` สำหรับการเรียกใช้แบบเคร่งครัดโดยไม่มีโมเดลสำรอง `cron edit <job-id> --clear-fallbacks` ลบการแทนที่โมเดลสำรองแยกตามงาน `cron edit <job-id> --clear-model` ลบการแทนที่โมเดลแยกตามงาน เพื่อให้งานเป็นไปตามลำดับความสำคัญการเลือกโมเดล cron ตามปกติ (ใช้การแทนที่เซสชัน cron ที่จัดเก็บไว้หากมี มิฉะนั้นใช้โมเดลของเอเจนต์/ค่าเริ่มต้น) และไม่สามารถใช้ร่วมกับ `--model` ได้ `cron add|edit --thinking <level>` ตั้งค่าการแทนที่การคิดแยกตามงาน ส่วน `cron edit <job-id> --clear-thinking` จะลบออกเพื่อให้งานเป็นไปตามลำดับความสำคัญการคิดของ cron ตามปกติ และไม่สามารถใช้ร่วมกับ `--thinking` ได้

<Warning>
หากโมเดลไม่ได้รับอนุญาตหรือไม่สามารถแก้ไขได้ cron จะทำให้การเรียกใช้ล้มเหลวด้วยข้อผิดพลาดการตรวจสอบที่ชัดเจน แทนที่จะย้อนกลับไปใช้การเลือกโมเดลของเอเจนต์หรือโมเดลเริ่มต้นของงาน
</Warning>

`--model` ของ cron คือ **โมเดลหลักของงาน** ไม่ใช่การแทนที่ `/model` ของเซสชันแชต ซึ่งหมายความว่า:

- โมเดลสำรองที่กำหนดค่าไว้ยังคงมีผลเมื่อโมเดลของงานที่เลือกทำงานล้มเหลว
- `fallbacks` ในเพย์โหลดแยกตามงานจะแทนที่รายการโมเดลสำรองที่กำหนดค่าไว้เมื่อมีการระบุ
- รายการโมเดลสำรองแยกตามงานที่ว่างเปล่า (`--fallbacks ""` หรือ `fallbacks: []` ในเพย์โหลด/API ของงาน) ทำให้ cron เรียกใช้แบบเคร่งครัด
- เมื่องานมี `--model` แต่ไม่ได้กำหนดค่ารายการโมเดลสำรอง OpenClaw จะส่งการแทนที่โมเดลสำรองว่างอย่างชัดเจน เพื่อไม่ให้โมเดลหลักของเอเจนต์ถูกเพิ่มเป็นเป้าหมายการลองใหม่โดยซ่อนอยู่
- การตรวจสอบเบื้องต้นของผู้ให้บริการภายในจะตรวจสอบโมเดลสำรองที่กำหนดค่าไว้ก่อนทำเครื่องหมายการเรียกใช้ cron เป็น `skipped`

`openclaw doctor` รายงานงานที่ตั้งค่า `payload.model` ไว้แล้ว รวมถึงจำนวนตามเนมสเปซผู้ให้บริการและความไม่ตรงกันกับ `agents.defaults.model` ใช้การตรวจสอบนี้เมื่อพฤติกรรมการตรวจสอบสิทธิ์ ผู้ให้บริการ หรือการเรียกเก็บเงินแตกต่างกันระหว่างแชตสดกับงานตามกำหนดเวลา

### ลำดับความสำคัญของโมเดล cron แบบแยก

cron แบบแยกจะแก้ไขโมเดลที่ใช้งานอยู่ตามลำดับนี้:

1. การแทนที่จากฮุก Gmail
2. `--model` แยกตามงาน
3. การแทนที่โมเดลของเซสชัน cron ที่จัดเก็บไว้ (เมื่อผู้ใช้เลือกไว้)
4. การเลือกโมเดลของเอเจนต์หรือโมเดลเริ่มต้น

### โหมดรวดเร็ว

โหมดเร็วของ Cron แบบแยกทำงานจะเป็นไปตามการเลือกโมเดลใช้งานจริงที่แก้ไขแล้ว การกำหนดค่าโมเดล `params.fastMode` จะมีผลโดยค่าเริ่มต้น แต่การแทนที่ `fastMode` ของเซสชันที่จัดเก็บไว้ยังคงมีลำดับความสำคัญเหนือกว่าการกำหนดค่า เมื่อโหมดที่แก้ไขแล้วเป็น `auto` จุดตัดจะใช้ค่า `params.fastAutoOnSeconds` ของโมเดลที่เลือก โดยมีค่าเริ่มต้นเป็น 60 วินาที

### การลองใหม่เมื่อสลับโมเดลใช้งานจริง

หากการทำงานแบบแยกส่งข้อผิดพลาด `LiveSessionModelSwitchError` Cron จะบันทึกผู้ให้บริการและโมเดลที่สลับแล้ว (รวมถึงการแทนที่โปรไฟล์การตรวจสอบสิทธิ์ที่สลับแล้ว หากมี) สำหรับการทำงานที่กำลังดำเนินอยู่ก่อนลองใหม่ ลูปการลองใหม่ภายนอกจำกัดการลองสลับไว้สองครั้งหลังจากความพยายามครั้งแรก จากนั้นจะยกเลิกแทนที่จะวนซ้ำตลอดไป

## เอาต์พุตการทำงานและการปฏิเสธ

### การระงับการตอบรับที่ล้าสมัย

รอบการทำงานของ Cron แบบแยกจะระงับการตอบกลับที่เป็นเพียงการรับทราบซึ่งล้าสมัย หากผลลัพธ์แรกเป็นเพียงการอัปเดตสถานะชั่วคราว และไม่มีการทำงานของ subagent สืบทอดใดรับผิดชอบคำตอบสุดท้าย Cron จะส่งพรอมต์อีกครั้งหนึ่งเพื่อขอผลลัพธ์จริงก่อนส่งมอบ

### การระงับโทเค็นเงียบ

หากการทำงานของ Cron แบบแยกส่งคืนเฉพาะโทเค็นเงียบ (`NO_REPLY` หรือ `no_reply`) Cron จะระงับทั้งการส่งออกโดยตรงและเส้นทางสรุปสำรองที่เข้าคิว ดังนั้นจึงไม่มีสิ่งใดถูกโพสต์กลับไปยังแชต

### การปฏิเสธแบบมีโครงสร้าง

การทำงานของ Cron แบบแยกใช้ข้อมูลเมตาการปฏิเสธการดำเนินการแบบมีโครงสร้างจากการทำงานที่ฝังอยู่ (ข้อผิดพลาดร้ายแรงของเครื่องมือดำเนินการที่มีรหัส `SYSTEM_RUN_DENIED` หรือ `INVALID_REQUEST`) เป็นสัญญาณการปฏิเสธที่เชื่อถือได้ นอกจากนี้ยังรองรับ Wrapper ของโฮสต์ Node `UNAVAILABLE` ที่ครอบข้อผิดพลาดแบบมีโครงสร้างซ้อนซึ่งมีรหัสใดรหัสหนึ่งดังกล่าว

Cron จะไม่จัดประเภทข้อความผลลัพธ์สุดท้ายหรือวลีปฏิเสธที่ดูเหมือนต้องขออนุมัติว่าเป็นการปฏิเสธ เว้นแต่การทำงานที่ฝังอยู่จะให้ข้อมูลเมตาการปฏิเสธแบบมีโครงสร้างด้วย ดังนั้นข้อความทั่วไปของผู้ช่วยจะไม่ถูกถือว่าเป็นคำสั่งที่ถูกบล็อก

`cron list` และประวัติการทำงานจะแสดงเหตุผลการปฏิเสธแทนการรายงานคำสั่งที่ถูกบล็อกเป็น `ok`

## การเก็บรักษา

ลักษณะการเก็บรักษา:

- `cron.sessionRetention` (ค่าเริ่มต้น `24h` หรือ `false` เพื่อปิดใช้งาน) จะล้างเซสชันการทำงานแบบแยกที่เสร็จสมบูรณ์แล้ว
- ประวัติการทำงานจะเก็บแถวสถานะสิ้นสุดล่าสุด 2000 แถวต่อหนึ่งงาน Cron แถวที่สูญหายยังคงใช้ช่วงเวลาล้างงานที่สูญหายมาตรฐาน 24 ชั่วโมง

## การย้ายงานรุ่นเก่า

<Note>
หากมีงาน Cron จากก่อนรูปแบบการจัดส่งและการจัดเก็บปัจจุบัน ให้เรียกใช้ `openclaw doctor --fix` Doctor จะปรับฟิลด์ Cron รุ่นเก่า (`jobId`, `schedule.cron`, ฟิลด์การจัดส่งระดับบนสุด รวมถึง `threadId` รุ่นเก่า และนามแฝงการจัดส่ง `provider` ในเพย์โหลด) ให้เป็นรูปแบบมาตรฐาน และย้ายงาน Webhook สำรอง `notify: true` จากค่า `cron.webhook` แบบดิบที่เลิกใช้แล้วไปเป็นการจัดส่ง Webhook ที่ระบุอย่างชัดเจน ก่อนนำคีย์การกำหนดค่านั้นออก งานที่ประกาศไปยังแชตอยู่แล้วจะคงการจัดส่งดังกล่าวไว้และได้รับปลายทาง Webhook เมื่อเสร็จสมบูรณ์ หากไม่มี Webhook รุ่นเก่า เครื่องหมายระดับบนสุด `notify` ที่ไม่มีผลจะถูกนำออกจากงานที่ไม่มีเป้าหมายสำหรับการย้าย (การจัดส่งเดิมจะยังคงเดิมโดยไม่มีการเปลี่ยนแปลง) ดังนั้น `doctor --fix` จะไม่แจ้งเตือนเกี่ยวกับงานเหล่านั้นซ้ำอีก
</Note>

## การแก้ไขที่ใช้บ่อย

อัปเดตการตั้งค่าการจัดส่งโดยไม่เปลี่ยนข้อความ:

```bash
openclaw cron edit <job-id> --announce --channel telegram --to "123456789"
```

ปิดใช้งานการจัดส่งสำหรับงานแบบแยก:

```bash
openclaw cron edit <job-id> --no-deliver
```

เปิดใช้บริบทเริ่มต้นแบบเบาสำหรับงานแบบแยก:

```bash
openclaw cron edit <job-id> --light-context
```

ประกาศไปยังช่องทางที่ระบุ:

```bash
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
```

ประกาศไปยังหัวข้อฟอรัม Telegram:

```bash
openclaw cron edit <job-id> --announce --channel telegram --to "-1001234567890" --thread-id 42
```

สร้างงานแบบแยกพร้อมบริบทเริ่มต้นแบบเบา:

```bash
openclaw cron create "0 7 * * *" \
  "สรุปการอัปเดตในช่วงข้ามคืน" \
  --name "สรุปยามเช้าแบบเบา" \
  --session isolated \
  --light-context \
  --no-deliver
```

`--light-context` ใช้กับงานรอบการทำงานของเอเจนต์แบบแยกเท่านั้น สำหรับการทำงานของ Cron โหมดเบาจะปล่อยบริบทเริ่มต้นให้ว่างแทนการแทรกชุดข้อมูลเริ่มต้นของพื้นที่ทำงานทั้งหมด

สร้างงานคำสั่งที่มี argv, cwd, env, stdin และขีดจำกัดเอาต์พุตที่แน่นอน:

```bash
openclaw cron create "*/30 * * * *" \
  --name "ส่งออกตำแหน่ง" \
  --command-argv '["node","scripts/export-position.mjs"]' \
  --command-cwd "/srv/app" \
  --command-env "NODE_ENV=production" \
  --command-input '{"mode":"summary"}' \
  --timeout-seconds 120 \
  --no-output-timeout-seconds 30 \
  --output-max-bytes 65536 \
  --webhook "https://example.invalid/openclaw/cron"
```

## คำสั่งผู้ดูแลระบบที่ใช้บ่อย

การเรียกใช้ด้วยตนเองและการตรวจสอบ:

```bash
openclaw cron list
openclaw cron list --agent ops
openclaw cron get <job-id>
openclaw cron show <job-id>
openclaw cron run <job-id>
openclaw cron run <job-id> --due
openclaw cron run <job-id> --wait --wait-timeout 10m
openclaw cron run <job-id> --wait --wait-timeout 10m --poll-interval 2s
openclaw cron runs --id <job-id> --limit 50
openclaw cron runs --id <job-id> --run-id <run-id>
```

`openclaw cron list` จะแสดงงานที่เปิดใช้งานโดยค่าเริ่มต้น ส่ง `--all` เพื่อรวมงานที่ปิดใช้งาน หรือ `--agent <id>` เพื่อแสดงเฉพาะงานที่มี ID เอเจนต์มาตรฐานที่มีผลตรงกัน งานที่ไม่มี ID เอเจนต์จัดเก็บไว้จะถือว่าใช้เอเจนต์เริ่มต้นที่กำหนดค่าไว้

`openclaw cron get <job-id>` จะส่งคืน JSON ของงานที่จัดเก็บไว้โดยตรง ใช้ `cron show <job-id>` เมื่อต้องการมุมมองที่มนุษย์อ่านได้พร้อมตัวอย่างเส้นทางการจัดส่ง

`cron list --json` และ `cron show <job-id> --json` จะมีฟิลด์ระดับบนสุด `status` ในแต่ละงาน ซึ่งคำนวณจาก `enabled`, `state.runningAtMs` และ `state.lastRunStatus` ค่าได้แก่ `disabled`, `running`, `ok`, `error`, `skipped` หรือ `idle` สถานะ JSON ยังคงเป็นรูปแบบมาตรฐานและไม่มีการตกแต่ง เพื่อให้เครื่องมือภายนอกอ่านสถานะงานได้โดยไม่ต้องคำนวณใหม่ ส่วนเอาต์พุตสำหรับมนุษย์อาจตกแต่งสถานะ `error` ที่เกิดซ้ำด้วยจำนวนความล้มเหลว

รายการ `cron runs` มีข้อมูลวินิจฉัยการจัดส่ง ซึ่งประกอบด้วยเป้าหมาย Cron ที่ตั้งใจไว้ เป้าหมายที่แก้ไขแล้ว การส่งด้วยเครื่องมือข้อความ การใช้วิธีสำรอง และสถานะการจัดส่ง

การกำหนดเป้าหมายเอเจนต์และเซสชันใหม่:

```bash
openclaw cron edit <job-id> --agent ops
openclaw cron edit <job-id> --clear-agent
openclaw cron edit <job-id> --session current
openclaw cron edit <job-id> --session "session:daily-brief"
```

`openclaw cron add` จะแจ้งเตือนเมื่อไม่ได้ระบุ `--agent` ในงานรอบการทำงานของเอเจนต์ และจะใช้เอเจนต์เริ่มต้น (`main`) แทน ส่ง `--agent <id>` ขณะสร้างเพื่อปักหมุดเอเจนต์ที่ระบุ

การปรับแต่งการจัดส่ง:

```bash
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
openclaw cron edit <job-id> --webhook "https://example.invalid/openclaw/cron"
openclaw cron edit <job-id> --best-effort-deliver
openclaw cron edit <job-id> --no-best-effort-deliver
openclaw cron edit <job-id> --no-deliver
```

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

- [เอกสารอ้างอิง CLI](/th/cli)
- [งานตามกำหนดเวลา](/th/automation/cron-jobs)