OmniRoute/docs/i18n/th/docs/compression/RTK_COMPRESSION.md

RTK Compression (ไทย)

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

---

การบีบอัด RTK คือเอนจินบีบอัดที่รับรู้คำสั่งของ OmniRoute สำหรับเอาต์พุตจากเทอร์มินัลและเครื่องมือ โดย ออกแบบมาสำหรับเซสชันของเอเจนต์เขียนโค้ด ซึ่งการเพิ่มขึ้นของบริบทส่วนใหญ่มาจากบันทึกการทดสอบ เอาต์พุตการบิลด์ ข้อความรบกวนจากตัวจัดการแพ็กเกจ ทรานสคริปต์ของเชลล์ เอาต์พุต Docker เอาต์พุต git และสแต็กเทรซ

RTK สามารถทำงานโดยตรงด้วย defaultMode: "rtk" หรือเป็นขั้นตอนแรกในไปป์ไลน์แบบซ้อน ซึ่งโดยทั่วไปคือ:

rtk -> caveman

ลำดับนี้จะบีบอัดเอาต์พุตจากเครื่องที่มีข้อความรบกวนก่อน จากนั้นให้ Caveman ย่อร้อยแก้วที่เหลืออยู่

RTK ต้นทางรายงานว่าสามารถประหยัดเอาต์พุตคำสั่งได้ 60-90% เซสชันตัวอย่างใน README ลดจาก โทเค็นมาตรฐาน ~118,000 เหลือโทเค็น RTK ~23,900 ซึ่งประหยัดได้ 79.7% (~80%) OmniRoute ใช้ ค่าเฉลี่ยจากต้นทางดังกล่าวในการคำนวณการประหยัดแบบซ้อนร่วมกับการบีบอัดอินพุตของ Caveman:

ค่าเฉลี่ย RTK:       ประหยัด 80%
อินพุต Caveman:      ประหยัด 46%
แบบซ้อน:             1 - (1 - 0.80) * (1 - 0.46) = ประหยัด 89.2%
ช่วง:                1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

สิ่งที่บีบอัด

ปัจจุบันแค็ตตาล็อกในตัวมาพร้อมตัวกรอง 49 รายการในหมวดหมู่เหล่านี้:

หมวดหมู่	ตัวอย่าง
git	git status, git branch, git diff, git log
test	Vitest, Jest, Pytest, Playwright, การทดสอบ Go, การทดสอบ Cargo
build	TypeScript, ESLint, Biome, Prettier, Vite, Webpack, Turbo, Nx
package	npm install, npm audit, pip, uv sync, Poetry, Bundler
shell	ls, find, grep, บันทึกเชลล์ทั่วไป
docker	docker ps, บันทึก Docker
infra	Terraform, OpenTofu, systemctl status
generic	เอาต์พุต JSON, สแต็กเทรซ, ตัวเลือกสำรองสำหรับเอาต์พุตทั่วไป

ตัวตรวจจับใน open-sse/services/compression/engines/rtk/commandDetector.ts จะจำแนกเอาต์พุต ก่อนเลือกตัวกรอง นอกจากนี้ ตัวกรองยังสามารถจับคู่ตามรูปแบบคำสั่งหรือ regex ของเอาต์พุตได้ เมื่อคลาสคำสั่ง เพียงอย่างเดียวไม่เพียงพอ

การเลือกตัวกรอง

RTK โหลดตัวกรองตามลำดับนี้:

1. ตัวกรองโปรเจกต์จาก .rtk/filters.toml และ .rtk/filters.json เฉพาะเมื่อได้รับความไว้วางใจ
2. ตัวกรองส่วนกลางจาก DATA_DIR/rtk/filters.toml และ DATA_DIR/rtk/filters.json
3. ตัวกรองในตัวจาก open-sse/services/compression/engines/rtk/filters/

ภายในขอบเขตเดียวกัน ตัวกรอง TOML schema v1 ของ RTK จะมีลำดับความสำคัญเหนือตัวกรอง JSON ของ OmniRoute นิพจน์ match_command ของ TOML จะได้รับการตรวจสอบก่อนการจับคู่ประเภทคำสั่ง เพื่อให้ตัวกรองเฉพาะคำสั่งที่นำเข้าสามารถ แทนที่ตัวกรองที่กว้างกว่าในขอบเขตนั้นได้ ขอบเขตโปรเจกต์ยังคงมีลำดับความสำคัญเหนือขอบเขตส่วนกลาง โดยไม่ขึ้นกับรูปแบบไฟล์

ตัวกรองโปรเจกต์ถูกควบคุมด้วยความไว้วางใจโดยเจตนา เนื่องจากตัวกรอง regex สามารถเปลี่ยนวิธีแสดงเอาต์พุตของเครื่องมือ ต่อเอเจนต์ได้ ไฟล์ตัวกรองโปรเจกต์จะได้รับการยอมรับเมื่อเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้เป็นจริง:

• rtkConfig.trustProjectFilters เป็น true
• มีการตั้งค่า OMNIROUTE_RTK_TRUST_PROJECT_FILTERS=1
• .rtk/trust.json มีแฮช SHA-256 ที่ตรงกับไฟล์ตัวกรองโปรเจกต์

ตัวอย่างไฟล์ความไว้วางใจ:

{
  "filtersSha256": "0123456789abcdef...",
  "filtersTomlSha256": "fedcba9876543210..."
}

แฮชเหล่านี้แยกจากกัน: filtersSha256 ให้ความไว้วางใจแก่ .rtk/filters.json ขณะที่ filtersTomlSha256 ให้ความไว้วางใจแก่ .rtk/filters.toml การแก้ไขไฟล์ใดไฟล์หนึ่งจะทำให้เฉพาะรายการความไว้วางใจของไฟล์นั้นใช้ไม่ได้ ไฟล์ส่วนกลาง ติดตั้งโดยผู้ดูแลระบบและใช้ลักษณะการทำงานด้านความไว้วางใจของตัวกรองส่วนกลางที่มีอยู่

