# 🗜️ Prompt Compression Guide — OmniRoute (ไทย)

🌐 **Languages:** 🇺🇸 [English](../../../../compression/COMPRESSION_GUIDE.md) · 🇪🇹 [am](../../../am/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇦 [ar](../../../ar/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇿 [az](../../../az/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇬 [bg](../../../bg/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇩 [bn](../../../bn/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇦 [bs](../../../bs/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇿 [cs](../../../cs/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇰 [da](../../../da/docs/compression/COMPRESSION_GUIDE.md) · 🇩🇪 [de](../../../de/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇷 [el](../../../el/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇸 [es](../../../es/docs/compression/COMPRESSION_GUIDE.md) · 🇪🇪 [et](../../../et/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇷 [fa](../../../fa/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇮 [fi](../../../fi/docs/compression/COMPRESSION_GUIDE.md) · 🇫🇷 [fr](../../../fr/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇪 [ga](../../../ga/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [gu](../../../gu/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ha](../../../ha/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇱 [he](../../../he/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [hi](../../../hi/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇷 [hr](../../../hr/docs/compression/COMPRESSION_GUIDE.md) · 🇭🇺 [hu](../../../hu/docs/compression/COMPRESSION_GUIDE.md) · 🇦🇲 [hy](../../../hy/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇩 [id](../../../id/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [ig](../../../ig/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇹 [it](../../../it/docs/compression/COMPRESSION_GUIDE.md) · 🇯🇵 [ja](../../../ja/docs/compression/COMPRESSION_GUIDE.md) · 🇬🇪 [ka](../../../ka/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇭 [km](../../../km/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [kn](../../../kn/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇷 [ko](../../../ko/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇹 [lt](../../../lt/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇻 [lv](../../../lv/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ml](../../../ml/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [mr](../../../mr/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇾 [ms](../../../ms/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇹 [mt](../../../mt/docs/compression/COMPRESSION_GUIDE.md) · 🇲🇲 [my](../../../my/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇵 [ne](../../../ne/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇱 [nl](../../../nl/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇴 [no](../../../no/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [or](../../../or/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [pa](../../../pa/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇭 [phi](../../../phi/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇱 [pl](../../../pl/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇹 [pt](../../../pt/docs/compression/COMPRESSION_GUIDE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇴 [ro](../../../ro/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇺 [ru](../../../ru/docs/compression/COMPRESSION_GUIDE.md) · 🇱🇰 [si](../../../si/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇰 [sk](../../../sk/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇮 [sl](../../../sl/docs/compression/COMPRESSION_GUIDE.md) · 🇷🇸 [sr](../../../sr/docs/compression/COMPRESSION_GUIDE.md) · 🇸🇪 [sv](../../../sv/docs/compression/COMPRESSION_GUIDE.md) · 🇰🇪 [sw](../../../sw/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [ta](../../../ta/docs/compression/COMPRESSION_GUIDE.md) · 🇮🇳 [te](../../../te/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇷 [tr](../../../tr/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/compression/COMPRESSION_GUIDE.md) · 🇵🇰 [ur](../../../ur/docs/compression/COMPRESSION_GUIDE.md) · 🇺🇿 [uz](../../../uz/docs/compression/COMPRESSION_GUIDE.md) · 🇻🇳 [vi](../../../vi/docs/compression/COMPRESSION_GUIDE.md) · 🇳🇬 [yo](../../../yo/docs/compression/COMPRESSION_GUIDE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/compression/COMPRESSION_GUIDE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/compression/COMPRESSION_GUIDE.md)

---

> ประหยัดโทเค็นบริบทที่เข้าเกณฑ์ 15-95% โดยอัตโนมัติ สำหรับภาพรวมโดยย่อ โปรดดู[ส่วนการบีบอัดใน README](../README.md#%EF%B8%8F-prompt-compression--save-15-95-eligible-tokens-automatically)

## ภาพรวม

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

```
คำขอจากไคลเอนต์
  → ตัวเลือกกลยุทธ์การบีบอัด
    → มีการตั้งค่าทับด้วยคอมโบหรือไม่? → ใช้การตั้งค่าคอมโบ
    → ถึงเกณฑ์ทริกเกอร์อัตโนมัติหรือไม่? → ใช้โหมดอัตโนมัติ
    → มีโหมดเริ่มต้นหรือไม่? → ใช้การตั้งค่าส่วนกลาง
    → ปิดอยู่หรือไม่? → ข้ามการบีบอัด
  → โหมดการบีบอัดที่เลือก
    → Off: ไม่มีการบีบอัด
    → Lite: ล้างช่องว่าง/การจัดรูปแบบอย่างปลอดภัย (~15%)
    → Standard: ลบคำฟุ่มเฟือยแบบภาษามนุษย์ถ้ำ (~30%)
    → Aggressive: ลดทอนประวัติเก่า + สรุปเนื้อหา (~50%)
    → Ultra: ตัดทอนด้วยฮิวริสติก + ลดขนาดบล็อกโค้ด (~75%)
    → RTK: กรองเอาต์พุตจากเทอร์มินัล/เครื่องมือโดยพิจารณาคำสั่ง (ช่วงต้นทาง 60-90%)
    → Stacked: ไปป์ไลน์หลายเอนจินตามลำดับ โดยทั่วไปใช้ RTK แล้วตามด้วย Caveman (ช่วงที่เข้าเกณฑ์ 78-95%)
  → คำขอที่บีบอัดแล้ว → ผู้ให้บริการ
```

---

## โหมดการบีบอัด

### Off

ไม่มีการบีบอัด ข้อความทั้งหมดจะถูกส่งผ่านโดยไม่มีการเปลี่ยนแปลง

### โหมด Lite (ประหยัด ~15%, เวลาแฝง <1ms)

โหมดที่ปลอดภัยที่สุด — ไม่มีการเปลี่ยนแปลงความหมาย มีเพียงการล้างการจัดรูปแบบ:

| เทคนิค                   | คำอธิบาย                                          |
| ------------------------ | ------------------------------------------------- |
| `collapseWhitespace`     | รวมบรรทัดว่างที่ต่อเนื่องกันและช่องว่างท้ายบรรทัด |
| `dedupSystemPrompt`      | ลบข้อความระบบที่ซ้ำกัน                            |
| `compressToolResults`    | บีบอัดเอาต์พุตจากเครื่องมือ/ฟังก์ชันที่เยิ่นเย้อ  |
| `removeRedundantContent` | ตัดคำสั่งที่ซ้ำกันออก                             |
| `replaceImageUrls`       | ย่อ URI ข้อมูลรูปภาพแบบ base64                    |

**เหมาะที่สุดสำหรับ:** การใช้งานแบบเปิดไว้ตลอดและเวิร์กโฟลว์ที่ให้ความสำคัญกับความปลอดภัย

### โหมด Standard (ประหยัด ~30%)

ได้รับแรงบันดาลใจจาก [Caveman](https://github.com/JuliusBrussee/caveman) — ลบคำฟุ่มเฟือยและสำนวนที่เยิ่นเย้อโดยยังคงรักษาความหมาย:

- ลบคำฟุ่มเฟือย ("โปรด", "ฉันคิดว่า", "โดยพื้นฐานแล้ว", "จริง ๆ แล้ว")
- ย่อวลีที่เยิ่นเย้อ ("เพื่อที่จะ" → "เพื่อ", "อันเป็นผลมาจาก" → "เพราะ")
- ตัดถ้อยคำเกรงใจที่ไม่แน่นอน ("คุณจะรังเกียจไหม...", "หากเป็นไปได้ คุณช่วย...")
- กฎ regex มากกว่า 30 รายการที่ปรับแต่งมาสำหรับพรอมต์การเขียนโค้ด

**เหมาะที่สุดสำหรับ:** เวิร์กโฟลว์การเขียนโค้ดประจำวันและทีมที่คำนึงถึงต้นทุน

### โหมด Aggressive (ประหยัด ~50%)

การจัดการประวัติอย่างชาญฉลาดสำหรับเซสชันที่ยาวนาน:

- **การลดทอนข้อความเก่า** — ข้อความที่เก่ากว่าจะถูกบีบอัดมากขึ้นเรื่อย ๆ
- **การบีบอัดผลลัพธ์จากเครื่องมือ** — เอาต์พุตขนาดยาวจากเครื่องมือจะถูกตัดหรือย่อออก (เก็บบรรทัดแรก/สุดท้าย
  กรองบรรทัดที่ตรงกัน และย่อคีย์ JSON)
- **ตัวป้องกันความสมบูรณ์ของโครงสร้าง** — ทำให้มั่นใจว่าคู่ `tool_use` + `tool_result` ยังคงสอดคล้องกัน
- **การรับรู้ขนาดหน้าต่างบริบท** — เคารพขีดจำกัดโทเค็นของแต่ละโมเดล

**เหมาะที่สุดสำหรับ:** เซสชันการดีบักที่ยาวนานและโค้ดเบสขนาดใหญ่

### โหมด Ultra (ประหยัด ~75%)

การบีบอัดสูงสุดสำหรับสถานการณ์ที่มีข้อจำกัดด้านโทเค็นอย่างมาก:

- **การตัดทอนด้วยฮิวริสติก** — ตัดโทเค็นจากข้อความร้อยแก้วโดยอิงตามคะแนน
- **การรักษาโครงสร้าง** — บล็อกโค้ดแบบมีรั้ว โค้ดอินไลน์ URL และตัวระบุจะถูกแทนที่ชั่วคราว
  และนำกลับมาประกอบใหม่แบบตรงตามต้นฉบับโดยไม่ถูกตัดทอน
- **ระดับ SLM ที่เลือกใช้ได้** — โมเดลภายในเครื่องขนาดเล็กสามารถปรับปรุงการตัดทอนได้เมื่อกำหนดค่าไว้
- ทำงานเป็นอิสระจากโหมด Aggressive: โหมดนี้จะไม่ลดทอนข้อความเก่า บีบอัดผลลัพธ์จากเครื่องมือ
  หรือเรียกใช้ตัวสรุปสำรอง (เฉพาะความล้มเหลวในระดับ SLM เท่านั้นที่สามารถส่งผ่านขั้นตอนสำรองไปยัง
  aggressive ได้)

**เหมาะที่สุดสำหรับ:** เมื่อคุณใช้บริบทถึงขีดจำกัดซ้ำ ๆ

### โหมด RTK (ช่วงต้นทาง 60-90%)

โหมด RTK ได้รับการปรับให้เหมาะกับเอาต์พุตจากเครื่องมือที่เยิ่นเย้อซึ่งปรากฏในเซสชันของเอเจนต์เขียนโค้ด:

- ตรวจจับคลาสคำสั่ง/เอาต์พุต เช่น `git status`, `git diff`, `git log`, ตัวรันการทดสอบ,
  บิลด์ TypeScript/Vite/Webpack, ESLint/Biome/Prettier, การตรวจสอบ/ติดตั้ง npm, บันทึก Docker, เอาต์พุต
  โครงสร้างพื้นฐาน และเอาต์พุตเชลล์ทั่วไป
- ใช้ชุดตัวกรอง JSON จาก `open-sse/services/compression/engines/rtk/filters/`
- นำเข้าตัวกรองสคีมา RTK TOML v1 จากไฟล์ `filters.toml` ของโปรเจกต์หรือส่วนกลาง พร้อมการตรวจสอบ
  การทดสอบแบบอินไลน์และการควบคุมความน่าเชื่อถือสำหรับไฟล์ของโปรเจกต์
- มาพร้อมตัวกรองในตัว 55 รายการพร้อมตัวอย่างการตรวจสอบแบบอินไลน์
- ลบลำดับควบคุม ANSI แถบความคืบหน้า บรรทัดที่ซ้ำกัน และสัญญาณรบกวนที่ไม่สามารถนำไปดำเนินการได้
- เก็บรักษาความล้มเหลว ข้อผิดพลาด คำเตือน ไฟล์ที่เปลี่ยนแปลง สรุป และส่วนท้ายของเอาต์พุตขนาดยาว
- รองรับตัวกรองของโปรเจกต์ที่ควบคุมด้วยความน่าเชื่อถือ ตัวกรองส่วนกลาง และการกู้คืนเอาต์พุตดิบที่ผ่านการปกปิดข้อมูลซึ่งเลือกใช้ได้

**เหมาะที่สุดสำหรับ:** เซสชันของเอเจนต์ที่มีทรานสคริปต์จากเชลล์ บิลด์ การทดสอบ git, grep และเอาต์พุตไฟล์

### โหมด Stacked (ช่วงที่เข้าเกณฑ์ 78-95%)

โหมด Stacked เรียกใช้เอนจินการบีบอัดหลายตัวตามลำดับที่กำหนดแน่นอน ไปป์ไลน์เริ่มต้นคือ:

```txt
RTK -> Caveman
```

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

**เหมาะที่สุดสำหรับ:** บริบทแบบผสมที่มีบันทึกจากเครื่องมือขนาดใหญ่ร่วมกับคำสั่งจากผู้ใช้หรือสรุปจากผู้ช่วย

---

## คณิตศาสตร์การประหยัดจากต้นน้ำ

OmniRoute บันทึกข้อมูลการประหยัดจากการบีบอัดโดยอ้างอิงจากสองแหล่ง ได้แก่ เกณฑ์มาตรฐานของโปรเจกต์ต้นน้ำและ
การประกอบเอนจินของ OmniRoute เอง

| แหล่งที่มา | ตัวเลขจาก README ต้นน้ำที่ใช้ในที่นี้                                                                                 |
| ---------- | --------------------------------------------------------------------------------------------------------------------- |
| Caveman    | โทเค็นเอาต์พุตลดลง `~75%`, ประหยัดเอาต์พุตเฉลี่ยจากเกณฑ์มาตรฐาน `65%`, ช่วง `22-87%` และเครื่องมือบีบอัดอินพุต `~46%` |
| RTK        | ประหยัดเอาต์พุตคำสั่ง `60-90%`; เซสชันตัวอย่าง `~118,000 -> ~23,900` โทเค็น หรือประหยัด `79.7%` (`~80%`)              |

สำหรับเพย์โหลดของเครื่องมือ/บริบทที่ทับซ้อนกัน คอมโบเริ่มต้นของ OmniRoute จะซ้อนเอนจินดังนี้:

```txt
RTK -> Caveman
```

การประหยัดรวมคำนวณแบบคูณ ไม่ใช่แบบบวก:

```txt
รวม    = 1 - (1 - การประหยัดของ RTK) * (1 - การประหยัดอินพุตของ Caveman)
ค่าเฉลี่ย = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
ช่วง    = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%
```

ตัวเลข `78-95%` นี้ใช้ได้เมื่อทั้ง RTK และ Caveman สามารถลดเพย์โหลดอินพุต/บริบทเดียวกันได้
โหมดเอาต์พุตการตอบกลับของ Caveman เป็นส่วนแยกต่างหาก: เมื่อเปิดใช้งาน ให้ใช้ค่าการประหยัดเอาต์พุตของ Caveman เอง (`65%`
โดยเฉลี่ย, ตัวเลขพาดหัว `~75%`, ช่วง `22-87%`) การประหยัดค่าใช้จ่ายทั้งหมดขึ้นอยู่กับสัดส่วนพรอมต์/เอาต์พุตของคุณ

### ความหมายที่แท้จริงของ "เข้าเกณฑ์"

ช่วงพาดหัว 15-95% เป็นตัวเลขจริง แต่ใช้ได้เฉพาะกับเนื้อหาที่ **ซ้ำซ้อนหรือเยิ่นเย้อ** เท่านั้น — เช่น บรรทัดข้อผิดพลาดที่เกิดซ้ำ
บันทึกการบิลด์ที่แสดงคำเตือนเดิมซ้ำจำนวนมาก หรือดัมป์จาก `grep`/การอ่านไฟล์ที่มีขนาดใหญ่เกินไป ตัวเลขนี้
**ไม่ได้** หมายความว่าทุกคำขอจะประหยัดได้มากขนาดนั้น

ผ่านการตรวจสอบเชิงประจักษ์แล้ว (`tests/unit/compression/stacked-compression-tool-result-savings.test.ts`): การรันแบบ
`stacked` (RTK + Caveman) กับบล็อก `tool_result` รูปแบบ Anthropic ที่มีบรรทัดข้อผิดพลาดเหมือนกัน 300 บรรทัด
ให้ผลลัพธ์เป็น **ประหยัดโทเค็น 95.93% / ประหยัดอักขระ 96.26%** — อยู่ในช่วงที่ประกาศไว้อย่างชัดเจน
แต่เมื่อใช้ไปป์ไลน์เดียวกันกับเอาต์พุตเครื่องมือปกติที่ไม่ซ้ำซ้อน (รายการผลลัพธ์ `grep` ที่สะอาด
การอ่านไฟล์สั้น ๆ หรือข้อความสนทนาทั่วไป) ระบบจะให้ผลเป็น **การประหยัดเกือบศูนย์** อย่างถูกต้อง เนื่องจาก
ไม่มีสิ่งซ้ำซ้อนให้ลบ และ `validateCompression()` (`validation.ts`) จะไม่ยอมส่ง
ข้อความที่เขียนใหม่ซึ่งทำให้บล็อกโค้ด, URL, หัวข้อ, เวอร์ชัน หรือตัวระบุค่าคงที่แบบตัวพิมพ์ใหญ่ทั้งหมดสูญหายหรือเปลี่ยนแปลงไป

นี่เป็นพฤติกรรมที่คาดไว้และปลอดภัย ไม่ใช่ข้อบกพร่อง: เซสชันการเขียนโค้ดที่ส่วนใหญ่อ่าน/ค้นหาไฟล์ที่สะอาดด้วย `grep` จะ
ประหยัดโดยรวมได้ไม่มากนัก แม้เปิดใช้งานการบีบอัดอย่างเต็มที่แล้ว ขณะที่เซสชันที่พบลูปล้มเหลว
หรือลินเตอร์ที่สร้างข้อความจำนวนมากจะประหยัดได้เต็มช่วง 78-95% สำหรับทราฟฟิกส่วนนั้น อย่าใช้เปอร์เซ็นต์
การประหยัดรวมที่ต่ำจากเซสชันเดียวเป็นหลักฐานว่าการบีบอัดถูกกำหนดค่าผิด — ให้ตรวจสอบก่อนว่า
เอาต์พุตเครื่องมือต้นทางมีความซ้ำซ้อนจริงหรือไม่

---

## การแสดงภาพการประหยัดโทเค็น

```
ไม่มีการบีบอัด:       ส่ง 47K โทเค็นไปยัง LLM
ใช้ Lite:              ส่ง 40K โทเค็น          (ประหยัด 15% — ปลอดภัยและเปิดใช้งานตลอด)
ใช้ Standard:          ส่ง 33K โทเค็น          (ประหยัด 30% — กฎ caveman-speak)
ใช้ Aggressive:        ส่ง 24K โทเค็น          (ประหยัด 50% — การลดความสำคัญตามอายุ + การสรุป)
ใช้ Ultra:             ส่ง 12K โทเค็น          (ประหยัด 75% — การตัดทอนตามฮิวริสติก)
ใช้ RTK:               ส่ง 19K-5K โทเค็น       (ประหยัด 60-90% สำหรับเอาต์พุตคำสั่ง/เครื่องมือ)
ใช้ Stacked:           ส่ง 10K-2.5K โทเค็น     (ช่วง 78-95% ที่เข้าเกณฑ์สำหรับ RTK+Caveman)
```

---

## การกำหนดค่า

### แดชบอร์ด

ไปที่ `Dashboard → Context & Cache`:

- **Caveman** — การเลือกโหมด ชุดภาษา การแสดงตัวอย่าง และค่าเริ่มต้นส่วนกลาง
- **RTK** — การแสดงตัวอย่างตัวกรองคำสั่ง การตั้งค่าความปลอดภัยของ RTK และแค็ตตาล็อกตัวกรอง
- **Compression Combos** — ไปป์ไลน์เอนจินที่มีชื่อซึ่งกำหนดให้กับคอมโบการกำหนดเส้นทาง
- **Auto-Trigger Threshold** — เริ่มใช้การบีบอัดโดยอัตโนมัติเมื่อจำนวนโทเค็นเกินเกณฑ์

### การแทนที่รายคอมโบ

ใน `Dashboard → Context & Cache → Compression Combos` ให้กำหนดคอมโบการบีบอัดแก่คอมโบการกำหนด
เส้นทาง:

```txt
คอมโบ: "free-tier-fallback"
  คอมโบการบีบอัด: "coding-agent-stack"
  ไปป์ไลน์: RTK -> Caveman
  เป้าหมาย:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview
```

วิธีนี้ช่วยให้คุณใช้การบีบอัดแบบซ้อนกับผู้ให้บริการแบบฟรี/สำหรับการเขียนโค้ด ขณะที่ยังคงใช้โหมด lite กับการสมัครใช้บริการ
แบบชำระเงิน

การกำหนด "การแทนที่รายคอมโบ" นี้เป็นการควบคุมคนละส่วนกับการแทนที่ **โหมดการบีบอัดของคอมโบการกำหนด
เส้นทาง** (Default/Off/Lite/Standard/Aggressive/Ultra/Codex Responses — สคีมาของฟิลด์นี้
ยังรองรับ `rtk`, `stacked` และ `omniglyph`) — การแทนที่ดังกล่าวไม่ได้เลือกไปป์ไลน์คอมโบการบีบอัด
ที่มีชื่อ แต่เพียงตั้งค่าฟิลด์ `compressionMode` ที่ `resolveCompressionPlan` ใช้อ้างอิง
คุณสามารถตั้งค่าได้ทั้งในการ์ดคอมโบ (`Dashboard → Combos`) หรือ ตั้งแต่ #6760 เป็นต้นมา
สามารถตั้งค่าแยกตามคอมโบการกำหนดเส้นทางในรายการ "Assign to routing" ที่
`Dashboard → Context & Cache → Compression Combos` ซึ่งอยู่ถัดจากช่องทำเครื่องหมายกำหนดไปป์ไลน์
ที่อธิบายไว้ข้างต้น ทั้งสองส่วนบันทึกค่าผ่านปลายทาง `PUT /api/combos/{id}` เดียวกัน

### การแทนที่รายคำขอ

ส่งส่วนหัวคำขอ `x-omniroute-compression` เพื่อแทนที่แผนการบีบอัดสำหรับคำขอเดียว
โดยมีลำดับความสำคัญสูงสุด — เหนือกว่าการแทนที่ของคอมโบการกำหนดเส้นทาง โปรไฟล์ที่ใช้งานอยู่
การทริกเกอร์อัตโนมัติ และค่า Default ของแผงควบคุม ค่าที่ไม่รู้จักจะถูกละเว้น (คำขอจะไม่ถูกปฏิเสธ)
และสวิตช์หลักส่วนกลางยังคงควบคุมทุกอย่าง: เมื่อปิดการบีบอัดในระดับส่วนกลาง ส่วนหัวนี้จะไม่สามารถ
เปิดใช้งานได้ ค่า:

| ค่า           | ผลลัพธ์                                                                                              |
| ------------- | ---------------------------------------------------------------------------------------------------- |
| `off`         | ไม่มีการบีบอัดสำหรับคำขอนี้                                                                          |
| `default`     | โปรไฟล์ Default ที่มาจากแผงควบคุม (ไม่สนใจโปรไฟล์ที่ใช้งานอยู่) เอนจินแบบสูญเสียข้อมูลจะยังคงปิดอยู่ |
| `safe`        | เหมือนกับการไม่ระบุส่วนหัว: ใช้เฉพาะการขจัดข้อมูลซ้ำและการยุบช่องว่าง                                |
| `allow-lossy` | คงแผนของโอเปอเรเตอร์สำหรับคำขอนี้ไว้ รวมถึงบทสรุป ตัวกรองความเกี่ยวข้อง และการปรับรูปแบบใหม่         |
| `engine:<id>` | เอนจินเดียวเมื่อเปิดใช้งาน เช่น `engine:rtk` นี่คือการเลือกใช้เอนจินนั้นเป็นรายคำขอ                  |
| `<combo>`     | คอมโบที่มีชื่อ โดยจับคู่ตามชื่อก่อน (ไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่) แล้วจึงตาม id                     |

หากไม่มี `allow-lossy`, `engine:<id>` หรือคอมโบที่มีชื่อ เอนจินแบบสูญเสียข้อมูลจะไม่ถูกนำมาใช้
คำขอยังคงได้รับการขจัดข้อมูลซ้ำของเซสชันและการยุบช่องว่างเมื่อเปิดการบีบอัด

แผนที่นำไปใช้จะถูกส่งกลับในส่วนหัวการตอบกลับ `X-OmniRoute-Compression: <mode>; source=<source>`
โดยที่ `<source>` เป็นค่าใดค่าหนึ่งใน `request-header`, `routing-override`, `active-profile`,
`auto-trigger`, `default` หรือ `off`

### API

```bash
# รับการตั้งค่าการบีบอัด
curl http://localhost:20128/api/settings/compression

# อัปเดตการตั้งค่าการบีบอัด
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# แสดงตัวอย่างเพย์โหลด RTK/stacked ที่ระบุ
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# แสดงรายการชุดตัวกรอง RTK
curl http://localhost:20128/api/context/rtk/filters

# ทดสอบ RTK โดยตรงพร้อมข้อมูลเมตาของคำสั่งที่ระบุหรือไม่ก็ได้
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'
```

---

## สิ่งที่ได้รับการปกป้อง

กลไกการบีบอัด **จะรักษาสิ่งต่อไปนี้ไว้เสมอ:**

- ✅ บล็อกโค้ด (ทั้งแบบมีรั้วและแบบอินไลน์)
- ✅ URL และพาธไฟล์
- ✅ โครงสร้าง JSON และข้อมูลที่มีโครงสร้าง
- ✅ ตัวระบุและโทเค็นทางเทคนิคที่ได้รับการปกป้อง
- ✅ นิพจน์ทางคณิตศาสตร์
- ✅ คำจำกัดความของการเรียกใช้เครื่องมือ/ฟังก์ชัน
- ✅ พรอมต์ระบบ (ในโหมด Lite)

การกู้คืนเอาต์พุตดิบของ RTK จะปกปิด API key ที่พบบ่อย, bearer token, โทเค็น Slack, AWS access key,
รหัสผ่าน, โทเค็น และข้อมูลลับ ก่อนที่จะมีการบันทึกข้อมูลใด ๆ อย่างถาวร

---

## สถิติการบีบอัด

ทุกคำขอที่บีบอัดจะมีสถิติรวมอยู่ในบันทึกของเซิร์ฟเวอร์:

```json
{
  "originalTokens": 47200,
  "compressedTokens": 40120,
  "savingsPercent": 15.0,
  "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"],
  "mode": "lite",
  "engine": "caveman",
  "compressionComboId": "coding-agent-stack",
  "durationMs": 0.8,
  "rtkRawOutputPointers": []
}
```

---

## แผนงานแต่ละระยะ

| ระยะ       | โหมด                                                                                                                                                | สถานะ          |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- |
| ระยะที่ 1  | Off, Lite                                                                                                                                           | ✅ เปิดตัวแล้ว |
| ระยะที่ 2  | Standard, Aggressive, Ultra                                                                                                                         | ✅ เปิดตัวแล้ว |
| ระยะที่ 3  | RTK, Stacked, Compression Combos                                                                                                                    | ✅ เปิดตัวแล้ว |
| ระยะที่ 4  | Output Styles, SLM-tier Ultra, eval harness                                                                                                         | ✅ เปิดตัวแล้ว |
| ระยะที่ 4C | งบประมาณบริบทแบบปรับเปลี่ยนได้ ("dial") — กลไกการคำนวณ + API (`contextBudget` บน `PUT /api/settings/compression`) + ส่วนควบคุมโหมด/นโยบายบนแดชบอร์ด | ✅ เปิดตัวแล้ว |

---

## กิตติกรรมประกาศ

กฎการบีบอัดของโหมด Standard ได้รับแรงบันดาลใจจาก **[Caveman](https://github.com/JuliusBrussee/caveman)** โดย **[JuliusBrussee](https://github.com/JuliusBrussee)** (⭐ 51K+) — โปรเจกต์ไวรัล "ทำไมใช้หลายโทเค็น ในเมื่อใช้ไม่กี่โทเค็นก็ได้ผล" Caveman รายงานว่าใช้โทเค็นเอาต์พุตน้อยลง `~75%`, ประหยัดเอาต์พุตโดยเฉลี่ยจากเกณฑ์มาตรฐาน `65%`, มีช่วงการประหยัดเอาต์พุต `22-87%` และมีเครื่องมือบีบอัดอินพุต `~46%`

โหมด RTK ได้รับแรงบันดาลใจจาก **[RTK - Rust Token Killer](https://github.com/rtk-ai/rtk)** โดย **[RTK AI](https://github.com/rtk-ai)** — โปรเจกต์บีบอัดเอาต์พุตคำสั่งประสิทธิภาพสูงสำหรับการกรองเอาต์พุตจากเทอร์มินัล, การบิลด์, การทดสอบ, git และเครื่องมือ RTK รายงานว่าประหยัดได้ `60-90%` โดยเซสชันตัวอย่างใน README แสดงการประหยัด `~80%`

---

## ระบบการบีบอัดขั้นสูง

นอกเหนือจาก 7 โหมดที่อธิบายไว้ข้างต้น (ซอร์สยังรองรับโหมด `codex-responses` และ
`omniglyph` ซึ่งคู่มือนี้ไม่ครอบคลุม) ส่วนด้านล่างจะกล่าวถึงฟีเจอร์ที่ทำงานภายในหรือควบคู่
กับโหมดเหล่านั้น: Tool Result Compression และ Progressive Aging เป็นขั้นตอนที่ 1 และ 2
ของเอนจินแบบ aggressive (โหมด Aggressive และขั้นตอน `aggressive` ของไปป์ไลน์แบบ
ซ้อน) ส่วน Stacked Pipeline คือวิธีที่โหมด Stacked ทำงาน ขณะที่ Cache-Aware Compression
จะลดระดับ `aggressive` และ `ultra` เป็น `standard` สำหรับผู้ให้บริการที่รองรับการแคชเมื่อเปิด
การบีบอัด และ Caveman Output Mode กับ Output Styles เป็นคำสั่งใน system prompt
แบบเลือกรับ ซึ่งปิดไว้โดยค่าเริ่มต้น และใช้กำหนดรูปแบบเอาต์พุตของโมเดลแทนการบีบอัดคำขอ

### การบีบอัดที่คำนึงถึงแคช

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

โมดูล `cachingAware.ts` แก้ปัญหานี้ด้วยการ **ตรวจจับบริบทการแคช** และ
**ปรับกลยุทธ์การบีบอัด** ให้เหมาะสม

#### วิธีการทำงาน

1. **ตรวจจับบริบทการแคช** — สแกนเนื้อหาคำขอหาเครื่องหมาย `cache_control`
2. **ระบุผู้ให้บริการที่รองรับการแคช** — ตรวจสอบว่าผู้ให้บริการเป้าหมายรองรับการแคชหรือไม่
3. **ปรับกลยุทธ์** — ลดระดับ `aggressive`/`ultra` เป็น `standard` สำหรับผู้ให้บริการที่รองรับการแคช
4. **ข้าม system prompt** — โดยทั่วไป system prompt จะถูกแคช จึงไม่ควรบีบอัด

ตัวช่วยกลยุทธ์ยังส่งคืนแฟล็ก `deterministicOnly` แต่ตัวสร้างแผนจะใช้เฉพาะ
กลยุทธ์เท่านั้น — ปัจจุบันไม่มีสิ่งใดในขั้นตอนถัดไปอ่านแฟล็กนี้

#### ตัวอย่างโค้ด

```ts
import {
  detectCachingContext,
  getCacheAwareStrategy,
} from "@omniroute/open-sse/services/compression/cachingAware";

const body = {
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Hello" }],
  cache_control: { type: "ephemeral" }, // ← เครื่องหมายแคช
};

const ctx = detectCachingContext(body, { provider: "anthropic" });
// → { hasCacheControl: true, provider: "anthropic", targetFormat: null, isCachingProvider: true }

const strategy = getCacheAwareStrategy("aggressive", ctx);
// → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true }
```

#### ควรใช้เมื่อใด

การบีบอัดที่คำนึงถึงแคช **เปิดใช้งานอยู่เสมอ** — ไม่ต้องกำหนดค่าใดๆ ฟีเจอร์นี้จะเริ่มทำงานเมื่อใดก็ตามที่
เปิดการบีบอัดและผู้ให้บริการเป้าหมายรองรับการแคชพรอมต์ (Anthropic, OpenAI
ฯลฯ) โดยไม่จำเป็นต้องมีเครื่องหมาย `cache_control` อย่างชัดเจน — เพียงเป็นผู้ให้บริการที่รองรับการแคช
ก็จะกระตุ้นการลดระดับ และเครื่องหมายเพียงอย่างเดียวจะไม่กระตุ้นการลดระดับ (การตรวจจับเครื่องหมายใช้เป็นข้อมูลสำหรับ
เทเลเมทรีของแคช ไม่ใช่การตัดสินใจเลือกกลยุทธ์)

### Progressive Aging

การสนทนาที่ยาวจะสะสมข้อความหลายรอบ แต่ข้อความในรอบที่เก่ากว่าจะมี
ความเกี่ยวข้องน้อยลง โมดูล `progressiveAging.ts` จะ **ลดรายละเอียดของข้อความตามระยะห่างของรอบ**
(วัดระยะห่างจากท้ายบทสนทนา) เมื่อใช้ค่าเริ่มต้นที่ให้มา
(`verbatim: 2, light: 2, moderate: 3`):

- **2 รอบล่าสุด (ระยะห่าง ≤ 2)**: เก็บไว้ตามต้นฉบับ
- **ระยะห่าง 3**: การบีบอัดแบบ Caveman (ลบคำฟุ่มเฟือย)
- **ระยะห่าง 4+**: สรุปข้อความของ assistant ส่วนข้อความของ user จะเหลือเพียงบรรทัดแรก
  และจำกัดไว้ที่ 120 อักขระ ส่วน role อื่นๆ จะไม่ถูกแก้ไข System prompt ข้อความที่ผ่านการ aging
  แล้ว และข้อความล่าสุดของ user จะถูกเก็บไว้ตามต้นฉบับเสมอโดยไม่ขึ้นกับระยะห่าง
  ไม่มีสิ่งใดถูกตัดทิ้งทั้งหมด และแถบ `light`
  ไม่สามารถเข้าถึงได้เมื่อใช้ค่าเริ่มต้นที่ให้มา (`light` เท่ากับ `verbatim`)

#### ตัวอย่างโค้ด

```ts
import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging";

const messages = [
  { role: "system", content: "You are a helpful assistant" },
  { role: "user", content: "What is 2+2?" },
  { role: "assistant", content: "4" },
  // ... อีก 50 รอบ ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // 3 รอบล่าสุด: ตามต้นฉบับ
  light: 8, // ระยะห่าง <= 8: การบีบอัดระดับ lite
  moderate: 20, // ระยะห่าง <= 20: การบีบอัดแบบ caveman
  fullSummary: 5, // type กำหนดให้ต้องมี แต่โค้ดแบ่งแถบไม่ได้อ่านค่านี้
  // ระยะห่าง > 20: สรุป (assistant) / เก็บไว้เฉพาะบรรทัดแรก (user)
});

// saved = จำนวนโทเค็นที่ประหยัดได้
```

#### ควรใช้เมื่อใด

Progressive aging **เปิดใช้งานอยู่เสมอ** สำหรับโหมด `aggressive` — โดยเป็นขั้นตอนที่ 2 ของ
`compressAggressive()` ส่วนโหมด Ultra จะไม่เรียกใช้ฟีเจอร์นี้ โดยจะ
มีประสิทธิภาพเป็นพิเศษสำหรับ:

- เซสชันการเขียนโค้ดที่ดำเนินต่อเนื่องเป็นเวลานาน
- การสนทนาที่กินเวลาหลายวัน
- เวิร์กโฟลว์แบบเอเจนต์ที่มีการเรียกใช้เครื่องมือจำนวนมาก

### โหมดเอาต์พุต Caveman

โหมดเอาต์พุต Caveman จะเพิ่ม **คำสั่งใน system prompt** ที่ขอให้ตัวโมเดลเองสร้าง
เอาต์พุตแบบกระชับ — ระดับ `lite` ขอให้ตอบอย่างกระชับโดยยังคงใช้ประโยคที่สมบูรณ์ ส่วน `full`
ขอให้โมเดล "ตอบสั้นห้วนเหมือนมนุษย์ถ้ำาฉลาด" และ `ultra` ขอเอาต์พุตแบบโทรเลข
คำสั่งเหล่านี้เป็นเพียงการร้องขอและไม่สามารถรับประกันผลลัพธ์ได้ คำขอจะได้รับคำสั่งผ่าน
`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`):
ก่อนอื่น `open-sse/handlers/chatCore.ts` จะกำหนดค่าที่เลือกด้วยชิมเพื่อรองรับความเข้ากันได้ย้อนหลัง
(`resolveOutputStyleSelection()` ใน
`open-sse/services/compression/outputStyles/backCompat.ts`) ซึ่งเมื่อ `outputStyles`
ว่างอยู่ จะแมป `cavemanOutputMode` ที่เปิดใช้งานไปยังสไตล์เอาต์พุต `terse-prose` ที่ระดับ
`cavemanOutputMode.intensity` (ดูส่วนความเข้ากันได้ย้อนหลังด้านล่าง) หากมีการเลือก `outputStyles`
ที่ไม่ว่าง ระบบจะใช้ค่านั้นตามที่เป็นอยู่ จากนั้น `cavemanOutputMode.enabled` และ `intensity` จะไม่มี
ผล ส่วนสวิตช์ `autoClarity` ของโหมดนี้ยังคงมีผลอยู่ `outputMode.ts` เก็บ
ข้อความคำสั่ง (`CAVEMAN_INSTRUCTION_BY_LANGUAGE`) การข้ามตามเนื้อหา และ
ตัวช่วยกำหนดตำแหน่งที่การแทรกใช้ ส่วนตัวแทรก `applyCavemanOutputMode()` ของโมดูลนี้ไม่มี
ตัวเรียกใช้ใน production

#### วิธีการทำงาน

โหมดนี้ไม่บีบอัดอินพุต แต่จะเพิ่มบล็อกคำสั่งลงในพรอมต์ระบบ
(ดูวิธีการแทรกด้านล่าง) และโหมดบีบอัดอินพุตใดๆ ที่เลือกไว้สำหรับคำขอ
จะยังคงทำงานภายหลังกับเนื้อหาที่มีบล็อกดังกล่าวแล้ว ก่อนถึงข้อกำหนดขอบเขตร่วม
ที่ทุกระดับลงท้ายด้วย ระดับ `full` ภาษาอังกฤษมีข้อความว่า:

> "ตอบให้กระชับเหมือนมนุษย์ถ้ำฉลาด ตัดคำนำหน้านาม (a/an/the), คำฟุ่มเฟือย (just/really/basically/actually/simply), คำสุภาพ และถ้อยคำแบ่งรับแบ่งสู้ ใช้วลีไม่สมบูรณ์ได้ ใช้คำพ้องที่สั้นกว่า (big ไม่ใช่ extensive, fix ไม่ใช่ implement) คงสาระทางเทคนิค โค้ด ข้อผิดพลาด URL และตัวระบุทั้งหมดไว้ตามเดิม"

โหมดนี้ทำงานได้ดีเป็นพิเศษสำหรับ:

- การสร้างโค้ด (เอาต์พุตกระชับขึ้น = ใช้โทเคนน้อยลง)
- การถามตอบแบบรวดเร็ว (ไม่ต้องมีคำอธิบายยืดยาว)
- การประมวลผลแบบกลุ่ม (เพิ่มปริมาณงานสูงสุด)

#### ควรใช้เมื่อใด

โหมดเอาต์พุตแบบมนุษย์ถ้ำเป็นแบบ **ต้องเลือกใช้เอง** เมื่อเปิดการบีบอัด (`enabled: true` ซึ่งเป็นสวิตช์หลัก
ในหน้า Compression Settings) ให้เปิดโหมดนี้ด้วย `cavemanOutputMode.enabled`; `intensity`
ใช้เลือกระหว่าง `lite`, `full` หรือ `ultra`:

```json
{
  "enabled": true,
  "cavemanOutputMode": {
    "enabled": true,
    "intensity": "full"
  }
}
```

สวิตช์ **Output Mode** ของชุดค่าการบีบอัด (`outputMode` โดยมีระดับอยู่ใน `outputModeIntensity`)
จะตั้งค่าสวิตช์เดียวกันสำหรับคำขอที่ชุดค่านั้นมีผล และเครื่องมือ MCP
`omniroute_set_compression_engine` จะเขียนค่านี้ผ่านอาร์กิวเมนต์บูลีน `outputMode`
การเลือก `outputStyles` ที่ไม่ว่างจะมีลำดับความสำคัญเหนือสวิตช์นี้ ในแดชบอร์ด การเปิดใช้
สไตล์เอาต์พุต **Terse prose** จะแทรกบล็อกเดียวกัน (ดู Output Styles ด้านล่าง)

### สไตล์เอาต์พุต (แค็ตตาล็อก)

โหมดเอาต์พุตแบบมนุษย์ถ้ำด้านบนคือ **เส้นทางสไตล์เดี่ยวแบบดั้งเดิม** Phase 4 ได้ขยายแนวคิดนี้
เป็นแค็ตตาล็อกของสไตล์เอาต์พุตที่นำมาประกอบร่วมกันได้: `OUTPUT_STYLE_CATALOG` ใน
`open-sse/services/compression/outputStyles/catalog.ts` แต่ละสไตล์คือคำสั่งในพรอมต์ระบบ
ที่ขอให้โมเดลสร้างเอาต์พุตที่ประหยัดขึ้น โดยสามารถเปิดใช้หลายสไตล์ร่วมกันได้
และระบบจะแทรกตามลำดับในแค็ตตาล็อก

| สไตล์                                           | `id`            | การทำงาน                                                                                                                                                                                                                                                                            | ภาษาของคำสั่ง                                 |
| ----------------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| ร้อยแก้วกระชับ                                  | `terse-prose`   | ตัดคำฟุ่มเฟือย/คำนำหน้านาม/ถ้อยคำแบ่งรับแบ่งสู้ และคงสาระทางเทคนิคไว้อย่างแม่นยำ ใช้ข้อความเดียวกับโหมดเอาต์พุตแบบมนุษย์ถ้ำดั้งเดิม (อ้างอิงโดยไม่เขียนซ้ำ)                                                                                                                         | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| โค้ดน้อยลง                                      | `less-code`     | ลำดับขั้นแบบ YAGNI: เปลี่ยนแปลงให้น้อยที่สุดเท่าที่ทำงานได้ และไม่สร้างนามธรรมที่ไม่ได้ร้องขอ                                                                                                                                                                                       | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| Ponytail (นักพัฒนาอาวุโสสายขี้เกียจ)            | `ponytail`      | "โค้ดที่ดีที่สุดคือโค้ดที่ไม่เคยถูกเขียน": นำกลับมาใช้ใหม่ > เขียนใหม่, สาเหตุรากฐาน > อาการ, diff ที่สั้นที่สุดและทำงานได้                                                                                                                                                         | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ฉันมี ADHD (ลงมือทำก่อน)                        | `i-have-adhd`   | ให้การลงมือทำมาก่อน (คำสั่ง/พาธ/ส่วนย่อยของโค้ดก่อนคำอธิบาย), ขั้นตอนแบบมีหมายเลขและจำกัดจำนวน, ขั้นตอนถัดไปที่เป็นรูปธรรมเพียงหนึ่งขั้น, ไม่มีคำนำ/สรุปทบทวน/คำลงท้าย ดัดแปลงจาก [ayghri/i-have-adhd](https://github.com/ayghri/i-have-adhd) (MIT)                                 | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ตัวกรอง Antislop สำหรับ UI                      | `antislop-ui`   | ทุกเทคนิคด้านภาพต้องผ่านการทดสอบด้านวัตถุประสงค์ (ลำดับชั้น, อัตลักษณ์, ความสามารถในการอ่าน) ห้ามใช้การไล่สี/กระจก/แสงเรืองรองเป็นค่าเริ่มต้น จำกัดชุดสี และไม่ใช้เลย์เอาต์แบบเทมเพลต สไตล์ antislop ทั้งสองแบบเพิ่มขอบเขตห้ามมีตัวควบคุมที่ใช้งานไม่ได้ / ห้ามสร้างคำกล่าวอ้างเท็จ | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| ตัวกรอง Antislop สำหรับข้อความและความเป็นมนุษย์ | `antislop-copy` | ใช้ข้อความที่เฉพาะเจาะจง (ไม่มี em dash, CTA ทั่วไป, buzzword, คำลงท้ายแบบแชตบอต หรือข้อเท็จจริงที่แต่งขึ้น) พร้อมกฎสำหรับผู้ใช้: คอนทราสต์ตาม WCAG AA, โฟกัสที่มองเห็นได้, เข้าถึงด้วยแป้นพิมพ์, สถานะว่าง/กำลังโหลด/ข้อผิดพลาด และการจัดวางใหม่บนอุปกรณ์เคลื่อนที่                | en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi |
| CJK แบบกระชับ (文言)                            | `terse-cjk`     | ระดับ `full`/`ultra` ตอบเป็นภาษาจีนคลาสสิก (文言); ระดับ `lite` ขอเพียงคำตอบสั้นๆ ที่ไม่มีคำบอกหน้าที่ทางไวยากรณ์ คำสุภาพ หรือการประดับถ้อยคำ                                                                                                                                       | zh (จำกัดตาม locale ดูด้านล่าง)               |

ทุกสไตล์มีระดับความเข้มสามระดับ ได้แก่ `lite`, `full`, `ultra` และทุกระดับ
ลงท้ายด้วยข้อกำหนดขอบเขตร่วม (`SHARED_BOUNDARIES` ใน `outputMode.ts`) ซึ่ง
คงบล็อกโค้ด พาธไฟล์ คำสั่ง ข้อผิดพลาด และ URL ไว้ตามเดิม ข้อความระดับต่างๆ ของ `terse-prose` และ
`terse-cjk` จะเพิ่มตัวระบุไว้ในรายการดังกล่าวด้วย

`terse-cjk` ถูกจำกัดตาม locale ให้ใช้ได้เฉพาะ `zh` ในสองตำแหน่ง หน้า Compression Settings จะแสดง
แถวของสไตล์นี้เฉพาะเมื่อภาษาของ UI แดชบอร์ดเป็นภาษาจีน (`zh-CN` หรือ `zh-TW`) และ
`applyOutputStyles()` จะแทรกสไตล์นี้เฉพาะเมื่อภาษาที่ระบบกำหนดให้คำขอ (ดูการเลือกภาษา
ด้านล่าง) เป็น `zh` การซ่อนแถวจะไม่ล้างการเลือก `terse-cjk` ที่บันทึกไว้:
API การตั้งค่ายอมรับ style id ใดๆ และการบันทึกสไตล์อื่นๆ บนหน้าดังกล่าวจะยังคงเก็บค่านี้ไว้
ขณะประมวลผลคำขอ การตรวจสอบภาษาของ `applyOutputStyles()` เป็นตัวจำกัด locale เพียงจุดเดียว

#### วิธีการแทรก

`applyOutputStyles()` (`open-sse/services/compression/outputStyles/apply.ts`) จะแก้ไขการเลือกโดยเทียบกับแค็ตตาล็อก (id ที่ไม่รู้จักและสไตล์ที่โลแคลไม่ตรงกันจะถูกตัดทิ้ง และจะไม่ถือเป็นข้อผิดพลาด การเลือกที่หลังจากแก้ไขแล้วไม่เหลือสไตล์ใดจะปล่อย body ไว้โดยไม่เปลี่ยนแปลง และข้ามด้วยเหตุผล `no_styles`) จากนั้นเชื่อมคำสั่งที่เลือกตามลำดับในแค็ตตาล็อก
เพิ่มข้อกำหนดเกี่ยวกับขอบเขตต่อท้าย **หนึ่งครั้ง** (รวมถึงข้อกำหนดด้านความปลอดภัย `SAFETY_BOUNDARIES` หรือคำแปลของข้อกำหนดดังกล่าว เมื่อเลือก `less-code` หรือ `ponytail`) และเริ่มต้นบล็อกด้วยเครื่องหมายป้องกันการใช้ซ้ำเพียงรายการเดียว (`[OmniRoute Output Styles]`) ดังนั้นการนำไปใช้อีกครั้งจะไม่มีผล เมื่อภาษาที่แก้ไขได้แล้ว (ดูการเลือกภาษาด้านล่าง) มีคำแปล ระบบจะแทรกคำสั่งฉบับภาษาท้องถิ่นแทนภาษาอังกฤษ

สำหรับ body ที่มีอาร์เรย์ `messages` ซึ่งไม่ว่างเปล่า การตรวจสอบการใช้ซ้ำจะทำงานก่อนการข้ามตามเนื้อหา เมื่อมีเครื่องหมาย `[OmniRoute Output Styles]` อยู่แล้วในฟิลด์ `system` ระดับบนสุด (ซึ่งเป็นสตริงหรืออาร์เรย์ของบล็อกเนื้อหา) หรืออยู่ในข้อความ system ที่มีเนื้อหาเป็นสตริง ระบบจะปล่อย body ไว้โดยไม่เปลี่ยนแปลงด้วยเหตุผล `already_applied` และจะไม่ตรวจสอบคีย์เวิร์ด
มิฉะนั้น การข้ามตามเนื้อหา (`shouldBypassCavemanOutputMode()` ใน
`open-sse/services/compression/outputMode.ts`) จะตรวจสอบข้อความของสามข้อความล่าสุด ไม่ว่าจะมีบทบาทใด และข้ามสไตล์ทั้งหมดสำหรับเทิร์นนั้นเมื่อข้อความตรงกับคีย์เวิร์ดด้านความปลอดภัย การดำเนินการที่ไม่สามารถย้อนกลับได้ หรือการขอคำชี้แจง หรือตรงกับลำดับที่ขึ้นอยู่กับลำดับคำ ได้แก่ `first`, `then`, `after that`, `before`, `rollback` หรือ
`backup` แล้วตามด้วย `delete`, `drop`, `migrate`, `deploy` หรือ
`release` ภายใน 240 อักขระ การข้ามจะทำงานขณะที่สวิตช์ **การข้ามเพื่อความชัดเจนอัตโนมัติ**
(`cavemanOutputMode.autoClarity` ซึ่งเปิดไว้ตามค่าเริ่มต้น) เปิดอยู่ การปิดสวิตช์นี้จะทำให้ข้ามการตรวจสอบคีย์เวิร์ด

เมื่อการตรวจสอบการข้ามอนุญาตให้เทิร์นผ่าน `placeSystemInstruction()` (อยู่ในไฟล์เดียวกัน) ซึ่งจะไม่สร้าง `messages[0]` ใหม่ จะวางบล็อกไว้ในตำแหน่งแรกที่พบตามลำดับต่อไปนี้:

1. ข้อความ system แรกสุดที่มีเนื้อหาเป็นสตริง: เพิ่มบล็อกต่อท้ายข้อความนั้น
2. ฟิลด์ `system` ระดับบนสุด: เพิ่มบล็อกต่อท้ายข้อความของสตริง หรือ
   เพิ่มเป็นบล็อกข้อความใหม่ในอาร์เรย์ของบล็อกเนื้อหา
3. ข้อความ system รายการแรกที่อยู่ถัดไปและมีเนื้อหาเป็นสตริง: เพิ่มบล็อกต่อท้ายข้อความนั้น
4. หากไม่มีกรณีใดข้างต้น: ใส่บล็อกไว้ในข้อความ system ใหม่ที่ท้าย `messages`

สำหรับ body ที่ไม่มีอาร์เรย์ `messages` (หรือมีอาร์เรย์ว่าง) จะไม่มีการข้ามตามเนื้อหา และจะไม่ตรวจสอบฟิลด์ `system` ระดับบนสุด บล็อกจะถูกเพิ่มต่อท้ายข้อความของฟิลด์ `instructions` ที่เป็นสตริง เว้นแต่ฟิลด์นั้นมีเครื่องหมาย
`[OmniRoute Output Styles]` อยู่แล้ว ซึ่งในกรณีดังกล่าว ระบบจะปล่อย body ไว้โดยไม่เปลี่ยนแปลงด้วยเหตุผล
`already_applied` เมื่อ body ไม่มีฟิลด์ `instructions` ที่เป็นสตริง แต่มี `input`
(เป็นสตริงหรืออาร์เรย์) บล็อกจะกลายเป็น `instructions` โดยแทนที่ค่าที่ไม่ใช่สตริงซึ่งฟิลด์นั้นเคยเก็บไว้ body ที่ไม่มีทั้งฟิลด์ `instructions` ที่เป็นสตริงและ `input` ที่เป็นสตริงหรืออาร์เรย์ จะถูกปล่อยไว้โดยไม่เปลี่ยนแปลงและข้ามด้วยเหตุผล `no_messages`

#### วิธีเปิดใช้งาน

ในแดชบอร์ด: **บริบทการบีบอัด → การตั้งค่าการบีบอัด**
(`/dashboard/context/settings`) ส่วนสไตล์เอาต์พุต: มีหนึ่งแถวต่อหนึ่งสไตล์ พร้อมสวิตช์เปิด/ปิดและตัวเลือกระดับ สไตล์จะถูกแทรกขณะที่การบีบอัดเปิดอยู่ (สวิตช์หลักของหน้า `enabled`) สวิตช์ **การข้ามเพื่อความชัดเจนอัตโนมัติ** อยู่ในหน้า **Caveman**
(`/dashboard/context/caveman`) ภายในการ์ด **โหมดเอาต์พุต** ในเชิงโปรแกรม การกำหนดค่าการบีบอัดจะจัดเก็บการเลือกไว้ดังนี้:

```json
{
  "outputStyles": [
    { "id": "i-have-adhd", "level": "full" },
    { "id": "less-code", "level": "lite" }
  ]
}
```

ความเข้ากันได้ย้อนหลัง: ขณะที่ `outputStyles` ว่างเปล่า การตั้งค่าเดิม `cavemanOutputMode.enabled`
จะถูกแมปเป็น `terse-prose` ที่ระดับ `cavemanOutputMode.intensity` จากนั้นบล็อกจะเริ่มต้นด้วยเครื่องหมาย `[OmniRoute Output Styles]` ขณะที่ตัวแทรกเดิม `applyCavemanOutputMode()`
เคยเขียน `[OmniRoute Caveman Output Mode]` ใต้เครื่องหมายดังกล่าว ข้อความจะตรงกับการแทรกแบบเดิมในภาษา en, pt-BR, es, de, fr, it, ru, id และ vi ส่วนในภาษา ja และ zh จะมีช่องว่างเพิ่มเติมหนึ่งช่องก่อนข้อกำหนดเกี่ยวกับขอบเขต `terse-prose` มีคำแปลเป็นภาษา pt-BR, es, de,
fr, it, ru, zh, ja, id และ vi ดังนั้นคำขอที่ได้ภาษาหลังการแก้ไขเป็น `hu` จะได้รับข้อความภาษาอังกฤษ ในขณะที่ตัวแทรกเดิมใช้ข้อความภาษาฮังการี

การเลือกภาษาของสไตล์เอาต์พุต (`resolveOutputStyleLanguage()` ใน
`outputStyles/apply.ts`): เมื่อเปิด `languageConfig.enabled` ไว้ `autoDetect` จะสุ่มตรวจข้อความล่าสุดจากผู้ใช้ในอาร์เรย์ `messages` ของคำขอที่มีข้อความ (เนื้อหาที่เป็นสตริง หรือ `text` ของส่วนเนื้อหา) และเรียกใช้ตัวตรวจจับของเอนจิน Caveman
(`detectCompressionLanguage()`) กับข้อความนั้น ตัวตรวจจับจะคืนค่า `zh` สำหรับข้อความที่มีอักษรฮั่นและไม่มีคานะ มิฉะนั้นจะคืนค่าภาษาที่มีจำนวนคำใบ้ตรงกันมากที่สุดจาก `it`, `pt-BR`, `es`, `de`,
`fr`, `ru`, `ja`, `hu` และ `id` และคืนค่า `en` เมื่อไม่มีรายการใดตรงกัน —
ข้อความที่ไม่สามารถจำแนกได้จะใช้ภาษาอังกฤษเสมอ โดยจะไม่ใช้ `defaultLanguage` และระบบจะไม่มีวันตรวจพบ `vi` แม้ว่าสไตล์จะมีข้อความภาษา `vi` ก็ตาม body ของ Responses API จะเก็บเทิร์นต่าง ๆ ไว้ใน
`input` ซึ่งจะไม่ถูกสุ่มตรวจ ดังนั้นจึงใช้ `defaultLanguage` แล้วจึงใช้ภาษาอังกฤษ เมื่อไม่มีข้อความจากผู้ใช้ใน `messages` ที่มีข้อความ หรือเมื่อปิด `autoDetect` ระบบจะใช้
`defaultLanguage` แล้วจึงใช้ภาษาอังกฤษ เมื่อปิด `languageConfig.enabled` ภาษาที่ใช้คือภาษาอังกฤษ — เว้นแต่จะมีคอมโบการบีบอัดที่ใช้กับคำขอ (คอมโบที่กำหนดให้กับคอมโบการกำหนดเส้นทางของคำขอ หรือคอมโบการบีบอัดเริ่มต้นที่ chatCore ใช้เป็นทางเลือกสำรองสำหรับไปป์ไลน์แบบซ้อนในตัว): การใช้คอมโบจะเปิด `languageConfig.enabled` สำหรับคำขอนั้น และตั้งค่า `defaultLanguage` จากแพ็กภาษาของคอมโบ (ใช้ค่าที่บันทึกไว้หากค่านั้นเป็นหนึ่งในแพ็กของคอมโบ มิฉะนั้นใช้แพ็กแรกของคอมโบ ซึ่งมีค่าเริ่มต้นเป็น `en`) ขณะที่ค่า `autoDetect` ที่บันทึกไว้ (เปิดตามค่าเริ่มต้น) ยังคงมีผล เอนจินอินพุต Caveman จะเลือกภาษาของแพ็กกฎด้วยวิธีที่ต่างออกไป — เลือกแยกตามแต่ละส่วนข้อความ และเมื่อปิดการตรวจจับอัตโนมัติ การเลือกจะถูกควบคุมโดย `enabledPacks`

เมทริกซ์รูปแบบ × ภาษาถูกตรึงไว้โดย
`tests/unit/compression/output-styles-i18n-matrix.test.ts`: รูปแบบทุกแบบในแค็ตตาล็อกต้องมี
รายการใน `BASELINE_LANGUAGES` ของการทดสอบ รูปแบบที่ไม่ได้ถูกจำกัดตาม locale ต้องมาพร้อมคำแปล
pt-BR (โดย `terse-cjk` ซึ่งถูกจำกัดตาม locale ได้รับการยกเว้นจากกฎนี้) เว้นแต่รูปแบบนั้นจะอยู่ใน
`KNOWN_ENGLISH_ONLY` ซึ่งอนุญาตให้มีได้เฉพาะรูปแบบที่ไม่มีคำแปลเลยเท่านั้น —
รูปแบบที่อยู่ในรายการแต่มีคำแปลใดๆ จะทำให้การทดสอบล้มเหลว และรูปแบบจะทำให้การทดสอบล้มเหลวเมื่อ
ภาษาที่ระบุไว้ในรายการ `BASELINE_LANGUAGES` ของรูปแบบนั้นหายไป หากต้องการเพิ่มรูปแบบ โปรดดู
[EXTENDING_COMPRESSION.md](./EXTENDING_COMPRESSION.md#adding-an-output-style)

### การบีบอัดผลลัพธ์ของเครื่องมือ

`compressToolResult()` ใน `open-sse/services/compression/toolResultCompressor.ts`
บีบอัดข้อความผลลัพธ์ของเครื่องมือด้วย **5 กลยุทธ์** โดยจะลองตามลำดับนี้ และ
กลยุทธ์แรกที่เปิดใช้งานและมีเงื่อนไขตรงกับเนื้อหาจะเป็นตัวกำหนดผลลัพธ์:

1. **`fileContent`**: เนื้อหาตั้งแต่ 3 บรรทัดขึ้นไป ซึ่งมีอย่างน้อยหนึ่งบรรทัดที่เมื่อไม่นับ
   การเยื้องนำหน้าแล้ว เริ่มต้นด้วย `import `, `export `, `function `, `class `,
   `const `, `let `, `var ` หรือ `return ` (คีย์เวิร์ดตามด้วยช่องว่าง) หรือด้วย `if`,
   `for` หรือ `while` ตามด้วย `(` หรือ ` (` จะเก็บ 20 บรรทัดแรกและ 5 บรรทัดสุดท้ายไว้ พร้อม
   ทำเครื่องหมายส่วนตรงกลางที่ถูกตัดออก
2. **`grepSearch`**: เนื้อหาที่มีอย่างน้อยหนึ่งบรรทัดในรูปแบบ `<path>:<digits>:`
   โดยข้อความก่อนเครื่องหมายโคลอนตัวแรกไม่มีอักขระช่องว่าง จะเก็บไว้เฉพาะบรรทัดดังกล่าว สูงสุด
   30 บรรทัด ตามด้วยจำนวนรายการที่ตรงกันเพิ่มเติมและรายชื่อไฟล์ที่ตรงกัน
   ส่วนบรรทัดอื่นทั้งหมดจะถูกทิ้ง เพียงหนึ่งบรรทัดดังกล่าวก็เพียงพอที่จะเรียกใช้กลยุทธ์นี้ ดังนั้น
   บรรทัดบันทึกที่ขึ้นต้นด้วยการประทับเวลา เช่น `12:30:45` ก็นับเช่นกัน
3. **`shellOutput`**: เอาต์พุตที่มีลำดับ ANSI CSI (`ESC[` ตามด้วยตัวเลขหรือ
   เครื่องหมายอัฒภาค แล้วตามด้วยตัวอักษร เช่นในรหัสสี) หรือมี `$` ตามด้วยอักขระช่องว่าง
   ที่ตำแหน่งใดก็ตามในข้อความ จะถูกนำลำดับเหล่านั้นออก (ลำดับหลีกอื่นๆ เช่น `ESC[?25l` หรือ
   ลำดับ OSC สำหรับชื่อหน้าต่างจะยังคงอยู่) และเก็บ 50 บรรทัดสุดท้ายไว้ โดยยุบ
   บรรทัดซ้ำที่ต่อเนื่องกัน เนื่องจากการตรวจสอบนี้ทำงานก่อน `json` และ `errorMessage`
   เอาต์พุต JSON หรือข้อผิดพลาดที่มี `$` ดังกล่าวจะไม่มีวันไปถึงกลยุทธ์เหล่านั้น ตราบใดที่
   `shellOutput` เปิดอยู่
4. **`json`**: เพย์โหลด JSON ที่ยาวกว่า 2,000 อักขระ ซึ่งเริ่มต้นด้วย `{` หรือ `[` (หลังจาก
   อักขระช่องว่างที่อาจมี) และสามารถแยกวิเคราะห์ได้ จะถูกสรุปดังนี้: อาร์เรย์ที่มีมากกว่า 7 รายการจะเก็บ
   5 รายการแรกและ 2 รายการสุดท้าย พร้อมจำนวนรายการทั้งหมด ส่วนอ็อบเจ็กต์จะเก็บ 20
   คีย์แรก โดยแทนค่าอ็อบเจ็กต์หรืออาร์เรย์ที่ซ้อนอยู่แต่ละค่าด้วยตัวยึดตำแหน่ง `{…N keys}`
   (สำหรับอาร์เรย์ N คือความยาวของอาร์เรย์) และใช้เครื่องหมาย `_remaining_<N>_keys` เพื่อนับคีย์
   ที่ถูกทิ้งหลัง 20 คีย์แรก ค่าสเกลาร์จะถูกคัดลอกทั้งหมด ดังนั้นอ็อบเจ็กต์ที่มีไม่เกิน 20 คีย์
   และไม่มีค่าซ้อนจะถูกจัดย่อหน้าใหม่เท่านั้น — อ็อบเจ็กต์แบบย่อจะมีจำนวนอักขระเพิ่มขึ้น
   และยังคงไม่เปลี่ยนแปลง
5. **`errorMessage`**: เอาต์พุตที่มี `error:`, `error ` (คำตามด้วยช่องว่าง เช่น
   `no error found`), `[error]`, `exception:`, `exception `, `[exception]` หรือ
   `traceback` อยู่ที่ตำแหน่งใดก็ตามและไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ จะเก็บบรรทัดแรก
   10 บรรทัดถัดไป และ 3 บรรทัดสุดท้ายไว้ โดยใช้เครื่องหมาย `… [N frames elided] …` แทน
   บรรทัดระหว่างนั้น เครื่องหมายนี้จะปรากฏเฉพาะเมื่อมีมากกว่า 13 บรรทัดต่อจากบรรทัดแรก
   ดังนั้นเอาต์พุตข้อผิดพลาดที่มีไม่เกิน 14 บรรทัดจะไม่ถูกย่อ (เมื่อมี 12 หรือ 13 บรรทัด
   3 บรรทัดสุดท้ายจะซ้ำกับบรรทัดที่เก็บไว้แล้ว)

หลังจากกลยุทธ์หนึ่งตรงตามเงื่อนไข แม้จะเป็นกลยุทธ์ที่ไม่ประหยัดอะไรเลย กลยุทธ์ลำดับถัดไปก็จะไม่
ถูกลองใช้ เมื่อกลยุทธ์ที่ตรงตามเงื่อนไขไม่ประหยัดโทเค็นโดยประมาณ (ความยาว ÷ 4 ปัดขึ้น) —
เช่น ไฟล์ที่มีลักษณะคล้ายโค้ดซึ่งมีไม่เกิน 25 บรรทัด หรืออาร์เรย์ JSON ที่ยาวกว่า 2,000
อักขระและมีไม่เกิน 7 รายการ — เอนจินแบบเข้มข้นจะเก็บผลลัพธ์เดิมของเครื่องมือไว้:
ตัวเรียกใช้ทั้งสอง (`compressAggressive()` และ `compressAnthropicToolResultBlock()`)
จะเก็บผลลัพธ์เดิมเมื่อ `saved` เท่ากับหรือต่ำกว่า 0 ขณะที่ `compressToolResult()` เองยังคง
ส่งคืนเอาต์พุตของกลยุทธ์นั้น ขั้นตอนผลลัพธ์ของเครื่องมือไม่ใช่ขั้นตอนสุดท้าย:
ตัวสรุปสำรองของเอนจินยังสามารถย่อข้อความ `tool` หรือ `function` ที่ยาวกว่า
8,192 อักขระได้ (`maxTokensPerMessage` เท่ากับ 2,048 คูณ 4)

#### ควรใช้เมื่อใด

การบีบอัดผลลัพธ์ของเครื่องมือเป็นขั้นตอนที่ 1 ของเอนจินแบบเข้มข้น (`compressAggressive()` ใน
`open-sse/services/compression/aggressive.ts`) ดังนั้นจึงทำงานในโหมด Aggressive และใน
ขั้นตอน `aggressive` ของไปป์ไลน์แบบซ้อน โดยจะบีบอัดข้อความ `tool` และ `function`
ที่มีโครงสร้างแบบ OpenAI รวมถึงข้อความภายในบล็อก `tool_result` ของ Anthropic แต่ละกลยุทธ์มี
สวิตช์ของตัวเองภายใต้ `aggressive.toolStrategies` ซึ่งเปิดใช้งานทั้งหมดโดยค่าเริ่มต้น ในแดชบอร์ด
สวิตช์เหล่านี้อยู่ในมุมมอง **Advanced** ของหน้า Caveman เมื่อเปิดการบีบอัดและ
โหมดเริ่มต้นคือ Aggressive

### ไปป์ไลน์แบบซ้อน

โหมดแบบซ้อนจะเรียกใช้ **หลายเอนจินตามลำดับ** — โดยทั่วไปเริ่มจาก RTK ก่อน
(ประหยัดเอาต์พุตของเครื่องมือ 60-90%) แล้วจึงใช้ Caveman กับข้อความที่เหลือ (ประหยัดอินพุต
ประมาณ 46%) เมื่อรวมกันจะได้ **ช่วงที่เป็นไปได้ 78-95%** (ดู Upstream Savings Math
ด้านบน): `1 - (1 - 0.60..0.90) × (1 - 0.46)` มีค่าเฉลี่ย ≈89%

#### วิธีการทำงาน

```
อินพุต (1000 โทเค็น)
  → RTK (ตัวกรองที่เข้าใจคำสั่ง) → 200 โทเค็น
    → Caveman (นำคำฟุ่มเฟือยออก) → 108 โทเค็น
  → เอาต์พุต (108 โทเค็น, ประหยัด ~89%)
```

#### ควรใช้เมื่อใด

ใช้โหมดแบบซ้อนสำหรับ:

- เวิร์กโฟลว์ที่ใช้เครื่องมือจำนวนมาก (การเขียนโค้ดแบบเอเจนต์, การวิจัย)
- การประมวลผลแบบแบตช์ที่คำนึงถึงต้นทุน
- เมื่อคุณต้องการประหยัดโทเค็นให้ได้มากที่สุด

ไปป์ไลน์แบบซ้อนได้รับการกำหนดค่าผ่านการตั้งค่าการบีบอัดส่วนกลาง `stackedPipeline`
หรือผ่านคอมโบการบีบอัดที่ตั้งชื่อไว้และกำหนดให้กับคอมโบการกำหนดเส้นทาง (ดู
Per-Combo Override ด้านบน) — ไม่ใช่ผ่าน `modePack` ของ auto-combo (ฟิลด์นั้นเพียง
ปรับน้ำหนักการเลือกโมเดลของ auto-combo ใหม่ และ `stacked` ไม่ใช่ชื่อแพ็กที่ถูกต้อง)

---

## การกำหนดค่าทับสำหรับชุดคอมโบการบีบอัด

คุณสามารถกำหนดโหมดการบีบอัดส่วนกลางทับ **เป็นรายคอมโบ** เพื่อปรับแต่งลักษณะการทำงาน
ให้เหมาะสมกับกรณีการใช้งานต่างๆ:

```json
{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "weights": { "taskFit": 0.5 },
    "modePack": "quality-first"
  },
  "compressionOverride": "aggressive"
}
```

สิ่งนี้มีประโยชน์สำหรับ:

- **คอมโบการเขียนโค้ด**: ใช้โหมด `aggressive` สำหรับเซสชันที่ยาวนาน
- **คอมโบถาม-ตอบแบบรวดเร็ว**: ใช้โหมด `lite` เพื่อการตอบกลับที่รวดเร็ว
- **คอมโบที่ใช้เครื่องมือจำนวนมาก**: ใช้โหมด `stacked` เพื่อประหยัดสูงสุด
- **คอมโบสำหรับระบบใช้งานจริง**: ปิดการกำหนดค่าทับไว้สำหรับผู้ให้บริการที่รองรับการแคช — การปรับค่า
  โดยคำนึงถึงแคชซึ่งเปิดใช้งานอยู่เสมอ จะลดระดับ `aggressive`/`ultra` เป็น `standard` โดยอัตโนมัติ
  (ไม่มีโหมด `cache-aware` ที่สามารถเลือกได้)

---

## ดูเพิ่มเติม

- [การกำหนดค่าสภาพแวดล้อม](../reference/ENVIRONMENT.md) — ตัวแปรสภาพแวดล้อมสำหรับการบีบอัด
- [คู่มือสถาปัตยกรรม](../architecture/ARCHITECTURE.md) — รายละเอียดภายในของไปป์ไลน์การบีบอัด
- [คู่มือผู้ใช้](../guides/USER_GUIDE.md) — เริ่มต้นใช้งานการบีบอัด
- [การบีบอัด RTK](./RTK_COMPRESSION.md) — ตัวกรอง RTK, โมเดลความน่าเชื่อถือ, เกตการตรวจสอบ และการกู้คืนเอาต์พุตดิบ
- [เอนจินการบีบอัด](./COMPRESSION_ENGINES.md) — Caveman, RTK, stacked, API, MCP และแดชบอร์ด
- [รูปแบบกฎการบีบอัด](./COMPRESSION_RULES_FORMAT.md) — รูปแบบแพ็กกฎ JSON
- [แพ็กภาษาสำหรับการบีบอัด](./COMPRESSION_LANGUAGE_PACKS.md) — กฎ Caveman เฉพาะภาษา