หัวเรื่องเรื่องต้นฉบับ: ทำไมเซสชัน OpenClaw ของฉันไร้ว่าด้วย 21.5M โทเค็นในหนึ่งวัน (และสิ่งที่แก้ไขจริง)
ผู้เขียนเรื่องต้นฉบับ: MOSHIII
คำแปล: Peggy, BlockBeats

หมายเหตุจากบรรณาธิการ: ในช่วงเวลาที่การใช้งานแอปพลิเคชัน Agent ขยายพื้นที่อย่างรวดเร็ว ทีมหลาย ๆ ทีมพบกับปัญหาที่ดูจะผกผัน: ระบบดำเนินการตามปกติ แต่ค่าโทเคนกลับเพิ่มขึ้นอย่างต่อเนื่องโดยที่ไม่มีคำนึงเหมือนจะเห็น. บทความนี้ทำการวิเคราะห์ OpenClaw workload ที่แท้จริงแล้วพบว่าเหตุผลในการเพิ่มค่าที่ตั้งใจในส่วนมากไม่ได้มาจากข้อมูลของผู้ใช้หรือค่าเอาต์พุทของโมเดล แต่มาจากการเล่นคำสั่งที่ไม่ได้รับความสนใจ (cached prefix replay) โมเดลจะอ่านเนื้อเรื่องใหญ่ทุก ๆ รอบการเรียกใช้งานซ้ำ ๆ ซึ่งเป็นที่มาของการใช้งานโทเคนอย่างยิ่ง

บทความนี้รวมข้อมูลเซสชันที่เฉพาะเจาะจง โชว์เอาต์พุทของเครื่องมือ snapshot บราวเซอร์ และการบันทึก JSON ที่มีขนาดใหญ่ ๆ ที่ได้ถูกติดต่อกันเขียนลงในเนื้อเรื่องที่เก่า ๆ และถูกไล่อ่านซ้ำในลูปของเอเจ้นต์

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

ด้านล่างคือเนื้อหาต้นฉบับ:

ฉันทำการวิเคราะห์งานที่แท้จริง OpenClaw เห็นเจอลูปของผู้ใช้ Agent จำนวนมากระงับ:

การใช้โทเคนดูเหมือนจะมีชีวิตชีวา

การลืมดูดข้อมูลดูเหมือนสมควร

แต่การบริโภคโทเคนเพิ่มขึ้นโดยไม่คาดคะน

ด้านล่างคือการวิเคราะห์ของคราว เนื้อหาเชิงเทิศน์ อันเป็นต้นไปของปัญหา และเส้นทางการซ่อมแซมที่เป็นไปได้

TL;DR

ปัจจัยการขับเคลื่อนค่าใช้จ่ายที่ทีมใหญ่ที่สุด ไม่ใช่ข้อความของผู้ใช้ที่ยาวเกินไป แต่เป็นการส่งเสริมค่า cache prefix ที่เยอะมากให้เร่งด่วน

ตั้งแต่ข้อมูลเซสชันมอง:

โทเคนทั้งหมด: 21,543,714

การอ่านแคช: 17,105,970 (79.40%)

อินพุต: 4,345,264 (20.17%)

เอาต์พุต: 92,480 (0.43%)

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

ช่วงเวลาที่มีคำถามว่า "รอแป๊บ ทำไมถึงเป็นอย่างนี้?"

เดิมๆ ฉันคิดว่าปริมาณการใช้โทเค็นสูงเกิดจาก: ข้อความผู้ใช้ที่ยาวมากเกินไป, การสร้างเอาต์พุตจำนวนมาก, หรือการเรียกใช้เครื่องมือที่ค่อนข้างแพง

แต่แบบแบ่งปันจริงๆ คือ:

อินพุต: ระหว่างร้อยถึงพันโทเคน

การอ่านแคช: 17,000 ถึง 18,000 โทเคนต่อการเรียกครั้ง

กล่าวคือ โมเดลทุกรอบจริงๆ ทำการค้นข้อมูลหนึ่งอย่างเดียวขนาดย่อ

ขอบเขตข้อมูล

ฉันได้วิเคราะห์ข้อมูลในระดับสองด้าน:

1. บันทึกเวลารัน (runtime logs)
2. บันทึกสนทนา (session transcripts)

ควรระบุว่า:

บันทึกเวลารันใช้สำหรับการสังเกตสัญญาณพฤติกรรม (เช่น รีสตาร์ท, เออเร่อ, ปัญหาการกำหนดค่า)

สถิติโทเคนที่แม่นยำมาจากฟิลด์การใช้งานใน JSONL ของเซสชัน