ตัวกรองแบบกำหนดเองสามารถเป็นออบเจ็กต์ตัวกรองหนึ่งรายการหรืออาร์เรย์ของออบเจ็กต์ตัวกรองได้ ตัวกรองแบบกำหนดเองที่ไม่ถูกต้องจะถูก ข้ามและรายงานโดยการวินิจฉัยของ /api/context/rtk/filters ส่วนตัวกรองในตัวที่ไม่ถูกต้องจะทำให้ระบบล้มเหลวทันที

ความเข้ากันได้กับ RTK TOML schema v1

OmniRoute สามารถแยกวิเคราะห์ ตรวจสอบความถูกต้อง ทดสอบ และติดตั้งไฟล์ตัวกรองแบบประกาศที่ใช้ RTK TOML schema v1 ได้ ฟิลด์ที่รองรับได้แก่ description, match_command, strip_ansi, filter_stderr, strip_lines_matching, keep_lines_matching, replace, match_output, truncate_lines_at, head_lines, tail_lines, max_lines, on_empty และการทดสอบแบบอินไลน์ [[tests.<filter>]] ระบบจะปฏิเสธฟิลด์ที่ไม่รู้จัก นิพจน์ทั่วไปที่ไม่ถูกต้องหรือไม่ปลอดภัย การใช้กฎ strip/keep พร้อมกัน ไฟล์ที่มีขนาดเกิน 1 MiB และการอ้างอิงถึงตัวกรองที่ไม่รู้จัก ไฟล์ที่การทดสอบแบบอินไลน์ไม่ผ่านยังสามารถรับการตรวจสอบความถูกต้องเพื่อการตรวจสอบไฟล์ได้ แต่ไม่สามารถติดตั้งหรือโหลดได้ ความล้มเหลวในการโหลดไฟล์แบบกำหนดเองยังคงทำงานแบบ fail-open กล่าวคือ ระบบจะข้ามไฟล์ที่ไม่ถูกต้อง และตัวกรองที่เหลือจะยังคงทำงานต่อไป

OmniRoute รับเอาต์พุตของเครื่องมือหลังจากที่ไคลเอนต์บันทึกเอาต์พุตไว้แล้ว ดังนั้น filter_stderr = true จึงไม่สามารถเปลี่ยนแปลงการบันทึกเอาต์พุตของกระบวนการได้ ฟิลด์นี้ได้รับการยอมรับในฐานะ no-op และการตรวจสอบความถูกต้องจะส่งคำเตือนกลับมา ลักษณะการทำงานนี้จงใจอธิบายว่าเป็น ความเข้ากันได้กับ RTK TOML schema v1 ไม่ใช่ความเข้ากันได้อย่างสมบูรณ์ กับไฟล์ปฏิบัติการ RTK, shell hooks, การใช้งานคำสั่งด้วย Rust หรือโครงสร้าง trust-store ของ RTK

มุมมอง RTK ขั้นสูงของแดชบอร์ดรองรับ TOML ที่วางหรืออัปโหลด การตรวจสอบความถูกต้องเป็นแบบอ่านอย่างเดียว การติดตั้งจะเขียน DATA_DIR/rtk/filters.toml แบบอะตอมมิกโดยใช้สิทธิ์การเข้าถึงที่เข้มงวด และรีเฟรช แค็ตตาล็อกตัวกรองที่กำลังใช้งานโดยไม่ต้องรีสตาร์ต การแทนที่ไฟล์ที่มีอยู่ต้องมีการยืนยัน overwrite อย่างชัดเจน และจะสร้าง DATA_DIR/rtk/filters.toml.bak ก่อน

DSL ของตัวกรอง

ตัวกรองใช้สคีมา JSON ที่อธิบายไว้ใน รูปแบบกฎการบีบอัด รันไทม์จะดำเนินการตามขั้นตอนเหล่านี้ตามลำดับ:

stripAnsi -> filterStderr -> replace -> matchOutput -> ตัดทิ้ง/รวมบรรทัด
  -> truncateLineAt -> head/tail/maxLines -> onEmpty

ฟิลด์สำคัญ:

ฟิลด์	วัตถุประสงค์
rules.stripAnsi	ลบลำดับสี/การควบคุมของเทอร์มินัลก่อนการจับคู่
rules.filterStderr	ปรับคำนำหน้า stderr ทั่วไปให้อยู่ในรูปแบบมาตรฐานก่อนการจับคู่/กรอง
rules.replace	ใช้การแทนที่ด้วยนิพจน์ทั่วไปตามลำดับ
rules.matchOutput	ส่งคืนสรุปแบบกระชับเมื่อเอาต์พุตตรงกับเงื่อนไขที่รู้จัก
rules.matchOutput[].unless	ข้ามทางลัดเมื่อมีรูปแบบข้อผิดพลาด/ความล้มเหลวปรากฏอยู่
rules.dropPatterns	ลบบรรทัดรบกวน
rules.includePatterns	ให้ความสำคัญกับบรรทัดที่นำไปดำเนินการต่อได้
rules.collapsePatterns	ยุบบรรทัดที่ตรงกันและซ้ำกัน
rules.deduplicate	เปิดใช้แยกตามตัวกรอง: ยุบบรรทัดซ้ำที่อยู่ติดกัน
rules.truncateLineAt	ตัดทอนแต่ละบรรทัดอย่างปลอดภัยสำหรับ Unicode
rules.onEmpty	ข้อความสำรองหากทุกบรรทัดถูกกรองออก
tests[]	ตัวอย่างแบบอินไลน์ที่ใช้โดยเกตการตรวจสอบ

ตัวกรองในตัวควรมีตัวอย่าง tests[] แบบอินไลน์ ตัวกรองแบบกำหนดเองก็ควรมี เช่นกัน โดยเฉพาะเมื่อมีการใช้ร่วมกันระหว่างหลายโปรเจกต์

การขจัดบรรทัดซ้ำ (สองชั้น)

RTK ยุบบรรทัดซ้ำในสองชั้นที่เป็นอิสระต่อกัน:

1. deduplicate ต่อฟิลเตอร์ (ต้องเลือกเปิดใช้ ค่าเริ่มต้นคือ false) ฟิลเตอร์สามารถกำหนด rules.deduplicate: true เพื่อยุบบรรทัดซ้ำที่อยู่ติดกัน ภายในเอาต์พุตที่ตรงกับฟิลเตอร์นั้น ก่อนการตัดทอน กระบวนการนี้ทำงานภายใน lineFilter.ts สำหรับฟิลเตอร์แบบเดิม ระบบจะเปิดใช้โดยอัตโนมัติเมื่อฟิลเตอร์กำหนด collapsePatterns สคีมา: deduplicate: z.boolean().default(false) ใน open-sse/services/compression/engines/rtk/filterSchema.ts
2. deduplicateThreshold ระดับเอนจิน (ค่าเริ่มต้นคือ 3) หลังจากฟิลเตอร์ทั้งหมดทำงานแล้ว เอนจินจะยุบ ชุดบรรทัดที่เหมือนกันและอยู่ติดกันซึ่งมีจำนวน >= deduplicateThreshold ทั่วทั้งผลลัพธ์ (deduplicateRepeatedLines ซึ่งนำไปใช้ใน engines/rtk/index.ts) ค่าจะถูกจำกัดให้อยู่ในช่วง 2–100 ระหว่างการปรับค่าให้เป็นมาตรฐาน

ขั้นตอนต่อฟิลเตอร์จะทำงานก่อน (ภายในฟิลเตอร์) และขั้นตอนระดับเอนจินจะทำงานเป็นลำดับสุดท้าย (กับเอาต์พุตที่รวมแล้ว) ดังนั้นทั้งสองจึงทำงานร่วมกันได้โดยไม่เกิดการนับซ้ำ

การจัดกลุ่มบรรทัด (enableGrouping)

เมื่อ rtkConfig.enableGrouping เป็น true (ค่าเริ่มต้นคือ false) RTK จะเรียกใช้ขั้นตอน groupSimilarLines เพิ่มเติมกับผลลัพธ์หลังการขจัดรายการซ้ำ เพื่อยุบชุดบรรทัดที่อยู่ติดกันและ เกือบเทียบเท่ากัน (ไม่จำเป็นต้องเหมือนกันทุกไบต์) rtkConfig.groupingThreshold (ค่าเริ่มต้นคือ 3) คือความยาวขั้นต่ำของชุดบรรทัดที่จะเริ่มการจัดกลุ่ม นี่คือกลไกเชิงโครงสร้างที่ทำงานคู่กับ deduplicateThreshold: การขจัดรายการซ้ำจัดการกับบรรทัดที่ซ้ำกันทุกประการ ส่วนการจัดกลุ่มจัดการกับบรรทัดที่มี "รูปแบบเดียวกันแต่แตกต่างกันเล็กน้อย" แฟล็กทั้งสองเป็นส่วนหนึ่งของ JSON rtkConfig ที่จัดเก็บถาวรในตาราง key_value (ดูการกำหนดค่าด้านบน) ดังนั้นการตั้งค่าจึงยังคงอยู่หลังการรีสตาร์ต

การลบความคิดเห็นออกจากโค้ด (stripCodeComments / preserveDocstrings)

เมื่อเปิดใช้ rtkConfig.applyToCodeBlocks แล้ว RTK ยังสามารถลบความคิดเห็นออกจากบล็อกโค้ดที่มีรั้วล้อมได้ด้วย:

• stripCodeComments (ค่าเริ่มต้นคือ false) — ต้องเลือกเปิดใช้ เมื่อเป็น true RTK จะลบความคิดเห็นออกจาก บล็อก JavaScript และ TypeScript ที่มีรั้วล้อม ในอดีต แฟล็กนี้ถูกอ่านค่าแต่ไม่เคยนำไปใช้ ดังนั้นค่าเริ่มต้นจึงยังคงเป็น "เก็บรักษาไว้" เพื่อหลีกเลี่ยงการเปลี่ยนแปลงในระบบที่ใช้งานจริงโดยไม่แจ้งให้ทราบ
• preserveDocstrings (ค่าเริ่มต้นคือ true) — เมื่อลบความคิดเห็น ความคิดเห็นแบบบล็อก JSDoc//** … */ จะถูก เก็บไว้ (เนื่องจากมีเอกสารประกอบ API ที่มีคุณค่ามากกว่าจำนวนไบต์ที่ใช้) กำหนดเป็น false เพื่อลบ ความคิดเห็นเหล่านั้นด้วย

การลบความคิดเห็นถูกนำไปใช้ใน open-sse/services/compression/engines/rtk/codeStripper.ts โดยใช้ ตัวแยกวิเคราะห์ TypeScript (ไม่ใช่นิพจน์ทั่วไป) เพื่อไม่ให้ลิเทอรัลชนิดสตริง เทมเพลต และนิพจน์ทั่วไป ถูกเข้าใจผิดว่าเป็นความคิดเห็น และจะยกเลิกการทำงานทั้งหมดเมื่อตรวจพบ JSX (เพื่อไม่ให้ความคิดเห็นในคอนเทนเนอร์นิพจน์ JSX เสียหาย) ปัจจุบัน การลบความคิดเห็นใช้กับ JavaScript และ TypeScript เท่านั้น — ภาษาอื่นๆ ในชุด CodeLanguage ของตัวลบ (Python, Rust, Go, Ruby, Java) จะมีการยุบช่องว่างและบรรทัดว่าง แต่ไม่มีการลบความคิดเห็น การประมวลผลบล็อกที่ถูกลบความคิดเห็นจะมีแท็ก rtk:code-strip ใน rulesApplied

หมายเหตุ — GCF / การเข้ารหัสแบบตารางเป็นเอนจินแยกต่างหาก RTK ไม่มี ตัวเข้ารหัส JSON แบบตาราง/แบบคอลัมน์ "GCF" (Graph Compact Format) ตัวเข้ารหัสดังกล่าว — ซึ่งมาแทนที่ตัวเข้ารหัส omni-tabular รุ่นเก่า — อยู่ในเอนจิน headroom (open-sse/services/compression/engines/headroom/ โดยมีโคเดกที่รวมไว้ภายใต้ headroom/gcf/) และไม่เกี่ยวข้องกับไปป์ไลน์ฟิลเตอร์ RTK ที่อธิบายไว้ที่นี่

การกำหนดค่า

การตั้งค่าส่วนกลางพร้อมใช้งานผ่าน /api/settings/compression และการตั้งค่าเฉพาะ RTK ก็พร้อมใช้งานผ่าน /api/context/rtk/config เช่นกัน

{
  "defaultMode": "stacked",
  "autoTriggerMode": "stacked",
  "autoTriggerTokens": 32000,
  "stackedPipeline": [
    { "engine": "rtk", "intensity": "standard" },
    { "engine": "caveman", "intensity": "full" }
  ],
  "rtkConfig": {
    "enabled": true,
    "intensity": "standard",
    "applyToToolResults": true,
    "applyToCodeBlocks": false,
    "applyToAssistantMessages": false,
    "enabledFilters": [],
    "disabledFilters": [],
    "maxLinesPerResult": 120,
    "maxCharsPerResult": 12000,
    "deduplicateThreshold": 3,
    "customFiltersEnabled": true,
    "trustProjectFilters": false,
    "rawOutputRetention": "never",
    "rawOutputMaxBytes": 1048576,
    "enableGrouping": false,
    "groupingThreshold": 3,
    "stripCodeComments": false,
    "preserveDocstrings": true
  }
}

enabledFilters และ disabledFilters ใช้รหัสตัวกรอง เช่น test-vitest หรือ git-diff

รูปแบบ rtkConfig ทั้งหมดถูกกำหนดโดย RtkConfig / DEFAULT_RTK_CONFIG ใน open-sse/services/compression/types.ts อ็อบเจ็กต์ทั้งหมดจะถูกจัดเก็บถาวรเป็นค่า JSON เดียวใน ตาราง SQLite key_value ภายใต้ namespace = "compression", key = "rtkConfig" (src/lib/db/compression.ts) และถูกปรับให้อยู่ในรูปแบบมาตรฐานเมื่ออ่านโดย normalizeRtkConfig ดังนั้นทุกฟิลด์ด้านล่าง — รวมถึง enableGrouping, groupingThreshold, stripCodeComments และ preserveDocstrings — จะผ่านการจัดเก็บเดียวกันแบบไป-กลับและยังคงอยู่หลังการรีสตาร์ต

คีย์	ค่าเริ่มต้น	วัตถุประสงค์
deduplicateThreshold	3	ทั้งเอนจิน: จำนวนบรรทัดที่เหมือนกันต่อเนื่องขั้นต่ำที่จะยุบรวม (จำกัดที่ 2–100)
enableGrouping	false	เปิดใช้โดยสมัครใจ: ยุบชุดบรรทัดต่อเนื่องที่เกือบเทียบเท่ากัน
groupingThreshold	3	จำนวนบรรทัดคล้ายกันต่อเนื่องขั้นต่ำที่จะเรียกใช้การจัดกลุ่ม
stripCodeComments	false	เปิดใช้โดยสมัครใจ: ลบความคิดเห็นออกจากบล็อกโค้ดแบบมีรั้ว (ต้องใช้ applyToCodeBlocks)
preserveDocstrings	true	เมื่อลบความคิดเห็น ให้คงบล็อก JSDoc//** … */ ไว้

API

เส้นทาง	เมธอด	วัตถุประสงค์
/api/context/rtk/config	GET	อ่านการกำหนดค่า RTK
/api/context/rtk/config	PUT	อัปเดตการกำหนดค่า RTK
/api/context/rtk/filters	GET	แสดงรายการแค็ตตาล็อกตัวกรองและการวินิจฉัยการโหลด
/api/context/rtk/import	POST	ตรวจสอบหรือติดตั้งไฟล์สคีมา RTK TOML v1
/api/context/rtk/test	POST	แสดงตัวอย่างการบีบอัด RTK สำหรับเพย์โหลดข้อความหนึ่งรายการ
/api/context/rtk/raw-output/[id]	GET	อ่านเอาต์พุตดิบที่ผ่านการปกปิดข้อมูลและเก็บรักษาไว้
/api/compression/preview	POST	แสดงตัวอย่างโหมดการบีบอัดใดๆ

เพย์โหลดทดสอบ RTK:

{
  "command": "npm test",
  "text": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed",
  "config": {
    "intensity": "standard"
  }
}

เพย์โหลดแสดงตัวอย่างการบีบอัด:

{
  "mode": "stacked",
  "messages": [
    {
      "role": "tool",
      "content": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed"
    }
  ],
  "config": {
    "rtkConfig": {
      "rawOutputRetention": "failures"
    }
  }
}

เส้นทางการจัดการต้องใช้การยืนยันตัวตนสำหรับการจัดการแดชบอร์ด หรือนโยบาย API key ที่ตรงกัน

เพย์โหลดตรวจสอบความถูกต้องของ RTK TOML:

{
  "action": "validate",
  "content": "schema_version = 1\n\n[filters.my-tool]\nmatch_command = \"^my-tool\\\\b\"\nmax_lines = 20\n"
}

ใช้ "action": "install" เพื่อติดตั้งไฟล์ที่ผ่านการตรวจสอบแล้วแบบส่วนกลาง เพิ่ม "overwrite": true เฉพาะ หลังจากตรวจทานและยืนยันการแทนที่ไฟล์ส่วนกลางที่มีอยู่แล้วเท่านั้น

การกู้คืนเอาต์พุตดิบ

โดยปกติ RTK จะส่งคืนเฉพาะข้อความที่บีบอัดแล้ว สำหรับการดีบัก rawOutputRetention สามารถเก็บเอาต์พุตดิบที่ผ่านการปกปิดข้อมูลสำคัญแล้วได้:

ค่า	ลักษณะการทำงาน
never	ไม่เก็บเอาต์พุตดิบ
failures	เก็บเฉพาะเอาต์พุตที่มีแนวโน้มว่าเป็นความล้มเหลว
always	เก็บเอาต์พุตดิบของ RTK ที่บีบอัดแล้วทุกรายการ หลังจากปกปิดข้อมูลสำคัญ

ไฟล์ที่เก็บไว้จะถูกเขียนลงใน:

DATA_DIR/rtk/raw-output/

ข้อมูลลับจะถูกปกปิดก่อนบันทึกถาวร รวมถึง bearer token ที่พบบ่อย, API key, Slack token, AWS access key และค่าในรูปแบบการกำหนดค่า เช่น token=..., secret=..., password=... ส่วนระบบวิเคราะห์ จะจัดเก็บเฉพาะ ID ตัวชี้ ขนาด และข้อมูลเมตาของแฮชเท่านั้น

เกตตรวจสอบ

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

node --import tsx/esm --test tests/unit/compression/rtk-verify.test.ts

เกต RTK ที่ครอบคลุมมากขึ้นคือ:

node --import tsx/esm --test \
  tests/unit/compression/rtk-*.test.ts \
  tests/unit/compression/pipeline-integration.test.ts \
  tests/unit/compression/context-compression-api.test.ts

เรียกใช้เกตการบีบอัดแบบครอบคลุมก่อนเผยแพร่:

node --import tsx/esm --test \
  tests/unit/compression/*.test.ts \
  tests/golden-set/*.test.ts \
  tests/integration/compression-pipeline.test.ts \
  tests/unit/api/compression/compression-api.test.ts

การขยายความสามารถของ RTK

1. เพิ่มหรืออัปเดตไฟล์ JSON ของตัวกรอง
2. ใส่ตัวอย่าง tests[] อย่างน้อยหนึ่งรายการที่พิสูจน์ลักษณะการทำงานสำคัญ
3. เพิ่มฟิกซ์เจอร์ไว้ใต้ tests/unit/compression/fixtures/rtk/ สำหรับกลุ่มคำสั่งใหม่
4. เพิ่มความครอบคลุมในการตรวจจับคำสั่งเมื่อเพิ่มคลาสเอาต์พุตใหม่
5. เรียกใช้เกตตรวจสอบและเกต RTK แบบครอบคลุม
6. หากตัวกรองใช้เฉพาะภายในโปรเจกต์ ให้คอมมิต .rtk/filters.json และรีเฟรช .rtk/trust.json หลังผ่านการตรวจทานแล้วเท่านั้น

---

ระดับความเข้มข้น (v3.8.16+)

RTK รองรับ ระดับความเข้มข้น 3 ระดับ ซึ่งสร้างสมดุลระหว่าง ความเข้มงวดในการบีบอัด และ ความปลอดภัย โดยกำหนดระดับผ่าน config.intensity ในการกำหนดค่าเอนจิน

ทั้ง 3 ระดับ

ระดับ	เกณฑ์การตัดทอน	การประหยัดโทเค็น	ความเสี่ยง	เหมาะที่สุดสำหรับ
minimal	24 บรรทัดต่อส่วน	~20-40%	ต่ำมาก	งานโปรดักชันที่มีบริบทสำคัญ
standard (ค่าเริ่มต้น)	24 บรรทัดต่อส่วน	~50-70%	ต่ำ	เซสชันเขียนโค้ดประจำวัน
aggressive	16 บรรทัดต่อส่วน	~70-90%	ปานกลาง	เซสชันยาวที่ต้องการประหยัดสูงสุด

ตำแหน่งที่เกิดการตัดทอน

เกณฑ์การตัดทอนมีผลต่อ lineFilter.ts:

// จาก open-sse/services/compression/engines/rtk/index.ts:329-330
config.intensity === "aggressive" ? 16 : 24,
config.intensity === "aggressive" ? 16 : 24,

ระบบจะเก็บทั้ง ส่วนต้น และ ส่วนท้าย ของแต่ละส่วนไว้ ส่วนเนื้อหาตรงกลางจะถูกตัดออกเมื่อเริ่มใช้การตัดทอน

สิ่งที่คงไว้เทียบกับสิ่งที่ถูกตัด

เนื้อหา	minimal	standard	aggressive
ข้อผิดพลาด / สแตกเทรซ	✅ คงไว้	✅ คงไว้	✅ คงไว้
การทดสอบที่ล้มเหลว	✅ คงไว้	✅ คงไว้	✅ คงไว้
ข้อผิดพลาดในการบิลด์	✅ คงไว้	✅ คงไว้	✅ คงไว้
การทดสอบที่ผ่าน (แบบละเอียด)	✅ คงไว้	🟡 ยุบรวม	🟡 ยุบรวม
เอาต์พุตทั่วไป (บันทึกข้อมูล)	🟡 ยุบรวม	🟡 ยุบรวม	❌ ตัดออก
แถบความคืบหน้า	🟡 ยุบรวม	❌ ตัดออก	❌ ตัดออก
แบนเนอร์ / ศิลปะ ASCII	🟡 ยุบรวม	❌ ตัดออก	❌ ตัดออก

การเลือกระดับความเข้มข้นที่เหมาะสม

                  การสูญเสียบริบทจะสร้างความเสียหายร้ายแรงหรือไม่?
                  │
      ┌───────────┼───────────┐
      │           │           │
     ใช่         ไม่ใช่       ไม่แน่ใจ
      │           │           │
      ▼           │           │
   minimal        │           │
      │           │           │
      │           ▼           ▼
      │      ปริมาณงานสำคัญ   ลองใช้ `standard` ก่อน
      │      เพียงใด?         (ใช้ได้กับ 80% ของ
      │           │          กรณีทั้งหมด)
      │      ┌────┴────┐
      │      │         │
      │     ต่ำ        สูง
      │      │         │
      │      ▼         ▼
      │   standard   aggressive
      │      │         │
      └──────┴─────────┘

การกำหนดค่าความเข้มข้น

ต่อคอมโบ (ในการกำหนดค่าคอมโบ):

{
  "combo": "my-coding-combo",
  "routing": {/* ... */},
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive"
  }
}

ผ่านโปรแกรม:

rtkEngine (@omniroute/open-sse/services/compression/engines/rtk) เป็น CompressionEngine และไม่มีเมธอด updateConfig ให้อัปเดตการกำหนดค่าของเอนจิน ผ่านตัวช่วยรีจิสทรีแทน:

import { updateEngineConfig } from "@omniroute/open-sse/services/compression/engines/registry";

updateEngineConfig("rtk", { intensity: "aggressive" });

การตรวจสอบผลลัพธ์

ใช้ เกตตรวจสอบ (ดูด้านล่าง) เพื่อยืนยันว่าตัวกรองของคุณปลอดภัยเมื่อใช้ระดับความเข้มข้นที่เลือก:

import { runRtkFilterTests } from "omniroute/compression/engines/rtk/verify";

const result = runRtkFilterTests({ intensity: "aggressive" });
if (!result.passed) {
  console.error("ตัวกรองล้มเหลวที่ระดับความเข้มข้น aggressive");
}

---

การพัฒนาตัวกรองแบบกำหนดเอง (v3.8.16+)

ไดเรกทอรี engines/rtk/filters/ มี ไฟล์ JSON ของตัวกรองในตัวมากกว่า 49 รายการ คุณสามารถเพิ่มตัวกรองของคุณเองเพื่อบีบอัดเอาต์พุตจากเครื่องมือแบบกำหนดเองที่ค่าเริ่มต้นยังไม่รองรับ

สคีมาของตัวกรอง (Zod)

{
  "id": "string",                      // จำเป็น ตัวระบุตัวกรอง (รูปแบบ kebab-case เช่น "python-traceback")
  "label": "string",                   // จำเป็น ชื่อตัวกรองที่มนุษย์อ่านเข้าใจได้
  "description": "string",             // ไม่บังคับ (ค่าเริ่มต้น: "") คำอธิบายสั้น ๆ ว่าตัวกรองทำอะไร
  "category": "git|test|build|shell|docker|package|infra|cloud|generic",
  "priority": number,                  // ไม่บังคับ (0-100, ค่าเริ่มต้น: 50) ลำดับการทำงาน (ค่ายิ่งสูงยิ่งทำงานก่อน)
  "match": {
    "commands": ["string"],            // ชื่อคำสั่งที่ต้องการจับคู่ (เช่น "python", "pytest")
    "patterns": ["string"],            // รูปแบบ Regex สำหรับจับคู่เอาต์พุต
    "outputTypes": ["string"]          // คลาสของเอาต์พุตที่ตรวจพบ (เช่น "test-failure")
  },
  "rules": {
    "stripAnsi": boolean,              // ไม่บังคับ (ค่าเริ่มต้น: false) ลบรหัสสี ANSI
    "replace": [                       // กฎการค้นหาและแทนที่ (ค่าเริ่มต้น: [])
      { "pattern": "regex", "replacement": "..." }
    ],
    "matchOutput": [                   // หยุดการประมวลผลทันทีเมื่อรูปแบบตรงกัน (ค่าเริ่มต้น: [])
      {
        "pattern": "regex",
        "message": "short summary",
        "unless": "regex"              // ข้ามหากรูปแบบนี้ตรงกัน
      }
    ],
    "includePatterns": ["string"],     // บรรทัดที่ต้องการเก็บไว้ (รูปแบบ Regex, ค่าเริ่มต้น: [])
    "dropPatterns": ["string"],        // บรรทัดที่ต้องการตัดทิ้ง (รูปแบบ Regex, ค่าเริ่มต้น: [])
    "collapsePatterns": ["string"],    // บรรทัดที่ต้องการยุบให้เหลือเพียงหนึ่งรายการ (ค่าเริ่มต้น: [])
    "deduplicate": boolean,            // ไม่บังคับ (ค่าเริ่มต้น: false) ลบบรรทัดที่ซ้ำกัน
    "truncateLineAt": number,          // ไม่บังคับ (ค่าเริ่มต้น: 0) ตัดทอนบรรทัดให้มีจำนวนอักขระไม่เกินค่าสูงสุด
    "maxLines": number,                // ไม่บังคับ (ค่าเริ่มต้น: 0) จำกัดจำนวนบรรทัดทั้งหมดแบบตายตัว
    "headLines": number,               // ไม่บังคับ (ค่าเริ่มต้น: 20) เก็บ N บรรทัดแรกของเอาต์พุตที่ตรงกัน
    "tailLines": number,               // ไม่บังคับ (ค่าเริ่มต้น: 20) เก็บ N บรรทัดสุดท้ายของเอาต์พุตที่ตรงกัน
    "onEmpty": "string",               // ไม่บังคับ (ค่าเริ่มต้น: "") ข้อความสำรองหากทุกบรรทัดถูกกรองออก
    "filterStderr": boolean            // ไม่บังคับ (ค่าเริ่มต้น: false) กรองเอาต์พุต stderr ด้วย
  },
  "preserve": {
    "errorPatterns": ["string"],       // รูปแบบที่ต้องเก็บรักษาไว้เสมอ (ค่าเริ่มต้น: [])
    "summaryPatterns": ["string"]      // รูปแบบสำหรับบรรทัดสรุปสุดท้าย (ค่าเริ่มต้น: [])
  },
  "tests": [                           // การทดสอบแบบอินไลน์สำหรับการตรวจสอบยืนยัน (ค่าเริ่มต้น: [])
    {
      "name": "string",               // จำเป็น ชื่อการทดสอบ
      "input": "sample output",        // จำเป็น ข้อความอินพุตตัวอย่าง
      "expected": "expected output",   // จำเป็น เอาต์พุตที่บีบอัดแล้วซึ่งคาดหวัง
      "command": "optional command"    // ไม่บังคับ บริบทของคำสั่ง
    }
  ]
}