สคริปต์ที่ใช้:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

ไฟล์การวิเคราะห์ที่สร้าง:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

Token ที่ใช้จริงมาจากไหน?

1) การใช้งาน Session ที่มีการรวมกัน

มีการใช้งานของ session ที่สูงมากกว่าอีก session:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens

แล้วมีการลดลงที่ชัดเจน:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2) การใช้งานที่มีการกระจาย

Token มากที่สุดมาจาก:

toolUse: 16,372,294

stop: 5,171,420

ปัญหาถูกต้องพบที่การเรียกใช้เครื่องมือวนเวียนและไม่ใช่การสนทนาปกติ

3) การใช้งานที่มีการกระจายตามเวลา

ค่าสูงสุดของ token ไม่ได้เป็นสุ่มแต่มีการกระจายในช่วงเวลาบางช่วง:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

คำขึ้นต้นของแคชขนาดใหญ่เก็บข้อมูลอะไร?

ไม่ใช่เนื้อหาของการสนทนา แต่เป็นสิ่งสำคัญที่ใหญ่:

ชุดข้อมูลขนาดใหญ่ของเครื่องมือ

ร่องรอยการคิดถึง/ความคิด

สแนปช็อตขนาดใหญ่

รายการไฟล์

ข้อมูลการดึงจากเบราว์เซอร์

บันทึกของสายต่อของเอเจนต์ย่อย

ในเซสชันขนาดใหญ่สุด มีประมาณจำนวนตัวอักษรดังนี้:

toolResult:text: 366,469 ตัวอักษร

assistant:thinking: 331,494 ตัวอักษร

assistant:toolCall: 53,039 ตัวอักษร

เมื่อเนื้อหาเหล่านี้ถูกเก็บไว้ในบริบทประวัติของมัน การเรียกครั้งถัดไปอาจจะใช้การเรียกในแคช(prefix) เพื่ออ่านมันอีกครั้ง

ตัวอย่างเฉพาะ (จากไฟล์เซสชัน)

มีบล็อกบริบทที่มีขนาดใหญ่ซ้ำกันติดต่อกันในตำแหน่งดังต่อไปนี้:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

บันทึก JSON ขนาดใหญ่ของเกตเวย์ (ประมาณ 37,000 ตัวอักษร)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

สแนปของเบราว์เซอร์ + การห่อหุ้มที่ปลอดภัย (ประมาณ 29,000 ตัวอักษร)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

เอาท์พุตขนาดใหญ่ของไฟล์รายการ (ประมาณ 41,000 ตัวอักษร)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

สแนปของสถานะ session/status + โครงสร้างโปรมป์ขนาดใหญ่ (ประมาณ 30,000 ตัวอักษร)

ความสูญเสียข้อมูลที่ซ้ำซ้อน vs ภาระการเล่นความท้าทายของแคช(prefix)

ฉันยังวัดอัตราส่วนของข้อมูลที่ซ้ำกันในการเรียกครั้งเดียวกัน:

อัตราส่วนของข้อมูลที่ซ้ำกันประมาณ: 1.72%

มันอยู่เหนือเหวี่ยงแต่ไม่ใช่ปัญหาหลัก

ปัญหาจริงอยู่ที่: ขนาดแบบไม่เปลืองของแคช(prefix)

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

ดังนั้น จุดประสงค์ในการปรับปรุงไม่ได้มุ่งเน้นไปที่การลดขนาดข้อมูลเท่านั้น แต่เน้นไปที่การออกแบบโครงสร้างของข้อมูลให้อยู่ในบริบทที่เหมาะสม

ทำไมวงจรของเอเจ้นท์มักจะพบปัญหานี้ได้ง่าย?

มีสามกลไกที่ทำงานร่วมกัน:

1. ข้อมูลเอาท์พุตจากเครื่องมือจำนวนมากที่ถูกบันทึกลงในคอนเท็กซ์ประวัติ

2. วงจรของเครื่องมือจะสร้างการเรียกใช้ในช่วงเวลาสั้นๆ อย่างต่อเนื่อง

3. การเปลี่ยนแปลงข้อมูลบางส่วนเล็กน้อย → การเก็บข้อมูลขนาดใหญ่ใหม่ทุกครั้ง

หากการบีบอัดข้อมูลในบริบทไม่ปรากฏ ปัญหาก็จะโตขึ้นเร็วๆ นี้

วางแผนการแก้ไขที่สำคัญสุด (เรียงตามการกระทบ)