ตัวอย่าง: ตัวกรอง Python Traceback

{
  "id": "python-traceback",
  "label": "Python Traceback Filter",
  "description": "Compresses Python tracebacks to essential file/line locations and error type",
  "category": "test",
  "priority": 60,
  "match": {
    "commands": ["python", "python3", "pytest", "uv", "poetry"],
    "patterns": ["Traceback \\(most recent call last\\)", "Error", "Exception"],
    "outputTypes": ["error-traceback"]
  },
  "rules": {
    "stripAnsi": true,
    "includePatterns": [
      "Traceback \\(most recent call last\\)",
      "^\\s*File \".+\", line \\d+",
      "^\\s*[A-Z][a-zA-Z]+Error:",
      "^\\s*[A-Z][a-zA-Z]+Exception"
    ],
    "dropPatterns": ["site-packages/", "^\\s+[a-z_]+\\([^)]*\\)$"],
    "headLines": 5,
    "tailLines": 3,
    "maxLines": 25,
    "filterStderr": true
  },
  "preserve": {
    "errorPatterns": ["Error:", "Exception:", "Traceback"],
    "summaryPatterns": ["^[A-Z][a-zA-Z]+(?:Error|Exception):"]
  },
  "tests": [
    {
      "name": "preserves-error-type-and-location",
      "input": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n    do_thing()\n  File \"lib/utils.py\", line 17, in helper\n    return 1 / 0\nZeroDivisionError: division by zero",
      "expected": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n  File \"lib/utils.py\", line 17, in helper\nZeroDivisionError: division by zero",
      "command": "python app.py"
    }
  ]
}

การโหลดตัวกรองแบบกำหนดเอง

วางไฟล์ไว้ในตำแหน่งที่ระบบรู้จัก:

~/.omniroute/rtk/filters/my-filter.json     # ระดับผู้ใช้
<project>/.rtk/filters/my-filter.json      # ระดับโปรเจกต์

ตัวกรองจะถูกโหลดโดยอัตโนมัติเมื่อเริ่มต้นระบบผ่าน loadRtkFilters() ใน open-sse/services/compression/engines/rtk/filterLoader.ts ตัวโหลดจะค้นหาตัวกรองจาก:

• แค็ตตาล็อกในตัว: open-sse/services/compression/engines/rtk/filters/
• ไดเรกทอรีของผู้ใช้: ~/.omniroute/rtk/filters/
• ไดเรกทอรีของโปรเจกต์: <project>/.rtk/filters/

หากต้องการโหลดตัวกรองด้วยโปรแกรม:

import { loadRtkFilters } from "@omniroute/open-sse/services/compression/engines/rtk/filterLoader";

// ตัวเลือก: customFiltersEnabled (โหลดตัวกรองของผู้ใช้/โปรเจกต์ โดยเปิดไว้เป็นค่าเริ่มต้น),
// trustProjectFilters, refresh
const filters = loadRtkFilters({ customFiltersEnabled: true });

การตรวจสอบความถูกต้อง

ตัวกรองจะได้รับการตรวจสอบกับสคีมา Zod ขณะโหลด ตัวกรองที่มีโครงสร้างไม่ถูกต้องจะโหลดไม่สำเร็จและบันทึกข้อผิดพลาด:

RTK_FILTER_LOADER: filter "my-filter" failed validation:
  - rules.replace.0.pattern: Invalid regex
  - match.commands: must not be empty

หากต้องการตรวจสอบตัวกรองที่ติดตั้งไว้ทั้งหมด ให้เรียก runRtkFilterTests() ซึ่งส่งออกมาจาก open-sse/services/compression/engines/rtk/verify.ts

แนวทางปฏิบัติที่ดี

1. ใส่ tests[] เสมอ — การทดสอบเหล่านี้พิสูจน์ว่าตัวกรองของคุณทำงานได้ และช่วยป้องกันการถดถอย
2. ใช้ matchOutput สำหรับการลัดขั้นตอน — หากบรรทัดเดียวอธิบายเรื่องราวทั้งหมดได้ ให้ใช้บรรทัดนั้นแทนทั้งบล็อก
3. เลือกใช้ keep แทน strip — กฎ "เก็บรักษาไว้เสมอ" ที่ระบุอย่างชัดเจนปลอดภัยกว่ากฎ "ลบออกเสมอ"
4. ทดสอบที่ระดับความเข้มข้นทั้ง 3 ระดับ — minimal ไม่ควรทำอะไรเลย ส่วน aggressive ยังคงต้องเก็บรักษาข้อผิดพลาดไว้
5. ใช้ฟิลด์ unless — ป้องกันการลัดขั้นตอนด้วยเงื่อนไข "อย่าทริกเกอร์หากมี X อยู่"

---

การกู้คืนเอาต์พุตดิบและเกตตรวจสอบ

เมื่อ RTK บีบอัดเอาต์พุตอย่างเข้มข้น คุณสามารถ กู้คืนข้อความต้นฉบับ เพื่อใช้ในการดีบัก การตรวจสอบ หรือการเล่นซ้ำได้

วิธีการทำงานของการกู้คืนเอาต์พุตดิบ

เอาต์พุตต้นฉบับ (10K โทเค็น)
        │
        ▼
RTK บีบอัด (โดยตั้งค่า rawOutput.enabled=true)
        │
        ├─▶ เอาต์พุตที่บีบอัดแล้ว (2K โทเค็น)  ──▶ ส่งไปยัง LLM
        │
        └─▶ เอาต์พุตต้นฉบับ (10K โทเค็น)       ──▶ จัดเก็บใน DB
                                                  (เชื่อมโยงด้วย request_id)

การเปิดใช้งานการจัดเก็บเอาต์พุตดิบ

ต่อคำขอ (ในการกำหนดค่าแบบผสม):

{
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive",
    "rawOutput": {
      "enabled": true,
      "maxBytes": 1048576 // ขีดจำกัด 1MB
    }
  }
}

ค่าเริ่มต้น: rawOutput.enabled: false (ช่วยประหยัดพื้นที่จัดเก็บ)

ค่าใช้จ่ายด้านพื้นที่จัดเก็บ

ต่อคำขอ	ขีดจำกัด 1MB	ขีดจำกัด 10MB
เอาต์พุตที่บีบอัดโดยเฉลี่ย	~5KB	~5KB
เอาต์พุตดิบที่จัดเก็บ	~50-500KB	~500KB-5MB
เมื่อมี 1000 คำขอ/วัน	50-500MB/วัน	500MB-5GB/วัน

คำแนะนำ: เปิดใช้งานเอาต์พุตดิบเฉพาะสำหรับ เซสชันการดีบัก หรือ การตรวจสอบแบบสุ่มตัวอย่าง เท่านั้น ไม่ควรเปิดใช้งานตลอดเวลา

การกู้คืนข้อมูลต้นฉบับ

import { readRtkRawOutput } from "omniroute/compression/engines/rtk/rawOutput";

const raw = readRtkRawOutput(pointerId); // pointerId จากสถิติการบีบอัด
if (raw) {
  console.log("Original output:", raw);
}

pointerId จะถูกส่งคืนใน CompressionStats.rtkRawOutputPointers[] หลังการบีบอัด ดูลายเซ็นของฟังก์ชันได้ที่ open-sse/services/compression/engines/rtk/rawOutput.ts:102

เกตตรวจสอบ

การตรวจสอบตัวกรอง RTK (open-sse/services/compression/engines/rtk/verify.ts) จะตรวจสอบความถูกต้องของตัวกรองทั้งหมดเทียบกับ tests[] และทำให้มั่นใจว่าการทำงานถูกต้องในระดับความเข้มข้นทั้ง 3 ระดับ

เรียกใช้ runRtkFilterTests() เพื่อดำเนินการตรวจสอบ:

import { runRtkFilterTests } from "open-sse/services/compression/engines/rtk/verify";

const result = runRtkFilterTests();
console.log(`Passed: ${result.outcomes.filter((o) => o.passed).length}`);
console.log(`Failed: ${result.outcomes.filter((o) => !o.passed).length}`);
if (!result.passed) {
  console.error("Filters failed verification");
  result.outcomes
    .filter((o) => !o.passed)
    .forEach((o) => {
      console.error(
        `  - ${o.filterId} / ${o.testName}: expected "${o.expected}", got "${o.actual}"`
      );
    });
}

สิ่งที่ระบบตรวจสอบ:

1. ตัวกรองทุกตัวโหลดได้และผ่านการตรวจสอบสคีมา
2. แต่ละรายการใน tests[] ให้ผลลัพธ์ตามที่คาดไว้
3. ระดับความเข้มข้น minimal จะไม่ดำเนินการใดๆ (คงข้อมูลต้นฉบับไว้ และใช้เฉพาะตัวกรองเชิงโครงสร้าง)
4. ระดับความเข้มข้น aggressive จะคงข้อผิดพลาด การทดสอบที่ล้มเหลว และสแต็กเทรซไว้
5. เอาต์พุตที่บีบอัดแล้วจะไม่มีขนาดใหญ่กว่าอินพุตต้นฉบับ

• ซอร์ส: open-sse/services/compression/engines/rtk/ (63 ไฟล์, ~70KB)

• ก่อนผสานการเปลี่ยนแปลงตัวกรอง — ตรวจสอบให้แน่ใจเสมอว่าการทดสอบผ่าน

• หลังอัปเกรดกลไก RTK — สคีมาอาจมีการเปลี่ยนแปลง

• เป็นระยะระหว่างการเฝ้าติดตาม — ป้องกันความคลาดเคลื่อนของฟิกซ์เจอร์ทดสอบ

• เมื่อเพิ่มเครื่องมือหรือตระกูลคำสั่งใหม่ — พิสูจน์ว่าตัวกรองใหม่ทำงานได้

---

ดูเพิ่มเติม

• COMPRESSION_GUIDE.md — ภาพรวมฉบับสมบูรณ์ของไปป์ไลน์การบีบอัด
• COMPRESSION_ENGINES.md — รีจิสทรีเอนจินและเอนจินในตัว
• EXTENDING_COMPRESSION.md — เอนจินแบบกำหนดเอง แพ็กภาษา และไปป์ไลน์แบบซ้อน
• ซอร์ส: open-sse/services/compression/engines/rtk/ (63 ไฟล์, ~70KB)