P0—อย่าให้ข้อมูลเอาท์พุตของเครื่องมือขนาดใหญ่เข้าคอนเท็กซ์ยาวนาน

สำหรับข้อมูลเอาท์พุตขนาดใหญ่:

· รักษาสรุป + พาธอ้างอิง / รหัส

· ข้อมูลเดิม บันทึกลง artifact ไฟล์

· อย่าเก็บข้อความเต็มรูปแบบไว้ในประวัติแชท

ให้ความสำคัญในการจำกัดหมวดหมู่เหล่านี้:

· JSON ขนาดใหญ่

· รายการโฟลเดอร์ยาว

· สแนปช็อตของเบราวเซอร์

· สปีชช์แอเจนต์เต็มรายการของบทสนทนา

P1—ตรวจสอบว่ากลไกการบีบอัดมีผลจริง

ในข้อมูลดังกล่าว ปัญหาความสอดคล้องกันในการปรากฏ: คีย์การบีบอัดไม่ถูกต้อง

สิ่งนี้จะทำให้กลไกการปรับปรุงถูกปิดอย่างบ่อยครั้ง

ปฏิบัติตามวิธีที่ถูกต้อง: ใช้การกำหนดค่าที่สำคัญของเวอร์ชั่นเท่านั้น

แล้วตรวจสอบ:

openclaw doctor --fix

และตรวจสอบบันทึกเริ่มต้นเพื่อยืนยันว่า การบีบอัด ถูกต้อง

P1—ลดการจดจำข้อความแบบเหตุผล

หลีกเลี่ยงการรักษาข้อความเหตุผลยาวไว้เพื่อทำให้มันถูกเล่นซ้ำๆ

ในสภาพแวดล้อมที่เป็นการทำงานจริง: รักษาสรุปสั้น ๆ แทนการรักษาเหตุผลทั้งหมด

P2—ปรับปรุงการออกคำสั่งของแคช

เป้าหมายไม่ใช่ให้ cacheRead สูงสุด แต่เป้าหมายคือการใช้งานแคชบน prefix ที่เสถียร คมชัด และมีความคุ้มค่า

ข้อเสนอ:

· ใส่กฎที่เสถียรเข้าไปในระบบพรอมป

· อย่าใส่ข้อมูลที่ไม่เสถียรลงบน prefix ที่เสถียร

· หลีกเลี่ยงการฉีดข้อมูล debug จำนวนมากในแต่ละรอบ

แผนการป้องกันความเสียหาย (หากพรุ่งนี้ฉันต้องจัดการ)

1. หา session ที่มีการใช้งาน cacheRead สูงสุด
2. รันคำสั่ง /compact สำหรับ session ที่มีปัญหา
3. เพิ่มการตัดข้อมูลและการทำให้เป็น artifact ในเครื่องมือ
4. รีรันสถิติ token ทุกรอบหลังการแก้ไข

ติดตามจุดสำคัญที่สี่ KPI:

cacheRead / totalTokens

toolUse avgTotal/call

จำนวนครั้งที่มีการเรียกใช้ toolUse ที่มี token เท่ากับหรือมากกว่า 100k

สัดส่วน session สูงสุด

สัญญาณความสำเร็จ

หากการปรับปรุงเป็นประโยชน์ คุณควรเห็น:

การเรียกใช้ token มากกว่า 100k ลดลงอย่างชัดเจน

สัดส่วนของ cacheRead ลดลง

การเรียกใช้ toolUse ลดลง

ระดับความสำคัญของ session แต่ละรายการลดลง

หากพบว่ามีการเปลี่ยนแปลงใดๆ จากข้างต้น หมายความว่ายังมีความคุ้มค่าของมาตรการขอบเขตของคุณ

คำสั่งการทดลองเอาชนะ

python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt

สรุป

หากระบบ Agent ของคุณดูเหมือนปกติ แต่ต้นทุนกำลังเพิ่มขึ้น คุณอาจต้องตรวจสอบปัญหาหนึ่งนี้ก่อน: คุณจ่ายเงินสำหรับการอุดตัวที่ใหม่ หรือกำลังทำการ์ตูนความเสี่ยงในลักษณะอดีตใหญ่?

ในกรณีของฉัน ความเสียหายในส่วนใหญ่เป็นเพราะ การทำการ์ตูนความเสี่ยงในลักษณะอดีต

เมื่อคุณตระเวนสติมะเข้าสู่จุดนี้ คำตอบก็กลายเป็นชัดเจน: ควบคุมข้อมูลที่เข้าสู่บทบาทยาวนานอย่างเข้มงวด

[ลิงก์ไปยังบทความเดิม]

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia